施工管理システムは内製とパッケージ、どちらを選ぶべきですか？
結論は「業務単位で分ける」です。工程表・写真台帳・日報のように業界内で手順が標準化されている領域はパッケージ、原価と会計をまたぐ処理や自社独自の提出様式のように分岐が多い領域は個別開発。この線引きを最初に引かず、システム全体を1つの意思決定として扱うと失敗します。
判断軸は次の7つです。
| 判断軸 | パッケージが向く | 個別開発が向く |
|---|---|---|
| 業務の標準度 | 他社と同じ手順で回っている | 自社独自の様式・承認フローが定着している |
| 例外処理の量 | 例外がほぼない | 「この元請のときだけ」「この工種だけ」が複数ある |
| 既存システムとの位置関係 | 単独で完結する | 会計・積算・原価管理の間に挟まれている |
| 利用者の範囲 | 自社社員のみ | 協力会社・一人親方も入力する |
| 差別化の源泉か | 単なる事務処理 | 受注や粗利に直結する判断が含まれる |
| 法定基準への追従 | 公共工事の基準に沿う必要がある | 社内管理のみで外部基準に縛られない |
| 5年後の運用者 | 決まっていない | 社内に担当を置ける |
「差別化の源泉か」の欄が重要です。工程表の描画機能を自社で作っても競合優位にはなりません。一方、積算根拠から実行予算に落とす際の社内ルールは、その会社の粗利の作り方そのものです。ここを汎用パッケージの入力項目に押し込むと、結果としてExcelが生き残ります。
内製・パッケージ・部分開発は何が違うのですか？
3つの選択肢を同じ軸で並べると差が明確になります。
| パッケージ導入 | 部分開発（FDE型） | フルスクラッチ内製 | |
|---|---|---|---|
| 対象範囲 | 工程・写真・日報など標準業務 | 転記・書類生成など隙間の業務 | 施工管理業務全体 |
| 立ち上がり | 契約後すぐ試用できる | 対象を絞れば短期で稼働 | 要件定義から段階的 |
| 自社様式への適合 | 標準機能の範囲内 | 自社様式そのまま再現できる | 自由 |
| 撤退のしやすさ | 解約で終わる | 対象が小さいため差し替えやすい | 撤退コストが最も高い |
| 運用に必要な人材 | 社内推進担当 | 発注側は業務担当のみで可 | 開発・保守の内部体制 |
| 基準改定への追従 | ベンダー側が対応 | 対象範囲のみ自社責任 | すべて自社責任 |
多くの会社が見落とすのは中央の列です。基幹の施工管理はパッケージに任せたまま、「パッケージから出力したCSVを会計ソフトの様式に直す」「元請提出用の様式に転記する」といった隙間だけを個別開発する構成が取れます。
エクサテックが株式会社イーリアルティ様に構築した転記エージェントは、この中央の列にあたる案件です。リーシングサービスと基幹システムの間で発生していたデータ転記を自動化しました。不動産の事例ですが、「2つのシステムに挟まれた人手の転記」という構造は施工管理でもまったく同じです。
パッケージで十分なのはどんな会社ですか？
次の項目にすべて「はい」と答えられるなら、まずパッケージを試すべきです。
- 現場からの日報・写真提出のルールが、監督者によって変わらない
- 実行予算の作り方が社内で1通りに統一されている
- 会計ソフト・積算ソフトへの入力を、パッケージの出力形式のまま流し込める
- 元請や発注者から求められる提出様式が、標準テンプレートで足りている
- 協力会社にIDを配り、ログインして入力してもらう合意が取れている
とくに最後の項目が現実的な壁になります。協力会社側が別の元請から別のシステムを指定されている場合、入力先が増え続け、結果として電話とFAX、LINEに戻ります。この場合は「協力会社に入力させる」前提を捨て、送られてきた写真や書類を自社側で自動的に処理する構成に切り替えたほうが定着します。
フルスクラッチ内製が正解になるのはどんな場合ですか？
内製が合理的なのは、次の条件が重なったときだけです。
- 対象業務が受注・粗利に直結し、手順が自社固有である
- その手順を今後も変える気がなく、標準に寄せる意思がない
- 5年後に保守を担当する人・体制が具体的に決まっている
- 法定基準や発注者要件への追従が発生しない領域である
3が最も軽視されます。作った時点では動いていても、担当者の退職、OSやブラウザの更新、連携先ソフトの仕様変更で止まります。施工管理は年度をまたいで継続する業務なので、繁忙期に止まると復旧を待てません。「作れるか」ではなく「止まったときに誰が直すか」で判断してください。
4も見落としがちです。公共工事の写真管理は、国土交通省「デジタル写真管理情報基準」（令和5年3月）で、写真区分→工種→種別→細別の階層により分類することが定められています。工種・種別・細別の入力要否は写真区分によって異なり、基準自体も改定されます。この追従を自社で背負う判断には、それなりの覚悟が必要です（基準への適合可否の最終判断は発注者・監督員が行います）。
「間」の選択肢としての部分開発（FDE）とは何ですか？
フォワードデプロイエンジニアリングとは、開発者自身が発注者の現場に入り、実際の業務手順と入力操作を観察しながら、動くものを短いサイクルで作って検証していく開発の進め方です。要件定義書を受け取って持ち帰る形ではなく、現場で仕様が確定していきます。
施工管理領域では、次のような対象に向いています。
- パッケージや積算ソフトの出力を、会計ソフト・原価管理の様式に変換する処理
- 元請ごとに異なる提出様式への書類生成（自社の実績データから出力する）
- 現場から届いた写真・書類の仕分けと台帳への反映
- グリーンファイル（安全書類）の作成・更新の下書き生成
- 見積・実行予算の作成時に、過去案件の歩掛や単価を引き当てる処理
いずれも「業務全体」ではなく「業務の間」です。だからこそ開発対象が小さく、うまくいかなければ捨てられます。
判断はどの順序で進めればよいですか？
比較表を作る前に、現場を見る工程を入れてください。エクサテックが案件の入口で取る手順は次の通りです。
- 現場と事務の両方に同行し、入力操作を観察する。 何を使っているかではなく、どの画面からどの画面へ、どのタイミングでコピーしているかを見ます。ヒアリングでは「Excelで管理しています」までしか出てきません。
- 1件の工事で発生する書類とデータの経路を1枚に書き出す。 受注→実行予算→発注→出来高→請求→原価集計まで、書類名とその入力者、入力先システムを線でつなぎます。ここで人手の転記が何本あるかが見えます。
- 転記1本ごとに「なぜ人が挟まっているか」を確認する。 様式が違うだけなのか、途中で人の判断が入っているのか。判断が入る転記は自動化の設計が変わります。
- 標準機能で吸収できる線を引く。 経路図の上で、パッケージが担える区間と、担えない区間を色分けします。この時点で機能一覧の比較が意味を持ちはじめます。
- 担えない区間だけを、個別開発の対象候補として並べる。 対象が1つに絞れるなら、そこから着手します。
- 1業務で稼働させ、現場が使い続けるかを確認してから範囲を広げる。
イーリアルティ様の案件でも、契約の前段階から何度も現場に足を運び、困りごとを理解するところから始めました。その結果分かったのは、業務マニュアルが未整備だったこと、そして転記を自動化することでマニュアル作成の必要自体が減ったことです。「先にマニュアルを整備してからシステム化」という順序が、必ずしも正しいとは限りません。
内製かパッケージかの判断で、よく失敗するのはどこですか？
現場で実際に詰まる論点を挙げます。
1. 入力の二重化を残したまま導入する
パッケージに入力しても、会計や発注者提出用に別途Excel入力が残ると、現場は「二重に入れるなら元のExcelだけでいい」と判断します。導入判断の時点で、転記が残る箇所を経路図で潰しておく必要があります。
2. 原価集計の締めタイミングを合わせていない
施工管理側の出来高計上と、会計側の締めが月内でずれると、原価が合いません。合わないと現場は数字を信用せず、独自のExcelを再び作ります。連携仕様より締めのルールが先です。
3. 例外処理の量を過小に見積もる
「基本はこの流れです」と説明された後に、元請別・工種別・地域別の例外が出てきます。例外は現場で観察しないと出てきません。ヒアリングだけで進めた要件定義は、稼働後に必ず膨らみます。
4. 積算のExcelを軽視する
歩掛や社内単価が長年のExcelに蓄積されている場合、そのExcelがその会社の資産です。パッケージの入力項目に合わせて作り直すと、精度が落ちます。Excelを入力元として残し、そこから読み取る設計のほうが定着します。
5. 通信環境を前提に置く
山間部や地下、鉄骨内での作業でモバイル回線が不安定な現場では、オンライン前提の入力は成立しません。オフライン入力と後送の設計が必要かどうかは、現地で確認する項目です。
6. 「2024年問題」への対応を機能の話に矮小化する
2024年4月1日から建設業にも時間外労働の上限規制が全面適用され、原則は月45時間・年360時間、特別条項がある場合でも年720時間以内、単月100時間未満（休日労働含む）、複数月平均80時間以内、月45時間超は年6か月までという上限があります（厚生労働省「建設業・ドライバー・医師等の時間外労働の上限規制」）。勤怠機能を入れれば数字は見えますが、書類作成の総量が減らなければ時間は減りません。見えるようにする機能と、作業を減らす仕組みは別物です（36協定の運用や適用可否の判断は社労士等の専門家にご確認ください）。
部分開発でも解決できないことは何ですか？
正直に書きます。
- 現場の運用ルールが決まっていない業務は、自動化してもぶれます。 ただし「マニュアルを完成させてから」ではなく、対象を絞って自動化しながら決めていく方法は取れます。
- 人の判断が本質の工程は置き換えられません。 施工計画の妥当性判断、近隣対応、協力会社の与信判断などです。自動化できるのは、判断に必要な情報を集めて並べるところまでです。
- 手書きの品質が低い書類は、読み取り精度が上がりません。 潰れた文字や斜めの撮影は限界があります。入力側の様式や撮影ルールをそろえる作業が先に必要です。
- 既存システムがデータを外に出せない場合、連携できないことがあります。 APIもエクスポートも無い製品は、まず出口の確認から始めます。
- 公共工事の基準適合を保証することはできません。 基準に沿った出力形式は実装できますが、適合の最終判断は発注者・監督員が行います。
- 入力を「する人」がいない業務は自動化できません。 誰も写真を撮っていない現場に、写真台帳の自動生成は効きません。
費用の目安については、1業務に絞った小さな範囲なら比較的小さい投資から着手でき、対象範囲が広がるにつれて増えます。金額は業務の複雑さ、入力データの状態、既存システム連携の有無、求める精度で変わるため、対象を1つ決めてから試算するのが現実的です。
まとめ
- 内製かパッケージかは全社一括で決めるものではなく、業務単位で線を引く
- 標準度が高く外部基準に沿う領域（工程表・写真管理）はパッケージ、システムの間に挟まれた転記や自社様式の書類生成は個別開発が向く
- 「内製」と「パッケージ」の間に、隙間だけを個別開発する部分開発（FDE）という選択肢がある
- 判断は機能比較表からではなく、現場での入力操作の観察と、1件の工事のデータ経路を1枚に書き出す工程から始める
- フルスクラッチ内製の可否は「作れるか」ではなく「5年後に誰が直すか」と「外部基準の追従を背負えるか」で決まる
よくある質問
Q. 施工管理システムは内製とパッケージのどちらが安く済みますか？
A. 対象業務を1つに絞れるならパッケージ、または部分開発のほうが安く済みます。逆に工程・原価・写真・書類すべてを内製すると、開発費だけでなく法定基準や発注者要件への追従コストが毎年発生します。総額は開発費より「誰が5年運用するか」で決まります。
Q. パッケージを入れたのに現場が使わない原因は何ですか？
A. 多くは入力の二重化です。パッケージに入力しても会計や積算、発注者提出物のために別途Excelへ転記が残ると、現場は元のExcelだけを使い続けます。パッケージ導入時は機能比較より、転記が残る箇所を先に洗い出すべきです。
Q. 内製とパッケージの中間の選択肢はありますか？
A. あります。工程表や写真台帳などの標準的な機能はパッケージに任せ、システム間の転記や自社様式の書類生成だけを個別開発する構成です。開発対象が小さく、置き換えや撤退も比較的容易です。
Q. 判断にはどれくらいの調査が必要ですか？
A. 最低限、現場と事務の入力操作を実際に観察し、1件の工事で発生する書類とデータの経路を一枚に書き出す工程が必要です。機能一覧の比較表だけでは、転記が残る箇所と例外処理の量が見えず、判断を誤ります。
Q. 工事写真の管理は内製できますか？
A. 技術的には可能ですが、公共工事では国土交通省「デジタル写真管理情報基準」（令和5年3月）に沿った分類が求められ、基準改定への追従が続きます。写真管理は既存製品に任せ、社内様式の書類生成側を個別開発するほうが合理的な場合が多いです。
ご相談について
エクサテックは、不動産・建設業の現場に入り、実際の入力操作を見てから設計する進め方を取っています。「パッケージを検討しているが、自社の様式に合うか判断がつかない」「どこまで既存ソフトで足り、どこを作るべきか整理したい」という段階でもご相談いただけます。まずは1件の工事でどこに人手が挟まっているかを一緒に書き出すところから始めましょう。
