受託開発やSES、フリーランスでの参画そのものを否定したいわけではありません。
ただ、AIを入れたときに、情報分断や権限分断がより見えやすくなるのではないか、という話です。
はじめに
ここまで、AIエージェントをSESや受託開発の現場で使うときの難しさについて書いてきました。
AIは便利です。
コードも書けます。
仕様整理もできます。
確認事項も出せます。
レビューも手伝えます。
それでも、AIを入れればすべての現場がすぐに良くなるとは限らないと思っています。
むしろ、AIを入れることで、もともと現場にあった問題がよりはっきり見えることがあります。
今回は、この小さな連載の締めとして、AIを入れても改善しにくい現場の特徴について考えてみます。
少し重い話になりますが、AIを否定したいわけではありません。
AIを使うなら、AIで何とかなる問題と、AIだけでは難しい問題を分けて考えた方がよさそうだ、という話です。
質問できない現場
まず厳しいのは、質問できない現場です。
仕様に疑問がある。
業務フローが曖昧。
例外ケースが分からない。
画面とAPIの前提がずれている。
AIは、こうした問題に対して確認事項を出してくれます。
しかし、その質問を誰にも投げられない場合、そこで止まります。
お客さんに直接聞けない。
元請け経由でないと聞けない。
質問しても回答が返ってこない。
返ってきても、背景のない一文だけ。
この状態では、AIがいくら良い質問を出しても、前提は解消されません。
AIは質問を作れます。
しかし、質問を通す経路までは作れません。
質問できない現場では、AIの価値がかなり制限されると思います。
判断者が分からない現場
次に厳しいのは、判断者が分からない現場です。
AIが次のような問題を見つけたとします。
- この仕様は他機能と矛盾している
- DB設計に影響がありそう
- APIの責務が曖昧
- 共通コンポーネントに影響がある
- 今回の範囲に含めるか判断が残っている
このとき、誰が判断するのか分からないと、作業が進みません。
現場担当者は決められない。
リーダーも決められない。
お客さんに確認したいが、窓口が分からない。
結局、曖昧なまま進む。
こうなると、AIの改善案は活かしにくいです。
AI時代には、判断者が分からないこと自体が大きなリスクになるのだと思います。
背景が出てこない現場
仕様はある。
タスクもある。
画面項目もある。
しかし、背景が出てこない現場も難しいです。
なぜその機能が必要なのか。
どの業務が困っているのか。
何を変えると困るのか。
過去に何で失敗したのか。
今後どう拡張したいのか。
こうした背景がないと、AIは一般的に良さそうな実装を出します。
しかし、その現場に合っているかは分かりません。
AIは、背景があるほど判断しやすくなります。
逆に、背景がないと、仕様の文字面をもとに補完します。
背景が出てこない現場では、AIが賢くなっても、判断の質は上がりにくいのではないかと思います。
権限がない現場
問題に気づいても、変えられない現場もあります。
AIが設計上の問題を見つける。
担当者もそれが問題だと分かる。
しかし、契約範囲外なので変えられない。
設計変更の権限がない。
別チームとの調整ができない。
納期が固定されている。
この状態では、AIの改善案は「正しいけれど実行できないもの」になりがちです。
もちろん、案を記録しておくことには意味があります。
将来の改善タスクにつなげられるかもしれません。
ただ、今の開発を大きく改善できるとは限りません。
AIを活かすには、出てきた案を実行できるだけの権限や調整経路が欲しくなります。
人だけ増える現場
納期が厳しいと、人を増やすことがあります。
これは従来からある進め方です。
しかし、AI時代には、人を増やせばそのまま速くなるとは限らないと思います。
AIを使う人が増えると、差分も増えます。
プロンプトの違いも増えます。
担当者ごとの前提の違いも増えます。
レビュー量も増えます。
コンフリクトも増える可能性があります。
前提が揃っていないまま人だけ増やすと、それぞれのAIがそれぞれの文脈で進んでしまいます。
結果として、作業量は増えているのに、統合が難しくなることがあります。
AI時代には、人を増やす前に、前提、境界、レビュー体制を揃えることがより効いてくると思います。
レビューできる人がいない現場
AIが書いたコードは、一見きれいに見えることがあります。
しかし、きれいに見えることと、プロジェクトに合っていることは違います。
既存設計に沿っているか。
責務の境界を壊していないか。
不要なリファクタが混ざっていないか。
テストが意味を持っているか。
業務フローに合っているか。
こうした観点でレビューできる人が欲しくなります。
レビューできる人がいない現場でAIを使うと、動くコードは増えます。
しかし、それが保守できるコードかどうかは分かりません。
AI時代には、書く人よりも、判断できる人の重みが増すのかもしれません。
AI利用が「早く作れ」の圧力になる現場
AIは開発速度を上げます。
そのため、現場によっては「AIを使えばもっと早くできるはず」という圧力が生まれるかもしれません。
しかし、AIで速くなるのは、主に実装や調査、整理の部分です。
仕様の確認。
業務の理解。
判断者との合意。
設計変更の承認。
レビュー。
リリース判断。
これらが自動で消えるわけではありません。
AIによって実装だけが速くなると、確認や判断が追いつかないことがあります。
その状態で「早く作れ」だけが強くなると、間違った前提で速く進んでしまいます。
AIを速度の道具としてだけ使うと、手戻りの速度も上がる可能性があります。
すべてAIで何とかするのは難しい
ここまでの話をまとめると、AIで何とかしやすい問題と、難しい問題があります。
AIで助けやすいのは、たとえば次のようなものです。
- 仕様の整理
- 確認事項の洗い出し
- 既存コードの調査
- 実装案の比較
- テスト観点の作成
- 差分レビュー
- ドキュメント作成
一方で、AIだけでは難しいものもあります。
- お客さんに質問できない構造
- 判断者が曖昧な体制
- 背景情報が出てこない状態
- 権限と責任の分断
- 人数追加だけで解決しようとする進め方
- レビューできる人がいない体制
これらは、ツールというより、組織や契約や開発体制の問題です。
AIはその問題を見つけることはできます。
しかし、AIだけで構造を変えることはできません。
それでもAIを使う意味はある
ここまで書くと、かなり悲観的に見えるかもしれません。
でも、AIを使う意味がないとは思っていません。
むしろ、AIは使った方がよさそうだと思っています。
ただ、期待する役割を間違えない方がよさそうだ、という話です。
AIは、現場の問題を全部解決する魔法ではありません。
しかし、問題を見える化する道具にはなります。
確認事項を出す道具になります。
前提の不足に気づく道具になります。
レビューの補助になります。
設計の違和感を言語化する相手になります。
AIを入れてすぐに現場が良くなるとは限りません。
しかし、AIによって「どこが詰まっているのか」は見えやすくなると思います。
その詰まりを、人間側が変える意思を持てるかどうか。
そこが大事だと思います。
おわりに
AIエージェントは、開発のやり方を大きく変える可能性があります。
しかし、SESや多重下請けの現場では、AIだけでは改善しにくい問題もあります。
質問できない。
判断者が分からない。
背景が出てこない。
権限がない。
人だけ増える。
レビューできる人がいない。
AI利用が早く作れという圧力になる。
こうした問題があると、AIを入れても根本的な改善は難しいです。
AIは、コードを書く速度を上げます。
仕様整理も手伝います。
問題も見つけます。
しかし、情報を渡すこと、判断すること、責任を持つこと、体制を変えることは、人間側に残ります。
AI時代になっても、開発現場の昔からの問題は消えません。
むしろ、AIによってその問題がより見えやすくなるのだと思います。
だからこそ、AIを導入するときは、ツールだけでなく、仕事の渡し方、担当の分け方、判断者、レビュー体制まで一緒に考えた方がよさそうです。
AIで何とかするのではなく、AIによって見えた問題を、人間側がどう変えていくか。
そこまで含めて、AI時代のチーム開発なのではないかと思います。
シリーズ構成
- 【AIエージェント時代のSES・受託開発を考える⑨】SESや多重下請けの現場では、AIだけでは開発はうまくならない
- 【AIエージェント時代のSES・受託開発を考える⑩】AIはヒアリングミスをどこまで救えるのか
- 【AIエージェント時代のSES・受託開発を考える⑪】共通ルールを配っても、AIの出力はなぜ揃わないのか
- 【AIエージェント時代のSES・受託開発を考える⑫】機能ごとに人を割り振ると、AIの強みが消えるのではないか
- 【AIエージェント時代のSES・受託開発を考える⑬】仕事を出す側が背景を渡せないと、AIも判断できない
- 【AIエージェント時代のSES・受託開発を考える⑭】判断権限のない現場で、AIの提案はどこまで活かせるのか
- 【AIエージェント時代のSES・受託開発を考える⑮】SES現場でAIを使う前に揃えたい前提
- 【AIエージェント時代のSES・受託開発を考える⑯】AIを入れても改善しにくい現場の特徴