受託開発やSES、フリーランスでの参画そのものを否定したいわけではありません。
ただ、AIを入れたときに、情報分断や権限分断がより見えやすくなるのではないか、という話です。
はじめに
前回は、仕事を出す側が背景を渡せないと、AIも判断しづらいという話を書きました。
今回は、もう一つ難しい問題について考えてみます。
それは、判断権限の問題です。
AIを使っていると、かなり良い改善案が出ることがあります。
この設計は分けた方がよさそう。
この責務は別の層に移せそう。
この共通処理は今のままだと危ない。
この仕様は他の機能と矛盾している。
こうした案は、実際に役立つことがあります。
しかし、現場の担当者にその判断権限がない場合、AIが出した案をそのまま活かすのは難しいです。
特に、SESや多重下請けの現場では、コードを書く人と、設計を決める人と、仕様を決める人が分かれていることがあります。
その状態でAIを使うと、問題には気づけるのに直せない、という状況が起きます。
この記事では、AI時代における判断権限と責任の分断について考えてみます。
AIは問題を見つけることがある
AIは、既存コードや仕様を読ませると、問題点を指摘してくれることがあります。
たとえば、次のような指摘です。
- 同じ意味の状態が複数箇所にある
- APIの責務が曖昧になっている
- 画面側に業務ロジックが寄りすぎている
- 例外処理の方針が画面ごとに違う
- 共通コンポーネントが特定画面に依存している
- 仕様とテストの前提がずれている
これらは、開発者にとってかなり助かる指摘です。
人間だけでは見落としていた設計の違和感に気づけることがあります。
ただ、問題を見つけられることと、それを直せることは別です。
AIが「こう直せそうです」と出してくれても、その変更を実行できるとは限りません。
現場担当者には変えられないことがある
現場の開発者がAIの改善案を見て、「たしかにその通りだ」と思うことがあります。
しかし、実際には変えられないことがあります。
たとえば、次のようなものです。
- DB設計
- API仕様
- 業務フロー
- 画面遷移
- 共通部品の責務
- 外部連携の方式
- リリース範囲
- 契約上の作業範囲
これらは、担当者が勝手に変えられないことが多いです。
たとえAIが良い案を出しても、設計変更には承認が要ります。
お客さんへの確認が要ります。
別チームとの調整が要ります。
スケジュールの見直しも出てきます。
そうなると、現場担当者だけでは動かせません。
AIは案を出してくれます。
しかし、それを採用するための権限や調整経路がなければ、実装には反映しにくいです。
責任はあるが、権限がない
SESや多重下請けの現場で難しいのは、責任と権限がずれやすいことです。
現場の開発者は、実装結果には責任を持ちます。
不具合があれば調査します。
レビューで指摘されれば直します。
納期にも追われます。
しかし、仕様や設計の根本には触れられないことがあります。
この状態でAIを使うと、少し複雑なことが起きます。
AIは、現場担当者に対して設計上の問題を指摘します。
現場担当者も、それが問題だと分かります。
しかし、変える権限がない。
結果として、問題を認識したまま、与えられた範囲でなんとか実装することになります。
これは、精神的にもかなりしんどいと思います。
AIによって問題が見えるようになった分、見なかったことにしづらくなるからです。
AIの改善案が「余計なこと」になることもある
AIの改善案は、技術的には正しいことがあります。
しかし、現場の状況によっては「今はできないこと」でもあります。
たとえば、AIが次のように言う。
この状態管理は複雑になっているため、共通のステートマシンとして整理できそうです。
技術的には良い案かもしれません。
しかし、リリース直前かもしれません。
他チームの作業と衝突するかもしれません。
今回の契約範囲外かもしれません。
お客さんに再確認する流れになりそうです。
その場合、現場担当者にとっては、良い案であってもすぐには採用できません。
AIが出す案が悪いのではありません。
ただ、それを受け止める体制がないと、現場では扱いに困ることがあります。
「案」と「実行」を分ける
AIの出した案を活かすには、案と実行を分けて扱うとよさそうです。
AIが問題を見つけたら、すぐに修正するのではなく、まず記録する。
たとえば、次のように整理します。
- 問題の内容
- 影響範囲
- 放置した場合のリスク
- 修正する場合のメリット
- 修正を判断する人
- 今回の作業範囲に含めるか
- 別タスクにするか
こうしておけば、現場担当者が勝手に大きな変更をしなくても、問題を上に渡せます。
AIの案をその場で全部実行しようとすると不安が残ります。
しかし、捨ててしまうのももったいないです。
案は案として残し、実行するかどうかは判断権限を持つ人が決める。
この流れが欲しくなりそうです。
判断者を明確にする
AIを使う前に決めておきたいことの一つが、判断者です。
たとえば、次のような判断です。
- DB設計を変えてよいか
- API仕様を変えてよいか
- 共通コンポーネントを変更してよいか
- 既存仕様と矛盾する場合、どちらを優先するか
- リファクタを今回のPRに含めるか
- 仕様の未決事項をどう扱うか
これらの判断者が分からないと、AIが問題を見つけても止まります。
担当者は判断できない。
AIは案を出す。
しかし、誰に確認すればよいか分からない。
この状態では、AIの価値がかなり下がります。
逆に、判断者が明確であれば、AIが出した案を確認事項として上げやすくなります。
AI時代には、「何を作るか」だけでなく、「誰が何を判断するか」を先に決めることが効いてくるのだと思います。
権限がないなら、変更範囲を狭める
現場担当者に大きな判断権限がない場合、AIへの依頼もそれに合わせた方が進めやすいです。
たとえば、次のように制約を明確にします。
今回の作業では、既存仕様と設計方針は変更しないでください。
問題を見つけた場合は、修正せずに確認事項として報告してください。
変更は指定された画面とテストに限定してください。
これはAIの力を抑えるように見えるかもしれません。
しかし、権限のない範囲までAIに自由に触らせると、後で困ることがあります。
AIが大きな設計変更をしてしまう。
担当者はそれを採用できない。
差分を戻すことになる。
レビューで止まる。
こうなると、AIを使った意味が薄れます。
権限が狭いなら、変更範囲も狭くする。
その代わり、問題発見や改善案の整理にはAIを使う。
この使い分けが現実的ではないかと思います。
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を入れても改善しにくい現場の特徴