システム開発の要件は、発注前に目的・範囲・優先順位・体制・運用の5点を固めておくことで、要件定義の手戻りを大きく減らせます。本記事では、建設業の現場特有の注意点も踏まえ、発注前に確認すべき判断基準を解説します。
システム開発の要件はどう決めるか？発注前の準備で成否の大半が決まる
要件定義とは、発注するシステムに「何を・どこまで・誰のために」実現してもらうかを言葉と資料にまとめる作業のことです。結論から言うと、要件定義そのものに着手する前に、目的・範囲・優先順位・体制・運用の5点を社内で固めておけるかどうかで、その後の手戻りの量が大きく変わります。開発会社との打ち合わせが始まってから「現場に聞いてみないと分からない」「それは想定していなかった」という話が続くと、仕様が固まらず見積りも遅れます。逆に、発注前にこの5点について社内の関係者（経営者・所長・事務担当など）の認識を合わせておくと、開発会社への説明が一本化され、要件定義の打ち合わせ回数自体を減らせます。つまり要件定義の成否は、発注後の技術的なやり取りよりも、発注前の社内整理の段階でおおよそ決まっているということです。
要件定義で最初に固めるべき5つの判断基準（目的・範囲・優先順位・体制・運用）
発注前に決めておくべきことは、次の5項目に整理できます。
項目 | 決めるべき内容 | 決まっていない場合に起きること |
|---|---|---|
目的（KPI） | このシステムで何を改善したいか（例: 原価集計の時間短縮） | 開発会社が機能の優先順位を判断できず、要望が全て「必須」扱いになる |
範囲 | どの業務・どの現場まで対象にするか | 対象外だったはずの業務まで仕様に含まれ、規模と費用が膨らむ |
優先順位 | 必須（Must）と、あれば良い（Should）の機能の切り分け | 予算超過時にどこを削るか判断できず、交渉が難航する |
体制 | 要件を最終的に誰が決めるか | 現場と事務所で意見が割れた際に決裁が止まる |
運用 | 納品後、誰が設定変更や問い合わせ対応を担うか | 導入後に使い方が分からず、現場で定着しない |
※KPI（目標の達成度を測る指標のこと）、Must（必須の機能）、Should（あれば望ましい機能）という意味です。
現場の所長・事務担当・経営者など複数の意思決定者がいる場合は、発注前に「最終的にどの立場の人が仕様を決めるか」を決めておくことが判断基準になります。これが曖昧なまま進むと、開発会社との打ち合わせの場で初めて意見の相違が表面化し、スケジュールが止まる原因になります。範囲についても、着手後に「ここも対応してほしい」という追加要望が出ることは珍しくありません。発注前に「追加要望が出た場合は今回対応するか次回に回すかをその場で判断する」という進め方まで決めておくと、範囲が際限なく広がる事態を防げます。
建設業の要件定義で見落とされやすい3つの視点
建設業の要件定義では、一般的なシステム開発記事が触れない3つの視点が見落とされやすい傾向があります。1つ目は、ベテラン所長が持つ暗黙知です。「この工種では資材発注を前倒しする」といった例外判断は文書化されていないことが多く、要件定義の場で言語化されないまま漏れてしまいます。2つ目は、原価管理など現場と事務所でデータの粒度が異なる情報の扱いです。現場では工区・工程単位の粗い実行予算で足りる場面がありますが、事務所では費目別の細かい集計が必要になることがあり、この粒度の違いをどちらに合わせるか決めておかないと、納品後に「使える数字になっていない」という不満につながります。3つ目は、実際にシステムを操作する人が必ずしもPC操作に慣れているとは限らないという前提です。発注側の窓口が本社の管理部門だけで要件を詰めてしまうと、現場での入力項目数や画面の複雑さが使う人の実態に合わず、不定着の原因になります。これら3点は、発注前に現場の声を直接聞く機会を設けることで要件に反映しやすくなります。
発注側はどこまで要件定義に関わるべきか（発注者の役割）
発注側（建設会社側）が要件定義を開発会社に丸投げすると、後工程での手戻りリスクが高まります。開発会社は一般的なシステムの作り方は分かっていても、現場の運用実態までは分かりません。発注者が担うべき役割は、「どの業務を」「誰が」「どんな場面で」システムを使うのかという実態と、譲れない判断基準を言語化して伝えることです。例えば日報入力であれば、現場で誰が入力するのか、何の情報を本社側がどう使うのかを発注者側が整理しておく必要があります。逆に、画面のボタン配置や処理速度の技術的な実現方法まで発注者が決める必要はありません。発注者は「業務の正解」を伝える役割、開発会社は「システムとしての実現方法」を考える役割、と線引きして考えると関与すべき範囲が見えやすくなります。
機能要件と非機能要件はどう切り分けて決めるか
機能要件と非機能要件は何が違うか
機能要件と非機能要件は、「何を作るか」と「どう動くべきか」という違いです。機能要件とは現場で実際に使う機能そのもの（例: 日報を入力する、写真を添付する、承認を回す等）を指します。非機能要件とは、性能・セキュリティ・使いやすさなど機能以外の品質条件を指し、普段は意識されにくい分だけ後から問題化しやすい領域です。
建設現場ではどう決めればよいか
建設現場特有の非機能要件としては、現場のネットワーク環境が不安定でも使えるか、電波が届かない場所でもオフラインで入力でき後で同期できるか、といった条件が挙げられます。決め方としては、まず機能要件を「現場で誰が何をするか」の業務の流れから洗い出し、その上で「その業務が止まると困る条件」を非機能要件として言語化する順序が分かりやすいです。機能だけを先に決めてしまうと、現場で使われてから通信環境の問題が表面化し、結局使われなくなるという事態につながりかねません。
要件定義書・RFP（発注仕様書）はどこまで作り込むべきか
要件定義書やRFP（提案依頼書。発注先に出す要望・要件をまとめた文書で、発注仕様書と呼ばれることもあります）をどこまで詳細に作るべきかは、社内の体制によって判断基準が変わります。社内に業務内容を整理できる担当者（所長や管理部門など）がいる場合は、自社である程度要件定義書を作成したうえで発注先に相談する進め方が適しています。要件が明確な分、提案や見積もりの精度も上がりやすくなります。一方、整理できる担当者が社内にいない場合は、要件定義の整理自体を一緒に進めてくれる発注先・支援者を選ぶ進め方が現実的です。この場合は最初から完成度の高いRFPを作ろうとせず、現状の課題や困っている業務を箇条書きでまとめる程度から始めても構いません。どちらの進め方を選ぶにしても、「誰が要件を整理する役割を担うのか」を発注前にはっきりさせておくことが、発注後のすれ違いを防ぐ分かれ道になります。
要件定義でよくある失敗パターンと回避策
要件定義がうまくいかないケースには、いくつかの共通パターンがあります。自社の進め方と照らし合わせ、当てはまる項目がないか確認してみてください。
目的が曖昧なまま始める：「何のために導入するか」を関係者間で言語化せずに打ち合わせを始めると、機能要望の寄せ集めになりがちです。要件定義に入る前に、解決したい課題を一文で言える状態にしておくことが回避策になります。
スコープが途中で膨らむ：スコープクリープ（当初決めた開発範囲が、打ち合わせの中で次第に広がってしまうこと）が起こると、工期・費用の見積もりが崩れます。追加要望が出た際は「今回入れるか、次回に回すか」をその場で判断し、記録に残すことが有効です。
意思決定できる人が打ち合わせにいない：現場担当者だけで話を進めると、持ち帰り確認が続いて停滞します。重要な判断が必要な打ち合わせには、決裁権を持つ人を同席させることが回避策です。
現場の暗黙知が文書化されない：所長や熟練者の頭の中にしかない判断基準は、開発側には伝わりません。業務の流れを図や箇条書きで一度書き出し、開発会社と共有しておくことが有効です。
発注側が丸投げする：要件定義を開発会社に任せきりにすると、現場の実情と合わないシステムになりやすいです。発注側が業務内容を説明する役割を担うという前提を、最初に確認しておくとよいでしょう。
発注の流れとスケジュール・体制の決め方
発注から要件定義完了までの流れ
一般的な発注の流れは、課題整理→発注先の選定→要件定義→見積もり確定という順になりますが、このうち要件定義の期間に最も時間がかかりやすいため、スケジュールには余裕を持たせておくことが大切です。決めたスケジュールを発注先の開発会社と共有しておくことも重要です。繁忙期を避けたい時期や、現場側の人員が動かせる期間を伝えておくことで、開発会社側も無理のない進行計画を立てやすくなります。
体制づくりで確保すべきこと
体制面では、経営層や所長など意思決定者が打ち合わせに参加できる状態を確保しておくことが欠かせません。加えて、現場の担当者が日々の業務を離れて打ち合わせに協力できる時間を事前に確保しておくことも必要です。打ち合わせのたびに現場が止まるようでは、協力体制が長続きしません。スケジュールと体制は、要件定義の内容そのものと同じくらい、発注の成否を左右する要素だと考えておくとよいでしょう。
まとめ
要件定義の失敗は、目的の曖昧さやスコープの膨張、意思決定者の不在、暗黙知の文書化不足、発注側の丸投げといった共通パターンから生じます。これらは事前に判断基準を持っておくことで回避できるものです。また、発注から要件定義完了までのスケジュールと体制を発注先と共有しておくことも、進行の停滞を防ぐ上で欠かせません。システム開発の発注で重要なのは、専門知識の有無ではなく、何を基準に判断するかをあらかじめ押さえておくことです。本論で紹介した判断基準を発注前に確認しておくことが、失敗を減らす近道になります。
よくある質問
Q. 要件定義にはどれくらいの期間がかかりますか？
プロジェクトの規模や社内の意思決定スピードによって変わります。目的・範囲が事前に整理されている場合は数週間程度で進むこともありますが、現場ヒアリングから始める場合はそれ以上かかることもあります。発注前に目的と範囲を固めておくほど、期間は短縮されやすくなります。
Q. 要件定義書とRFP（提案依頼書）は同じものですか？
役割が異なります。RFPは発注先に検討してほしい内容を伝える依頼文書で、要件定義書はシステムの仕様を詳細に記した文書です。発注初期はRFPで方向性を伝え、発注先が決まった後に要件定義書を詳細化していく進め方が一般的です。
Q. 社内に要件を整理できる担当者がいない場合はどうすればよいですか？
最初から完成度の高い資料を用意する必要はありません。現状の課題や困っている業務を箇条書きでまとめる程度から始め、要件の整理自体を一緒に進めてくれる発注先・支援者を選ぶという進め方が現実的です。
Q. パッケージ型のSaaSと個別のシステム開発、どちらを選ぶべきですか？
業務が標準的な範囲に収まるならSaaS、現場独自の運用や既存システムとの連携が多い場合は個別開発が検討対象になりやすいという整理ができます。どちらが適するかは、要件定義で自社の業務の特殊性がどの程度あるかを明らかにした後に判断するのが妥当です。
あわせて読みたい
自社のボトルネックを整理してから、要件を固める
システムの要件を考える前に立ち止まりたいのが、自社のどこが最も大きなボトルネックになっているかという視点です。最初から大規模なシステムを一括で導入するのではなく、小さく試して効果を確認しながら範囲を広げていく進め方であれば、要件を固める負担も小さくできます。何から手をつければよいか整理したい方は、まず現状の業務の棚卸しから始めてみてください。
お気軽にご相談ください
Contact
お気軽にご相談ください。60分の初回相談は完全無料。オンライン対応可能です。