小さな工事会社の
データ基盤をどう作るか。

「小さなsukuna」を作るだけでは、
現場の仕事はつながり切らない。

デジタル庁の記事が紹介するsukunaは、既存システムのデータを収集・蓄積・加工して、分析に使えるようにする基盤です。日々の受注入力や現場の配員そのものを回すアプリとは役割が違います。[1]

工事会社への応用では、業務を記録・更新する仕組みと、記録を横断して判断する仕組みの両方を考える必要があります。ただし、両方を新しく作り直す必要があるとは限りません。

本稿の比較判断と設計案は、確認できた機能からの評価です。特定企業の導入済み実績や、導入後の効果を示すものではありません。sukuna本体をそのまま導入できる公式公開リポジトリは、今回の検索では確認できませんでした。

入力画面をそろえるより、
同じ出来事を、同じ根拠で使い回す。

この分解なら、元データがExcelでも、既製品でも、自作アプリでも構いません。「正しい値をどこで直すか」を一つに定め、他の画面はそれを参照する設計にします。全システムを一つのデータベースへ押し込むことと、情報を一貫させることは別です。

sukunaの2023年の構成にはBigQuery・dbt・Power BIなどが含まれますが、製品名をすべて踏襲することを本稿の前提にはしません。[1]

労務・工程・受注を、
別々の管理表で終わらせない。

労務管理：勤怠と「何に時間を使ったか」を分けて、照合する

勤怠は始業・終業・休憩・休暇など、働いた時間の記録。工事別の作業実績は、その時間をどの工事・作業へ使ったかの記録です。同じ一日でも、午前と午後で現場が変わったり、業務上の積込みや移動などが入ったりします。

Frappe HRにはチェックイン・チェックアウト記録があり、ERPNextには工事やタスクへ時間を割り当てるTimesheetがあります。既存実装でも両者は分かれています。厚生労働省の説明でも、労働時間は始業・終業の確認と記録が基本です。[4][5][18]

工程管理：ガントチャートと、班・人・車両の割当は別の問題

「基礎が終われば建柱できる」という作業順序に加えて、「その日に必要な技能を持つ人がいるか」「車両が空いているか」「材料や着工条件がそろうか」を扱う設計にします。信号・照明工事を想定するなら、停電調整、道路使用等の手続き、交通規制、他工種の完了も、該当する作業の開始条件として持たせる案が考えられます。

このときの価値は、工程表を自動で美しく描くことより、明日の施工を止める不足を、今日のうちに担当者へ戻せることです。工事全体の期間と、実際に自社の班を入れる日を分ければ、工期の長い案件が毎日同じ人数を拘束しているように見える誤りも防げます。

受注管理：「売上になるか」に「施工できるか」を加える

引合い・見積提出・内示・契約済みを別の状態で管理し、案件ごとに予定時期と必要な工種・人工を付ける設計です。確定受注の負荷と、未確定案件が入った場合の負荷を切り替えて見ます。

見込案件を一律に「確率50％だから人数も半分」と扱うと、実際に受注した日の配員を説明できません。営業見通しの期待値とは別に、確定分だけ／有力案件も入った場合などのシナリオで施工余力を確認する方が、この用途には向いています。

工事原価：終わってからの反省だけでなく、途中で手を打つ

実績だけなら「24人工使った」で終わります。残作業も持てば、施工方法の見直し、応援の手配、追加変更の確認へつなげられます。進捗率だけから残人工を機械的に推定するのではなく、残る作業と必要人数・時間を更新する方法です。

材料費なども含める場合は、実績原価・発注済み未計上分・未発注の残作業見込を重複しない区分で集計します。受注額、請求額、入金額も分けます。ここで作るのは管理用の完了見込であり、会計上の売上認識や利益と同一視しません。

使う候補と、設計を学ぶ候補を分ける。

比較軸は、業務の範囲、入力負担、データの取り出しやすさ、追加開発箇所です。GitHubのスター数だけで導入順位は付けていません。

ERPNextは「対応しているらしい」ではなく、データ定義まで確認

公開されたProject定義には、sales_order、estimated_costing、total_costing_amount、total_purchase_cost、total_billed_amountなどが実在します。TimesheetにもProject・Task・時間を持たせる仕組みがあります。[3][4]

つまり、受注・工事・労務費・購買・請求の関連付けを、ゼロから全設計する必要はありません。これが自社の「請負工事」「常用」「複数現場」の扱いに合うかを、同じ具体例で比較する価値があります。

建設業専用の新しい実装にも、学べる部分がある

「公開コードがある」「全機能が公開されている」「自社で運用できる」は別の判定です。ライセンス、対象版、必要モジュール、バックアップと更新方法まで含めて採用単位を決めます。OCAはモジュールごとのライセンス確認も必要です。[6]

軸は「工事番号」だけでは足りない。

工事番号は重要ですが、顧客・契約・工事・現場の場所・日々の作業を同じものとして扱わない設計にします。一つの契約で複数箇所を回る場合や、同じ場所で別契約の工事をする場合にも耐えられるようにするためです。

この表は論理的な区分です。八つの表や八つのアプリを必ず作るという意味ではありません。採用製品の既存データを利用し、足りない関係だけ追加する案です。

先に決めたい、四つの共通ルール

対応表を持つ。既存の社員番号や工事番号を無理に全廃せず、「出所のシステム＋元のID」と共通IDの対応を残します。工事名の似た文字列だけで自動的に合体させません。

予定・実績・見込を別にする。雨で予定が動いても、実績は動きません。工程の当初計画と変更履歴を残せば、後から予定を書き換えて遅れを消してしまうことも防げます。

根拠と訂正履歴を残す。受注の根拠、日報、打刻、請求書へ戻れるようにします。訂正は誰がいつ何を直したかが分かる形にし、集計側でこっそり数字を直しません。

計算の単位を固定する。一人工の換算、時間の丸め、材料の単位、税込／税抜、労務費の単価と適用期間を明示します。単価変更で過去の管理原価まで意図せず書き換わらないようにします。

最初から「自作」「ERP」「クラウド」を
答えにしない。

一度の入力を、勤怠・日報・原価へ。
ただし、記録の意味は混ぜない。

次は実装時の画面案です。現場の人が毎日同じ工事名や班員を入力するのではなく、事務側が決めた予定を候補として出し、実際との差だけ確認できるようにします。

NFC社員証を使う入口とスマホを使う入口は、同じ本人IDへ結べる設計にできます。Frappe HRにも外部打刻の取り込みを想定した仕組みがありますが、実際のカードリーダーとの接続は別途アダプターの実装・検証範囲です。[5]

常用・協力会社の作業記録は、自社社員の給与対象時間と区別します。また、労務単価を全員の現場画面に表示する必要はありません。作業員・班長・事務・経営で、見せる情報を分けます。

AIと自動配員は、役割を分ける

AIを使う候補：文章・音声の日報から入力候補を作る、変更理由をまとめる、必要な元資料を探す。確定前に根拠と候補を人が確認できる形にします。

確定計算の担当：労働時間、工数、費用、残額はルールを定めた処理で再計算する。配員の重複や技能条件も、明示した条件で確認します。

配員案を自動で作る段階では、GoogleのOR-Toolsに勤務割当の公式実装例があります。これを参考に、人の重複・休暇・必要技能・車両などを条件としてモデル化する案が考えられます。完成済みの建設業向け配員アプリではなく、最適化に使う部品です。[16]

最初の価値は、全自動の最適配員よりも、手配した予定の「二重割当」「条件不足」を見つけることにもあります。無理な条件では、もっともらしい配員を返さず、どの条件が両立しないかを確認できるようにします。

機能一覧ではなく、
工事を一件通した結果で判断する。

次のケースを、既存活用型と業務統合型に同じ条件で当てます。すべてのケースを最初から作り込むのではなく、自社で実際に頻度や手間の大きいものを選んで比較する方法です。

比較で測るもの

入力が減ったか。作業員・班長・事務それぞれの手間と、同じ情報を入力する回数を見る。数字が合うか。元の日報・勤怠・台帳の合計と照合する。判断が変わるか。不足や未請求が、対応できる時点で見つかるかを見る。保守できるか。更新・権限変更・復元を、担当者が再現できるかを見る。

現行の受注・日報・勤怠・会計から取り出せる項目は、この調査では確認していません。したがって、いま採用製品を一つへ決めるのではなく、同じ数件の工事と一期間の明細を使って、連携で足りるのか、記録側の変更が必要なのかを判定するのが次の具体的な選定作業です。