当サイトの記事は編集部がIPAなど公的機関の公開資料と読者の声を調べて独自に執筆しています。
システム開発の要件定義を任されたものの、何をどこまで決めればいいのか、ぼんやりしている方も多いはずです。
結論から言うと、要件定義はシステム開発の最初に「何を作るか」を発注側と開発側で決めて合意する工程です。
この記事を読むと、要件定義で決めることと、その内容が後の工程でどう使われるのかがつかめます。
システム開発における要件定義とは？最初に「何を作るか」を決める工程
要件定義とは、システム開発で実現することを決めて、関係者で合意する工程です。ここで決めたことが、設計からテスト、運用まですべての工程の土台になります。
要件定義とは、システム開発で利用者の要望を聞き取り、システムで実現する内容として決める工程のことです。
英語では Requirements Definition と言います。要件定義（RD：Requirements Definition）と略して呼ぶ現場もあります。
よく似た言葉に「要求」があります。違いを表で見てみましょう。
| 言葉 | 意味 | 例（社内の経費精算の場合） |
|---|---|---|
| 要求 | 利用者や発注者の「こうしたい・こうなってほしい」 | 精算の手間を減らしたい、紙をなくしたい |
| 要件 | 予算・期間・技術を踏まえて、システムで実現すると合意したこと | 領収書の画像を添付して申請し、上長が画面で承認する |
要求はたくさん出てきます。その中から、予算や期間の中で実現できるものを選び、言葉にして合意するのが要件定義なんです。
開発の要件定義には誰が関わる？
要件定義は、発注側だけでも開発側だけでも進められません。
それぞれの立場が持っている情報が違うからです。
| 立場 | 主な役割 |
|---|---|
| 利用部門（業務部門） | 今の業務と困りごと、目指す姿を伝える |
| 情報システム部門・社内SE | 社内の他のシステムとの関係や運用の事情を伝える |
| 開発側のSE・PM | 要望を要件の形に言い換え、実現できるかを判断する |
IPAが2019年に公開した「ユーザのための要件定義ガイド 第2版」も、業務に責任を持つユーザが主体的に要件定義に関わることの大切さを伝えています。
意味の詳しい解説は、要件定義とは？意味をわかりやすく解説にまとめています。
要件定義はシステム開発のどのタイミングで行う？
要件定義は、企画の後、設計の前に行います。ウォーターフォールなら要件を確定させてから設計へ進み、アジャイルなら短い期間ごとに要件を見直しながら進めます。
『そもそも、いつ要件定義をするの？』という疑問もありますよね。
一般的なシステム開発の流れは、次のように進みます。
- 企画：なぜシステム化するのか、範囲と予算の枠を決める
- 要件定義：何を実現するのかを決めて合意する
- 基本設計：画面や帳票など、利用者から見える部分をどう作るか決める
- 詳細設計：プログラムの中身をどう作るか決める
- 開発とテスト：作って、小さい単位から順に確かめる
- 受入テストと導入：発注側が要件どおりかを確かめて使い始める
- 運用・保守：使いながら直したり改善したりする
工程を上から順に進め、前の工程の成果物を確定させてから次へ進む進め方をウォーターフォールと呼びます。
ウォーターフォールでの要件定義の進め方は、ウォーターフォール開発の要件定義で詳しく解説しています。
要件定義の期間の中では何をする？
要件定義の工程そのものも、いくつかの作業に分かれます。
まず今の業務と課題を聞き取り、次に目指す業務の姿を描きます。そのうえで、システムで実現することを決めて、要件定義書にまとめて合意を取ります。
| 作業 | 主にやること | 残すもの |
|---|---|---|
| 現状の把握 | 今の業務の流れと困りごとを聞く | 現状の業務フロー、課題の一覧 |
| 目指す姿を描く | 業務をどう変えるかを決める | 目指す業務フロー、業務一覧 |
| システムの要件を決める | 機能と品質の条件を決める | 機能一覧、非機能要件の一覧 |
| 合意を取る | 関係者で読み合わせて承認する | 要件定義書、議事録 |
「どの作業にどれくらいかかるか」は、関わる部署の数や今のシステムがあるかどうかで大きく変わります。
アジャイルでは、短い期間で作って確かめるを繰り返します。要件はプロダクトバックログやユーザーストーリーとして持ち、期間ごとに優先順位を見直すのが一般的です。
システム開発の要件定義で決めること
要件定義で決めるのは、業務要件・機能要件・非機能要件の3つが中心です。システムの入れ替えなら移行要件、使い始めた後のための運用・保守要件も加えます。
要件定義で決める内容は、会社や案件で呼び方が少しずつ違います。
ただ、中身としてはおおよそ次の5つに収まります。
| 種類 | 何を決めるか | 決める内容の例 |
|---|---|---|
| 業務要件 | 業務をどう変えるか | 誰が、いつ、何を、どの基準で行うか |
| 機能要件 | システムが何をするか | 画面、帳票、データ、処理、外部とのつながり |
| 非機能要件 | どのくらいの品質で動くか | 性能、可用性、セキュリティ、運用 |
| 移行要件 | 旧システムからどう移るか | 移すデータ、変換のルール、切り替え日 |
| 運用・保守要件 | 使い始めた後どう回すか | 問い合わせの窓口、障害時の連絡、保守の範囲 |
非機能要件は、利用者からは見えにくいので後回しにされがちです。
IPAの「非機能要求グレード」は、可用性、性能・拡張性、運用・保守性、移行性、セキュリティ、システム環境・エコロジーの6つの大項目で整えられています。各項目のレベルを0〜5の段階で選べるので、合意を取る時の助けになります。
伝わる要件と伝わらない要件の書き方
要件は、読んだ人によって受け取り方が変わらないように書くのがコツです。
『「使いやすい画面」って書いたら、だめなの？』と思った方もいますよね。
「使いやすい」は人によって基準が違うので、テストで確かめられません。次のように言い換えてみてください。
| 伝わりにくい書き方 | 伝わる書き方（例） |
|---|---|
| 使いやすい申請画面にする | 申請に必要な項目を1画面で入力できる |
| 承認を早くする | 承認待ちになったら承認者に通知する |
| データはしっかり残す | 申請データは決めた保存期間のあいだ検索できる |
- 例外の時の業務の流れを決める（承認者の不在、差し戻しなど）
- 画面ごとに誰が使うのかを決める
- データをどれくらいの期間残すのかを決める
- 止まった時にどこまで待てるのかを決める
- 決まっていないことを課題一覧に残す
要件定義で決めたことは、開発のどこで使われる？
要件定義の中身は、作って終わりの書類ではありません。設計の材料になり、テストの合格基準になり、運用のルールにもなります。
要件定義の大切さは、よく「後工程に影響するから」と説明されます。
でも、具体的にどこでどう使われるのかまで見ると、手を抜けない理由がはっきりします。
例として、社内の経費精算システムを入れ替える場合で追ってみます。
| 工程 | 要件定義のどの内容を使うか | 使われ方の例 |
|---|---|---|
| 基本設計 | 機能要件（画面・帳票） | 申請画面と承認画面の項目や並びを決める |
| 詳細設計 | 業務要件のルール | 金額によって承認者が変わる処理を組み立てる |
| 結合・システムテスト | 機能要件と非機能要件 | 月末に申請が集中しても待ち時間が許容内か確かめる |
| 受入テスト | 業務要件 | 利用部門が実際の業務の流れで使えるか確かめる |
| 移行 | 移行要件 | 旧システムの未精算データを新システムへ移す |
| 運用・保守 | 運用・保守要件 | 問い合わせの窓口と障害時の連絡先を決めておく |
左側の上流工程と右側のテスト工程を対応させて考える見方を、V字モデルと呼びます。
要件定義の内容は、受入テストで発注側が確かめるものです。つまり、要件定義書の一文一文が、そのまま合格基準になるんです！
例えばこんな会話が、受入テストでよく起こります。
「承認の通知、メールでも来るものだと思っていました」「要件定義では画面上の通知だけになっています」
こうしたずれを防ぐには、要件を「検証できる書き方」にしておくことが大切です。国際規格のISO/IEC/IEEE 29148でも、良い要件の性質として、あいまいでないことや検証できることが挙げられています。
途中で要件が変わったらどうなる？
開発の途中で要件が変わることは、珍しくありません。
その時は、変わった要件がどの設計とどのテストにつながっているかを確かめます。工程ごとの使われ方が分かっていれば、影響の範囲をすぐに話し合えます。
要件定義から運用までの流れ全体は、要件定義から運用までの流れで詳しく見られます。工程の中での位置づけは要件定義プロセスとはも参考にしてみてください。
要件定義ガイド
まずは型をそろえよう｜要件定義書のテンプレートと記入例
章立て・各章に書くこと・1行の記入例をひとつの表にまとめました。白紙から書き始める前に、型を手元に置いておきましょう。
無料要件定義書のテンプレートを見る当サイトの記事ページに移動します。
よくある相談に答えます
システム開発の要件定義について、よく寄せられる相談を要点だけまとめて答えます。
中途半端にしか決めないなら、要件定義は必要ないのでは？
『どうせ途中で変わるなら、最初に決める意味ある？』という疑問ですね。
確かに、要件は開発中に変わることがあります。ただ、最初に決めていないと、何が変わったのかすら分からなくなってしまいます。
決めたことと決まっていないことを分けて残しておけば、変更があっても影響の範囲を話し合えます。
例えば、こんなやりとりができるようになります。
「承認の段階を一つ増やしたいです」「それなら承認画面と通知、受入テストの手順が変わります。どれを優先しますか？」
決めた土台があるからこそ、変更の相談が具体的になるんです！
見積もりの前と後、どのタイミングで要件定義をするの？
複数の開発会社から見積もりを取る場合、要件定義の前か後かで迷う方は多いです。
一般論として、要件定義だけを先に準委任契約で依頼し、設計以降を請負契約で分けて契約する例があります。
要件定義の作業量は、決める範囲や関わる部署の数がはっきりしないと読みにくいからです。
要件が固まる前の見積もりは幅が大きくなりやすいので、何が決まっている前提なのかを見積もりの内訳で確かめておきましょう。
画面の表示項目まで、要件定義で固めるべき？
ここは悩みどころです。
要件定義では、画面に必要な情報と、その画面を誰が何のために使うかまでを決めておくのがおすすめです。細かい並び順や見た目は、基本設計で詰めることが多いです。
例えば「申請画面には申請日、金額、用途、領収書の画像が要る」までは要件定義で決めます。どの順に並べるか、ボタンをどこに置くかは基本設計の話です。
「画面は設計で決めればいい」と、必要な項目まで後回しにしてしまう。業務で使う項目が抜けると、設計の段階で要件を決め直すことになります。
よくある質問
システム開発の要件定義とは、誰が行うものですか？
発注側の利用部門と情報システム部門、開発側のSEやPMが一緒に進めるのが一般的です。どの立場が中心になるかは、契約の形や会社によって変わります。
要件定義と基本設計の違いは何ですか？
要件定義は何を実現するかを決める工程で、基本設計はそれを利用者から見える画面や帳票としてどう作るかを決める工程です。
小さなシステム開発でも要件定義は必要ですか？
規模が小さくても、何を作るかを文書で合意しておくことは役に立ちます。項目を絞った簡単な要件定義書でも、後のずれを減らせます。
要件定義書は誰に向けて書くものですか？
発注側の利用部門と、設計や開発を担う開発側の両方が読む前提で書きます。業務の言葉で書きつつ、専門用語は用語集で説明しておくと読み違いが減ります。
要件定義で決めた内容は、後から変えられますか？
変えることはできますが、後の工程ほど影響が大きくなります。変更する時は、どの設計やテストに影響するかを確かめてから合意しましょう。
まとめ
- システム開発における要件定義とは、何を作るかを決めて合意する工程
- 企画の後、設計の前に行い、すべての工程の土台になる
- 業務要件・機能要件・非機能要件を中心に、移行や運用の要件も決める
- 決めたことは設計の材料、テストの合格基準、運用のルールとして使われる
- 要件は検証できる書き方にしておくと、受入テストでのずれを防げる
コメント