発注側が自分で作る罠

AI関連の発注で起きる問題は、受注側の能力不足だけが原因ではありません。発注側の進め方が、後半の詰まりを作っていることが少なくありません。この章では、発注側が自分で避けられる4つの型を扱います。

型1 ― 要件定義書さえ完成すれば安心という思い込み

要件定義書は必要です。しかしAIを含む案件では、要件定義書が完成しても実現可能性は確定していません。理由は単純で、実現可能性が自社データの状態に依存するからです。

「請求書から金額を読み取り、基幹システムに登録する」という要件は明確です。しかし実際にできるかどうかは、次で決まります。

  • 取引先ごとの書式が何種類あるか
  • 手書きの割合はどれくらいか
  • 基幹システムに登録用の接続口があるか
  • 登録時の必須項目が、請求書から取れる項目で埋まるか

これらは要件定義の作業ではなく、現物の調査です。要件定義書と並行して、実データのサンプル調査を工程に入れてください。ここを飛ばすと、開発の後半でデータ側の問題が発覚し、範囲を削るか品質を落とす選択になります。

型2 ― デモの完成度を本番品質と誤認する

提案時のデモは、動作を確認するためのものです。デモで確認できていないのは、シンプル版 第4章「AIを使ったコーディング・システム開発」で挙げた6項目(異常時の動き、権限、整合性、性能、保守性、運用の受け皿)です。

誤認を避ける方法は1つです。デモに使ったデータの件数と出所を聞くこと。「実際の帳票を何件使いましたか」「そのうち手書きは何件ですか」。この2問で、デモの示している範囲がわかります。

型3 ― 発注後に仕様が膨らむ

着手後に「せっかくだからこの機能も」という要望が増えていく現象です。AI案件で特に起きやすい理由があります。動くものを見ると、追加でできそうなことが具体的に想像できるためです。

膨張自体が悪いわけではありません。問題は、追加の判断基準と費用の扱いが決まっていないことです。次の2つを契約時に決めておけば、追加要望は正常な変更管理として処理できます。

  • 追加要望の窓口と判断者 ― 誰が受け、誰が可否を決めるか
  • 追加時の費用と期間の扱い ― 無償の範囲、有償になる境界

型4 ― 体制と受け入れ条件が曖昧なまま進む

最も後で効いてくるのがこれです。次の4点が決まっていない発注は、完了の判断ができません。

  1. 誰が作業するのか ― 提案者と実作業者が同じか、再委託があるか。
  2. 受け入れの条件 ― 何をもって完成とするか。AIの出力は毎回変わるため、「正しく動く」では条件になりません。「実データ100件で、人の修正が必要な件数が10件以下」のように件数で定義します。
  3. 納品物の範囲 ― コードだけか、設計資料と手順書を含むか。含まなければ、以後の変更は発注元では行えません。
  4. 稼働後の保守 ― 誰が、どの範囲を、いくらで見るのか。ここが空欄だと、稼働直後に追加契約の交渉が始まります。
⚠ 危険信号

受け入れ条件を「正常に動作すること」と書いた契約は、AI案件では機能しません。出力が毎回変わる前提では、単発の動作確認は合否の判定にならないからです。実データの件数と、許容できる誤りの件数で定義してください。「実データ100件を処理し、修正が必要な件数が10件以下」であれば、双方が同じ基準で判定できます。

現場のシーン架空の例

朝凪精機では前の年、社内規程についての質問に答える総務の規程Q&Aを外部に発注しました。検収は問題なく通りました。ところが規程が改定されると、答えは古いままになりました。参照する資料の更新手順が納品物に入っておらず、結局、追加の見積もりを取ることになりました。三月九日、問い合わせ記録の入力画面の発注を話し合う席で、情報システム課の倉田はこの件を挙げ、検収を通ったあとに何が起きたかを話しました。これを受けて経営企画部の瀬尾は、入力画面の発注条件に「納品物に設計資料と運用手順書(マスタの更新のしかた、止まったときの戻し方)を含める」と書き入れました。納品物の範囲に「運用の手順書」を明記するだけで避けられる種類の追加費用です。

この場面は物語之巻 第4話「仕様書に書いていないこと」に出てきます。

発注前に決めておく5項目

これだけ決めておけば、上の4つの型はほぼ防げます。

  1. 実データのサンプル調査を工程に入れる ― 要件定義と並行して、現物を数十件見る。
  2. 受け入れ条件を件数で定義する ― 「実データ○件で修正必要が○件以下」。
  3. 納品物に設計資料と運用手順書を含める ― これがないと自社で変更できません。
  4. 追加要望の窓口・判断者・費用の扱いを決める ― 変更管理として処理できるようにする。
  5. 稼働後の保守範囲と費用を、発注時に見積もる ― 後から交渉しないため。

いずれも技術的な知識を必要としません。発注の一般的な作法をAI案件に当てはめただけです。逆に言えば、AIという言葉に気を取られて、通常の発注管理が抜け落ちることが最大の罠です。