誰も入力しない項目と、誰も見ないレポートだけが増えていく ── BizOpsが社内に閉じることのデメリット
株式会社テイクアステップの祖川です。
御社に、あるいは皆さん自身に、こんな状態はありませんか？
- 声の大きい人から降ってきた要望が、そのまま今月の開発リストになっている
- 「これ、Salesforceで見られるようにできない？」と言われて、「承知しました」と即答している
- 情報収集といえば、SaaSベンダーのオウンドメディアと、きれいにまとまった導入事例記事
- リリースするたびに感謝はされる。でも、事業の数字が動いた実感はない
- 気づけば、誰も入力しない項目と、誰も見ないレポートだけが増えている
一つでも心当たりがあるなら、この記事はきっとお役に立てます。
そして、もし経営者の方が読んでくださっているなら、この記事は**「なぜ、うちのSalesforceには数字が集まらないのか」**の話でもあります。その答えは、担当者の能力ではなく、判断の基準がどこに置かれているか、にあります。
今回お話ししたいのは、BizOpsという仕事が「社内」に閉じてしまうことの怖さです。
結論を先に書きます。
外に出て、情報を取りに行ってください。ただし、その取り方には気をつけてください。
この2つはセットです。外に出たつもりで、実は誰かの意図が乗った情報を飲まされているケースが、本当に多いからです。
念のため、BizOpsという言葉についても触れておきます。
概念としてのBizOpsは、「事業（Business）の成長を、オペレーションの設計と改善によって支える機能」です。特定の部署の名前ではなく、役割の名前ですね。
一方、職種としての実態は、SalesforceやHubSpotのようなSFA/CRM（営業支援・顧客管理システム）の管理者、データ整備担当、業務改善のなんでも屋として置かれていることが圧倒的に多い。
専任の担当者を置いていない会社でも、営業企画や情報システムの誰かが、兼務でこの役割を背負っています。つまり「うちにBizOpsはいない」という会社にも、BizOpsの仕事だけは必ず存在しています。
この「概念」と「実態」のギャップこそが、今日お話しする問題の出発点です。
目次
- 断る動機が、構造的に存在しない仕事
- 現場は「オブジェクトを追加して」とは言いません
- ベンチマーク先は、社内にありません
- 実例：「ヨミ」を「フェーズ」に切り替えたとき、何が起きたか
- 情報の取り方には、気をつけてください
- おわりに：明日、何をするか
1. 断る動機が、構造的に存在しない仕事
まず、この仕事の構造を確認させてください。
BizOpsの担当者にとって、カウンターパートは基本的に社内です。営業の方、マーケティングの方、コーポレートの方、事務の方。
毎日のように社内の誰かと話をして、SFA/CRMを触り、データ基盤を整え、資料をつくる。これがBizOpsの、ごくごく通常の一日です。
ここまでは何もおかしくありません。でも、これを何年も続けていくと、必ず受け身になっていきます。
なぜか。「相手が社内だから」ではありません。もっと厄介な理由です。
要望を出してくる人が、そのまま自分の評価者だからです。
営業部長の依頼を断れば、営業部長からの評価が下がる。つまり、「断る」という選択肢が、構造的に消えているんですよ。
そしていつの間にか、こう錯覚します。
「正解は、カウンターパートが持っている」
しかもこの錯覚、自分では気づけません。要望は具体的だし、相手は本当に困っているし、実装すれば感謝されるんですから。
「リリースしました」 「ありがとう、助かりました！」
いい光景ですよね。でも、これを何十回と繰り返した先に、会社はどんな姿になるでしょうか。
負債が溜まるんです。
誰かの「やりたい」に応え続けた結果、全体としての整合性を失った項目、ワークフロー、レポート。それだけが積み上がっていく。
冒頭の箇条書きに書いた「誰も入力しない項目と、誰も見ないレポート」は、こうして生まれます。
もう一つ、厳しい話をします。
言われた通りに受けて、その通りにつくる。これは、逃げ場としては、いちばん居心地がいいんです。
感謝されるし、揉めないし、成果物は目に見える。私も何年か、そこにいました。
でも、つくる技術だけが上がっても、その仕事はいずれAIに代替されます。「言われた要件を形にする」という工程は、最も自動化しやすい領域だからです。
BizOpsが本当に磨くべきは、そこじゃないんです。
2. 現場は「オブジェクトを追加して」とは言いません
何を磨くのか。
- 相手の立場になり話を傾聴し、
- 想像力を働かせてイメージし、
- 現状を深く理解した上で、原因を特定して、対案を出す力
です。
その前に、一つ前提を書かせてください。
現場の方は、「オブジェクトを追加してほしい」なんて言いません。（オブジェクトというのは、Salesforceでいうデータの入れ物のことです。「顧客」「案件」といった単位ですね）
現場が言うのは、いつも業務の言葉です。
「これ、見られるようにできない？」 「あの数字、すぐ出せるようにしてよ」
その言葉を、私たちBizOps側が勝手に「入れ物の話」に翻訳してしまう。この翻訳の速さこそが、受け身の正体です。
私はずっと、速く翻訳できることを自分のスキルだと思っていました。そうではなかったんです。
【パターンA】受け身のBizOps
営業部長「案件になる前の見込みも、一覧で見たいんだよね。Salesforceでできない？」
私「なるほどですね。承知しました、管理できるようにしますね」
営業部長「助かる！」
一見、完璧な対応です。スピードも速いし、感謝もされる。
でもこの裏側で、私は「じゃあ新しい入れ物を用意しよう」と設計を始めています。何も判断していないのに、手だけが動いている状態です。
【パターンB】背景を引き出すBizOps
営業部長「案件になる前の見込みも、一覧で見たいんだよね。Salesforceでできない？」
私「できます。ただ、つくり方を考えるのは、もう少しだけ引きましょう。……そもそも、なぜ見たいんですか？」
営業部長「いや、メンバーが今月何を追ってるのかが見えないんだよ」
私「それは今、誰がどこで管理しているんですか？ 一度、Excelでもいいので見せていただけませんか」
営業部長「……たぶん、人によってバラバラだと思う」
私「だとすると、足りていないのは入れ物じゃなくて、“どこからを案件として扱うか”の基準かもしれません。原因、こっちじゃないですか？」
やっているのは、背景・事象・原因・解決策を全部引き出すという作業です。その上で、自分の中にストックされている他社の事例と照らし合わせる。
ここで、実務的なコツを一つ。
「他社ではこうなっていますよ」とは、あまり言わない方がいいです。 角が立つからです。「うちはうちだから」の一言で会話が終わります。
そうではなく、こう言う。
「原因、違うんじゃないですか？」 「実現方法、違うんじゃないですか？」
この一言は、外の情報を持っている人にしか言えません。
【パターンC】そして、現実はだいたいこうなる
ただ、正直に書きます。毎回パターンBのように進むわけがありません。実際に多いのは、こちらです。
私「そもそも、なぜ見たいんですか？」
営業部長「そんなのいいから、作ってよ。来週の役員会で使うんだから」
……はい。私も何度も言われました。
ここで「いや、しかし背景をですね」と粘るのは悪手です。相手には本当に来週があるので、正論をぶつけても関係が悪くなるだけです。
私がやっているのは、時間を切って、本命だけを守るという進め方です。
私「わかりました。来週の役員会は、私がExcelで作って出します。それなら明日出せます」
営業部長「おお、助かる」
私「その代わり、役員会が終わったら15分ください。実際に役員が見た項目だけをSalesforceに残したいので。使わなかった項目まで作ると、入力の手間だけが増えます」
目先の困りごとは、最速で片付ける。設計の判断は、事実が出てからにする。
要望を出してくる方は、声が大きかったりします。正面からぶつかるのはしんどいですし、「わかりました」と言った方が楽です。
でも、相手は実は、対案を求めていることが多いんです。
「A案とB案がありますけど、どちらにしますか？」
この形に持ち込めた瞬間、あなたは御用聞きではなく、議論のパートナーになっています。
3. ベンチマーク先は、社内にありません
その対案の材料は、どこにあるのか。
私の結論はシンプルです。社内に、答えはありません。
やりたいと思っているのは、そのカウンターパートの方が「やりたい」と言っているだけです。それが本当に必要なのか。その道しるべ、つまりベンチマーク先は、社内にはないんですよ。
どこに置くか。
- 自分たちより少し先を行っている企業
- 同じくらいの規模 × 業種で、条件が近い企業
- 平たく言えば、ライバルと呼ばれる会社
ここにちゃんと話を聞きに行くと、他社の事例が自分の中に溜まっていきます。そうすると、「ひょっとしたら別の案があるんじゃないか」と考えられるようになる。
聞きに行く先は、テーマによって変えてください。課題は人によって、会社によって、まったく違うからです。
- 業務オペレーションを効率的に回すには？
- 採用はどうしているのか？
- 目標設定と評価はどうしているのか？
- 横の部署とのうまい付き合い方は？
- プロジェクトを立ち上げるとき、経営層をどう巻き込むのか？
その時々の切り口で、聞ける先を持っておく。
ただし、有名企業の名前に飛びつかないでください
営業の型ならあの会社、人事ならあの会社、という定番はあります。実際、そういった先進企業に話を聞きに行く方も多いですよね。
でも、ここは注意が必要です。
数千人規模の会社の仕組みを、数百人の会社にそのまま持ち帰ると、たいてい事故ります。その仕組みが機能しているのは、その会社の採用力と人材の層があってこそだからです。土台が違えば、同じ制度は動きません。
これは、SFA導入で最も頻繁に起きる失敗の一つです。
だから、基準は先ほどの**「規模 × 業種」**に戻してください。有名企業の話は、あくまで思想を学ぶために聞く。仕組みをそのまま輸入するために聞くのではありません。
そして、聞きに行く相手を選ぶ基準として一つだけ。
「話しやすいから」で選ばないでください。
ちゃんと事業が成長している会社。文化が素晴らしいと思える会社。 そこを選ぶ。
ここを知らないまま社内の要望だけを処理していると、「これ、意味あるんだっけ？」という感覚がずっと続くことになります。
4. 実例：「ヨミ」を「フェーズ」に切り替えたとき、何が起きたか
「外に聞きに行かないと解けない課題なんて、本当にあるの？」
そう思われた方のために、私が実際にぶつかった話をします。
営業の現場には、「ヨミ」という文化がありますよね。Aヨミ、Bヨミ、Cヨミ。 営業本人が「これは今月イケます」「これは来月ですね」と、自分で確度を申告する仕組みです。
呼び方は会社によって違います。「確度A・B・C」でも「コミット・ベスト・パイプライン」でも構いません。呼び方が何であれ、営業本人の自己申告で見込みを立てているなら、これから書く話はそのまま当てはまります。
一方で、Salesforceに代表されるSFAには「フェーズ」という考え方があります。
こちらは、顧客が実際に何をしたかで進捗を決めます。「初回商談が完了した」「課題に合意した」「稟議に上がった」「最終見積を提示した」。営業の気持ちではなく、顧客側の事実で並べていく。
どちらが良い・悪いという話ではありません。もともとの思想が違うんです。
| 考え方 | 何で進捗を決めるか | 誰の軸か |
|---|---|---|
| Aヨミ・Bヨミ・Cヨミ | 営業本人が「今月中に取る」と宣言する | 自分軸 |
| フェーズ | 顧客がどう動いたかという事実 | 顧客軸 |
数字を並べて、私は最初、現場を疑いました
きっかけは、ある検証でした。
月末の締めの一日前に出した見込み数値と、実際の着地数値を比べてみたんです。
私が見てきた企業では、プラスマイナス5%に収まるのが望ましい、という基準で運用されていることがほとんどでした。締めの前日ですから、そこまでズレるはずがない。私もそう思っていました。
結果は、全然合わない。
10チームほどで見たのですが、プラスマイナス5%に入っていたチームが、一つもなかったんです。
一つも、です。
横並びで並べたとき、私が最初に思ったのは「現場の精度が低い」でした。
これが、間違いでした。
冷静に考えれば、6〜7名のチームは、案件1本の増減が月次の2割を動かす粒度です。そこに全社向けの±5%という基準をそのまま当てていた。指標の置き方が、そもそも私のミスだったんです。
現場の規律を疑う前に、自分の設計を疑うべきでした。
ただ、基準を直して全社サマリーで見直しても、中身は同じでした。
「今月中に行きます」と言っていた案件が、行っていない。逆に、読んでいなかった案件が入って帳尻が合っている。
さらに厄介なのは、サマリーで見ると達成していたりすることなんですよ。
会社全体では目標を達成している。だから「よかったじゃないか」となる。勢いだけで数字が伸びていく局面なら、まだ目をつぶれます。でも、再現性がありません。
なぜ勝ったのか、なぜ負けたのかが説明できない。 経営から見れば、これがいちばん困る状態です。人も金も、どこに置けばいいか判断できませんから。
システムを変えるのは簡単。地獄はその先です
原因はフェーズの定義にある。だとすれば、切り替えるしかない。
ここで正直にお伝えしたいのですが、システムを変えるのは、簡単なんです。 選択リストの値を変えて、入力規則を整えて、ダッシュボードを直す。技術的にはそれだけです。
難しいのは、中身です。
そのフェーズの考え方は、営業部長やマネージャーが長年慣れ親しんできたやり方そのものだからです。自分たちのやり方を否定されたと受け取られれば、反発は当然大きくなります。
言い方を変えれば、こういうことです。
「あなたたちが『行きます』と言った言葉は、指標としては使いません。顧客が実際に何を言ったか、それだけを見ます」
性善説から、少し性悪説に寄せる。そう受け取られてもおかしくない転換なんです。
だから、順番を間違えてはいけません。
いきなり「制度を変えます」と切り込んでも、まず通りません。まずは、現場が「これは楽になった」と実感できる改善を泥臭く回して、信頼残高を貯める。そのあとで、経営視点の改革に乗り出す。
そしてもう一つ。このとき、正論を会議室で並べても、人は動きません。
私がやったのは、営業部長の隣に座って、一緒にチームごとの数字を眺めることでした。「これ、なんでズレたんですかね」と、一件ずつ潰していく。
責めない。詰めない。ただ、横に居続ける。「またあいつが来たよ」と思われながら、笑顔で通い続けるわけです。
しんどいです。でも、この積み重ねでしか、制度は変わりません。 制度を動かすのは決裁ではなく、現場の納得だからです。
実際、この切り替えも、反発がすぐに消えたわけではありません。それでも、ズレの理由を一件ずつ一緒に潰し続けるうちに、「フェーズで見た方が振り返りの会話が早い」と現場の側から言われるようになり、切り替えは定着しました。
そして、その反発に負けないだけの理論を構築するためには、外の話を聞きに行くしかありません。
なぜ切り替えたんですか。切り替えたあと、現場は何と言いましたか。どこで失敗しましたか。
こんなことは、Web検索では出てきません。AIに聞いても出てきません。実際にやった人に、聞くしかないんです。
信頼残高を貯めるためにやった「改善」の具体例
改革（全体最適）を成し遂げるには、まずは徹底的な「改善（部分最適）」をぶん回して、現場からの信用＝「信頼残高」を極限まで貯める必要があります。
私が「1人Salesforce管理者（ADMIN）」として現場に入り込んだ当時、信頼残高を貯めるために実際に手を動かした3つの泥臭い改善例を紹介します。
具体例1：「システム管理権限10人持ちカオス」の回収
前職に入社した当時、120名ほどのSalesforceユーザーに対して、なぜか「システム管理者権限」を持つ人が社内に10人も存在していました。
誰もが好き勝手に設定を変更できるため、データは重複し、消してはいけない項目が削除され、現場は混乱を極めていました。
ここで単に「危ないから権限を取り上げます」と上から伝えると、現場は「自分たちのやり方に口を出された」と反発します。そこで私は、営業企画のメンバーにこう宣言しました。
「皆さんは本来の『企画業務』に集中してください。Salesforceの面倒な要件定義や、バグ対応、実装はすべて私が引き受けます。そのために、一度権限を私に一本化させてください。必ず皆さんの業務を今より楽にします」
面倒なシステム設定やトラブルシューティングから解放されると知った現場は大喜びし、大歓迎で権限を渡してくれました。
間違いを正そうというスタンスではなく、現場の負荷に寄り添い、それを解消することを申し出るというスタンスで関わる。これでまずは「頼れるお助けマン」として信頼してもらえる基礎ができました。
具体例2：「見積書・申込書PDF化」への「なぜ？」の深掘りと段階的検証
現場のマネージャーから「見積書や申込書をスプレッドシートから作るのが面倒なので、Salesforceから直接PDF出力できるようにシステムを構築してほしい」という相談が来ました。
言われた通りにすぐシステムを作る（＝単なる作る人）のではなく、私は「どうしてですか？」と背景を深掘りしました。
すると真の課題は、個人のスプレッドシートで作ることで「営業が勝手にひな形をカスタマイズしてしまい、会社として許容できない備考（法的なリスクがある内容など）を勝手に記載して契約してくるのを防ぎたい」というガバナンス上の問題だとわかりました。
そこで私は「いきなり大きなシステムを組む前に、まずはNGとなる契約基準を一緒に定義し、スプレッドシートをベースに営業部全体で1ヶ月テスト運用してみませんか？ 売上にマイナスが出ないか検証し、そのルールでいけると確信してからシステム化しましょう」と逆提案しました。
現場の「早く楽にしたい」という感情に寄り添い、無下に否定せず、段階的なアプローチでリスクを検証する。この「相談の粒度を抽象的にしていくコミュニケーション」によって、「システムの便利屋さん」から「ビジネスプロセスの設計パートナー」への信頼が積み上がっていきました。
具体例3：「ニコニコ張り付き戦法」によるSFA入力の定着
SFAを導入しても、現場の営業メンバーが面倒くさがって入力してくれない、というのは誰もがぶち当たる壁です。
ここで「上司から怒ってもらう」とか「会議で晒し上げる」といった手を取ると、現場との人間関係は一瞬で崩壊します。
そこで私が取ったのは、超が付くほど泥臭い「張り付き戦法」でした。入力が滞っている営業メンバーの席の横にニコニコしながら毎日張り付き、こう声をかけ続けるのです。
「今月も絶好調で忙しそうですね！ 入力するの大変だと思うので、今、僕が代わりにキーボード叩きます！ 口頭で内容を教えてください！」
これを嫌な顔ひとつせず、本気でサポートする姿勢でやり切る。毎日やっていると、相手も「また来たな……気まずいな」となってきます。
結果、私の顔を見ただけで「あ、今から自分でちゃんと入れます！」と苦笑いしながら自発的に入力してくれるようになり、最終的には言われる前に入力する習慣がチーム全体に定着していきました。
脅しで相手を悪者にしてコントロールしようとしない。あくまで力になりたい、寄り添いたいというスタンスで接して、敵対しない信頼関係を作る。これが要点です。（このケースはちょっとうるさがられてはいるのですが（笑）、ポイントはあくまでニコニコと「力になりますよ！」全開で接することです）
改革の結末：契約・請求統合プロジェクトで何が変わったか
小さな改善を積み重ね、信頼残高が満タンになったタイミングで、私は「各事業部がバラバラに契約・請求書を発行しているカオス」を解消する**「契約・請求統合プロジェクト」**という抜本的な改革を起案し、実行に移しました。
経営者や事業責任者が最も知りたがる「で、結果どうなったのか？」という結末をお伝えします。
定着までにかかった期間：丸1年
プロジェクトの発足（要件定義）から、複数の事業部をまたぐシステム・オペレーションの共通基盤への完全移行、そして現場が何一つ不満を言わずに自走する「定着」に至るまで、およそ1年（約12ヶ月）を要しました。
最初の8ヶ月でシステム構築とデータの移行を行い、実際に稼働。その後、現場のオペレーションに血肉化し、マニュアルなしでも呼吸するように処理が回るようになる定着フェーズに、さらに4ヶ月の並走期間が必要でした。
もたらされた変化
-
予実の誤差が5%未満に激減。 それまでは各事業部が独自のタイミングと異なる言葉（「システム利用料」や「利用料」など）でバラバラに契約や売上を管理していたため、データの転記漏れや重複が多発し、月末にフタを開けるまで正確な経営数字がわからない（予実誤差20〜30%）状態でした。※この予実誤差は、前半で触れたヨミの精度とは別の、データ転記や言葉の定義のバラつきに起因するものです。データの定義を統一し、共通データ基盤に統合したことで、経営陣がいつでも事実に基づく売上推移をリアルタイムに把握できるようになりました。
-
請求額・発行枚数が2倍、3倍になっても追加の人員はゼロ。 全社共通の請求自動化オペレーションを構築した結果、会社の急成長に伴って請求額や発行枚数がスケールしても、バックオフィスの担当者を1人も増やすことなく、同じ人数でミスなく処理し続ける組織基盤ができました。
-
プロダクト開発チームのリソースを顧客価値に集中。 それまで事業部のプロダクトチームが片手間でやっていた「できればやりたくない、間違えたら顧客に怒られる」請求書発行や契約管理システムの手戻り作業をBizOpsチームがすべて引き取ったため、開発チームはコア機能の開発にリソースを集中させられるようになりました。
途中で「諦めた」こと：完璧なシステム化を捨てる決断
この改革を成功に導くために、私が途中で諦めたことがあります。それは**「すべてのイレギュラーをシステムで自動化する完璧さ」**です。
統合を進める中で、数千契約に1件しかないような特殊な請求パターンや、特定の顧客にだけ発生する例外的なオペレーションがいくつか浮き彫りになりました。これらをすべてシステム側で自動判定させようとすると、開発工数は跳ね上がり、稼働がさらに半年以上後ろ倒しになることが判明したのです。
そこで私は、最初からシステムを100点満点にする完璧主義を捨てました。 全体の約9割をシステム統合の波に乗せ、残りの複雑な「イレギュラーな1割」については、無理に開発せず「マニュアル対応による手動の運用」としてあえて残すという決断をしたのです。
「システムを導入すること」が目的ではなく、「顧客に早く価値を届け、事業をスケールさせること」が本来の目的です。この現実的な割り切りがあったからこそ、プロジェクトは期限どおりに稼働し、現場を大混乱させることなく全体最適へ着地させることができました。
5. 情報の取り方には、気をつけてください
※このセクションで触れる「カスタマービジットの活用法」は、以前の記事その提案、本当に御社のため？ ― ベンダーに振り回されない3つの武器でも取り上げた「一次情報を取りに行く」実践編にあたります。あわせてご覧ください。
ここまで読んで、こう思われた方も多いと思います。
「一次情報が大事なのはわかります。でも、メディアの情報はタダで置いてあって、すぐ読めるじゃないですか」
おっしゃる通りです。手軽です。でも、手軽なのには理由があるんですよ。
冒頭で「情報の取り方には気をつけてください」と書いたのは、この話です。ここからは、注意点と活用法をセットでお伝えします。
【注意点1】二次情報は「真水」ではありません
自分で取りに行かなかった情報には、必ず誰かの意図が入っています。純粋な、真水のような情報ではありません。
すでに塩が入っていたり、砂糖が入っていたりする状態で出てくる。 水だと思って飲んでいるけれど、実は違うんです。
特に、ベンダーが運営しているメディアには注意が必要です。
悪意があるという話ではありません。ただ、彼らが何のためにメディアを運営しているかを考えれば、答えは明らかです。リード獲得のためです。
だとしたら、「ここで苦労しました」とは書いても、「ここで失敗しました」とは書けません。書けないんですよ、構造的に。
導入事例も同じです。マーケティング担当の方が編集して、きれいに仕上げる。当然のことで、悪いことでもありません。
問題は、それを鵜呑みにしてしまうことです。
【活用法1】事例は「担当者を探す名簿」として使う
どう使うか。
私は、メディアも導入事例も否定していません。使い方があるだけです。
導入事例を読んだら、こう見てください。
「この案件、誰が担当したのか」
事例記事には、たいてい担当者の顔と名前が出ています。その名前で、LinkedInやFacebookを検索してみてください。だいたい出てきます。
そうしたら、連絡してみるんです。
はじめまして。突然のご連絡失礼いたします。
御社の◯◯導入事例を拝見しました。特に、フェーズ定義を見直されたという一文が気になっています。 弊社でも同じ課題に取り組んでおりまして、記事には書かれていない部分をぜひお伺いしたいです。
弊社は◯◯業で、同じ論点を昨年から進めています。うまくいかなかった部分も含めて、こちらからお話しできることがあればお持ちします。 お時間はYY分いただけると幸いです。
長々と書きましたが、外せないのは後半の2点です。
一つは、記事のどの一行に引っかかったのかを書くこと。読んでいない人からのDMはすぐわかりますが、ちゃんと読んだ人からのDMは、返したくなるんですよ。
もう一つは、こちらから出せるものを先に置くこと。「教えてください」だけの依頼は、相手にとって純粋な持ち出しです。
「自分にGiveできるものなんてない」と思われるかもしれません。あります。あなたの失敗談やその他の施策、事例です。 うまくいった話より、つまずいた話の方がはるかに価値があります。どこにも書かれていないからです。
返信率について、正直に書いておきます
私の実感では、10人に連絡すると5人くらいは返ってきます。
ただし、この数字は参考にしないでください。 会社の知名度や露出度も関係してくるからです。無名の状態で送るなら、返信は1〜2人と見ておいてください。だから、1通に賭けない。10通送る。
返ってこないのは、あなたの問題ではなく、確率の問題です。
そして送る前に、これだけは確認してください。
- 自社の情報管理規程（他社担当者への個別接触の可否）
- 相手にも上長承認が要る場合があるので、所属・目的・所要時間を明記する
- 一度断られたら、引く
ここを飛ばすと、熱意ではなく迷惑になります。
【注意点2】カスタマービジットは、楽な分だけ薄くなります
情報の取り方で、もう一つ気をつけていただきたいのがこれです。
カスタマービジットというのは、SaaSベンダーが「うちの導入企業を紹介しますよ」と、他社訪問をセッティングしてくれる仕組みのことです。
これに、いきなり乗っかるのはおすすめしません。
いや、楽なんですよ。すごく楽です。アポイントも取ってくれる。場所も用意してくれる。お茶とお菓子まで出てくる。
でも、楽なところには裏があります。
きれいにお膳立てされた場で、「失敗したことはありますか？」と聞いたとして、何が返ってくるか。
「まあ、失敗というほどじゃないんですけど、この辺りは少し困りましたね」
……これです。ベンダーの方が同席している場で、本音の失敗談が出てくるはずがありません。
一方で、担当者の方と二人だけで話をするとどうなるか。
「いやあ、本当に困ったんですよね。実は、社内でこう言われて、結局あれは解決できなかったんですよ」
粒度が、段違いです。
【活用法2】1回目は顔つなぎ、2回目に一対一で
だから私がおすすめしているのは、二段構えです。
- 1回目：カスタマービジットで構いません。ここは顔つなぎ。担当者の方と接点を持つことがゴールです。
- 2回目：ベンダーを介さず、自分で連絡を取ってお会いする。ここで、深く聞く。
2回目で聞くべきなのは、成功事例ではありません。
「いちばん困難だったのは、どこでしたか」「今振り返って、後悔している判断はありますか」
担当者の方が後悔した部分。それは、あなたがこれから踏みに行く地雷そのものです。
繰り返しますが、カスタマービジットもメディアも、否定しているわけではありません。彼らも人件費やサーバー費用といったコストを払って運営しています。その意図をわかった上で使うのと、わからずに使うのとでは、まったく違うという話です。
課題の重さで、取り方を変えてください
整理します。
| 課題の重さ | 取り方 |
|---|---|
| ハウツーで解決する話（標準機能の使い方など） | Web検索・AI・公式ヘルプで十分 |
| 思想の転換が必要な重い話（ヨミからフェーズへの切り替えなど） | 実際にやった人に聞く |
軽い課題に重い取り方をするのは、時間の無駄です。でも、重い課題を軽い取り方で済ませようとすると、解決しません。
ここの見極めだけは、外してほしくないんです。
6. おわりに：明日、何をするか
BizOpsが社内に閉じることのデメリットは、突き詰めればこの一点です。
判断の基準が、社内の「声の大きさ」だけになってしまうこと。
そうならないために、やることはシンプルです。
- 事業が成長していて、文化を尊敬できる会社に、自分の足で聞きに行く
- ただし、規模と業種が近い会社を選ぶ。有名企業の仕組みは、そのまま持ち帰らない
- メディアや導入事例は、鵜呑みにせず**「担当者を見つけるための名簿」**として使う
- 返信は来ない前提で、10人に送る。ただし、自社の情報管理ルールは先に確認する
- カスタマービジットは1回目が顔つなぎ。本音は2回目、一対一で「後悔した判断」を聞く
- もらったら、必ず返す。自分の失敗談は、一級のGiveです
もし、明日できることを一つだけ選ぶなら。
直近で読んだ導入事例を開いて、担当者の名前を検索してみてください。 送るかどうかは、そのあと決めればいい。
BizOpsの顧客は、最終的には経営者です。そして目的は、システムをつくることではありません。データドリブン経営を実現し、事業成長に寄与することです。
その目的地に向かうための地図は、残念ながら社内にはありません。
外に一つも話を聞きに行かない。それ自体が、いちばん大きなデメリットなんです。
事件は会議室で起きてるんじゃない。現場で起きてるんです。そしてその現場は、自社の中だけにあるわけではありません。
……とはいえ、です。
この話をすると、必ずこう言われます。
「コミュ力があるからできるんですよ」「それ、強者の理論ですよね」
正直、そうかもしれません。
しかも、動けない理由はコミュ力だけではありません。時間がない。競合に会うなんて稟議が通らない。営業部長の隣に座る資格がない。
その3つの壁に正面から答える記事を、後編として別途公開します。
よくある質問
Q1. BizOpsが社内に閉じると、何が問題になりますか？
A. 判断の基準が社内の「声の大きさ」だけになることです。要望を出す人がそのまま評価者でもあるため「断る」選択肢が構造的に消え、誰かの「やりたい」に応え続けた結果、誰も入力しない項目と誰も見ないレポートという負債が積み上がります。
Q2. BizOpsのベンチマーク先は、どう選べばいいですか？
A. 規模と業種が近く、事業が成長していて文化を尊敬できる会社を選んでください。数千人規模の有名企業の仕組みを数百人の会社にそのまま持ち帰ると、採用力や人材の層という土台が違うため機能しません。有名企業の話は、仕組みを輸入するためではなく思想を学ぶために聞くものです。
Q3. 営業の「ヨミ」とSFAの「フェーズ」は何が違いますか？
A. 思想が違います。ヨミ（Aヨミ・Bヨミ・Cヨミ）は営業本人の自己申告で見込みを立てる「自分軸」、フェーズは「初回商談が完了した」など顧客側の事実で進捗を決める「顧客軸」です。予実の精度と勝敗の再現性を求めるなら顧客軸への転換が必要になりますが、現場の納得を得る順番とプロセスの設計が成否を分けます。
Q4. SaaSベンダーの導入事例やカスタマービジットは、参考にしてもいいですか？
A. 使い方次第です。ベンダーのメディアはリード獲得が目的のため、構造的に失敗談は書けません。導入事例は鵜呑みにせず「担当者を見つけるための名簿」として使い、カスタマービジットは1回目を顔つなぎに、2回目にベンダーを介さず一対一で「いちばん困難だったこと」「後悔している判断」を聞いてください。
無料相談のご案内
「うちの数字は、なぜ締めの前日でも当たらないのか」 「Salesforceに何年も払っているが、投資として回収できている実感がない」
そうした課題を、社外の事例と御社の実態を突き合わせながら、改善と改革の順番に落としてご一緒しています。
外の知見を、御社の言葉に翻訳して持ち込むところからが私たちの仕事です。最初のご相談は、現場のご担当者お一人から、というケースがほとんどです。上申の材料づくりからお手伝いします。初回のご相談は無料です。
参考文献・出典
- 本記事に登場する数値（Salesforceユーザー120名に対しシステム管理者権限が10人、予実誤差20〜30%から5%未満への改善、統合プロジェクトの定着に約12ヶ月、返信率の実感値）は、いずれも筆者（祖川慎治）自身の前職および現在の実務での実体験に基づく数値です。第三者調査による統計値ではありません
- 「ヨミ」と「フェーズ」の思想の違い、ベンチマーク先の選び方、一次情報の取り方に関する考察は、筆者の実務経験に基づく整理です
- 関連記事：その提案、本当に御社のため？ ― ベンダーに振り回されない3つの武器
この記事を書いた人
祖川 慎治（そがわ・しんじ）
株式会社テイクアステップ 代表取締役／一般社団法人BizOps協会 代表理事。大手メーカー・大手SIerを経て、HR Techベンチャーで全社の業務改善を担うBPR部署の責任者として社内IT戦略の立案から実行・定着化までを担当。5年で300名から1,400名へ成長する組織とIPO実現を業務基盤の面から下支えした。2021年に株式会社テイクアステップを設立し、BizOps・業務プロセス設計の実行支援を行う。ポッドキャスト「どうする？BizOps」配信中。