私たちの失敗談

Marooについて、「完璧主義で、ミスをしない会社」「失敗が許されない組織」という印象を持たれる方もいるかもしれません。

しかし実際の私たちは、これまで数多くの失敗を経験してきました。

現在の社内の取り組みや制度、オペレーションの多くは、そうした失敗を起点に生まれたものです。

うまくいかなかった原因を振り返り、言語化し、仕組みとして組み直す。その積み重ねが、今のMarooを形づくっています。

ここでは、私たちが経験してきた失敗の中から、いくつかをご紹介します。

かなり以前の事例も含まれており、現在の体制とは異なる点もありますが、失敗とどう向き合い、学びに変えてきたのかというプロセス自体は、参考にしていただけるはずです。

私たちは、決して完璧な会社ではありません。

これからも失敗を重ねるでしょう。それでも、失敗を隠さず、学びに変え、社員とともに進化し続ける組織でありたいと考えています。

失敗1：KPIを「量」に寄せすぎて、商談化率を下げてしまった

新規接点数・架電数・Eメール送信数などの“量”が伸びているのに、SQLと受注が伸びない——。ある立ち上げ直後の案件で、私たちはKPI設計を活動量に偏らせ、パイプラインの健全性（到達率・速度・歩留まり）の可視化と学習サイクル設計が後手に回りました。結果、Tierや案件成熟度に応じた配分が崩れ、商談化率が低下しました。
どう改めたか

• KPIをパイプライン健全性中心（各ファネルの到達率・滞留日数・歩留まり）へ再設計

• ダッシュボードの読解基準を会議体で標準化し、“次の仮説”を必ず定義して検証→改善をルーチン化

• Outreach／Salesforceのデータ粒度を揃え、活動→成果の因果チェーンで見直し
  この一件以降、私たちはKPIを「再現性を学習するための設計図」と定義し、設計と運用をセットで提供する体制に統一しています。

失敗2：Salesforceのスキーマ変更が現場運用に波及し、データ欠損を招いた

新しい評価軸を早期に反映しようと、Salesforceのオブジェクト／フィールドを拡張したところ、Outreach連携の前提と食い違い、計測が一時不整合に。データの完全性が崩れ、振り返りの精度が落ちました。
どう改めたか

• 変更管理（Change Management）を制度化：事前影響分析→承認→Sandbox検証→段階リリース

• 命名規約・データ辞書・利用境界（必須／任意、入力主体、更新トリガ）を整備

• Data QAを自動・準自動で常時監視（重複率・入力率・同期エラー）
  以後は「設計→実装→検証→定着」を一体提供する“インサイドセールスエンジニアリング”での実装統括を原則とし、構造と運用の乖離を抑えています。

失敗3：ICP／Tierとシーケンス設計がズレ、接点の“質”が下がった

ICP再定義の途中で暫定Tierを運用に回した結果、Outreachのシーケンスが優先すべきターゲットに十分当たらず、高反応セグメントでの接点密度が希薄化。短期的にリーチは伸びたものの、学習効率が悪化しました。
どう改めたか

• ICP・Tier・スコアリングを先に合意し、シーケンス設計の前提として固定

• 接点頻度・チャネル配分・停止/再開条件を明文化し、変更管理の対象に

• 検証カレンダーを設け、テンプレートのAB検証→採択→標準化のリズムを固定
  Salesforceの属性・行動データを前提に、Outreachでファネル上の意図に沿った配信・同期・検証を回すのが、現在の標準です。

失敗4：意思決定の“場”を設計せず、会議体が機能不全に陥った

週次レポートは整っているのに、必要な意思決定がされない——。担当者レベルの議論に終始し、稟議ラインや評価基準が会議体で揃っていなかったため、優先順位が毎週入れ替わり、実装は停滞しました。
どう改めたか

• 会議体の設計（参加者・合意事項・判断基準・SLA）を先に定義

• MCP（Mutual Close Plan）でマイルストーンと責任を可視化

• DSR（Digital Sales Room）を使い、改訂履歴と合意内容を「見える化」
  現在は、MCP／DSRを“合意の器”として活用し、仮説と意思決定の往復を短サイクルで回す運用が定着しました。

失敗5：BPO立ち上げでSOPが未成熟、品質のばらつきが発生

立ち上げスピードを優先し、SOP／レビュー基準の整備より先に稼働を拡張。担当者ごとに運用の解釈が分かれ、入力基準・停止条件・引き継ぎの抜け漏れが発生しました。
どう改めたか

• Playbook（Day1-3／週次運用）とレビュー基準をセットで標準化

• Enablementで習熟度・入力率・活用率を評価指標に設定し、再訓練ループを常設

• 「設計チーム≒運用チーム」ではなく、ディレクターが実装と定着の両面を統括
  これにより、BPOの“作業”をプロセス資産として蓄積し、再現性と生産性を両立する運用へ移行しました。

失敗6：成果物偏重で“動く仕組み”に落とし切れなかった

良質な戦略資料や要件定義を納めても、翌日から現場が動けない——。過去、納品物の完成度は高いのに運用定着の設計が薄く、「移管後にすぐ運用できる状態」を満たさなかった案件がありました。
どう改めたか

• 納品の定義を「資料」ではなく「運用”開始”」に変更

• 実装手順・検証設計・トレーニング計画・ダッシュボードの読み方まで一体納品

• 30/60/90日の定着レビューを標準プロセス化
  以降、私たちは「戦略→実装→検証→定着」を統合するサービスとして提供し、“翌日から動く形”で移管することを徹底しています。

私たちが失敗から学んだこと

• 合意設計は成果設計です。会議体・稟議・判断基準を先に設計し、仮説の学習速度を高めます。

• データ完全性が再現性を支えます。スキーマ／命名／変更管理／QAを運用と同列で扱います。

• 道具は方法論に従います。Salesforce×Outreach×運用ルールを、KPIモデルに直結させます。

• 納品はスタートライン。“動く仕組み”に落ちるまでをサービスの範囲とします。

私たちは、失敗を出発点にプロセスを強化してきました。今もインサイドセールスエンジニアリング（Consulting／Enablement／BPO／Engineering を一体提供）で、再現性と生産性を同時に引き上げる支援を標準化しています。

付記：読者（SaaS営業・IS経験者）の方へ

• KPIを変える前に、会議体を変える。ここから劇的に改善するケースが最も多いです。

• “量→質→再現”の順で設計する。ICP／Tier→シーケンス→検証→標準化が王道です。

• データ辞書とSOPは最初の資産。立ち上げ初月から作り込みます。

失敗は避けられません。ただし、繰り返さない仕組みは設計できます。Marooはその設計と実装に責任を持って伴走します。