【AIエージェント時代のSES・受託開発を考える⑮】SES現場でAIを使う前に揃えたい前提

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

はじめに

ここまで、SESや多重下請けの現場でAIを使う難しさについて書いてきました。

ヒアリングミス。
共通ルールを配っても出力が揃わない問題。
機能ごとの分担による局所最適。
仕事を出す側が背景を渡せない問題。
判断権限がない現場でAIの改善案を活かしにくい問題。

少し重い話が続きました。

今回は、もう少し実践寄りに考えてみます。

SESや受託開発の現場でAIを使うなら、何を先に揃えておくとよいのか。

もちろん、現場によって事情は違います。
すべてを完璧に揃えるのは難しいです。

それでも、AIにコードを書かせる前に、最低限これだけは見えていた方が安心そうだ、というものを整理してみます。

AIに渡す前提が成果物を決める

AIは、渡された情報をもとに動きます。

既存コード。
仕様書。
ルール。
プロンプト。
直近の会話。
担当者の指示。

これらをもとに、実装方針を考えます。

つまり、AIに何を渡すかによって、出てくる成果物はかなり変わります。

前提が整理されていれば、AIは使いやすくなります。
前提が曖昧なら、AIは曖昧なまま補完します。
前提が間違っていれば、AIも間違った方向に進みます。

AI時代の開発では、コードを書く前の前提整理がかなり効いてくるのだと思います。

1. 業務フロー

まず揃えたいのは、業務フローです。

画面単位やAPI単位ではなく、業務として何がどう流れるのかを整理します。

たとえば、次のようなものです。

• 誰が申請するのか
• 誰が承認するのか
• 差し戻しはあるのか
• キャンセルはできるのか
• 承認後に修正できるのか
• 月末や締め処理で何が起きるのか
• 例外時は誰が対応するのか

AIに画面だけを見せると、画面単位で考えます。
APIだけを見せると、API単位で考えます。

しかし、業務フローを渡すと、AIはその流れに沿って設計を考えやすくなります。

SESや受託開発では、実装担当者が業務フローを十分に知らないことがあります。

その状態でAIを使うと、AIも画面やAPIの範囲でしか判断できません。

まずは、対象機能が業務の中でどこに位置づくのかを揃えたいです。

2. 用語定義

次に効いてくるのが、用語定義です。

業務システムでは、似たような言葉がたくさん出てきます。

たとえば、次のような言葉です。

• 申請
• 依頼
• 承認
• 確定
• 締め
• 登録
• 更新
• 取消
• 無効
• 削除

これらの言葉は、プロジェクトによって意味が違います。

AIは一般的な意味で補完することがあります。
しかし、業務上の意味が違えば、実装もずれます。

たとえば、「削除」が物理削除なのか、論理削除なのか。
「確定」が編集不可を意味するのか、帳票出力済みを意味するのか。
「承認」が最終承認なのか、一次承認なのか。

こうした用語の意味が揃っていないと、AIの出力も担当者ごとにずれます。

用語定義は地味ですが、AIに読ませる前提としてかなり効いてくると思います。

3. データの正

AIを使う前に、データの正を決めておきたいです。

つまり、ある情報の正しい値はどこにあるのか、ということです。

たとえば、ユーザーの所属部署はユーザーマスタが正なのか。
申請時点の部署を申請データにコピーして持つのか。
請求金額は請求テーブルが正なのか、明細の集計が正なのか。
ステータスは画面側の状態なのか、DBに保存する業務状態なのか。

ここが曖昧だと、AIはそれぞれの実装箇所で便利な形を作ってしまうことがあります。

結果として、同じ意味のデータが複数箇所に生まれます。
どれを参照すればよいのか分からなくなります。
更新タイミングによって不整合が起きます。

AIはデータ構造を作るのが得意です。
だからこそ、データの正は人間側で決めておきたいです。

4. 状態遷移

業務システムでは、状態遷移もかなり大事です。

たとえば、申請データが次のように変わるとします。

下書き -> 申請中 -> 承認済み -> 確定
              -> 差し戻し -> 再申請

この状態遷移が曖昧だと、AIは画面ごとに違う前提で実装することがあります。

ある画面では承認済みから編集できる。
別の画面では承認済みから編集できない。
APIでは差し戻しを許可している。
テストでは差し戻し後の再申請を考慮していない。

こうしたズレは、後から見つかるとかなり大変です。

AIを使うなら、状態遷移図や状態一覧を先に用意しておくとよさそうです。

完璧な図でなくても構いません。
少なくとも、状態の一覧、遷移できる条件、遷移できない条件があると、AIはかなり判断しやすくなります。

5. 変更してよい範囲

AIに作業を依頼するときは、変更してよい範囲を明確にしておくと安心です。

たとえば、次のようなものです。

変更してよい範囲：
- src/pages/RequestListPage.tsx
- src/components/request/*
- src/hooks/useRequestSearch.ts
- 対応するテスト

AIは、関連しそうな箇所を広く変更することがあります。
それが便利な場面もあります。

しかし、チーム開発では、勝手に広い範囲を触るとレビューが難しくなります。
他の担当者の作業と衝突することもあります。

そのため、変更してよい範囲を先に決めておくと安心です。

特にSESや受託開発では、契約や担当範囲の制約もあります。
AIに自由に触らせる前に、今回どこまで触ってよいのかを明確にしておくと進めやすいです。

6. 変更してはいけない範囲

変更してよい範囲と同じくらい、変更してはいけない範囲も大事です。

たとえば、次のようなものです。

変更してはいけない範囲：
- 共通コンポーネント
- APIクライアント
- 認証処理
- 既存の状態管理方式
- DBスキーマ
- 既存の公開API仕様

AIは、問題を見つけると直したくなることがあります。

共通コンポーネントを少し直せば楽になる。
APIクライアントを整理すればきれいになる。
状態管理を変えれば実装しやすくなる。

それ自体は良い案かもしれません。

しかし、今回の作業で触ってよいとは限りません。

そのため、変更禁止範囲を明示し、問題を見つけた場合は報告だけにする、というルールがあると安全です。

7. 判断者

AI時代には、判断者を明確にすることも大事です。

たとえば、次のような判断です。

• 仕様の解釈を誰が決めるのか
• DB設計を誰が承認するのか
• 共通コンポーネント変更を誰が見るのか
• 未決事項を誰に確認するのか
• リファクタを今回含めるか誰が判断するのか

AIは確認事項を出せます。
しかし、その確認先が分からなければ止まります。

また、担当者が判断できないことをAIが案として出しても、現場では扱いに困ります。

AIを使う前に、少なくとも「この種類の判断は誰に聞くか」を決めておくと、案や確認事項を流しやすくなります。

8. 未決事項

未決事項も、AIに渡したい前提です。

決まっていないことを隠したまま進めると、AIは仮の前提で実装してしまうことがあります。

たとえば、次のように明示します。

未決事項：
- 承認後の修正可否
- 管理者権限の範囲
- 帳票項目の最終確定
- 外部連携エラー時の運用

未決事項があるなら、AIには「ここは仮実装にしてください」「ここは実装せず確認事項にしてください」と伝えておくと安心です。

未決なのに確定した前提で実装すると、後から大きな手戻りになります。

AI時代には、決まっていないことを決まっていないまま扱う力も効いてくると思います。

9. 受け入れ条件

最後に、受け入れ条件です。

AIに実装させると、動くものは比較的すぐできます。

しかし、何をもって完了とするかが曖昧だと、レビューが難しくなります。

たとえば、次のような条件です。

• 画面で期待通り操作できる
• APIのエラー時挙動が決まっている
• 権限ごとの表示差異が確認できる
• 状態遷移ごとのテストがある
• 既存挙動が変わっていない
• 仕様変更とリファクタが混ざっていない

受け入れ条件があると、AIにも依頼しやすくなります。

また、担当者ごとにAIの使い方が違っても、成果物の評価基準を揃えやすくなります。

AI時代には、プロンプトを揃えること以上に、受け入れ条件を揃えることが効いてくる場面があると思います。

まずは完璧でなくてよい

ここまで読むと、かなり大変に見えるかもしれません。

業務フロー、用語定義、データの正、状態遷移、変更範囲、判断者、未決事項、受け入れ条件。

全部を最初から完璧に用意するのは難しいです。

ただ、完璧でなくても、あるだけでかなり違います。

最初は箇条書きでもよいと思います。
分からないところは未決事項として書けばよいです。
AIに「この前提で不足しているものを洗い出してください」と聞いてもよいです。

大事なのは、前提がないまま実装だけを急がないことです。

AIは速いです。
だからこそ、間違った前提でも速く進んでしまいます。

少し立ち止まって前提を揃えることが、結果的に手戻りを減らすのではないかと思います。

おわりに

SESや受託開発の現場で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を入れても改善しにくい現場の特徴