リフォーム見積システムを案件管理と一体で作る設計｜台帳を2層に分けノーコードで実現

リフォーム見積システムの検討でつまずく原因の多くは、ソフトの機能不足ではなく、データの持ち方にあります。結論は次の3点です。

 

1. 本質を知る：「1対多」の業務を1枚の表で管理しない
2. 実現方法を考える：案件（親）と見積（子）の2層構造にする
3. 着手順序を考慮する：画面づくりの前に「元請けごとの違い」を洗い出す

 

1点目は、「1対多」の業務を1枚の表で管理しないこと。転記ミスや取り違えが起きる根本原因は、「1つの案件に対して複数パターンの見積が発生する」という業務構造を、1枚の表（フラットなデータ）で管理しようとする点にあります。案件と見積は、発生回数も更新タイミングもまったく異なる別物です。

 

2点目は、案件（親）と見積（子）の2層構造にすること。本記事ではノーコード・クラウドデータベース「Slopebase」を使い、親となる「案件管理トラン（18項目）」に、子となる「見積管理トラン（27項目）」がぶら下がる構造を設計しました。見積データが親の案件番号を参照するため、顧客名や工事場所を毎回入力し直す手間がゼロになります。

 

3点目は、画面づくりの前に「元請けごとの違い」を洗い出すこと。いきなりシステム画面を作り始めてはいけません。最初にすべきは、元請けごとに異なる「見積書の様式」や「指定条件」をすべて書き出すことです。ここを飛ばすと、導入後に「あの元請けの見積書だけシステムから出せない」という致命的な事態に陥ります。

 

この形が向いている業務と、向いていない業務は次のとおりです。

 

向いている業務

1. 1件の案件に対して、契約が決まるまで複数の見積プランを並行して扱う
2. 元請や窓口ごとに見積の条件が異なり、案件の情報を軸にまとめて管理したい
3. 案件の進捗を、受付から完工まで同じ画面で追いたい

 

向いていない業務

1. 見積の内訳が毎回まったく異なり、項目の型そのものを決められない
2. 元請が見積書の様式を細かく指定しており、ページ構成まで一切変えられない（この場合は帳票の出し方を別途検討する必要があります）
3. 見積の件数が少なく、1人がExcelで管理しても転記ミスが全く起きていない

 

この記事で扱う範囲と、扱わない範囲

扱う範囲
外装リフォームの見積業務という1つの業務を対象に、元請ごとの条件差の分解から、案件と見積の2層構造の設計、項目の型と粒度、自動化を見送った設計判断までを、外装リフォームの業務を想定した設計検討の内容から整理します。

 

扱わない範囲
次のテーマはそれぞれ独立した記事にまとめているため、本記事では深追いせず該当記事へご案内します。

案件管理の定義とツールの種類
→案件管理とは？ツールの選び方と「案件情報を1か所に持つ」設計例
案件管理表をExcelで作る方法
→案件管理をExcelで行う方法（テンプレート付）
見積管理システムの一般的な選び方と承認フロー
→見積管理システムの導入で承認フロー高速化と利益率向上へ
工事台帳の記載項目と原価管理
→工事台帳とは？記載項目と作り方
顧客管理をExcelからデータベースへ移す一般論
→Excel顧客管理の限界とデータベース化
Excelマクロの属人化とブラックボックス化
→エクセルマクロはもう限界？
導入前の検証の進め方
→PoC設計の進め方

Excelが重い、ファイルが壊れるといった一般的な限界は、ほかの記事に記載しているのでここでは言及しません。ここで取り上げるのは、提携先（元請）から紹介される外装リフォーム案件を扱う現場に特有の兆候です。3つとも、ツールの性能ではなく、日々の業務の進め方に原因があります。

案件と見積が1枚の台帳に同居する、リフォームの顧客管理の構造

案件を受け付けると、案件番号を振って台帳に登録します。台帳には顧客情報、施工先の住所、元請と窓口、現地調査の担当、進捗、契約金額、発注金額、着工日、完工日、保証書の送付状況まで、案件のライフサイクルに関わる情報が横に並んでいきます。

 

便利だからと列を足していくうちに、台帳は「リフォームの顧客管理」と「見積の結果」と「工事の進捗」を1行で背負うようになります。その結果、見積を作るときは台帳から必要な列だけを別のファイルへ写し、契約が決まると見積の金額を台帳へ書き戻す、という往復が生まれます。転記の回数が多いほど、取り違えの機会も増えます。

1案件に複数の見積プランが並び、どれを提示したか分からなくなる

外装リフォームでは、外壁と屋根の仕様や塗料を変えた複数のプランを並べて提案することが珍しくありません。契約が決まるまでの間に、提示した条件を少しずつ調整することもあります。

 

1行に1案件という台帳では、この「複数の見積」をまとめて管理することが困難です。見積用のファイルを複製して管理すると、どのファイルが最新で、どのプランを施主に提示し、どれで契約したのかを、担当者の記憶に頼ることになります。見積用のExcelを関数やマクロで作り込んでいる場合、その仕組みを直せる人が1人しかいない、という状態にもなりがちです。

受付経路と進捗が紙と担当者の判断に散らばる

元請から届く案件情報は、案件共有のクラウドツール、メール、FAX、電話など経路がそろっていないことがあります。事務担当者が内容を整理して台帳に入力しますが、「現地調査を依頼したが日程が未確定」といった途中の状態は、紙の進捗表や担当者の判断で管理されやすくなります。
途中の状態が台帳に記載されていないと、催促されて初めて止まっている案件に気づく、ということが起きます。必要なのは入力を頑張ることではなく、案件の状態を決まった選択肢で持つことです。

 

製品を比べる前に、自社の見積業務がどの軸で分かれているのかを洗い出します。この棚卸しが、リフォーム見積システムを載せられるかどうかを決めます。方法論の一般的な進め方は既存記事で解説しているため、ここでは外装リフォームの見積に絞って手順を示します。

見積が分かれる軸を4つに分解する

まず、見積書がどこで分かれるのかを軸ごとに書き出します。外装リフォームの見積では、次の4つの軸で整理すると全体が見えやすくなります。

 

元請の軸
元請によって、見積書の様式、利益の考え方、提出の流れが違うか

 

工事部位の軸
外壁、屋根、付帯部（破風・軒天・雨樋など）、外壁と屋根以外の工事で、明細の持ち方が違うか

 

プランの軸
1案件に何通りのプランを並べるか、プランごとに仕様と金額が独立しているか

 

ページの軸
標準の工事で1ページに収まるのか、追加工事やその他の工事でページが増えるのか

 

軸ごとの組み合わせを数えると、「固定の様式で済む部分」と「案件ごとに変わる部分」の境目が見えてきます。後者が多いほど、帳票を作り込むよりも、データを正しく持つことを優先すべきです。

塗装の見積書の作り方を差分表に落とす手順とチェックリスト

次に、手元のExcelと過去の見積書から差分表を作ります。塗装の見積書の作り方そのものではなく、「どこが案件によって変わるか」を書き出すのが目的です。

 

1. 元請ごとに、実際に提出した見積書を1枚ずつ用意する
2. 見積書の項目を上から順に書き出し、表の行にする
3. 列に元請（または様式）を並べ、項目ごとに「あり／なし／書き方が違う」を記入する
4. 金額の項目は「手入力か、数量×単価の自動計算か、パックの一式か」を記入する
5. ページが増える条件（追加工事、その他工事など）を書き出す
6. 案件の台帳から写している項目に印を付ける

 

差分表のチェックリスト
□すべての元請の見積書を、少なくとも1枚ずつ確認したか
□案件の台帳から写している項目（顧客名、工事場所、元請、窓口など）を特定したか
□見積の金額のうち、自動計算の項目と手入力の項目を区別したか
□案件で複数のプランを出したときに、プランごとに変わる項目を特定したか
□ページ数が変わる条件と、その上限を確認したか
□元請が様式を指定している箇所と、自社で変えてよい箇所を区別したか

項目の型と桁を先に決めておく

差分表ができたら、項目ごとに型を決めます。金額は整数で持ち、3桁区切りで表示する、保証年数は部位ごとに整数で持つ、といった決め方です。過去の見積書から最大の値を確認しておくと、入力の制約を後から変える手戻りを防げます。リフォームの見積書作成で数値を扱う項目は思った以上に多いため、ここで決めた型がそのまま設計の章の土台になります。

 

◆検討チェックリスト
□元請との間で、案件情報や見積書をデータでやり取りする必要があるか
□見積を作る人、確認する人、施主に提示する人の役割分担が決まっているか
□複雑な案件だけ、営業担当が見積を確認する承認の流れがあるか
□元請、窓口、施工店などを、自社独自の一覧として管理する必要があるか
□契約後に金額を変えてはいけない情報と、変えてよい情報を区別しているか

 

◆システム選定のポイント
□案件管理と見積管理のように、親子の関係を持つデータを扱えるか
□1つの業務からスモールスタートし、あとから工程を追加できるか
□利用人数や機能に対する課金体系が、自社の規模に合っているか
□項目や選択肢を、自社の担当者が画面上で追加・変更できるか
□見積書などの帳票を、登録したデータから出力できるか。元請指定の様式にどこまで合わせられるか
□既存の案件共有ツールや会計ソフトとのデータ連携の方式（CSV、API）が用意されているか

 

---

見積業務の棚卸しから始めたい方へ

 

対象業務の選び方、確かめること・やめる線の決め方、効果指標の設計、要件定義、稟議書までを4つの書式にまとめた資料は、こちらからお受け取りください。

 

---

 

ここからは、外装リフォームの見積業務を想定して設計した、データ構造の中身を見ていきます。最初の段階で対象にしたのは、案件管理、複数の見積の作成、見積書のPDF出力という基本の流れです。

 

 

案件管理トランと見積管理トランの2層構成

設計の中心は、2本のトランです。トランとは、日々の業務で発生するデータを登録する表のことです。

 

親データ：「案件管理トラン」（全18項目）

1件の案件につき、1つのデータ（レコード）を作成します。案件番号はシステムが自動で割り振るため、重複することのない固有の番号（ユニークキー）となります。

そのほか、受付日、お客様のお名前、ご住所、ご連絡先、施工先住所、元請、窓口、現地調査の担当者と日付、工事担当者、成否、着工日、完工予定日、完工日、備考といった情報を管理します。

 

案件の進捗状況は、「ステータス」という項目で管理します。「受付・現調中・見積中・商談中・成約・施工中・完工・失注」という8段階から選択する仕組みです。『課題の整理』の章で課題として挙げた「案件の途中の状態が把握できない」という問題は、スタッフ全員がこの8段階を共通の認識で運用することによって解決に導きます。

 

子データ：「見積管理トラン」（全27項目）

 

1件の案件に対して、必要な数だけいくつでも見積もりデータを作成することができます。

親である案件管理の画面には「見積管理」という関連データ（サブレコード）の項目があり、そこからその案件に紐づく見積もりを一覧でスムーズに確認できるようになっています。
これは、お客様に複数のプランを並べて提案するという「外装リフォーム」ならではの業務の流れを、そのまま直感的なデータの形に反映させた構造です。

 

案件管理トランの入力画面（ステータス8段階と、紐づく見積の一覧）

 

 

入力を減らす参照方式の使い分け

見積管理トランでは、案件番号を「トラン参照」で親とつなぎます。案件番号を選ぶと、顧客名、顧客住所、顧客連絡先、元請、窓口が、オートコンプリートで親のレコードから入ります。台帳から見積用のファイルへ写す作業は、ここでなくなります。

 

一方、見積名、工事名、工事場所、見積日、提案日、外壁と屋根の仕様は、見積ごとに変わりうるため、文字列や日付として見積側で持ちます。たとえば工事場所は、施工先住所と同じであることが多いものの、見積書に書く表記を調整したい場合があるため、あえて参照にしていません。「親から引けるものは引き、見積ごとに変わるものは子で持つ」という線引きが、この設計の要です。

 

見積管理トランの入力画面（案件番号を選ぶと顧客情報が自動で入る）

項目の型と桁数の決め方

見積管理トランの金額の項目は、原価、売価、見積合計金額、消費税額の4つです。いずれも整数で持ち、3桁区切りと円マークを付けて表示します。保証年数は外壁、屋根、付帯部の3つを整数で持ち、次回の塗り替えの目安も整数で持ちます。部位ごとに保証年数が異なる外装リフォームの見積書を、そのまま表現するための分け方です。

 

トラン項目例（設計判断が読み取れる項目に絞って掲載）

 

分類	名称	代表項目	項目タイプ	桁数／値域
親トラン	案件管理トラン	案件番号	自動採番	ユニークキー（重複不可）
親トラン	案件管理トラン	ステータス	選択文字参照	受付／現調中／見積中／商談中／成約／施工中／完工／失注の8値
親トラン	案件管理トラン	成否	選択文字参照	-／×／〇の3値
親トラン	案件管理トラン	見積管理	サブレコード	紐づく見積を一覧表示
親トラン	案件管理トラン	元請・窓口・施工担当	文字列	マスタ化を検討中
子トラン	見積管理トラン	見積番号	自動採番	6桁・ユニークキー
子トラン	見積管理トラン	案件番号	トラン参照	案件管理トランと紐づけ
子トラン	見積管理トラン	顧客名・顧客住所・顧客連絡先	トラン参照	オートコンプリートで親から取得
子トラン	見積管理トラン	原価・売価・見積合計金額・消費税額	整数	3桁区切り、円マーク表示
子トラン	見積管理トラン	外壁・屋根・付帯部の保証年数	整数	年数（部位ごとに保持）
子トラン	見積管理トラン	採用フラグ／PDF作成フラグ	選択文字参照	-／×／〇の3値（PDF作成フラグは帳票作成のトリガー）

出典：外装リフォームの見積業務を想定した設計検討をもとにSlopebase編集部が作成

採用フラグとPDF作成フラグで帳票出力につなぐ

見積管理トランには、2つのフラグを置いています。「採用フラグ」は、複数のプランのうち、どれで契約したかを示す項目です。値は「-」「×」「〇」の3つから選びます。どのプランを提示し、どれが採用されたのかを、ファイル名ではなくデータで残せます。

 

「PDF作成フラグ」は、見積書を作るきっかけになる項目です。値を「〇」にすると、そのレコードの登録内容が帳票のテンプレートに差し込まれ、見積書と工事費の内訳書がPDFとして出力される構成です。帳票の出力には、Slopebaseと外部の帳票ツールとの連携を使います。

 

1件の案件に紐づく見積プランの一覧と採用フラグ

 

 
PDF作成フラグをきっかけに出力した見積書のプレビュー（検証段階の構成）

スコープ外とした範囲

最初の段階では、発注、リフォームの工事管理、完工後の保証書、計上と請求の確認をスコープ外にしました。案件管理トランには着工日や完工日の項目を置いていますが、施工店への発注書、保証書、仕入伝票といった帳票の管理は、次の段階で項目とステータスを追加する前提です。元請側の案件共有ツールとの連携、承認フロー、マスタの運用も同じ扱いです。

 

線を引いた基準は、「いまのExcelで最も負荷が高く、毎回の転記が発生している部分から確かめる」ことでした。案件管理と見積管理がつながらなければ、後ろの工程を載せても転記は残るからです。

自動化を見送った箇所とその判断理由

システムの設計過程において、あえて自動化を見送った箇所が3つあります。

 

1. 見積書のフォーマットを固定様式にすること
2. 取引先（元請け・窓口・施工店）のマスタ化
3. 重複依頼（同一施主・同一工事内容）の自動検知

 

それぞれの判断理由は以下の通りです。

 

1つ目は、「見積書のフォーマットをパックごとの固定様式にすること」です。
外装リフォームの見積もりは、あらかじめ決まったパック内容で案内することが多いものの、実際にはお客様に合わせて中身を細かく調整するケースも少なくありません。また、案件によってページ数が変動することや、そもそも元請け企業から指定された見積書の様式がある場合は、自社の判断でフォーマットを変更することができません。

 

そのため、システム上にパック数分の帳票をあらかじめ用意する形はとりませんでした。まずは実際の帳票パターンを収集し、その上で最適な出力方法を検討する方針としています。様式によっては、見積書の出力機能のみをあえてシステム化せず、手作業（システム外）に残すという選択肢も視野に入れています。

 

2つ目は、「元請け・窓口・施工店のマスタ（一覧）化」です。
設計書の備考欄には「マスタ化を検討」と記載しつつも、初期段階ではあえてマスタを作らず、名称を直接テキストで入力して保持する形をとりました。

 

もちろん、あらかじめ登録した一覧から選択する仕組みにしたほうがデータの表記揺れは防げます。しかし、開発の初期段階では「まずはシステムを通じた業務の全体フローがスムーズに回るかどうか」を検証することを最優先としたため、今回は見送る判断をしました。

 

3つ目は、「同じ施主様から同じ工事内容で、別々の施工店を経由して見積もり依頼が届いた際の自動検知」です。
システム上で案件番号のような固有のキー（ユニークキー）を設け、重複登録をシステム的に禁止する方法もありますが、これは実際の業務運用にはそぐわないと判断しました。また、依頼が届くたびに過去のデータを検索して手動でチェックする運用も検討しましたが、業務上の負担が大きく長続きしないと考えました。

 

現段階では自動化を見送ったものの、この「重複依頼の検知」については、今後の解決すべき課題として認識しています。

新しいシステムを社内へ導入・提案する際、決裁者からは「いまのやり方（Excel）ではダメなのか？」「他のツールではいけないのか？」といった明確な理由が求められます。

ここでは、自社に最適な手段を選ぶための判断軸として、検討過程で比較に挙がりやすい「2つの選択肢」と、それらを見送るに至った理由について整理します。

検討して外した選択肢と却下理由

選択肢1：いまの「Excelとマクロ」を使い続ける
追加の費用がかからない点は大きなメリットですが、以下の理由から見送りました。

 

機能面の限界
1行1案件で管理する現在の台帳形式では、1つの案件に対して複数の見積もりパターンを柔軟に持たせることができません。結局、案件管理表と見積書のあいだで、手作業による転記作業が残ってしまいます。

 

保守の属人化
Excelのマクロや複雑な関数を修正できる担当者が限られているため、業務の変化に合わせて仕組みを改修したくても、特定の担当者の手が空くのを待たなければなりません。

 

選択肢2：他の「ノーコードツール」を利用する
自社の業務に合わせて画面を自由に構築できる点は同じ方向性ですが、複数のノーコードツールを比較する際は、以下の3点が重要な分かれ目となります。

 

データ構造（機能面）
「顧客・案件（親）」に対して「複数の見積もり（子）」が紐づくような、親子関係のデータ管理ができるか。

 

帳票出力（機能面）
登録したデータから、希望するレイアウトで見積書などの帳票を出力できるか。

 

費用対効果（費用面）
利用人数や利用したい機能に応じた課金体系が、自社の規模に見合っているか。

 

特に「外装リフォーム」の見積もりは、考慮すべき項目や条件が非常に多岐にわたります。そのため、単に機能一覧を見るだけでなく、「実際の項目数や帳票パターンをツール上で表現しきれるか」を、実データを用いて検証してから判断することを強くおすすめします。

既製のリフォーム見積ソフトで足りるケース

既製製品で足りるケースも挙げておきます。自社で見積書の様式を決められ、プランの数も少なく、見積の作成だけを効率化できればよい場合は、既製のリフォーム見積ソフトや塗装の見積ソフト、見積書アプリのほうが早く使い始められます。単価の一覧や部材の選択肢があらかじめ用意されている製品も多くあります。

 

反対に、元請ごとに条件が違い、案件の進捗から見積、その後の工事管理までを1つのデータでつなぎたい場合は、業務に合わせて作る方式が向いています。製品ごとの機能の比較は、見積管理システムの選び方の記事で扱っています。

社内で挙がりやすい懸念への答え方

検討の場では、「Excelに代わるノーコードを導入して、運用していけるのか」という懸念がよく挙がります。答え方のポイントは、一度にすべてを置き換えないことです。最初は案件管理と見積管理に範囲を絞り、項目や選択肢を担当者が画面上で調整できることを確かめてから、発注や工事管理に広げます。

 

ほかにも、「見積の考慮要素が可変で、どこまでマスタ化できるか分からない」「それに伴ってトランの項目数が限界に達するのではないか」「用意すべき帳票のパターンが分からない」という懸念が出やすくなります。いずれも、手順の章の差分表を作れば、事前に答えの材料をそろえられます。

外装リフォームにおける見積もりや案件管理の業務見直しを検討される際、事務や管理の担当者からよく寄せられる現場のお声をご紹介いたします。リフォーム業に限らず、案件を受注して見積もりを提示し、工事や納品へと進むビジネスモデルであれば、多くの企業様において共通する課題です。

 

見直しを検討されるきっかけとして最も多く挙がるのが、「Excelの限界」という悩みです。案件管理用のExcelファイルに機能を詰め込みすぎた結果、動作が著しく重くなってしまったり、案件管理と見積もり作成で複数のファイルを並行して扱わなければならなかったりと、日々の業務における大きな負担となっています。また、複雑化したExcelの仕組みを特定の担当者1人で保守しているという属人化の状況も頻繁に耳にします。

 

新しいツールの導入を検討する段階での懸念として多く挙がるのは、「自社で構築や運用をしていけるのか」という不安です。専門のシステム担当部門がない企業様にとっては、画面の設計や入力項目の変更を自社で対応できるかどうかが最初のハードルとなります。こうした不安に対しては、まずは影響の少ない小さな範囲からスタートし、担当者自身で項目の追加や削除が問題なく行えるかを実際に確かめながら進めていただくことで解消を図ります。

 

---

自社の見積業務で同じ形が成立するかを確かめる

 

本記事の設計は、製品を選ぶ前に業務を棚卸しするところから始まっています。同じ手順を自社に当てはめ、「載る条件」に収まるかどうかを一緒に確認するところからご相談いただけます。ご用意いただくのは、現在お使いのExcelと見積書のサンプルだけで構いません。

 

---

 

Q1 リフォームの見積もりに時間がかかるのはなぜですか？

A 現地調査の結果をもとに、部位ごとの仕様、数量、単価を積み上げる作業そのものに時間がかかるうえ、案件の情報を見積用のファイルへ写す作業や、プランごとにファイルを複製する作業が重なるためです。積算の時間を減らすには単価や仕様の選択肢を整えることが、転記の時間を減らすには案件と見積を参照でつなぐことが有効です。本記事の設計は、後者を解くためのものです。

Q2 リフォームの見積ソフトは、どのような基準で選べばよいですか？

A まず、見積書の様式を自社で決められるかどうかを確認してください。自社で決められ、見積の作成だけを効率化したい場合は、既製のリフォーム見積ソフトが向いています。元請ごとに様式や条件が違い、案件の進捗や工事管理までつなげたい場合は、親子の関係を持つデータを扱えるか、帳票をデータから出力できるかを優先して比べます。製品の比較は、見積管理システムの選び方の記事で詳しく扱っています。

Q3 リフォームの顧客管理はExcelのままでもよいですか？

A 顧客と案件の数が少なく、1人が管理していて転記ミスも起きていないなら、Excelで十分なこともあります。ただし、1件の顧客や案件に複数の見積が紐づき、複数の担当者が同時に更新するようになると、1行1案件の表では持ちきれなくなります。兆候の章の3つに当てはまるかどうかを、判断の目安にしてください。

Q4 元請が指定する見積書の様式は、システムで再現できますか？

A 様式の固定部分が多ければ、登録したデータを帳票のテンプレートに差し込んで再現できます。一方、ページ数や明細の構成が案件ごとに大きく変わる場合は、すべてを自動で再現できるとは限りません。本記事の設計でも、帳票をパックごとに固定する方式は見送りました。事前に差分表で様式の違いを洗い出し、どこまでを帳票にするかを決めてから検討することをおすすめします。

リフォーム見積システムの検討で起きる転記や取り違えは、担当者の注意力ではなく、1件の案件に複数の見積が生まれる業務を1枚の表で持とうとする構造から生まれます。

 

本記事では、案件管理トランを親、見積管理トランを子とする2層の構造で、この問題を解く設計を整理しました。着手の順序は、元請ごとの様式と条件の差分を書き出すことが先です。帳票の固定化や重複依頼の検知のように、自動化を見送った部分も含めて判断することが、移行を成立させる近道になります。

 

---

見積業務の業務構築について、資料と個別相談をご用意しています

本記事で紹介した業務概要・業務フロー・業務ポイント・トランの設計は、住宅リフォーム（外装工事）の見積業務を想定した設計検討の内容にもとづくものです。同じ形式で自社の業務を設計するとどうなるのか、資料でご確認いただくか、個別にご相談いただけます。

 

 

---