Web開発における要件定義書の書き方とは？押さえるべき項目と整理のポイント

「web 要件定義書テンプレート」と検索して、要件定義書のひな形をそのまま流用しようとする発注者や開発担当者は少なくありません。しかし既成のテンプレートに項目を当てはめるだけでは、Webシステム特有の画面構成や外部サービス連携の要件が抜け落ち、後工程での手戻りにつながりやすくなります。本記事では、要件定義書に何を、どこまでの粒度で記載すれば発注者と開発会社の認識がそろうのかを、機能要件・非機能要件の記載例とあわせて整理します。テンプレートを使う場合も、まず本記事で紹介する項目を確認したうえで、自社のプロジェクトに合わせて中身を組み立てることが実務では重要です。

Web開発における要件定義書の役割

Web開発における要件定義書は、発注者が実現したい業務要件をシステムの機能・仕様に落とし込み、発注者と開発会社が同じ認識で開発を進めるための合意文書です。

要件定義書は、発注者側の「実現したいこと」と開発会社側の「作れるもの」をすり合わせ、双方が合意した内容を文書として残す役割を担います。合意内容が曖昧なまま設計・開発工程に進むと、完成後に「思っていたものと違う」という認識の齟齬が発生し、追加開発や仕様変更の交渉に時間とコストがかかります。要件定義書は、こうした手戻りを防ぐためのプロジェクトの土台となる文書です。

一般的な要件定義書との違い

Web開発の要件定義書は、業務システム向けの要件定義書に比べて、画面構成やユーザー導線、外部サービス連携に関する項目の比重が大きくなります。

情報処理推進機構(IPA)が公開する「超上流から攻めるIT化の事例集」では、要件定義フェーズの成果物を、業務の流れを表す機能要件(プロセス)、データの構造を表す機能要件(データ)、外部とのやり取りを表す機能要件(インターフェイス)、そして品質面の目標を定める非機能要件に整理しています。基幹システムや業務システムの要件定義書では機能要件(プロセス)と機能要件(データ)の比重が大きくなる一方、Web開発の要件定義書では、画面遷移・レスポンシブ対応・CMSの要否・決済やSNS認証などの外部サービス連携といった機能要件(インターフェイス)にあたる項目が加わり、比重が相対的に高くなる点が特徴です。加えて、Webサイト・Webサービスは公開後も継続的に更新・改修が発生するため、更新頻度や運用体制を見据えた記載が必要になる点も、業務システムの要件定義書とは異なります。

発注者・開発会社双方が確認すべき事項

発注者と開発会社は、要件定義書を確定させる前に、責任分担・変更管理のルール・保守体制の3点を特にすり合わせておく必要があります。

経済産業省とIPAが公開する「情報システム・モデル取引・契約書(第二版)」は、2020年12月に公開されたモデル契約のひな形で、要件定義を含む各開発工程においてユーザー企業とITベンダーがそれぞれ担うべき責務を整理しています。このモデル契約書が前提とする考え方は、要件定義書についても当てはまります。具体的には、①要件定義書に記載した内容の最終確認・承認は発注者の責任で行うこと、②要件定義書確定後に仕様変更が発生した場合の追加費用・スケジュールへの影響をどう扱うか、③公開後の保守・運用フェーズで誰がどこまで対応するか、の3点を要件定義書とあわせて文書化しておくと、後工程でのトラブルを避けやすくなります。

要件定義書に盛り込むべき項目

要件定義書に盛り込むべき主要項目は機能要件と非機能要件の2つに大別され、双方を漏れなく記載することで後工程の手戻りを防ぎやすくなります。

機能要件は「システムが何をするか」を定義する項目で、非機能要件は「どのレベルで実現するか」という品質面の目標を定義する項目です。テンプレートを使うかどうかに関わらず、この2つを分けて整理する考え方さえ押さえておけば、プロジェクトの規模に応じて自分たちで項目を組み立てられます。それぞれの具体的な記載内容を見ていきます。

機能要件(ページ構成・機能一覧)

機能要件では、サイト全体のページ構成と各画面が持つ機能を、一覧化して過不足なく洗い出すことが基本になります。

IPAの整理に沿うと、機能要件は業務の流れを表す「プロセス」、データの構造を表す「データ」、外部とのやり取りを表す「インターフェイス」の3種類に分けて記載すると網羅しやすくなります。Web開発の場合、ページ構成・画面遷移・入力フォームの項目定義・外部API連携の仕様が、それぞれこの3分類に対応します。以下は、架空のBtoC通販サイトを想定した機能要件一覧の記載例です。

このように画面ID・画面名・主な機能・外部連携の有無を一覧化しておくと、開発会社が見積もりを作成する際の精度が上がるだけでなく、発注者自身も「どの画面に何が必要か」を後から確認しやすくなります。項目を増やす場合も、画面ごとに機能を1行で言い切れる粒度でまとめることが、次の章で解説する曖昧な表現を避ける書き方にもつながります。

非機能要件(性能・セキュリティ・保守性)

非機能要件では、性能・セキュリティ・保守性など、目に見えにくい品質面の要求を数値や具体的な条件で記載することが重要です。

IPAが公開する「非機能要求グレード」は、非機能要求についてユーザーと開発者の間で認識の行き違いが起きるのを防ぐ目的で2018年に整備された資料で、非機能要求の項目を可用性・性能効率性・運用保守性・移行性・セキュリティ・システム環境/エコロジーという6つの大項目に分類し、検討漏れを防ぐチェックリストとして活用できる形で整理しています。Web開発の要件定義書でも、この6分類を参考に必要な項目を絞り込むと網羅性を確保しやすくなります。以下は、架空のBtoC通販サイトを想定した非機能要件の記載例です。

非機能要件は機能要件に比べて発注者側がイメージしにくい項目ですが、「〜秒以内」「〜%以上」のように測定可能な数値で記載しておくことで、開発会社との合意形成がしやすくなります。数値化が難しい項目は、「〜のような状態を目指す」といった達成条件を具体的に書き添えるだけでも、認識のずれを防ぐ効果があります。

記載時に注意すべきポイント

要件定義書を記載する際は、曖昧な表現を避けることと、後工程で検証できる粒度で書くことの2点に特に注意が必要です。

せっかく機能要件・非機能要件の項目を網羅していても、記載の仕方が曖昧だと、発注者と開発会社の間で解釈が分かれてしまいます。ここでは、実務でつまずきやすい2つのポイントを整理します。

曖昧な表現を避けるための書き方

「使いやすい」「わかりやすい」といった主観的な表現は、検証可能な条件に言い換えることで解釈の幅を狭められます。

NG例に共通するのは、達成できたかどうかを客観的に判断できない書き方になっている点です。OK例のように数値や具体的な操作手順に置き換えることで、開発会社は設計・実装の指針を得やすくなり、発注者側も検収時に要件を満たしているかを確認しやすくなります。

後工程(設計・テスト)を意識した粒度

要件定義書の各項目は、後工程のテストで合否を判定できる粒度まで具体化しておくと、設計・テスト工程との整合が取りやすくなります。

要件定義書に書かれた項目は、その後の設計工程で画面設計書やデータベース設計書に、テスト工程でテスト項目書に、それぞれ具体化されていきます。この際、要件定義書の記載が抽象的すぎると、設計担当者が独自の解釈で仕様を補ってしまい、発注者の意図と異なる形で実装が進んでしまうことがあります。目安としては、要件定義書の1項目に対して「何をもって完了とするか」を一文で説明できるかどうかを確認する方法が実務的です。説明できない項目は、テスト工程で検証可能な条件まで分解してから要件定義書に落とし込むことをおすすめします。

独立コンサルタントとしての関わり方

独立系ITコンサルタントは、要件定義フェーズにおいて発注者側の立場に立ち、開発会社が作成する要件定義書の抜け漏れを確認する役割を担うことがあります。

発注者企業の多くは、社内に要件定義の専門知識を持つ担当者を常に確保できているわけではありません。特に中小企業やIT部門を持たない事業会社では、開発会社から提示された要件定義書の内容が十分かどうかを判断できないまま契約を進めてしまうケースも見られます。こうした場面で、独立系ITコンサルタントが発注者側のアドバイザーとして要件整理を支援する需要が生まれています。

発注者側に立った要件整理支援

発注者側に立つコンサルタントの役割は、開発会社の提示する要件定義書を鵜呑みにせず、機能要件・非機能要件の抜け漏れを発注者の言葉で確認し直すことです。

コンサルタントの歩み編集部が要件定義支援に携わる独立コンサルタントを取材したところ、こうした案件は「PMO」「要件定義支援」といった名称で募集されることが多く、開発会社と発注者の間に立って議事録の整理やヒアリングの進行を担うことが多いという声が聞かれました。要件定義フェーズを主導するPMO/PM人材としての専門性を示す手段として、PMP(Project Management Professional、PMI認定)のような資格を取得しておくと、案件を紹介するエージェント側にもスキルシート上で説明しやすいという指摘もあります。もっとも、単価や評価を最終的に左右するのは資格の有無よりも、担当したプロジェクトの規模や要件定義フェーズでの役割の大きさであるという点は変わりません。要件定義書を正確に読み解き、発注者の意図を代弁できる実務経験こそが、独立コンサルタントとして案件を獲得し、単価交渉を有利に進めるための土台になります。

まとめ

要件定義書は、機能要件と非機能要件を漏れなく整理し、曖昧な表現を避けて記載することで、発注者と開発会社の認識をそろえるための文書です。

要点の整理

• 要件定義書は、発注者と開発会社が同じ認識で開発を進めるための合意文書である
• 機能要件はページ構成・画面遷移・外部連携などプロセス/データ/インターフェイスの3分類で整理する
• 非機能要件は可用性・性能・セキュリティなど、IPAの非機能要求グレードの6分類を参考に数値で記載する
• 曖昧な表現は検証可能な条件に言い換え、テスト工程で合否判定できる粒度まで具体化する
• 独立コンサルタントは発注者側に立って要件整理を支援する役割を担うことがある

要件定義書の具体例トピックへの導線

要件定義書の中でもデータに関する項目を整理する際は、要件定義とデータ設計の関係を押さえておくと、機能要件(データ)の記載精度をさらに高められます。要件定義書は一度作成して終わりではなく、プロジェクトの進行にあわせて見直しを重ねていくものです。本記事で紹介した項目・書き方を土台に、自社のプロジェクト規模に合わせて内容を組み立てていくことをおすすめします。本記事は2026年9月時点の情報に基づいています。

出典・参考情報

1. IPA(情報処理推進機構)「超上流から攻めるIT化の事例集：要件定義」（2026-09-14参照）
2. IPA(情報処理推進機構)「情報システム・モデル取引・契約書（第二版）」（2026-09-14参照）
3. IPA(情報処理推進機構)「非機能要求グレード」紹介ページ（2026-09-14参照）
4. PMI日本支部（PM/PMO関連資格に関する一次情報、2026-09-14参照）

本記事は2026年9月時点の情報に基づいています。