⚠️ この記事について
この記事はAI（Claude）を活用して作成しています。
以下の点にご注意ください：
- 情報の鮮度: 記事作成時点（2026年7月）の情報です。ガイドラインは改定される場合があるため、最新情報は必ず一次情報でご確認ください
- 適用範囲の確認: 紹介する内容は主に政府情報システムを対象としたガイドラインですが、民間の要件定義にも応用できる考え方が多く含まれています。ご自身のプロジェクトの規模・性質に合わせて取捨選択してください
- 出典の確認: 重要な実務判断は本文中の参考リンクや公式ドキュメントで必ず一次確認をお願いします
- 誤りの可能性: AI生成コンテンツには誤りが含まれる場合があります。お気づきの点はコメントでご指摘ください
はじめに
「要件定義」という言葉はシステム開発に関わる人なら誰でも聞いたことがあると思いますが、いざ「要件定義とは何か、何をどこまでやればいいのか」を説明しようとすると意外と難しいものです。特に発注者側（PM・PdM・企画担当者など）にとっては、「事業者に任せておけば大丈夫だろう」と思ってしまいがちですが、それは大きな落とし穴です。
本記事では、日本政府のデジタル庁が公開している「デジタル・ガバメント推進標準ガイドライン」および、その実践的な解説である「実践ガイドブック（第３編第５章 要件定義）」の内容をベースに、要件定義の基本的な考え方から、実際に何をどう定義していくのかという実務レベルの進め方までを、1つの記事にまとめました12。
政府調達のために書かれたガイドラインではありますが、業務要件・機能要件・非機能要件を体系立てて整理する考え方は、民間のシステム開発やSaaS導入プロジェクトにもそのまま活用できる内容になっています。
この記事を読むとわかること：
- 要件定義とは何か、なぜ重要なのか
- 要件定義の全体の流れ（事前準備〜RFI〜定義〜終了後の対応）
- 機能要件として定義すべき5つの領域
- 非機能要件として定義すべき17個の領域
- 要件定義でよくある失敗パターンと対策
要件定義とは何か
要件定義とは、これから構築する情報システムが「何を実現すべきか」を明確にし、ドキュメントとして言語化する工程のことです。一般的なシステム開発の上流工程では、以下のような順序で検討が進みます。
政策目的・事業目標
↓
業務要件（どんな業務をどう実現したいか）
↓
機能要件（システムがどんな機能を持つべきか）
↓
非機能要件（性能・セキュリティなど機能以外の品質要件）
デジタル庁の実践ガイドブックでは、要件定義は業務要件・機能要件・非機能要件の3種類から構成されるとしており、特に機能要件・非機能要件は専門的な内容を多く含むため事業者の支援を受けることもあるが、要件定義の実質的な部分を事業者に丸投げするとプロジェクトはうまくいかないと強調されています2。家を建てるときにどんなに優秀な建築士がついても、施主自身が要望を伝えて選択しなければ理想の家にならないのと同じで、発注者（プロジェクトを企画する側）が主体的に検討することが重要だとされています。
つまり要件定義とは、「システムに詳しい人だけが行う専門作業」ではなく、「事業やサービスの目的を一番理解している人が、その実現方法をシステムという形に翻訳していく共同作業」だと捉えるとイメージしやすいと思います。
要件定義の全体の流れ
デジタル庁の実践ガイドブックでは、要件定義の進め方を大きく6つのステップで整理しています2。
| ステップ | 内容 |
|---|---|
| Step.2 事前準備 | プロジェクト目標・業務要件の把握、知識の属人化防止 |
| Step.3 RFIの実施 | 事業者から技術動向や実現方式の情報を収集 |
| Step.4 要件定義の全体像の把握 | 業務要件・機能要件・非機能要件の構造を理解する |
| Step.5 機能要件の定義 | 機能・画面・帳票・データ・外部インタフェースを定義 |
| Step.6 非機能要件の定義 | 性能・セキュリティなど17領域を定義 |
| Step.7 終了後の対応 | 関係者への共有、プロジェクト計画書への反映 |
それぞれのステップについて、実務で押さえておきたいポイントを見ていきます。
Step.2 事前準備でやるべきこと
要件定義を始める前に重要なのが、「そもそも何のためにこのシステムを作るのか」という上位目的を見失わないことです。実践ガイドブックでは、関係者の要望をそのまま取り入れようとすると要件がどんどん膨らんでしまうケースが多いため、要件が過度に増加した場合は法令・政策目的・プロジェクト目標まで立ち返り、必要十分な範囲を選び直すことが重要だと述べられています2。
また、要件定義の過程で担当者が得る知識（なぜこの仕様にしたのか、という背景や経緯）は、ドキュメント化しにくい「暗黙知」であることが多く、担当者の異動によってこの知識が失われると、後工程で判断ミスや手戻りが発生するリスクがあるとも指摘されています2。要件定義は複数人で行い、相互にレビューすることで知識の属人化を防ぐことが推奨されています。
Step.3 RFIで情報収集する
RFI（Request For Information：情報提供依頼）とは、構築しようとしているシステムについて、技術動向や実現方式、概算予算、想定されるリスクなどの情報を、複数の事業者に対して依頼する活動です2。
自分たちの知識・経験だけでは、世の中の技術動向やサービスの選択肢を網羅的に把握することは困難です。RFIを行わずに要件定義を進めてしまうと、費用対効果の良い方式を採用できなかったり、優れた先進事例を取り込めなかったりするリスクがあるとされています2。
RFIで求める情報の例としては、以下のようなものが挙げられています2。
- 市場にあるサービスの種類とその動向
- 国内外の類似事例とその教訓
- 新たな技術動向や製品のライフサイクル
- 要件を実現する方式とその実現可能性・制約事項
- 概算の予算規模、大まかなスケジュール
- 著作権や法的な制約、実現に際してのリスク
Step.4 要件定義の全体像を理解する
要件定義は定義すべき項目が非常に多く、検討が進むほど「漏れがないか」「重複していないか」不安になりがちです。実践ガイドブックでは、要件定義書が完成した後の最終確認の観点として、以下の8つを挙げています2。
| 確認の観点 | 内容 |
|---|---|
| 必要性 | 政策目的・目標達成に貢献する要件のみが定義されているか |
| 網羅性 | 業務要件が漏れなく定義され、対応する機能・非機能要件が漏れなく定義されているか |
| 具体性 | 実現の難易度や調達コストに影響する不確定要素が排除されているか |
| 定量性 | 規模や性能について計測可能な指標と目標値が設定されているか |
| 整合性 | 業務・機能・非機能要件の内容に矛盾がないか |
| 中立性 | 特定事業者に不必要に依存した内容になっていないか |
| 役割分担の明確性 | 発注者と事業者の役割分担が明確か |
| 情報セキュリティ | セキュリティポリシー上必要な対策が漏れなく定義されているか |
また、機能をすべて実現できるとは限らないため、政策目的やプロジェクト目標との関係、費用対効果の観点から優先順位を判断すること、業務担当者の手作業で代替する選択肢も合わせて検討することが推奨されています2。
機能要件の定義：5つの領域
機能要件として定義すべき内容は、大きく次の5つの領域に分類されます2。バッチ処理のみのシステムであれば画面の定義が不要になるなど、システムの性質によって一部が省略される場合もあります。
1. 機能に関する事項
「機能」とは、システムが外部に価値を提供する一連の動作のまとまりで、基本的に「入力」「演算（処理）」「出力」の3要素で構成されます2。これらを一覧化したドキュメントを「情報システム機能一覧」と呼びます。
業務要件を詳細化していくことで機能要件を洗い出すことができます。たとえば「〇〇申告書をオンラインで作成する」という業務要件は、「申告内容を新規登録する」「申告内容を更新する」「申告内容を削除する」「〇〇申告書を作成する」「〇〇申告書をPDFでダウンロードする」といった機能に分解できます2。ユーザーアカウントの追加・削除やログ検索など、システム管理者が使う「管理系の機能」も忘れずに検討する必要があると注意喚起されています。
2. 画面に関する事項
画面に関する要件は、画面一覧・画面イメージ（モックアップ）・画面遷移図・画面設計方針書といったドキュメントで整理します2。
実務上とても重要なポイントとして、「画面イメージや画面遷移図を細かく決めすぎない」ことが挙げられています。現場の意見を聞きすぎると、いつまでも要件が確定しない事態に陥りやすく、また詳細に決めすぎるとクラウドサービスやパッケージ製品を採用しようとしたときに「適合するものがない」という弊害につながるためです2。要件定義段階での画面イメージは、あくまで作業規模の見積りと、後工程で詳細設計を行うための要求事項に過ぎないと位置づけられています。
3. 帳票に関する事項
帳票とは、業務で使用するために出力される紙やPDF形式の電子帳票を指します。帳票一覧・帳票イメージ・帳票設計方針書として整理します2。画面と同様、法定帳票などフォーマットが確定しているもの以外は、細かいレイアウトまで決め込みすぎないことが推奨されています。
4. データに関する事項
データはシステムの中で管理される、利用者からは見えない情報ですが、「国民共有の財産」として広く利活用されることを想定しなければならないとされています2。データに関する定義では、以下のようなドキュメントを整備することが推奨されています。
| ドキュメント | 概要 |
|---|---|
| データモデル | データ同士の関連をER図等で表現したもの |
| データ一覧 | データのまとまり単位を一覧化したもの |
| データ定義 | データ項目の内容・意味・表現ルールを定義したもの |
| CRUDマトリクス | 機能ごとにデータがどう変化するか（Create/Read/Update/Delete）を整理したもの |
| コード一覧・コード内容定義 | システム内で使うコードの構造と意味を定義したもの |
| オープンデータ一覧 | 一般公開する対象データの一覧 |
特に強調されているのが「データの品質確保」です。「1丁目」と「一丁目」のように、人間にとっては同じ意味でもコンピュータ内部では全く別のデータとして扱われてしまうため、データ項目には厳格な定義が必要だと解説されています2。また、機密性の高いデータについては分類と管理方法を明確にしておくことが、情報漏えいを防ぐ上で最も重要な作業の一つだとされています。
5. 外部インタフェースに関する事項
自分のシステムが他のシステムと連携して情報をやり取りする仕組みを定義します。「外部インタフェース一覧」として、連携先システム、送受信のタイミング・条件、実装方式などを整理します2。連携先システムの要件が確定していない場合はその理由を、障害発生時の代替手段があればそれも記述しておくことが推奨されています。
機能要件を書くときの心構え
実践ガイドブックでは、「実現手段ではなく、求める結果を記載する」ことの重要性が強調されています2。要件定義の段階で「どう処理するか」まで細かく決めてしまうと、システムの専門家である事業者が最適な実現方式を提案できなくなってしまうためです。特に既存システムの更改では、使い慣れているという理由だけで古い仕様をそのまま踏襲してしまい、更改の目的を果たせなくなるケースに注意が必要だと述べられています。
非機能要件の定義：17の領域
非機能要件は「機能」以外の品質要件で、機能要件とは異なり基本的にすべての項目を定義する必要があるとされています2。以下の17領域が定義対象です。
| 分類 | 概要 |
|---|---|
| A. ユーザビリティ・アクセシビリティ | 使いやすさ、目的の情報へのたどり着きやすさ |
| B. システム方式 | アーキテクチャ、OSS活用方針などの全体方針 |
| C. 規模 | 利用者数、データ量などの定量的な規模 |
| D. 性能 | 応答時間、スループットなどの処理能力 |
| E. 信頼性 | 平均故障間隔（MTBF）など故障への耐性 |
| F. 拡張性 | 将来の性能・機能向上への対応しやすさ |
| G. 上位互換性 | バージョンアップ時の互換性 |
| H. 中立性 | 特定ベンダーへの依存を避ける度合い（ベンダーロックイン対策） |
| I. 継続性 | 障害時の目標復旧時間などBCPに関わる要件 |
| J. 情報セキュリティ | 機密性・完全性・可用性を確保する対策 |
| K. 情報システム稼働環境 | ハードウェア・ソフトウェア・ネットワーク・施設の構成 |
| L. テスト | 単体・結合・総合・受入テストの内容 |
| M. 移行 | データ移行・システム移行・業務運用移行 |
| N. 引継ぎ | 事業者交代時の引継ぎ項目 |
| O. 教育 | 利用者向け研修・教材の要件 |
| P. 運用 | 運転管理・監視、運用サポート体制 |
| Q. 保守 | 是正保守・予防保守・適応保守・完全化保守 |
これらすべてを一度に細かく決める必要はありませんが、性能や信頼性の要件は「十分な」といった曖昧な表現ではなく、「同時アクセス可能人数：XX人」「稼働率99.99%」のように定量的に定義することが重要だと繰り返し述べられています2。過大な非機能要件を設定すると、それだけ調達コストが跳ね上がってしまうため、業務要件に見合った適切な水準を見極めるバランス感覚が求められます。
非機能要件の中でも特に実務でつまずきやすいのが、機能要件との相互影響です。実践ガイドブックでは、複数の類似画面を保守コスト削減のために統合した結果、プルダウンに表示する組織名称のデータ量が増えて画面表示性能が大幅に劣化してしまった事例が紹介されています2。機能要件だけを見ていると問題なさそうでも、非機能要件（規模・性能）の観点から見直しが必要になることがある、という教訓です。
Step.7 要件定義が終わったら
要件定義書ができあがったら、それで終わりではありません。実践ガイドブックでは以下の2点を忘れずに実施するよう案内されています2。
- 関係者への共有：要件定義書を関係者に確認してもらうことで、これまで気づかなかった考慮漏れが発見できることがあります。変更要望や新たな課題が見つかった場合は、業務要件まで立ち返って対応方針を検討し、再度共有します。
- プロジェクト計画書への反映：要件定義の過程で当初の計画からずれが生じた項目を、プロジェクト計画書に反映して最新化します。これにより、後続の調達や設計・開発を計画に沿って進めやすくなります。
まとめ
- 要件定義とは、システムが実現すべきことを「業務要件」「機能要件」「非機能要件」の3階層で言語化する工程であり、発注者側が主体的に関わる必要がある
- 事前準備として、プロジェクトの上位目的を把握し、担当者の暗黙知を属人化させない体制を作ることが重要
- RFI等を通じて事業者から技術動向や実現方式の情報を集めることで、手戻りや調達失敗のリスクを減らせる
- 機能要件は「機能・画面・帳票・データ・外部インタフェース」の5領域、非機能要件は「ユーザビリティからテスト・移行・運用・保守」まで17領域に整理して定義する
- 要件定義では「実現手段」ではなく「求める結果」を記載し、定量的な表現を心がける
- 完成した要件定義書は関係者に共有し、プロジェクト計画書にも反映して最新化する
要件定義は項目が非常に多く、専門的にも見えますが、デジタル庁のガイドラインが示す構造に沿って一つずつ整理していけば、抜け漏れの少ない要件定義書を作成できます。実際にテンプレート（機能要件定義書・非機能要件定義書のひな形）も公開されているので、自分たちのプロジェクトに合わせてカスタマイズしながら活用してみてください2。