実装は、製品を顧客の環境で稼働させる技術的な作業です。オンボーディングは、顧客を「製品が動く」から「これなしでは生きられない」へと導く価値のジャーニーです。両者は時間軸で重なり、人々は絶えず両者を混同しますが、答える問いが異なり、責任を持つロールが異なり、失敗の仕方も異なります。実装は「設定され、統合され、稼働しているか？」を問います。オンボーディングは「顧客は購入した outcome に到達したか？」を問います。deal は完全に実装されていながら、オンボーディングとして完全な失敗であることがあり得ます。そのギャップこそが、初回更新の churn が生まれる場所です。
区別を正確に
- 実装 は範囲が限定され、技術的で、完了状態がバイナリです。インスタンスをプロビジョニングし、データソースを接続し、統合（SSO、CRM の sync、webhook）を配線し、legacy データを移行し、workspace を設定し、1 つの実際の workflow がエンドツーエンドで動くことを証明します。成功は観測可能で客観的です。配管が機能します。これは scope、statement of work、受け入れテストを持つプロジェクトです。
- オンボーディング はオープンエンドで、outcome 駆動で、完了状態が曖昧です。実装を内包しますが、配管が機能した時点では終わりません。顧客が購入した outcome に自ら到達し（time-to-first-value）、その利用が champion を超えてチームの習慣的な adoption に広がったときに終わります。成功は顧客が「これは価値があった」と言うことであり、実際の価値マイルストーンとして計装されます。
別の言い方をすれば、実装は時間軸においてオンボーディングの部分集合であり、同義語ではありません。実装はオンボーディングのジャーニーの中の 1 つのステージ、すなわち setup ステージです。「実装完了」を「オンボーディング完了」として扱うことは、見せかけの勝利を報告し、その後の更新でアカウントを失う最も一般的な方法です。
それぞれの責任者は誰か
責任の分担こそが、2 つの概念を分ける目的そのものです。両者を混同すると、あるロールが、自分の備えていない仕事を渡されることになります。
| 次元 | 実装 | オンボーディング |
|---|---|---|
| 主たる責任者 | 実装スペシャリスト / solutions engineer / professional services | CSM（またはオンボーディングスペシャリスト） |
| スキルセット | 技術系：API、データ移行、統合、config | 関係 + outcome：success planning、adoption、エグゼクティブのアラインメント |
| 完了状態 | バイナリ — workflow がエンドツーエンドで動く | Outcome — 初回価値に到達、adoption が習慣的 |
| 測定指標 | 期限内・scope 内の納品、ticket の解決 | Time-to-value（TTV）、ステージ 3 の終了、週次アクティブ利用 |
| 時間軸 | 数日から数週間（範囲が限定されたプロジェクト） | 数週間から 1 四半期（アカウントが継続的な CS へ卒業するまで） |
小規模な会社では 1 人が両方の帽子をかぶります。しかし headcount が 1 人であっても ロール は依然として別物であり、作業は 2 つの workstream として追跡すべきです。mid-market と enterprise では分かれます。professional services または実装チームが技術プロジェクトを所有し、CSM がその周りを包む価値のジャーニーを所有します。CSM は実装中を含め常に outcome に責任を持ち続けます。なぜなら、遅延が組織図のどこに属するかは顧客には関係ないからです。
引き継ぎが起きる場所
実装からオンボーディングへの引き継ぎは、顧客ライフサイクルにおいて最もリスクの高い継ぎ目であり、コンテキストが蒸発する場所です。実装チームは技術プロジェクトを終え、ticket をクローズとしてマークし、次のアカウントへ移ります。そして CSM は、顧客が実際に何を達成したかったのかの記録のないまま、設定済みの製品を引き継ぎます。すると顧客は、価値の時計が動き続ける中で、新しい担当者に自分のゴールを再説明することになります。
引き継ぎを暗黙ではなく明示的にしてください。
- success plan を書面で前へ運ぶ。 kickoff で合意した相互の success plan — 顧客自身の成功の定義と、指名されたエグゼクティブ sponsor — が、引き継ぎを生き延びる成果物です。実装は入る際にそれを読み、CSM は出る際にそれを所有します。
- 引き継ぎの trigger を config のゲートではなく価値のゲートとして定義する。 引き継ぎは「config 完了」ではありません。「config 完了 かつ 1 つの実際の workflow が顧客自身のデータでエンドツーエンドに動いた」です。そうすれば CSM は、空の殻ではなく、顧客が実際に価値を築ける何かを引き継ぎます。
- fire-and-forget ではなく合同の移行を行う。 実装と CSM が両方とも顧客との call に同席する短い重なりが、コールドな再起動を防ぎます。CSM は技術的コンテキストを一次情報として聞き、顧客は二度と繰り返しません。
この継ぎ目を両側に見えるようにする tool が存在します。Rocketlane は顧客向けのプランで実装プロジェクトを運営し、受け入れゲートを追跡します。Arrows と Dock は、共有されたオンボーディングプランと成功基準を引き継ぎを越えて可視に保ちます。Gainsight のような CS プラットフォームは、ステージの終了を計装し、アカウントが「実装済み」と「adoption 済み」の間で停滞したときに health-score アラートを発火します。
よくある落とし穴
- 実装の時点でアカウントを完了とみなす。 配管が機能し、ticket がクローズされ、誰も初回価値を確認しません。ガード：プログラムの終了基準は顧客が述べた outcome（オンボーディングのステージ 3）であり、実装の受け入れテストではありません。
- 継ぎ目の間に指名された責任者がいない。 実装は引き継ぎを終え、CSM はまだ引き受けておらず、アカウントが 1 週間、責任者不在のまま放置されます。ガード：あらゆる瞬間に単一の責任を持つ責任者を置き、引き継ぎの日付と責任者を、想定ではなく書面で記します。
- 実装の scope creep が価値の時計を食う。 長い custom 統合が初回価値を数週間先送りにする一方で、全員がプロジェクトを「on track」と報告します。ガード：time-to-value を実装中も走る別個のメトリクスとして追跡し、遅れている統合がプロジェクトの緑ステータスではなく TTV の違反として現れるようにします。
- モデルを純粋な self-serve に無理やり当てはめる。 人手の setup を持たない PLG 製品には、引き継ぎ元となる実装チームがありません。ガード：実装を in-product のアクティベーションに畳み込み、TTV を product analytics で計装します。引き継ぎがないため、管理すべき継ぎ目もありません。
関連
- Customer onboarding — 実装がその中に収まる、完全な 4 ステージのジャーニー
- Time to value — 両者を横断して走るメトリクス
- Customer health score — 停滞した引き継ぎが最初に現れる場所
- Rocketlane — 実装プロジェクトの管理