イントロダクション — Darwinの考え方

その工事の見積もり方を、御社はすでに知っています。 どの工事も、次の工事の学びになる。だから Darwin という名前です。

建設工事の見積は、これまで経験と判断、そして互いに連携するように作られていないツールに散らばった情報に頼ってきました。図面はあるシステムから、数量は別のシステムから、単価表はメールの受信箱から届き、最終的な予算はそれらを手作業で突き合わせてまとめる必要があります。

本当の問題は、知識が失われることです。建設会社は同じ仕事を何度も見積もります。同じコンクリート、同じ壁、同じ作業班。それなのに、その知識はコピーされた表計算ファイルと、一部の担当者の頭の中にしかありません。

Darwinは、その知識を社内に残します。原価の考え方を再利用できるモジュールとして記録し、価格は別に管理します。見積をレビューして正式に承認すると、それが実績原価を管理するための実行予算になります。差異が出たときは、チームがその内容を確認し、どの改善をカタログに反映するかを判断します。

Darwinは、見積を単発の作業としてではなく、繰り返し使え、データに基づくワークフローとして扱います。

Darwinは、組織の原価のDNAを残し、整理し、進化させるための原価の知識システムです。見積を中心に作られていますが、その範囲は見積にとどまりません。

Darwinの基本的なワークフローは次のとおりです。

依頼 → 明確化 → 見積 → レビュー → 承認 → 記録 → 学習

作業の依頼は、チームがレビューする見積になります。承認すると、原価管理の実行予算が記録されます。実績原価と差異は、チームが今後の見積を改善するための根拠になります。

マニフェストにあるとおりです。

建設業に足りないのは専門知識ではない。失われない記憶だ。

Darwinの仕組みを理解するには、まずワークフローを知り、そのうえで背景にある基本原則を確認してください。

依頼から実行予算までのワークフロー

Darwinは、建設の仕事が実際にどう始まるかを反映しています。最初から完璧なプロジェクト記録があるわけではありません。始まりは依頼、質問、工事範囲のパッケージ、足りない図面、価格への懸念、確認が必要な変更などです。

ワークフローは、そうした仕事に明確な道筋を与えます。

依頼 — 誰かが、仕事の見積、レビュー、変更、承認を依頼します。
明確化 — チームが図面、ファイル、コメント、数量、前提条件、不足している情報を追加します。
見積 — 積算担当者が依頼を、構造化された原価の考え方に落とし込みます。
レビュー — 価格、数量、前提条件、提案内容を検証します。
承認 — 見積が確定した実行予算になります。
記録 — 承認済みの実行予算に対して、実績原価と請求書を記録します。
学習 — 差異から何が変わったかを読み取り、今後の見積の進め方を改善します。

だからこそ、Darwinはばらばらの機能の集まりとして覚えるべきではありません。その価値は、最初の依頼から施工時のフィードバックまで、ワークフローが背景情報を失わずに保つところにあります。

1. プロジェクトが中心になる

プロジェクトには、見積と原価管理の記録がまとまります。再利用するカタログ、作業依頼、個人の Quantos 下書きは、プロジェクトより前から存在していてもかまいません。

プロジェクトには次のものが含まれます。

作業依頼と、確認のやり取りの履歴
IFCモデルと2D図面
見積とその改訂
モジュールと単価表
ドキュメントと連絡のやり取り
承認、操作履歴、タスク
承認済みの実行予算と原価管理の情報

これらを1つにまとめることで、Darwinはプロジェクトを、見積がどう作られたかを示す生きた記録にします。見積の根拠となるファイルと判断はプロジェクトと一緒に残しておきましょう。そうすれば、後から別の担当者が見つけて確認できます。

プロジェクトは、信頼できる原価インテリジェンスの基盤です。

2. モジュールは施工の知識を一度だけ記録する

Darwinでは、毎回明細を一から書く代わりにモジュールを使います。モジュールは、ある部位をどう施工するかを表す、再利用できる構成要素です。日本でいえば、御社がすでに使っている歩掛にもとづく単価内訳にあたります。

モジュールには次の内容を含められます。

材料とその数量
労務と歩掛
経費と間接費
ドキュメント
分類（UniFormat、MasterFormat、IFCの情報）

レビューを済ませたモジュールは、御社の原価のDNAの一部になります。工事範囲、数量、前提条件を決めるのは、引き続き担当者です。

レビュー済みの組み立て方を再利用すると、次のことができます。

既存の資源リストから始める
共通の前提条件を確認する
別の積算担当者に作業内容を説明する
根拠がそろったときに組み立て方を修正する

モジュールによって、見積は毎回作り直す作業から、知識を当てはめる作業に変わります。

3. 価格は変わる。考え方は変わらない

市場は動きます。材料の価格は変動し、労務単価も変わります。しかし、その下にある施工の考え方は変わりません。

Darwinはこの2つを分けて扱います。

モジュールは施工の考え方を保存します
単価表は経済的な条件を保存します

この分離によって、次のことができます。

編集可能な見積を、レビュー済みの価格で明示的に再計算する
時期や地域の異なる見積を比較する
チーム間で一貫性を保つ

単価表を更新しても、既存の見積が知らないうちに変わることはありません。明示的に再計算すると、レビュー済みの組み立て方の変更も反映されることがあります。差を価格だけによるものと判断する前に、結果を確認してください。

多くの会社が、表計算ファイルですでにこの問題を感じています。考え方と価格が同じセルに入っているため、片方を更新するともう片方を壊してしまうおそれがあるのです。私たちはExcelが好きです。ただ、記憶の役割までExcelに任せるのをやめただけです。

4. 役立つときにBIMと図面を使う

DarwinはIFCモデルと2D図面（PDF、JPG）に対応しており、数量拾いを効率化し、設計と原価をつなぎます。

モデルや図面を取り込むと、次のことができます。

数量を抽出する
要素をグループ化・分類する
オブジェクトをモジュールに対応付ける
要素を3Dで表示する、または2D図面に注記を付ける

ただし、Darwinはこれらの入力を実務的に扱います。

モデルや図面は形状とメタデータを提供します
Darwinは原価の構造と追跡可能性を提供します

中心にあるのは、あくまで積算担当者の判断です。手入力の数量だけで見積を作ることもできます。BIMと図面は任意の入力です。

なぜこれが重要か

依頼、見積の情報、プロジェクト、モジュール、単価表、取り込んだデータ（IFCまたは2D）を整理することで、Darwinは見積が次のようになるワークフローを作ります。

再現できる — 同じ考え方を実行すれば、同じ結果が得られる
追跡できる — すべての判断に背景と履歴がある
共同で進められる — タスク、レビュー、ドキュメントが一か所にある
変化に対応できる — 見積を作り直さずに、価格や設計の入力を更新できる

Darwinは、この考え方を見積の先にも広げます。

同じ構造で、次のことにも対応します。

予算と実績の比較
請求書の差異の確認
分類体系・細目別の原価管理
見積を提出した後の、施工段階の原価インテリジェンス

Darwinは、見積の作成から原価管理まで、建設工事の原価に関する意思決定に構造とインテリジェンスをもたらします。

よく見積もる工事から始める

30年分の表計算ファイルを一度に移す必要はありません。チームがよく見積もる単価内訳を10〜15件選んで始めましょう。最初のモジュールを手で作成するか、利用できる場合は Module Copilot が作成した下書きを確認・修正します。何をカタログに加えるかを決めるのは御社です。

サプライヤーの価格は、すでにお使いのExcelシートから取り込めます。既存の見積の表計算ファイルが自動でモジュールに変換されることはありません。仕事を進めながらレビュー済みの知識を加え、工事からのフィードバックで改善していきます。

どの工事も、次の工事の学びになる。だから Darwin という名前です。