ID:64166さん

開発チームが少ないコストで大きな成果を出せる土台をつくることに、技術的な責任を持ちたい

qnote時代に、プログラミング未経験で入社したメンバー1名の育成を、複数案件をまたいで約1年半担当していました。私自身もリード開発者として実装と納期を抱えていたため、教えた時間はそのまま自分のアウトプットから引かれます。それでも判断の理由まで毎回説明することを省かなかったのは、結論だけを渡すと、私がいなくなった時点で本人の成長が止まると考えたからです。このメンバーは私の退職後も在籍を続け、現在は私の後任としてリード開発者を務めています。自分が書いたコードよりも、自分が残した判断の基準の方が長く効いた、という経験でした。 ここから、自分の出力を上げることよりも、チームの出力の上限を上げることの方に手応えを感じるようになりました。直近のECプラットフォームのフロントエンドでも、レビューで繰り返し出る指摘は指摘のままにせず、規約・参照実装・自動チェックのいずれかに変換することを自分のルールにしていました。同時に、チェックを増やすだけでは開発が重くなり「急いでいるから飛ばす」が起きるため、モノレポ化やビルドの高速化といった開発体験側の改善をセットで進めています。コストを下げながら成果を大きくする、という点にこそ技術的な工夫の余地があると考えています。 一方で、この進め方には自分でも未検証な部分があります。ADRやユビキタス言語、深いモジュール設計といった設計手法は、個人開発やゼロから立ち上げるプロジェクトでは機能することを確認できましたが、既に何年も動き続けていて、複数人が並行して触っているコードベースに後から入れて成立するかは、まだ確かめられていません。次はそうした環境で実際に試し、その効果を自分の実感だけでなく観測できる形で回せるようになりたいです。 なお、気になった技術は自分で作って確かめないと納得できない性分で、個人開発はその判断材料をつくる場として続けています。そこでは設計判断をADRやCONTEXT.mdとして残したうえでエージェントに実装させる進め方を試していますが、結局それは人が読みやすいコードベースを整えることと同じ作業でした。判断が構造として残っている状態は、人にもAIにも効くと考えています。