2024-04-17

技術について理解するための問い

最近、何かの技術について調べるとき、以下のような問いに答える形で調べるようにしている。

一言で言うと何か
どのような課題を解決するのか
主要な特徴は何か
どのように動くのか
代表的な選択肢は何があるか
どのような時代的背景で出てきたものか
代替・競合となるものは何か
どこ・誰が提唱・開発しているのか
どのような課題を新たにもたらすか
フィットするのはどのようなときか、しないのはどのようなときか
将来の展望や持続可能性はどうか

2023-12-29

2023年振り返り

プロジェクト1

去年の年末から夏くらいにかけて、Pulse というプロダクトの大きな機能変更を行うプロジェクトをやっていた。久しぶりにがっつりプロダクト構造の整理をするプロジェクトだった。最初の2ヶ月くらいは PdM・デザイナーと3人で、プロダクトの体験や構造を模索・整理して、それを UI に落とし込むことをやっていた。この仕事をしながら、社内でこれができるエンジニアはあまりいないなと思った。自分はプロダクト領域や多職種とのコラボレーションが得意だと再認識した。

実装フェーズに入ってからのプロジェクトマネジメントは未熟だった。 UI が固まり、仕様をまとめ、実装の方針を考えてタスクの分解を行った時点で、それ以前の段階で見立てていたよりもリリースが1.5~2ヶ月延びそうなことがわかった。この時点で、ステークホルダーと話して、このスケジュールは許容できるのか、できないとしたらスコープやリソースをどう調整するのか、といったあたりのハンドリングが素早くできているとよかった。

自分の立場としてそうした振る舞いができていたらよかったと思う一方で、ビジネス出身の事業責任者や PdM との間で、プロジェクトが進むに連れてスケジュール見積もりの精度がどう変化していくかについての理解に差があるなというのを感じた。この頃にちょうど新刊として出た『人が増えても速くならない』を読んでいい本だなと思い、ビジネス出身のメンバーにも薦めて読んでもらった。

プロダクトとテクノロ ジーを繋ぐ領域で価値を発揮する / テックリードとして振る舞う

このプロジェクトが終わった秋くらいのタイミングで、自分の成長の方向性を考えていた。 Engineering Management Triangle というやつを知って、自分は Product と Technology をつなぐ領域で価値を発揮していくのがいいと思った。自分は Product 特化でも Technology 特化でもない。Team を作るというところにも現状そこまで熱量を持てていない。自分の観測範囲での知識だが、エンジニアの中には Technology に強い人はたくさんいるが、Product と Technology の接続領域で価値を発揮できる人はあまり多くないと思った。

また、夏くらいに『エンジニアのためのマネジメントキャリアパス』を読んで、自分はチームのテックリードだと意識して振る舞うことを始めた。（なお Wantedly の開発組織には「テックリード」という名前のロールがあるが、これは組織内である技術分野をリードするロールのことで、この本で言う「テックリード」とはけっこう別物）

このあたりの話を踏まえて、以下のような価値の発揮のしかたをしていこうと思った。

事業責任者やPdMと連携し、顧客の課題を特定し、施策の優先度づけをする
技術的な側面から事業成長のために解決すべき課題を特定・提言し、チームのロードマップに盛り込む
ビジネス的なやりたいことに対して最適な How を提示し実現する
開発チームによるソフトウェアデリバリーのプロセス (要件整理 / 設計 / 実装 / テスト / リリース) をリードする
適切な技術的負債の解消によってソフトウェアの持続性を担保する

できているものもあるし、できていないものもある。特に「技術的な側面から事業成長のために解決すべき課題を特定・提言し、チームのロードマップに盛り込む」「適切な技術的負債の解消によってソフトウェアの持続性を担保する」といったあたりの振る舞いはまだあまりできていなく、伸ばしたいところ。

2つのプロジェクトを並行してマネジメントする

プロジェクト1が終わった後、秋から PdM と2つのプロジェクトの立ち上げをやって、今はその2つのプロジェクトの開発を見ている。自分自身はあまり手を動かさずにプロジェクトのマネジメントとレビューを中心に行っている。

上で書いたような価値領域で、今の2倍価値を発揮できるとしたらどのような形になるかというのを考えて、複数のプロジェクトを同時にリードする、というのが一つの形になるだろうと思った。ちょうどそれにトライする機会になっている、というか半分はそれをやってみようと思って配置調整をした。

まだうまくはいっていない。自分がボトルネックになってしまうこともけっこう起きている。あとは片方のプロジェクトに脳みそを持っていかれて、もう片方のプロジェクトのことがおそろかになってしまうみたいなことも起きていた。2つを並行でマネジメントするのは難しいなと感じているが、最近自分の時間を何にどれくらいの割合で使うかを明確に意識するようになって、それによって解決のいとぐちを掴みつつある。これを乗り越えられたら一つ成長できそう。

日記をつけるようになった

5月頃からつけはじめて、それ以来続いている。いい習慣になった。Notion に毎月「日記 2023/12」みたいなページを作って、毎日箇条書きで書いていっている。箇条書きだと頑張らずに書けるのでいい。最初の頃は毎日書いてて、最近は忘れちゃう日もあるが、だいたい7~8割くらいの日は書いている。

日々忙しく過ごしていると、その日の出来事だったり感情だったりを整理しきれないまま次の日を迎えてしまう。そういう日々が続いていると、自分ではコントロールできない大きな波に飲まれ、振り回されているような感覚になる。その日あったよかったことや、感じたことなどを日記に書き留めていくと、人生のコントロールをちょっと取り戻せた気持ちになる。うまくいかなかったように思う一日であっても、何か一つでもよかったなと思うことを書き留めると、まあそんなに悪くはなかったかなという気持ちになる。もやもやすることがあってもそれを書き出すと、一回気持ちがすっきりして、ちょっと冷静になって物事と向き合える。こんな感じでその日その日に一区切りをつけて、ちょっと落ち着いた気持ちで次の日を迎えられるようになった。

投資を始めた

今年の目標の一つであった投資を始めた。これまでお金に関することはちょっと毛嫌いしていて、ちゃんと考えてこなかったのだけど、30歳になったのでいい加減ちゃんとしたいなと思って、思い腰を上げて勉強を始めた。YouTube でリベ大というチャンネルの動画を見て基礎知識を学んだ。最初から本を読むのはやる気が湧かなかったので、動画で知識が得られるのはありがたかった。

NISA枠で毎月インデックス・ファンドを積み立てるようにした。株価を追って細かく売買するみたいのは性格的に向いていないので、自動で積み立てられるくらいの距離感がちょうどいい。始めたタイミングがよかったのもあって、初年度からいくらか含み益が出ていて嬉しい。今まで投資とかをしてこなかったのもあって貯金に少し余裕があるので、来年からは新NISAで投資比率を上げていく予定。

引越した。同棲を始めた

夏前に同棲しようかという話をして、8月から本格的に動き始めて、11月頭に引っ越した。場所は小田急線のちょっと奥の方。お互い在宅で仕事することがあるので、ミーティングの声が干渉しない 2LDK の間取りにした。最初は通勤しやすさを考えて、東横線や目黒線、大井町線あたりを探していたが、2LDKは物件が少なくて、いいと思うところがなかなか見つからなかった。不動産屋さんにちょっとエリア変えて小田急線のこのあたりとかどうですかと紹介してもらって、土地勘なかったけど町の雰囲気見に行ったら気に入ったので、そこに決めた。

町自体も家の周りも静かだし、家は広くてきれいで、家賃はちょっと高かったけどとても満足している。通勤は1時間強かかるようになり大変になったが、週2日くらいなら許容。通勤の時間は記事を読んだりできて、それはそれでいい時間になっている。

本格的に動き始めてからの3ヶ月くらいはやることが多くて、勉強とかがあまりできなくなるくらい忙しかった。当分は引越はいい。

同棲は楽しい。誰かと一緒に暮らすのはもうちょっとストレスも感じるかと思ったけど、意外と感じていない。家が広くて、籠もれる個室があるのも大きい気がする。あとは寝る時間や起きる時間など生活リズムが近かったのもありそう。休みの日もずっと一緒に何かして過ごすわけではなく、適度にお互い自由に過ごす時間を取るようにしている。なので自由に過ごせる時間が減ったという感覚はあまりない。近くに飲食店や惣菜屋さんが少ないので、自炊することが増えた。買い出しの量が多くて大変なので、ネットスーパーを使うようにした。Amazon みたいにポチポチ注文して翌日指定した時間に届けてくれるのでとても便利。

今年買ってよかったもの

デスク配線トレー

引越を機にデスク配線周りをきれいにしたいと思って、Melius Design メッシュケーブルトレーというやつを買った。電源タップや配線を床に置かなくて済むのと、見た目的にも死角に隠れてくれてすっきりするので気に入っている。

キーボード

キーボードは今まであんまりこだわりがなくて、Apple の Magic Keyboard を使っていたが、ある時期からなんかタイピングにストレスを感じ始めた。ものは試しとメカニカルキーボードを買ってみた。買ったのは NuPhy Air75 V2。スイッチはよくわからなかったので動画を見て一番タイピング音が好きだった Cowberry にした。

結論から言うととても気に入っている。タイピングスピードが体感1.5倍くらいになったのと、単純に打っていてコトコトと気持ちがいい。昔 HHKB を使ってみたけど、ストロークの深さに馴染めずにすぐ使わなくなった経験があったので、通常のプロファイルではなくロープロファイルにしてみた。これくらいのストロークが自分にはしっくり来るような気がする。細かくこだわりだすと沼が見えているので、今のところパーツの交換とかはせずに、買ってそのままの状態で使っている。

睡眠薬

自分は睡眠の質がパフォーマンスに大きく影響するタイプで、元々寝る前のルーティーンなどにはかなり気を使っていた。それでも毎日安定して質の高い睡眠が取れていたわけではなく、感覚的には70~80点くらいの日が多かった。1ヶ月に1回くらい頭が興奮して寝付けなくて、翌日虚無の日を過ごすことがあり、どうにかできないかなと思っていた。毎日コンスタントに90点以上の睡眠が取れるようになったら QoL がかなり上がるだろうなと思った。そういえば前に一緒に働いていた人が毎日睡眠薬を飲んで寝ていて快適と話していたのを思い出して、たまたま会った機会に話を聞いて、同じものを試してみることにした。

使っているのは「ネムレルくん」というサービスで、電話で医師の診察を受けて、続けて薬剤師からも電話で説明を受けて、あとは家に薬を配送してくれる。電話は2回目以降は「お変わりないですか」くらいで1~2分で終わる。1回で4週間分処方してくれるので、これを毎月繰り返す。市販のドリエルなんかと違って、依存性の低い薬を処方してくれるので、安心して飲める。はじめはちょっと怖いなと思っていたけど、実際依存症になっているという感じはなく、たぶんなくなっても生きてはいける。飲むと30分後くらいには眠気が襲ってきて、ベッドに入ると100%値落ちできる。

毎日「今日はちゃんと寝れるかな」とちょっと不安になるストレスから解放されたのはとても嬉しい。診察代と薬代で合わせて月5000円くらいとちょっと高いけど、日々のパフォーマンスが安定して睡眠のストレスからも解放されるならいいかと思って続けている。

DeepL Pro

Webページをレイアウトそのままに丸ごと翻訳できるのが便利。英語の記事とかドキュメントを読むのが捗る。Google 翻訳でも同じことができるけど、翻訳精度が DeepL の方がいい。年払いにすれば月1000円と料金が手頃なのも嬉しい。

今年仕事関係で読んでいた本

2022-12-30

2022年振り返り

課金基盤改修プロジェクトが終わった

2020年の6月からやっていた自社の課金周りのシステムの改修プロジェクトが1月に終わった。自分の役割はプロジェクトマネジメントとエンジニアリングリードで、開発は他に業務委託の方2人と進める形だった。このプロジェクトは要素として、ドメインモデリングを含む中規模の設計、データ移行を伴う無停止の基盤移行 (かつ課金周りなので品質保証の要求レベルが高い)、年単位以上の長期プロジェクトといったものがあり、自分にとってはチャレンジングな仕事だった。もちろんうまくいかないこともあったが、これを一つやりきれたというのは大きな自信になった。エンジニアとして一皮剥けることができたかなと感じた。

この仕事を通じて自分が得意だなと認識したことが二つある。一つはこうしたしっかり動く必要のあるシステムを慎重に堅実に作ること (SoR)。もう一つはステークホルダーとコミュニケーションを取ってすりあわせながら物事を進めていくこと。社内にも、もちろん社外にも、優れたエンジニアがたくさんいる中で、自分のエンジニアとしての強みを自覚できたのはよかったと思う。

あとはこの仕事について会社のブログを出せてよかった (執筆にはだいぶ苦労したけれど)。今まで仕事でこれという成果を出してアウトプットするということができていなかったので、やっとそれができたのが嬉しかった。

www.wantedly.com

プロダクト開発チームに戻った

2月からはプロダクト開発チームに戻った。課金基盤改修プロジェクトをやる前は会社のメインの事業である Visit の開発チームにずっといたが、今回は自分の希望もあって、正式リリースから半年くらいの Engagement という新規事業の開発チームに移った。

これまではエンジニア出身の PdM としか仕事したことがなかったが、初めてビジネス出身の事業責任者/PdM と仕事をすることになり、そのやり方を新鮮に見ていた。数値分析を軸に、失注原因などセールスから来るインサイトも織り込んで、現状の把握と注力すべきポイントをずばずば決めていくスタイルが特にそうだった。また課題に対する打ち手も、ビジネス的な打ち手と開発的な打ち手を、それぞれの有効性をうまくとらえて、バランスよく考えているなと思ってとても感心して見ていた。

自分の役割としては、ガリガリコードを書くというよりは、開発のマネジメントや設計・コードのレビューの比重が大きかった。後述する Chapter の仕事含め何かとサイドタスクが多く、まとまった時間が取りづらいため、クリティカルパスにあるタスクや、クイックに出したい施策の実装などはあまり持たずに、不具合対応だったり、次に取り組むプロジェクトの下準備だったりと、多少遅れてもいいような仕事をやるようにしていた。

あとは2年ぶりにモダンなフロントエンドのコードに触れるようになったが、フロントエンド難しいなと思っていた。特に React の hooks がふんだんに駆使されたコードを見て、これってコンポーネントのライフサイクルを通じてどこでどういうふうに動くんだ？というのがよくわからないなと思っていた。チーム内のフロントエンドが得意なメンバーの書いたコードをレビューしながら、よさそう...だけどこれは自分では書けないな...と思いながら読んでいた。

Backend Chapter のリードの仕事を始めた

これまた課金基盤改修プロジェクトが終わるのとだいたい同時期から Backend Chapter のリードをするようになった。Wantedly の開発組織は事業的なミッションに基づく縦軸の Squad と、共通の専門領域に関して連携を行う横軸の Chapter というもので構成されていて、各人は1つの Squad にメインの籍を置きながら、任意の数の Chapter にも参加する形になっている (ref)。とはいっても自分がリードをするようになった時点で、Backend Chapter はバックログが管理されているくらいであまり活動といった活動はしておらず、まずは Chapter として動き出すところからやる感じだった。

自分がやっていたこととしては以下のようなものなど。

バックエンド領域が現状抱える課題の整理と、その中から優先して取り組むものの選択と担当のアサイン
new joiner のキャッチアップを容易にするためのドキュメントの拡充
数年前に切り出したマイクロサービスの再統合判断
バックエンド領域に存在するサービス群の棚卸しとそれぞれのメンテナンス方針の整理 (WIP)
Rails アップグレードのリード
Chapter 間 sync-up や、SRE会、セキュリティリスク共有会などの各種ミーティングに出て、そこで出たアクションを持ち帰って Chapter 内でディスパッチ
インフラ系コンポーネントのアップグレードのためのアプリケーション側の連携窓口

こうやって羅列するとけっこういろいろなことをやっていたように見えるが、正直言うとあまり十分な成果は出せなかったかなと感じている。Chapter リードとして成果を出す上で、自身の課題が主に二つあるかなと感じている。

一つは課題を見つける力。夏に何人かのメンバーと一緒に領域の課題の整理を行ったが、深さの面でも広さの面でも質がまだまだだなと思う。もっと力のある人が見たら自分が見えていない課題を見出すだろうなと思う。課題を見つける力にしろ、それを解決する力にしろ、個としてのエンジニアリング力がボトルネックだなと感じていて、今年はインプットのウェイトもそこにかなり寄せるようにしていた。

もう一つは時間の使い方。Squad の活動やその他のサイドタスクとの兼ね合いで、あまりまとまった時間を割けなかったなというのと、内容としても割と受動的なタスクの処理に追われて、緊急度は低いが重要度の高い課題にプロアクティブに取り組むことがあまりできなかった。こうした低緊急度・高重要度な課題への取り組みを、Squad の活動と並行して片手間的な感じでやろうとしても思考が細切れになるし時間がかかりすぎるしで、（少なくとも今の自分の力では）あまり成果が出ないなというのが何ヶ月かやってみてわかった。一時的に Squad の活動をもっと大胆に減らして Chapter の活動に取り組む時間を確保するみたいなことが必要だなと思う。

そんなこんなで Chapter リードとしてはまだまだ力不足を感じているけれど、このロールをするようになって視野も広がっているし、視座も高くなっているのを感じている。10年以上開発を続けていて一定のシステム規模もある会社で技術領域のリードをするというのもそんなにできる経験ではないので、それも含めて自分の成長につながっているなと思っていて、楽しめてやれている。

2年ぶりにメンタリングと評価をするようになった

9月から Squad 内の専門性の近いメンバーのメンターと評価をするようになった。課金基盤改修プロジェクトをやる前も Squad リーダーとして Squad メンバーの評価をしていたが、当時は正直メンタリングとしても何を話していいかわからないなと思ってやっていたし、評価もあまり自信がないままやっていた。

この間の数年を経て自分の経験や見てきたものの幅が広がったのと、今年に入って 1on1 をするようになった自分のメンターとキャリアラダーに関する対話を重ねてきたことで、キャリアラダーへの解像度がだいぶ上がった。そのおかげで前に比べると 1on1 でもだいぶまともなことが話せるようになったし、評価も自信を持ってできるようになってきたかなと思う。

Chapter リードの仕事は自分にとってチャレンジであるわけだが、そうした一段上の仕事にトライするには、自分が当たり前にできる仕事を他のメンバーに任せていくことで、それに取り組む時間を確保する必要がある。自分が一つ上の仕事にトライすることと、メンバーの育成はセットだなということを考えたりしていた。

技術を網羅的に学ぶ

夏くらいにメンターと「エンジニアとしての迫力をもっと上げるにはどうしたらいいか」みたいなことを 1on1 で話していて、yugui さんの技術の学び方の記事の記事を持ち出しながら、何かの技術を学ぶときは網羅的に理解することが大事だよというヒントをもらって、これがけっこう転機になったなと感じている。

とりあえず、これまで雰囲気で書いていた Ruby を網羅的に勉強してみようと思って、オライリーのプログラミング言語 Ruby を頭から全部読んでいた。これはやってみてとてもよかったなと思っていて、Ruby のコードを読み書きするときの怖さや不安、迷いみたいなものがかなりなくなったし、ライブラリのコードとかも怖れなく読めるようになった。あらゆるライブラリやフレームワークは言語の上に成り立っているわけで、自分の使っている言語に精通するというのは大事だなということを感じた。あとは一回一つの言語を網羅的に理解することで、他の言語を学ぶことの心理的ハードルがだいぶ下がったなと感じる。

Ruby の他にも何かライブラリや外部サービスを触るときなんかも、とりあえずドキュメントをザーッと目を通すみたいなことを意識してするようになり、このプロセスを踏むことで「ライブラリをちゃんと理解して正しく使う」みたいなことが前に比べてだいぶできるようになったなと感じていた。

まとめ

今年は Squad と Chapter とのリソース配分に悩みながら働いていた感じで、結果としてどちらも中途半端なアウトプットになってしまったかなという気がする。上でも書いたとおり、個としてのエンジニアリングの地力と時間の使い方が課題かなと思うので、これは来年に持ち越し。

今年はコードはそこまで書かなかったけど、「技術を網羅的に学ぶ」に書いたブレイクスルーもあって、むしろこれまで以上に技術的には成長できたように思う。コードを書かなくても技術力は伸ばせるということを体感した一年だった。

仕事関係で今年読んでいた本

今年はエンジニアとしての地固めをテーマに、ソフトスキル系よりもハードスキル系のものを多く読んでいた。

(ちょっとしか読んでないものも含む)