KPIが未達のとき、ファネルの中で自分が最もコントロールできる変数は何か。リードの数でも、商談化率でもない。答えは「売上に近い活動へ、実際に何時間使ったか」だ。ここが最もコントロールしやすい変数であるにもかかわらず、多くの営業組織はここを測っていない。
私は、営業の改善はスキル論やツール導入より先に、この時間の計測から始めるべきだと考えている。ただし条件がある。計測が効くのは、KPI未達の原因を「量」と「質」のどちらかに切り分けたい局面に限られる。サービス知識、業界知識、ロープレによるアウトプット練習——こうした前提がまだ整っていない段階では、時間をいくら測っても診断は成立しない。時間データは万能薬ではなく、条件付きの道具だ。
本記事は、Salesforce の「State of Sales 2026」と HubSpot Japan の「日本の営業に関する意識・実態調査2024」という2つの一次情報を土台に、時間×成果の4象限という診断フレームを重ねて書いている。ツール比較や運用ノウハウは、この診断フレームを実際に回すための手段として位置づける。
議論を進める前に、繰り返し使う言葉を定義しておく。定義が曖昧なまま進めると、読者が「いや、それは違う」と反論する余地すらなくなる。
売上に近い活動(売上近接活動) と呼ぶのは、次の活動に限る。
境界線上にあるのが「CRM入力」だ。商談直後の記録は売上近接活動に含めてよいが、まとめて行う月次の日報整理は含めない。以下の議論はすべて、この定義の上に乗っている。
もう一つ前提として置いておきたいのが、本記事でいう「営業」の定義だ。顧客の課題解決と、その意思決定をアシストする情報提供を行い、購買活動を支援することを目的とする仕事を指す。売ることは手段であって、目的ではない。この前提を外すと、後述する「時間を売上活動に戻す」という設計思想自体が成立しなくなる。
Salesforce の「State of Sales 2026」によると、営業担当者が selling に使える時間は平均40%。残り60%は、見込み客の発掘、見積作成、計画立案、データ入力、研修などの非 selling 業務に消えている。同レポートでは、ハイパフォーマーな営業チームほど単一プラットフォームへの統合とデータの整備を優先しているとも報告されている。実際、単一プラットフォームを使っていない営業チームの8割超がツール統合を計画しており、平均して8個のツールを抱えているという(同レポート)。差を生むのは気合いではなく、時間を売上活動へ戻す設計だ。
一方、HubSpot Japan が2024年に公開した「日本の営業に関する意識・実態調査2024」では、日本の営業担当者が顧客とのやりとりに使える時間は業務時間の54%。理想としては「1日あたりあと25分」増やしたいという結果だった。営業が時間を割きたい業務の1位は「顧客との商談」(35.3%)、2位は「商談後のフォローアップ」(31.4%)、3位は「営業戦略の振り返り」(30%)だった。
「selling」と「顧客とのやりとり」——両調査の定義は一致していない。selling はより狭く売る行為そのものを指し、顧客とのやりとりはフォローや情報提供まで含む、より広い概念だ。それでも、営業担当者の週の半分前後しか売上近接活動へ使えていないといえそうだ、という点で両者は一致する。
「KPIが未達です。もっと頑張ります」——この報告には診断が入っていない。時間データがあれば、報告は変わる。
これらの会話を成立させているのは、時間×KPIという2軸の掛け合わせだ。ここで、本記事で繰り返し使う中心概念を定義する。
この2つを取り違えると、量の問題に「もっと工夫しろ」と言い、質の問題に「もっと架電しろ」と言う、逆の処方箋を出すことになる。時間データがなければ、この取り違えに気づく方法がない。
この取り違えは、当事者の話を聞いているだけでは気づけないというのが私の見立てだ。「頑張っているのに成果が出ない」という訴えは、量の問題を抱えた人からも、質の問題を抱えた人からも、同じトーンで出てくる。両者を分けられるのは、結局のところ時間データだけだと思う。
まずはツールを増やさずに始める。既存の Google カレンダーと Google Apps Script(GAS)があれば、追加コストゼロで計測を始められる。
予定名に「go1t_[予定名]」のような、他と重複しないキーワードを入れる。go1t は「Go 1 trillion」を略したもので、それ自体に意味はない(オープンハウスの「行こうぜ1兆」から着想を得た。気合いの入った語にするのがおすすめだ)。
| ルール | 理由 | 例 |
|---|---|---|
| 英数字+アンダースコア | GASでの抽出が容易 | go1t_call, go1t_mtg |
| 活動カテゴリを付与 | 分析精度が上がる | go1t_prep(準備), go1t_follow(フォロー) |
| 顧客名は含めない | カレンダーの見やすさ確保 | 予定本文に記載する |
記録の粒度も先に決めておく。5分単位は精度が高いが記録の手間が大きく、30分単位は手間が少ない代わりに分析には粗すぎる。多くの場合、15分単位が負担と精度のバランスを取りやすい。
ここで手を抜くと、あとで必ず響く。キーワードとカテゴリの命名規則を運用の途中で変えると、それ以前のデータと接続できなくなり、分析期間が実質的にリセットされる。情報システム部への確認も、走らせてから止められるより、先に通しておいたほうが手戻りが少ない、というのが私の考えだ。
GAS で go1t_ を含む予定の開始・終了時刻とカテゴリを抽出し、スプレッドシートへ時間主導トリガーで反映する。
1. CalendarApp.getCalendarById(...) または getDefaultCalendar() で対象カレンダーを取得
2. calendar.getEvents(startTime, endTime) で期間内イベントを取得
3. event.getTitle() に go1t_ を含むものだけをフィルタ
4. event.getStartTime() / getEndTime() とカテゴリを SpreadsheetApp に書き出す
5. time-driven trigger で定期実行し、実行権限は最小範囲に絞る
注意: 機密性の高いGoogleカレンダーの情報を取得するため、必ず情報システム部の方に確認してください。
カテゴリは「新規開拓(go1t_prospect)」「商談(go1t_mtg)」「提案準備(go1t_prep)」「フォローアップ(go1t_follow)」「社内業務(go1t_admin)」の5つ程度に絞ると、後段の4象限分析と接続しやすい。
手動記録に限界を感じたら、専用ツールへ移行する選択肢がある。Toggl Track は手動タイマーの標準化に強く、Salesforce Einstein Activity Capture はメール・カレンダーの活動を自動でSalesforceに同期する。RescueTime はPC上の作業時間をバックグラウンドで自動計測するが、営業カテゴリへの割り当ては手動補正が必要になる。いずれも「何を、どこまで自動化したいか」を先に決めてから選ぶのが安全だ(Einstein Activity Captureの利用範囲は edition / add-on によって変わる)。会話・活動データの自動収集をさらに深掘りしたい場合は、レベニューインテリジェンス系の実装を扱った Gong Deep Dive も参考になる。
時間計測は、それ単体では何も変えない。効くのは、仮説を立て、目標データを作り、実績と突き合わせ、KPIと照合し、振り返るという一連の流れを毎週回したときだけだ。
まず仮説を立てる。新規アポ1件を取るのに何コール必要か、商談1件の準備にどれだけ時間がかかるか。過去のデータがあればそれを土台にする。たとえば「新規アポ1件=架電20件×5分=約100分」「商談1件の準備=企業調査30分+資料作成60分=約90分」といった具合だ。次に、月間目標から週次・日次の活動時間目標を逆算する。
| 月間目標 | 必要商談数 | 必要アポ数 | 週あたり売上活動時間 |
|---|---|---|---|
| 売上500万円 | 10件 | 30件 | 15時間 |
| 売上1,000万円 | 20件 | 60件 | 25時間 |
ここまでは準備にすぎない。本当の仕事はその先にある。毎週金曜日に目標時間と実績時間を突き合わせ、差異が±20%以上ある項目にフラグを立てる。そのフラグを、前段で定義した「量の問題」「質の問題」の2軸に当てはめる。時間は投下したのにKPI未達なら質の問題、時間が足りずKPI未達なら量の問題だ。ここまでやって初めて、時間データは診断材料になる。
そして、振り返りをやめた瞬間に計測は形骸化する。日次5分のセルフチェック、週次30分のチームMTG、月次60分のマネージャー1on1——頻度と所要時間を決め、どれか一つでも欠かすと、蓄積したデータは「見えているのに使われない数字」に変わる。計測より振り返りの方が、実は難しい。
導入から本格運用までの目安は次のとおりだ。
| 期間 | やること |
|---|---|
| 第1週 | キーワードとカテゴリを決め、記録を始める |
| 第2〜4週 | データを溜め、日次振り返りを始める |
| 第5〜8週 | 週次分析と改善アクションを回す |
| 第9〜12週 | 4象限分析を本格運用する |
時間×成果の4象限に当てはめると、同じ「KPI未達」でも打ち手がまったく変わる。
| 象限 | 状況 | 打ち手 |
|---|---|---|
| 時間使えた × 達成 | 目標達成、活動量も十分 | ストレッチ度合いを確認し、次期は難易度を上げる |
| 時間使えた × 未達 | 活動量は十分だが成果が出ない=質の問題 | コール内容、提案内容、ターゲット選定を見直す |
| 時間使えなかった × 達成 | 少ない時間で成果が出た | 再現性を検証。運か効率かを判断する |
| 時間使えなかった × 未達 | 活動時間が足りない=量の問題、または環境の問題 | 他業務を見直し、上長が時間の優先順位をつける |
このメンバーが持っているのは、再現可能な型だ。どの活動に何時間使ったかを言語化し、チームに共有する。次期は目標を10〜20%ストレッチし、成長を促す。
最も改善余地が大きい象限であり、量を増やしても解決しない象限でもある。コールスクリプトの見直し(録音分析が有効)、提案資料のテンプレート改善、ターゲットリストの精度向上(業種・規模・課題のフィット)、ロールプレイによるスキル強化——量ではなく質に手を入れる。
この象限が厄介なのは、本人に「サボっている」という自覚がまったくないことだと思う。時間は使っているという実感があるからこそ、「質が悪い」という指摘に納得感が伴いにくい。だからこそ、感覚での指摘ではなく、コール録音やターゲットリストの数字を本人と一緒に見ながら、どこにズレがあるかを特定する作業が要る。
一見良さそうに見えるが、疑うべきは持続性だ。大型案件1件による一時的な達成ではないか。既存顧客のリピートに依存していないか。来期も同じペースで達成できる根拠があるかを確認する。
ここはマネージャーが最も介入すべき象限だ。社内会議の棚卸し、事務作業の自動化・委託、上長によるブロッカー排除——これは個人の時間管理では解けない。全員が自分の仕事をしていてもパイプラインが増えない組織の話は、別記事「RevOpsとGTMエンジニアの違い」で部門サイロの問題として扱った。象限4に何人も溜まっているなら、疑うべきは個人の時間管理ではなく組織設計だ。
時間計測が効かない場面、あるいは逆効果になる場面もある。
第一に、前提が整っていない場合だ。サービス知識、業界知識、事例の引き出し、ロープレを通じたアウトプット練習——これらが未整備なら、時間をいくら測っても「量か質か」の診断自体が成立しない。診断エンジンは、走らせる前に前提を満たしているかを確認する装置でもある。
第二に、この仕組みは簡単にハックできる。空予定を入れれば記録上の時間は増やせる。先々の予定を埋めすぎると日程調整にも影響が出るため、作業後に実際の時間へ修正する運用がポイントになる。「正確なデータが自分の成果につながる」という意識づけ、ランキングや表彰ではなく改善のためのデータとして使うという運用ルール、そしてマネージャー自身も計測して率先垂範することが対策になる。
第三に、マイクロマネジメントに見えやすい。「時間計測は監視ではなく、皆さんが成果を出しやすい環境を作るためのデータ収集です」——目的と背景を丁寧に伝えることが、抵抗感を下げる唯一の方法だ。
この2つの失敗パターンは、机上の空論ではなく、時間計測を仕組みとして入れようとすれば早晩ぶつかる壁だと思う。空予定というハックは仕組みそのものでは防ぎきれず、運用のインセンティブ設計でしか対処できない。前提知識が整っていない営業に計測だけを足しても、「なぜ数字が悪いのか」を言語化できないまま終わる——だからこそ本記事は、時間データを万能薬として扱わない立場を取っている。
ここまでの話を、私は次のように持ち帰っている。時間データは、営業を監視するための道具ではない。KPI未達という一つの事象を、量の問題か質の問題かに仕分けるための道具だ。仕分けを間違えれば、量の問題に質の処方箋を、質の問題に量の処方箋を出し続けることになる。
ただし、この道具にも境界がある。サービス知識、業界知識、ロープレという土台が整っていない営業に時間計測だけを入れても、診断は成立しない。時間データは万能薬ではなく、条件が揃ったときにだけ効く道具だ——この境界を忘れると、計測そのものが目的化し、営業の時間をさらに奪う、本末転倒が起きる。
この記事は、SFA導入前、あるいは手動でも計測を始めたい局面を扱った。SFA/CRMを実際に入れたあと、入力や部門間の受け渡し、改善会議をどう組み直すかは、別記事「営業DXのその先へ: SFA導入後の営業設計メモ」で続きを書いている。時間の計測を終えた先に、その設計がある。
はい、スキルレベルに応じて調整すべきだ。新人は習熟に時間がかかるため、売上活動時間の比率を段階的に引き上げるアプローチが効果的だ。商談同席、提案準備、CRM更新などの内訳を分けて計測し、役割に応じた目標へ調整する。
リモートこそ時間計測が重要になる。オフィスでの「見える化」が効かない分、データによる可視化が必要になる。RescueTimeのようなバックグラウンド計測ツールと、カレンダーベースの活動記録を組み合わせるのがおすすめだ。
getEvents() / getEventsForDay() の公式リファレンス本記事はネクサフローの営業効率化シリーズの一部です。