受託開発やSES、フリーランスでの参画そのものを否定したいわけではありません。
ただ、AIを入れたときに、情報分断や権限分断がより見えやすくなるのではないか、という話です。

はじめに

前回は、AI時代には機能ごとに人を割り振るだけでは難しくなるのではないか、という話を書きました。

今回は、仕事を出す側の話です。

AIを使った開発の話では、どうしても開発者側の使い方に注目が集まりがちです。

どのAIツールを使うか。
どうプロンプトを書くか。
どこまでAIに任せるか。
レビューをどうするか。

もちろん、それらは大事です。

ただ、受託開発やSESの現場では、受ける側だけがAIをうまく使っても限界があると感じています。

なぜなら、AIが判断するための前提は、仕事を出す側から渡される情報に大きく依存するからです。

仕事を出す側が背景や判断基準を渡せないまま、「この機能を作ってください」と依頼しても、AIは本当の意味では判断できません。

この記事では、AI時代に仕事を出す側が何を渡したくなるのかを考えてみます。

仕様書がないこともある

開発では、仕様書が渡されることがあります。

画面一覧、項目定義、API仕様、DB定義、処理フローなどです。

これらはもちろん大事です。
仕様がなければ実装できません。

ただ、現場では、そもそも仕様書が十分にないこともあります。

きれいな仕様書があるというより、口頭で説明される。
チャットで断片的に共有される。
会議の中で「さっき言った通りで」と進む。
古いExcelや過去の画面を見ながら、なんとなく理解する。

こういう進み方も少なくないと思います。

この場合、問題は「仕様だけでは足りない」以前に、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時代の依頼では、「作るもの」だけでなく「判断基準」も渡しておくと進めやすいと感じています。

たとえば、単に次のように依頼するのではなく、

ユーザー一覧画面に検索条件を追加してください。

次のように判断基準も添える。

ユーザー一覧画面に部署検索を追加してください。

この画面は管理者が日常的に使うため、操作速度を優先します。
検索条件は増えすぎると使いづらくなるので、初期表示では主要条件だけを出してください。
部署マスタは頻繁に変わるため、固定値ではなくAPIから取得してください。
今回は一覧表示の性能を優先し、詳細な権限制御は別タスクで扱います。

ここまであると、AIは実装だけでなく、設計上の判断もしやすくなります。

何を優先するのか。
何を今回はやらないのか。
どこを将来の変更に残すのか。

こうした判断基準がないと、AIは一般的に良さそうな実装を出します。
しかし、その現場にとって良い実装かは分かりません。

「未決事項」を明示する

仕事を出す側が、すべてを最初から決められるわけではありません。

未決事項があるのは自然です。

意識したいのは、未決事項を未決事項として渡すことだと思います。

たとえば、次のように書く。

未決事項：
- 承認後の修正を許可するかは未決
- 管理者の権限範囲は確認中
- 帳票に出す項目は経理部門に確認中
- 外部連携のエラー時運用は未確定

こう書かれていれば、AIも「ここは確定していない」と認識しやすくなります。

逆に、未決事項が隠れていると、AIは仮の前提で実装を進めてしまうことがあります。

仮実装になる場合もあります。
ただ、その場合でも「これは仮です」と分かるようにしておくと安心です。

AI時代には、確定していることだけでなく、確定していないことを明示することも大事になりそうです。

発注側にもAIリテラシーが効いてくる

AIを使う開発では、開発者だけがAIに詳しければよいわけではないと思います。

仕事を出す側にも、ある程度のAIリテラシーが効いてきます。

ここで言うAIリテラシーは、プロンプトを上手に書けることだけではありません。

AIが何を知らないのか。
AIに何を渡すと判断しやすいのか。
どの情報が落ちると危ないのか。
AIがもっともらしく補完してしまうことがあるのか。

こうした感覚です。

発注側や上流側がこの感覚を持っていると、依頼の出し方が変わります。

「この機能を作ってください」だけではなく、「背景はこうです」「判断基準はこうです」「未決事項はここです」と渡せるようになります。

これは、AI時代の受託開発ではかなり大きい気がしています。

おわりに

AIを使った開発では、受ける側の使い方が注目されがちです。

しかし、AIが判断するための前提は、仕事を出す側から渡される情報に大きく依存します。

仕様だけでは足りないことがあります。
背景、目的、制約、判断基準、未決事項が欲しくなることがあります。

仕事を出す側がそれらを渡せないまま、受ける側だけがAIを使っても、うまくいかない場面は残ると思います。

AIは、伝えられていない背景を勝手に正しく理解するわけではありません。
不足した情報を自然に補完することはありますが、その補完が正しいとは限りません。

だからこそ、AI時代には、仕事を出す側の情報の渡し方も変えていくことになるのだと思います。

「何を作るか」だけでなく、「なぜ作るか」を渡す。
「どう動くか」だけでなく、「何を優先するか」を渡す。
「決まったこと」だけでなく、「まだ決まっていないこと」を渡す。

AIをうまく使うためには、受ける側のプロンプト力だけでなく、出す側の前提共有力も問われると思います。

シリーズ構成