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

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

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

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

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