受託開発企業のSalesforce活用｜案件・工数・請求と顧客ポータル連携の設計
目次 クリックで開く
受託開発ビジネスにおいて、Salesforceは単なる「顧客管理ツール」に留まりません。商談の獲得から、エンジニアの工数管理、月次の請求処理、そして顧客への進捗公開までを一気通貫で管理する「ビジネスのOS」となり得ます。
しかし、多くの企業では、Salesforceに商談データは入っているものの、実際の開発工数はスプレッドシートで管理され、請求書は会計ソフトで手入力するといった「情報の分断」が起きています。本記事では、受託開発（請負・準委任）におけるSalesforceのデータアーキテクチャから、顧客ポータルを用いた透明性の高い運営手法まで、実務に即した「完全版」として解説します。
1. 受託開発におけるSalesforceの理想的なデータ構造
受託開発の管理をSalesforceで行う際、最も重要なのは「オブジェクト間のリレーション」です。ここを誤ると、後から案件別の採算（粗利）を出すことが困難になります。
1-1. 基本となるオブジェクト構成
標準オブジェクトとカスタムオブジェクトを以下のように組み合わせるのが一般的です。
- 商談（Opportunity）: 受注前のパイプライン管理。
- プロジェクト（Project / カスタム）: 受注後に作成。工期、予算、責任者を管理。
- タスク（Project Task / カスタム）: WBSに相当。進捗率を管理。
- 工数（Time Entry / カスタム）: 「誰が」「いつ」「どのタスクに」「何時間」使ったかの記録。
ここで重要なのは、商談とプロジェクトを1:1または1:Nで紐付けることです。保守運用の場合は、1つの商談（年間保守契約）に対して、毎月の「プロジェクト」が紐付く形になります。これにより、商談で決まった「受注金額」と、工数オブジェクトから算出される「原価（工数 × メンバー単価）」を比較し、リアルタイムで粗利を可視化できます。
Salesforceの標準機能である「商談」だけでは、受託開発の細かいフェーズ管理（要件定義、開発、テスト等）は不十分です。必ず「プロジェクト」という器をカスタムオブジェクトで作成し、そこに工数を積み上げる設計にしてください。
1-2. オブジェクト間のリレーション設計マップ
オブジェクト構成を列挙しただけでは、どのオブジェクトをどう紐付ければ採算が可視化できるかが見えません。下表は、受託開発でSalesforceの標準＋カスタムオブジェクトをどのように関連付けるかを、リレーション種別（主従／参照）、主要フィールド、採算可視化での役割とあわせて整理したものです。導入初期にこのマップを社内で合意してから設定に入ると、後からのデータ移行や粗利集計の作り直しを大幅に減らせます。
| 親オブジェクト | 子オブジェクト | リレーション種別 | 主要フィールドの例 | 採算可視化での役割 |
|---|---|---|---|---|
| 取引先（Account） | 商談（Opportunity）標準 | 標準（参照関係） | 商談名／受注予定日／受注金額／契約形態（請負／準委任） | 顧客別の受注ボリュームと粗利を集計する起点 |
| 商談（Opportunity） | プロジェクト（Project__c）カスタム | 参照関係（1:Nを許可） | プロジェクト名／工期／予算（受注金額の引継ぎ）／PM | 受注後の実行管理単位。1商談に対し保守の月次プロジェクトを複数持てる |
| プロジェクト（Project__c） | プロジェクトタスク（Project_Task__c） | 主従関係（マスタ削除でタスクも削除） | タスク名／予定工数／実績工数（ロールアップ）／進捗率／フェーズ（要件定義／開発／テスト） | WBS相当の粒度で進捗・予算消化を見る単位 |
| プロジェクトタスク（Project_Task__c） | 工数エントリ（Time_Entry__c） | 主従関係 | 担当ユーザー／日付／投入時間／メモ／承認ステータス | 原価計算の基礎データ。タスクへロールアップ集計させる |
| ユーザー（User）／社員マスタ（Employee__c） | 工数エントリ（Time_Entry__c） | 参照関係 | 時間単価（原価）／チャージャブル率／所属部門 | 「投入時間×単価」の単価側を提供。退職者単価も履歴で残す設計に |
| プロジェクト（Project__c） | 請求（Invoice__c）カスタム | 参照関係（1:Nを許可） | 請求月／請求額／請求ステータス（草案／承認済／発行済／入金済） | マイルストーン請求・月次請求の発行履歴を保持。会計ソフトとAPI連携 |
| 商談（Opportunity） | 契約（Contract）標準 | 標準（参照関係） | 契約期間／自動更新フラグ／請求サイクル | 準委任・年間保守の請求サイクル管理。電子契約サービスと連携 |
| プロジェクト（Project__c） | 顧客ポータル参照ビュー | 共有ルール＋プロファイル制御 | 顧客に見せる項目（進捗・残工数）／隠す項目（原価単価・社内メモ） | 同一レコードを社員と顧客で見え方を分ける。OWD非公開＋共有ルールが基本 |
この設計の肝は、プロジェクト→プロジェクトタスク→工数エントリを「主従関係」で繋ぐことです。これにより、ロールアップサマリーで「タスクごとの実績工数」「プロジェクトごとの累計工数・累計原価」を自動集計でき、Apexでの再計算を書く必要がなくなります。一方、商談→プロジェクト、プロジェクト→請求は「参照関係」（1:Nを許可）にしておくと、1つの大型商談に対して月次プロジェクト・月次請求を複数紐付ける運用に柔軟に対応できます。なお、社員マスタを Userオブジェクトに持たせるか専用カスタムにするかは、退職者の単価履歴をどう保持したいかで決まります。
2. 現場が「動く」工数管理の実装手順
受託開発企業のSalesforce導入が失敗する最大の要因は、現場エンジニアが「工数を入力してくれない」ことです。入力画面が複雑であればあるほど、データは形骸化します。
2-1. 入力負荷を軽減するUI設計
標準のレコード作成画面をエンジニアに使わせてはいけません。以下のいずれかの手法で「10秒以内に終わる」入力環境を構築します。
- 画面フロー（Screen Flow）の活用: カレンダー形式や、直近の担当タスクをプルダウンで表示し、時間を入れるだけの専用画面を作成します。
- 外部ツール連携: SlackやTeamsから「/time 2h」のように入力し、SalesforceのAPI経由で工数オブジェクトにレコードを作成させます。
2-2. 工数単価と原価計算のロジック
各ユーザー（エンジニア）のレコード、あるいは専用の「社員マスタ」に、標準単価（原価）を保持させます。工数レコードが作成された際、フロー（Flow Builder）を用いて以下の計算を自動実行します。
実績原価=投入時間×ユーザー別時間単価
このデータが「プロジェクト」オブジェクトに積み上がることで、PMは「予算消化率」を常に監視できるようになります。もし、既存の管理がExcelで限界を迎えているなら、Google Workspace × AppSheetでの業務DXと同様の思想で、モバイルからでも入力できるフロントエンドをSalesforce上に構築することが推奨されます。
3. 請求管理の自動化と会計ソフト連携
工数が正しく入力されていれば、月末の請求業務は「確認とボタン押し」だけで完了します。
3-1. 請求対象の自動抽出ロジック
受託開発には「請負」と「準委任」の2つのパターンがあります。
| 契約形態 | Salesforceでの管理ロジック | 請求のタイミング |
|---|---|---|
| 請負（一括/分割） | 商談またはプロジェクトの「マイルストーン」レコードの状態をトリガーにする。 | 検収完了日ベース |
| 準委任（工数清算） | 前月1日〜末日までに作成された、ステータスが「承認済み」の工数レコードを集計。 | 月次（翌月月初） |
3-2. 会計ソフトとのAPI連携
Salesforce上で確定した請求データを、わざわざ手入力で会計ソフトに打ち込むのは生産性が低いうえ、ミスの原因になります。特に、前受金の管理やサブスクリプション型の保守費用が混在する場合、手作業は限界を迎えます。
例えば、Salesforceとfreee会計を連携させる場合、単に金額を飛ばすだけでなく、「どの案件の工数に対する請求か」というタグ情報を保持させることが重要です。詳細なアーキテクチャについては、Salesforceとfreeeの請求連携アーキテクチャを参考に、債権管理の自動化を検討してください。
4. 顧客ポータル連携による「透明性」の確保
受託開発において、顧客から「今の進捗はどうなっているか？」「工数が予算をオーバーしていないか？」という問い合わせに対応する時間は、非生産的なオーバーヘッドです。これを「顧客ポータル」の開放によって解決します。
4-1. ツール選定：Experience Cloud vs 外部サービス
Salesforceのデータを顧客に見せる方法はいくつかあります。
| ツール | メリット | デメリット | 適したユースケース |
|---|---|---|---|
| Experience Cloud | 純正ツール。権限管理が非常に強固でカスタマイズ性が高い。 | ライセンス料が高い。構築に専門知識が必要。 | 大規模案件、長期的なパートナーシップ、BtoCポータル。 |
| Chobiit (by カンパネルラ) | 安価。設定が容易で、既存のSalesforce画面をそのまま公開できる。 | 高度なデザインカスタマイズには向かない。 | 中堅・中小企業の受託開発ポータル。 |
| 自作ポータル (Heroku等) | 完全に自由なUI/UX。 | 開発・保守コストが高い。 | 特定機能に特化した独自のサービス提供。 |
4-2. 顧客に見せるべき項目と制限
ポータルを開放する際、セキュリティ設定（OWD：組織全体のデフォルト）は必ず「非公開」にし、共有ルールで「その顧客の案件」だけが見えるようにします。また、「社内メモ」や「エンジニアの原価単価」はプロファイルレベルで参照不可に設定してください。
公開すべき情報の例：
- 現在のタスクステータス（進行中、レビュー中、完了）
- 今月の累計稼働時間（準委任の場合）
- 共有ドキュメント（Salesforce Filesへのリンク）
- 検収承認ボタン（顧客がポータル上で検収をクリックすると、Salesforce側の請求フラグが立つ）
このように顧客をプロセスに巻き込むことで、SFA/CRMとWebを統合した全体設計が完成し、コミュニケーションコストを劇的に削減できます。
5. セキュリティと権限管理のベストプラクティス
顧客ポータルを導入する場合、セキュリティ事故は会社の信頼を失墜させます。以下の3点は必ず実施してください。
- 外部ユーザーのプロファイル権限の最小化: 基本的に「作成」「削除」権限は与えず、「参照」と特定のカスタム項目への「編集（検収チェックなど）」のみに絞ります。
- 多要素認証 (MFA) の強制: 顧客がログインする際もMFAを必須にします。Salesforce Authenticator等の利用を促しましょう。
- Sandboxでの事前検証: 本番環境に反映する前に、必ずSandbox環境で「別の顧客のデータが見えないか」をテスト用ユーザーでログインして確認してください。
まとめ：受託開発の「ブラックボックス」を解消する
受託開発の現場において、案件・工数・請求をSalesforceで統合することは、単なる効率化以上の意味を持ちます。それは「収益の可視化」であり、「顧客への信頼提供」です。
一気に全てをシステム化するのが難しい場合は、まず「工数入力の定着」から始め、次に「会計連携による請求の自動化」、最後に「顧客ポータルでの情報公開」と、ステップを分けて進めることをお勧めします。公式サイトのヘルプや開発者ドキュメントを参考に、自社の業務フローに最適な「プロジェクト管理オブジェクト」を設計してみてください。
受託開発のSalesforce活用をfreee × kintone × Claude Codeで統合管理する
受託開発企業のSalesforce案件管理にfreeeとkintoneを統合することで、営業・開発・経理の三部門が同じデータで動く体制が整います。freeeの工数・外注費・請求データをSalesforceの案件コストとして連携させれば、案件ごとの実績粗利をリアルタイムで把握できます。kintoneの開発タスク管理データ（スプリント進捗・バグ件数・残工数）をSalesforceのサービス雲レコードに同期することで顧客向けダッシュボードへの表示も可能です。Claude Code × Salesforce MCPサーバー構成ではfreee・kintone・Salesforce APIの三者連携スクリプトをMCP経由で設計・実装でき、受託開発特有の「変更指示による追加見積→請求」フローの自動化も対応できます。
Salesforce活用・営業DXとデータ連携のご相談
Salesforceの定着支援や営業プロセスの可視化、基幹・会計システムとのデータ連携までをまとめて支援します。現在の設定や連携方式が最適かを確認したい、という導入前後のセカンドオピニオンにも対応しています。