要件定義ガイド

当サイトの記事は編集部がIPAなど公的機関の公開資料と読者の声を調べて独自に執筆しています。

要件定義を任されたものの、何を決めて、何を書けば終わりなのかが見えずに困っていませんか。

結論から言うと、要件定義は「システムで何を実現するかを、発注側と開発側で合意して文書に残す工程」です。

要件定義ガイドは、要件定義を初めて担当するSE・PM・社内SE、そして発注側の業務部門の方に向けた実務ガイドです。

IPA（情報処理推進機構）が公開している資料など公的な情報をもとに、編集部が第三者の立場でまとめています。

このページでは、意味から進め方、要件定義書の中身、つまずきやすい違いまでを一気に見渡せます。

気になる節から読んで、詳しい記事へ進んでみてください。

要件定義とは？意味と全体像を早見表で

先に結論

要件定義は、利用者の「こうしたい」を、予算・期間・技術を踏まえて「システムで実現すること」に絞り込み、関係者で合意する工程です。

IT業界では、要件定義をRD（Requirements Definition）と略して呼ぶこともあります。

開発の一番最初の工程なので「上流工程」と呼ばれることも多いですよね。

『意味は何となく分かるけど、結局何を決めるの？』という方も多いはずです。

まずは、要件定義で押さえておきたいことを表で見てみましょう。

項目	中身	詳しい記事
意味	システムで実現することを決めて合意する工程	要件定義とは
目的	作る物の認識をそろえ、後からの手戻りを防ぐ	要件定義の目的
決めること	業務要件、機能要件、非機能要件、移行や運用の要件	業務要件定義・システム要件定義
主な成果物	要件定義書、業務フロー図、機能一覧など	要件定義の成果物一覧
関わる人	発注側の業務部門・情報システム部門、開発側のSE・PM	要件定義は誰がやる？
次の工程	基本設計（利用者から見える部分の設計）	要件定義と基本設計の違い

家づくりにたとえると、要件定義は「間取りと暮らし方を施主と工務店で決める打ち合わせ」に近いです。

図面を引く前に、家族の人数や生活の流れを話し合わないと、住みにくい家ができてしまいますよね。

意味をもっとかみくだいて知りたい方は、要件定義とは？意味をわかりやすく解説から読んでみてください。

なぜこの工程を省けないのかは、要件定義の目的で、省いた時に後工程で起きることと合わせて紹介しています。

業務要件とシステム要件は何が違う？

要件定義で決めることは、大きく「業務をどう変えるか」と「そのためにシステムが何を持つか」の2段に分かれます。

種類	決めること	書き方の例
業務要件	誰が・いつ・何を・どの基準で行うか	申請は担当者が当日中に入力し、上長が翌営業日までに承認する
機能要件	システムが何をするか（画面・帳票・データ・処理・外部連携）	申請画面から入力でき、承認待ちの一覧を上長が見られる
非機能要件	どのくらいの品質で動くか（性能・可用性・セキュリティ・運用など）	業務時間中に止まらず、権限のある人だけが見られる

業務要件から先に決めるのがコツです。

業務の姿が決まらないまま画面の話を始めると、「便利そうな機能」が積み上がるだけになりがちなんです。

業務要件の書き方は業務要件定義とは、システム側への落とし方はシステム要件定義とはで、記入例つきで紹介しています。

両者の対応をもう少し細かく見たい方は、業務要件とシステム要件の違いも役立ちます。

要件定義の進め方の流れ

ここが大事なところです

いきなり機能の一覧から作り始めないことです。目的と範囲を先に固め、今の業務と目指す業務を比べてから要件を決めると、話が戻りにくくなります。

『何から手をつければいいのか分からない』というのが、初めての方の一番の悩みですよね。

要件定義は、次の順番で進めると迷いにくくなります。

要件定義の進め方（例）

目的と対象範囲を確かめる（キックオフ）
今の業務と課題を聞き取る（As-Is）
目指す業務の姿を描く（To-Be）
業務要件・機能要件・非機能要件を決める
要件定義書にまとめる
レビューして関係者の合意を取る

要件定義の進め方を、目的の確認から関係者の合意までの6つの手順として順番に並べた図解

手順2と手順3で使うのが、今の業務（As-Is）と目指す業務（To-Be）を比べて差分を洗い出すやり方です。

具体的な書き方と記入表は、要件定義の業務分析（As-Is/To-Be）で紹介しています。

業務の流れは、部署ごとにレーンを分けた業務フロー図にすると、関係者の認識がそろいやすくなります。

図の描き方とチェックの観点は要件定義の業務フロー図の書き方をどうぞ。

例えば、社内の経費精算システムを入れ替える場合、聞き取りの場ではこんな会話になります。

「差し戻しになった申請は、今はどう扱っていますか？」

「紙で戻して、担当者が手で直しています。月末はそれが一番の負担なんです」

こうした例外の流れこそ、要件として拾っておきたいところです。

要件定義ガイド

まずは型をそろえよう｜要件定義書のテンプレートと記入例

章立て・各章に書くこと・1行の記入例をひとつの表にまとめました。白紙から書き始める前に、型を手元に置いておきましょう。

無料要件定義書のテンプレートを見る

当サイトの記事ページに移動します。

週ごとのスケジュール例や、会議ごとに決めることは要件定義の進め方・手順で詳しく紹介しています。

開発工程全体の中で要件定義がどこにあり、何を受け取って何を渡すのかは、要件定義プロセスとはが参考になります。

要件定義の後、設計・開発・テスト・移行がどう続くかは要件定義から運用までの流れで一通り追えます。

要件定義書の書き方と成果物

要件定義書でよく使われる章立て（例）

背景・目的、現状の課題（As-Is）、目指す姿（To-Be）
対象範囲（スコープ）
業務要件（業務フロー・業務一覧）
機能要件（機能一覧・画面・帳票・データ・外部インターフェース）
非機能要件、移行要件、運用・保守要件
制約条件・前提、用語集、未決事項・課題一覧、承認欄

要件定義書は、決まったことを関係者が同じ意味で読めるように残す文書です。

様式は会社ごとに違うので、上の章立てはあくまで一例として見てみてください。

『白紙から書くのはさすがに無理…』と感じますよね。

実は、章立てを先に決めて、聞き取りで分かったことから埋めていくほうが早く進みます。

要件定義でできあがる成果物は、要件定義書だけではありません。

成果物	何のために作るか	主に読む人
要件定義書	決まったことをまとめ、承認を取る	発注側の責任者、開発側の全員
業務フロー図（As-Is/To-Be）	業務の流れと変わる部分を共有する	業務部門、SE
機能一覧	システムが持つ機能の抜け漏れを防ぐ	SE、PM
画面一覧・帳票一覧	利用者が触れる部分の範囲を決める	業務部門、設計担当
データ項目一覧	扱うデータとその意味をそろえる	SE、設計担当
外部インターフェース一覧	他のシステムとの受け渡しを決める	SE、相手システムの担当
非機能要件一覧	性能や可用性などの品質の水準を合意する	発注側の情報システム部門、インフラ担当
課題管理表・議事録	未決事項と決定の経緯を残す	関係者全員

非機能要件は、発注側と開発側で言葉がずれやすいところです。

IPAの「非機能要求グレード」では、可用性、性能・拡張性、運用・保守性、移行性、セキュリティ、システム環境・エコロジーの6つの大項目について、レベルを0〜5の段階で選ぶ形で合意を取りやすくしています。

要件定義書の中身と読み手ごとの見方は要件定義書とは、章ごとの書き方とNG文の直し方は要件定義書の書き方で紹介しています。

そのまま使える記入例がほしい方は要件定義書の例・テンプレート、成果物をまとめて確かめたい方は要件定義の成果物一覧をどうぞ。

業務部門向けの文書にしたい時は、業務要件定義書の書き方が近い内容です。

架空の題材で業務要件から非機能要件までを通して見たい方は、要件定義の具体例がイメージをつかみやすいです。

要求定義・基本設計との違い

言葉の揺れについて

「要求定義」「要件定義」「要求仕様書」「基本設計」などの呼び方は、会社やプロジェクトによって揺れがあります。ここでは一般的な使い分けで紹介します。

似た言葉が多くて、どれが何なのか混乱しますよね。

ここでは、要件定義の前後にある言葉を1つの表で並べてみます。

言葉	一言でいうと	主に書く人・決める人
要求定義	利用者・発注者の「こうしたい」を集めて並べる	発注側（業務部門）
要件定義	要求のうち、システムで実現すると合意したことを決める	発注側と開発側の両方
要求仕様書	発注側の要求を文書にまとめたもの	発注側
RFP（提案依頼書）	ベンダーに提案を依頼するための文書	発注側
基本設計（外部設計）	画面・帳票・操作・外部連携など、見える部分をどう作るか	開発側
詳細設計（内部設計）	プログラムの内部構造をどう作るか	開発側

要求と要件の違いは、「希望」と「約束」の違いと考えると分かりやすいです。

例えば「全部の画面をスマホでも見たい」は要求で、「申請と承認の画面だけはスマホで操作できる」が絞り込んだ後の要件、というイメージです。

会話例で要望が要件になるまでを追いたい方は、要求定義と要件定義の違いを読んでみてください。

文書の違いで迷っている方は、要求仕様書と要件定義書の違いで「誰が書いて誰に渡すか」の違いを紹介しています。

要件定義と設計の境目は、現場でも一番もめやすいところなんです。

要件定義は「何を実現するか」、基本設計は「それをどう見せるか」を決める、と覚えておきましょう。

1つの機能で書き方の違いを並べた要件定義と基本設計の違いと、1つの画面で3工程を比べた要件定義・基本設計・詳細設計の違いもあわせてどうぞ。

ちなみに、テスト工程と上流工程を対応させて見るV字モデルでは、要件定義の内容は受入テスト（発注側の確認）で確かめるとされます。

「受入テストでどう確かめるか」まで考えて要件を書くと、あいまいな表現が減りますよ。

開発手法・システム別の要件定義

メリット

デメリット

要件定義のやり方は、開発の進め方によって変わります。

『アジャイルなら要件定義はいらないのでは？』と聞かれることもありますよね。

実はそうではなく、決めるタイミングと残し方が違うだけなんです。

アジャイルソフトウェア開発宣言（2001年）にある「包括的なドキュメントよりも動くソフトウェアを」も、文書に価値がないという意味ではありません。

ウォーターフォールでの固め方と変更の扱い方はウォーターフォール開発の要件定義、アジャイルで最初に決めることと後で決めることはアジャイル開発の要件定義で紹介しています。

作る物の種類によっても、要件定義で気をつけるところが違います。

場面	特に気をつけたいところ	詳しい記事
業務システム・アプリの導入	業務の流れと既存の仕組みとのつなぎ方	システム導入・構築の要件定義
インフラ・基盤	性能・可用性・運用などの非機能要件	インフラ・基盤の要件定義
システム移行・リプレース	「現行と同じ」で済ませず、今の機能を棚卸しする	システム移行・リプレースの要件定義
RPA・DX・PoC	小さく試す範囲と、何を確かめたら次に進むか	RPA・DX・PoCの要件定義

リプレースでよくあるのが「今と同じでいいです」という一言です。

ただ、今の機能には使われていないものや、誰も理由を知らない処理が混ざっていることも。

現行の機能を一つずつ見て、要るか要らないかを決めておきましょう。

業務システムやアプリの導入ならシステム導入・構築の要件定義、基盤まわりはインフラ・基盤の要件定義が近い内容です。

移行が絡む案件はシステム移行・リプレースの要件定義、小さく試す取り組みはRPA・DX・PoCの要件定義を読んでみてください。

開発全体の中で要件定義が何に使われるかは、システム開発における要件定義とはで、工程ごとに紹介しています。

要件定義の役割と身につけたいスキル

先に結論

要件定義は、開発側だけ、発注側だけでは進みません。業務を知っている人と、システムに落とせる人が一緒に決める工程です。

『要件定義って、結局は誰の仕事なの？』という疑問はよく聞きます。

どの立場が中心になるかは、契約の形や会社の体制によって変わります。

立場	主な役割
発注側の業務部門（ユーザー部門）	業務の困りごとと目指す姿を伝え、決めたことに責任を持つ
発注側の情報システム部門・社内SE	業務部門とベンダーの間に立ち、全体をまとめる
開発側のPM・PL	進め方と範囲、スケジュールを管理し、合意を取る
開発側のSE	聞き取った内容を要件に落とし、要件定義書を書く
インフラエンジニアなど	非機能要件や基盤の条件を具体化する

IPAの「ユーザのための要件定義ガイド第2版」は、発注側の業務部門に向けて、要件定義でつまずきやすい問題と解決の勘どころを128項目にまとめた資料です。

業務部門が主体的に関わることが、それだけ大事だということですね。

役割の分け方は要件定義は誰がやる？SE・エンジニアの役割で、立場ごとに紹介しています。

要件定義に役立つ力

相手の話を最後まで聞いて、例外まで聞き出す力
業務の流れを理解する力
誤解のない文章で書く力
図にして見せる力
立場の違う人の合意を取る調整力
ITの基礎知識

初めから全部そろっている人はいません。

議事録を書く、要件の一覧を作る、業務フローを描く、と小さなところから慣れていけば大丈夫です。

未経験からの身につけ方は要件定義のスキルを未経験から身につける方法で紹介しています。

うまく進まない時の原因を先に知っておきたい方は、要件定義が難しい理由とつまずきポイントも読んでおくと安心です。

外部に頼む時の費用の考え方は、要件定義の費用相場で見積もりの比べ方と合わせて紹介しています。

目的別に記事を探す

知りたいことに合わせて、カテゴリごとに記事を選んでみてください。

要件定義の基本（10本）

開発手法・システム別の要件定義（6本）

進め方・プロセス（5本）

要件定義書・成果物（5本）

要求定義・設計との違い（4本）

役割・スキル（2本）

公式・公的な情報

要件定義について公的な資料で確かめたい時は、IPAの公開資料が参考になります。

IPA（情報処理推進機構）の資料

「ユーザのための要件定義ガイド第2版」は2019年に公開された資料で、要件定義の全体像、ビジネス要求定義、システム化要求定義、要件定義マネジメント、主要ドキュメントの作成といった章で構成されています。

工程の区切りや用語をそろえたい時は、IPAの「共通フレーム2013」という枠組みもよく使われます。

よくある質問

要件定義とは、わかりやすく言うと何ですか？

システムで何を実現するかを、発注側と開発側で話し合って決め、文書にして合意する工程です。家づくりでいえば、図面の前に間取りと暮らし方を決める打ち合わせにあたります。

要件定義と基本設計の違いは何ですか？

要件定義は「何を実現するか」を決める工程で、基本設計は画面や帳票など利用者から見える部分を「どう作るか」を決める工程です。境目は会社によって揺れるので、プロジェクトの最初にそろえておきましょう。

要件定義書には何を書けばいいですか？

背景・目的、対象範囲、業務要件、機能要件、非機能要件、移行や運用の要件、未決事項などがよく使われる章立てです。様式は会社ごとに違うので、テンプレートを土台に自社に合わせて調整してみてください。

要件定義は誰がやるものですか？

発注側の業務部門と、開発側のSEやPMが一緒に進めるのが一般的です。どちらが中心になるかは契約の形や会社の体制によって変わります。

アジャイル開発でも要件定義は必要ですか？

必要です。最初に目的と大枠を決め、細かい要件はプロダクトバックログやユーザーストーリーで少しずつ決めていく、というように決めるタイミングと残し方が変わります。

まとめ

このページの要点

要件定義は、システムで実現することを発注側と開発側で合意して文書に残す工程
業務要件を先に決め、そこから機能要件と非機能要件に落とす
進め方は、目的と範囲の確認、As-Is、To-Be、要件決め、文書化、合意の順が基本
成果物は要件定義書のほか、業務フロー図、機能一覧、非機能要件一覧、課題管理表など
要求定義は「希望」、要件定義は「約束」、基本設計は「どう作るか」と分けて考える
開発手法や作る物によって、決めるタイミングと気をつけるところが変わる

要件定義ガイド

要件定義ガイド編集部

システム開発の要件定義について、意味・進め方・要件定義書の書き方とテンプレート・必要なスキルを実務目線でまとめている情報サイトです。公式サイト