最近チームのテックリードを拝命して、テクノロジーマネジメント領域もリードすることになりました。興味の中心は開発プロセスやデリバリーで、エンジニアリングはまだまだひよっこなので苦労の日々が続いています。この記事では新米テックリードとしての取り組みをひとつ紹介します。
私のチームでは10個近いコンポーネントのオーナーシップを持っています。それらの品質の期待度は大きく異なり、変更頻度、採用技術、システムに占める重要度といったパラメータから決定されます。この期待を見誤ると、変更頻度が極めて低いコンポーネントを頑張ってリファクタリングしたり、モダンな技術が採用され寿命の長いシステムを雑に拡張したりと、成果の小さいアクションを取ってしまいます。逆にこの期待を適切に捉えられると、チームのリソースがコスパが高いアクションに向かっていくことが期待できます。変更頻度の高いコンポーネントのCI/CDを改善し、重要なコンポーネントのリファクタリングを積極的に行う、といったムーブメントが自然に起こると理想です。また、そうした認識が揃っていることによって、レビュー等のコミュニケーションも円滑になることが予想されます。
こうした考えから、コンポーネントの品質期待度を順位づけして、チームのScrapboxに明記してみることにしました。実際に書いてみて面白かったのは、なぜその順位なのかを深掘りすることで、その一覧がそのままシステムの現状と未来を簡潔に示すドキュメントになったことです。例えば以下のような記述が並びました（実際は各コンポーネントで5行くらい書いています）。
- XXX
- YYY
- リプレイス候補だが変更頻度が高いのでリードタイムに効くところは積極的に投資する
- ZZZ
- 古代のシステムで変更が困難になりつつあり最優先でリプレイスする
- AAA
- システム上の重要度は低いので動かなくなったらそのまま止めたい
水面下で検討されているリプレイスの計画なども透明化され、チームが自律的に行動するための材料を提供することができました。チームに参加して間もないメンバーからも、なかなかこういう雰囲気を感じ取るのは難しいので助かるとポジティブなフィードバックをもらいました。アクションを整理する際の指針としても機能し、実際に変更頻度の高いコンポーネントのデプロイ時間を半分にしてやったりと、コスパの高い開発にも繋がりつつあります。
優れたソフトウェアエンジニアを目指して、やはり日常的に品質向上に取り組みたいですが、そこの踏ん張りを効かせるには「そのコードに未来があると信じられる」ことが非常に重要だと思います。3年後、5年後も誰かがメンテするなら頑張ってやろうかという気持ちが湧いてきますし、実際に効果も高いです。そこを多少は信じやすい状態にしたのが今回の施策で、チームの足場をわずかでも固められたのではないかと思います。
