2023年上半期振り返り

雑多に振り返り。

1年おきでしたが、半年でやってみました。去年のものはこれ。

blog.zuckey17.org

仕事

引き続きスタディストでエンジニアリングマネージャーとして働いていますが、最近は入社より携わっている事業の開発責任者というふうに自己紹介することも増えてきたのかなと思います。後に触れる通り採用の兼ね合いでその方がわかりやすいかなと思ってのことなんですが、コードを書く時間よりもプロダクトマネジメントについて考えることが増えているというのもあります。

この6月で在籍3年半となりキャリア最長記録を更新中です。

コードも書いてはいますが、メンバーには大玉を任せつつ僕はその周りの雑務とレビューという感じ。リリースから2年半となっており、コードの削除が気持ちいいです。

4月に入ってからまだ2週間経過してないけど、すでに1万行以上プロダクションコード削除している気がする。
採用のこととか、目標設定とか、そんなことよりも優先的にやることあるのに。

— zuckey ずっきー (@zuckey_17) 2023年4月13日

採用

前回の振り返りで採用を頑張る年にしたいと書いていましたが、とくに3月より採用に一定のリソースをさくようになりました。

媒体からスカウトを送ったり、面談・面接をしたりですが、右も左もわからないのでまずは、人事から進めてもらった書籍を読みました。特に良かったのは「経営×人材の超プロが教える人を選ぶ技術」で、エピソードの深掘りの重要性とその方法について学びました。

以前Podcastをやっていて、聞いたエピソードに対して事前のインプットとの関連からストーリー性を探して推測しすぎてしまったり、解釈を加え過ぎてしまったりする癖があったので修正しました。一方で、あまり意識しすぎると楽しくない時間になってしまうので、バランスが難しいところです。

youtrust.jp

YOURTRUSTでカジュアル面談も公開しているので少しでも気になる方いらっしゃったらお声がけください。Twitter DMでもOKです。

採用関係なく、zuckeyと雑談してみたいという人もWelcomeです。

その他

6月は会社でブログ執筆月間というのをやっていて3本ほど記事を書きました。ただ、あんまりPVが伸びなかったなぁというのがくやしかったので、もう少し見られる記事を書けるようになれたらなと思いました。まずは個人のブログを定期的に更新せねばな、と思ってはいます。

そのブログの1つにも書きましたが、認定スクラムマスターの研修を受けてきたので、採用でメンバーも増えるし、良いチームをつくるということを頑張りたいですね。

studist.tech

プライベート

プライベートは去年生まれた息子中心の生活になっています。

この状態から起こさずに抱っこひもを抜く方法 pic.twitter.com/K53KEFy55r

— zuckey ずっきー (@zuckey_17) 2023年1月28日

メインは風呂と寝かしつけ担当という感じ。特に平日の大半面倒を見てくれる妻に感謝です。

まだ、あまり遠出はできておらず、唯一の遠出は奈良の実家への初めての帰省でした。

妻も初めてで「東京は山が見えなくてつらい、と言っている意味がようやくわかった」という言葉をもらいました。

ペーパードライバー講習を受けてから全く乗れていないので、もう一度頑張りたい、という気持ちです。

AtCoderを初めてみた

GW明けくらいから競技プログラミングの勉強を始めました。採用活動をしていると候補者の方で競プロをされている方もチラホラおり、あと Rebuild.fm でnaoya_itoさんがいつ始めてもよい、みたいなことを仰っていたので始めたんですが、全然成果は出てません。

鉄則本 を進めつつ、土曜日のABCに出るというのをやっていますが、ここ2週間くらい1週分の離乳食づくりで参加がとまっており、すると学習の頻度も落ちてしまっています…

定期的にコンテストに出てフィードバックをもらうの大事ですね。引き続きゆるゆるとやっていきます。

英語

4月頃から英語を頑張る期間n度目に入っています。基本は英単語とシャドーイング。

業務上も英語の必要性をちょくちょく感じるようになり、比較的長く続いているイメージ、どこまで続くのやら。

英単語は、はじめTOEICむけの『金のフレーズ』をやってましたが、2.5週くらいして語彙数が少ない気がして、「Distinction 2000」というのをやり始めました。どちらもabceedというアプリで音声も流せるのでよいです。

シャドーイングは、「タニケイ式シャドーイング」 を一通り読んでから、TEDの動画をシャドーイングしてます。

今のところ1.5ヶ月くらいやってますが、成長は見られないのでちょっとつらい。継続が必要。

英語のシャドーイング一向にうまくなってなくてつらい。
楽しくなるかなと思って、洋楽のコピーも織り交ぜたりしてるけど、絶対1音も現れてない単語あるし厳しい。
リダクションじゃない、これはもう1音もない。

— zuckey ずっきー (@zuckey_17) 2023年6月9日

notion でタスク管理

asana使ってると書いたが、ちょうど体験が終わってルールが使えないことがわかったので移行先考えてる...
ちょっと1200/月は高い...

— zuckey ずっきー (@zuckey_17) 2023年1月7日

notionでのタスク管理を始めてみました。昨年、エンジニアリングマネージャーのしごとという本を読んでからAsanaを使ってタスク管理していましたが、ワークフロー自動化の機能が有料で、1200円/月と高く感じたので notion のDBで管理し始めました。

課金してAPIも利用してタスク管理していますが、Macからタスクを追加したり、GitHub Actionsで定期実行してAsanaのワークフローのような体験を実現しました。

notion AI も始まっているので、会社のブログのためにも使ってみましたが、箇条書きから、文章生成しても、結局ほぼ全て書き直ししています。プロンプトが悪いのかもしれませんが、現状あまり使い所を見つけられていません。

エンタメ

今年入ってからほぼゲームができてません。新しい漫画をいくつか一気に読みました。

TotKは買ったのに起動してもいないです。

YouTube

人狼ゲームを見るのが楽しく、「おさかなじんろう」というのが上がったらその度に見てます。

時々業務で人狼用語を使ってしまいそうになってしまうので良くないですね。

https://www.youtube.com/hashtag/おさかなじんろう

ゲームさんぽの方が独立されてチャンネルを立ち上げられたのでそちらも見てます。

www.youtube.com

漫画

新しく読んだ、読み始めたシリーズは以下。

• アオのハコ
• 海が走るエンドロール
• 左利きのエレン
• 僕の心のヤバいやつ
• スキップとローファー
• 進撃の巨人
• あかね噺
• 違国日記
• リヴァイアサン
• BEASTARS
• チ。―地球の運動について―

特に、「違国日記」がよかったです。もう少し日々を思い返せるようにしたほうが良いなとおもって、この振り返りも半年で筆を取ってます。

「スキップとローファー」とか、「僕ヤバ」、「アオのハコ」みたいないわゆる学園モノをこの年になってこんなに読むことになるとは思ってなかったですが、良いものですね。

「左利きのエレン」はいつか読んでみるかーとおもっていたんで一気見したんですが、終盤思ったよりも超能力モノみたいな感じになっていてあんまり好きじゃなかったかもしれないです。

アナログゲーム

友人と2回ほどボードゲーム会をやりました。休日の昼間から始まって夕方には解散するという健康的なボードゲーム会です。

定期的に開催されるようになったら嬉しいので、忘れないように声を書けないといけないですね。

第1回 bodoge.hoobby.net

第2回 bodoge.hoobby.net

おわり

分割キーボード MOONLANDER MARK I を買って設定し3ヶ月使ってみた

MOONLANDER MARK Ⅰ という分割キーボードを購入しました。

www.zsa.io

黒に赤の差し色がかっこいい

MOONLANDERはカナダの会社ZSA Technology Labsさんのプロダクトで、僕は以前からこの会社の Ergodox EZ を愛用しています)。

左右に分離したキーボードは肩甲骨を開いた状態でタイピングができるので、姿勢よく作業ができ肩こりや腰痛に効果があります（と信じています）。

MOONLANDERとErgodoxとの比較と感想

Ergodoxはよいキーボードなんですがいかんせん大きくて分厚いので持ち運びには向きません。 MOONLANDERはErgodoxの後継にあたるモデルで軽量化、スリム化されてポータビリティが上がっています。

具体的な進化ポイントは以下のような感じです。

• ポータビリティ
  • リストレスト一体型
  • スリム化、軽量化
• 親指部分のキーの角度を変えることができる
• USBのポートが Type-C に変更（Ergodoxは USB miniBなのでケーブルが限られた）
  • 位置も右から左に。右のマウスの領域に影響がない
• キーボードが虹色に光る
  • 全体が虹色に光りますし、設定によってはレイヤーごとに色を変えることもできる

逆に親指部分のキーの数はErgodoxより減っています。

すでに購入から3ヶ月使ってみており、比較してみた感想は

• リストレストはよくずれるし、ゴム製だと汚れが目立つため、プラスチックで一体になっているのはよい
• Type-Cポートがケーブルの選択肢が増えて嬉しい
• ほとんど外出しないので長距離の移動はわからないが、ダイニングテーブルでiPadを利用するときに使うために書斎からさっと運ぶハードルはぐっと下がった

というかんじです。

Cloud9をiPadから使うのはこのあとやめました

2022の振り返りでも書きましたが、子供が生まれ休日のちょっとした時間の作業はダイニングテーブルで作業することが増えました。そのために役に立っています。

購入から到着

Webサイトでの購入から11日で到着しました。（9月21日に購入し、10月2日に到着しました）
DHL EXPRESSで台湾から送られてきましたが、注意すべきは関税の支払いです。 Webページで商品の支払いは完了しますが、キーボードが日本に入るときに関税を支払う必要があります。ZSAからではなくDHLからメールが届くのでリンクからクレジットカードなどで支払う必要があります。僕の場合は2800円でした。

設定方法

基本的には、以前に書いたErgodoxの設定方法とほぼ同じです。 ErgodoxとMOONLANDERでは親指部分のキー配列が微妙に異なるため、レイアウト編集のためのWebアプリケーションのURLが以下に変わっています。

Oryx: The ZSA Keyboard Configurator

おわり

コロナもそろそろ落ち着いてきたと思いきやまた感染拡大しており、いつになったらしたいタイミングで出社できる*1のかわかりませんが、気軽にキーボードを持ち歩ける日々が待たれます。

*1:気軽に飲みに行きたいものです

ペーパードライバー歴10年、出張講習で3時間公道を走ってきた

年末の振り返りでペーパードライバーを卒業して車に乗りたいという目標を掲げたので、早速行ってきました。 教えてもらったことを振り返りつつメモを残しておこうと思います。

2012年、学生時代に免許を取得してすぐに1度だけ運転して以来、一度も乗ったことがなかったので10年ぶりの公道での走行でした。 今日の講習のはじめ、ブレーキを左足で踏もうとしたぐらい何もかも忘れていましたが、終わるころには次またすぐ運転したい！と思うくらいには楽しかったです。

ペーパードライバー講習

世の中にはペーパードライバー講習というものがあるようで、いわゆる教習所と出張型のタイプがあるようです。 軽く調べたところ都内だと3時間2万円前後で受けられそうです。

いきなり公道が怖ければ教習所、普段利用する道で練習をしたければ出張型、という整理でしょうか。

教習所や大手のペーパードライバー講習のサービスだとかなり先まで予定が埋まっていたため、以下のサイトで口コミを見つつ探して予約しました。

ペーパードライバー講習を探すなら、[ペーパードライバーナビ]

最終的にRe:Driversというスクールにお世話になりました。 スクールといいつつおそらくお一人で運営されているようで、予約の確定や問い合わせなどもメールでやり取りしました。 3時間で1万8000円のコースを受講しました。

講師の方はもともと教習所で教えておられたようで、教習所で見たことがあるような本や資料を使いつつ丁寧に教えて下さいました。個人的に教習所の先生はあまり好きな人が多くなかったんですが、この方はフランクで雰囲気も良かったのでおすすめです。東京・神奈川・千葉なら出張可能みたいなのでぜひ。 (何ももらってません)

教習車もプリウスで高級感ありつつ乗りやすかったです。マイカーでも講習を受けられるみたいです。

なにより、大晦日に予約をし1月4日に受講できたので思い立ったときに実行に移せて良かったです。

講習内容

講習内容は以下のような感じでした。 備忘を兼ねて。

教習所にいたときのことを正確には覚えていないですが、短い時間だったからか、より実践的なアドバイスが多かったような気がしました。

運転する道は希望があれば聞いていただけるようでしたが、僕は特になかったのでおまかせしました。

座席の調整や基本操作の確認15分

• 座席の調整
  • ブレーキを踏んで足が少し曲がる程度に調整
  • 座面は道路が見やすいように高めに設定
  • シート角度はハンドルの上を両手で持ったときにちょうど腕が伸び切るくらい
• ミラーの調整
  • バックミラーはリアガラスがすべて見えるように
  • サイドミラーは左右それぞれ車体の1/4が入っていて、地面が1/2くらい見えるように
• シフトレバーの操作、パーキングの入れ方、MTでとの差分
• サイドブレーキの操作、プリウスは左足で押し込むタイプのサイドブレーキ
• ウィンカー、ライト、ワイパーの操作

意外と忘れていることが多かったですが、必要最低限の情報を伝えていただけて好印象でした。

近所をぐるぐる 1時間ほど運転

• 30km/hの道を左まわり、右回り変えつつゆっくり走行
  • 住宅街なので細い道を飛び出しに注意しつつ
• 車体の左右へのよせ方、停車
• 右左折の際の歩道の確認、タイミング
• 左折時の内輪差の把握とハンドルを切るタイミング
• 細い道での対向車の対応と信号の待ち方

はじめは30km/hでも速く感じて怖かったですが、教習所の車と同様助手席からのブレーキもあったので安心して運転できました。 結局助手席ブレーキの活躍の機会はなかったですが、やはり１人でいきなり練習するとそうはいかないのでよかったです。

残りの時間、家から10km圏内位を少し広めの道路を中心に運転

• 片側2車線の道路（50km/h）の道を走行
• 大きい交差点での右折
• 車線変更のための確認
• 信号や道路標識の意味を適宜クイズ形式で確認

半径10km圏内くらいを運転できて、行きたいなと思っていた大きめの公園の近くまでいけたので、出張型を選んでよかったなと思いました。

家の周りに帰ってくる頃には30km/hがゆっくりに感じて、近所の道も視野を広く保ちながら落ち着いて乗れるようになっていて感動しました。

駐車が不安だったんですが、それを伝え忘れて練習ができなかったのが心残りです。口コミには駐車も練習された方もいらしたのでできそうでした。

今後

近所にカーシェアサービスがあるので、まずはもう少し1人で練習したいですね。 今日は1月4日で普段よりも都内の交通量が少なかったようなので少し不安もありますが、楽しみです。

将来的には、子供を連れてキャンプに行きたいので引き続きチャレンジしていきます。

めちゃくちゃ運転にハマったら車を買ってしまう未来もあるのかもしれないです... 💸

2022年の振り返り

2022年の振り返りです。雑多に。

去年のものはこれ。

blog.zuckey17.org

仕事

引き続き、株式会社スタディストにて、エンジニアリングマネージャーとして働いています。 今年の頭に、開発本部エンジニアリング部 副部長という立場に任用いただきましたが、変わらず新規事業を成功させることに軸足をおいています。 この12月で丸3年となりキャリア最長記録を更新中です。

チームを一歩前にすすめる取り組み

人数の増減はあれどチーム結成から2年以上経つと、チームとして新しいチャレンジをしていきたくなるものです。

個人的にも事業立ち上げの際に僕自信の手に馴染んだ言語、環境、フレームワークを選択してきたので、変化が欲しいタイミングでした。

変化を意識的に起こしていくためにも、会社の他のチームメンバーに「あそこはなんか勢いありそうだぞ」と思ってもらうためにも、年始から動いていました。

studist.tech

特にTypeScript を本番に導入して運用するのは初めてで開発体験も良かったなと思っており、来年は既存システムのフロントエンドの置き換えをしたいなと思っています。

採用

2022年の振り返りではないんですが、2023年は採用を頑張る年にしたいです。 2年もマネージャーをしているのに採用の実績がありません。 新規事業でミニマムなチームでやりくりしていたこと、ちょうどよく社内でリクルーティングできていたために本腰を入れることがありませんでした。 事業の成長により本格的にチームの拡大を目指すため、採用を頑張りたいです。 採用、オンボーディング、チームの拡大によってマネージャーとしても一皮むけたいなと思っています。

すでに募集しており、詳細については弊社VPoEのブログが凄くよくまとまっていたので貼っておきます。 興味がある人は僕個人でも良いので連絡ください。

studist.tech

成功させるためにも、アウトプットや露出を増やしたいですね。

インプット

去年はインプットが少なかったと書きました。 今年は書籍を読み上げさせて聞くことによってかなりインプットを増やすことに成功しました。

blog.zuckey17.org

コードがあまり出てこない本でいうと以下の書籍を読みました。増やせたような気もしますが波もあり、まだまだ少ないような気がします。

昨年末にチームトポロジーを読みましたが、僕は基本1チームで開発しているためそこまでしっくりこず、年明けから前半はコーチング関連の本をいくつか集中的に読みました。
後半は、オライリーから出ているマネジメント系の本を中心にマネジメント業務について体系的にインプットしました。

2023年はコーチングを実務にもっとしっかり落とし込んだり、チーム外でもコーチングの実績を作ることができたら面白いかもな、と考えています。

また、英語でインプットできるようにしたい、という気持ちがあり、以下の本を読みはじめました。 友人も巻き込んだのに途中で脱落する、というゴミムーブをカマしてしまったので、来年はリベンジしたいと思います。

Amazon.co.jp: A Philosophy of Software Design, 2nd Edition (English Edition) 電子書籍: Ousterhout, John K. : 洋書

直近ではないですが、将来英語で仕事ができるようになりたいとも思っており、来年はそういう準備にも力を入れていきたいです。

プライベート

大きなライフイベントがあり、夏以降ガラッと生活スタイルが変わりました。

子供が生まれた

夏に子供が生まれました。 それに伴い8月中旬から10月末まで約2ヶ月半の間育休を取得しました。 マネージャーとして育休を取ることについて、快く送り出してくれたメンバーに感謝しています。

まだまだ乳児で、首も完全には据わっていない状態なんですが、表情が豊かになってきて、笑顔が育児の大変さを癒やしてくれます。

これからどんどん動くなって目が離せなくなると思うとゾッとしますが、楽しんでいきたいです。

子供ができると車に乗れるようになったほうがいいな、と思う機会が増えました。 ペーパードライバー歴11年ですが、近場にカーシェアのある駐車場があるので、来年は車に乗る練習をしていきたいなと思っています。

住み替え

去年は書斎のために家を購入し直したと書きましたが、子供が生まれることに備えたものでした。 1LDKだったところが3LDKになりました。念願の書斎（兼物置）も手に入れました。

前の家は西新宿だったのでアクセスや利便性がかなり良かったのですが、少し都心からは遠くなりファミリー層が多いエリアになりました。

住み替えに際してFPに相談し最低限の保険にも加入しましたが、子供が生まれたので再度見直す必要がありそうです。

旅行

子供が生まれる前、駆け込みで夫婦2人の最後の旅行に行きました。 ちょうどコロナが落ち着きを見せているタイミングを狙って、石垣島と横浜に行きました。

石垣島（4月）

GWすこし手前に行きました。石垣島はコロナの第1波が落ち着いたタイミングで新婚旅行に行ったんですが、もう一度2人で行っておきたいということで安定期を狙って行きました。

フサキビーチリゾートに2泊3日し、短い期間でしたが中日に竹富島にまでいけてかなり充実していました。 フサキの夕日がもう一度見たいと思っていたので、綺麗な夕日が見れて満足でした。

今回は基本タクシーで移動しました。基本ホテルでゆっくりしたので良かったんですが、次家族で来るときは石垣島を車で移動したいです。

フサキビーチの夕日、南国っぽい写真、フサキのプール

有名なアイス店からのフサキビーチの眺めとアイス、竹富島コンドイビーチ

横浜（7月）

近場であれば良いだろうということで横浜のランドマークタワーの上にある横浜ロイヤルパークホテルに泊まりました。 基本ホテルでまったりしつつ、食事とショッピングを楽しむという優雅な休日を過ごしました。

部屋から見た景色

エンタメ

ゲーム

Minecraft

今年はあまりゲームをしませんでしたが、時たま開いてはちょっとだけワールドをいじるというのを続けていました。 また、MODを入れてみるなどをして、影MODで建築をきれいに見せてみたり、縛りプレイ要素を導入したりして楽しみました。 ゲーム実況は引き続き時間があるときに見ているので、将来息子とやったときにドヤれるように腕を磨きたいです。 Java がかければ MODも作れるのでやってみたいなと思いましたが、PCが必要っぽいので一旦断念しました。

天空の庭園

Factorio

Switch 版が出たので、やってみました。 サンドボックス型のゲームが好きなのでやはりハマりましたが、時間が吸われて仕方がないのでパタッと触らなくなりやめました。 Switch 版だと要素の選択がスティック操作で難しいのでやはりPCが欲しくなります。

漫画

読んだ漫画をあげ始めればキリがないんですが、印象に残っているものを紹介だけしておきます。

アオアシ

もともと大学で体育会に所属していたときから、モチベーションを上げるためにスポ魂漫画を利用してきました。 たぶん、ハイキュー!!とかが好きな人はハマるんじゃないかなと思います。 青とかブルーとかが付く漫画が多いな〜と思って避けていたんですが、大好きなやつでした。

今日のさんぽんた

女の子と柴犬、ポン太との散歩の一幕を1話完結で描いている漫画です。 ちょっとアホな飼い主の言動にポン太が心の中で突っ込むことで話が展開するんですが、なにも考えずに読めるのですごく良かったです。 関西弁なのがかなりポイント高かったです。

日本三國

まだ3巻しか出ていないんですが面白かったです。 近未来、文明が崩壊した後戦国時代になった日本で、三国志みたいな物語が展開します。 ちょっとグロ描写あるのでそこだけが注意ポイントでした。

その他

• 銀の匙
• SPY×FAMILY
• サマータイムレンダ
• 推しの子
• 数字であそぼ。

あたりを新規に読みました。

電子書籍をiPhoneで聴くようにしたら読書への苦手意識が和らいだ

*1

読書の秋ですね。

書籍を読む行為は、自分のペースで読み進めることができるという点が良い反面、ページ送りをするという行為が必須であるため、「ながら」ができないのがイマイチだなと感じることも多いです。

昨今ではaudible など、耳で本を聴くという体験も広がっているように思います。読み上げられた本を聴くならば、精読をしたいのか、拾い読みをしたいのかに関わらず一定のスピードで読み進めてくれ、ページ送りも不要なので「ながら」読みが可能になります。

しかし、そういったサービスでは別途お金がかかったり、お目当ての本がなかったりというので、少し残念だなと感じていました。

そこで本エントリでは最近僕が重宝している、iOS や iPadOS の読み上げの機能を紹介します。

各OSのアクセシビリティの機能として存在する画面上の文字の読み上げを流用し、Kindle や ブックアプリの電子書籍を機械に読み上げさせ、聴く読書に使おうというものです。

利用方法

準備は簡単です。新規にアプリをインストールする必要はありません。

設定アプリを開き「アクセシビリティ > 読み上げコンテンツ」と進み、以下の画像のようにします。 *2

• 「画面の読み上げ」のトグルを有効にする
• 「読み上げコントローラ」をオンにする

すると、画面の端に 「>」のようなマークが現れ、タップすると画像のようなコントロールキーが現れます。

その後、少し説明が難しいですが、以下の gif のように手のマークをタップしてから画面上からスワイプすることで、そのページの読み上げがスタートします。

実は紹介する以前からこの機能は存在していたのですが、僕の旧端末の iPhone SE2 ではスペックの問題なのか、読み上げが止まるなどあまり思うように動いてくれず、今回 iPhone 13 mini と 第3世代の iPad Proで動作が確認できたため、紹介しようと思いました。

使ってみて

僕は精読が苦手で、理解のために何度も同じ場所を読み返して進行が遅くなってしまい、結果飽きてせっかく買った書籍も途中で離脱してしまうことが多いのが悩みでした。

逆にスピードを上げてとりあえず浅くでも読み終えることを優先する方法を試そうとしたこともありましたが、なかなかよいバランスがわからず結局時間がかかってしまっていました。

この読み上げ機能を利用し始めてからは、「ながら」でもとりあえず本を最後まで流すことができ、この本は大体こういうことを言っている、というインデックスを貼ることが可能になりました。聴き流した後で気になる場合は後でもう一度読めばよく、その時は初めて精読するときよりもスムーズに読み進められている感覚がありました。

家事をしながら、日々の買い物をしながら、散歩・ランニングしながら聴くことができ、読書の量が以前より増えたように思います。

プログラムコードがたくさん存在するような書籍では利用できませんが、そういう書籍はむしろ写経するので、読み上げの対象にならない、という整理をしています。

一方でこの機能はあくまでアクセシビリティのためのものですので、聴く読書としての使い勝手がこなれているとはいえません。

具体的には以下の部分が微妙ポイントです。

• スワイプの操作、再生の操作に多少の慣れがいる
• 読み上げ中にKindle や ブックアプリを離れたり、画面がロックされるとページの境界で読み上げがストップする
• 漢字などの読みが不正確な時がある*3
• 埋め込まれているリンクも読み上げてしまうので、目次や章末の参考文献を聴くのが辛い
• Kindle の固定レイアウトのものや、PDFの本は読み上げを利用することができない
• 図表などは読み上げられない（これは読み上げ機能だけの問題ではなく、聴く読書の問題だと思います）

ということで、もちろん 本を聴くという体験としては audible などにお目当ての書籍がある場合はそちらを利用するほうが良いのだろうな、と思います。

まとめ

メリデメありますが、読書について僕と同様の課題がある方はぜひ試してみてください。

なんかうまくいかないよ、もっとこういう良い方法があるよ、とかがあれば是非コメントまたはTwitter にて教えてほしいです！

これで読んだ本の感想もブログに書いていきたいです。

*1:もちろん聴くのは電子書籍です

*2:僕は全ての端末をダークモードで利用しているので、背景色・文字色などはお手元の環境と異なっている可能性があります。

*3:漢字の読みは登録できたりします。が、なんとなく想像できる範囲なので、僕はあまりつかっていません

2021年の振り返り

2021年振り返りです。雑多に。

本業

タスクのデリゲーション

去年の振り返りブログにも書いたんですが、昨年マネージャー職になって今年の頭はプレイイングしていた業務のデリゲーションを求められていました。

去年からもペア・モブで作業したり、議事録やメモを多めに残したりしてましたが、なかなか情報を渡しきること、任せきることが難しかったです。

今年途中から僕のチームでモバイルアプリ開発が始まったことにより一気にデリゲーションが進んだように思います。

studist.tech

既存の画面をアプリストアからインストールできるようにする、というように要求が明確であったということと、僕自身が詳しくない領域であったことから、調査なども含めて任せる部分がわかりやすかったのが良かったかなと思いました。

一方でプロジェクトの進め方、スケジューリングについても一気に任せようとしてしまい、メンバーに負荷をかけすぎてしまったのは反省が必要なポイントでした。

プロダクトマネジメント業

EMの傍らプロダクトマネジメントのようなことも引き続きやってました。

studist.tech

会社のブログでも言及しましたが、「可能な限り作りすぎない」というのを基本スタンスとして、各所からの機能要望について対処してきました。

不信感を持たれないように、やることになった開発プロジェクトのスケジュールについては意識していました。しかしそれでも「Noというのではなく、対案を出してほしい」と言われたことがありました。対案を出すと結局なにか作ってしまうことになるので避けたかった僕は、backlogを用意して個別のやりたくないことではなく全体像に話を向ける、ようにしました。時間がすぎると優先順位も変わって不要な機能となることも多く、チケットをクローズできると清々しい気持ちになるのでちょうどよい塩梅の対応だったかなと思います。

bizメンバーとよりガッツリ関わるようになった

仕事のデリゲーションができてきたことにより、事業のbizメンバーとの1on1を隔週で実施したり、biz定例に参加し始めました。僕は開発部で、事業部のメンバーとはレポートライン上にもいなかったり、定例では開発の自分がはいる必要がない話題も多いですが、これによって体感かなり話やすくなりしました。また、事業部のOKRを考えることにも積極的に参加でき、結果事業KPIの決定にも入っていきやすくなりました。KPIが定まっていけば開発要望についてのやるやらの議論もやりやすくなり、backlogに入れて塩漬け、というようなある種の姑息対応をせずにすむようになりました。

インプットが足りない

ぼくの振る舞いとして、自分の経験からそれっぽく話すことに対し、よいよねと言われることが何回かありました。具体的な話になるのでわかりやすくてよい、ということなのかなと思うんですが、それに甘んじてインプットが少なすぎたな、と感じることが増えてきました。会社の周りの方々は本などからインプットしたことを利用して考えを整理されているのがすごくうまいなと思ったのがきっかけでした。来年は技術についても、マネジメント系についてもインプットにあてる時間を意識的にとっていきたいと思っています。

副業

coralcap.co

今年は友人のhkdnetから紹介してもらった Fanfare さんで副業を行っていました。基本的にRuby on Railsのコードを書いています。 去年の振り返りブログでは、本業で得られない技術的興味を満たすことをモチベーションとして書いていました。 しかし、今は友人であり尊敬するエンジニアであるhkdnetの振る舞いを近くで見られる貴重な機会として、また、本業のサービスの少し前をいくVertical SaaS の CTOのかたの振る舞いを間近で見る機会として、利用できることにありがたみを感じています。

一方で、今年後半にかけて稼働が少なめでアウトプットも比較的すくなくなってしまっており、来年からは書斎も手に入るので気合を入れ直したい気持ちです。

プライベート

デスク周りを整えた

ゴールデンウィークに Flexispotさん昇降デスクの脚とKANADEMONO さんの天板を購入し、デスク周りを整えました。コロナになってから自宅で作業することが多く座り続けているのもあまり良くないなと思っていたし、ミーティングが増えていたのでミーティング中は立つか、というので買いました。

リフレッシュできるし眠くなるお昼過ぎのミーティングでも集中できるので、良い買い物でした。

僕は有線のキーボードを使っているため、線を机上にだしたくなくてスライド式のキーボードトレイを購入しました。スタンディング状態ではちょうど良かったんですが、座ったときに使い心地が悪く、使わなくなってしまいました。

今年頭にブログに書いて使い始めたErgodoxは今でもガッツリ使っています。2ヶ月くらいで完全に慣れて、これまでの速度と同じ程度のタイピングができるようになりました。US配列にも同じタイミングで慣れたので、キーボードを劇的に変えても概ね2ヶ月位あればなんとかなるというのがわかってよかったです。

住み替え

今の住まいから近場の新宿中央公園によく散歩に行きました。懐かしむ日が来るんだろう。

今のマンションの部屋を購入してから2年半と経たないんですが、住み替えることになりました。結婚して土日に一人じゃなくなり、副業もガッツリするようになり、仕事をするための部屋が欲しくなったのです。

5月頃に具体的に検討を始め、まずは夢を膨らませようということで住宅展示場にも足を運びました。人生でそういうところに行くことになるとは思ってもなかったのでなかなか面白い体験ができました。

結局前職のサービスである cowcamo を利用させてもらってまた都内の中古マンションを購入することになったんですが、今回は今の住まいの売却の話も並行してすすめたのでかなり疲弊してしましました。詳しくはどこかでまた書こうと思っています。余裕があれば。

旅行

あんまりアクティブに出歩く方ではないんですが、泊まりの国内旅行に2回行きました。ご時世もあるので近場で、秩父と葉山に行きました。

秩父（2月）

近場の温泉、という感じで、はなのやという温泉旅館に泊まりました。人生で初めて部屋に風呂がついている宿に泊まり、風呂に入っては寝、飯を食っては寝という1日目でした。

2日目に長瀞に行き、こたつ舟でライン下りをしようと思っていたんですが、ご時世と平日ということもありやってなかったのは残念でした。

けれども、宝登山神社の雰囲気がよかったのと、阿左美冷蔵のかき氷は絶品でした。

葉山（7月）

近場のリゾート、という感じで、音羽の森というホテルに泊まりました。ベランダからの長めが良かったのと、インフィニティプールというものを初めて知りました。晩ごはんに食べた地元の野菜を使ったフランス料理がおいしかったのと、ベランダでの朝ごはんもご飯もかなり気持ちよかったです。

パン作り

オーブンレンジを買い数回パンを焼きました。僕はシナモンロールが大好きなんですが、かもめ食堂のシナモンロールを作りたくてチャレンジしました。発酵などで時間はかかりますが意外と簡単で美味しいので何度か作りました。体重にはリティカルに影響するので抑えめにしたいところですが、在宅の趣味としてはおすすめです。

マイクラ

前から何度からやっていたこともあったんですが、YouTube で何人かの実況者を知ることでハマりました。

ハヤシさんの熊本城

www.youtube.com

鶴太郎さんの巨大図書館

www.youtube.com

などに憧れを持ちつつ、家を作っては壊しを繰り返しています。

ドズル社さんとかを見てmodづくりとかも面白そうだなぁと思いながらなにかできないかなぁとか考えています。

しがないラジオ

あまり更新できませんでした。

実は2人回を8月に収録し、2人の半年ごとの振り返りをメインにしつつ、ゲスト回は声をかけられたら収録する感じにゆるく続けて行こうか、という話をしたんですが、

Soundcloud ではなくAnchorに移行し、費用も抑えようというところで、手作業での移行がめちゃくちゃ大変ですべての作業が止まっています。

フェードアウトになってしまうのも悲しいので、がんばって移行を完了して何かしらの宣言を投稿しようとは思います。これからの話しはそれからちゃんとアナウンスしたいですね。

おわり

Rails 6.0 ⇒ 6.1アップグレード時にActiveModel::Errorsの仕様変更にハマったメモ

つい先週 Rails 6.0系だったアプリケーションを 6.1にアップグレードした。

6.0系で rails new しているもので、テストカバレッジもそこそこあるので、アップグレード自体は半日もかからず終わったが、ActiveModel::Errorsの仕様の変更によって修正が必要な部分があり、その原因が分かりづらかったのでメモ。

ActiveModel::Errors の変更内容

Rails ガイドの記述: https://railsguides.jp/6_1_release_notes.html#active-model-主な変更

PR: https://github.com/rails/rails/pull/32313

例えば、以下のようなモデルクラスがあるとして:

class Dog
  include ActiveModel::Validations

  validates :name, presence: true
  validates :age, numericality: { only_integer: true }, allow_nil: true

  attr_reader :name, :age

  def initialize(name: nil, age: nil)
    @name = name
    @age = age
  end
end

Rails 6.0系では:

Loading development environment (Rails 6.0.3.4)

> dog = Dog.new(age: 3)
=> #<Dog:0x0000559792f03f50 @age=3, @name=nil>
> dog.valid?
=> false
> dog.errors
=> #<ActiveModel::Errors:0x000055978faa7338
 @base=
  #<Dog:0x0000559792f03f50
   @age=3,
   @errors=#<ActiveModel::Errors:0x000055978faa7338 ...>,
   @name=nil,
   @validation_context=nil>,
 @details={:name=>[{:error=>:blank}]},
 @messages={:name=>["を入力してください"]}>
> dog.errors[:name]
=> ["を入力してください"]
> dog.errors[:age]
=> []

のように、動く。

details と messages という属性に見える通り、ハッシュのようにしてエラーの内容を持っている。

各エラーにアクセスするためには、ActiveModel::Errors のインスタンスにたいしてハッシュの値を取得するようにしてアクセスする必要があった。

Rails 6.1系では:

Loading development environment (Rails 6.1.1)
> dog = Dog.new(age: 3)
=> #<Dog:0x00007f1745a30008 @age=3, @name=nil>
> dog.valid?
=> false
> dog.errors
=> #<ActiveModel::Errors:0x00007f17459f2c58
 @base=
  #<Dog:0x00007f1745a30008
   @age=3,
   @errors=#<ActiveModel::Errors:0x00007f17459f2c58 ...>,
   @name=nil,
   @validation_context=nil>,
 @errors=[#<ActiveModel::Error attribute=name, type=blank, options={}>]>
> dog.errors.where(:name)
=> [#<ActiveModel::Error attribute=name, type=blank, options={}>]
> dog.errors.where(:name).first.message
=> "を入力してください"
> dog.errors.where(:age)
=> []
> dog.errors.messages_for(:name)
=> ["を入力してください"]
> dog.errors.messages_for(:age)
=> []

各エラーは、ActiveModel::Errorオブジェクトとして表現され、ActiveModel::Errors は その Errorオブジェクトのリストとなった。

where、messages_for を利用することによって、各エラーにアクセスすることができる。

もともとのハッシュのようなアクセスもインターフェースとしては6.1の段階では残っているが、PRによるとdeprecatedとなっているので、whereやmessages_forなどにおきかえていくのが良いと思う。

変更が必要だった点

6.0系では、[]インターフェースで各エラーにアクセスしたときに、空のエラーが追加されていた。

例えば、

Loading development environment (Rails 6.0.3.4)

> dog = Dog.new(age: 3)
=> #<Dog:0x0000559792f03f50 @age=3, @name=nil>
> dog.valid?
=> false
> dog.errors
=> #<ActiveModel::Errors:0x000055978faa7338
 @base=
  #<Dog:0x0000559792f03f50
   @age=3,
   @errors=#<ActiveModel::Errors:0x000055978faa7338 ...>,
   @name=nil,
   @validation_context=nil>,
 @details={:name=>[{:error=>:blank}]},
 @messages={:name=>["を入力してください"]}>
> dog.errors[:name]
=> ["を入力してください"]
> dog.errors[:age]
=> []
> dog.errors
=> #<ActiveModel::Errors:0x0000561e22f62890
 @base=
  #<Dog:0x0000561e22fa7c88
   @age=3,
   @errors=#<ActiveModel::Errors:0x0000561e22f62890 ...>,
   @name=nil,
   @validation_context=nil>,
 @details={:name=>[{:error=>:blank}]},
 @messages={:name=>["を入力してください"], :age=>[]}>
> dog.errors.to_json
=> "{\"name\":[\"を入力してください\"],\"age\":[]}"

一度dog.errors[:age]にアクセスすると、ageにエラーはないにも関わらず、age keyが存在する形になる。

一方で、6.1系では[]でアクセスしても、error のリストや、errors.to_jsonの結果に変更はない。

Loading development environment (Rails 6.1.1)
> dog = Dog.new(age: 3)
=> #<Dog:0x00007f1745a30008 @age=3, @name=nil>
> dog.valid?
=> false
> dog.errors
=> #<ActiveModel::Errors:0x00007f17459f2c58
 @base=
  #<Dog:0x00007f1745a30008
   @age=3,
   @errors=#<ActiveModel::Errors:0x00007f17459f2c58 ...>,
   @name=nil,
   @validation_context=nil>,
 @errors=[#<ActiveModel::Error attribute=name, type=blank, options={}>]>
> dog.errors[:name]
=> ["を入力してください"]
> dog.errors[:age]
=> []
> dog.errors
=> #<ActiveModel::Errors:0x000055f4b47046e0
 @base=
  #<Dog:0x000055f4b474d570
   @age=3,
   @errors=#<ActiveModel::Errors:0x000055f4b47046e0 ...>,
   @name=nil,
   @validation_context=nil>,
 @errors=[#<ActiveModel::Error attribute=name, type=blank, options={}>]>
> dog.errors.to_json
=> "{\"name\":[\"を入力してください\"]}"

errors を JSONとして APIレスポンスとしてまるっと返してしまっていると、APIのインターフェースが変わってしまう。

開発しているアプリケーションでは、key にたいする空配列が作成される前提のコードになっていたため、変更が求められた。

※その他に、errors[:hoge]でアクセスしていたところをmessages_for やwhereに修正するという必要もあったが、その部分では動きは変わらなかったのでたいした問題にはならなかった。

CSVのバリデーションとエラーレスポンス

ここから、僕が具体的に遭遇したケースの話を書く。

ユーザーがアップロードしたCSVを利用して、手で作るのは辛い大量のデータを作成する機能を実装するのはよくある。

そういう機能を実装するときに、フォーマットや各項目のバリデーションをするのに、AcriveModel::Validationsを利用していて、

class BaseCsv
  include ActiveModel::Validations

  attr_accessor :header, :table

  def initialize(csv_string)
    @table = ::CSV.new(csv_string, headers: true).read
    @header = ::CSV.parse(csv_string).first
  end

  #
    # 各種バリデーションロジック
    #

end

というような感じで、headerとtableに分けてバリデーションしている。

まずheaderで、各列ごとの要素や順番、列の数など、CSVの大まかな形を検証し、仕様通りのフォーマットでアップロードされたCSVかを判断し、 tableの方のロジックで、1つずつの値をバリデーションしていく。

すると、

{
    "header": [],
  "table": [
    "[2 行目] 他の メールアドレス と重複しています。",
    "[4 行目] 名前 は 20　文字以内で指定してください。",
    "[5 行目] 名前 は 191　文字以内で指定してください。",
    "[7 行目] 名前 が空です。入力してください。",
    "[8 行目] メールアドレスのフォーマットが不正です。",
    "[9 行目] 店舗名 が空です。入力してください。"
  ]
}

という形で、keyはちょっと分かりづらい感があるが、フォーマット と 各項目によってエラーを分けることができる。

フォーマットが誤っているときは、各項目が空になったり、要素がおかしかったりして、全行に渡って大量にメッセージが入ってしまうため、フォーマットをきれいに直してもらってから、中身の検証をしてあげよう、ということになっている。*1

名前,メールアドレスなCSVがほしいときに、仮に名前列しかなかった場合、

{
    "header": [
        "CSV は 2 列で指定してください。",
        "2 列目は 名前 を指定してください。"
    ],
  "table": [
    "[2 行目] 名前 が空です。入力してください。",
      "[3 行目] 名前 が空です。入力してください。",
        "[4 行目] 名前 が空です。入力してください。",
        ........
        "[2000 行目] メールアドレス が空です。入力してください。"
  ]
}

みたいなことになりかねないので、フォーマットのエラーだけを先に見て、問題なければ中身を見る、ということにしている。

csv.errors[:header].present?

というのを聞けばよいだけだが、こうすると、6.0ではheader key がerrorsに追加され、6.1では追加されなかった。

で、request spec には、header keyに空配列が入っていることを検証しようとしているのに、バージョンアップすればなくなる、といった問題だった。

結果、このプライベートAPIを利用しているフロントの実装は問題なかったので、そのままにし、RSpec を拡充してこの問題は終了した。

おわり

• ActiveModel::Errorsに []のインターフェースでアクセスしたときの挙動が変わっていることに気づくのに少し時間がかかった
• Rails 6.1移行では、messages_forや whereなどを使ってActiveModel::Error オブジェクトにアクセスしましょう

*1:CSVテンプレートをダウンロードさせてあげることでフォーマットの誤り自体はある程度防ぐことができるとはおもう