日本語

導入障壁の特定と除去:利用への道を切り開く

導入障壁の特定と除去:利用への道を切り開く - 2026

Turn this article into takeaways for your work.

Each assistant summarizes the article only for you and suggests best practices for your work.

あるSaaS企業は6ヶ月かけて「完璧な」オンボーディングプログラムを構築しました。トレーニングセッション、ドキュメント、ビデオ、専任のCSM。それでも利用率は予想レベルの35%に留まりました。

彼らがようやく、より多くのトレーニングが必要だと思い込むのではなく、人々が製品を使用しない理由を尋ねたとき、真の障壁が明らかになりました:

「その機能があることを知りませんでした。誰も教えてくれませんでした。」(認識)

「マネージャーが使っていないので、私も使っていません。」(組織)

「ERPシステムとの統合が機能しないので、データ入力を重複させなければなりません。」(技術)

「これが個人的にどう役立つのか分かりません。会社には役立ちますが、私にはより多くの作業を作り出します。」(動機)

「今、複雑な新しいシステムを学ぶ時間がありません。」(能力)

彼らは知識の問題を解決しようとしていましたが、実際の障壁は認識、組織の整合性、技術的摩擦、動機、キャパシティでした。より多くのトレーニングでは、これらのどれも解決できませんでした。

彼らが実際に人々をブロックしているもの—隠れた機能をより見やすくし、利用のための経営者の委任を得て、統合を修正し、会社のROIだけでなく個人のメリットを示し、初期のワークフローを簡素化した—に対処すると、利用率は60日で35%から73%に跳ね上がりました。

より多くのトレーニングのためではありません。実際に邪魔になっているものを除去したからです。

顧客が製品を使用しない理由を理解することは、使用する理由を理解することよりも価値があります。導入とは、意欲的な人を動機づけることではありません。それは他のすべての人のために障壁を除去することです。

導入障壁のタイプ

6つのカテゴリーがほとんどの導入抵抗を説明します。

認識の障壁:「それについて知りませんでした」

顧客は存在を知らない機能を使用できません。

次のようなバリエーションが聞こえます:「待って、製品はそれができるの?」または「手動でこれをやっていました、それ用の機能があるとは知りませんでした」または「誰もこれについて教えてくれませんでした。」

これは、機能がUIでの発見性が低い場合(メニューに埋もれている、ナビゲーションが不適切)、オンボーディングが速すぎて多すぎる場合(人々は言及されたことを忘れる)、機能が発表なしでリリースされる場合、ドキュメントが埋もれている場合、またはCSMがキックオフ中に基本のみに焦点を当てている場合に発生します。

マーケティングオートメーションプラットフォームには、8%の顧客のみが使用する強力なA/Bテスト機能がありました。ユーザーを調査すると、67%がそれが存在することを知らず、21%がそれについて知っていたがアクセス方法を知らず、わずか12%が知っていて使用しないことを選択していました。

実際の問題は機能ではありませんでした。誰もそれがそこにあることを知らなかったことでした。

知識の障壁:「使い方が分かりません」

顧客は機能が存在することを知っていますが、効果的に使用する方法を理解していません。

次のように聞かれます:「これは複雑に見えます」または「一度試しましたが、理解できませんでした」または「何かを壊したくありません」または「これには技術的すぎます。」

通常、不十分または不明瞭なドキュメント、トレーニング中の実践的な練習がない、ガイダンスなしの複雑なUX、人々を混乱させる専門用語または技術用語、例とユースケースの欠如、または圧倒する全か無かの学習アプローチによって引き起こされます。

ある会社のワークフロー自動化機能は高い認識度を持っていましたが(オンボーディングでカバーされていた)、導入率はわずか15%でした。調査すると、ドキュメントが操作ガイドではなく参照マニュアルであることが分かりました。開始するためのテンプレートや例がありませんでした。ユーザーは不正確な自動化の構築を恐れていました。ある人はコメントしました:「それがそこにあることは知っていますが、それを使用するにはコンピューターサイエンスの学位が必要です。」

機能は強力でしたが、学習可能ではありませんでした。

動機の障壁:「価値が見えません」

顧客は機能が何をするかを理解していますが、個人的なメリットが認識されないため気にしません。

これは次のように聞こえます:「なぜ気にする必要があるのですか?」または「現在の方法はうまく機能しています」または「会社には良いですが、私にとって何のメリットがありますか?」または「これをする時間がありません。」

根本原因は通常、価値提案が個人的ではなく組織的である、メリットが即座または明白ではない、後でペイオフのために前もって作業が必要である、変更が追加の負担のように見える、非導入に対する結果がない、または導入に対する認識がないことです。

販売CRMを取ります。経営陣はパイプラインの可視性を望んでいました(組織的価値)。営業担当者はそれを追加のデータ入力(負担)、経営陣の監視(脅威)、クォータ達成の助けなし(個人的メリットなし)と見なしました。

結果は?コンプライアンス導入のみ、最小限の使用、不適切なデータ品質。真の障壁は動機でした。彼らは自分自身にとってメリットがないと見なしたため、望んでいませんでした。

能力の障壁:「今はこれができません」

顧客は導入したいが、スキル、時間、またはリソースが不足しています。

次のように聞かれます:「これを学ぶ時間がありません」または「これを設定するために誰かを雇う必要があります」または「これには自分が持っていない技術的スキルが必要です」または「これを適切に実装するには人手不足です。」

一般的な原因には、高い学習曲線、リソース集約的なセットアップまたは実装、技術的前提条件の欠如、優先順位を取る競合する優先事項、または小さすぎるまたは忙しすぎるチームが含まれます。

高度な分析機能は、カスタムクエリを書くためにSQL知識を必要とし、最初にダッシュボードを設定するために3-4時間を必要とし、クリーンなデータを必要としました(ゴミイン、ゴミアウト)。小規模企業には、SQLを知っているチームメンバーがおらず、それを学ぶ時間がなく、データ品質が混乱しており、アナリストを雇うことを正当化できませんでした。

彼らは価値を望んでいましたが、それにアクセスできませんでした。それは能力の障壁です。

環境の障壁:「組織が許可しません」

個人は導入したいが、組織的要因がそれを防ぎます。

これは次のように聞こえます:「上司が使っていないので、私も使えません」または「ポリシーは古いシステムを使用することを要求しています」または「他の部門は賛同していません」または「得られない経営者の承認が必要です。」

通常、経営者のスポンサーシップの欠如、競合するツールまたはプロセス、部門のサイロ、インフルエンサーからの変更抵抗、組織的委任なし、または文化的抵抗によって引き起こされます。

マーケティングチームがプロジェクト管理ツールを採用しました。しかし、クリエイティブチームはまだリクエストにメールを使用し、財務は予算に別のツールを使用し、マーケティングは部門を超えた導入を強制できませんでした。結果は、断片化されたデータ、重複作業、ツールが助けではなく負担と見なされました。

彼らは孤立して成功できませんでした。それは環境の障壁です。

技術的障壁:「製品が許可しません」

製品自体が導入をブロックする摩擦を作成します。

人々は不満を言います:「遅すぎます」または「クラッシュし続けます」または「UIが混乱しています」または「モバイルで動作しません」または「統合が壊れています」または「機能させるために回避策をしなければなりません。」

一般的な原因は、UXの複雑さまたは不適切なデザイン、パフォーマンスの問題、バグと信頼性の問題、プラットフォームサポートの欠如(モバイル、ブラウザ)、統合の失敗、または人々が実際に働く方法と一致しない柔軟性のないワークフローです。

あるモバイルアプリは、89%のユーザーがリモートで作業しているにもかかわらず、わずか12%の導入率でした。調査すると、アプリが頻繁にクラッシュし、15秒以上のロード時間があり、デスクトップと比較して限られた機能(10倍少ない機能)があることが分かりました。ユーザーはあきらめて試すのをやめました。

製品体験が導入をブロックしました。それは技術的障壁です。

障壁発見方法

実際に導入をブロックしているものを見つける方法。

使用データ分析:使用されていないもの

数字から始めます。

低導入機能を探します:機能Xは、それを試したことがあるユーザーのわずか8%です。機能Yは試した人が23%ですが、30日後もまだ使用している人はわずか9%です。

これらは障壁候補です。何かが導入を妨げています。

高いドロップオフ率(人々が機能を開始するが、ワークフローを完了しない)、短いセッション時間(機能を開き、すぐに離れる)、繰り返し使用なし(一度試して、二度としない)、または低い幅の導入(試す人が少ない)などの行動信号を監視します。

データが教えてくれること:障壁が存在すること、およびそれがどれほど深刻か(何人が影響を受けているか)。

データが教えてくれないこと:なぜ障壁が存在するのか、それがどのタイプの障壁か、またはそれを修正する方法。

次のステップ:顧客と話します。

顧客インタビューとフィードバック

直接会話をします。

低導入者にインタビューします:「あなたが[機能]を使用していないことに気づきました。なぜか教えてください?」

彼らの応答は障壁タイプを明らかにします。「それが存在することを知りませんでした」は認識です。「試しましたが、理解できませんでした」は知識です。「意味が分かりません」は動機です。「ニーズには複雑すぎます」は能力です。「チームが使用していません」は環境です。「バグがある/遅い」は技術です。

このスクリプトを使用します:

  1. 「[機能]について聞いたことがありますか?」(認識チェック)
  2. 「試しましたか?」(アクティベーションチェック)
  3. 「試すこと、または使用を続けることを妨げたものは何ですか?」(障壁の特定)
  4. 「それを使用するために何が変わる必要がありますか?」(ソリューションの発見)

非導入者15-20人にインタビューします。パターンはすぐに現れ、調査だけよりも精度が高くなります。

サポートチケット分析

サポートデータを採掘します。

チケットパターンは障壁を明らかにします。「Xを構成する方法」に関する47枚のチケットは、知識の障壁を示唆しています。「機能が動作しない」に関する33枚のチケットは、技術的障壁を指摘しています。「Xを行う場所が見つからない」に関する28枚のチケットは、認識の障壁を示しています。

チケットのセンチメントにも注意を払ってください。イライラしたトーンは通常、技術的または能力の障壁を意味します。混乱したトーンは知識の障壁を示唆します。無関心なトーンは動機の障壁を示唆します。

解決パターンも見てください。チケットがドキュメントリンクで解決された場合、知識の障壁があります(ドキュメントは存在しますが、人々はそれらを見つけていません)。バグ修正は技術的障壁を指摘します。価値の説明は動機の障壁を示唆します。

チケット分析の利点は?顧客は、尋ねなければならない調査とは異なり、促されずに問題を教えてくれます。

セッション記録とユーザーテスト

人々が実際に製品をどのように使用するかを見ます。

セッション記録(FullStory、Hotjar、LogRocketなどのツール)を使用すると、ユーザーがどこで立ち往生するかを確認し、機能の放棄をリアルタイムで見て、UXの摩擦を特定できます。

混乱の信号には、クリックせずに要素の上にカーソルを置く(何をすべきか分からない)、ランダムにクリックする(迷っている)、同じものを繰り返しクリックする(異なる結果を期待している)、レイジクリック(イライラしている)、または頻繁に後戻りする(間違った道)が含まれます。

放棄の信号は、ワークフローを開始してから途中で停止して離れる、機能を開いてから30秒以上画面を見つめてから閉じる、またはアクションを複数回試してからあきらめるように見えます。

学ぶこと:ユーザーが立ち往生する正確な瞬間(知識または技術的障壁)、混乱させるUI要素(技術的障壁)、複雑さが圧倒する場所(能力の障壁)。

ユーザーテストでは、ユーザーにタスクを与え、彼らがそれを試みるのを見て、声に出して考えるように頼みます。「新しいプロジェクトを作成して、チームに割り当ててください。」

観察:プロジェクトを作成する場所を見つけられますか?(認識)フォームフィールドを理解していますか?(知識)正常に完了しますか?(技術的/能力)「これは混乱しています」とコメントしますか?(直接フィードバック)

調査と投票

大規模で障壁を定量化します。

非導入者にこれらの質問で調査します:

「[製品]に[機能]があることを知っていますか?」(はい/いいえ)

「[機能]を使用してみましたか?」(はい、現在使用しています/はい、試しましたが停止しました/いいえ、試していません)

試していない場合:「[機能]を使用していない主な理由は何ですか?」(1つ選択)

  • それが存在することを知りませんでした(認識)
  • 使い方が分かりません(知識)
  • それが私をどのように助けるか分かりません(動機)
  • 複雑すぎる/時間がかかりすぎる(能力)
  • チーム/マネージャーが使用していません(環境)
  • うまく機能しません(技術)

試したが停止した場合:「[機能]の使用をやめた理由は?」(同じオプション)

次に尋ねます:「[機能]を使用する可能性を高めるものは何ですか?」

  • メリットのより良い説明
  • ステップバイステップのトレーニング
  • よりシンプルなインターフェース
  • より良いドキュメント
  • 同様の会社からの例
  • 経営陣の要件

調査の利点は、顧客ベース全体で障壁の分布を定量化できることです。

CSMの観察とレポート

CSMがすでに知っていることを活用します。

CSMはすべての顧客会話で障壁を聞きます。障壁収集プロセスを設定します。

各顧客コールの後、CSMに記録させます:どの機能が議論されたか、導入ステータス(使用しているか、使用していないか)、特定された障壁(該当する場合)、障壁タイプ(認識、知識、動機、能力、環境、または技術)。

毎週のCSチームミーティングで、記録された障壁をレビューする必要があります:どの障壁が最も一般的か、どの機能が最も多くの障壁を持っているか、どの障壁タイプが支配的か、および顧客セグメント別のパターン。

これがログエントリの例です:

顧客:Acme Corp
機能:ワークフロー自動化
障壁タイプ:知識
メモ:「それを使用したいが、ワークフローを構築する方法を理解していない。ドキュメントではなく、実践的なトレーニングが必要です。」
アクション:トレーニングセッションをスケジュールし、テンプレートライブラリを作成する

CSMレポートは、データだけでは提供できない最前線のインテリジェンスを集約します。

認識の障壁:ソリューション

顧客が機能が存在することを知らない場合。

症状と特定

使用分析を見て、機能を試したことがある人が10%未満であることを示しています。機能がすでにXに存在する場合に「Xを行う方法は?」と尋ねるサポートチケット、人々が「待って、それができるの?」と言うインタビュー、または「それが存在することを知りませんでした」と答える高い割合の調査。

根本原因

機能は、UIに表示されない場合(メニューに埋もれている、ナビゲーションが不適切)、オンボーディングでカバーされない場合(カバーする機能が多すぎる、基本のみが選ばれる)、リリース時に発表がない場合、ドキュメントが適切なタイミングで表示されない場合、または機能の命名が不明確な場合(ユーザーはそれが何をするかを認識しない)に隠されたままです。

ソリューション:教育、コミュニケーション、可視性

機能のハイライトとコールアウト、「新機能」セクション、「これにも[機能]を使用できます」などのコンテキストヒント、および機能の提案を含む検索で、製品内の発見性を向上させます。

機能スポットライトメールキャンペーン、アプリ内アナウンス、使用されていない機能を強調するウェビナーとオフィスアワー、およびCSMのアウトリーチ(「[機能]を探求しましたか?」)を通じて積極的なコミュニケーションを追加します。

機能が何をするかを説明するツールチップ、「あなたが好きかもしれない関連機能」の推奨事項、および「Xをしたいですか?機能Yを試してください」などのユースケースベースのナビゲーションを介してコンテキスト教育を含めます。

ある会社は、機能を強調するアプリ内バナーを追加し、ユースケースの例を含むメールキャンペーンを実行し、CSMがオンボーディングコールでそれを言及するようにトレーニングし、ナビゲーションを更新してそれをより目立たせた後、機能の導入が9%から34%に跳ね上がりました。

製品内発見の改善

機能を見つけやすくします。

ナビゲーションの改善は、メニューの深さを減らすこと(機能に到達するためのクリック数を減らす)、明確な説明的なラベルを使用すること(専門用語ではない)、および関連する機能を論理的にグループ化することを意味します。

可視性の強化には、新しいまたは使用されていない機能を強調すること、段階的な開示(ユーザーが成熟するにつれて高度な機能が表面化する)、およびすべてのコア機能を含むオンボーディングチェックリストが含まれます。

スマートな提案は次のようになります:「あなたがしていることに基づいて、[機能]を試してください」または「あなたのようなユーザーはしばしば次に[機能]を使用します」または「より多くの価値を得るためにこれらのタスクを完了してください。」

知識の障壁:ソリューション

顧客が機能が存在することを知っているが、それらを使用する方法を知らない場合。

混乱と誤解の特定

高いトライアル率だが低い継続使用、「どうすれば...?」と尋ねるサポートチケット、混乱行動を示すセッション記録、高いトレーニング出席だがまだ低い使用、またはユーザーが「複雑すぎます」とコメントすることを監視します。

特定の信号には、機能が開かれてからすぐに閉じられる(混乱し、あきらめた)、ワークフローを完了しようとする複数の試みがあるが、成功したものがない、またはエラーと不正確な使用パターンが含まれます。

ドキュメントとトレーニングのギャップ

ドキュメントの問題は通常、いくつかのカテゴリーに分類されます。

ギャップ1は参照マニュアルの問題です。ドキュメントは機能が何をするかを説明しますが、目標を達成する方法を説明しません。技術的には正確ですが、学習可能ではありません。

これを修正するには、「毎週のレポートを自動化する方法」または「5ステップで最初のワークフローを設定する」または「クイックスタート:10分で結果を得る」などの目標ベースのガイドを作成します。

ギャップ2は例やテンプレートの欠如です。具体的な出発点のない抽象的な説明は、ユーザーがどこから始めるべきか分からないことを意味します。

これを修正するには、ユーザーがカスタマイズできる事前に構築されたテンプレート、同様の会社からの実世界の例、およびビフォーアフター比較を提供します。

ギャップ3は学習への全か無かのアプローチです。一度にすべてまたは何もない、これは前もって圧倒的な複雑さを作成します。

これを修正するには、コンテンツをレベルに分割します:初心者(基本的な使用)、中級(一般的なユースケース)、および上級(パワーユーザーテクニック)。

トレーニングの問題は、しばしばオンボーディング中の1回限りのセッションに起因します。現実は、人々は1週間以内に学んだことの70%を忘れるということです。

これを、基本をカバーする初期トレーニング、Q&Aと高度なトピックのための2週間後のフォローアップセッション、必要に応じたサポートのための継続的なオフィスアワー、および時間をかけて配信される一口サイズのヒント)の分散学習で修正します。

ソリューション:より良い教育、よりシンプルなUX

教育ソリューションには、安全な実験のためのサンドボックス環境を通じた実践的な練習、ガイド付きチュートリアル(ビデオだけでなくインタラクティブ)、および「一緒にフォロー」するライブトレーニングセッションが含まれます。

ジャストインタイムヘルプは、ユーザーが必要とする瞬間のコンテキストツールチップ、機能自体に埋め込まれたビデオチュートリアル、および「これを行うのを手伝って」ウィザードを意味します。

ピア学習は、ユーザーが互いに助け合う顧客コミュニティ、ベストプラクティス共有セッション、および伝道する顧客チャンピオンのように見えます。

UXソリューションには、オプションを減らすことでインターフェースを簡素化すること(段階的な開示)、明確なラベルと指示を使用すること、および視覚的階層(重要なものが目立つ)が含まれます。

インラインガイダンスは、例を示すプレースホルダーテキスト、フィールドレベルのヘルプテキスト、および問題を修正する方法を説明するエラーメッセージを意味します。

ワークフローウィザードは、ステップバイステップのガイド付きセットアップを提供し、各ステップが完了するまでユーザーが進むことを防ぎ(エラーを防ぐ)、進捗を示します(完了を動機付ける)。

ある会社は、最初のワークフロー用のウィザードを追加し、一般的なユースケース用の12のテンプレートを作成し、各ステップでインラインヘルプテキストを追加し、2分間のビデオチュートリアルを埋め込み、月次の「ワークフローオフィスアワー」ウェビナーを実行した後、ワークフロービルダーの導入を14%から51%に増やしました。

ジャストインタイムヘルプとガイダンス

必要な場所と時に助けを提供します。

ユーザーが一度見て忘れる45分間のトレーニングビデオの代わりに、ワークフローにコンテキストヘルプを埋め込みます。ユーザーがワークフローを開始すると、ツールチップが表示されます。立ち往生すると、「助けが必要ですか?」というプロンプトがクイックヒントを提供します。エラーを犯すと、説明と修正方法が表示されます。タスクを完了すると、「もっと学びたいですか?」リンクが高度なガイドに移動します。

利点:実行中に学習が行われる(より良い保持)、摩擦が減少する(ドキュメントを検索するために製品を離れる必要がない)、スケールする(自動化され、CSM依存ではない)。

動機の障壁:ソリューション

顧客が機能を理解しているが、使用することを気にしない場合。

「なぜ気にする必要があるのか」問題の理解

動機の失敗は、会社の価値が個人の価値と等しくない場合に発生します。

時間追跡を取ります。会社はプロジェクトの収益性のためにそれを望んでいます。従業員はそれをマイクロマネジメントと追加の作業と見なし、個人的なメリットはなく、負担のみです。結果は、最小限の導入、不適切なデータ品質、および恨みです。

根本原因?価値提案が間違った聴衆(個人ではなく会社)をターゲットにしています。

これはWIIFM問題です:「私にとって何がありますか?」答えが不明確または不満足な場合、導入は失敗します。

価値提案の明確性

個人のメリットを明白にします。

悪い価値提案(会社に焦点を当てた)は次のように聞こえます:「組織の効率を改善し、リーダーシップのためのより良いレポートを可能にするために[機能]を使用してください。」これは「エグゼクティブがより良いダッシュボードを得られるように余分な作業をする」に変換されます。

良い価値提案(個人に焦点を当てた)は次のように聞こえます:「手動レポート作成を排除する(週4時間節約)ために[機能]を使用し、あなたの進捗を自動的に追跡して、あなたの影響を証明できるようにします。」これは「より少ない作業をして、より良く見える」に変換されます。

時間の節約(より少ない作業)、獲得した認識(貢献の可視性)、回避された問題(防止された間違い)、キャリアの進歩(開発されたスキル、証明された結果)、または自律性の増加(データが説明責任を提供するため、監視が少ない)としてメリットをフレーム化します。

ソリューション:より良いポジショニング、価値の証明

「これは会社を助けます...」から「これは個人的にあなたを助けます...」への価値提案を再フレーム化します。

CRM導入の場合、古いピッチは「経営陣が収益を予測できるように機会を入力してください」でした。新しいピッチは「機会を追跡して、取引を見失わないようにし、パイプラインのサイズを証明し、取り組んでいるすべてのものに対してクレジットを得ることができるようにします」になりました。

理論ではなく、証明を示します。「これは時間を節約します」の代わりに、「サラは先週これを使用して6時間節約しました。方法は次のとおりです。」と言います。

証明形式には、顧客の声(それが助けたと言う仲間)、ビフォーアフター比較(具体的な結果)、時間節約計算(数学を示す)、および成功事例(実際の例)が含まれます。

動機は速く価値を見ることを必要とするため、クイックウィンのために導入を構成します。1日目:即座のメリットを提供するシンプルなタスク。1週目:最初の具体的な結果。1ヶ月目:測定可能な改善。

レポートツールの場合、これは次のようになる可能性があります:1日目は10分で最初の基本レポートを作成すること(クイックウィン)。1週目は手動スプレッドシートを自動レポートに置き換えること(時間節約)。1ヶ月目はツールを通じてのみ可能な洞察でエグゼクティブチームにプレゼンテーションすること(キャリアウィン)。

早期の勝利は動機の勢いを作成します。

インセンティブと認識

導入のための肯定的な結果を作成します。

外発的動機には、認識(リーダーボード、バッジ、叫び)、報酬(パワーユーザー用のスワッグ、ギフトカード)、および競争(最高の導入を持つチームが勝つ)が含まれます。

内発的動機は、習熟(新しいスキルの学習)、自律性(より良いツールを通じた制御)、および目的(チームの成功への貢献)に訴えます。

経営陣の強化は、エグゼクティブが製品を目に見えるように使用すること、1対1で議論される使用、追跡され祝われる導入メトリクス、および結果を持つ非導入(期待が設定される)のように見えます。

ある販売チームは、営業担当副社長がミーティングでCRMを公に使用し、毎週のリーダーボードがトップユーザーを示し、月間担当者がCRMデータを使用して結果を証明することを要求し、非ユーザーがデータなしでクォータレビューに参加できない場合に、導入が40%から84%に跳ね上がりました。

能力の障壁:ソリューション

顧客が導入したいが、できない場合(スキル、時間、リソース)。

スキルとリソースの制約

一般的な能力のギャップには、スキルのギャップ(機能がユーザーが持っていない技術知識を必要とする、スキルを開発する時間やリソースがない、忙しいユーザーには学習曲線が急すぎる)およびリソースのギャップ(実装がユーザーが持っていない専用の時間を必要とする、利用可能ではない追加のツール/システムが必要、達成するのが難しいチーム調整が必要)が含まれます。

高度な分析にはSQLが必要でした。アナリストのいない小規模チームは、SQLスキルがなく、それを雇うことができず、十分に速く学ぶことができなかったため、それを採用できませんでした。それは能力の障壁です。

技術的前提条件

隠された要件が導入をブロックします。

一般的な前提条件には、クリーンなデータ(データが混乱している場合、機能が機能しない)、統合(システムが接続しない場合、機能は役に立たない)、インフラストラクチャ(十分なライセンス、適切な権限)、およびプラットフォームの互換性(デスクトップでは機能するがモバイルでは機能しない)が含まれます。

発見の質問:「これを正常に使用する前に何が必要ですか?」

ソリューション:簡素化されたワークフロー、より良いイネーブルメント

バーを下げることで複雑さを減らします。「シンプルモード」と「アドバンストモード」を作成し、技術的機能の代わりにノーコードの代替案を提供し、テンプレートと事前に構築された構成を提供します。

SQL障壁の場合、ある会社はビジュアルクエリビルダー(SQLは不要)を構築し、20の事前に構築されたレポート(パラメーターをカスタマイズするだけ)を作成しました。分析の導入は18%から62%に跳ね上がりました。

高価値で高複雑性の機能の場合、CSMが最初に顧客のためにそれを設定する、構成サービスを提供する、またはマネージドサービス階層を提供する、あなたのためにやってくれるサービスを検討してください。

全か無かを要求しないでください。フェーズ1は基本的な使用(低い努力、迅速な価値)です。フェーズ2は中級(快適になったら)です。フェーズ3は高度(時間をかけて)です。

マーケティングオートメーションの場合、これは次のようになる可能性があります:フェーズ1は事前に構築されたメールキャンペーン(カスタマイズするだけ)です。フェーズ2はカスタムメールを構築することです。フェーズ3は複雑な自動化ワークフローです。能力が成長するにつれて複雑さが徐々に増加します。

段階的な複雑さの導入

段階的な開示戦略を使用します。

1週目は本質のみである必要があります:3つのコア機能のみ、シンプルなワークフロー、事前に構成されたセットアップ。

1ヶ月目は、基本をマスターしたら中級機能を追加します。まだガイドされており、テンプレートがまだ利用可能です。

3ヶ月目以降は高度な機能をアンロックします:パワーユーザー機能、完全な柔軟性とカスタマイズ。

利点は、圧倒することは決してないということです。段階的に能力を構築します。

環境の障壁:ソリューション

個人は喜んでいるが、組織が導入を妨げる場合。

組織的抵抗

一般的なパターンには、リーダーシップが製品を使用していない(上司が使用しない場合、チームはそれを優先しない、経営者のスポンサーシップの欠如)、サイロ(ある部門が採用し、他の部門が採用しない、部門を超えた機能のワークフローが故障する)、競合するツール(異なるチームが同じ目的のために異なるツールを使用する、データの断片化、どのツールが「公式」か不明確)、および変更抵抗(「常にこのようにやってきました」、政治と縄張り保護)が含まれます。

プロセスとポリシーの制約

例には、製品がサポートしていない特定のプロセスを要求するコンプライアンス、特定の統合をブロックするITポリシー、拡大を妨げる調達ルール、または完全な展開を妨げる契約制限が含まれます。

発見の質問:「完全な導入を妨げる組織的要因は何ですか?」

ソリューション:ステークホルダーのエンゲージメント、変更管理

エグゼクティブレベルでROIを実証し、エグゼクティブをチャンピオンにし、エグゼクティブに使用を義務付けさせる(トップダウンの強化)ことで、リーダーシップの賛同を得ます。

エグゼクティブのアクションには、ミーティングで製品を公に使用すること、製品を介して報告することをチームに要求すること、導入目標を設定してそれらを追跡すること、および競合するツールを削除することが含まれる必要があります。

マーケティングオートメーションの導入は、CMOがプラットフォームを介してすべてのキャンペーンレポートを要求し、エグゼクティブミーティングでプラットフォームダッシュボードを使用し、Q2で80%の導入の目標を設定するまで35%で停滞していました。彼らは79%を達成しました。

成功のために誰が採用する必要があるかをマッピングし、各部門から賛同を得て、共有された目標とプロセスで整合させることで、すべてのステークホルダーを関与させます。

あるCRMは、営業がそれを採用したが、マーケティングがリードをそれに同期しなかったときに失敗しました。それは、彼らがリードプロセスについて合意し、両方の部門がコミットした共同の営業-マーケティングキックオフの後に成功しました。

5つのツールが同じことをしている場合は成功できません。1つのプラットフォームに統合し、レガシーツールを廃止し、データとユーザーを移行し、新しいツールを公式の記録システムにします。

経営者のスポンサーシップ

なぜそれが重要か:重要性を示します(エグゼクティブが気にする場合、チームは気にする)、組織的障壁を除去し、リソースと優先度を提供し、説明責任を強制します。

それを確保する方法:ビジネスケースを構築します(ROI、戦略的価値)、エグゼクティブにプレゼンテーションします(中間レベルだけでなく)、公的なコミットメントを得て、定期的なエグゼクティブのエンゲージメントを維持します(賛同を得て消えるだけではありません)。

経営者のスポンサーシップのアクションには、プロジェクトを個人的にキックオフすること、導入の進捗に関する月次チェックイン、高導入者を公に認識すること、およびチームによってエスカレートされた障壁に対処することが含まれる必要があります。

技術的障壁:ソリューション

製品自体が導入をブロックする場合(UX、パフォーマンス、バグ)。

UXの摩擦と複雑さ

一般的なUX障壁には、タスクを完了するためのクリック数が多すぎる、混乱したナビゲーション、不明確なラベリング、一貫性のないパターン、不適切なモバイル体験、および圧倒的な数のオプションが含まれます。

発見方法には、セッション記録(ユーザーが苦労するのを見る)、ユーザーテスト(摩擦ポイントを観察する)、「Xを行う方法」に関するサポートチケット、および完了までの時間メトリクス(遅いことは摩擦を意味する)が含まれます。

パフォーマンスと信頼性の問題

技術的問題は導入を殺します。

パフォーマンスの問題には、遅いロード時間(5秒以上)、ラギーなインタラクション、およびワークフロー中のタイムアウトが含まれます。

信頼性の問題には、頻繁なクラッシュ、データ損失、機能しない機能、および失敗する統合が含まれます。

ユーザーの応答:試すのをやめます。イライラしすぎます。

ソリューション:製品の改善、回避策

理想的なソリューションは、UXの改善を優先し、パフォーマンスのボトルネックを修正し、バグを解決し、信頼性を改善することで製品を修正することです。

現実?製品の改善には時間がかかります。

暫定ソリューションには、既知の問題とそれらを回避する方法を文書化すること、代替アプローチを提供すること、およびCSMが摩擦をナビゲートするのを助けること(回避策)が含まれます。製品が改善されるまで、CSMが顧客のために困難な部分を一時的に行うマネージドサービスを提供することもできます。

制限について透明であること、修正のタイムラインにコミットすること、および進捗について顧客に情報を提供し続けることで期待を管理します。

CSMは顧客の声であるため、データを使用して導入をブロックする問題をエスカレートします:何人の顧客が影響を受けているか、導入と保持への影響、リスクにさらされている収益、および競争上の不利益。

CSMから製品チームへのエスカレーション

効果的なエスカレーションプロセスを実行します。

問題を文書化します:何が壊れているか困難か、何人の顧客が影響を受けているか、導入への影響(使用データ)、回避策(ある場合)、および顧客の引用(実際の声)。

ビジネスへの影響を定量化します:修正されない場合のリスクにさらされているARR、ブロックされた拡大機会、解約の可能性、および競争上の損失。

証拠を持って製品チームに提出し、優先順位付けを要求し、タイムラインへのコミットメントを得ることで、緊急性を持ってエスカレートします。

進捗について顧客を更新し、影響を受けた顧客と修正をベータテストし、ソリューションが機能することを検証し、解決を伝えることでループを閉じます。

CSMとしてのあなたの仕事は、顧客をブロックするものを表面化することで製品をより良くすることです。

障壁の優先順位付けとアクション計画

複数の障壁が見つかります。すべてを一度に修正することはできません。

影響対労力マトリックス

4つの象限を使用して障壁除去に優先順位を付けます。

象限1は高影響、低労力(最初に実行)です。これらは多くの顧客に影響を与え、修正が簡単です。クイックウィン。メニューに埋もれている機能を目立つ場所に移動すると、高影響(多くの顧客がそれを見つけられない)および低労力(UIの変更のみ)があります。すぐに実行してください。

象限2は高影響、高労力(計画と実行)です。これらは多くの顧客に影響を与えますが、修正が難しいです。戦略的イニシアチブ。技術的専門知識を必要とする機能のノーコードバージョンを構築すると、高影響(能力の障壁が導入をブロックする)および高労力(重要な製品開発)があります。次の四半期にロードマップを作成します。

象限3は低影響、低労力(あれば良い)です。これらは少数の顧客に影響を与えますが、修正が簡単です。キャパシティがある場合に実行します。ニッチ機能の不明確なドキュメントを書き直すと、低影響(使用する人が少ない)および低労力(ドキュメントのみ)があります。バックログに入れて、時間があるときに実行します。

象限4は低影響、高労力(実行しない)です。これらは少数の顧客に影響を与え、修正が困難です。価値がありません。エッジケース機能リクエストのカスタム開発は、低影響(1-2人の顧客)および高労力(エンジニアリング月)があります。延期または辞退します。

クイックウィン対戦略的イニシアチブ

クイックウィン(0-30日)には、コミュニケーションの修正(認識の障壁)、ドキュメントの改善(知識の障壁)、UIの調整(技術的障壁)、およびCSMプロセスの変更(環境の障壁)が含まれます。

戦略的イニシアチブ(3-6ヶ月)には、製品UXのオーバーホール、能力の障壁を減らすための新機能、組織的変更管理プログラム、およびプラットフォームのパフォーマンス改善が含まれます。

両方のバランスを取ります。クイックウィンは勢いを維持します。戦略的イニシアチブは深い問題を解決します。

所有権と説明責任

各障壁タイプに所有者を割り当てます。認識の障壁はマーケティングまたはCS Opsに行きます。知識の障壁は教育またはイネーブルメントに行きます。動機の障壁はCSリーダーシップまたは製品マーケティングに行きます。能力の障壁は製品または教育に行きます。環境の障壁はCSリーダーシップまたは販売に行きます。技術的障壁は製品またはエンジニアリングに行きます。

所有者にタイムラインにコミットさせ、定期的なステータス更新を提供し、導入メトリクスを通じて障壁の削減を測定することで進捗を追跡します。

測定と検証

障壁が除去されたことをどのように知りますか?

前:機能Xは12%の導入率です。障壁は認識です(67%がそれが存在することを知りませんでした)。

アクション:アプリ内アナウンス、メールキャンペーン、CSMがコールで言及。

後(60日後):機能Xは34%の導入率です。調査は認識が81%に増加したことを示しています。

検証:障壁が減少し、導入が増加しました。成功。

測定を続けます。障壁が修正されたと思い込んで進まないでください。時間をかけて追跡します。導入が成長するにつれて新しい障壁が現れる可能性があります。

結論

導入は、顧客が怠惰または不本意であるために失敗するのではありません。障壁が彼らをブロックするために失敗します—あなたが特定して除去できる障壁。

障壁を体系的に特定して除去するチームは、50-70%高い機能導入(導入が起こることを望むのではなく)、30%速い価値までの時間(早期に除去された障壁)、25%少ないサポートチケット(除去された摩擦)、およびより高い保持(アンロックされた価値の実現)を達成します。

障壁を無視してトレーニングにより強く押すだけのチームは、より多くの教育にもかかわらず停滞した導入、イライラした顧客とCSM、間違ったソリューションに浪費されたリソース、および防止可能な解約を経験します。

基本:6つの障壁タイプ(認識、知識、動機、能力、環境、技術)。それぞれには異なるソリューションが必要です(より多くのトレーニングは認識や動機を修正しません)。データと顧客会話を通じて障壁を発見します。最高の影響、最低の労力を最初に優先します。障壁が実際に除去されたことを検証するために測定します。

障壁の特定と除去プロセスを構築します。あなたの導入はそれに依存しています。


導入をブロックしているものを除去する準備はできましたか?導入の基本製品導入フレームワーク、および機能導入戦略を探索してください。

もっと学ぶ:

About the author

Tara Minh

Tara Minh

Senior Operations & Growth Strategist

Tara Minh is Senior Operations & Growth Strategist at Rework, helping B2B SaaS leaders scale without breaking their teams. With 8+ years in revenue operations and process optimization, Tara turns messy workflows into systems people actually follow. Readers get practical frameworks they can use to cut waste, align teams, and grow on purpose.