0. はじめに
今回は、要件定義についてです。
要件定義のポイントや注意点について説明していきます。
できれば、要件定義の「提案前」に読んでください。
（理由は、読めばわかります）
1. 要件定義のポイント＆注意点
1-1. 要件定義には2種類ある
まず、要件定義ですが、そもそも大きく分けて2種類あります。
１つ目が「業務要件定義」、2つ目が「システム要件定義」です。
1つ目の「業務要件定義」は、そもそもお客様が業務をするうえで求める要件・要望を取りまとめる工程です。
SIer（システムインテグレータ）が実施することもありますが、お客様自身で実施したり、コンサルティングファーム等の上流工程を得意とする会社が実施することもあります。
また、「業務要件定義」という名称ではなく、現状分析や将来構想、ロードマップ策定等の中に、業務要件定義が含まれることもあります。
2つ目の「システム要件定義」は、その名の通り、お客様の（業務）要件・要望をシステム化するための工程です。
システム化する際に求める機能を定義したり、機能以外の部分（非機能要件）を定義します。
SIerが実施することもありますし、当然お客様自身で実施することもあります。
お客様から要件定義の依頼があった場合、また「要件定義書」を受け取って後続工程を進める場合、
内容が「業務要件」なのか「システム要件」なのか、見極めが必要です。
内容が「業務要件」「システム要件」という風にわかりやすく記載されていれば見極めやすいですが、
あまり意識せずに記載されている場合もあります。
その場合、お客様の要件・要望を分解するというプロセスが必要になります。
お客様自身もあまり意識せず、「要件定義お願い」という場合もあります。
何はともあれ、お客様が求めているものが「業務要件」なのか「システム要件」なのか（あるいは両方なのか）、
はっきりさせたうえで進めることが重要です。
1-2. システム要件定義にも2種類ある
実は、システム要件定義にも2種類あります。
（ややこしいこと言いやがって、と思うかもしれませんが、もう少しお付き合いください）
１つ目が「特定のシステムを想定しないシステム要件定義」、2つ目が「特定のシステムを想定したシステム要件定義」です。
1つ目の「特定のシステムを想定しないシステム要件定義」は、システムに求める要件・要望を取りまとめる工程です。
ここでいう「特定のシステム」とは、○○社の△△パッケージとか、□□社の☆☆クラウドサービスとか、そういう具体的なシステムを指します。
つまり、「特定のシステムを想定しないシステム要件定義」は、具体的なシステム固有の要件定義ではなく、あくまで業務を実現するためのシステムとして求める要件・要望をまとめるための工程となります。
「特定のシステムを想定しないシステム要件定義」を取りまとめたものは、RFPという形でまとめる場合もあります。
その場合、RFPをSIerやSaaSベンダー/パッケージベンダーに提示し、適したシステムを提案してもらうことになります。
特定のシステムを想定していないため、どのシステムを選定するかはSIerの腕の見せ所です。
最適なシステムが無い場合は、新規でプログラム開発する提案をする場合もあります。
一方、2つ目の「特定のシステムを想定したシステム要件定義」は、文字通り利用するシステムを決めた状態でのシステム要件定義です。
業務システム要件定義後に、お客様要件にあうシステムを選定した後、実施します。
また、RFPに基づき最適なシステムを選定した後、実施する場合もあります。
「特定のシステムを想定したシステム要件定義」は、利用するシステムが決まっているので、比較的構築するシステムをイメージしながら進めることができます。
ただし、何をどこまでいつまでに実現するのか、その要件は基本機能で実現できるのかオプション機能が必要なのか、はたまた追加開発が必要なのか、を考えながら進めたほうが手戻りが少なくなります。
1-3. 「機能要件」を定義しよう
要件定義の肝となる項目の一つに「機能要件」があります。
構築するシステムに求める「機能」に関する要望をまとめる作業です。
そのため、機能要件の項目は、構築するシステムによって異なります。
そのため、あまり汎用的な目次案が存在しません。
また、お客様によっても求める機能が異なることもあるため、目次案の立案は悩ましい問題です。
一般的なパッケージやクラウドサービスが持つ機能から、
機能要件として検討が必要な項目を洗い出す、という方法もありです。
または、ガイドライン等がある場合は、要件として確認すべき項目を洗い出す方法もあります。
どちらにしても、要件定義の機能要件は経験やノウハウが重要になってきます。
「特定のシステムを想定したシステム要件定義」の場合、SaaSベンダー/パッケージベンダーに依頼するか、それらのベンダーが推奨するSIerを利用した方が良いでしょう。
1-4. 「非機能要件」を定義しよう
機能要件と比べ、少し忘れられがちなのが「非機能要件」です。
これは、通常あまり意識していない（できて当然）と思ってしまう範囲のため、「要件」として主張されることが少ないためです。
そのため、非機能要件を漏れなく定義できるお客様は、少ないのではないでしょうか。
そういう意味で、この辺りはSIerの腕の見せ所でもあります。
なお、この状況を防ぐ方法の一つとして、IPAの「非機能要求グレード」があります。
https://www.ipa.go.jp/archive/digital/iot-en-ci/jyouryuu/hikinou/ent03-b.html
非機能として検討すべき主要項目が含まれていますので、参考にしてください。
クラウド利用の場合、例えばAWSであれば「AWS Well-Architected フレームワーク」は非常に参考になると思います。
https://aws.amazon.com/jp/architecture/well-architected/
セキュリティを考える場合、NISTの「The NIST Cybersecurity Framework (CSF) 2.0」も参考にするとよいでしょう。
https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.29.pdf
世の中には参考になる資料がたくさんありますので、うまく活用して非機能要件を進めてください。
1-5. 「機能要件」「非機能要件」以外も定義しよう
要件定義工程では、「機能要件」「非機能要件」を決めて要件定義書に記載しますが、それ以外にも決めておきたいことがあります。
例えば「テスト方針」「移行方針」です。
1-5-1. テスト方針
「テスト方針」は、どういうテストをどのタイミングで実施するかを定義します。
例えば「単体テスト」「結合テスト」「システムテスト」「移行テスト」等があった場合、これらのテストでは何をどこまで実施するのかを定義します。
大事なことは、テスト漏れを防ぐことです。つまり、今回実施する様々なテスト項目が、上記のテストカテゴリのどこかに必ず含まれるように方針を決める必要があります。
さらに、それぞれのテストを誰が実施して、誰が承認するのかの責任を明確にしておく必要があります。
テストで使用する環境の定義も必要です。
例えば、本番環境の結合テストは、既存の本番環境と接続して実施するのか、それとも既存の検証環境と接続して実施するのか？ システムテストの場合はどうか？などです。
それぞれのテストを、どの環境でどれだけ実施するのかも定義しておきましょう。
例えば、本番環境、開発環境、検証環境がある場合、すべての環境でシステムテストを全ケース実施するのか、それとも開発環境では全ケース実施するが本番環境ではサンプリングによる実施にするのか、などです。
方針のすり合わせの時点でスケジュール的に無理が無いか、使用しようとしている環境が空いているのか（使えるのか）、平日昼間で実施できるのか（深夜作業でないと実施できないのか）、大まかに確認しておくことが重要です。
1-5-2. 移行方針
同様に「移行方針」も要件定義で検討して、記載しておいたほうがよい項目です。
「移行方針」は、どのシステムのどのデータを、どのタイミングで移行するかを定義します。
すべてのデータ/システムを一括で移行できることは稀です。
そのため、移行はステップを区切って実施することになります。
どのデータ/システムを、どのステップで移行するのか、
データはどうやって旧システムから抜き出して、新システムに投入するのか、
既存ツールでデータ抽出できるのか、新規にツール開発しないといけないのか、
移行手順書はどの環境を使って作るのか、
移行テストは何回実施するのか、
移行リハーサル実施後にデータ/システムは元に戻すのか、そのまま暫定運用してしまうのか、
移行失敗時の切り戻しはどうするのか、
移行切り戻しの判断基準はどうするか、
移行テストのデータはダミーを使うのか、本番データをマスクして使うのか、
データは一括で移行するのか、差分移行するのか、
移行後の旧システム平行稼働はどの程度許容するのか、
旧システムの停止はいつどのタイミングで実施するか（これはそもそも「移行」に含める作業なのか）、
などなど
細かい点は「移行設計（基本設計の一部）」で実施するべきテーマですが、
大枠の方針としてどうするかを決めておくことが重要です。
（この「移行方針」に基づき、後続工程の工数見積もりが変わるので）
1-6. 後続のどの工程で何をどこまでするかを定義しよう
要件定義で決めておくべきことは、まだまだあります。
それは、どこの工程で何をすべきか、です。
さきどほどの「「機能要件」「非機能要件」以外も定義しよう」にも関係する話ですが、
どの工程で何をするかの認識合わせを「要件定義」で実施しておかないと、後々後悔します。
「検討漏れ」で工数（見積）してなくて泣く泣くタダでやる羽目になったりとか、
気づいたタイミングで検討した結果スケジュールが遅延して本番リリース影響でたりだとか、
後悔事例は様々です。
さて、具体的には何を決めておくべきなんでしょうか？
例えば、テスト仕様書です。
単体テスト仕様書、どこの工程で作成するのでしょう？
単体テスト工程の最初の方でしょうか？
それとも、構築工程の最後の方でしょうか？
どっちでも一緒じゃないの？ と思うかもしれません。
確かに、一緒の場合もあります。でも、違う場合もあります。
例えば、構築工程の最後に単体テスト仕様書を作る場合、
単体テスト仕様書の完了が構築工程の完了条件になっているはずです。
つまり、単体テスト仕様書が完成していないと次の工程にすすめない、ということになります。
一方、単体テスト工程の最初に単体テスト仕様書を作る場合、
構築工程とは切り離して考えることができるため、（条件にもよりますが）構築工程は完了させることができます。
同様のものに、手順書があります。
例えば、構築手順書、どこの工程で作成するのでしょうか？
構築工程の最初の方でしょうか？
それとも、構築工程を速やかに進めるために、構築工程の前（例えば詳細設計工程）でしょうか？
いやいや、詳細設計が決まってないと構築手順書作れないから、やっぱり構築工程でしょうか？
でもでも、基本的な構築自体は詳細設計に依存しないから、やっぱり詳細設計工程でしょうか？
手順書は、他にもいろんな手順書があります。
テスト手順書、システム操作手順書、オペレータ向け運用手順書、などなど。
何をどこの工程で、どこまで作るのか（あるいは作らないのか）、決めておくことが重要です。
そして、それを実施するのに最適な工程は、「要件定義」です！
1-7. 要件定義書に「設計」を書くべきか否か
繰り返しになりますが、要件定義はお客様要件を取りまとめる工程です。
そのため、要件定義書には、お客様要件を記載する必要があります。
逆に言うと、要件以外のこと（特に後続工程で実施するべき「設計」等）はできる限り記載しないほうが良いです。
同じ内容を異なる文書（要件定義書と基本設計書）に書いてしまうと、修正が発生した場合に手間がかかります（2つの文書を修正して整合性を担保する必要がある）。
設計に関する内容だったので基本設計書だけ修正したというケースの場合、要件定義書の修正は漏れる可能性があります。
こういった事態を避けるためにも、基本的には最適な文書のみに記載する必要があります。
それでは、そもそも要件と設計の違いは何でしょうか？
簡単な例を挙げます。
例えば、システムの利用時間を考えてみます。
お客様が「平日9-17時だけ使えればよい」とか「24時間365日使用したい」と言ったとします。
これは「要件」に該当します。
要件定義書には例えば「本システムは日本在住の職員が業務時間内に使用するため、平日9-17時に稼働しておく必要がある。」という風に書かれるでしょう。
さて、これに対して設計はどうなるのでしょうか？
平日9-17時に稼働するシステムなので、設計方法はいろいろありそうです。
例えば「サーバ2台構成とし、手前にロードバランサーを配置して負荷分散する。」という設計もありますし、「ホットスタンバイ構成とする。」という設計もあるでしょう。
ここまでをまとめると、次の通りです。
要件定義：本システムは日本在住の社員が業務時間内に使用するため、平日9-17時に稼働しておく必要がある。
基本設計：（平日9-17時での稼働を確保するために）サーバ2台構成とし、手前にロードバランサーを配置して負荷分散する。
さてさて、ここまでで要件定義と基本設計（要件定義書と基本設計書に記載するもの）はざっくり理解できたかと思います。
そのうえで、またややこしいことを言います（SIerの仕事は、ややこしいことを分解して文書化することだと思ってください）。
もしお客様が要件定義段階で「うちにはロードバランサー無いから、ホットスタンバイがいいなぁ」と言ったとします（もちろん理由はきちんと確認しましょう。例えば「ロードバランサーを追加購入する予算が無い」とか「新しいものを入れると管理が増えるから嫌だ」とか、いろいろ理由があるはずです）。
この瞬間、要件定義と基本設計（要件定義書と基本設計書に記載する内容）が変わります。
具体的には、要件定義書に「（仮称）システム実装方式案」という項目が爆誕します！
どういうことかというと、要件の一部として、システム実装に関する要件が浮上します！
つまり、平日9-17時に稼働するシステムが（何らかの理由で）使えなくなった場合の切替に関する要件です。
（今回の例では）ロードバランサー案とホットスタンバイ案で、両者のメリットデメリットを比較し、お客様要件として「ホットスタンバイ」が要件であることを明記します。
（比較表には「コスト」という項目が必要で、それが今回の予算を踏まえると適切な選択肢ではない、という結論になります）
要件定義書には例えば「本システムは日本在住の社員が業務時間内に使用するため、平日9-17時に稼働しておく必要がある。システム実装方式案を検討した結果、今回はホットスタンバイ案でシステムを構築する。」という風に書かれるでしょう。
では、基本設計書にはどう書くのでしょう？
ここが、若干書き方が難しいところです。
「要件定義書のシステム実装方式案に基づき、システムを設計する。」という書き方が本来望ましいと思いますが、この書き方だと「どの方式なの？」となってしまいます。
どういうことかというと、実装方式を確認するため、いちいち要件定義書を見直す必要があります。
そのため、実際には「要件定義書のシステム実装方式案に基づき、ホットスタンバイでシステムを設計する。」と書くことになるでしょう。
ここまでをまとめると、次の通りです。
要件定義：本システムは日本在住の社員が業務時間内に使用するため、平日9-17時に稼働しておく必要がある。システム実装方式案を考慮し、今回はホットスタンバイ案でシステムを構築する。
基本設計：（要件定義書のシステム実装方式案に基づき）ホットスタンバイでシステムを設計する。
このように、要件定義の進め方次第で、要件定義に記載する内容が変わってきます。
今回のケースでは「うちにはロードバランサー無いから、ホットスタンバイがいいなぁ」という一言がきっかけでした。
では、なぜこのようなことが発生するのでしょうか？
それは、お客様の予算や、契約の結び方に理由があります。
ウォーターフォールモデルは基本的に各工程毎に進めるため、あるべき論でいえば各工程毎に契約すべきです。
要件定義を契約して、要件定義書を完成させる。
次に基本設計を提案して、契約して、基本設計書を完成させる。
その次に詳細設計を提案して、契約して、詳細設計書（パラメータシート）を完成させる。
そのまた次に、という流れです。
しかし、お客様の予算の関係もあり、要件定義の契約前に、基本設計の概算を求められるケースがあります。
また、基本設計から結合テストまでをまとめて契約するケース等もあります。
このような場合、要件定義段階で、ある程度後続（基本設計など）の話をしておく必要があります。
（「え？きいてないよ？」というのを防ぐためです）
つまり、本来の要件定義では「本システムは日本在住の職員が業務時間内に使用するため、平日9-17時に稼働しておく必要がある。」だけでよいところを、後続工程を踏まえると「ちなみにどういう実装（設計）になりそう？その場合、いくらかかりそう？」という会話が要件定義工程で発生するのです。
実装方式（設計）によっては、追加でサーバ購入が必要になったり、既存のロードバランサーだけでは足りないから増設が必要になったりします。
基本設計が終わった段階で判明することではありますが、その時点では遅いというケースがあるのです。
そのため、要件定義書には設計（実装）に関することが含まれてしまうことがあります。
しかし、それはあくまでお客様要件であり、システム設計ではない点に注意してください。
ただし書き方を間違えると「なんで要件定義書に設計が含まれているの？」と質問されたりします。
特に要件定義工程と基本設計工程でお客様の参加者が異なる場合です。
（「議事録読んでよ」と言いたいところですが、丁寧に説明するのもSIerの仕事です。こういう工数をきちんを積んでおけるようになると、上級SEの仲間入りです）
1-8. 要件定義書に「経緯」「検討結果」を書くべきか否か
ここまでいろいろ述べたように、要件定義書には書くべきことがいっぱいあります。
そのため、できるだけ簡素にまとめたいと思うかもしれません。
（後で読み返すことを考えても、短くて簡単な方が読みやすく理解しやすいですし）
しかし、ただ単に「要件」だけを書いても、「どうしてそうなったのか」を書いておかないと、必ず後悔します。
そのため、その要件に至った「経緯」や、その要件にたどりついた「検討結果」は必ず書いてください。
これには理由があります。
まず最初に、どうしてその要件で合意したかがわかりやすくなります。
要件定義書は、後続の基本設計でも利用します。
その際、要件定義に参加していなかったメンバーも、要件定義書を確認します。
要件定義書に「経緯」や「検討結果」を記載しておけば、説明が楽になりますし、余計な手戻りを防ぐことができます。
他にも、後続の設計がやりやすくなります。
お客様がやりたいこと（要件）の「経緯」や「検討結果」がきちんと書かれていれば、
それを満たす設計を検討しやすくなります。
複数の選択肢（設計パターン）がある場合、検討結果を踏まえて最適な設計を選ぶことができます。
要件定義フェーズは限られた時間の中で進めることが多いため、
「経緯」や「検討結果」は議事録で済ませてしまうこともあるかと思いますが、
要件定義書は後から読み返すことがある文書、と考えると、できる限り要件定義書に記載しておくことをお勧めします。
だって、あとから全部の議事録読み返すの、結構大変でしょ？
（今だったら、生成AIに全部突っ込んで調べさせれば、少しは楽できるかもしれませんが…）
2. まとめ
要件定義のポイント＆注意点は、まとめると次の通りです。
- 「業務要件定義」なのか「システム要件定義」なのか、確認しよう
- 「システム要件定義」が「特定のシステムを念頭に置いているかどうか」、確認しよう
- 「機能要件」で定義すべき内容・範囲を、決めましょう
- 「非機能要件」で定義すべき内容・範囲を、決めましょう
- 「機能要件」「非機能要件」以外で定義すべき内容・範囲を、決めましょう
- 後続のどの工程で、何をどこまでするかを、決めましょう
- 「設計」内容をどこまで記載するか、相談しよう
- 「背景」「検討結果」をどこまで記載するか、相談しよう
3. おわりに
要件定義は様々な観点で進める必要があります。
そのため、新人や若手にはなかなか荷が重く、逆に古参のシステムエンジニアには恰好の腕の見せ所です。
単に技術に詳しいだけでなく、
お客様の要望の表や裏に潜むあれやこれやを引き出し、会話し、文書としてまとめる能力が必要となります。
要件定義で手を抜くと、後続工程で炎上＆デスマーチ確定です。
要件定義で手を抜かなくても、抜け漏れ（検討忘れ）があると、やっぱりデスマーチです。
時間とお金がひっ迫する状況で、どうやって予定通りに要件定義をFIXするか、
システムエンジニアの皆さんの力量が試されています。
このように要件定義は非常に難しく、それゆえに楽しい作業の一つです。
若手のシステムエンジニアは、焦らず、まず技術を身につけましょう。
製品パラメータをいじくり倒し、特定サービスやパッケージを知り尽くし、その圧倒的ノウハウを持って、要件定義に挑みましょう！
なお、私自身は「若いうちは一つの製品を極めるべき」派の人間です。
自分がそうやって若手時代を過ごしてきたため、その育成方針を支持しています（生存者バイアスともいう）。
※対抗馬は「若いうちはいろいろやるべき」派
要件定義を極めれば、生成AIにも代替されないあなただけのスキルが手に入るはず！
（幸運を祈ります）
96.連載のリンク先
SIの基礎：ウォーターフォールモデルの各工程をざっくり理解し、良いシステムを作るための知識を身に着けよう！その1 全体概要編
https://qiita.com/peridotan/items/3d1921e36219129a4b16
97.参考文献
98.更新履歴
- 2026.07.01 初版