見積もり:Laravel構造化見積もりエンジンの開発と要件

2026年04月05日

Estimates: Laravel Structured Estimating Engine Development and Requirements

見積エンジン「見積OS」:包括的ブリーフィング・ドキュメント

エグゼクティブ・サマリー

本ドキュメントは、構造化された見積データの生成・管理を目的とした共通基盤システム、通称「見積OS」の要件、設計、および現在の開発状況をまとめたものである。

このプロジェクトの核心は、単なる見積作成ツールの提供ではなく、「あらゆる業界の業務構造をそのままデータ化するエンジン」を構築することにある。システムは、共通のデータ構造を保持しつつ、UI(ユーザーインターフェース)と計算ロジック(Calculator)を業界ごとに切り替える「3層構造(共通基盤・業界別機能・企業別設定)」を採用している。

現在、Laravel 12およびPHP 8.3をベースとしたMVP(実用最小限の製品)の開発が完了し、IT受託開発向け(WBS型)およびサービス業向け(カート型)のUIが既に実装・公開されている。建設業向けの積算型UIや製造業向けの原価計算機能の拡充も進行中であり公開は近い。および各業界向けプリセットの整備を優先事項として、プロダクトの完成度を高めている。


--------------------------------------------------------------------------------


1. プロダクト定義と戦略方針

1.1 基本コンセプト

本プロダクトは、業界を問わず利用可能な「構造化見積システム」である。以下の3つの主要価値を提供する。

* 業務構造のデータ化: 複雑な階層構造(ツリー構造)を持つ見積を正確にデータ化する。
* 業界最適化: UIは業界ごとに最適化し、データ構造とAPIは共通化する。
* 拡張性: 将来的に建設積算や製造原価などの高度な計算要件にも対応可能な設計。

1.2 アーキテクチャの3層構造

プロダクトの保守性と拡張性を担保するため、以下の3レイヤーで責務を分離している。

レイヤー 内容 管理主体
共通基盤 データ構造、明細ツリー、共通API、PDF出力基盤、ステータス管理。 システム・コア
業界別機能 UI構造(WBS型/カート型等)、Calculator、業界固有の計算ルール、初期テンプレート。 業界別コード
企業別設定 用語(工程、商品等)、表示ラベル、既定値、テンプレート内容。 管理画面設定

1.3 配備戦略

SaaS型のマルチテナント方式を必須とせず、共通のコードベースを利用しながら「業種別個別サイト(サブドメイン)」として配備する方針を優先している。これにより、各業界に特化した運用と設定の簡素化を実現する。


--------------------------------------------------------------------------------


2. 技術スタックと実装要件

2.1 開発スタック

* Backend: Laravel 12 (PHP 8.3 FPM)
* Database: MySQL 8.4
* Frontend: Blade + JavaScript (Vanilla JS / Alpine.js を想定)
* Environment: Docker Compose (開発), Apache + MySQL (VPS本番)

2.2 実装の絶対ルール

1. APIファースト: Bladeから利用する場合もAPI経由でデータを操作し、将来的なReact/Next.jsへの移行を容易にする。
2. 計算のサーバー主導: 金額の整合性を保つため、すべての計算はサーバー側(Calculator)で行い、フロントエンドの仮計算よりも優先させる。
3. 明細のツリー構造: すべての明細は parent_id による階層構造を保持し、原価情報(cost)を必須とする。


--------------------------------------------------------------------------------


3. 業界別計算ロジック (Calculator)

各業界の特性に合わせ、AbstractEstimateCalculator を継承した専用クラスで計算ロジックを上書きする。

業界 Calculator種別 特筆すべき計算ルール
共通 基本計算 数量 × 単価、親子ロールアップ、税計算、粗利計算。
IT ItEstimateCalculator 任意項目(is_optional=true)を親グループおよび合計から除外する。
サービス ServiceEstimateCalculator 選択されたオプション(selected=true)のみを合計に加算する。
建設 ConstructionEstimateCalculator 小計に対する率計算(percent_of_subtotal)をサポート(例:諸経費10%)。
製造 ManufacturingEstimateCalculator 歩留まり(yield_rate)を考慮した原価計算をサポート。


--------------------------------------------------------------------------------


4. 主要機能の詳細

4.1 明細ツリー編集機能

見積明細は、単純なリストではなく高度なツリー構造として管理される。

* 階層操作: 行の追加、子行の追加、削除、複製。
* 移動・インデント: 上下移動、インデント(子にする)、アウトデント(親に戻す)。
* 範囲操作: 連続選択(Shift+クリック)による一括削除や一括移動。親行を移動・削除すると、その配下の子孫行(subtree)も同様に処理される。

4.2 テンプレート機能

2つの異なるテンプレート概念を持つ。

1. 見積全体テンプレート: 新規見積作成時に、あらかじめ定義された構成を丸ごと生成する。
2. 階層構成テンプレート(コンポーネント): 既存の見積に対し、特定の「工事パック」や「工程セット」を部分的に挿入する。挿入位置は「末尾」「指定行の下」「指定行の子」から選択可能。

4.3 企業別設定 (Organization Settings)

各導入企業は、管理画面から以下の設定をカスタマイズできる。

* 用語の差し替え: 「工程」を「作業区分」に変更、「商品」を「施術メニュー」に変更など。
* 表示制御: PDFでの原価表示の有無、特定のボタン名称の変更。
* 既定値: 標準税率、計算方式(税込/税抜)、初期テンプレートの選定。


--------------------------------------------------------------------------------


5. 業界別UI要件

5.1 IT受託開発向け (WBS型)

工程やタスクを階層的に管理し、工数(人日)と単価から見積を算出する。

* フェーズごとの小計表示。
* 範囲選択による高度な並び替え・移動操作。

5.2 サービス業向け (カート型)

標準プランにオプションを追加していく形式。

* 商品リストからの選択。
* 「標準 / オプション」のステータス表示と選択チェックボックス。

5.3 建設・リフォーム向け (積算型・将来拡張)

「工事項目」を軸に、部材と施工費を積み上げる。

* 諸経費などの率計算の自動適用。
* 工事パック(構成テンプレート)の頻繁な再利用。


--------------------------------------------------------------------------------


6. 進捗状況とロードマップ

6.1 現在のステータス

* 実装済み: 見積・明細のCRUD、ツリー編集(インデント/移動/範囲操作)、IT・サービス用Calculator、PDF出力、構成テンプレートのインポート機能、基本的な組織設定(税・用語)。
* 公開状況: ポータル、ITサイト、サービスサイトがVPS(Apache + MySQL)上でHTTPS公開済み。

6.2 今後のフェーズ

1. フェーズ 1 (現行): ITおよびサービス機能の磨き込み、UXの改善、モバイル対応の確認。
2. フェーズ 2: ポータルサイトの整備、VPS運用手順の安定化。
3. フェーズ 3: 建設業向けUIの実装(積算型UI、諸経費計算導線)。
4. フェーズ 4: 製造業向けUIの実装(原価内訳、歩留まり入力)。

6.3 直近の具体タスク

* IT/サービスUIにおける全画面への用語設定の反映。
* 建設・製造サイトの初期化と公開準備。
* PDF文言設定や見積番号ルールの追加。

見積もりは「OS」だった:あらゆる業界を構造化する、次世代エンジンの設計思想

1. イントロダクション:見積もりの背後にある「構造」の不一致

ビジネスの最前線において、見積もりは単なる「価格の提示」を遥かに超えた存在です。それはプロジェクトの全容、リソースの配分、そして提供価値の境界線を定義する「業務の設計図」そのものです。しかし、我々は長らく、業界ごとに見積もりの形式は根本的に異なり、それぞれに専用のシステムが必要であるという「構造の不一致」を宿命として受け入れてきました。

ITのWBS、建設の積算、サービス業のオプション選択。これらは一見、相容れないロジックに見えます。しかし、我々シニア・アーキテクトの視点に立てば、そこには共通の抽象的なデータ構造が静かに横たわっています。

ここで提唱するのが「見積OS」というパラダイムシフトです。これは単なるツールではなく、複雑極まる業務構造をエレガントな抽象化によってデータ化する「次世代エンジン」です。バラバラに見える商習慣の裏側に潜む「普遍的な文法」を解き明かすことで、ビジネスの構造を再定義します。

2. 衝撃の事実:ITも建設も、実は「同じ木」からできている

異なる業界の見積もりを深く観察し、極限まで抽象化を推し進めると、ある一つの「絶対ルール」に突き当たります。それは、あらゆる商取引は「ツリー構造(階層構造)」に集約されるという事実です。

IT業界の「工程 > タスク > 詳細」という作業分解構造と、建設業界の「工事項目 > 中項目 > 部材・施工費」という積み上げは、データモデルの視点では完全に同一の「木」です。我々はこの構造を、柔軟性と整合性を両立する**Adjacency List(隣接リスト)**形式で実装しました。parent_idsort_orderdepthを基軸としたこのモデルは、いわば「商業の普遍的な文法」です。

最下層の計算結果が親要素へと再帰的に集約される「ロールアップ計算」こそが、全業界を貫く共通基盤となります。

「正体はこれ:『業務構造をそのままデータ化するエンジン』」

このエンジンは、単に数値を合計するだけではありません。業務の階層性そのものを計算可能なデータへと変換する装置なのです。

3. 三層分離の魔法:なぜ一つのシステムで「カート型」と「積算型」が共存できるのか

このエンジンの真価は、「共通基盤」「業界別機能」「企業別設定」という徹底した三層分離の設計思想にあります。これにより、裏側のデータ構造を不変に保ちながら、表層の操作体験を劇的に変化させることが可能となりました。

  • 共通基盤:PHP 8.3とLaravel 12、そしてMySQL 8.4を基盤とし、100〜300行の明細を1秒以内で再計算する高パフォーマンスなコアロジック。
  • 業界別機能industry_typeに応じて「Calculator」を動的に差し替えます。例えば、建設業向け(construction)では、小計に対する諸経費の率計算を行うcalc_mode = percent_of_subtotalを適用し、製造業向けではyield_rate(歩留まり)を考慮した原価計算をオーケストレートします。
  • 企業別設定:管理画面から用語や表示ラベルを調整します。

ここで鍵となるのが、**meta_json**という「アーキテクチャの逃げ道」です。製造業の歩留まり率や建設業の管理費率など、業界固有の属性を硬直的なカラムとして定義せず、このJSONフィールドに閉じ込めることで、スキーマを変更することなく無限の拡張性を確保しました。

4. 「あえてSPAを選ばない」という、実利主義的な技術選定

モダンな技術に飛びつくのは容易ですが、優れたアーキテクトは「決定を遅らせる技術」を心得ています。我々はMVP(実用最小限の製品)を最速で届けるため、あえてフロントエンドを完全に分離したSPAではなく、「Laravel 12 + Blade + JavaScript」というハイブリッド構成を選択しました。

これは決して妥協ではありません。戦略的なデカップリングです。 「APIファースト」の原則を徹底し、Bladeは初期レンダリングに徹しながら、画面内の複雑な階層操作はJavaScriptでAPIを叩く構造にしています。これにより、MVPとしてのスピードを最大化しつつ、将来的にツリー編集UIなどのリッチな操作が求められる部分だけをReactやNext.jsへ差し替える「進化の余地」を残しています。

アーキテクチャとは、未来の選択肢を奪わないための設計です。この実利主義的な選定こそが、プロジェクトを成功へと導くのです。

5. 業界の境界線を消す「構成テンプレート」の再利用性

見積作業の真のボトルネックは、ゼロからのデータ入力にあります。「見積OS」はこれを解決するため、単なるコピーではない「階層構成テンプレート」という強力な武器を備えています。

これは、特定の工程や工事パックを「Recursive Sub-trees(再帰的な部分木)」、あるいは「Atomic Business Units」として既存の見積に注入する仕組みです。

  • IT業:「要件定義セット(ヒアリング、業務整理、要件定義)」を、既存の見積の任意の位置へ階層ごと一括挿入。
  • 建設業:「風呂工事一式(浴槽、給排水、解体撤去、設置施工)」という「工事パック」を、親子構造と計算属性を保持したまま一瞬で展開。

meta_jsonに保持された業界固有のロジックごと「部品」として再利用できるため、実務のスピードは次元の違うレベルへと引き上げられます。

6. 結論:見積もりを再定義した先に広がる世界

現在、このエンジンの共通基盤はすでに完成し、Portal、IT、Serviceの3サイトはすでに実戦配備されています。我々の次なるフロンティアは、建設積算と製造業のBOM(部品表)展開です。

ビジネスの本質が「価値の構造化」であるならば、見積もりはその構造が最も純粋に現れる場所です。業界という既存の境界線をデータ構造によって消し去り、あらゆる業務を「見積OS」という一つの言語で記述する。これが我々の目指すビジョンです。

最後に、あなたに問いかけます。 「あなたのビジネスの構造を、もしOSとして定義するとしたら、どんなツリーが描けるだろうか?」

IT業界向け、サービス業向け、建設業向けが完成している。

https://estimates.iplusone.co.jp

最新のお知らせ

thumb
2026年4月5日
見積もり:Laravel構造化見積もりエンジンの開発と要件

Estimates: Laravel Structured Estimating Engine Development...

thumb
2026年4月2日
MDXレンダリング最適化および高機能コンポーネント実装要件定義書

1. プロジェクトの背景と戦略的意義 モダンなWebフロントエ...

No Image
2026年4月2日
Next.js App Router × MDX 導入・完全ワークフロー

Next.js エバンジェリストの視点から、MDXをプロジェクトに...

thumb
2026年4月2日
【新常識】MarkdownとReactが融合する「MDX」の世界:記事の中でアプリが動く魔法

1. はじめに:なぜ今、MDXが必要なのか? プログラミン...

thumb
2026年4月1日
多拠点展開の「正解」がここにある。次世代ポータル基盤『Plus1 Community』から学ぶ5つの設計思想

1. イントロダクション:多拠点管理の「カオス」を解き明か...

thumb
2026年3月31日
アイプラスワンのホームページトップに、ECサイト基盤とコミュニケーションサイト基盤をのせたい

いいですね、その方向はかなり“刺さる”構成になります。今やる...

thumb
2026年3月30日
WindowsでのDocker開発を劇的に変える、5つの「戦略的」最適化術と真実

WindowsプラットフォームにおけるDocker開発の歴史は、仮想化技...

thumb
2026年3月29日
1つの方程式で、あらゆる「つながり」を。マッチング基盤設計に学ぶ、究極の再利用戦略

1. イントロダクション:マッチングサイト乱立時代の「車輪...

thumb
2026年3月26日
Beyond the Hammer: Rediscovering the Joy of Building

このブログ記事は、開発者のコミュニティや職場において人工知...

thumb
2026年3月26日
モダンECプラットフォーム「ec-plus1」構造完全ガイド

このドキュメントでは、最新のECプラットフォーム「ec-plus...