整備工数は、見積もりから最も外れやすい
見積もりから最初に落ちるのは、データを整える工数です。目に見えず、着手してからしか正確に測れないためです。落ちた工数は消えるのではなく、自社側の作業として残ります。
この省略は、必ずしも意図的とは限りません。データの状態は着手するまで見えないため、提案の段階では実態が分からないことが多いのです。しかし「分からない」ことと「かからない」ことは別です。不明な工数を0として見積もれば、後から必ず追加になります。
型1 ― データ品質の問題を「AIが解決する」と誤誘導する
表記のゆれ、欠損、重複といった問題について、「AIが吸収します」という説明が行われることがあります。
この説明が部分的に正しい点と、成立しない点を区別します。
| データの問題 | AIで軽減できるか | 残る作業 |
|---|---|---|
| 表記のゆれ(社名・商品名) | 候補の提示はできる | 同一かどうかの最終判定と対応表の保守 |
| 形式の不統一(日付・単位) | 変換はできる | 変換ルールの決定と検証 |
| 欠損 | できない | 欠損の意味の確認。存在しない値は作れない |
| 記録されていない項目 | できない | 記録を始める運用の構築 |
| 期間の不連続(システム移行) | できない | 対応表の整備、または期間の限定 |
| 定義の不一致(部署間) | できない | 定義の統一という組織的な合意 |
| 新旧の版の混在 | できない | 現行版を決める運用 |
上2行については、AIの活用で工数が減ります。下5行は、技術では解決しません。とくに「記録されていない項目」と「定義の不一致」は、組織側の作業です。
確認は次の1問です。「当社のデータのどの問題が、この仕組みで軽減されますか。残る作業は何ですか」。残る作業を挙げられない提案は、データの状態を確認していません。
型2 ― 整備工数を見積もりから省く
見積もりに含まれるべきで、外れやすい項目を挙げます。
- データの棚卸し ― どこに何があり、現行版がどれかを一覧化する作業。
- 実データの確認 ― 数百件を目で見て、欠損率と表記の種類を数える作業。
- 期間の連続性の確認 ― システム移行・コード改訂の影響の調査。
- 定義の統一 ― 部署間で異なる定義を揃える調整。組織的な作業のため時間がかかります。
- 対応表の作成 ― 名寄せや旧コードとの対応。
- 文書の現行版の特定 ― RAGを使う場合に必須。
- 更新の運用設計 ― 誰がいつ参照データを更新するか。
- 権限の整理 ― 誰がどの文書を見てよいか。
これらは自社側の作業になることが多く、そのためベンダーの見積もりには現れません。提案書の金額が小さく見えるのは、この部分が自社負担として計上されていないためである場合があります。
提案書にデータ整備の工数が1行も書かれていない場合、その工数は自社が負担することになります。金額の比較をする前に、「当社側で必要になる作業と工数を挙げてください」と依頼してください。挙げられない提案は、着手後に「データが揃っていないため進められません」という状態になります。この確認は、提案者を試すためではなく、自社の総工数を把握するためのものです。
型3 ― 因果関係の逆転
「AIを入れれば、後からデータが整う」という説明があります。この説明が成立する場合と、しない場合を区別します。
成立する場合
- 記録の入口を作る場合 ― これまで記録されていなかった作業を、AIを含む仕組みを通すことで記録できるようになる。実際に効果があります。
- 整備の動機になる場合 ― 具体的な用途が決まると、どのデータをどこまで整えるべきかが明確になり、整備が進むことがあります。
成立しない場合
- 過去のデータが必要な用途 ― 予測系では過去の履歴が必要で、これは今から記録しても得られません。
- 定義の不一致 ― 仕組みを入れても、部署間の定義は自動的に揃いません。むしろ数字が合わない問題が顕在化します。
- 文書の版の混在 ― 参照する仕組みを入れると、古い版を根拠にした回答という形で問題が現れます。
したがって確認は「この用途に、過去のデータは必要ですか」です。必要な場合、後から整えるという説明は成立しません。必要でない場合(記録の入口を作る用途)であれば、その説明には根拠があります。
型4 ― データ整備プロジェクトが独立して膨らむ
逆方向の問題も存在します。整備の必要性が認識された結果、用途が決まらないまま大規模な整備プロジェクトが始まることがあります。
この形が問題になる理由は3つです。
- どこまで整えるべきかが決まらない ― 用途がないと、整備の完了条件が定義できません。
- 効果が測れない ― 整備そのものは業務の改善を生みません。
- 整備が終わる前に前提が変わる ― 業務やシステムが変われば、整備の対象も変わります。
実務的な順序は、件数の多い業務を1つ選び、その用途に必要な範囲だけを整備することです(表の網羅版 第7章「DXの進め方 ― データ化なくして活用なし」)。1業務で通すと、整備の手順と工数の実測が得られ、次の業務の見積もりが具体的になります。
八月、盆休みの前の週に、アストラム・データの営業部長の間宮は社内文書検索の試行について「データ整備は後で大丈夫です」「既存の社内文書を、そのまま活用できます」と説明しました。見積書は初期設定・取り込み・月額利用料・操作説明会の4項目で、データを整える作業の行はありません。AI推進室の瀬尾は、試行を始めるまでに当社側で必要になる作業を、工数の見込みを添えて書面で挙げるよう依頼しました。盆休み明けの週にアストラムの技術部から届いた回答は、現行版の特定、画像で保存された手順書の作り直し、更新担当の決定の3点でした。照会前の見積もりにはこの3つが含まれておらず、いずれも自社で行う作業でした。照会に要したのはメール1往復で、その結果として着手時期の見通しが3か月変わりました。
この場面は網羅物語之巻 第5章「本当の最新版」に出てきます。
この章の確認質問
- 「当社のデータのどの問題が軽減され、残る作業は何ですか」 ― データ品質の主張を検証する。
- 「当社側で必要になる作業と工数を挙げてください」 ― 最も重要な1問。
- 「この用途に、過去のデータは必要ですか」 ― 「後から整う」の成立可否を判定する。
- 「参照する文書の現行版を決める作業は、誰が行いますか」 ― RAGを使う場合。
- 「参照データを更新する担当と頻度は、どう想定していますか」 ― 運用の設計。
- 「期間の連続性(システム移行・コード改訂)は確認済みですか」 ― 予測系で必須。
自社側で先に済ませられること
提案を受ける前に自社で確認しておけば、見積もりの精度が上がり、交渉も具体的になります。所要は数日です(表の第6章の判定手順)。
- 対象データを実際に数百件見る
- 列ごとの欠損率と値の種類数を数える
- 主要項目の表記のゆれを一覧にする
- 期間の連続性を確認する
- 業務担当者に、各項目がどう入力されているかを聞く
この5点の結果を提案依頼時に提示すると、見積もりの前提が揃い、後からの追加が減ります。提案者にとっても不確実性が下がるため、双方に利益があります。