この章の前提 ― 扱うのは行動の型
AI導入のプロジェクトでは、上に届く報告と現場の実態がずれることがあります。この章で扱うのは、そのずれが生じる行動と構造の型です。特定の人物像を名指しするものではありません。
この区別は実務上も重要です。ずれの多くは、誰かが意図的に虚偽を述べた結果ではなく、情報の非対称性から生じます。上には要約された情報だけが届き、下には全体の判断材料がない。この状態が続けば、悪意がなくても報告と実態は離れていきます。
したがって対処も、人を責めることではなく情報の流れを変えることになります。表の網羅版 第15章「経営層と現場のギャップ」は同じ問題を経営の側から扱っており、本章は現場と中間層で起きる型に焦点を当てます。
型1 ― 成果だけが上がり、条件が落ちる
試験導入がうまくいったとき、報告されるのは達成された数値です。落ちるのは条件です。
この現象は報告の階層構造の性質から生じます。要約は情報を捨てる処理であり、捨てられるのは条件の側です。結果として次の状態になります。
- 上層は「成功した施策」として認識し、拡大の指示を出す
- 現場は残りの範囲で同じ結果が出ないことを知っている
- 中間層は、指示と現実の間で範囲を狭めるか精度を落とす選択をする
- 結果が出ないとき、原因が「実行の問題」として扱われる
対処 ― 書式で強制する
個人の注意に頼らない方法があります。報告書式に「対象範囲」の欄を作ることです。
欄があれば、書かないという選択ができなくなります。逆に欄がなければ、意識の高い担当者だけが条件を併記する状態になり、書いた人の報告のほうが成果が小さく見えるという逆転が起きます。書式の不在は、条件を省いた報告を有利にします。
型2 ― AIの出力を判断の隠れ蓑にする
「AIの分析ではこの案が最適でした」という説明は、客観的に見えます。しかし実際には、どのデータを入力に含めたか、どの選択肢を比較の対象にしたか、どう指示を書いたかという各段に判断が入っています。
この型が問題になるのは、うまくいかなかったときです。判断した人が特定できないため、原因の検証もできません。そして検証されないため、同じ判断が繰り返されます。
確認の2問
- 「入力に何を使いましたか」
- 「比較した選択肢は何でしたか」
AIの出力は入力と指示で決まります。この2点を確認すれば、判断がどこで行われたかが明確になります。あわせて、最終的な判断は人が行ったと記録に残す運用にしておくと、後の検証が可能になります(表の網羅版 第16章「AIガバナンス体制の構築」)。
この確認は責任追及ではありません。入力の選び方に改善の余地があれば、それが次回の精度向上につながります。
型3 ― 改善要望が「そういうもの」で終わる
現場から出力の質について指摘が上がったとき、その後の対応は2つに分かれます。プロンプトの見直し、参照データの追加、確認工程の変更、ベンダーへの照会といった具体的な改善に変換するか、「AIというのはそういうもの」「今の技術では無理」という一言で終わらせるか。
後者が選ばれる理由は、必ずしも怠慢ではありません。
- 改善に必要な知識がない(どこを変えれば何が変わるか分からない)
- 時間がない
- ベンダーへの照会に費用が発生する
- 「無理」と答えるほうが、期待値の管理として安全に見える
しかしこの一言が続くと、現場は声を上げなくなり、利用率が静かに下がります。そして低下の理由は「慣れの問題」として報告されます。
対処 ― 要望を分類して理由を残す
要望を記録する場所を作り、対応・保留・不可の3つに分類して理由を1行書く運用にします。
この形の利点は、「不可」の理由が書けないものが可視化されることです。表の第2章・第13章で扱ったとおり、変更できる対象は複数あります(プロンプト、参照データ、確認工程、モデル、設定値、業務手順)。これらのどれを試したかを書けない場合、まだ検討されていません。
型4 ― 他社比較が「特殊だから」で遮断される
「他社ではこうしているらしい」という情報に対して、「うちは業務が特殊だから」で議論が終わることがあります。
実際に特殊な場合もあります。しかしこの一言は検証なしに使えるため、比較を避ける機能も持ちます。
対処 ― 「特殊」を要素に分解する
次の5点のどれが特殊なのかを1つずつ確認します(第5章)。
- 取扱品目・サービスの種類数
- 取引先・拠点の数
- 承認の階層
- 適用される規制
- 既存システムの構成
分解すると、本当に比較不能な部分はごく一部であることが多いことが分かります。そして特殊な要素が特定できれば、その部分だけを別途検討する形に進めます。
型5 ― 成功だけが共有され、中止が共有されない
組織内の情報の流れとして、最も損失が大きい型です。中止した案件の理由は、次の案件で最も価値のある情報です。しかし共有されません。
理由は構造的です。中止が担当者の評価を下げる組織では、中止の報告そのものが不利益になります。そのため、中止は静かに行われ、理由は記録されません。
対処の3点
- 着手前に中止条件を文書化する ― 中止が「計画の実行」になり、個人の判断ではなくなります(表の網羅版 第9章「プロジェクトマネジメント・投資対効果」)。
- 評価指標を活動量から結果に変える ― PoC件数ではなく、稼働して6か月後も動いている件数。
- 中止事例の書式を決める ― 対象業務・やったこと・結果・止めた理由・次にやるなら何を変えるか。1ページで足ります。
朝凪精機の全社DX推進委員会では、各部の月次報告の書式が「取組名・進捗・今月の活動・AI利用回数・PoC実施件数」の5欄だけで、「対象範囲」の欄がありませんでした。九月の委員会では、第一工場だけが「今月の活動」の欄の端に、対象は一つの工程の傷の一種類だけだと書き足していました。書き足したぶん報告はいちばん小さく見え、常務の大槻は「遅れている」と言いました。AI推進室の瀬尾が「対象範囲」の欄を入れた書式の改訂案を出すと、大槻は次の委員会からの採用を決めました。書式に「対象範囲」の欄を置くと決めたところで、第一工場への「遅れている」は取り消され、翌月の委員会から全部署の報告に範囲が入るようになりました。書式の不在が、条件を省いた報告を有利にしていたことになります。
この場面は網羅物語之巻 第6章「進捗良好」に出てきます。
情報の流れを変える5つの仕組み
本章の対処を、実行できる形にまとめます。いずれも人ではなく仕組みを変えるものです。
- 報告書式に「対象範囲」の欄を作る ― 型1に効きます。1箇所の変更で全報告に反映されます。
- AIの出力を根拠にする場合、入力と比較対象を併記させる ― 型2に効きます。
- 要望を対応・保留・不可で分類し、理由を1行残す ― 型3に効きます。
- 「特殊」の主張は5要素に分解して確認する ― 型4に効きます。
- 中止条件を着手前に文書化し、中止事例の書式を作る ― 型5に効きます。
加えて、現場の担当者が月1回でも直接説明する機会を作ると、要約を経ない情報経路ができます。この経路の存在自体が、情報の非対称性を緩めます。