Salesforce導入が8割失敗する本当の理由—曹操軍が教える「定着しない組織」の構造

使われないSalesforceが、今日も起動している

会議室のプロジェクターに、Salesforceのログイン画面が映し出される。

営業部長が静かに言う。「みなさん、先月の入力状況を確認しましょう」。沈黙。パイプラインの更新率は32%。残りの68%は、誰かのExcelの中にある。。。

導入から14ヶ月が経っていた。

ライセンス費用は年間800万円。導入コンサルへの支払いは別途1,200万円。合計2,000万円のシステムが、週に一度ログインされるだけの「報告用ツール」になっていた。そして誰もその現実を、声に出して指摘しなかった。

私はそのプロジェクトのPMOとして、その会議室にいた。

これは特殊な事例ではない。

Salesforceの国内導入案件を長く見てきた実感として、「導入したが定着しなかった」という結末は、例外ではなくデフォルトに近い。華々しいキックオフがあり、ベンダーによるトレーニングがあり、Go-liveの記念日がある。そして静かに、誰も使わなくなる。

問題はSalesforceではない。

問題は、なぜ組織がCRMを拒絶するのかを、誰も正面から語らないことだ。ベンダーは機能の話をする。コンサルはプロセスの話をする。経営層はROIの話をする。しかし現場のPMが見ているのは、もっと根深い何かだ。

人が変わることへの抵抗。情報を手放すことへの恐怖。入力という名の余計な仕事。そして「なぜこれをやるのか」という問いに、誰も答えてくれない現実。

1,800年前、曹操はまったく同じ問題に直面していた。

10万を超える兵を率い、複数の戦線を同時に管理し、刻々と変わる戦況を正確に把握しなければならなかった。情報が遅れれば軍が死ぬ。報告が歪めば判断が狂う。組織が情報を隠せば、指揮系統が崩壊する。

曹操軍がそれを解決した方法は、テクノロジーではなかった。

人の動機と、組織の構造を設計し直すことだった。

その原則は、今日のSalesforce導入プロジェクトにそのまま適用できる。そしてその原則を知らずに導入を進めるかぎり、何度でも同じ失敗を繰り返す。

本稿はその構造を、PMOの実務経験と三国志の組織論を重ねながら解体する試みだ。

曹操軍は、なぜ情報を制したのか

建安元年（西暦196年）。

曹操は献帝を擁立し、許を新たな都と定めた。この決断の意味を、多くの歴史書は「政治的正統性の獲得」と読む。しかし私はもう一つの意味を見る。情報の集約点を、意図的に設計したということだ。

天子の名のもとに諸侯へ命令を下す。各地の戦況報告が許に集まる。人材の推薦と登用が一箇所で管理される。曹操が構築したのは、乱世における最初期の「統合情報管理システム」だった。

現代の言葉で言えば、CRMである。

荀彧という名のシステム管理者

曹操軍の情報管理を実質的に担ったのは、荀彧だった。

彼の役職は「尚書令」。
今日で言えば、COOとCIOを兼任したような立場だ。前線で曹操が戦う間、荀彧は許で政務を執り、人材を発掘し、補給を管理し、各地からの情報を整理して曹操に届け続けた。

荀彧がいなければ、曹操の戦略は机上の空論で終わっていた。

なぜか。どれだけ優れた戦略も、実行を支える情報インフラがなければ動かないからだ。郭嘉の天才的な先読みも、曹操の決断力も、荀彧が整備した情報の流れの上に乗っていた。

これはSalesforceの構造と同じだ。

フロントの営業が動き、マネージャーが判断し、経営が戦略を描く。その全員の動きを支えるデータの流れを設計し、維持し、品質を保ち続ける役割。
それがSalesforceであり、荀彧だった。

情報を持つ側が、戦略を握る

官渡の戦い（西暦200年）の直前、曹操軍は深刻な兵糧不足に陥っていた。

袁紹の10万の大軍に対し、曹操の兵力は3分の1以下。さらに補給が続かないとなれば、撤退以外に選択肢はないように見えた。しかしこの局面で、曹操は袁紹軍の補給基地・烏巣を奇襲するという賭けに出る。

この判断を可能にしたのは、情報だった。

烏巣の守備が手薄であること。袁紹が優柔不断で、奇襲への迅速な対応が苦手であること。そして自軍の兵糧が底をつく前に決着をつけなければならないこと——これらの情報が正確に把握されていたから、曹操は動けた。

情報なき決断は、博打だ。情報ある決断は、戦略だ。

現代のSalesforce導入プロジェクトでも、この原則は変わらない。パイプラインのデータが正確であれば、どの案件に営業リソースを集中すべきかが見える。顧客の接触履歴が蓄積されていれば、次の一手が読める。失注理由が記録されていれば、同じ失敗を繰り返さない。

Salesforceは武器ではない。情報インフラだ。そしてインフラは、使われなければただの建造物になる。

なぜ曹操軍の情報システムは機能したのか

ここで一つ、重要な問いを立てる。

荀彧が整備した情報管理の仕組みは、なぜ機能したのか。兵士たちはなぜ、正確な情報を報告し続けたのか。

答えは三つある。

一つ目は、情報を報告することが「兵士自身の生存」に直結していたからだ。不正確な報告は戦場での判断ミスを生み、それは味方の死を意味した。入力の動機が、個人の損得と組織の目標に一致していた。

二つ目は、曹操自身が情報を使って意思決定する姿を、組織全体が見ていたからだ。報告が戦略に反映され、報告した兵士の功績が正当に評価された。「報告しても何も変わらない」という絶望が、組織に蔓延していなかった。

三つ目は、荀彧が情報の「入口」と「出口」を設計したからだ。何を報告するか、どの形式で、どのタイミングで——これが標準化されていたから、情報の品質が保たれた。

この三つが揃っていないSalesforce導入プロジェクトは、必ず失敗する。

動機の設計。意思決定への反映。入力プロセスの標準化。ツールの問題ではなく、組織設計の問題だ。曹操軍が1,800年前に解いた問いを、私たちは今も解けていない。

そして現代の「荀彧」は、どこにいるのか

Salesforce導入プロジェクトには、荀彧が必要だ。

フロント営業でも、ITベンダーでも、経営層でもない。情報の流れを設計し、品質を維持し、現場と経営の間でデータを翻訳し続ける役割——それがPMOであり、本来のSalesforce管理者の姿だ。

しかしほとんどの導入プロジェクトで、荀彧の役割は空白のまま放置される。

ベンダーはGo-liveで仕事を終える。ITは技術的な保守をする。営業は入力を嫌がる。経営はダッシュボードを眺める。その誰もが「情報の流れを設計する」という荀彧の仕事を、自分の役割だと思っていない。

これが、8割の導入が失敗する構造的な理由の、一番深いところにある根だ。

次のセクションでは、この根がどのように具体的な失敗パターンとして現れるかを解体する。

Salesforce導入が失敗する、3つの構造的理由

「ツールが悪い」と言う人がいる。

「現場が協力しない」と言う人がいる。「予算が足りなかった」と言う人もいる。しかしPMOとして複数の導入プロジェクトを見てきた経験から言えば、失敗の理由はほぼ例外なく同じ場所にある。

ツールでも、現場でも、予算でもない。

導入を「イベント」として扱い、「プロセス」として設計しなかったことだ。

曹操軍の情報管理が機能し続けたのは、荀彧が「仕組みを作り続けた」からだ。Go-liveというゴールテープを切って終わりにしたのではなく、情報の流れを日々設計し、維持し、改善し続けた。その継続性が、組織の継戦能力を支えた。

Salesforce導入の失敗は、この継続性の欠如から始まる。そしてその欠如は、三つの構造的な理由によって引き起こされる。

理由① 経営層の関与が、Go-live後に消える

キックオフ時、経営層は必ず熱心だ。

「これで営業の可視化ができる」「データドリブンな組織になる」——そういった言葉が飛び交い、プロジェクトは華やかに始まる。しかしGo-liveを境に、経営層の関与は急速に薄れる。次の優先事項へ移動し、Salesforceは「ITの管理するシステム」へと格下げされる。

曹操が前線に出た後、許の政務を荀彧に完全に委任しながらも、重要な意思決定には必ず戻ってきたことを思い出してほしい。曹操は「委任」と「放棄」を明確に区別していた。

経営層がSalesforceから手を引いた瞬間、現場は察する。

「これは本気のプロジェクトではない」と。その認識が広がった組織で、入力率が上がることはない。

理由② 現場の「入力コスト」が、設計段階で無視される

営業担当者にとって、Salesforceへの入力は本来業務ではない。

顧客と話し、提案書を書き、クロージングする——それが彼らの仕事だ。その合間に、商談の詳細をシステムに入力することを求められる。しかも入力項目が多く、UIが直感的でなく、モバイルで使いにくい。

郭嘉の言葉を借りれば「兵士に余計な荷物を持たせれば、行軍速度が落ちる」だ。

現場の入力コストを設計段階で真剣に検討したプロジェクトを、私はほとんど見たことがない。ベンダーは機能を詰め込み、管理者は項目を増やし、経営は「全部入れてほしい」と言う。その結果、誰も使わないシステムが完成する。

理由③ KPI設計が、現場の行動を歪める

「Salesforceの入力率を月次KPIに設定しました」

この瞬間、プロジェクトは別の失敗モードに入る。

入力率を上げることが目的化した組織では、営業担当者は「入力しやすい案件」を優先し、「入力が面倒な案件」を後回しにする。数字は改善するが、データの品質は劣化する。そして品質の低いデータから導き出された戦略は、現実と乖離する。

曹操軍で言えば、「戦勝報告の数」をKPIにした結果、兵士が勝てる小競り合いだけを選んで戦うようになった——という構造だ。測定する対象が変わると、人の行動が変わる。そしてその行動変容が、組織全体を歪める。

KPIは武器だ。設計を誤れば、味方を傷つける。

3つの理由が重なるとき、組織は静かに崩壊する

この3つが同時に起きているプロジェクトを、私は何度も見た。

経営層は関与をやめ、現場は入力を避け、KPIは歪んだ数字を報告し続ける。ダッシュボードの数字は改善しているように見える。しかし実態は、誰も信頼しないデータが蓄積されているだけだ。

そしてある日、誰かが言う。「Salesforce、やっぱり使いにくいですよね」と。

問題はツールではなかった。最初から、ずっと。

ここまでが、失敗の「診断」だ。

では、どう防ぐか。PMOとして、何をいつ、誰に対してやるべきか。ここから先は、この3つに加えてさらに2つの失敗パターンを解体し、それぞれに対する具体的な介入手順を示す。

2,000万円のシステムを「報告用ツール」で終わらせないために。