要件定義とは？システム開発7工程のどこに位置し、誰が関わり、何が残るのかをわかりやすく解説

「要件定義から始めましょうと言われたが、そもそも要件定義とは何をする工程なのか」——初めてシステム開発の担当になった方から、こうした相談をよく受けます。手順を説明した記事を読んでも、自分がどの場面に登場するのかが分からない。専門用語で説明されるほど、かえって全体像が見えなくなる。そういう状態でベンダーとの初回打ち合わせを迎えるのは、要注意です。

結論から言うと、要件定義とは「何を作るか」を関係者で決めて文書に残す工程です。開発全体では企画とRFPの後、設計の前に置かれます。決める責任は発注者側にあり、開発会社は聞き出して整理し、文書にする側です。そして成果物である要件定義書は、その後の見積もりの根拠であり、完成したかどうかを判定する検収の基準になります。

この工程を理解する近道は、手順を覚えることではなく、開発全体の地図の中で要件定義がどこに置かれているかを掴むことです。地図が頭に入れば、打ち合わせで飛び交う「基本設計」「非機能要件」「スコープ」といった言葉が、どの場面の話なのかが分かるようになります。

本記事では、要件定義の定義と「要求」との違い、システム開発7工程の地図における位置づけ、関わる5者の役割と要件定義書に残るもの、要件定義がないと何が起きるか、期間と体制の目安、オフショア開発での扱いと当社の位置づけ、よくある質問の順に解説します。工程の地図と関係者の流れは図解にしました。決める7項目や進め方の5ステップといった手順は「要件定義の進め方」の記事に譲ります。

私は人材業界の出身で、2018年からホーチミンでベトナムオフショア開発の体制づくりに携わり、約100社の相談に乗ってきました。相談の入口でいちばん多い質問が「要件定義もそちらでやってもらえますか」です。この記事を読み終えるころには、その問いに自分で答えられるようになっているはずです。

要件定義とは——「何を作るか」を決めて文書に残す工程

まず言葉の意味から整理します。要件定義は、システム開発の工程のひとつで、プロジェクトの初期に実施されます。ここで決まった内容が、そのあとの設計・実装・テストのすべての前提になります。逆に言えば、ここが曖昧なまま先に進むと、後工程は何を基準に作ればよいのか分からなくなります。

要件定義の定義——実装すべき機能と満たすべき性能を確定させる作業

要件定義とは、システムやソフトウェアの開発において、実装すべき機能や満たすべき性能などの要件を明確にしていく作業を指します。利用者がそのシステムで何をしたいのかをもとに、それを実現するために必要な機能や、達成すべき性能を洗い出し、関係者の合意のうえで確定させます。

確定した内容は「要件定義書」という文書にまとめられます。この文書は、発注者と開発会社が「どのようなシステムを作るか」について同じ絵を見るための土台です。開発の途中で「これはどうなっていましたか」という確認が出たときに、立ち返る先になります。

家づくりにたとえると分かりやすいと思います。何部屋必要か、キッチンはどの位置か、駐車場は何台分か、予算はいくらか。こうした「どんな家が欲しいか」を決めるのが要件定義です。柱を何本立てるか、配線をどう通すかを決めるのは、そのあとの設計の仕事になります。

「要求」と「要件」の違いは、合意したかどうか

要件定義の説明で必ず出てくるのが、「要求」と「要件」という2つの言葉です。ここを混同すると、打ち合わせの議論が噛み合いません。

要求とは、利用者や関係者が「こうしたい」と述べた希望です。現場からは無数に出てきます。一方の要件は、その要求のうち、実現性・費用・期間を踏まえて「今回作るもの」として関係者が合意した内容を指します。つまり、要求を選別し、合意という手続きを通したものが要件です。

IPAの解説では、この過程を「ビジネス要求を定義する」「システム化要求を定義する」「関係者と合意して要件とする」という流れで説明しています。要求の段階では業務の観点で「グローバルに在庫の状態がリアルタイムに把握できる」と書かれていたものが、要件の段階では「各倉庫の入出庫情報をリアルタイムに伝送し、安全在庫量を下回った場合にメールで通知する」という形に具体化されます。

なお、この2つを工程として分け、前半を「要求定義」、後半を「要件定義」と呼び分ける現場もあります。呼び方は組織によって揺れますが、やっていることは「集めて、選んで、合意する」で共通しています。

要件定義は「何を」まで。「どう作るか」は設計の仕事

もうひとつ押さえておきたい線引きが、要件定義と設計の境目です。要件定義の段階では「何が」必要なのかを定義するに留め、それを「どのように」実現するかは後の工程で検討します。

たとえば「申請書をPDFで出力できること」は要件です。そのPDFをどのライブラリで生成し、どのサーバーに置き、どんなファイル名で保存するかは、基本設計や詳細設計で決めることです。非エンジニアの担当者が要件定義の場で技術的な実装方法まで決めようとすると、話が進まなくなります。逆に、開発会社側が「使いやすくしておきます」で済ませようとしたら、それは要件として成立していません。

この線引きが守られていると、発注者は業務の言葉だけで参加できます。専門用語が分からなくても、「この業務をこうしたい」「この画面ではこの情報が見えていないと困る」と言えれば、要件定義には十分に貢献できます。では、その要件定義は開発全体のどこに置かれているのか。次に工程の地図を見ていきます。

開発全体のどこに位置するのか——企画・RFPから運用まで7工程の地図

要件定義という工程の性格は、前後に何があるかを見ると一気に理解しやすくなります。前には企画があり、後ろには設計があります。つまり要件定義は、「やりたいこと」と「作り方」をつなぐ蝶番の位置にあります。ここでは開発全体を7つの工程に分けて地図を描きます。

システム開発の7工程と、要件定義の前後

工程の切り方は会社やプロジェクトによって変わりますが、発注者の立場で全体を把握するなら、次の7つで足ります。

この表で押さえてほしいのは、主担当の列です。1から3までは発注者が主役で、4から5は開発会社が主役、6以降はふたたび両者が並びます。要件定義は、発注者が主役である最後の工程です。ここを越えると、決定権は少しずつ開発会社側の技術判断へ移っていきます。

RFPと要件定義を混同する方が多いのですが、順番と目的が違います。RFPは発注先を決めるために「こういうものを作りたい」と外に向けて示す依頼文書で、契約前に書きます。要件定義は契約後に、選んだ相手と一緒に中身を確定させる作業です。RFPの中身については「RFP 書き方」の記事で詳しく扱っています。

上流工程とは——企画・要件定義・基本設計の3つ

打ち合わせでよく聞く「上流工程」という言葉は、この7工程のうち企画・要件定義・基本設計の3つを指します。IPAの解説でも、要件定義の前には企画、うしろには基本設計があり、これらをまとめて上流工程と呼ぶと説明されています。そして、上流工程の取り組みが、完成するシステムの品質に大きく影響するとされています。

上流という呼び名のとおり、ここで混ざった濁りは下流のすべてに流れていきます。実装の腕がどれだけ良くても、作るものが間違っていれば、出来上がるのは「よくできた間違ったシステム」です。発注者が最も影響力を持てるのが上流工程であり、逆に言えば、上流で手を抜いた分は下流で取り返せません。

ウォーターフォールとアジャイルで置かれ方が変わる

ここまでは、前の工程を終わらせてから次へ進むウォーターフォール型を前提に説明しました。この方式では、要件定義はプロジェクトの最初に一度だけ行われ、これをもとに仕様や設計が固められます。官公庁や大企業の基幹システム、請負契約での開発では、いまもこの形が主流です。

一方、アジャイル開発のように同じ工程の流れを繰り返す反復型では、前の反復で作られた半完成品に触れながら要件定義を繰り返し、段階的に要件を明確化・詳細化していく進め方が取られる場合があります。「アジャイルだから要件定義はしない」のではなく、一度にまとめてやらずに小分けにする、と理解するのが正確です。

どちらの方式でも、「何を作るかを決めて合意する」という行為そのものは消えません。消えるのは「全部を最初に決める」という前提だけです。地図の上で要件定義の位置が分かったところで、次は、その場に誰が座り、何が残るのかを見ていきます。

要件定義に関わる人と、成果物として残るもの

要件定義は、1人で机に向かって書く作業ではありません。決める人、情報を出す人、聞き出して整理する人が別々にいて、その全員が揃わないと成立しません。ここでは登場人物と責任の所在、そして最後に何が手元に残るのかを整理します。

登場する5者と、それぞれが持つ責任

案件の規模によって人数は変わりますが、登場する役割はおおむね次の5つに分かれます。

この表で強調したいのは、いちばん右の列です。役割の境目は「やること」より「やらないこと」で決まります。業務部門が実装方法を指定し始めると選択肢が狭まり、開発会社が業務の決定まで引き受けると、出来上がったものを誰も評価できなくなります。

責任の所在についても、公的な整理があります。IPAは、システムの要件を定義する責任は、構築されたシステムを利用してビジネスに貢献する役目を負うユーザにある、としています。つまり決めるのは発注者です。当社が相談を受けたときに必ずお伝えしているのも同じ線引きで、決めるのは御社、聞き出して文書にするのは当社、という分け方です。この一線を曖昧にしたまま「要件定義もお任せします」で始めるのは、失敗のもとです。

ただし、これは発注者が1人で書けという意味ではありません。要求を引き出す質問の設計、抜け漏れの点検、文書としての体裁づくりは、経験のある側がやったほうが速く正確です。負担の大半はそちらに寄せてかまいません。

要件定義書に残る6つの中身

要件定義の成果物は、要件定義書です。プロジェクトによって章立ては変わりますが、含まれる中身はおおむね次の6つに整理できます。

このうち非機能要件は、発注者から自発的には出てきにくい部分です。「業務とは直接関係ないが、業務機能を実現するために必要な事項」なので、聞かれなければ誰も言いません。夜間に止まってよいのか、何秒で画面が開けば業務が回るのか、何年分のデータを残すのか。こうした問いは、開発会社側が投げかける必要があります。

なお、要件定義書に何をどう書くかという文書作成そのものの話は、この記事では扱いません。決める項目の中身と進め方については「要件定義の進め方」の記事にまとめています。

成果物は、見積もりの根拠と検収の基準になる

要件定義書は、作って終わりの文書ではありません。2つの場面で効いてきます。

1つは見積もりです。開発の見積金額は、作る対象の量と複雑さから積み上げられます。要件が確定していない状態の見積もりは、開発会社が「たぶんこのくらい」と幅を取った数字にならざるを得ません。要件定義書があると、その根拠を行ごとに確認できます。

もう1つは検収です。完成したかどうかは、契約上「要件を満たしているか」で判定されます。要件定義書に書かれていない期待は、法的にも実務的にも「言っていないこと」になります。納品物を見て「思っていたものと違う」と感じたとき、それが是正の対象になるか追加費用になるかは、この文書の記述で決まります。

だからこそ、要件定義書は発注者が読める言葉で書かれている必要があります。開発の知識がない人が読んでも分かるように専門用語を避けて書く、というのは、親切心ではなく検収のための実務要件です。

要件定義がないと何が起きるのか——手戻り・追加費用・検収トラブルと、期間と体制の目安

「要件定義は重要です」とだけ言われても、忙しい現場では後回しになります。そこで、飛ばした場合に実際に何が起きるのか、そして適切にやるならどれくらいの時間と人数が要るのかを、公開されているデータと現場の経験の両方から示します。

要件定義を薄くしたときに起きること3つ

まず、これは精神論ではありません。一般社団法人日本情報システム・ユーザー協会の「ユーザー企業ソフトウェアメトリックス調査(2016年版)」では、システム開発プロジェクトの工期遅延理由の1位と2位が、いずれも要件定義フェーズに原因があるという回答でした。調査対象のプロジェクトのうち4割が、要件定義に問題があって工期が遅延したとしています。

現場で起きることを具体的に書くと、次の3つに集約されます。

1つ目は手戻りです。要件定義で抜け・漏れ・あいまいな表現があると、設計や開発の工程に入ってから作り直しが発生します。厄介なのは、遅い工程で見つかるほど直す範囲が広がることです。画面を1枚追加するだけのつもりが、データ構造の変更を伴い、既に作った機能まで巻き込む。私が相談を受けた案件でも、要件定義を薄くして「作りながら決めましょう」で始まったものは、3か月目に作り直しが出るのが実情です。

2つ目は追加費用です。契約後に出てきた要求は、原則として追加の作業になります。要件定義書がなければ、その要求が「もともと含まれていたもの」なのか「新しく増えたもの」なのかを判定する基準がありません。判定できない以上、金額の交渉は力関係の話になってしまいます。

3つ目は検収でのもめごとです。納品されたものを見て「これでは業務が回らない」と感じても、要件として書かれていなければ、開発会社に是正の義務は生じません。関係が悪化したまま運用に入ると、その後の保守も進まなくなります。

期間と体制の目安——投入人数を増やしても期間は縮みにくい

では、どれくらいの時間をかけるのが普通なのか。工程別の工数・工期の比率を示した公的な一次データは、現在の公開資料からは確認できませんでした。そのため、ここでは数値ではなく性質で押さえます。

当社が支援してきた案件で一貫しているのは、要件定義が「少人数で、一定の期間をかけて進む」工程だということです。人を10人投入しても10分の1の期間で終わる性質のものではありません。関係者の合意を積み上げる作業なので、会議と持ち帰りの往復が必要になり、そこに日数がかかるからです。増員では短縮しにくい工程だという点は、スケジュールを引く前に知っておいてください。

体制の目安も、この性質から導けます。発注者側は、最終的に決める人を1名に決めておくこと。そのうえで、業務を説明できる現場の担当者、既存システムを把握している情報システム部門の担当者を加えた2〜4名程度が、中小規模の業務システムでの現実的な構成です。人数を増やすより、出席者が毎回同じであることのほうが効きます。前回の議論を知らない人が入るたびに、話は最初に戻ります。

進め方の手順は別記事へ——本記事は地図まで

では実際に、何をどの順番で決めていけばよいのか。要件定義には、決める項目(業務要件・機能要件・非機能要件・画面UI・データ・外部連携・運用保守など)と、進める手順(体制づくり、ヒアリングと現状分析、要求の整理と優先順位づけ、要件の確定と文書化、合意形成)があります。これらの中身と、発注者・ベンダーそれぞれが担う作業分担については「要件定義の進め方」の記事で詳しく扱っています。本記事は工程の地図までを担当しますので、実務に入る段階ではそちらをご覧ください。

ここまでで、要件定義が何をする工程で、どこに置かれ、誰が関わり、何が残るかを見てきました。では、その工程を海外の開発チームと進める場合、何が変わるのでしょうか。

オフショア開発・外部委託での要件定義と、当社の位置づけ

ここまでは、開発を外部に委託する場合に共通する話でした。委託先が海外のチームになると、要件定義の重みはさらに増します。最後に、その理由と当社の進め方、そして向かない案件を正直に書いておきます。

海外チームに渡すと、要件定義の粗さがそのまま品質に出る

国内の開発会社に発注していると、書かれていないことを相手が業務知識で補ってくれる場面があります。「この帳票なら普通は締め日で区切るだろう」といった補完です。この補完は、同じ商習慣を共有しているから成り立ちます。

海外のチームには、その前提がありません。日本の業務慣行や、その業界特有の当たり前を知らない相手に対しては、書かれていないことは存在しないのと同じです。結果として、要件定義が粗いままオフショアに渡した案件は、出来上がったものの差が国内発注よりはっきり出ます。逆に、要件が明確であれば、実装の品質そのものは国内と変わりません。当社の事例でも、お客様から「想像以上にエンジニアのレベルが高い」という評価をいただいています。差が出るのは技術力ではなく、渡し方です。

当社は「決めるのは御社、聞き出して文書にするのは当社」

当社への相談でいちばん多いのが、「要件定義もそちらでやってもらえますか」という質問です。当社の答えは一貫しています。業務を知っているのは御社なので決めるのは御社、聞き出して整理し、文書にするのは当社です。

具体的には、日本人PMをフロントに置く体制(パターンA)を推奨しています。日本人PMがヒアリングの設計と議事の整理、仕様の文書化、ベトナム側エンジニアへの伝達までを担い、発注者には業務の言葉で判断していただきます。品質面では、日本人PMによる設計レビュー、Gitのプルリクエストによるコードレビューの標準化、リリース前のダブルチェックを標準の仕組みとしています。時差は2時間なので、日本の午前中に投げた質問はその日のうちに返ります。

介護記録SaaSのCareViewerでは、日本語のできるブリッジSE1名とフルスタックエンジニア2名の体制で、要件が動き続けるプロダクトを週次の優先順位判断で回しています。最初にすべてを決め切るのではなく、決める場を毎週用意する形です。費用は、日本人PMフロントに2〜3人月を加えた最小構成で月額約80万円〜が目安です。エンジニアの公開単価は実務3年目安で1,500USD(1USD=150円換算で約22.5万円)、5年で2,000USD、10年目安やブリッジSEで3,000USDとしています。

向く案件と向かない案件

正直に書くと、当社のようなラボ型の体制が向くのは、要件が動き続けるプロダクトや、継続して開発と改修が発生する案件です。決める場を毎週持てる体制と相性が良いからです。

一方、要件がすでに確定していて単発・短期で終わる開発、社内に判断できる担当者を置けない案件は向きません。前者は請負契約のほうが適していますし、後者は体制の前に社内の意思決定の整理が先です。そうした案件のご相談をいただいた場合は、その旨を率直にお伝えしています。ラボ型の全体像については「ラボ型開発」の記事も参考にしてください。

要件定義に関するよくある質問

最後に、非エンジニアの担当者から実際によく受ける質問を5つ取り上げます。いずれも本文で触れた内容の補足ですが、打ち合わせの場で言葉に詰まりやすい論点なので、独立させて答えておきます。

Q1. 要求定義と要件定義は何が違いますか

要求定義は「利用者が何を実現したいのか」を整理する段階、要件定義はその要求をもとに「システムで何を実現するのか」を確定させる段階です。要求は希望であり、要件は関係者が合意した決定事項です。組織によっては両方をまとめて要件定義と呼び、その中を業務要件とシステム要件に分けて扱います。呼び方の違いに悩む必要はなく、いま話しているのが希望の段階なのか合意済みの段階なのかを確認してください。

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

要件定義は「何を実現するか」を決める工程、基本設計は決まった要件を「どのように実現するか」を具体化する工程です。基本設計では画面や帳票のレイアウト、データ項目、外部システムとの連携方法などが決まり、基本設計書としてまとめられます。発注者が最も影響力を持てるのは要件定義までで、基本設計以降は技術判断の比重が上がります。

Q3. 要件定義は結局、誰が責任を負うのですか

責任は発注者側にあります。IPAも、システムの要件を定義する責任は、そのシステムを使ってビジネスに貢献する役目を負うユーザにあるとしています。開発会社が担うのは、ヒアリングの設計、要求の構造化、実現性の提示、文書化までです。ただし責任があることと、1人で書くことは別です。作業の負担は経験のある側に寄せてかまいません。

Q4. 機能要件と非機能要件は、どう見分ければよいですか

機能要件は「システムが何をするか」、非機能要件は「どの程度の品質で動くか」です。検索できる、承認できる、帳票を出力できる、は機能要件です。3秒以内に表示される、100人が同時に使える、夜間バックアップを取る、5年分のデータを保持する、は非機能要件にあたります。非機能要件は発注者から自発的に出てきにくいため、開発会社側から具体的に聞くべき領域です。

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

必要です。なくなるのは「最初に全部決める」という前提だけで、何を作るかを決めて合意する行為そのものは各反復の中に残ります。むしろ、毎回の優先順位を判断する人が発注者側にいないと進みません。当社のラボ型でも、1名からの小さな体制で始めて、週次で優先順位を決める場を持つ運用。

まとめ: 要件定義とは、作るものの輪郭を決めて文書に残す工程——地図を持ってから手順に進む

要件定義とは、実装すべき機能と満たすべき性能を関係者で決め、要件定義書として残す工程です。開発全体では企画、RFP・発注に続く3番目に置かれ、企画・要件定義・基本設計をまとめて上流工程と呼びます。決めるのは「何を」までで、「どう作るか」は基本設計以降の仕事です。要求は希望、要件は合意した決定事項という違いも押さえておいてください。

関わるのは、経営層・業務部門・情報システム部門・開発会社のPMやブリッジSE・エンジニアの5者です。決める責任は発注者側にあり、開発会社は聞き出して整理し、文書にする側にいます。成果物である要件定義書は、その後の見積もりの根拠であり、検収の基準にもなります。この工程を薄くすると、手戻り・追加費用・検収でのもめごとという形で必ず跳ね返ってきます。人を増やしても短縮しにくい工程なので、スケジュールは先に確保してください。

ここまでが工程の地図です。実際に何をどの順番で決めるか、発注者とベンダーがそれぞれ何を担うかは要件定義の進め方にまとめました。発注前に依頼内容を文書化する段階であればシステム開発のRFPの書き方もあわせてご覧ください。海外チームに開発を任せる場合、要件定義の粗さはそのまま成果物の差として出ます。当社は日本人PMがヒアリングの設計と文書化を担い、決めるのは御社という線引きで進めています。現在の体制と要件をお聞かせいただければ、どこから手をつけるべきかの判断と概算見積もりでお答えします。合わない案件にはその旨も率直にお伝えします。