受託開発やSES、フリーランスでの参画そのものを否定したいわけではありません。
ただ、AIを入れたときに、情報分断や権限分断がより見えやすくなるのではないか、という話です。
はじめに
これまで、AIエージェントを使ったチーム開発について書いてきました。
AIを使うと、コードを書く速度はかなり上がります。
代表実装やルール、CI、レビューの仕組みを整えれば、チーム開発でもある程度はうまく使えると思っています。
ただ、最近もう一つ別の問題を感じています。
それは、自社プロダクトや自社サービスの開発ではなんとか成立しそうなやり方でも、SESや多重下請けのような現場に持ち込んだ瞬間に、かなり苦しくなるということです。
これは、SESだけの話ではないと思います。
受託開発はもちろん、フリーランスとして外部からプロジェクトに関わる場合にも、似たような難しさは出てくるはずです。
AIが悪いという話ではありません。
むしろ、AIはシステム全体を見たり、仕様の抜けを探したり、設計の矛盾を見つけたりするのが得意です。
しかし、そのAIを使う現場の構造が、従来と同じままだと、AIの良さがほとんど活かされません。
この記事では、SESや多重下請けの現場でAIを使っても、なぜうまくいかないことがあるのかを考えてみます。
自社プロダクトなら、まだなんとかなる
まず、自社プロダクトや自社サービスの開発では、AIを使ったチーム開発は比較的やりやすいと思います。
理由は、情報が社内に集まりやすいからです。
たとえば、次のようなことができます。
- 仕様の背景を確認できる
- 過去の設計判断を聞ける
- プロダクト全体の優先順位を共有できる
- 変更範囲をチームで調整できる
- AIに読ませる設計資料を整備できる
- 仕様の矛盾を見つけたら、その場で相談できる
もちろん、自社開発でも問題はあります。
AIが勝手に広い範囲を直したり、PRが大きくなったり、既存設計とずれたりすることはあります。
しかし、少なくとも「なぜこの仕様なのか」「どこまで変えてよいのか」「誰に確認すればよいのか」が比較的見えやすいです。
そのため、AIを使うための仕組みを作れば、まだ改善の余地があります。
SESや多重下請けでは、前提情報が分断される
一方で、SESや多重下請けの現場では、前提情報が分断されやすいです。
お客さんがいて、元請けがいて、二次請けがいて、三次請けがいる。
その中で、機能単位や画面単位で作業が切り出される。
この構造では、開発者が持っている情報がかなり限定されます。
たとえば、次のような状態になりがちです。
- お客さんの本当の困りごとが分からない
- 仕様の背景が分からない
- なぜその設計にしたのか分からない
- 他機能との関係が分からない
- どこまで変更してよいのか分からない
- 誰が最終判断するのか分からない
この状態でAIを使っても、AIは渡された情報の範囲でしか考えられません。
AIは賢いですが、伝えられていない業務背景や、契約上見えない情報までは読めません。
つまり、情報が分断された現場では、AIも分断された前提の中で動くことになります。
ヒアリングミスは、AIではなかなか救えない
AIを使っていて感じるのは、AIは「与えられた情報の整理」は得意だということです。
仕様書を読ませれば、矛盾を探してくれます。
要件を渡せば、確認事項を出してくれます。
画面一覧やAPI一覧を渡せば、抜け漏れを指摘してくれます。
しかし、そもそものヒアリングが間違っていた場合は厳しいです。
たとえば、お客さんが本当に困っていることを聞き取れていない。
業務フローの例外パターンを確認できていない。
既存運用で暗黙的に行われている作業を拾えていない。
この状態でAIに設計や実装をさせても、AIは間違った前提の上で頑張ってしまいます。
間違った要件をもとに、きれいな設計を出す。
間違った仕様をもとに、動くコードを書く。
間違った業務理解をもとに、もっともらしいテストを書く。
これはかなり危険です。
AIを使うと、間違った前提でも作業が速く進んでしまいます。
そのため、ヒアリングミスが後から分かったときの手戻りも大きくなります。
機能ごとに人へ割り振ると、AIの強みが消える
従来の開発では、機能ごとに担当者を割り振ることがよくあります。
たとえば、次のような分担です。
- Aさんはユーザー管理
- Bさんは請求管理
- Cさんは通知機能
- Dさんは帳票出力
人間だけで開発していた時代には、この分け方はある程度自然でした。
作業を並列化しやすいですし、担当範囲も明確に見えます。
しかし、AIを使う場合、この分け方が逆に問題になることがあります。
AIは、本来であればシステム全体を横断して考えることができます。
ユーザー管理と請求管理のデータ構造の整合性。
通知機能と業務ステータスの関係。
帳票出力と画面表示の項目差異。
API、DB、画面、バッチの責務分担。
こういう横断的な観点を持てることが、AIの強みの一つです。
しかし、人間の担当を機能ごとに切ってしまうと、AIも担当者ごとの小さな箱の中で使われます。
その結果、各担当者のAIは、それぞれの機能だけを最適化します。
全体としては、設計が少しずつずれます。
そして最後に結合すると、コンフリクトや仕様不整合が出ます。
コンフリクトはコードではなく、前提のコンフリクトになる
AIを使ったチーム開発では、Gitのコンフリクトだけが問題ではありません。
もっと大きいのは、前提のコンフリクトです。
たとえば、AさんのAIは「このステータスはユーザー管理側で持つべき」と判断する。
BさんのAIは「このステータスは請求管理側で持つべき」と判断する。
どちらも、それぞれの担当機能だけを見ると自然に見えるかもしれません。
しかし、システム全体で見ると、責務が重複したり、データの正が分からなくなったりします。
これは、単なるマージコンフリクトではありません。
仕様理解、責務分担、データ設計、業務フローのコンフリクトです。
AIは各担当者の中ではそれらしく答えを出します。
しかし、担当者同士の前提が揃っていなければ、AI同士の出力も揃いません。
「仕事を出す側」が全部伝えられない問題
SESや受託開発では、仕事を出す側と受ける側の間に情報差があります。
仕事を出す側は、背景を全部知っているつもりになりがちです。
仕事を受ける側は、渡された仕様が十分だと思いがちです。
しかし実際には、かなりの情報が落ちます。
- なぜその機能が必要なのか
- どの業務が一番重要なのか
- 何を変えてはいけないのか
- どの例外ケースが現場では多いのか
- 過去に失敗した設計は何か
- 今回は何を諦めているのか
このあたりは、仕様書にきれいに書かれていないことが多いです。
そして、AIはこの落ちた情報を勝手には補えません。
むしろ、AIは不足した情報をもっともらしく補完してしまうことがあります。
その補完が当たっていればよいですが、外れていた場合は危険です。
だから、仕事を出す側が十分に伝えられない状態では、AIを使っても根本的な問題は残ります。
では、どうすればよいのか
完全な解決策は簡単ではありません。
ただ、AIを使うなら、少なくとも従来の「機能を切って人に割り振る」だけの進め方は見直した方がよいと思います。
たとえば、次のような工夫が必要になります。
- 実装前にAIで仕様の矛盾や確認事項を洗い出す
- 機能単位ではなく、業務フロー単位で設計を見る
- データの正、責務境界、状態遷移を先に決める
- 各担当者のAIに同じ前提資料を読ませる
- 変更範囲だけでなく、変更してはいけない範囲も決める
- 横断的に設計を見る役割を置く
- PR前に、機能間の整合性レビューを行う
特に重要なのは、横断的に見る役割です。
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時代のチーム開発は本当の意味では良くならないのではないかと思います。
シリーズ構成
- 【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を入れても改善しにくい現場の特徴