受託開発やSES、フリーランスでの参画そのものを否定したいわけではありません。
ただ、AIを入れたときに、情報分断や権限分断がより見えやすくなるのではないか、という話です。
はじめに
前回は、共通ルールやハーネスを配っても、AIへの頼み方までは完全には揃わないという話を書きました。
今回は、その続きとして「担当者の分け方」について考えてみます。
従来の開発では、機能ごとに担当者を割り振ることがよくありました。
たとえば、ユーザー管理、請求管理、通知機能、帳票出力のように分ける。
あるいは、画面、API、バッチ、テストのように分ける。
これは、人間だけで開発していた時代には、ある程度自然な分担だったと思います。
しかし、AIエージェントを使う場合、この分け方が少し難しくなっているのではないかと感じています。
AIは、本来であればシステム全体を横断して考えることができます。
仕様の矛盾、データのつながり、状態遷移、画面とAPIの関係などを広く見られます。
それなのに、作業を細かい機能単位に切りすぎると、AIも担当者ごとの小さな箱の中で使われてしまいます。
この記事では、AI時代に機能ごとに人を割り振ることの難しさについて考えてみます。
機能ごとに人を分けるのは分かりやすい
まず、機能ごとに担当者を分けること自体は、とても分かりやすいです。
たとえば、次のような分け方です。
Aさん：ユーザー管理
Bさん：請求管理
Cさん：通知機能
Dさん：帳票出力
誰が何を担当しているかが見えやすいです。
進捗も管理しやすいです。
タスクも切りやすいです。
受託開発やSESの現場では、作業を分解して人に割り当てる場面が多いため、この分け方になりやすいのも理解できます。
人を追加するときも、「この機能をお願いします」と渡しやすいです。
なので、この分け方が間違っているとまでは思いません。
ただ、AIを使う場合は、この分かりやすさが逆に危うくなる場面があるように思います。
AIは横断的に考えられる
AIの強みの一つは、広い範囲を読んで、関係を整理できることです。
たとえば、次のようなことを考えられます。
- この画面項目はDBのどのカラムに対応しているか
- この状態はどこで変更されるか
- APIと画面の項目名がずれていないか
- バッチ処理と画面操作で同じデータを更新していないか
- 通知条件と業務ステータスが矛盾していないか
- 帳票に出す値と画面に表示する値が一致しているか
人間がすべてを追うのは大変です。
AIに既存コードや仕様を読ませると、こうした横断的な確認を手伝ってくれます。
ここは、AIのかなり大きな価値だと思います。
しかし、担当者ごとにAIを閉じ込めてしまうと、この強みが出にくくなります。
ユーザー管理の担当者は、ユーザー管理の範囲だけでAIを使う。
請求管理の担当者は、請求管理の範囲だけでAIを使う。
通知担当者は、通知機能の範囲だけでAIを使う。
すると、各AIはそれぞれの担当範囲ではよく考えます。
ただ、全体としての整合性は見えにくくなります。
各担当者のAIが局所最適する
AIは、与えられた文脈の中で良さそうな答えを出します。
そのため、担当範囲が狭いと、その範囲の中で最適化しようとします。
たとえば、ユーザー管理担当のAIは、ユーザー管理画面を自然にするために、ユーザーのステータスを追加したくなるかもしれません。
一方で、請求管理担当のAIは、請求状態を管理するために、似たようなステータスを請求側に持たせたくなるかもしれません。
それぞれの担当範囲だけを見ると、どちらも自然に見えることがあります。
しかし、システム全体で見ると、似た意味の状態が複数箇所に分かれてしまうかもしれません。
どちらが正なのか分からなくなるかもしれません。
更新タイミングがずれて、後から不整合が出るかもしれません。
これは、AIが悪いというより、AIに渡している文脈が分断されていることが原因だと思います。
各担当者のAIは、それぞれの箱の中では真面目に考えています。
しかし、箱同士の関係が曖昧だと、全体では少しずつずれていきます。
コンフリクトはコードだけではない
AIを使うとコンフリクトが増える、という話はよくあります。
もちろん、Git上のコンフリクトもあります。
同じファイルを複数人がAIで変更すれば、マージ時に衝突しやすくなります。
ただ、それ以上に難しいのは、設計や前提のコンフリクトです。
たとえば、次のようなものです。
- このデータはどの機能が正として持つのか
- この状態遷移はどこで管理するのか
- このバリデーションは画面側かAPI側か
- この例外処理は共通化するのか個別に持つのか
- この通知は業務イベントなのか画面操作の副作用なのか
これらは、単純にマージツールで解決できる問題ではありません。
担当者同士の前提が違っていると、コードは動いても、システム全体として不自然になります。
AI時代のコンフリクトは、行単位の衝突だけではなく、前提の衝突として出てくるのだと思います。
細かい部品単位の分担は特に難しい
特に難しいと感じるのは、細かい部品単位で担当者を分けるケースです。
たとえば、次のような分担です。
Aさん：入力画面
Bさん：確認画面
Cさん：API呼び出し
Dさん：バリデーション
Eさん：状態管理
Fさん：テスト
人間だけでも調整が大変ですが、AIを使うとさらにズレが出やすくなります。
各担当者がそれぞれAIに依頼します。
AIは、それぞれの担当範囲に合わせて実装します。
すると、入力画面のAIは入力しやすさを優先する。
API担当のAIはAPIの都合を優先する。
状態管理担当のAIは状態の一貫性を優先する。
テスト担当のAIはテストしやすい構造を優先する。
どれも悪いことではありません。
しかし、全体の前提が揃っていないと、それぞれの正しさがぶつかります。
業務フロー単位で見る
AIを使うなら、もう少し大きな単位で担当を持つのもありだと思います。
たとえば、機能の部品ではなく、業務フロー単位で見る。
Aさん：申請の作成から承認依頼まで
Bさん：承認、差し戻し、再申請の流れ
Cさん：請求データの登録から確定まで
Dさん：帳票出力と出力履歴
この分け方なら、担当者とAIが一つのまとまった文脈を持ちやすいです。
画面、API、DB、状態、テストをばらばらに見るのではなく、「この業務がどう流れるか」として考えられます。
AIも、業務フロー全体を読んだうえで、実装内容を考えやすくなります。
もちろん、担当範囲が大きすぎるとレビューが難しくなります。
一人に責任が寄りすぎる不安もあります。
そのため、大きくすればよいという単純な話ではありません。
ただ、AIを使う場合は、細かく切りすぎるよりも、文脈が保てる単位で切る方が合っているのではないかと感じています。
インターフェースを先に決める
大きなブロックで担当を分ける場合でも、境界は欲しくなります。
むしろ、境界を曖昧にしたまま大きく任せると、別の問題が起きます。
先に決めておきたいのは、次のようなものです。
- データの正
- 状態遷移
- APIの責務
- 画面間の受け渡し
- 共通コンポーネントの扱い
- 変更してよい範囲
- 変更してはいけない範囲
これらを決めずに担当者ごとのAIへ任せると、各ブロックがそれぞれ便利な形に変えてしまう可能性があります。
逆に、インターフェースが決まっていれば、担当者ごとのAIの使い方に多少違いがあっても、全体としては合わせやすくなります。
AI時代の分担では、「誰が何を作るか」だけでなく、「どこでつながるか」を先に決めることが効いてきそうです。
横断的に見る役割が欲しくなる
業務ブロック単位で分けたとしても、横断的に見る役割は欲しくなります。
各担当者が自分のブロックを見ているだけでは、全体の整合性は抜けることがあります。
そこで、次のような観点を持つ人が欲しくなります。
- 用語が揃っているか
- データの正が重複していないか
- 状態遷移が矛盾していないか
- 似た処理が別々に実装されていないか
- 共通化したいものと個別に持つものが分かれているか
- 業務フローとして自然か
この役割でも、AIは使えます。
各担当者の設計や差分をAIに読ませて、矛盾や重複を探してもらう。
PR前に、機能間の整合性を確認してもらう。
仕様書、画面、API、DBの項目差異を見てもらう。
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を入れても改善しにくい現場の特徴