はじめに

弊社でも時代の流れを受け、エンジニア全員がAIを使って開発するようになりました。
一方で目の前の開発に追われ、AIの使い方を見直す時間はあまり取れておらず、まだまだ有効活用出来ているとは言い難い状況にあります。

そんな中、あるプロダクトチームが企画した生産性向上MTGに私も参加し、そこでの「AIをどう使えば生産性をさらに高められるのか」という議論は、当たり前のようで見落としていた気づきも多く、とても参考になりました。

既存プロダクトを任されているエンジニアの方々の中には、同じような境遇にいる方もいるかと思うので参考になれば幸いです。

前提：ドキュメントと開発スタイル

まずはAIをどのように活用し、どのように感じているか参加者それぞれがコメントしました。

現状ではGoogle検索の代替のような使われ方に留まっている
- そのレベルではインパクトが弱く、時間短縮を実感できず活用が進まない
不具合や動作不良の調査をよく担当するが、その場合ほとんど役に立たない
- 検討違いな提案が多く逆に時間がかかる
Viewなどの画面の実装、新規機能のバックエンド実装など「新しく作る」作業ではAIが生産性向上に貢献している。一方で、既存コードの修正や仕様変更では期待通りの提案が得られない
エラー番号などの具体的な情報がある場合は有効なこともあるが、ビジネスロジックに深く関わる修正はAIが苦手な印象

まとめると

「新機能には強く、既存コードに弱い」

という感覚が、チーム全体の共通認識でした。

議論を通じて見えてきた理由は、そこまで複雑なものではありませんでした。

AIは、

については、ある程度考慮して提案してくれます。

しかし、既存コードの修正では次のような情報が重要になります。

これらはコード上に明示されていないことが多く、AIはほとんど考慮できていません。
つまり、コードが成立している「前提知識」が足りない。という結論に至りました。

言語化する事はなくても、皆同じような事を薄々感じながら日々過ごしていたようです。
では、なぜその前提知識をAIに与えられなかったのでしょうか？

人向けに作られたドキュメントをそのままAIに取り込むには限界があり、皆そこで壁にぶつかっていました。

これまで出てきた課題感を踏まえ、当該チームでは以下の施策を実施する事になりました。

AIに読み込ませる前提知識として、Repository内に情報を蓄積する

AI用に別に用意するのではなく、点在している情報を徐々に集約（移行）していく事を考えています。

という点で、かなり相性が良さそうに感じました。

まずは早急にドキュメントの保管ルールを決めて、過去にうまくいかなかった既存バグ修正を題材にして試してみる事になりました。

これを繰り返すことで、

見えてくるはずです。

1つのバグ修正にフォーカスすれば、そこまで時間をかけずに有用性の確認とガイドライン作成もできそうです。

プロダクトにとってノウハウの俗人化は頭を悩ます問題でもあります。
今回の施策は開発メンバーの負荷軽減だけでなく、マネジメントにとってもノウハウ共有や俗人化の観点から有効な施策に感じました。

時間経過と共に徐々にAIが育ってきて、新たな戦力になってくれる事を期待したいなと思いました。

2026/5/28に博多でエンジニア向けのLT会開催します。
お食事＆ドリンクでワイワイする会です。
是非お気軽にお越しください。
https://layered.connpass.com/event/378115/