「仕組みを作ったら、あとは任せる」——育児中の開発リーダーが試行錯誤した、一軍コンテキストAI駆動開発

登壇のきっかけ——Developers Summitで芽生えた「いつか登壇したい」という想い

IT Women Summitへの応募の起点となったのは、兄弟イベントであるDevelopers Summitへの参加経験だった。2〜3回ほど足を運ぶうちに、「いつか自分も登壇したい」という気持ちが積み重なっていった。ちょうどIT Women Summitの公募が始まったタイミングで思い切って応募し、審査を通過。念願のセッションに臨むこととなった。

セッションの概要

今回のセッションで山田さんが伝えたのは、大きく3つのテーマだ。

1つ目は「一軍コンテキストの設計と実践」。1日1回以上参照されるコンテキストファイルを"一軍"と定義し、AI専用のREADMEや実務特化のプロンプト、仕様書などを整備する方法を紹介した。ポイントは「一気に作らず、使う時になったら作り、徐々に育てていく」という考え方だ。

2つ目は「生成AIの品質を上げる工夫」。課題の粒度を1日以下に分割すること、チーム共通の用語集（ユビキタス言語）を案件開始時に定義すること、kiroを使ったテストファースト開発の導入など、実案件で試した具体的な手法が紹介された。

3つ目は「実際にやってしまったアンチパターン」。コンテキストを作りすぎて管理不能になった失敗や、お願いベースでのAI導入が機能しなかった経験など、現場でリアルに起きた問題とその対策を包み隠さず共有した。

セッションの核心にあったのは、「リーダーが都度教えなくても動ける状態を作ること」。仕組みを整え、AIをチームの共通言語として使いこなすことで、新しい技術に全員が挑戦できる環境を生み出した実践知だった。

原点にある「怖い経験」

今回のセッションテーマの根っこには、前職での苦い記憶がある。

「過去に、十分なナレッジ共有やレビュー体制が整っていない中で開発を進めざるを得ない環境を経験しました。『自分のコードが本当に正しいのか確証が持てないまま』プロジェクトが進行し、最終的にエラーが発生してしまって……。知識や確実な仕組みがない状態で開発を進める難しさと怖さを、そのとき痛感したんです。」

その経験があるからこそ、リーダーになったときは「とにかくコンテキスト（背景情報やドキュメント）を書き、チーム全員の品質を一定に保つ」という方針を徹底した。「新しい技術への挑戦には、安全性を担保する仕組みが絶対に必要だ」という強い想いがあったからだそうだ。

全員未経験の技術を選んだ理由

今回の案件では、あえてチームメンバー全員が初めて触れる技術を1つ組み込んだ。技術選定は山田さん自身が担当した。

「エンジニアとして、いろんな言語を触るべきだという思いがありました。もちろん突飛なものではなく、メンバーの技術スタックから逆算して『1週間ほど勉強すればキャッチアップできる』という見立ての上での選択です」

アジャイルの星取り表でメンバーのスキルを可視化し、「いける」と判断した。

「少しストレッチな挑戦でしたが、結果的にそれがちょうど良い成長の機会になりました。」

「一軍コンテキスト」とは何か

山田さんが定義する「一軍コンテキスト」とは、1日1回以上参照されるコンテキストファイル（AI専用READMEや実務特化プロンプトなど）のこと。それ以外は「二軍」として別フォルダに隔離する。

「一気に全部作ろうとしないのがポイントです。使うときになったら作り、徐々に育てていくイメージですね」

「この取り組みを始めるきっかけになったのは、社内の別チームにいる先輩エンジニアの存在でした。」

何でも文字に起こし、チーム全員が参照できるドキュメントを整備するというその先輩の仕事のスタイルに触れ、コンテキスト活用への関心を強く持つようになったそうだ。

実際の構築にあたっては、社内の生成AI勉強会で提供されたものをベースに、案件に合わせてカスタマイズしていった。

「ゼロから一人で作ったわけじゃなくて、社内の仲間から学んで、育てていった感じです。意見をもらうことで自分のアイデアも拡張されていく。一人より人と一緒に作った方が絶対いいものができると思っています。」

コンテキストの主管理は山田さんが一元的に担当した。「メンバーに心理的な負担をかけたくなかったので、作ったり消したりは私がやっていました。ただ、修正していいですよとは何度も言い続けていて。最初の2ヶ月は仕組みに慣れる期間でしたが、チーム内に浸透してからは、自発的に修正提案が上がってくるようになりました。」

コンテキスト隊長のような存在が最初は必要で、時間をかけてメンバーが育てていく環境になっていく——その感覚を、山田さんは実感として持っている。

また、ユビキタス言語を案件開始時に定義したことも、AIの出力品質を高める上で効果的だった。チーム全員が同じ単語・用語を使うことで、AIも人間も統一感のある成果物を作れるようになる。

アンチパターン①——「お願いベース」の限界

実践の中では、うまくいかなかったことも多かった。山田さんはその一つひとつを率直に話してくれた。

AI導入を検討した際、「気になる方は申請してみてください」と呼びかけたところ、誰も動かなかった。「初対面のメンバーも多く、まだ関係性が築けていない中でのテキストだけの呼びかけだったため、Slackにスタンプはついても、実際の行動にまでは繋がりにくかったです。」

ゆるく伝えると、ゆるく受け取られる。「やるかやらないか判断させてしまった」というのが反省だ。それ以降は、新しい技術の導入を「これはルールです」と明確に位置づけて進めるようにした。

「曖昧な指示を出すくらいなら、指示を出さない方がいい。やると決めたなら最初から明確に入れちゃった方がスムーズでした」

アンチパターン②——コンテキストを作りすぎた

もう一つの失敗が、コンテキストの作りすぎだ。

50個ものファイルを作った結果、「どれを見たらいいかわからない」状態が生まれた。目次を作っても目次自体が読まれない。コードとの差分をコンテキストに反映するのも手間になる。

そこで一軍ドキュメントを6ファイルに絞り、不要になったコンテキストはリーダーが責任を持って移動・削除。仕様書は実装後に参照フォルダへ隔離し、「保守しないと割り切る」ことにした。hooksで業務終了前に自動更新する仕組みも取り入れた。

AI駆動開発が変えたもの

「kiro」によるテストファースト開発の導入により、開発スピードは着実に向上した。一方で、AI活用のリアルな気づきもあった。

「技術的な正解イメージが頭にある領域では圧倒的に早くなります。一方で、まだ経験が浅く正誤判断に時間がかかる領域では、共通のコンテキストでチーム全体の目線を合わせることがいかに重要かを実感しました。」

品質面については、コンテキストが効いた。「コンテキストがあったからこそ担保できた。とんでもないコードの発生を防止できたのは、コンテキストのおかげだと思っています」

AIに任せてよいことについては「機械的な単純作業——例えば文字の変換やフォーマットの修正、誤字脱字のチェックなど」と山田さんは言う。それ以外は、グレーでいい。「AIも道具。何を人間がやって何をAIがやるか、あまり区分けしなくてもいいと思っています」

人間がやるべきことについては、明確だった。「人と人とのやりとりは人間にしかできない。AIで空いた時間を、そこに使った方がいいと思っています」

目指すリーダー像——「自分がいなくても回るチーム」

今回の取り組みは、山田さんが以前から描いていたリーダー像に向かうための「準備」だった。

「自分がいてもいなくても回るチームを作りたいというのが、ずっと思っていたことで。AI駆動開発もコンテキスト整備も、そのための一つの手段でした。考えは変わっていないけど、今回少し近づけたかなという感覚はあります」

技術がアイデンティティの根幹にあり、その拡張としてチームビルディングがある——山田さんがそう語る姿は、スペシャリストとしての自分とリーダーとしての自分を切り分けず、両方を同時に高めようとしているように見えた。

登壇後の反応と、これから

IT Women Summitでの反応は、「女性エンジニア」というくくりを超えて、具体的な実践内容への共感が大きかった。アンケートでも「具体的で良かった」という声があった。社内Slackでも「社外登壇している姿はエネルギーをもらえます」——そんな言葉が並んだ。

「女性かどうかっていうくくりよりも、具体的な内容への反応が多かったですね。そこが一番うれしかったかもしれないです」

今後については、新しい技術の勉強会を継続しながら、チームでの学びの場をさらに広げていきたいと山田さんは話す。「仕組みを作ったら、あとは任せる。それが今回のテーマでもあったし、これからもやっていきたいことです」