積算システムの要件定義は、現状業務の可視化、目的に沿ったRFPの作成、要件の凍結、データ整備の順に進めると、投資を無駄にしない導入につながります。
RFP・要件定義書・提案依頼書の作り方を、発注企業の視点で順に見ていきます。全体像は積算システムの完全ガイドもご覧ください。
▼全体ガイドの記事
・積算システムの完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
現状業務の可視化とAX前提の要件整理
要件定義は、現在の積算業務を把握するところから始めます。機能の希望リストは、その後に作ります。現場の実態を見ずに理想像を描くと、業務とかけ離れて定着しません。
「DXが流行りだから」と高機能なシステムを入れ、現場の反発を招く失敗は、業界を問わず起きています。そこで、現場業務を起点にあるべき姿（ToBe）を描く順序が大切です。
積算担当へのヒアリングと現状フローの可視化
まず、積算担当・営業・現場・経理に、現在の業務を聞き取ります。数量の拾い方や使っている単価表、見積書の順序を確かめ、無駄や手戻りも洗い出します。
- 作業の流れ：現状の業務フローを図に描き、工程の前後関係を見える形にする
- 暗黙知：ベテランの単価感覚や歩掛など、文書に残りにくい判断を書き出す
- 例外処理：通常の流れから外れる処理も、拾い漏らさないよう確かめる
この段階で書き出しておくことが、特定の人に頼らない設計の前提になります。担当者によって見積の作り方が違う場合は、システム化を機に、標準の手順へ揃えておく必要があります。現状をそのまま写すと無駄な工程まで残るため、それを除いてから仕組みを組み立てます。
可視化と標準化を飛ばすと、非効率な業務をそのまま電子化するだけになり、効果は出にくくなります。業務改革を伴うデジタル化が、AXの考え方です。
導入目的の明確化と要件の優先順位付け
要件定義書では、機能を並べる前に導入目的を明記します。目的を起点に要件を仕分けると、予算内で価値のあるシステムに絞れます。
- 必須（Must）：目的の達成に欠かせない要件として扱う
- あると良い（Want）：必須ではないが、余裕があれば追加したい要件
目的の例には、見積作成時間の短縮、属人化の解消、見積精度の向上による利益率の安定などがあります。要望を曖昧なまま集めると、範囲が膨らみ、費用も高止まりします。
たとえば、「見積作成時間50%削減で年間人件費を圧縮」のように、効果を必須要件に結び付けておくと、ROIを説明しやすくなります。また、製造業の集計自動化では、月100時間以上、年60〜100万円以上の削減という相場感も示されています。
便利さだけで必須要件を増やすと、見積が膨らみ、稟議も通りにくくなります。優先順位は、技術都合ではなく、経営の目的を起点に決めます。
現場・経理・経営では、重視する要件がそれぞれ異なります。そのため、優先順位を話し合い、各部門の期待をすり合わせておく必要があります。合意しないまま開発へ進むと、要望が反映されていないという不満が出て、定着の妨げになります。
要件の優先順位付けは、技術的な整理にとどまらず、プロジェクトを支える社内の納得感を作る工程でもあります。
RFP（提案依頼書）に盛り込むべき項目
RFP（提案依頼書）は、複数のベンダーから提案と見積を得るための文書です。内容が曖昧だと各社の前提が食い違い、比較できないうえに追加費用も発生しやすくなります。
積算システムのRFPに必要な記載を揃えておけば、発注側は提案の条件を合わせてベンダーを選べます。
背景・目的・業務範囲・機能要件の記載項目
提案と見積の前提を揃えるため、RFPの基本構成は次の5項目で整理します。
- 背景と目的：なぜ導入するのか、その経緯と目的
- 対象業務：システム化する業務の範囲を示す
- 機能・非機能：必要な機能と、性能などの条件
- 予算・日程：使える予算と、導入までの日程
- 提案・選定：提案してほしい内容と、選ぶときの基準
上の5項目のうち、機能と非機能は次の段落から別々に説明します。
機能要件には、拾い出しや単価マスタ、見積書作成といった機能を記します。実行予算などの機能も、自社の工種や様式を例に挙げ、業務に沿って具体化します。
「見積書を作れること」の一言では、ベンダーごとに解釈が分かれてしまいます。自社の表紙・内訳・明細に対応すること、過去見積を複製して再利用できることまで書きます。
非機能要件には、利用人数や求めるレスポンス、クラウドかオンプレかといった条件を含めます。セキュリティやバックアップの条件も、書き添えます。
重い図面データを扱う製造業では、データ量によってオンプレが有利になる場合もあります。そのため、自社のデータ特性を踏まえて方式を指定します。
条件をRFPに記載すれば、ベンダーは同じ前提で提案できます。逆に曖昧なままだと、追加費用や「言った言わない」の原因になります。
SLA・保守・サポート体制の要件明記
保守・サポートとSLA（サービス品質保証）は、導入後の運用を左右します。必要な対応は、RFPで具体的に示しておきます。
- 障害対応：障害が起きたときに、どれくらいの時間で対応するか
- 問い合わせ：返答までの目安をどれくらいにするか
- 定着支援：稼働までの伴走支援を、どこまで受けられるか
導入後も単価マスタの更新や運用支援が必要で、サポートの質が定着を左右します。たとえば、格安アプリの支援が遅れ、1年未満で乗り換えた工務店の例もあります。
保守費は一般に開発費の15〜20%が相場で、開発費3,000万円なら年450〜600万円が継続してかかります。初期費用だけで選ぶと、運用時に予算が破綻しかねません。
RFPの回答に保守範囲と年間保守費を書いてもらい、初期費用と運用費を合わせた総額（TCO）で比べます。
安いライセンスでも、サポートが薄いと乗り換え費用がかさむ場合があります。そこで、RFPの段階で保守条件を確かめておきます。
RFPで示す選定基準と評価方法
評価軸と重みをRFPに示しておけば、各社の提案を同じ物差しで並べて比べられます。
- 価格：提示された費用を評価する
- 機能：要件をどこまで満たしているか
- 業界理解：自社の業界をどこまで理解しているか
- 支援と実績：サポート体制と導入実績を見る
基準が曖昧だと、各社は自社の強みを中心に提案するため、横並びの比較が難しくなります。評価軸を決めておけば、選定の客観性も高まります。
価格だけで選ぶと、格安アプリの例のように定着に失敗することもあります。
建設・リフォームの現場や自社の工種・単価体系を理解しているベンダーかどうかは、提案やデモで見極めます。自社の積算をどう効率化するか具体策を求めると、各社の理解度と本気度が見えてきます。事前に基準を決めておけば、感覚による選定も防げます。
協力義務を踏まえた要件凍結と発注側の責任
要件定義は、ベンダー任せにできない発注側の責任領域です。開発では、ベンダーの管理義務だけでなく、ユーザー（発注側）の協力義務も問われます。
発注側が役割を理解し、要件を確定させることは、トラブルと費用超過を防ぐことにつながります。
ユーザーの協力義務と判例から学ぶ要件の固め方
発注側の協力不足が敗訴の一因となった判例があります。争点になったのは、要件確定後の追加要望と、仕様凍結への協力でした。
- 事件：旭川医大病院とNTT東日本の間で争われた事件
- 追加要望：169項目のうち124項目は、開発対象外と判断された
- 支払い：ユーザー側だけに、約14億1,500万円が命じられた
控訴審の札幌高裁は、平成29年8月31日にユーザー側の協力義務違反を認定しました。大量の要望を後から出し、仕様凍結に協力しなかった点が責任とされました。
発注側は、主体的に意思決定し、合意した要件を凍結する責任があります。積算システムでも、現場と経営が要件を固め、「今回の範囲」に線を引きます。
後から要望を追加し続けると、費用が膨らむうえ、法的にも不利になりかねません。そこで、意思決定者が会議に出席し、合意を文書に残しておきます。
要件凍結と変更管理のルール
要件を固めたあとの変更は、正式な変更管理の手順で扱うルールを決めておきます。思いつきで工種を追加すると、手戻りが生じて日程と費用が膨らみます。
- 影響を確認：変更がどこまで及ぶかを見積もる
- 条件を合意：追加費用と納期への影響を見たうえで、双方が納得する形にする
変更の手順を契約や進め方に組み込んでおけば、追加対応の認識をそろえ、トラブルを防げます。
要件は完璧には固まりません。そこで、全機能を一括で開発せず、必須機能から作り、現場の反応を見ながら段階的に広げる方法も有効です。
各フェーズの要件は凍結したうえで作り、次の段階で得た学びを、次のフェーズに反映します。この進め方は、要件凍結と両立します。
こうした規律は、要件の膨張による費用超過や、発注側の協力義務違反という法的リスクを抑えます。自社業務の理解と変更管理の両方が必要です。
データ移行・マスタ整備の要件
データ移行とマスタ整備は、導入後の定着を左右します。単価マスタや過去データが整っていなければ、システムの力を発揮できません。要件に明記しておけば、稼働後に「使えない」という事態を防げます。
単価マスタのクレンジングと移行範囲の定義
既存の単価表や過去見積を移す前に、移行範囲と、クレンジング（データ整理）の担当を決めておきます。
- コード：工種コードの表記をそろえ、同じ工種を一つのコードで扱う
- 対象外：廃番になった材料は、移行の対象から外す
- 単価：古い単価ではなく、現行の単価に更新して移す
重複や表記の揺れをそのまま残すと、不要なデータを処理するだけのシステムになりかねません。単価が正しいかどうかは発注側でなければ判断しにくいため、ベンダー任せにはできません。
移行の範囲は欲張らないことも大切です。過去10年分をすべて移すと、整理の工数が膨らみ、費用と期間も増えてしまいます。そこで、直近の有効な単価と再利用の頻度が高い見積に絞り、残りは必要に応じて追加します。
マスタ整備は、ベンダーへの依頼分と自社で行う分を分け、双方の役割をはっきりさせます。担当者を決めておけば、後の混乱を防げます。
発注側はベンダーが整備するものと考え、ベンダーは単価の判断を発注側の役割と考えることがあります。こうした認識のずれは、クレンジングの担い手をめぐる導入トラブルの典型で、本番直前にデータが整わず、稼働が遅れることもあります。
要件定義の段階で、担当者・期限・対象範囲を文書にし、スケジュールに組み込みます。データ整備は、技術だけでは完結せず、業務知識も必要になります。そのため、発注側が関与する前提を最初に共有しておきます。
運用ルールと教育・定着支援の要件
機能だけでなく、稼働後の運用と定着も要件に含めておきます。運用の設計を先に決めておけば、稼働後の混乱を減らせます。
- マスタ更新：単価マスタを誰が更新するかを決めておく
- 承認：見積を誰がどの順で承認するかを定める
- 入力：入力の書き方を統一し、担当者による差を抑える
- 教育：操作教育やマニュアル、初期支援までを要件に含める
建設・リフォーム業界には、ITに不慣れな担当者もいます。そのため、教育をどこまで手厚くするかが、定着を左右します。
たとえば、稼働後はExcelと並行して運用し、現場が慣れたら一本化する移行計画も描けます。ただし、二重管理を漫然と続けると効果が出ません。旧運用を止める目標時期も、あらかじめ決めておきます。
riplaは、フルスクラッチ受託と国内開発の立場から、現状業務の可視化、マスタ整備、定着支援まで一貫して支援します。要件定義の段階から、使われるシステムを設計します。要件定義を丁寧に進めることが、その後の成否を左右します。
要件定義書・RFPを文書として残す意味
要件定義書やRFPは、社内の合意を形にし、後の認識違いを防ぐための記録です。口頭やメールの断片だけに頼ると、手戻りや追加費用につながりかねません。
- 合意を記録：誰が何に合意したのかを、文書で残す
- 凍結の根拠：凍結した要件が何かを、文書で示す
- 経緯を引き継ぐ：仕様を決めた背景を残す
文書があれば、協力義務をめぐる紛争でも、自社を守る材料になります。担当者が替わっても、判断の根拠をたどれます。文書は、導入後の運用や機能拡張、更新にも役立ちます。
積算システムは長く使う業務システムです。数年後にバージョンアップや乗り換えを検討する場面では、当初の要件定義書が検討の効率を左右します。
要件定義は、何度も見返しながら使う、システムのライフサイクルを支える資産です。文書化しておくことが、長期的な保守と進化の土台になります。
まとめ
成否は、現状業務の可視化とAX前提の標準化、目的起点の要件整理と具体的なRFPで左右されます。さらに、協力義務を踏まえた要件凍結と変更管理、データ移行・マスタ整備・定着支援も欠かせません。
旭川医大の判例では、大量の追加要望に関してユーザー側に約14億円（約14億1,500万円）の支払いが命じられました。判例が示すとおり、要件定義は、ベンダーに任せきれない発注側の責任領域です。
保守費は開発費の15〜20%が相場です。初期費用だけでなくTCOも踏まえて、RFPを作ります。
自社業務を言語化し、必須要件と運用、定着まで固めます。riplaは、現状業務の可視化から要件凍結、データ整備、定着支援まで伴走します。RFPの記載項目や費用相場の全体像は、積算システムの完全ガイドをご覧ください。
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。