建設・建築業界のシステムの要件定義は、現場業務の把握、要件の優先順位づけ、変更範囲の合意を順に進めると、現場に定着する導入につながります。
発注企業の立場から、現場調査、要件整理、RFP（提案依頼書）と要件定義書の作り方を解説します。全体像は建設・建築業界のシステムの完全ガイドもご覧ください。
▼全体ガイドの記事
・建設・建築業界のシステムの完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
現場ヒアリングと業務標準化から始める要件定義
要件定義は、機能を決める前に現場の業務を詳しく聞き取ることから始まります。建設・建築の現場には、長年の慣行や細かな取り決めが積み重なっているため、この聞き取りを省くことはできません。
実態を把握しないまま、発注側が「DXが流行りだから」と高機能なシステムを入れると、現場の反発を招きます。また、目的が曖昧なままトップダウンで進めることも、失敗の原因になります。そのため、要件定義は現場で実際に起きていることを出発点にします。
現状の業務フロー（AsIs）を把握するヒアリング
まず、現状の業務フロー（AsIs）を把握します。そのために、関係者に実際の進め方を聞き取り、無駄や手戻りが起きている箇所を確かめます。
- 聞き取り対象：現場監督、職人、積算担当、経理、経営層
- 確認する業務：写真整理、日報、見積、原価管理、安全書類
聞き取りでは、一人の理想ではなく、現場で実際に起きている事実を拾います。現場ごとに手順が違う場合は、その違いも把握しておきます。
現状を整理したら、次にあるべき業務の姿（ToBe）を設計します。その際は、導入を機に業務をどう変えるかを考えます。
たとえば、紙の日報を電子化するだけでなく、写真と日報を一体化して帰社後の作業をなくす案があります。業務そのものを改善するAXも、要件に含めます。
AsIsの把握とToBeの設計を順に行うことで、現場で使われるシステムの土台が整います。
業務標準化と過剰カスタマイズ回避の要件化
ToBeを描く際は、システムに合わせて統一できる業務を標準化します。現場ごとの違いをすべて個別対応にすると、過剰なカスタマイズにつながります。
過剰なカスタマイズは、バージョンアップを難しくします。さらに、ベンダーロックインを招き、保守費用が高止まりする原因にもなります。
一方で、自社の競争力の源泉となる独自業務まで標準化する必要はありません。業務のやり方が自社固有の価値を生むかどうかを、判断の基準にします。
- 標準機能に合わせる業務：日報、写真管理、安全書類などの定型業務
- 個別対応を検討する業務：見積の掛け率、原価管理の独自ロジックなど競争力に直結する業務
要件定義では、業務をシステムに合わせる発想を持つことが大切です。標準化とカスタマイズの線引きを明確にすると、コストと使い勝手を両立しやすくなります。
機能要件と非機能要件の整理
業務を整理したら、機能要件と非機能要件に落とし込みます。機能要件はシステムが行うことを、非機能要件は品質や性能の条件を定めるものです。両方をバランスよく整理すると、要件定義書の質が高まります。
建設・建築の現場では、スマホでの利用を前提に要件を組み立てます。操作性や応答速度、オフライン対応も、機能と同じくらい大切です。
機能要件の必須・優先・将来による分類
機能をすべて同列に扱わず、必要な時期と効果に応じて、発注側が優先順位を決めます。分類がないと、要求が膨らんで見積もりや開発期間が増えるおそれがあります。
- 必須：今、最も困っている業務を解決する機能
- 優先：導入すると効果が大きい機能
- 将来：当面なくても業務を回せる機能
この分類を、予算内で実現できる範囲に結びつけると、投資効果を高めるスコープを設計できます。
機能の分類では、現場利用者と経営層の双方の視点を入れることが大切です。求める効果は異なることがあり、現場は写真や日報の負担軽減を、経営層は原価管理による利益の把握を重視するかもしれません。
それぞれの評価基準をすり合わせ、全社で納得できる順位を決めます。機能要件の分類は、整理であると同時に社内合意をつくる作業です。この合意は、後の社内稟議を進める助けにもなります。
操作性・性能・セキュリティの非機能要件
建設・建築の非機能要件では、特に操作性を重視します。高齢のベテランやITに不慣れな職人にとって、複雑な画面は混乱の元になりかねません。
- 操作性：スマホやタブレットで直感的に扱える画面
- 入力負担：少ないタップで写真や日報を登録できる操作
- オフライン：通信が不安定でも入力でき、後で同期できる仕組み
通信が弱い現場では、オフライン対応が求められる場合があります。そのため、「誰もが迷わず使えること」のように求める状態を明記しておくと、提案を評価しやすくなります。
性能と可用性では、繁忙期でも安定して動くか、データのバックアップ体制が整っているかを確認します。セキュリティでは、図面や原価情報を守るため、協力会社に開示する情報の範囲を決め、アクセス権を管理します。
品質基準が曖昧だと、現場で使えない、情報が漏れるといった問題が起きかねません。だからこそ、要件定義書には機能だけでなく、こうした品質の基準も明記します。
外部連携とデータ移行の要件化
機能・非機能要件に加えて、外部連携とデータ移行も要件定義で詰めます。連携方式によって導入費用と期間が変わるため、既存の会計ソフトや基幹システムとの連携方式を、要件定義の段階で決めます。
- 標準連携：標準機能で既存システムと連携できる形
- CSV連携：CSVファイルでのデータのやり取り
- API連携：追加開発によるAPI接続
連携方式と対象を要件に明記しないと、会計データが合わない、二重入力が残るといった問題につながります。
データ移行は見落とされがちですが、導入の成否を左右する重要な論点です。何を移すかは、見積データや単価マスタを中心に決めます。過去案件や顧客情報も含め、対象範囲を要件に入れます。
移行前のクレンジングでは、重複削除、表記統一、不要データの除去を行います。古いデータをそのまま移すと、不要なデータを速く処理するだけになりかねません。
データをどの基準で整理するかは、発注者が事前に決めます。移行とクレンジングにかかる手間を明確にしておくことが、信頼できる数字を得る第一歩です。
RFP作成と要件凍結・ベンダー選定の進め方
整理した要件は、RFP（提案依頼書）にまとめてベンダーに提示します。RFPは、自社の希望を伝え、各社から比較できる提案を得るための文書です。
RFPの質が低いと、各社の前提が異なり、提案を適切に比べられません。そのため、発注者が主体的に作り込むことが、選定の前提になります。
RFPに盛り込むべき項目と業界理解の確認
RFPには、目的と背景を書いたうえで、記載項目を次のとおり3区分に分けます。
- 業務範囲：対象業務と機能要件の優先度
- 導入条件：非機能要件、既存システムとの連携
- 契約・運用：予算、希望スケジュール、保守・サポート条件
建設業の実績や、施工管理、積算、安全書類への理解を問う項目も入れます。業界特有の現場感や商習慣を理解しているかが、導入後の定着を左右するからです。
データ移行とマスタ整備の条件も明記します。見積データや単価マスタ、過去案件を、どの方法で移すかを定めます。古いデータをそのまま移すと不要なデータまで処理することになりかねないため、重複や表記揺れのクレンジング方法も決めておきます。
保守費用は開発費の15〜20%が一般的な目安です。この目安を踏まえ、初期費用だけでなく運用段階の費用まで含めた見積もりを求めます。
要件凍結とユーザーの協力義務
発注者にも、システム開発における法的な「協力義務」があります。開発は、ベンダーだけでなく発注者の協力があって初めて進みます。
要件を固める段階で必要な情報を出さないまま、仕様凍結後に大量の追加要望を出すと、プロジェクトが破綻しかねません。
旭川医大病院とNTT東日本の裁判では、控訴審の札幌高裁が平成29年8月31日にユーザーの協力義務違反を認定しました。169項目のうち124項目が開発対象外とされ、ユーザー側だけに約14億1,500万円の支払いが命じられました。
この判例は、要件を固めて合意した範囲を一度凍結することの大切さを示しています。仕様凍結後の追加要望を無秩序に受け入れないため、RFPと契約で決める事項を次のとおり整理します。
- 追加要望の基準：今回の範囲と別フェーズにする判断基準を定める
- 費用の扱い：変更に伴う費用をRFPと契約で明確にする
- 変更管理の責任：発注者が責任を持ち、混乱と法的リスクを防ぐ
riplaは、フルスクラッチ受託と国内開発の立場から、現場業務を起点にした要件整理を重視します。発注者とベンダー双方の役割を明確にして進めます。
提案評価とベンダー選定・社内稟議の進め方
RFPを提示してベンダーから提案を集めたら、評価、ベンダー選定、社内稟議へ進みます。評価では、見栄えや価格だけでなく、要件への適合度と現場への定着体制を合わせて見ます。
提案を比較評価するときの観点
各社を同じ基準で比べるため、評価の観点を事前にそろえておきます。RFPで尋ねた項目への回答を表にまとめると、提案の差が見えてきます。
- 要件適合：必須要件を満たす範囲
- 業界理解：施工管理、積算、安全書類への理解
- 費用と移行：見積内訳の妥当性、移行・クレンジング計画
- 導入後の支援：保守・サポート体制
建設・建築では、技術力や価格に加えて、現場への定着実績と業界理解が欠かせません。導入8万社・14万人に使われるサービスのように、現場を知るベンダーは導入支援の勘所を心得ています。
似た規模や業態での導入実績と、定着までの支援方法が具体的かを確認します。たとえ安価でも定着せずに作り直すことになれば、現場を理解するベンダーのほうが総コストを抑えられます。
社内稟議を通すROIの示し方
ベンダーを絞り込んだあとは、社内稟議が最後の関門になります。そこで、要件定義で整理した効果を、ROI（投資対効果）として数字で示します。効果を自社の金額に置き換え、初期費用と保守費用に対して提示します。
- 見積作成：作成時間50%削減を時給換算する
- 現場業務：写真・日報の現場完結で減らせる残業代
- 原価管理：原価を把握することで防げる赤字現場の損失
保守費用は開発費の15〜20%が目安です。効率化を漠然と示すだけでなく、回収年数まで示すと、稟議を通しやすくなります。
評価する人によって関心は異なるため、伝える内容も変えます。現場責任者には負担や残業の減少を、経理には利益を把握できる点を、経営者には人手不足のなかでも事業を回せる点を伝えます。
要件定義で現場、管理、経営の各層を巻き込むと、それぞれが投資を支持できる状態になります。要件定義は設計図であり、社内合意とROIの根拠をつくる作業です。
ここまでの流れは、現場ヒアリング、要件整理、RFP作成、提案評価、稟議の順に続きます。一貫して必要なのは、発注者が主体的に関わる姿勢です。
ベンダー任せでは、要件がベンダーの作りやすい形に寄り、現場の実態から離れるおそれがあります。そのため、発注者が業務を起点に要件と優先順位を決め、範囲を凍結します。
合意した範囲を凍結し、効果を数字で示すと、システムが現場に根づくことにつながります。一方で、導入企業の約7割は効果を実感できていないという現実があります。
この状況からすると、要件定義に主体的に取り組む会社が成果を出すと考えられます。急がば回れの考えで、前工程に十分な時間と労力をかけます。
それが開発、導入、定着を支え、要件を実装へ届けることにつながります。結果として、最も確実な投資になります。
まとめ
建設・建築業界の要件定義は、現場のAsIsを把握し、ToBeを描くところから始まります。そのうえで、業務を標準化し、要件の優先順位をつけてから、RFP作成、要件凍結、提案評価へ進みます。
業務を標準化して過剰なカスタマイズを避けたうえで、機能要件を必須・優先・将来に分けます。さらに、操作性や性能など、非機能要件も明記します。
RFPには、業界理解やデータ移行、保守費用まで含めます。また、発注者は要件凍結とユーザーの協力義務にも責任を持ちます。
工事管理アプリ導入企業の約7割が効果を実感できていない背景には、要件定義の甘さがあります。また、旭川医大の約14億1,500万円の判決は、ユーザーの協力義務の重さを示しています。
大切なのは、ベンダーに任せきりにせず、自社業務を起点に何を、なぜ、どこまで作るかを言語化することです。発注者が主体的に要件を整理することが、投資の成否を決めます。
現場の声を拾い、優先順位をつけて、合意した範囲を凍結します。この一連の作業が、現場に使われるシステムと、誰も使わないシステムを分けることになります。
riplaはフルスクラッチ受託と国内開発を組み合わせ、現場業務から逆算した要件整理と、発注者の負担を抑えた要件定義を支援します。全体像は完全ガイドをご覧ください。
▼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を創業。