Volodymyr Silchenkoは、国家安全保障に向けた自律性を推進するシリコンバレーの防衛テック・スタートアップ、OMNIA AIの創業者兼CEOである。
現場チームが心から気に入るものを作っても、大規模な導入に失敗することはある。
規制が厳しく、リスクの高い環境では、導入は一人の判断で決まることはまずない。それは調整の問題なのだ。異なる職務、リスク、インセンティブを持つ複数の人々が、前に進む道筋に同意しなければならない。
参考になるデータが1つある。複雑なB2B購買に関するChallengerの調査では、購買グループは初期段階で平均5.4人の利害関係者を抱え、その後時間とともに増加することが示された。言い換えれば、リスクが高まるほど関与者は増える。これは「プロダクト・マーケット・フィット」が実際に意味するものを変えてしまう。
防衛テックの創業者として顧客発見に取り組む中で、私はエンドユーザーの強い熱狂がプロセスの終点ではなく、しばしば起点に過ぎないことを学んだ。
混同してはならない4つの役割
多くの創業者は「顧客」を、製品を使う人として思い描く。これは良い出発点だ。しかし複雑な組織では、頭の中で少なくとも4つの異なる役割を分けて考える必要がある。
これは、受益者、意思決定者、リソース所有者を明確に分けるミッション主導のステークホルダーモデルにもきれいに対応する。
• エンドユーザー：ワークフローの中にいる人である。画面を監視するオペレーター、訪問記録を残す看護師、データを突き合わせるアナリスト。彼らはスピード、使いやすさ、信頼性、そして日々の負担を軽減するものを重視する。
• 意思決定者：ミッションの責任者、あるいは説明責任を負うエグゼクティブである。彼らは日常的にツールに触れないことも多い。成果とリスク、すなわち安全性、即応性、品質、インシデント率、評判への露出を気にかける。投資を正当化し、何か問題が起きた場合に組織としてのリスクを引き受けるのが彼らの仕事だ。
• バイヤー（調達、契約、コンプライアンス、セキュリティ）：契約の進め方を握る人々である。彼らは、ベンダーとしての存続可能性、セキュリティ態勢、統合の境界、監査可能性、そして最初のパイロットだけでなく数年にわたる総所有コストを重視する。
• スポンサー（推進者）：あなたを組織内に招き入れ、プロジェクトを前に進める内部の擁護者である。彼らは整合性、タイミング、そして「なぜ今、ほかの10個の案件ではなくこれをやるのか？」と問われたときに守りきれる展開ストーリーを重視する。
各役割は「価値」を異なる形で定義する。これらを1つの架空の「顧客」に混ぜ合わせてしまえば、ロードマップは誤る。
スポンサー主導のソリューション構築はこうして始まる
私はこのパターンを繰り返し目にする。
スポンサーが明確な課題定義と、望ましいソリューションの形を携えて連絡してくる。あなたは素早く作る。スポンサーは自分の話が聞き入れられたと感じる。エンドユーザーはデモを気に入る。
そして現実が姿を現す。
実際のワークフローにシステムを組み込もうとすると、誰も言及しなかった例外、文書化されていなかった手順、初期の会話では見えなかった制約が見つかる。すると意思決定者は問う。「これはリスクの露出をどう変えるのか？ どれほどの研修負荷を引き受けるのか？」調達は問う。「このベンダーはセキュリティ審査を通過できるのか？ 長期的なサポート費用はどうなるのか？」
パイロットが止まるのは、4つの役割すべてにわたって導入が設計されていなかったからである。
スポンサーは不可欠だ。誤りは、スポンサーの要望を仮説ではなく要件として扱うことにある。より良い姿勢はシンプルだ。「それは良い出発点です。確定させる前に、実際のワークフローでどこが破綻するのか、何が導入を阻むのかをテストしましょう」
「2つのイエス」ルール
スケール可能なものを得るには、少なくとも独立した2つのイエスが必要である。
エンドユーザーのイエス：「これは私のワークフローに合っていて、実際に感じている負担を軽減してくれる」
意思決定者のイエス：「これは制約の範囲内で大規模に導入でき、私が守りきれる」
オペレーターの支持はあるが意思決定者の整合がないなら、それはデモにすぎない。意思決定者は熱心でも、オペレーターが使うのを嫌がるなら、それはリリース後に静かに消えていく命令である。
医療技術における構造化された導入フレームワークでは、展開を決める前に、エンドユーザーと組織の意思決定者の双方を早期から関与させることが明示的に求められている。両者の不整合は、プロジェクトがパイロットと本番の間で行き詰まる主因の1つだからだ。
今週から使える実践的な導入マップ
大きな開発サイクルにコミットする前に、4つのことを行うべきだ。
1. 役割を明示的に特定する。実際のアカウントについて、具体的なエンドユーザー、意思決定者、バイヤー、スポンサーを書き出す。役職。組織上の位置づけ。彼らが握っているもの。まだ名前を挙げられないなら、それは発見すべきギャップとして扱うべきである。
2. 価値提案は1つではなく4つ書く。役割ごとに、明確な1文を強制する。
• エンドユーザーの価値：時間を節約し、認知負荷を減らし、失敗のパターンを防ぐ。
• 意思決定者の価値：彼らが責任を負う成果とリスク指標を改善する。
• バイヤーの価値：コンプライアンス、セキュリティ、総所有コストの現実に適合する。
• スポンサーの価値：組織内で正当化できる物語を支える。
どの文も曖昧に感じるなら、それは組織を理解していない箇所を示している。
3. スポンサーの要望を検証可能な仮説に変換する。スポンサーが「Xが必要だ」と言ったら、こう試してみる。「それは良い出発点です。作る前に、現場チームと現行プロセスを一緒にたどり、この案がどこで破綻する可能性があるのか、あるいはどこでブロックされるのかを見たいのですが」
4. 追加機能より先に、導入の証拠を作る。機能は、製品が何をするかである。導入の証拠とは、顧客がそれを大規模に受け入れて運用できるというエビデンスである。
例：新規ユーザーが数カ月ではなく数日で生産的になれるトレーニング計画。セキュリティを安心させる1枚ものの統合境界。バイヤーの実際のフレームワークに対応づけたコンプライアンス・チェックリスト。利用が10倍に増えても成立するユニットエコノミクス。
これらは新機能ほど華やかではない。しかし、関心を導入へと変えるのは、まさにこれである。
防衛領域だけの問題ではない
このパターンは、複雑な組織がソリューションを購入するあらゆる場面で現れる。臨床AIを評価する病院、グリッド監視の近代化を進める公益事業者、Fortune 500企業でのエンタープライズ導入。名前は変わる。だがメカニズムは変わらない。
チームは最も声の大きい利害関係者、たいていは最も頻繁に目にするエンドユーザーに最適化し、システムの残りがノーと言うと驚く。
リーダーシップの転換
「顧客は誰か？」と問うのをやめるべきだ。その代わりに、「デモから導入へ進むために、整合が必要な人々は誰なのか？」と問い始めよ。
初日から導入スタックを念頭に設計すれば、単発のデモを作るのではなく、出荷し、更新され、スケールするシステムを作るようになる。オペレーターの支持は会話の終着点ではなく、出発点になる。
