工事進捗管理システムとは：PMU向け2026年ガイド

1つの都市に3基の地下貯留槽があります。小さな2基は完成しています。都市に約束された貯水量の大半を担う大きな1基は74%です。3基を平均すると、この都市の進捗は91.33%と報告されます。各貯留槽を提供する容量で加重すると、実態を正しく示す数値は75.70%です。

約16ポイントのこの差こそが、工事進捗管理システムが必要な理由のすべてです。スプレッドシートは文句も言わずにパーセンテージを平均し、担当者はその結果を善意で読み上げます。そして誰かが大きな貯留槽の前に立つまで、誰も気づきません。

このガイドは、こうしたシステムの仕様を定め、調達し、あるいは引き継ぐ立場の方々に向けたものです。PMU（プログラム管理ユニット）や PIU（事業実施ユニット）のプロジェクトディレクター、そして業務仕様書（TOR）を作成するコンサルタントの皆様です。私たちは運用者の立場から書いています。2026年7月から NexGenix は、パンジャブ開発プログラム（Punjab Development Program）の PDP Executive Monitoring Dashboard を移行、再設計し、運用しています。このシステムは52都市の下水道、排水、排水ポンプ場の工事を追跡しています。冒頭の貯留槽の例は、このシステム自身の計算方法の資料から引用したものです。

表計算と WhatsApp による報告がプログラム規模で破綻する理由

多くのプログラムは同じように始まります。各現場が数値を送り、写真は WhatsApp グループに投稿され、本部の誰かが週次会議の前にそれをすべてワークブックに書き写します。現場が5か所ならそれで回ります。50都市になると破綻し、しかも破綻する箇所はいつも同じです。

• 写真を証明できない。転送された画像からは、いつどこで撮影されたのかについて信頼できる情報は何も得られません。同じ施工途中の排水路が、3週連続で登場することもあります。
• パーセンテージが計測ではなく入力される。「排水路60%」は意見にすぎません。どの延長の60%で、誰が、いつ計測したのでしょうか。
• 規模の異なるものを平均して集計する。先ほどの貯留槽の例のとおりです。
• 履歴が消える。ワークブックには今週の数値は載っていても、先週の数値の方が高かったことや、誰がそれを変更したのかはほとんど残りません。
• 報告は構造的に遅れる。集約に2日かかれば、報告されるのは2日前のプログラムの状況です。

州レベルのプラットフォームがあっても、この必要性はなくなりません。パンジャブ州ではすでに、2016年から各部局が月次の進捗報告を提出している Smart Monitoring of Development Projects（開発事業のスマート監視）と、GIS に対応した Monitoring Observatory for Development Projects（開発事業モニタリング・オブザーバトリー）が運用されています。これらは数百の事業を横断的に把握するためのものです。プログラム独自のシステムは、その一段下で機能します。構造物ごとに、日ごとに、証跡を添えて。

工事進捗管理システムに必要な10の機能

資金の出し手が誰であっても、業務仕様書（TOR）が求める内容は驚くほど似ています。Web とモバイルのモニタリング・情報システム、GIS 対応の MIS、中央プラットフォームにデータを送る Android アプリ、ダッシュボード、マニュアル、研修です。KfW 開発銀行は 遠隔管理・モニタリング・検証に関するガイドブック まで公開しています。重要なのは名称よりも、システムの振る舞いです。私たちが必ず求める10の機能は次のとおりです。

1. 改ざんを検知できる現場の証跡

写真は、サーバーに届いた瞬間に証跡にならなければなりません。PDP の現場アプリでは、サーバーがすべての写真の画素にバナーを焼き込みます。プログラム、都市、職員、座標、パキスタン時間、そして職員・時刻・位置をハッシュ化して導いた短い検証コードです。サーバーは自身の時計で刻印するため、先週の火曜日に設定されたスマートフォンで日付を偽ることはできません。

注意点が1つあります。スラブの下や狭い路地では、スマートフォンが GPS の測位を得られないことがあります。その場合は座標をでっち上げるのではなく、「座標なし」と記録してください。

2. 二重登録しないオフライン現場アプリ

現場では電波が途切れます。常時接続が必要なアプリでは、職員はその日の夜に記憶を頼りに入力するようになってしまいます。PDP Field Progress アプリは、報告と写真を端末内に蓄積して後から同期します。各報告には固有の参照番号が付くため、再送しても同じ進捗が二重に登録されることはありません。

可能な場合は、入力を求めるのではなく計測しましょう。PDP アプリでは、下水管の進捗は、職員がスマートフォンの GPS を使って設計線形の上に描いた線から算出されます。パーセンテージを入力する人はいません。

3. 平均ではなく加重による進捗

貯留槽の例に戻り、順を追って見てみましょう。

1. 各構造物は、それぞれの単位で位置（施工済み量 ÷ 契約数量）を持ちます。貯留槽 A は1,000,000ガロンで、進捗は74%です。貯留槽 B（40,000ガロン）と C（30,000ガロン）は完成しています。
2. 単純平均は (74 + 100 + 100) ÷ 3 = 91.33% です。
3. 容量で加重すると、1,000,000 × 74 + 40,000 × 100 + 30,000 × 100 = 81,000,000 です。
4. これを総容量の1,070,000ガロンで割ると、75.70% になります。

小さな貯留槽は完成していますが、都市の新しい貯水量の大半は、完成していない1基に集中しています。コードにすると数行です。

// 1つの都市にある3基の地下貯留槽（容量はガロン、進捗は%）
const tanks = [
  { capacity: 1_000_000, progress: 74 },
  { capacity: 40_000, progress: 100 },
  { capacity: 30_000, progress: 100 },
];

const naive = tanks.reduce((sum, t) => sum + t.progress, 0) / tanks.length;

const weighted =
  tanks.reduce((sum, t) => sum + t.capacity * t.progress, 0) /
  tanks.reduce((sum, t) => sum + t.capacity, 0);

console.log(naive.toFixed(2), weighted.toFixed(2)); // "91.33" "75.70"

PDP の完全な集計は4段階です。構造物は、それぞれが提供するもので加重され、都市内のコンポーネントに集計されます。貯留槽はガロン、排水ポンプ場は湿式井の容量、排水路と下水管は延長（フィート）です。コンポーネントは、合計が100になるよう PMU が設定した重みで都市に集計され、都市は承認事業費でプログラムに集計されます。進捗値は保存せず、要求のたびに計算するため、ダッシュボード、PDF、データフィードの数値が食い違うことはありません。

もう1つ、大いに役立つルールがあります。承認された下限値です。幹部職員がある位置を検証すると、それ以降の報告はその値を下回ることができません。修正できるのは次官またはシステム管理者のみで、その変更は記録されます。本当に必要な訂正には署名が要るようになったのです。その手間は、あるべき場所にあります。

見出しのパーセンテージの背後にある計算式をベンダーが示せないなら、そのパーセンテージは飾りにすぎません。

4. Sカーブによる進捗管理：計画と実績

Sカーブは、累積進捗を時間に対して描いたものです。立ち上がりは緩やかで、中盤は急になり、終盤は緩やかに収束します。計画曲線と実績曲線を同じ軸に描くと、その縦の差がスケジュール差異となり、完成日が遅れる何か月も前に見えるようになります。

実績線には、記録された履歴が必要です。PDP は毎晩すべての位置のスナップショットを取り、Sカーブと「今週」のあらゆる数値は、そのスナップショットから読み出されます。

難しいのは計画線の方です。数百の契約パッケージを抱えるプログラムで、パッケージごとに資源を割り付けた工程表がそろっていることはまれです。そのため PDP の計画ベースラインは、目標日に向けてモデル化した曲線です。グラフにそう明記されている限り、それは正当な方法です。四半期ごとに実績線のすぐ上に来るよう描き直される計画線は、Sカーブがないよりも悪いものです。

5. 行政区分に沿って構成された GIS マップ

行政の担当者は行政区分で考えます。PDP のマップは管区から県、テシル、市町委員会へと絞り込め、すべての貯留槽、排水路、排水ポンプ場を現在の進捗とともに表示します。

マップはすぐに重くなります。PDP ダッシュボードで初期に行った作業の1つは、マップの初回読み込みデータを37 MBから9 MBに削減することでした。4G 回線では、これが担当者がマップを開くかどうかを左右します。ベンダーには、マップのデータ量を尋ねてください。

6. PMU 事務所向けのライブ活動ウォール

PDP Live は、現場報告を受信と同時に表示する大型スクリーン用のボードです。昼前になっても報告していない都市は、月次の審査ではなく、その場でウォール上に表れます。

PDP Live は、プッシュ接続を開いたままにするのではなく、約10秒ごとにサーバーをポーリングします。リアルタイム GPS トラッキングのアーキテクチャ に関する記事で説明しているとおり、プッシュがその複雑さに見合うのは、車両位置が絶えず流れ込むフリートマップのような場面です。報告が数件ずつ届く程度なら、ポーリングの方がシンプルで、見ている人には違いがわかりません。

7. 幹部がすでに使っている形式でのワンクリックレポート

朝のブリーフィングには、すでに決まった形とページ順があります。それを無視するシステムでは、数値が古いテンプレートに打ち直されることになります。PDP は、日次の現場進捗ブリーフを、幹部が使うスライドと同じレイアウトのワンクリック PDF として作成し、都市別、構造物の種類別、安全遵守状況別の PDF・Excel レポートもあわせて提供しています。

8. メニューではなくデータを絞り込むロールベースのアクセス制御

PDP には6つのロールがあり、担当都市だけを見る現場職員から、プログラム全体を見る幹部までをカバーします。データを絞り込むのはサーバーです。メニュー項目を隠すことは、アクセス制御ではありません。

9. 監査担当者にそのまま渡せる監査証跡

ダッシュボードでは、進捗の記録は追記専用で、履歴のあるアカウントは削除されず無効化されます。同じプログラムの契約・支払システムである PMIS は、4層の監査証跡を保持しています。決定、すべてのリクエスト、すべての行変更の前後の値、そしてログを封印する毎晩の SHA-256 ハッシュチェーンで、後から編集するとチェーンが壊れます。

10. 契約・出来高管理との連携

進捗管理が問うのは、どれだけ施工されたかです。契約・出来高管理が問うのは、どの控除を差し引いた後に、誰の承認で、いくら支払うべきかです。PDP では、これらは別々のシステムです。PMIS は各契約の数量明細書（BOQ）を4階層で保持し、9種類の控除をサーバーで計算し、出来高払いの各中間支払証明書（IPC）を11段階の承認ルートと承認後の1ステップに回付します。2026年10月13日からは州の財務管理システムとライブで連携しており、10月21日以降は承認済みの請求を自動送信しています。この境界は、初日から業務仕様書に明記しておきましょう。

アーキテクチャとデータモデルの要点

ダッシュボードは目に見える部分にすぎません。その数値を信じてよいかどうかを決めるのは、下にあるデータモデルです。私たちが期待するレコードと、それぞれを信頼できるものにするルールは次のとおりです。

技術スタックは、あえて地味なものにしておきましょう。PDP ダッシュボードは Node.js 20、Express、MySQL 8.0 で動作しています。コードは約128,000行、API エンドポイントは約210、テーブルは約52です。元のチームが去った後も、何年にもわたって誰かがこれを保守します。一般的な技術を使えば、その担い手の層が広がります。287テーブルの本番 MySQL データベースを最適化して得た教訓 でもわかったとおり、インデックスを意図的に設計すれば、この規模でも MySQL には十分な余裕があります。そして現場アプリをアプリストア以外で配布するなら、サーバーに最小バージョンチェックを設けてください。

報告を止めずに稼働中の行政システムを引き継ぐ

行政の監視システムの多くは、新規に構築されるのではなく引き継がれるものです。2026年7月の PDP もそうでした。元のプラットフォームは Technology Hive が開発したもので、NexGenix がこれを引き継ぎ、パンジャブ州政府が管理するサーバーへ移行し、以来、再設計と運用を担っています。2026年7月24日の切り替えで生じた影響は、報告が減った1日だけでした。もう一度行うとしても、私たちは次の順序に従います。

1. 何かに手を付ける前に監査する。コード、スキーマ、実際に稼働しているものを読み、文書にまとめます。
2. 完全なコピーを移す。アプリケーション、データベースのダンプ、そしてすべての現場写真です。写真は通常、最も大きなデータで、PDP の場合は引継ぎ時点で13,595ファイルありました。
3. 書き込み元を常に1つに限る。旧サーバーが現場データの受け付けを止め、新サーバーが受け付けを始める瞬間を厳密に決めます。
4. 現場アプリを動かし続ける。切り替え前に新しいアドレスを知っているアップデートを配布し、その後、旧バージョンに更新を強制します。
5. 数えて検証する。レコード数、写真数、都市ごとの合計を、移行の前後で比べます。
6. その後、小さなリリース単位で改善する。各リリースでは先にバックアップを取り、元に戻す手段を用意します。これは、私たちの 4つのフェーズからなるカスタムソフトウェア開発プロセス を支える規律でもあります。

調達チェックリスト：工事進捗管理システムのベンダーに確認すべきこと

これらは、デモの場で、貴機関自身のデータを使い、実際の利用者が同席したうえで確認してください。

1. 「見出しのパーセンテージの計算式を見せてください」。重み、単位、そして貴機関の都市の1つを使った計算例が示されるはずです。
2. 「機内モードにして進捗を報告し、その後で再接続してください」。報告は端末内に蓄積され、1回だけ同期され、サーバーの刻印付きで届くはずです。
3. 「先月の写真を今日の写真として報告されるのを、何が防ぎますか」。答えは端末のメタデータではなく、サーバー側の刻印であるべきです。
4. 「現場職員としてログインしてください」。サーバーによって強制され、担当する現場だけが表示されるはずです。
5. 「ある構造物の進捗を下げてみてください」。検証済みの位置を下回る値は拒否されるか、誰がなぜ変更したかとともに記録されるはずです。
6. 「Sカーブの計画線はどこから来ていますか」。承認された工程表か、モデルであることが明記されたものであるべきです。
7. 「先週のブリーフィング資料を当機関の形式で作成してください」。開発者が必要なら、月曜日の朝には間に合いません。
8. 「当機関のサーバーで運用できますか」。ネットワークに何が必要かを尋ねてください。
9. 「引継ぎ時に何を受け取れますか」。ソースコード、スキーマのドキュメント、ユーザーマニュアル、導入手順、研修を、契約書に明記してください。
10. 「稼働中のシステムに変更をどのようにリリースしますか」。バックアップ、ロールバックの手段、変更履歴を確認してください。

工事進捗管理システムの危険信号

• 裏付けとなる数量がなく、パーセンテージを入力するだけの進捗報告。
• サーバーによる刻印がなく、スマートフォンのギャラリーから写真を受け付ける仕組み。
• ベンダーの誰も手計算で導けない見出しの数値。
• 提出済みの進捗に付いている削除ボタン。
• サンプルデータでしか動かないデモ。
• ソースコードとデータの所有者について、明確な回答がないこと。

私たちが取引を見送る決め手になるのは、削除ボタンです。履歴を上書きできるようになった時点で、システム内のあらゆる数値が交渉の対象になってしまいます。

PDP パンジャブ：52都市の工事進捗を管理

パンジャブ開発プログラム（PDP）は、パンジャブ州25県の52都市、約700万人が暮らす地域で、下水道、雨水排水、排水ポンプ場のインフラを整備しています。2026年11月時点で、394の契約パッケージにわたり、承認されたプログラム事業費は約3,080億PKRです。パンジャブ州政府の地方自治・コミュニティ開発局（Local Government & Community Development, LG&CD）が設置したプログラム管理ユニット（PMU）は、2つのシステムを使っています。

• PDP Executive Monitoring Dashboard（Web と Android 現場アプリ）は、物理進捗、証跡、マップ、レポートを扱います。2026年11月時点で、約33,000枚の現場写真（その大半が位置情報付き）を保持し、6つのロールと、27の Web ページにわたる11のモジュールを備えています。現場アプリのバージョンは2.9.0です。
• PMIS（Project/Contract & Payment Management System） は、BOQ、出来高払いの中間支払証明書、控除、財務管理システムとの連携を扱います。テーブル数は70以上、本番リリースは45回以上で、承認ルートは2026年10月24日から画面上で設定できるようになっています。

両システムとも、元のプラットフォームは Technology Hive が開発しました。両システムはパンジャブ州政府が管理するサーバーへ移行され、2026年7月から NexGenix が再設計と運用を担っています。

私たちが伝えたい教訓は、定着についてです。幹部が独自のスライドレイアウトで使う朝のブリーフのように、担当者がすでに使っている文書を作り出すシステムは、ほとんど研修なしで使われるようになります。そうした機能を早い段階で作りましょう。ダッシュボードは後からでも構いません。

画面とタイムラインは PDP Executive Monitoring Dashboard の導入事例 で、承認ルートと財務連携は姉妹編の PMIS 契約・IPC 出来高払いシステムの導入事例 でご覧いただけます。同様のシステムをご検討中でしたら、官公庁向けソフトウェア開発 のページで、私たちが PMU とどのように協働するかをご紹介しています。

よくあるご質問

工事進捗管理システムとは何ですか？

開発事業の工事の物理進捗を写真証跡とともに現場から記録し、ダッシュボード、マップ、レポートに集計するソフトウェアです。優れたシステムは、各構造物が提供するものに応じて進捗を加重し、すべての数値の履歴を保持します。

M&E システムにおけるモニタリングと評価の違いは何ですか？

モニタリングは、工事の進行中に進捗を継続的に追跡します。施工した数量、支出した金額、スケジュール差異です。評価は、モニタリングで収集したデータを使い、決められた時点で振り返って、プログラムが意図した成果を達成したかどうかを判断します。

位置情報付きの写真は、官公庁の工事の進捗をどのように裏付けますか？

現場アプリからの各写真は構造物と進捗記録に紐付けられ、サーバーが職員、座標、時刻を刻印します。これにより審査担当者は、写真が正しい日に正しい現場で撮影されたことを確認できます。

工事進捗管理におけるSカーブとは何ですか？

計画ベースラインと実際の工事について、累積進捗を時系列で示すグラフです。2本の線の差から、プロジェクトが工程よりどれだけ進んでいるか、あるいは遅れているかがわかります。

工事進捗管理システムを政府自身のサーバーで運用できますか？

はい。そして多くの政府機関にとっては、そうすべきです。PDP のシステムは、パンジャブ州政府が管理するサーバー上で稼働しています。インターネット接続の制限と、機関自身が管理するバックアップを前提に計画してください。

工事進捗管理システムと、契約・出来高管理システムはどう違いますか？

工事進捗管理システムは、どれだけ施工されたかを計測します。契約・出来高管理システム（PMIS と呼ばれることが多い）は、支払が行われる前の BOQ、出来高払いの中間支払証明書、控除、承認を扱います。大規模なプログラムには両方が必要です。

ダッシュボードではなく証跡から始める

結局のところ、あらゆる工事進捗管理システムは、1つの問いで評価されます。担当者が会議で数値を口にしたとき、誰かがそれを証明できるか、です。まず証跡の連鎖、加重の方法、監査証跡を仕様に定めてください。グラフは簡単な部分です。

---

NexGenix エンジニアリング・チームによるレビュー済み。編集ガイドラインでは、情報源の検証、AI 支援の開示、誤りの訂正をどのように行っているかをご確認いただけます。