要件定義とは？意味をわかりやすく解説｜家づくりで見る全体像

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

要件定義とは？意味をひとことで言うと

ITの世界で「要件」と言う時は、システムが満たすべき条件のことを指します。つまり、IT分野の要件定義とは、その条件を一つずつ言葉にして関係者で確かめ合う作業なんです。

よく混ざるのが「要求」という言葉ですよね。要求は利用者や発注者の「こうしたい」「こうなってほしい」という願いです。

一方で要件は、その要求のうち予算や期間、技術を踏まえて「システムで実現する」と合意したものです。願いを出すのが要求定義、実現する約束に絞るのが要件定義、と覚えておくとわかりやすいです。

要求と要件の違いをもっと深く知りたい方は、要求定義と要件定義の違いで詳しく扱っています。

要件定義の「要件とは」何を指すのか

要件には大きく分けて、業務のやり方に関するものと、システムの働きに関するものがあります。前者を業務要件、後者をシステム要件と呼ぶことが多いです。

さらにシステム要件は、何をするかを決める機能要件と、どのくらいの品質で動くかを決める非機能要件に分かれます。この3つがそろって、はじめて「何を作るか」が決まったと言えます。

要件定義はシステム開発のどこにあるのか

要件定義は、システム開発のいちばん最初のほうにある「上流工程」です。IPAの「共通フレーム2013」では、企画の後に要件定義があり、そこから設計、実装、テストへと進む流れで説明されています。

開発の左側（要件定義や設計）と右側（テスト）を対応させて考える見方を、V字モデルと呼びます。この見方では、要件定義で決めた内容は最後の受入テストで発注側が確かめることになります。

つまり、要件定義で書いたことが、そのまま「完成を判断する物差し」になるんです。ここが大事なところなので、覚えておいてください。

家づくりにたとえると要件定義の全体がつかめます

ここがこの記事でいちばん伝えたいところです。要件定義は、注文住宅を建てる前の「間取り決め」によく似ています。

施主（発注側）は「家族4人で住みたい」「在宅勤務の部屋がほしい」と希望を出します。工務店（開発側）は、予算や土地の広さを見ながら「この間取りなら建てられます」と提案し、図面で合意しますよね。

『家の話ならわかるけど、システムだとピンとこない』という方もいるかもしれません。ただ、間取りが決まらないまま柱を立て始めたら困るのは、どちらも同じなんです。

例えば完成間近に「やっぱり和室がほしい」と言われたら、壁を壊してやり直すことになります。システムでも、作った後に「この画面が足りない」と分かると、設計から作り直す手間がかかります。

間取り図がないとどうなるか

間取り図がないと、施主と工務店がそれぞれ別の家を思い浮かべたまま進んでしまいます。要件定義書がないシステム開発も同じで、完成してから「思っていたのと違う」が起きやすくなります。

発注側「この前話した集計の画面、入っていないんですか」
開発側「議事録には残っていなかったので、対象外だと思っていました」

こうしたすれ違いを防ぐために、要件定義を文書に残して両者で確かめるんです。要件定義を書面にする具体的な方法は、要件定義書とはでも紹介しています。

要件定義で決めることは大きく3つ

『機能を並べれば終わりじゃないの？』と思われがちですが、実は機能だけでは足りません。それぞれ何を決めるのか、見ていきましょう。

業務要件：業務をどう変えるか

業務要件は、業務を誰が、いつ、何を、どんな基準で行うかを決めるものです。システムの話をする前に、仕事のやり方そのものを決めておく部分ですね。

例えば経費精算なら「申請者が月末までに申請し、上長が3営業日以内に承認する」のように書きます。業務の流れは、業務フロー図で描いておくと関係者が同じ絵を見て話せます。

機能要件：システムが何をするか

機能要件は、画面、帳票、データ、処理、外部との連携など、システムが行うことを決めるものです。「申請画面で領収書の画像を添付できる」のように、できることを具体的に書きます。

非機能要件：どのくらいの品質で動くか

非機能要件は、性能や安全性、運用のしやすさなど、機能以外の品質に関する条件です。見落とされやすいのですが、後から変えるのがとても大変な部分なんです。

IPAの「非機能要求グレード」では、非機能要件を次の6つの大項目で考えます。各項目のレベルを0から5の段階で選ぶ方式で、発注側と開発側が合意しやすくなる道具として公開されています。

詳しくはIPA 非機能要求グレードで確認できます。

記入例：社内の勤怠管理システムを入れ替える場合

言葉だけだとイメージしにくいので、架空の題材で記入例を作ってみました。社内の勤怠管理システムを入れ替える場合の、3つの要件の書き方の例です。

このように、業務要件で「仕事のやり方」を決め、機能要件と非機能要件で「それを支えるシステムの条件」を決めていきます。上から順に書くと、なぜその機能が必要なのかが自然とつながりますよ。

システム側の要件をもっと詳しく知りたい方は、システム要件定義とはを読んでみてください。

要件定義の進め方と役割分担

要件定義を進める時は、いきなり機能を書き出すのではなく、目的から順に絞り込んでいきます。大まかな流れは次のとおりです。

各ステップの詳しいやり方は要件定義の進め方・手順にまとめています。ここでは、立場ごとの役割を見ておきましょう。

発注側と開発側は何を担うのか

『要件定義は開発会社がやってくれるもの』と考えている方もいるかもしれません。でも、業務を一番知っているのは発注側ですよね。

IPAが2019年に公開した「ユーザのための要件定義ガイド 第2版」も、業務に責任を持つユーザ（発注側や業務部門）に向けて書かれています。DXの流れの中で、業務部門が主体的に要件定義に関わる必要が増している、という問題意識が背景にあります。

どの立場がどこまで担うかは、契約の形や会社によって変わります。誰が中心になるかで迷ったら、要件定義は誰がやる？も参考にしてみてください。

ウォーターフォールとアジャイルで要件定義は変わるのか

工程を上から順に進めるウォーターフォールでは、要件定義書を確定させてから設計に進むのが基本です。後から変えると手戻りが大きいので、最初にしっかり決めておきます。

一方、短い期間で作って確かめるを繰り返すアジャイルでは、要件を一度に決めきりません。「利用者として、目的のために、この機能がほしい」という形のユーザーストーリーで要望を並べ、優先順位の高いものから少しずつ決めていきます。

どちらの進め方でも「何を作るかを合意する」という目的は変わりません。違うのは、決めるタイミングと文書の厚さなんです。

要件定義書にはどんな項目を書くのか

要件定義の結果をまとめたものが要件定義書です。様式は会社ごとに違いますが、一般的な章立ての例を挙げておきます。

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

書き方の手順は要件定義書の書き方で、項目ごとの記入例つきで紹介しています。

要件定義でつまずきやすいポイントと防ぎ方

初めて要件定義を担当すると、同じところでつまずく方が多いんです。よくある失敗と、その防ぎ方を見ておきましょう。

国際規格のISO/IEC/IEEE 29148では、よい要件の性質として、あいまいでないこと、検証できること、矛盾しないことなどが挙げられています。言い換えると「後から確かめられる書き方」になっているかが大事なんです。

決めきれないことは「未決」として残す

全部を一度に決めきるのは、実際にはなかなか難しいですよね。決まらないことを黙って先送りにすると、設計の途中で問題が大きくなりがちです。

そこで、決められなかったことは課題一覧に「未決」として書き、誰がいつまでに決めるかを添えておきましょう。それだけで、後から「聞いていない」となるのを防げます。

関係者が多くて話がまとまらない

部署ごとに言うことが違って、なかなか要件がまとまらないこともありますよね。そんな時は、最終的に決める人（承認者）を最初に決めておくのが近道です。

意見が分かれた時は、システム化の目的に照らしてどちらが近いかで判断します。目的が文書になっていれば、「声の大きい人の意見が通る」という事態も防ぎやすくなります。

利用部門「入力画面は今の帳票と同じ並びにしてほしいです」
情報システム部門「目的は入力ミスを減らすことでしたよね。並びを変えるとミスが減るなら、そちらを優先しませんか」

このように、目的に戻って話すと、好みの違いで止まっていた話も前に進みます。

設計と混ぜてしまう

要件定義は「何を作るか」、基本設計は「どう作るか」を決める工程です。要件定義の場でボタンの色や画面の配置まで細かく決め始めると、肝心の範囲や優先順位が決まらないまま時間が過ぎてしまいます。

工程の境目は要件定義と基本設計の違いで詳しく紹介しています。目的を見失わないコツは要件定義の目的も読んでみてください。

よくある相談に答えます

ここでは、要件定義について実際によく寄せられる相談を、要約してお答えします。

要件定義の段階で、入出力の細かい仕様まで求められるのは普通？

「要件定義の工程なのに、設計や実装に近い資料まで作るよう求められる」という相談があります。結論から言うと、会社や案件によってよくあることですが、範囲を確かめておくのが大切です。

要件定義で決めるのは「何を入力し、何を出力するか」までが目安です。項目の桁数や画面の細かい配置は、本来は設計で決める話なので、どこまで書くかを最初に関係者とすり合わせておきましょう。

社内SEが一人で要件定義から導入まで担当している。進め方は合っている？

人数の少ない会社では、社内SEが要件定義から導入まで一人で担うこともありますよね。一人で進める時ほど、決めたことを文書に残しておくのが助けになります。

業務部門の責任者に要件の承認をもらう場を設けると、後から「そんな話は聞いていない」と言われにくくなります。一人で抱え込まず、決める人と確かめる人を分けておきましょう。

「要求定義」と「要件定義」は英語でどう言うの？

要求はRequirement、要件定義はRequirements Definitionと書かれることが多いです。英語では要求と要件を一つの言葉で表すことが多く、日本語ほど区別しない場面もあります。

日本の現場で迷ったら、「願い」が要求、「合意した条件」が要件、と考えておけば大きく外れません。

よくある質問

まとめ

あわせて読みたい

要件定義書とは？中身と読み手別の見方、システム要件定義書との関係

要件定義の進め方とやり方｜6つの手順と週ごとのスケジュール例

要求定義と要件定義の違いを会話例で解説｜要望が要件になるまで