2種類の売り込み

AIをめぐる売り込みには2つの方向があります。1つは外から製品やサービスを売るもの、もう1つは社内で「AIに詳しい人」という位置を得ようとするものです。

動機は違いますが、話し方には共通の特徴が現れます。どちらも、相手が検証できない領域で説得力を作る必要があるためです。

念のため確認しておきます。売り込むこと自体は問題ではありません。良い製品は売り込まれるべきで、社内で専門性を示すことも正当な行動です。見分けたいのは、検証を避ける形の説明になっているかだけです。

本章は第0章で扱った「新しい分野では3種類の人が同じ肩書きで並ぶ」という構造の、実践編に当たります。

外から売る側の話法

頻出する型を挙げます。それぞれ本書の該当章に対応します。

外部からの売り込みで現れる型
型内容扱う章
抽象度を上げる「業務全体をAIで最適化」のように対象が特定できない粒度で語る第7・15章
技術の名前で答える質問に対して、より専門的な用語で応答する第1・2章
他社名を出す導入の範囲と稼働状況を示さずに社名を挙げる第4章
デモの範囲を示さない実演は行うが、使ったデータの件数と出所を言わない第4・15章
比較表の設計で誘導する自社が優位な指標だけを並べる第3章
整備工数を省く自社側で必要になる作業を見積もりに含めない第6章
期限を切る確認可能な理由のない時間の圧力第25章
危険性を煽るリスクを強調して乗り換えを促す第18章
規制対応を誇張する製品の導入によってのみ対応が達成されるように示す第19章

この一覧の使い方は、型を見つけて相手を判定することではありません。該当する型があれば、対応する章の確認質問を1つ使うという形で使います。

社内でポジションを作る側の特徴

こちらは外部より見分けにくいことがあります。日常的に接している相手であり、実際に一定の知識を持っている場合も多いためです。

現れやすい特徴を挙げます。

  • 情報の経路が集約される ― ベンダーとのやり取り、技術情報の共有が特定の人を経由するようになる。
  • 質問に知識量で応じる ― 業務上の疑問に技術的な詳しさで答える。疑問は解消しないまま終わる。
  • 失敗の情報が出てこない ― うまくいった話は共有されるが、止まった案件の理由は共有されない。
  • 範囲外を範囲内として語る ― 実装の経験からデータ整備・法務・契約まで意見が及ぶ(第0章)。
  • 他者の確認を歓迎しない ― 第二の意見や外部の評価を求める提案に消極的である。

これらの特徴が現れているとき、本人に悪意があるとは限りません。頼られる状況が続けば、範囲外の質問にも答えざるを得なくなります。そして答えられないと表明することが、その人の位置を脅かす構造になっています。

だから対処は、人を替えることではなく情報の経路を複線化することです。

複線化の具体策

  1. ベンダーとの窓口を1人にしない ― 打ち合わせに2人以上が同席する運用にします。
  2. 技術情報の共有先を複数にする ― 更新情報の受信先を部署の共有アドレスにします(表の網羅版 第24章「継続的な検証・改善サイクル」)。
  3. 止まった案件の理由を記録する場を作る ― 書式を決め、検索できる場所に置きます(第8章)。
  4. 外部の評価を定期的に入れる ― セキュリティ診断、契約のレビューなど、範囲を限定した確認。
  5. 判断の記録を残す ― 誰がどの根拠で判断したかを残すと、属人性が下がります。

どちらにも効く確認質問

次の5問は、外部にも社内にも同じように使えます。専門知識を必要とせず、失礼にもなりません。

  1. 「今回の話のうち、ご自身が実際に手を動かされたのはどこまでですか」
    専門範囲を確認します。誠実な相手は境界を具体的に答えます(第0章)。
  2. 「デモで使ったデータは何件で、どこから持ってきたものですか」
    実演の示す範囲が分かります(第4章)。
  3. 「対象は全業務の何割ですか。残りはなぜ対象外ですか」
    提案の適用範囲が確定します(第15章)。
  4. 「うまくいかなかった場合、何が原因だと想定されますか」
    経験のある相手は具体的なリスクを挙げます。「ないと思います」は経験の不足を示します。
  5. 「同じことを実現する別の方法は何がありますか。なぜそれを採らないのですか」
    比較検討をしているかが分かります。代替案を挙げられない提案は、目的から出発していません。

5問目が最も情報量の多い質問です。代替案を説明できることは、提案の弱さではなく検討の証拠として扱われます。

質問への反応を見る

5問の答えの内容と同じくらい、質問に対する反応が情報になります。

⚠ 危険信号

確認質問に対して質問の妥当性を問い返す反応が返ってきた場合は注意してください。「その水準まで確認されますか」「専門的な内容になりますがよろしいですか」「他のお客様からこうしたご質問はいただかないのですが」。いずれも質問を取り下げさせる働きをします。誠実な相手であれば、その場で答えられない場合にも「確認のうえ改めて回答します」と応じられます。この応答は、答えられないこと自体より重要な判断材料になります。

自分が売り込む側になるとき

この章の内容は、立場が逆になったときにも使えます。社内でAI活用を提案する側になったら、5問に自分で先に答えて資料に書いておくことです。

  • 自分が手を動かした範囲と、そうでない範囲を明示する
  • デモに使ったデータの件数と出所を書く
  • 対象範囲の割合と、対象外の理由を書く
  • 想定されるリスクと、その場合の対処を書く
  • 代替案と、それを採らない理由を書く

この5点が書かれた提案は、検証可能です。検証可能な提案は、通ったときに反対者が残らないという実務上の利点もあります(表の網羅版 第15章「経営層と現場のギャップ」)。

現場のシーン架空の例

一年目の三月、朝凪精機の営業部の小野寺は、生成AIで自作した見積書作成ツールについて、経営企画部の瀬尾から5つの質問を受けました。5問目の「同じことを別の方法でやるとしたら?」に、小野寺は表計算のマクロでもできると答え、その場合の制約も説明しました。単価を引いて書式を埋めるところはマクロで足り、単価表を外に出さずに済む。ただし添え状は定型文になり、型番が増えるたびに表を直す人が要る。結果として、計算と書式は当面マクロで回して制約が実際に問題になるかを確かめる方針になり、小野寺への信頼は上がりました。二年目の三月に瀬尾が一年の総括をまとめたとき、見積もりはまだマクロで動いていて、「うまくいったこと」の欄に入りました。代替案を説明できたことが、提案全体の確度を上げました。

この章の位置づけ

本書では第1章から第22章まで、領域ごとの型と確認質問を扱ってきました。本章はそれらを相手の側から見る形で整理したものです。

実務では、領域ごとの質問をすべて覚えておく必要はありません。本章の5問を持っていれば、必要な領域の質問は相手の答えから導けます。「手を動かした範囲」が実装だけであれば、データ整備と契約は別途確認する必要があると分かります。「デモのデータ」が手作業で整えた数十件であれば、実データでの検証が必要だと分かります。

次章では、この確認を導入後の運用に対して行う形を扱います。