ID:84882さん

今後離れる必要のある、今までリードしていたAI機能開発プロジェクト

自身が離れても問題なく設計判断やコード品質の維持が行え、自走できるチームにする

# ドキュメンテーションの強化 今までの思考を引き継いでもらうため、そして今後の判断の礎にするため、今まで自身が行なってきた設計判断とその理由、テスト戦略などの全てをドキュメンテーションにまとめた。 その際、社内ではKibelaという外部SaaSのWikiにドキュメントをまとめる文化があったが、あえてリポジトリ内にmarkdownとして作成した。理由は、AIエージェントの参照性が最も高く、AIコードレビューの際のベースになることや、コードの一部としてgit管理することで、メンテナンス対象として意識してもらうため。 # 輪読会 ドキュメンテーションするだけでは参照されにくいと思い、輪読会を開催して上記ドキュメンテーションの周知に勤めた。その際、一方的に伝えるだけではなく、メンバーからのフィードバックも受けて一緒に修正するなど、当事者意識を持って参画してもらえるように努めた。 # モブプログラミングの企画と実施 AIエージェントに投げっぱなしで成長していないメンバーがいたり、上記ドキュメンテーションに示した判断の具体的な適用方法がはっきりとはつかめていないメンバーがいたため、その解決策として社内としては前例がなかったがモブプログラミングを企画し、実施した。 その際、モブプログラミングを行う理由が上記の通りであることを冒頭に説明し、積極的に技術を盗むように促した。実際にテストケースの洗い出しや費用対効果の高いテスト設計を行なったり、それをベースにしたリファクタリングの実施や、新規実装の際のモジュール設計など多くの実装をモブプログラミングで行なった。 適宜振り返りも行い、メンバーの負担の少ない進め方を模索した。 例えば、「知らないことを黙々と調べたいフェーズがあるが、ライブコーディング中は考えるのに必死でできない」といった意見から、ドライバー交代の間に5分間の自由時間を設け、それぞれが気になっていることを調査したり、手元でコードを動かしたりする時間を確保した。 また、いきなり実装するとなると難しいという意見から、前日のうちに翌日の実装箇所を周知しておき、当日の最初の段階で大まかな実装計画を擦り合わせるなどの負担軽減を実施した。 # 設計業務の段階的な委譲 朝会や仕様検討のタイミングなど、発言が必要になる場面があるが、自分がリードして喋っているままではどうしても他メンバーは自分に任せがちになってしまうと感じ、「自分は◯◯かなと思うけど、◯◯さんから見て気になる所はない？」といったように思考と発言を徐々に求めるようにしたり、インフラを含めた設計判断が必要な難易度の高いタスクについても「挑戦してみてほしい」とタスクを委譲するようにした。 その際、投げっぱなしにするのではなく、「◯◯までできたら一回一緒に確認しましょう」といったように適切なタイミングでフォローしながら徐々に自身の担っていた業務を委譲できるよう努めた。