AIを使った業務システムの開発で「予定より2か月延びた」という話は珍しくありません。ただ、遅れた理由を後から並べてみると、多くはAIモデルの性能や実装の難易度そのものではなく、着手前の段階ですでに見えていた条件に起因します。つまり、計画の時点で手当てできた可能性が高いということです。
この記事では、AI業務システムの受注開発でスケジュールが延びやすい4つの箇所を整理し、見積もりや計画に織り込むための確認項目をまとめます。発注側の経営者・担当者が、キックオフ前に自社で確かめられる内容に絞りました。
遅れ①:学習・検証に使うデータが、期日までに揃わない
最も頻度が高い遅れです。AIを業務に組み込む場合、社内の文書・帳票・過去の対応履歴などを用意する必要がありますが、この「用意する」が想定の数倍かかります。
詰まるのは次のような段階です。
- 所在の確認:どのフォルダ、どのシステム、誰のPCにあるのかが分からない
- 形式の不統一:同じ帳票でも紙のスキャン、Excel、PDFが混在している
- 持ち出し可否の判断:顧客名や個人情報が含まれており、開発会社に渡してよいか社内で決まっていない
- 新旧の判別:どれが現行版か分からず、業務部門に確認して回る必要がある
特に社内文書を検索・参照させる仕組み(RAG:社内文書を検索してAIの回答の根拠に使う方式)では、この工程がプロジェクトの大半を占めることがあります。文書の整理状況が精度を左右する点は、RAG の精度はモデルではなく文書管理で決まるで詳しく触れています。
着手前に確認することは、「誰が、いつまでに、どの形式で、何件渡せるか」の4点です。ここが口頭の「たぶん出せます」で止まっているなら、その時点でスケジュールに予備日を置くべきです。
遅れ②:「何が正解か」を決める人が決まっていない
AIの出力は、従来のシステムのように仕様書と突き合わせて○×を付けられません。「この要約は業務上使えるか」「この分類は妥当か」を判断する人が必要です。
ところが、この判断役が決まらないまま開発が進むと、こうなります。
- テスト段階で複数の担当者から別々の指摘が出て、どちらに合わせるか決まらない
- 「もう少し自然に」「もっと業務に合わせて」といった定性的な要望が繰り返し届く
- 修正しても評価基準が変わるため、良くなったかどうか誰も判断できない
たとえば次のような場面です。問い合わせ分類AIについて、営業部門は「取りこぼしを防ぐため広めに拾ってほしい」、サポート部門は「無関係な案件が流れてくると負担が増える」と主張し、どちらを優先するか決まらないまま2週間が過ぎる——こうした調整は技術的な作業ではないため、開発会社側では解決できません。
対策は、着手前に評価データ(想定入力と期待される出力の組)を数十件つくり、最終判断者を1人決めておくことです。この準備の進め方は評価データセットの作り方と運用にまとめています。
遅れ③:既存システムとの接続で止まる
AI部分が単体で動いても、基幹システムや業務システムとつながらなければ業務には乗りません。そして、この接続は社外の開発会社が自力で進められない領域です。
よく止まるのは次の3点です。
- 接続仕様が分からない:導入ベンダーが変わっている、API(システム同士をつなぐ窓口)の資料が残っていない
- テスト環境がない:本番しかなく、試すには業務を止める必要がある
- 権限の発行に時間がかかる:接続用アカウントの発行に、情報システム部門や外部ベンダーの承認が要る
いずれも調査すれば分かる話ですが、回答が返ってくるまでの待ち時間が読めません。外部ベンダーへの問い合わせが1往復で1〜2週間かかるケースもあります。詳細は基幹システムにAIを足すと工期が延びるで整理しています。
遅れ④:審査と承認が、開発の後ろに回っている
4つ目は社内手続きです。開発が終わってから稟議や審査に回すと、そこから数週間が追加で乗ります。
確認が必要になりやすいのは次の項目です。
- 外部のAIサービスに業務データを送ることの可否(個人情報保護法の観点、取引先との秘密保持契約の条項)
- クラウド利用に関する社内規程との整合
- 帳票や記録を扱う場合の保存要件(電子帳簿保存法など、該当する法令の確認)
- 予算の執行区分(試験導入か本稼働かで決裁者が変わる場合がある)
法令や規程の具体的な適用範囲は業種・取扱いデータによって異なるため、該当しそうな項目を早い段階で挙げ、自社の管理部門や顧問に確認しておくのが確実です。経営層への説明で問われやすい論点は、AI導入の稟議を通すに整理しています。
着手前にスケジュールへ書き込む「4つの日付」
上の4つは、いずれも開発会社の作業ではなく発注側の準備に属します。したがって、工程表に開発会社のタスクだけを書くと、遅れが見えないまま進みます。キックオフ時点で、次の4つを日付付きで決めておくことを勧めます。
| 遅れの箇所 | 決めること | 担当 | 目安の時期 |
|---|---|---|---|
| データ | 渡す対象・件数・形式・持ち出し可否 | 業務部門+管理部門 | 開発開始前 |
| 正解の基準 | 評価データの作成と最終判断者の指名 | 業務部門の責任者 | 開発開始前 |
| 既存システム接続 | 仕様資料の有無・テスト環境・権限申請 | 情報システム担当 | 見積もり時点で調査開始 |
| 審査・承認 | 必要な審査の洗い出しと申請日 | 管理部門 | 開発と並行 |
この表に日付が埋まらない行があれば、そこが遅れる候補です。埋まらない理由(担当が決まらない、判断材料がない)こそが、着手前に解消すべき課題になります。
なお、見積もり段階で開発会社から「データはいつ頂けますか」「正解を判断するのはどなたですか」という質問が出てこない場合は、こちらから確認しておくと安全です。これらを前提条件として契約書や提案書に明記しておくと、遅れが生じたときの責任範囲も整理しやすくなります。
まとめ
AI導入のスケジュールが延びる原因は、着手前に次の4点として見えています。
- データが期日までに揃わない——所在・形式・持ち出し可否が未確定
- 正解を決める人がいない——評価基準と最終判断者が未指名
- 既存システムとの接続で止まる——仕様資料・テスト環境・権限の不足
- 審査と承認が後ろに回る——法令・社内規程の確認が開発後になる
いずれも技術的な難問ではなく、社内で誰が何をいつまでに決めるかという問題です。逆に言えば、キックオフ前の数時間を使って上の表を埋めるだけで、後工程の数週間を節約できる可能性があります。
AI導入の計画を立てる際は、開発会社の作業日数だけでなく、自社側の準備・判断・承認にかかる日数を同じ工程表に並べてください。遅れは、そこに空欄があるときに起きます。
