非対称は、利用できる資源にもなる

経営層と現場のあいだの情報の差は、構造的に生じるものです。ただしそれは、埋めるべき問題であると同時に、使える資源にもなります。ここでは使う側から見ます。

第8章では同じ構造を現場と中間層の側から見ました。本章は、経営層に向けた説明の場で起きる型に焦点を当てます。

前提を確認しておきます。抽象度の高い説明が経営層に向けられるのは正常です。経営判断に必要なのは投資額と回収の見込みであり、実装の細部は本来その材料に含まれません(表の第15章)。問題は、AIの領域では実現可能性そのものがデータの状態という細部に左右されることです。この性質があるため、通常であれば妥当な省略が、判断の誤りを生みます。

型1 ― 抽象的なプレゼンで実現性の説明を避ける

提案が抽象度の高い水準で止まる場合、確認すべきは1点に絞られます。データの現状について記述があるか。

表の第15章で示した2つの確認事項を再掲します。

  1. どのデータを、どの粒度で、何年分使うのか
  2. それが現在どこに、どの形で存在するのか

この2点に答えられない提案は、実現可能性を検証していません。金額の妥当性を議論する段階に達していないため、差し戻しは正当な判断です。

あわせて確認すると効果が大きい項目を挙げます。

  • 「当社側で必要になる作業と工数」 ― データ整備の工数は自社負担になるため、提案書には現れません(第6章)。
  • 「対象は全業務の何割か」 ― 精度の数値と必ずセットで。
  • 「うまくいかなかった場合、何が原因だと想定するか」 ― 経験のある提案者は具体的なリスクを挙げます。

型2 ― デモと量産運用の溝を見せない構成

デモは成功する場面を選んで見せるものです。これは不誠実だからではなく、限られた時間で価値を示す方法として自然です。結果として、判断者が見る情報は「うまくいく場面」に偏ります。

偏りを補正する方法は2つあります。

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

2番目は、相手を試す質問ではありません。実際に運用した経験がある相手であれば、苦手な条件を具体的に挙げられます。そしてその情報は、自社のデータがその条件に該当するかを判断する材料になります。挙げられない場合、運用の経験が薄い可能性があります。

⚠ 危険信号

実演の場で「では当社のデータで試してもらえますか」と依頼したときの反応を見てください。これは選定の正当な手順であり、断られる理由は通常ありません。「準備に時間が必要です」という回答は妥当です。「デモ環境では対応していません」「一般的なデータで十分お分かりいただけます」という応答が返る場合、実データでの結果が示せない理由を確認する必要があります(表の網羅版 第3章「主要AIサービス・モデルの比較」)。

型3 ― 現場の課題が経営層に届かない構造の利用

表の第15章で扱ったとおり、現場の課題は「しのげている間は報告されず、しのげなくなったときに結論だけが伝わる」という性質を持ちます。

この構造が利用される形を挙げます。意図的なものと、結果的にそうなるものの両方があります。

情報が届かない形と、対処
形起きていること対処
報告経路が一本に集約される特定の担当者を経由した情報だけが上がる現場が直接説明する機会を月1回作る
利用率の低下が「慣れの問題」とされる具体的な不一致が抽象化される使わない理由を現場に直接聞く
確認工数の増加が報告されない数値化されておらず、担当者の工夫で吸収されている確認を含む所要時間を測る
要望が記録されない口頭で消え、対応の有無も残らない要望を対応・保留・不可で記録する(第8章)
成果だけが上がり条件が落ちる要約の性質。書式に欄がない報告書式に対象範囲の欄を作る

2行目が最も頻繁に見られます。使われない理由は、抽象的な意識の問題ではなく具体的な不一致であることが多いのです(表の第15章)。出力形式が引き継ぎ方と合わない、確認の手間が元の作業を上回る、根拠が表示されないため信頼して次に進めない。いずれも具体的で、対処可能です。

型4 ― 経営層向けと現場向けで説明を分ける

同じ施策について、経営層には効果を、現場には負担の小ささを強調する形です。それぞれの説明が矛盾していない限り問題ありませんが、前提が異なる説明になっている場合は後で衝突します。

衝突が起きる典型を挙げます。

  • 経営層には「全業務が対象」、現場には「まず一部から」と説明されている
  • 経営層には「人手が減る」、現場には「業務がなくなることはない」と説明されている
  • 経営層には「短期間で効果」、現場には「定着には時間がかかる」と説明されている
  • 経営層には「追加の人員は不要」、現場には「運用の担当が必要」と説明されている

対処は、同じ資料を両方に見せることです。表の第15章に示した「経営層向けに必ず入れる4項目」と「現場向けに必ず入れる4項目」を1つの資料に含めれば、前提の相違が生じません。

型5 ― 成功事例だけが社内で流通する

組織内の情報の流れとして、最も損失が大きい型です。第8章でも扱いましたが、経営層の視点から見ると次の問題になります。

  • 他部署の失敗が共有されないため、同じ壁に同じ費用をかけて突き当たる
  • 成功例だけを見て判断するため、成功の条件が一般化される
  • 中止の判断が遅れ、予算が固定される
  • 投資判断の精度が改善しない

対処は経営層の側からしか実行できません。中止を報告しても不利にならない扱いを、制度として明示することです。これがない限り、失敗の情報は上がりません。

あわせて、中止事例の書式を決めます。対象業務・やったこと・結果・止めた理由・次にやるなら何を変えるか。1ページで足ります(表の第15章)。

現場のシーン架空の例

朝凪精機が入れた議事録の要約ツールは、利用率が1割を切り、常務の大槻には「現場の慣れの問題」と報告されていました。実際には、要約の形式がカスタマーサポート課の引き継ぎ方と合っていなかっただけで、出力を決まったこと・宿題と担当・期限・決まっていないことの4つに分けて出すよう変えると、課では使う人が戻っていました。大槻がそれを課長の村瀬から直接聞いたのは、一年目の三月です。二年目の二月、現場同行でCS課を訪れた大槻に、村瀬は、その話が届くまでに3か月かかったことを改めて指摘しました。大槻はその日の帰りに、経営会議の最初の30分を月1回、現場の担当者が直接話す場にすると決めました。この情報が届くまでに3か月かかったこと自体が、本章で扱った構造の現れでした。

経営層の側から打てる手

本章の型は、いずれも経営層の側からの操作で緩みます。所要は小さいものです。

  1. 提案の受付時に、データの現状の記述を必須にする ― 1行の運用ルールで、実現可能性の検証が前提になります。
  2. 報告書式に「対象範囲」の欄を作る ― 条件が落ちなくなります。
  3. 現場の担当者が直接説明する機会を月1回作る ― 要約を経ない経路ができます。
  4. 実演の際に自社データでの結果を求める ― 選定の正当な手順です。
  5. 中止を報告しても不利にならない扱いを明示する ― 失敗の情報が上がるようになります。
  6. 経営層向けと現場向けの説明を同じ資料にする ― 前提の相違を防ぎます。

3番目が最も効果が大きく、最も実施しやすい項目です。月1回、30分でも、要約を経ない情報経路があると非対称は緩みます。