工事の案件管理システムを設計する｜引合から施工・検収・請求までのパイプライン

「案件一覧を開いても、見積中の案件と施工中の案件が混ざっていて、今月の受注見込みが分からない」「完工したのに請求が漏れていた」——工事の案件管理をシステム化しようとすると、この2つの課題に必ず突き当たります。

工事案件のパイプライン設計とは、引合から検収・請求までの長い進行を、どの単位で区切り、何をもって次に進んだと判定するかを決める作業です。ステージの名前を並べる作業に見えますが、実際には「誰がどのタイミングで何を判断するか」を決める業務設計そのものです。

この記事では、HubSpotを例に工事案件のパイプラインをどう組むかを、具体的なステージ案とともに解説します。汎用的な営業パイプラインをそのまま当てはめる方法ではなく、建設業の時間軸に合わせて分割する考え方をお伝えします。

建設会社・工事会社で案件管理の仕組みを作る立場の方、既にCRMを導入したがステージが機能していない方に向けた内容です。次の4点がわかります。

• 1本のパイプラインが破綻する理由 ── ヨミのレポートが施工中の案件で埋まり、失注と工事中止が同じ扱いになる構造を説明します
• 引合〜受注と着工〜検収の具体的なステージ案 ── そのまま検討のたたき台にできる粒度で提示します
• ステージの定義を「事実」で書く方法 ── 「詰めている」ではなく「何が起きたら次へ進むか」で書くと運用が揃います
• 出来高請求と失注理由の持たせ方 ── 請求漏れの検知と、負け筋の分析を同じ仕組みで実現します

読み終える頃には、自社の工事案件をどのステージで区切るかのたたき台が作れる状態になります。ぜひ最後までご確認ください。

1本のパイプラインに詰め込むと何が起きるか

まず、多くの会社が最初にやってしまう「引合から検収までを1本で管理する」構成の問題点を整理します。

これは特定の企業の実装ではなく、建設業でよく出てくる進行を一般化した設計例です。そのまま検討のたたき台として使える粒度で示しています。

ステージが15前後に膨らむ

引合受付、現地調査、積算、見積提出、交渉、受注、契約、着工準備、着工、中間出来高、完工、検収、引渡し、請求、入金。素直に並べると15ステージ前後になります。HubSpotのボードビューは横スクロールになり、1画面で全体を把握できなくなります。

受注確度のレポートが施工中の案件で埋まる

より本質的な問題はレポート側にあります。取引の金額と確度を集計すると、施工中の案件も同じ母集団に入ります。「今期の受注見込み」を出そうとしたのに、既に受注済みで施工中の金額が混ざり、営業会議で使えない数字になります。ステージごとの確度（%）を設定しても、受注後のステージは常に100%となるため、加重予測の意味がなくなります。

失注と工事中止が同じ扱いになる

1本にすると、クローズ（失注）が2つの意味を持ちます。見積段階で他社に決まった「失注」と、受注後に発注者都合で止まった「中止」です。この2つは原因も対策もまったく違うのに、同じステージに集約されると分析ができません。負け筋を改善したくても、母集団に中止案件が混ざっている限り正確な数字は出ません。

1本と2本の違いを整理する

部門ごとに不要な項目が視界に入り続ける

営業にとっては工程の進捗プロパティーが不要で、工事にとっては受注確度や競合先のプロパティーが不要です。1本のパイプラインでは両方が同じレコードに乗るため、どちらの部門にとっても「使わない項目が多い画面」になります。入力されない項目が増えると、入力されるべき項目まで信用されなくなります。全体のデータ構造は建設業のCRM活用ガイドで整理しています。

引合〜受注パイプラインのステージ設計

ここからは具体案です。まず営業側のパイプラインから見ていきます。

ステージ案（7ステージ）

ステージの定義は「営業の気持ち」ではなく「事実」で書く

ステージ設計でいちばん差が出るのがここです。「前向きに検討中」「詰めている」といった定義にすると、担当者ごとに判定がばらつき、集計した数字が意味を失います。

次に進む条件を、第三者が見ても同じ判定になる事実で書くことをおすすめします。「現地調査が完了した」「見積書を送付した」「注文書を受領した」であれば、誰が見ても同じ判定になります。この1点だけで、パイプラインのレポートが会議で使える精度になります。

書き換えの効果は、担当者が2名以上いる会社ほど大きく出ます。1人で回している間は本人の基準で一貫しますが、増員や引き継ぎが起きた瞬間に定義の揺れが表面化するためです。CRMの前提となる考え方は建設・建築業界のCRM導入でも整理しています。

「引合受付」の前を作らない

情報収集段階の案件まで登録すると、パイプラインが未確定の案件で膨れ上がります。入札情報や噂レベルの案件は、取引ではなくリードやメモとして持ち、参加を判断した時点で取引を作るほうが、母数の意味が保たれます。

確度は「ステージ確度」と「担当者確度」を分ける

HubSpotの取引ステージには確度（%）を設定できます。これは「このステージにある案件は平均して何%受注できるか」という統計値であり、個別案件の見込みとは別物です。特定案件の確度を担当者の感覚で表現したい場合は、別のプロパティー（例：受注確度A／B／C）を持たせると、統計値と主観を混ぜずに済みます。

着工〜検収パイプラインのステージ設計

受注後は別のパイプラインに移します。

ステージ案（5ステージ）

ステージ数を増やしすぎない

工程は現場ごとに違うため、細かく作りたくなります。しかし施工パイプラインで見たいのは工程の詳細ではなく、「請求できる状態か」「遅れていないか」の2点です。工程の詳細は施工管理システムの領域として割り切り、CRM側は5ステージ前後に抑えるほうが更新されます。

変更契約（追加・減額）の扱い

工事では途中の仕様変更が発生します。ここで元の取引の金額を上書きすると、当初契約額が分からなくなり、変更の履歴も残りません。変更分は商品項目として追加する方式であれば、当初契約額と変更後の合計を両方持てます。変更が大きい場合は別取引にする判断もありますが、レポート上で1つの工事として合算できなくなる点は理解しておく必要があります。

出来高請求をパイプラインに載せる

建設業の案件管理で最も実務価値が高いのが、請求予定の可視化です。

取引の金額欄1つでは表現できない

契約金額を着手金・中間金・完成時に分けて請求する場合、取引の金額プロパティーは合計値しか持てません。これでは「今月いくら請求するのか」が出せません。

商品項目（ラインアイテム）を請求回ごとに作成し、それぞれに請求予定日と請求ステータスを持たせる方式にすると、月別の請求予定が集計できます。契約総額は商品項目の合計として自動的に取引金額に反映されます。

請求漏れを検知する

請求予定日を持たせておくと、「予定日を過ぎているのに請求ステータスが未請求のまま」という条件でレポートが作れます。完工したのに請求書が出ていない、検収が終わったのに最終請求が漏れている、といった状態を人の記憶に頼らず検知できます。属人的な確認作業を仕組みに置き換えるという意味では、パイプライン設計の中で最も効果が分かりやすい部分です。

会計システムとの線引き

請求予定はCRMに、請求の実行と入金消込は会計システムに。この線引きを崩さないことをおすすめします。CRM側で請求書そのものを発行し始めると、会計の正が二重になり、監査対応で困ります。連携の考え方はCRMと会計システムの連携設計で整理しています。

失注・中止の理由設計と、そこから何を読むか

分けたパイプラインの効果が最も出るのが、負けの分析です。

失注理由は選択肢型で持つ

自由記述にすると集計できません。「価格」「工期」「実績・信用」「仕様が合わない」「予算未成立」「辞退（自社都合）」といった選択肢型のプロパティーで持ち、補足はメモに書く形にします。選択肢は最初から細かくせず、6〜8個程度から始めて、実データを見ながら足すほうが現場が迷いません。

「辞退」を負けと混ぜない

工期が合わない、体制が取れない、といった理由で自社から辞退した案件を失注として集計すると、受注率が実力より低く出ます。辞退は別カテゴリーとして持ち、「そもそも取りに行った案件」の母数で受注率を見るほうが実態に合います。

見るべきレポートは3つで足りる

レポートを増やすほど見なくなります。最初は3つに絞り、会議で実際に使われたものだけ残す進め方をおすすめします。同じ考え方は不動産の追客パイプライン設計でも扱っています。レポートの作り方はHubSpotレポート・ダッシュボード設計をご覧ください。

施工側で見るのは2つだけ

施工パイプラインで見たいレポートは、「今月・来月の請求予定額」と「完工したのに未請求の案件」の2つに絞れます。工程の遅れは施工管理システムや現場の判断で扱う領域であり、CRM側で細かく追おうとすると、更新されない数字が並ぶことになります。CRMのレポートは、CRMに正しく入っているデータだけで組むのが原則です。

パイプライン設計でよくある失敗

実際にご相談をいただく中で繰り返し出てくるつまずき方を、先にお伝えしておきます。

ステージを「部署の担当範囲」で切ってしまう

「営業部ステージ」「積算課ステージ」のように部署名でステージを作ると、複数部署が並行して動く案件を表現できなくなります。ステージは案件の状態であり、担当部署は別のプロパティーで持つべき情報です。誰が動いているかは担当者プロパティーで表現できます。

確度（%）を担当者が自由に書き換える

ステージ確度は「そのステージにある案件が平均して何%受注できるか」という統計値です。個別案件ごとに書き換えると、加重予測の意味がなくなります。個別の見込みを表現したい場合は、別のプロパティーを用意してください。

失注案件をレコードごと削除する

「もう終わった案件だから」と削除してしまうと、受注率も失注理由も計算できなくなります。失注はクローズであって削除ではありません。負けた案件こそ、翌年の提案の材料になります。同じ発注者から次の引合が来たとき、前回の失注理由が残っているかどうかで打ち手が変わります。

途中でステージを増やし続ける

運用しているうちに「この状態も表したい」とステージが増えていきがちです。増やす前に、既存ステージのプロパティーで表現できないかを確認してください。ステージの追加はレコード全件の再配置につながるため、後戻りのコストが最も高い変更のひとつです。

誰も見ないレポートを作り込む

きれいなダッシュボードを作っても、会議で使われなければ更新の動機が生まれません。レポートは会議の議題に紐づけて作るほうが定着します。「この数字を見て何を決めるのか」が答えられないレポートは、いったん作らない判断も有効です。

運用に乗せるための実装上のポイント

設計ができたら、次は動かし続けるための仕組みです。

受注時に施工側の取引を自動生成する

引合パイプラインの「受注」ステージに到達したら、ワークフローで施工パイプラインの取引を自動作成し、会社・コンタクト・現場の関連付けと、契約金額・工期・現場情報を引き継ぎます。手入力を挟むと、忙しい時期に必ず抜けます。

滞留を検知する

同じステージに長期間留まっている案件は、実質的に止まっています。ステージ変更日からの経過日数で判定し、一定日数を超えたら担当者に通知する仕組みを入れると、パイプラインの掃除が回ります。HubSpotではワークフローで日付プロパティーを基準にした遅延処理が組めます（HubSpotナレッジベース「ワークフローアクションを選択する」 2026年8月1日確認）。

必須項目を増やしすぎない

ステージ移動時に必須項目を設定できますが、増やすと現場はステージを動かさなくなります。動かさなければパイプラインは死にます。必須にするのは、そのステージの判定に不可欠な1〜2項目に留め、残りは推奨に留めるほうが結果的にデータが揃います。

権限とビューを部門ごとに用意する

パイプラインを分けたら、ビューも部門ごとに用意します。営業には引合パイプラインのボードと「見積提出から2週間以上動いていない案件」の一覧を、工事には施工パイプラインと「今月請求予定」の一覧を。開いた瞬間に自分の仕事が見える状態になっているかどうかが、ログインが続くかどうかを決めます。

権限については、最初から細かく絞る必要はありません。ただし、金額や粗利にあたるプロパティーを誰が見られるかだけは、運用開始前に決めておくことをおすすめします。後から絞ると「見えていたものが見えなくなった」という反発が起きやすいためです。

自社に合わせて調整する前提で始める

ここまで示したステージ案は、あくまで検討のたたき台です。工種や規模、公共・民間の比率によって最適な形は変わります。最初から完璧を目指さず、3か月運用して合わなかったステージを1つ統合するくらいの進め方が現実的です。ステージの統合は、レコード数が増えるほど難しくなるため、早い段階で見直す前提を持っておくことをおすすめします。

よくある質問

工事案件のパイプライン設計について、ご相談の場でよくいただく質問をまとめました。

Q1. パイプラインを2本にすると、案件の全体像が追えなくなりませんか。

引合側の取引と施工側の取引を関連付けておけば、どちらのレコードからも相互にたどれます。全体像を1つのレポートで見たい場合は、共通の工事番号をプロパティーとして両方に持たせ、その番号で名寄せする方法もあります。1本にまとめる代償（レポートが使えない、不要な項目が視界に入る）のほうが、実務上は大きくなりやすい部分です。

Q2. ステージはいくつが適切ですか。

引合側で6〜8、施工側で4〜6が扱いやすい範囲です。10を超えると、ボードが横に伸びて全体が見えなくなり、担当者もどのステージか迷い始めます。迷うステージが生まれた時点で、そのステージの定義が曖昧になっている合図です。

Q3. 変更契約は新しい取引にすべきですか、既存に足すべきですか。

原則は既存の取引に商品項目として追加する方式をおすすめします。1つの工事としての契約総額と粗利が追えるためです。ただし、当初契約と実質的に別工事といえる規模の追加（別棟の追加など）であれば、別取引にして関連付けるほうが実態に合います。判断の基準は「別々に採算を見たいかどうか」です。

Q4. 入札案件はどのステージから登録すべきですか。

参加を判断した時点からの登録をおすすめします。公告を見た全案件を登録すると、パイプラインの母数が実態と乖離し、受注率のレポートが意味を失います。参加判断そのものを管理したい場合は、取引ではなくリードやタスクとして持ち、参加を決めたら取引へ昇格させる二段構えが扱いやすいです。

Q5. 既にCRMを入れていますが、ステージが機能していません。作り直すべきですか。

作り直す前に、ステージの定義を書き出してみることをおすすめします。多くの場合、機能していない原因はステージ数ではなく、「次に進む条件」が主観で書かれていることにあります。定義を事実ベースに書き換え、必須項目を減らすだけで運用が戻るケースは少なくありません。それでも噛み合わない場合に、パイプラインの分割を検討する順序が安全です。ステージを減らす変更は既存レコードの再割り当てが必要になるため、影響範囲を先に確認してください。

まとめ

工事案件のパイプライン設計は、ステージ名を並べる作業ではなく、判断のタイミングを決める業務設計です。要点を整理します。

• 引合から検収までを1本にすると必ず破綻する。受注見込みのレポートが施工中の案件で埋まり、失注と中止が同じ扱いになります
• 引合側は7ステージ、施工側は5ステージが扱いやすい起点。工程の詳細は施工管理システムに残し、CRMは請求可否と遅延の把握に絞ります
• ステージの定義は事実で書く。「詰めている」ではなく「注文書を受領した」と書くだけで、集計の精度が変わります
• 出来高請求は商品項目で分割する。請求予定日を持たせると、請求漏れを人の記憶に頼らず検知できます
• 失注理由は選択肢型で持ち、辞退と分ける。負け筋の分析は、母数の定義が正しいことが前提になります

最初の一歩としておすすめしたいのは、「直近で失注した案件を5件並べ、どのステージまで進んでいたかを書き出す」ことです。どの段階で落ちているかが分かれば、必要なステージの粒度が具体的に見えてきます。全社の設計を描く前に、この5件から始めるほうが早く形になります。

そのうえで、まずは引合パイプラインだけを動かし、失注理由が集計できるようになってから施工側を足していく。段階的な進め方が現場に残ります。

自社の工事案件のステージ設計を具体的に検討したい場合は、StartLinkの無料相談でご相談ください。現状の進め方をうかがったうえで、設計の方向性をご提案します。