Excel・別ツールに分断したまま回している案件管理を、Salesforceの中に取り戻す
はじめに：商談クローズの瞬間に「データの分断」が始まる
多くのSalesforce導入企業では、商談クローズ＝Closed Wonの瞬間に、データの流れが断絶しています。商談ステージは「100%」になり、SalesCloud上では完了したように見える。しかし、その先で実際に動く「案件タスク」「工数」「原価」「進捗」「検収」といった受注後の業務は、Salesforceの外側に流れ出していくのが現実です。
Excelの工数表、Asana・Backlogの進捗ボード、別の勤怠システム、メールでの差戻し履歴——分断されたツールを跨いで集計する作業は月末に集中し、案件の粗利が確定するのは検収の数週間後。この構造のまま回している企業は、本来Salesforceの基盤上で得られるはずの「進行中の収益見える化」を享受できていません。
本記事では、受注後の工程管理がなぜ分断するのかを構造的に整理し、Salesforce上で「商談→案件→検収→請求」を一気通貫にする全体像を解説します。これは、Salesforce導入企業の経営者・Deliveryマネージャー・PMOが押さえるべき、受注後ガバナンスのピラー記事です。
この記事でわかること
- 受注後の工程管理が分断する3つの構造的要因
- SalesCloudの守備範囲と、その先に必要な5つの追加レイヤー
- 商談→案件→検収→請求を一気通貫にする運用設計
- Salesforceネイティブで実現する受注後ガバナンスの実装パターン
第1章：なぜ受注後の工程管理は分断するのか
理由① SalesCloudの設計思想は「受注まで」
Salesforceの中核製品であるSales Cloudは、商談・取引先・リード・キャンペーンといった「受注前」のデータモデルを軸に設計されています。商談ステージはClosed Won／Closed Lostで終了し、その先の案件タスク・工数・原価・要員・検収条件などを保持する標準オブジェクトは存在しません。
これは設計の不備ではなく、Sales Cloudの責務範囲が「商談の見える化と受注の確度向上」だからです。受注後の工程管理は別のソリューションに委ねることが前提となっています。
理由② 部門ごとに最適なツールが異なるという現実
受注後の業務は、部門ごとに必要な機能が異なります。開発部はチケット管理（Jira／Backlog）、制作部はワークフロー（Asana／monday）、経理は会計連携、HRは勤怠管理——それぞれが部門最適のツールを選択した結果、全社視点では「データが分断したサイロ」が積み上がります。
各部門にとっての「ベスト」が、会社全体の「ガバナンス上のワースト」になっている、というのが多くの企業の現状です。
理由③ Excelとメールが「最後の接着剤」になっている
ツール間の隙間を埋めているのは、ほとんどの場合Excelとメールです。「営業からの引き継ぎ書」「進捗共有のスプレッドシート」「差戻しのメール履歴」「月次原価集計のExcel」——これらが受注後の業務を辛うじて成立させていますが、データとしての追跡可能性・検索性・集計性はゼロに近い状態です。
受注後の工程管理が分断する原因は「ツール選定の失敗」ではなく、SalesCloudの守備範囲を補完する明確な設計が組織に存在しないこと。Excelとメールが接着剤になっている限り、データガバナンスは成立しない。
第2章：SalesCloudの先に必要な5つの追加レイヤー
受注後の工程管理を機能させるには、SalesCloudの上に5つの追加レイヤーを乗せる必要があります。これらをExcel・他SaaSで実装するか、Salesforceネイティブで実装するかが、ガバナンスの行き先を分けます。
レイヤー① 案件タスク管理（WBS／ガント）
商談クローズと同時に「実行可能な案件レコード」を立ち上げ、WBSのタスクに分解する仕組みです。受注金額・想定工数・期限・担当者を商談から自動展開し、ガントチャートで依存関係を可視化します。
レイヤー② 工数管理（タイムシート）
タスクに対して日次で工数を入力するレイヤー。15分単位の入力粒度・稼働種別の分類・タスクとの自動紐づけが要件です。月末一括入力ではなく、その日のうちの入力が定着する仕組み設計が肝になります。
レイヤー③ プロジェクト原価・採算管理
工数×フルコスト単価で原価をリアルタイム算出し、商談時の受注金額と突き合わせて粗利率を出すレイヤー。経理の月次クローズを待たず、進行中に粗利の悪化を捕まえられる状態を作ります。
レイヤー④ リソース・要員管理
商談確度を加味した3か月先までの要員需要予測、メンバー別のスキルマトリクス、稼働率（チャージ率）の可視化を行うレイヤー。受注後すぐに必要になるアサインの属人化を防ぎます。
レイヤー⑤ 検収・納品ガバナンス
検収条件と納品物リストを商談時の合意から検収段階まで一貫して管理するレイヤー。「言った言わない」の検収紛争を防ぎ、追加請求の根拠データを保持します。
第3章：商談→案件→検収→請求を一気通貫にする運用設計
ステップ1：商談オブジェクトと案件オブジェクトのデータモデルを連結する
まず必要なのは、商談クローズ時に案件レコードを自動生成し、受注金額・取引先・想定工数を商談から引き継ぐ仕組みです。Salesforce Flowまたは AppExchangeアプリで実装し、営業から開発・Deliveryへの「ハンドオフのゼロ日化」を実現します。
ステップ2：タスク階層とWBSテンプレートを標準化する
案件種別ごとにWBSテンプレートを用意し、案件レコード生成時にデフォルトのタスク構造が展開されるようにします。「プロジェクト→マイルストン→タスク」の3階層が標準で、各層に予算工数・期限・担当者を持たせます。
ステップ3：工数入力の習慣化と稼働種別の標準化
15分単位のドラッグ操作・タスクとの自動紐づけ・稼働種別（新規／修正／会議／調整）を標準化することで、月末一括入力をやめ、日次入力に切り替えます。入力されたデータは即座にプロジェクト原価レポートに反映されます。
ステップ4：週次レビュー運用と予実管理
Deliveryマネージャー・PMが集まる週次レビューで、案件粗利ヒートマップ・ボトルネック工程・仕様変更累計影響をレビューする運用を立ち上げます。「赤」案件にはその場で責任者を付ける運用が、組織の規律を作ります。
ステップ5：検収条件の合意管理と請求連動
商談時の検収条件・納品物リストを案件レコードに紐付け、検収段階まで一貫して管理します。検収完了時には会計システムと連動して請求計上が走り、Project-to-Cashが完結します。
第4章：Salesforceネイティブで実装する3つのアプローチ
アプローチA：Salesforce標準機能でカスタムオブジェクト構築
案件・タスク・工数のカスタムオブジェクトをゼロから設計し、Apexトリガー・Flowで自動化を組む方法。柔軟性は高いものの、設計と保守のコストが大きく、PMやプロジェクト管理に必要な汎用機能（ガント・カレンダー・ヒートマップ等）はすべて自前で構築する必要があります。
アプローチB：AppExchangeのプロジェクト管理アプリを導入
プロジェクト管理に特化したAppExchangeアプリを導入する方法。商談・取引先と同じデータモデル上にタスク・工数・原価が乗るため、最短期間で受注後ガバナンスを立ち上げられます。Task Relayを含むネイティブアプリがこのカテゴリに該当します。
アプローチC：他SaaSとAPI連携
Asana／monday／Jiraなどの他SaaSをAPIで連携する方法。各部門が既に使っているツールを活かせる一方、データはSalesforceの外側に存在するためレポート統合に制約があり、ガバナンス面では限界があります。短期的には現実解、長期的には統合への移行が望ましい構成です。
受注後の工程管理は「Salesforceの内側にデータを取り戻すこと」から始まる。データが外にある限り、リアルタイム粗利・要員予測・経営ダッシュボードは絵に描いた餅。AppExchangeアプリの活用が、もっとも短期間で投資対効果を出すルート。
第5章：Task Relayが実現する受注後ガバナンス
Task Relayは、Salesforce上で動作するプロジェクト＆工数管理SaaSです。本記事で挙げた5つの追加レイヤーを、商談・取引先と同じデータモデルの上にネイティブ実装します。
- Salesforce商談クローズ→案件レコード自動展開（Sales→Deliveryハンドオフのゼロ日化）
- WBSテンプレート＋ガントチャートでタスク管理
- 15分単位×稼働種別×タスク連動の工数入力
- フルコスト単価による案件粗利のリアルタイム集計
- 商談確度を加味したリソース需要予測
- 検収条件・納品物管理から請求連動まで一気通貫
既存のSalesforceライセンス・権限・監査ログ・レポートをそのまま活用するため、Salesforce資産を最大化したまま受注後ガバナンスを立ち上げられます。
| 観点 | SalesCloud標準のみ | AppExchange活用 | 他SaaS連携 |
|---|---|---|---|
| 案件タスク管理 | 不可 | ◎ 標準提供 | △ 別ツール |
| 工数管理 | 不可 | ◎ 同一画面 | △ API連携 |
| プロジェクト原価 | 不可 | ◎ リアルタイム | △ 月次集計 |
| ガバナンス | 商談まで | ◎ 受注後まで | △ サイロ化 |
| 立ち上げ期間 | 不可 | ○ 1〜3か月 | △ API設計次第 |
| Salesforce資産活用 | ○ | ◎ | △ |
まとめ：商談クローズはゴールではなく、受注後ガバナンスのスタート
受注後の工程管理は、SalesCloudの守備範囲の外にある領域ですが、Salesforce導入企業にとっては「資産を最大化できるかどうか」を分ける最重要テーマです。Excelと他SaaSで分断したまま回している限り、進行中の粗利・要員予測・経営判断に必要なデータは集まりません。
まずは自社の受注後業務を本記事の5レイヤー（タスク／工数／原価／要員／検収）に当てはめ、どこがSalesforceの外側に流れているかを点検してみてください。優先順位の高いレイヤーから1つずつ取り戻すことが、受注後ガバナンス確立への最短ルートです。
商談→案件→検収→請求を、
Salesforceひとつで一気通貫に。
Sales Cloudの先で起きているデータ分断を、ネイティブアプリで解消するTask Relay。30分のオンラインデモで、貴社の受注後ガバナンス設計をご紹介します。