経営層と現場のギャップ

断絶は能力の問題ではない

経営会議で高く評価されたAI施策が、現場では「使えない」と言われる。逆に、現場が効果を実感している改善が、経営層には報告されず予算がつかない。この断絶は多くの組織で観察されます。

シンプル版のシンプル版を読んだ方は、断絶の構造までは同じです。この章が足すのは、双方に伝わる資料の書き方・成功と失敗の社内共有の仕組み・ギャップを埋める最小構成です。

最初に確認しておきます。これは誰かの能力や姿勢の問題ではありません。両者が見ている情報の粒度と時間軸が構造的に違うために起きます。

本章では構造を分解し、間に共通の軸を置く方法を扱います。第7章(DXの粒度)と同じ根を持つ問題を、経営の側から扱う章です。

報告が階層を上がるときに落ちるもの

経営層に届く情報は、性質上まとめられています。「AI導入により処理時間が40%短縮」という一文は、それ自体は正確でも、次のような条件を伴っている場合があります。

• 対象は全体の3割にあたる定型パターンのみで、残り7割は従来どおり
• 短縮されたのは入力作業で、確認作業が新たに増えている
• 試験導入の1か月間、担当者が付きっきりで運用していた
• 比較対象の「従来の処理時間」が推測値である

これらは意図的に隠されているとは限りません。報告の階層を上がるたびに情報は要約され、要約では成果より先に条件が落ちます。要約は情報を捨てる処理だからです(第4章)。

この結果、上層には順調に進んでいるという像が残り、現場には限定的にしか使えていないという像が残ります。どちらも自分の情報の範囲では正しいのです。

対処 ― 書式で強制する

個人の注意に頼らない方法があります。報告書式で、成果と条件を同じ行に書かせることです。

• ×「処理時間40%短縮」
• ○「処理時間40%短縮(対象:定型パターン、全体の3割。確認工程を含む合計時間)」

書式で強制すれば、階層を上がっても条件が残ります。これは第9章のKPI設計と同じ原則(範囲と精度は常にセット)です。

抽象的なAIプレゼンが通る構造

経営層向けの提案では、抽象度の高い説明が好まれる傾向があります。これには合理的な理由があります。経営判断に必要な情報は投資額と回収の見込みであり、実装の細部は本来その判断材料に含まれないためです。

ところがAIの領域では、この妥当な省略が問題を生みます。実現可能性そのものが、データの状態という実装の詳細に左右されるためです。

「需要予測により在庫を最適化する」という説明は、投資判断の粒度としては足りているように見えます。しかし実際にできるかどうかは、次で決まります。

• 何年分の販売データが、どの粒度で残っているか(第6章)
• 欠品・販促の記録が残っているか
• システム移行やコード改訂をまたいでいないか
• 予測を発注に反映する仕組みが、人の判断を挟まずに動かせるか

確認を経ずに投資が決まると、着手後になってデータが存在しないという事実に突き当たります。すでに予算と期限が決まっているため、範囲を狭めるか、精度を落として無理に形にするかの選択になります。

PoCデモと量産運用の間にある溝

試験的に作った実証がうまく動いたのに、本番に移すと止まる。溝の中身は第11章の8項目とほぼ同じですが、組織の話として見ると追加で3つの要素が現れます。

1. 件数が変わる ― 100件で動いた処理が10万件で動くとは限りません。費用も比例します。
2. 担当者が変わる ― PoCは意欲の高い担当者が丁寧に運用します。本番では、日々の業務に追われている全員が使います。
3. 例外が現れる ― PoCの対象は代表的なパターンです。本番では第7章で述べた例外が一定割合で混ざります。

したがってPoCの評価では、精度の数値だけでなく対象範囲の割合を必ず確認する必要があります。「精度92%」と「全業務の3割を対象にした精度92%」は、まったく違う情報です。

デモの見え方の非対称

もう一つ構造的な問題があります。デモは成功する場面を選んで見せるものです。これは不誠実だからではなく、限られた時間で価値を示す方法として自然です。

しかしその結果、経営層が見る情報は「うまくいく場面」に偏ります。対処は2つです。

• 失敗する場面も見せてもらう ― 「うまくいかないのはどういうデータですか」と聞き、実際に試してもらいます。
• デモに使ったデータの件数と出所を確認する ― 手作業で整えた数十件なのか、実際の業務データなのか。

現場が直面する現実的な課題

現場側から見ると、問題は精度そのものよりその周辺に集中します。

共通するのは、しのげている間は報告されず、しのげなくなったときに「使えない」という結論だけが伝わるという構造です。だから経営層には、突然の失敗として見えます。

共通の評価軸をつくる

両者の間に橋を架けるには、双方が同じ数字を見られる状態を作ることです。次の5項目は、経営層にとっても現場にとっても意味があり、かつ測れます。

この5項目を月次で並べるだけで、議論の噛み合い方が変わります。経営層は「範囲を広げるか、確認を減らすか」という判断ができ、現場は「確認の手間」を数字として提示できるようになります。

加えて、これらの数字は第13章のログから自動的に得られます。抽象化の層で記録していれば、集計は仕組みで行えます。

双方に伝わる説明資料の作り方

資料を作る側の実務的な工夫を挙げます。

経営層向けに必ず入れる4項目

1. 対象範囲 ― 全体の何割か。ここを書かない資料は評価できません。
2. 3年間の総額 ― 初期費用だけでなく、運用・保守を含めた金額(第9章)。
3. 止まったときの業務への影響 ― 代替手段があるか(第10章)。
4. やめる場合の条件と費用 ― 中止・移行が可能か。

現場向けに必ず入れる4項目

1. 確認作業の内容と所要時間 ― 何をどれだけ確認する必要があるのか。
2. 誤りが出たときの対処手順 ― 誰に連絡し、どう処理するか。
3. 責任の所在 ― AIの出力を使った結果の責任は誰が負うのか(第16章)。
4. 止まったときの代替手順 ― 手作業に戻す方法。

現場向けの3番目が、実務では最も重要です。責任の所在が曖昧なままだと、現場は使わないことで自衛します。これは合理的な判断です(第8章)。

成功事例・失敗事例の社内共有

共有の仕組みがないと、部署をまたいで同じ失敗が繰り返されます。「データが足りず中止した」という記録は、次の案件では最も価値のある情報です。

共有が成立する条件

• 中止を報告しても不利にならない扱いにする ― これがないと、失敗事例は共有されません(第8章の評価制度)。
• 書式を決めて短くする ― 対象業務・やったこと・結果・止めた理由・次にやるなら何を変えるか。1ページで足ります。
• 検索できる場所に置く ― 会議で共有するだけでは、後から探せません。
• 数値を残す ― 対象範囲、精度、費用、所要時間。抽象的な感想は再利用できません。

共有すべき失敗の型

実際に繰り返されやすい失敗を、共有の対象として挙げます。

• データの期間・粒度が足りなかった(第6章)
• システム移行をまたいでデータが連続していなかった
• 確認工数が削減効果を上回った
• 費用が想定を超えた(再試行分の見込み漏れ)
• 権限設計が後付けになり公開できなかった
• 参照文書の整理が終わらず稼働できなかった

これらはいずれも、他の部署でも同じ条件で発生します。1つの部署が経験した内容が共有されれば、他部署は着手前に確認できます。

ギャップを埋めるための最小構成

本章の内容を、実行できる形にまとめます。

1. 報告書式に「対象範囲」の欄を作る ― 1箇所の変更で、条件が落ちなくなります。
2. 月次で5つの数字を並べる ― 対象範囲・確認を含む所要時間・1件あたり費用・例外発生率・直せる人の数。
3. 現場の担当者が直接説明する機会を月1回作る ― 要約を経ずに情報が上がる経路になります。
4. 失敗事例の書式を決め、検索できる場所に置く ― 中止が不利にならない扱いを明記します。
5. 提案の受付時に、データの現状の記述を必須にする ― 実現可能性の検証を前提にします。

いずれも大掛かりな体制を必要としません。変えるのは情報の流れであり、人ではありません。