当サイトの記事は編集部がIPAなど公的機関の公開資料と読者の声を調べて独自に執筆しています。
資格の勉強や現場の会話で「要件定義プロセス」という言葉が出てきて、システム要件定義と何が違うのか迷っていませんか。
結論から言うと、要件定義プロセスは「利用者側が何を実現したいのか」を決めて合意する工程です。
この記事では、開発工程の並びの中での位置と、前後の工程から何を受け取り何を渡すのかを、表と図で確かめていきます。
要件定義プロセスとは？わかりやすく言うと「何を作るか決める工程」
要件定義プロセスは、業務をどう変えたいかを利用者側の言葉で固め、関係者で合意する工程です。どう作るかを決めるのは、その次の工程の役目です。
要件定義プロセスとは、システムの利用者や発注側の「こうしたい」を集めて、実現する内容として決める工程のことです。
ここで決めるのは、主に業務要件です。誰が、いつ、何を、どの基準で行うのかという、業務のあり方ですね。
『でも、画面や機能も要件定義で決めるのでは？』と思った方もいるはずです。
実は、日本で広く使われるIPAの「共通フレーム2013」では、利用者側の要件を決める工程と、開発側の技術要件に落とす工程を分けて考えます。
この記事では、前者を「要件定義プロセス」、後者を「システム要件定義」「ソフトウェア要件定義」と呼び分けて説明していきます。
| 呼び方 | 決める人の中心 | 決める内容の例 |
|---|---|---|
| 要件定義プロセス | 利用者・発注側 | 業務の流れ、業務のルール、達成したい目標 |
| システム要件定義 | 開発側（発注側と合意） | システムが持つ機能、性能、外部とのつながり |
| ソフトウェア要件定義 | 開発側 | ソフトウェア単位で実現する機能や条件 |
要件定義の全体像から知りたい方は、要件定義とは？意味をわかりやすく解説も合わせて読んでみてください。
共通フレーム2013とは何か
共通フレーム2013は、ソフトウェアのライフサイクルで使う用語と作業の区切りをそろえるための枠組みです。
発注側と開発側で「要件定義」の意味がずれないよう、共通の物差しとして使われています。
この版では企画プロセスと要件定義プロセスが強化され、国際規格ISO/IEC/IEEE 29148（要求工学）の考え方も取り入れられました。
システムライフサイクルの中で、要件定義プロセスはどこにある？
システムライフサイクルの要件定義は、企画のすぐ後、設計の前に置かれます。上流の中でも「業務の言葉」と「システムの言葉」をつなぐ位置にあります。
システムライフサイクルとは、システムを企画してから、作って、使って、役目を終えるまでの一連の流れのことです。
共通フレーム2013の工程を並べると、おおよそ次の順番になります。
- 企画プロセス
- 要件定義プロセス
- システム要件定義
- システム方式設計
- ソフトウェア要件定義
- ソフトウェア方式設計とソフトウェア詳細設計
- 実装とテスト、結合とテスト
- 導入
- 運用・保守
つまり、システム開発のプロセスにはシステム要件定義もソフトウェア要件定義も含まれます。
「要件定義」と名の付く工程が3つもあるので、混乱しやすいんですよね。
ただ、上から順に「業務の要件」「システムの要件」「ソフトウェアの要件」と、話が細かくなっていくと考えると覚えやすくなります。
運用や廃棄まで考えておくのがポイント
共通フレーム2013では、要件定義の段階で機能だけでなく、運用や廃棄に関する要件も考えることが大事とされています。
例えば、こんな場面を想像してみてください。
「月末の締め処理は誰が動かしますか？」「古いデータは何年残しますか？」という質問に、要件定義の時点で答えを持っているかどうかです。
ここが空白のまま進むと、運用が始まってから決め直すことになります。
企画プロセスと要件定義プロセスは何が違う？
- なぜシステム化するのかを決める
- 経営や事業の目標とつなげる
- 予算や大まかな範囲の枠を決める
- 何を実現するのかを具体的に決める
- 業務の流れとルールを固める
- 関係者の合意を取って文書に残す
企画プロセスと要件定義プロセスは、続けて行われるので境目があいまいになりがちです。
結論から言うと、企画プロセスは「なぜ・どこまで」を決め、要件定義プロセスは「何を」を決める工程です。
『システムに必要な要件を集めるのは、企画のほうでは？』と迷う方も多いはずです。
企画でも要望は集めますが、それは方向と枠を決めるための材料です。要件として細かく決めて合意するのは、要件定義プロセスの役目になります。
例えば、社内の勤怠管理システムを入れ替える場合で比べてみましょう。
| 観点 | 企画プロセスで決めること（例） | 要件定義プロセスで決めること（例） |
|---|---|---|
| 目的 | 残業の申請と承認の手間を減らしたい | 申請から承認までの業務の流れを決める |
| 範囲 | 本社と支店の全社員を対象にする | 雇用形態ごとの申請ルールの違いを決める |
| 予算と時期 | 来期中の入れ替えを目指す | 締め日や給与計算への受け渡しの日程を決める |
| 判断の場 | 経営層が承認する | 利用部門と情報システム部門が合意する |
会話にすると、こんな違いです。
「残業申請をシステムにしたいですね」と経営側が言うのが企画の段階です。
「承認者が不在の時は、誰が代わりに承認しますか？」と利用部門に聞くのが要件定義の段階ですね。
要件定義プロセスとシステム要件定義・ソフトウェア要件定義の違い
要件定義プロセスは業務の言葉、システム要件定義はシステムの言葉、ソフトウェア要件定義はソフトウェアの言葉で書きます。同じ要望が、工程を進むごとに具体的な形へ変わっていきます。
ここは試験の勉強でもつまずきやすいところです。
同じ要望が、工程ごとにどう言い換えられていくのかを見ると、違いがすっと入ってきます。
| 工程 | 書き方の例（残業申請の場合） |
|---|---|
| 要件定義プロセス | 残業は前日までに申請し、課長が当日中に承認する |
| システム要件定義 | 申請画面と承認画面を用意し、承認待ちを承認者に知らせる |
| ソフトウェア要件定義 | 申請データの登録、承認状態の更新、通知の送信を行う |
システム要件定義では、利用部門の要件を受けて、システムが持つべき機能や性能を決めます。
ソフトウェア開発のプロセスを要件定義から細かく見ると、その次にシステム方式設計があり、さらにソフトウェア要件定義へと続きます。
ソフトウェア要件定義は、システムを構成するソフトウェアの単位で、実現する機能や条件を決める工程です。
会社や現場によっては、これらをまとめて「要件定義」と呼ぶこともあります。会議で言葉がずれていると感じたら、「業務の話ですか、システムの話ですか」と一言確かめてみてください。
入口と出口で見る要件定義プロセス：何を受け取り、何を渡すか
要件定義プロセスを理解する近道は、「前の工程から何を受け取り、次の工程へ何を渡すか」を押さえることです。入口と出口が分かれば、やるべき作業の中身も見えてきます。
工程の説明は、作業の一覧だけ読んでもピンと来にくいですよね。
そこでこの記事では、要件定義プロセスを「入口」と「出口」で見ていきます。
| 区分 | 主なもの | ひとこと |
|---|---|---|
| 入口（受け取る） | システム化の目的と背景 | なぜやるのかの出発点 |
| 入口（受け取る） | 対象範囲と予算・時期の枠 | 決めてよい範囲の上限 |
| 入口（受け取る） | 現状の課題と関係部署の要望 | 要件のもとになる材料 |
| 出口（渡す） | 業務要件（業務フロー・業務一覧） | 業務をどう変えるか |
| 出口（渡す） | 機能要件と非機能要件のたたき台 | システムに求めること |
| 出口（渡す） | 未決事項・課題一覧と合意の記録 | 次で決めることの引き継ぎ |
出口のうち、非機能要件はつい後回しにされがちです。
IPAの「非機能要求グレード」は、発注側と開発側の合意を助ける道具です。大項目は、可用性、性能・拡張性、運用・保守性、移行性、セキュリティ、システム環境・エコロジーの6つです。
各項目のレベルを0〜5の段階で選ぶ形なので、「速いほうがいい」のようなあいまいな言い方を減らせます。
入口が足りない時はどうする？
現場では、企画から十分な材料を受け取れないまま要件定義が始まることもあります。
『目的があいまいなまま、とりあえず要望を聞いてと言われた…』という状況ですね。
そんな時は、要件定義の最初の打ち合わせで、入口の3つを確かめ直すところから始めてみてください。
「今回のシステム化で、いちばん減らしたい手間は何ですか？」「対象外にしてよい部署や業務はありますか？」と聞くだけでも、決める範囲がぐっと絞れます！
出口でそろっているか確かめるチェック
- システム化の目的が一文で言える状態にする
- 業務フローが今と目指す姿の両方で書けているか確かめる
- 機能要件と非機能要件の抜けを関係者と見直す
- 決まっていないことを課題一覧に残す
- 誰が何に合意したかを議事録で残す
『全部そろうまで次に進めないの？』と不安になる方もいますよね。
ただ、未決事項があること自体は珍しくありません。大事なのは、決まっていないことが見える形で引き継がれていることです。
このあと工程がどう続いていくかは、要件定義から運用までの流れで詳しく見られます。
要件定義ガイド
まずは型をそろえよう｜要件定義書のテンプレートと記入例
章立て・各章に書くこと・1行の記入例をひとつの表にまとめました。白紙から書き始める前に、型を手元に置いておきましょう。
無料要件定義書のテンプレートを見る当サイトの記事ページに移動します。
よくある相談に答えます
ここでは、要件定義プロセスについて寄せられがちな相談を、要点だけまとめて答えます。
要件定義プロセスとシステム要件定義の違いが分からない
資格の勉強中に、この2つの違いで手が止まったという相談は多いです。
答えは、決める内容の「言葉」が違う、という点で覚えるのがおすすめです。
要件定義プロセスは業務の言葉で、システム要件定義はシステムの言葉で書きます。前の章の残業申請の例のように、同じ要望を2通りに書き分けてみると、すっきり区別がつきます！
要件を集めるのは企画プロセスではないの？
企画でも関係者の要望は聞きますが、目的は方向と範囲を決めることです。
要件として細かく固めて合意するのは要件定義プロセスなので、「企画は枠決め、要件定義は中身決め」と覚えておくと迷いません。
確認し忘れた要件があって、設計をやり直すことが多い
要件定義から設計に進んでから、肝心な要件の確認漏れに気づくという悩みもよく聞きます。
この場合は、出口のチェックを習慣にするのが効きます。
画面や機能の話ばかりで、例外の処理や運用のルールを聞かないまま設計に進んでしまう。承認者の不在時、データの訂正、締め後の修正など「いつもと違う時」の扱いを、要件定義の段階で一度聞いておきましょう。
システム開発の要件定義全体の考え方は、システム開発における要件定義とはで解説しています。進め方の手順を知りたい方は要件定義の進め方・手順も役に立つはずです。
よくある質問
要件定義プロセスとは、ひとことで言うと何ですか？
利用者側が業務で何を実現したいのかを決めて、関係者で合意する工程です。どう作るかではなく、何を実現するかを決めます。
企画プロセスと要件定義プロセスは同じ人が担当しますか？
会社や契約の形によって変わります。企画は経営層や事業部門が中心になり、要件定義は利用部門と情報システム部門、開発側が一緒に進めることが多いです。
共通フレーム2013の工程どおりに進める必要はありますか？
共通フレーム2013は用語と作業の区切りをそろえる物差しなので、そのままの順番で進めることが求められているわけではありません。自社の進め方と照らし合わせ、抜けている作業がないかを確かめる使い方がおすすめです。
要件定義プロセスで非機能要件まで決めますか？
たたき台までは考えておくのがおすすめです。IPAの非機能要求グレードの6つの大項目を使うと、発注側と開発側で話がかみ合いやすくなります。
要件定義プロセスをわかりやすく覚えるコツはありますか？
「業務の言葉で、何を実現するかを決めて合意する工程」と一文で覚えるのがおすすめです。そのうえで、前後の企画プロセスとシステム要件定義との違いを、身近な業務の例で書き分けてみると定着します。
まとめ
- 要件定義プロセスは、利用者側が何を実現したいのかを決めて合意する工程
- 共通フレーム2013では企画プロセスの次、システム要件定義の前に置かれる
- 企画は「なぜ・どこまで」、要件定義は「何を」を決める
- 業務の言葉からシステムの言葉、ソフトウェアの言葉へと具体的になっていく
- 入口で受け取るものと出口で渡すものを押さえると、作業の中身が見えてくる
コメント