建設現場の進捗・出来高管理をデジタル化する|項目定義から定着KPIまでの進め方
建設現場の進捗・出来高管理は、いまだにExcel・紙・口頭のやり取りに依存し、締めまで実績が見えない、出来高査定に時間がかかる、といった課題が残りがちです。管理ソフトを入れても定着せず元に戻ってしまうのは、ツールの問題ではなく運用の設計がないからです。本記事は、建設業のPM・現場監督・IT企画・DX推進担当に向けて、進捗・出来高をデジタル化する進め方を、データ項目の定義から入力の仕組み、承認フロー、可視化、定着KPIまで、プロジェクト推進の型として整理します。
なぜ建設現場の進捗・出来高管理はデジタル化しても回らないのか
建設現場の進捗管理と出来高管理は、いまだにExcel・紙・口頭のやり取りに強く依存しています。日々の出来形は職長のメモや写真に残り、それを事務所で誰かが集計し直し、月末になってようやく実績が見える。こうした運用では、遅れの兆候に気づくのが遅れ、出来高査定にも時間がかかります。
多くの現場が「管理ソフトを導入すれば解決する」と考えます。しかし実際には、ツールを入れただけでは定着せず、二重入力が増えて現場の負担が上がり、いつの間にか元のExcelに戻ってしまう例が後を絶ちません。問題はツールの有無ではなく、「何のデータを、誰が、いつ、どう入力し、どう承認して、どう使うか」という仕組みが設計されていないことにあります。
本記事では、建設現場の進捗・出来高をデジタル化する進め方を、プロジェクト推進の型として整理します。デジタル化すべきデータの整理から、データ項目の定義、現場が入力し続けられる仕組みと承認フロー、ダッシュボードでの可視化、そして定着させるためのKPIまで、順を追って解説します。ツール選定の前に押さえるべき「設計」の話です。
何をデジタル化するのか ― 進捗データと出来高データの整理
「進捗」と「出来高」は混同されがちですが、性質の異なる2種類のデータです。デジタル化を始める前に、この2つを分けて捉えることが出発点になります。
| データ | 何を表すか | 主な用途 | デジタル化の勘所 |
|---|---|---|---|
| 進捗データ | 計画に対して工事がどこまで進んだか(進捗率) | 工程管理・遅れの早期検知 | 計画(工程表)と実績を同じ粒度で比較できる形にする |
| 出来高データ | 実際に完成した工事の量と、それに対応する金額 | 出来高査定・請求・原価管理 | 数量の根拠(数量拾い・写真)とセットで記録する |
進捗データは「予定に対する実績」を、出来高データは「完成した量とその金額」を扱います。両者は連動しますが、必要な精度も承認の重さも異なります。進捗は日次で速報性が重視され、出来高は査定・請求の根拠になるため正確性と証跡が重視されます。この違いを踏まえずに一つのフォーマットで扱おうとすると、入力が煩雑になり定着しません。
出来形・出来高・進捗率の違い ― 現場で混ざりやすい3つの言葉
現場では同じような意味で使われることがありますが、この3つの言葉が指すものは異なります。まず意味をそろえておきます。
| 用語 | 指すもの | 確認のしかた |
|---|---|---|
| 出来形 | 工事でできあがった部分の形状・寸法 | 設計図書で定めた基準に対して、測定値と写真で確認する(出来形管理) |
| 出来高 | できあがった部分を数量と金額に換算したもの | 数量の根拠と単価から算出し、査定・請求に使う |
| 進捗率 | 計画に対してどこまで進んだかの割合 | 数量ベースか工数ベースかを先に決めて算出する |
3つは「形が基準どおりにできているか」「それがいくら分になるか」「計画に対してどこまで来たか」の順につながります。ただし、確認する人も使う場面も異なります。出来形は品質の確認として現場で測り、出来高は査定と請求の根拠として金額に置き換え、進捗率は工程の遅れを見るために計画と突き合わせます。
進捗の確認を写真や目視の報告だけに頼ると、その記録は出来高の数量と結びつきません。「8割ほど終わった」という報告からは数量も金額も出せないため、締めの段階で数量を数え直すことになります。出来形を確認する時点で数量もあわせて記録しておけば、同じ記録から出来高と進捗率を算出できます。
進め方の型① データ項目を定義する
デジタル化で最初に失敗するのは、項目定義を曖昧にしたまま入力を始めてしまうケースです。「作業が終わったら報告する」という運用では、人によって粒度も表現もばらつき、結局は事務所での拾い直しが発生します。まず、何をどの単位で記録するかを定義します。
| 定義する項目 | 内容 | 曖昧だと起きること |
|---|---|---|
| 工種・作業の単位 | 進捗・出来高を計上する最小単位(WBS)をそろえる | 人により粒度が違い、集計できない |
| 数量の定義 | 何をもって『1』と数えるか(面積・本数・m³等) | 同じ作業で数え方が割れ、査定で揉める |
| 進捗率の基準 | 進捗率をどう算出するか(数量ベース/工数ベース) | 感覚報告になり、遅れが見えない |
| 証跡 | 写真・数量拾いなど、実績を裏づける記録 | 査定時に根拠を再収集する手戻り |
特に重要なのが、進捗・出来高を計上する最小単位(WBS)を計画と実績でそろえることです。工程表は工種単位なのに、実績報告は作業員の主観で上がってくる、という食い違いが「比較できないデータ」を生みます。計画時点で決めた単位のまま実績を記録できるようにすることが、後工程すべての前提になります。なお、WBSや数量の定義は工種や発注形態によって慣行が異なるため、自社の積算・査定の実態に合わせて設計する必要があります。
進め方の型② 現場が入力し続けられる仕組みと承認フロー
項目を定義できても、現場がデータを入力し続けられなければ意味がありません。デジタル化の成否の大半は、この「入力の負担をどこまで下げられるか」で決まります。
入力の負担を下げる
現場監督や職長は、そもそも入力作業のために現場にいるわけではありません。スマートフォンやタブレットでその場で記録できること、写真がそのまま数量や進捗の証跡になること、前日の入力をコピーして差分だけ直せることなど、「片手間でも続けられる」設計が欠かせません。PCに戻って改めて入力し直す運用は、ほぼ確実に形骸化します。
承認フローを軽く、しかし証跡は残す
出来高は査定・請求の根拠になるため、承認は避けて通れません。ただし承認を重くしすぎると、今度は承認者がボトルネックになります。日次の進捗は軽い確認にとどめ、出来高の確定など金額に関わる部分だけ承認を厚くする、といったメリハリが必要です。誰が・いつ・何を承認したかの証跡が自動で残る形にすれば、後からの照会にも耐えられます。
| 対象 | 入力のタイミング | 承認の重さ |
|---|---|---|
| 日次の進捗 | 作業終了時に現場でその場で記録 | 軽(職長/監督の確認) |
| 写真・数量の証跡 | 作業と同時に取得・ひも付け | 自動記録(改ざん防止) |
| 出来高の確定 | 締め・査定のタイミング | 厚(金額に関わるため多段承認) |
進め方の型③ ダッシュボードで可視化し、定着KPIで運用に乗せる
入力されたデータは、見える形にして初めて価値を生みます。ただし、ダッシュボードを作ること自体が目的化すると、誰も見ない画面が増えるだけになります。「誰が、どの判断のために見るか」から逆算して設計します。
可視化は『判断』から逆算する
経営層が見るのは全現場の進捗と収益の状況、現場所長が見るのは自現場の遅れと出来高、といったように、立場ごとに必要な情報は異なります。計画と実績の乖離、遅れている工種、出来高の進み具合を、それぞれの判断に必要な粒度で示す。すべてを1画面に詰め込むのではなく、役割ごとにビューを分けることが、実際に使われるダッシュボードの条件です。
計画と実績の乖離をEVM(アーンドバリュー)で見る ― PV・EV・ACの3つの値
EVM(Earned Value Management、アーンドバリューマネジメント)は、進捗を金額という共通の単位に置き換え、工程の遅れとコストの超過を同じ軸で見る手法です。工種ごとに進み方の単位が違っても、金額にそろえれば全体を一つの尺度で比べられます。出来高を金額で持つ建設工事とは相性のよい考え方です。
| 値・指標 | 意味 | 建設現場での読み替え |
|---|---|---|
| PV(計画値) | その時点までに完了している予定の作業の予算額 | 実行予算を工程表に割り付け、その時点までの予定分を積み上げた額 |
| EV(出来高) | 実際に完了した作業を予算額で評価した値 | 完了した数量に実行予算の単価を掛けた額 |
| AC(実コスト) | 実際にかかった原価 | 同じ時点までに発生した労務費・材料費・外注費などの原価 |
| SV=EV−PV、SPI=EV÷PV | 工程の差異。SPIが1未満なら計画より遅れている | 工程表どおりに出来高が上がっているか |
| CV=EV−AC、CPI=EV÷AC | コストの差異。CPIが1未満なら予算を超過している | 上がった出来高に対して原価がかかりすぎていないか |
EVMが機能する前提は、計画と実績が同じ単位と基準で記録されていることです。「進め方の型①」で決めたWBS・数量の定義・進捗率の基準が計画と実績でそろっていなければ、PVとEVを比べる土台がありません。進捗率が感覚的な報告のままではEVが信用できず、そこから計算するSPIやCPIも意味を持たなくなります。
最初から全工種に適用する必要はありません。金額の大きい工種や、遅れが利益に響きやすい工種に絞り、月次の出来高査定のタイミングでPV・EV・ACの3つを並べるところから始めるのが現実的です。ダッシュボードには指標の値そのものを並べるより、乖離が出ている工種がひと目で分かる形で示します。見る人が「どの工種に手を打つか」を判断できることが、前節で述べた逆算の起点になります。
定着させるためのKPIを置く
デジタル化は、導入した瞬間ではなく、現場が使い続けて初めて成功と言えます。そのため、システムの利用状況そのものをKPIとして観測します。入力率・入力の遅延・写真添付率などをモニタリングし、下がってきた現場に手を打つ。この「定着を管理する」視点があるかどうかが、一度きりの導入で終わるか、業務として根づくかの分かれ目です。
| KPIの種類 | 指標の例 | 見る目的 |
|---|---|---|
| 入力の定着 | 日次入力率・入力遅延日数 | 運用が形骸化していないかを早期に察知 |
| データの質 | 写真添付率・差戻し率 | 査定に耐えるデータになっているか |
| 業務効果 | 出来高査定の所要日数・拾い直し件数 | デジタル化が実際に効いているか |
よくある失敗パターンと回避策
建設現場の進捗・出来高デジタル化でつまずく典型パターンを整理します。多くは技術ではなく、進め方と定着の設計に起因します。
| 失敗パターン | 何が起きるか | 回避策 |
|---|---|---|
| ツール先行で導入 | 現場に合わず二重入力が発生し、元に戻る | 項目定義と運用設計を先に固めてからツールを選ぶ |
| 項目定義が曖昧 | データの粒度が揃わず集計・査定で手戻り | WBS・数量・進捗率の基準を計画時点で定義する |
| 承認を重くしすぎ | 承認者がボトルネックになり入力が滞る | 日次は軽く、金額に関わる部分だけ承認を厚く |
| ダッシュボードが目的化 | 誰も見ない画面が増える | 『誰のどの判断のためか』から逆算して設計 |
| 定着を放置 | 導入直後だけ使われ、数か月で形骸化 | 入力率などの定着KPIを置き、下がった現場に手を打つ |
まとめ:デジタル化は『入れる』ではなく『使われ続ける』まで設計する
建設現場の進捗・出来高管理をデジタル化する進め方の要点を整理します。
- 進捗(予定対実績)と出来高(完成量と金額)は性質の異なる2種のデータ。分けて捉える
- 最初にWBS・数量・進捗率の基準・証跡を定義する。曖昧さが拾い直しと査定の手戻りを生む
- 入力は『片手間でも続けられる』設計が要。承認は日次を軽く、金額に関わる部分だけ厚く
- ダッシュボードは『誰のどの判断のためか』から逆算し、役割ごとにビューを分ける
- 入力率などの定着KPIを置き、使われ続けているかを観測する。定着まで設計して初めて成功
建設現場のデジタル化でつまずく原因の多くは、ツールの性能ではなく、進め方と定着の設計にあります。何をデータ化し、誰がどう入力し、どう承認して、どの判断に使い、どう使われ続けるか。この一連の流れを設計し、現場に根づくまで走り切れるかどうかが、デジタル化を成果に変えられるかの分岐点になります。蓄積した進捗・出来高データは、やがて遅れの予測や査定の自動化といった、AIを前提にした業務の再設計にもつながっていきます。
次に読む記事
| 知りたいこと | 記事 |
|---|---|
| 建設DXの全体像とi-Construction | i-Constructionとは |
| BIM/CIMを工程・数量につなげる | BIM/CIMを進捗・出来高管理につなげる |
| 現場に定着させる打ち手 | BPRは「設計」より「定着」で決まる |
| 業務プロセスの棚卸しから始めたい | 業務プロセス棚卸しは「AI適用可否」で見直す時代 |
Alphaktで働くことに興味はありますか?
応募の前に、まず話すところから。「提言して終わり」ではなく実装まで走り切る現場で、いま何が起きているかをお伝えします。カジュアル面談から受け付けています。
話を聞いてみる →