最終更新日：2024年7月2日
「要件定義って具体的に何をするんだろう？」
「要件定義はどうして重要だと言われているんだろう？」
「要件定義で失敗しないためには、どんなことに気を付けたらいいんだろう？」
システム開発の現場でたびたび耳にする「要件定義」という言葉について、上記のような疑問を持ったことはありませんか？
そこで今回は、システム開発プロジェクトの最初の一歩となる「要件定義」についてあまり詳しく知らない方向けに、要件定義の概要や求められるスキル、進め方のポイントなどについて解説していきます。
この機会に要件定義に関して理解を深めたい方は、ぜひ参考にしてみてください。
目次
１．要件定義とは？
要件定義とは、ユーザー（発注者）の要望をヒアリングしたうえで、その要望を実現するために具体的にどのような方向性・手順でシステムを構築していくべきか、誰が見ても理解できるように文書化する作業のことです。
簡単に言えば、要件定義とはシステム開発の土台作りの工程であり、プロジェクトを迷走させないための道しるべであると考えることができます。
要件定義はウォーターフォールモデルの最上流に位置する
システム開発の手法は様々ありますが、日本で古くから幅広く採用されてきた開発手法として「ウォーターフォールモデル」というものがあります。
ウォーターフォールモデルとは、その名が示す通り上流から下流へと「水が流れ落ちる」がごとく、前の工程には戻らないことを前提に要件定義、設計、開発、テストと1つ1つの工程を確実に完了させながら進めていくシステム開発モデルです。
要件定義はウォーターフォールモデルの一番上に位置し、システムに搭載する機能や細かな仕様、必要な予算、人材、各工程にかかる期間などをすべて詳細に決めてから開発をスタートさせます。
要件定義の重要性
要件定義はシステム開発の初期段階で行われる工程であり、プロジェクトの成否やシステムの品質を左右する非常に重要な役割を担っています。
万が一、要件定義が不十分なままプロジェクトが進んでしまうと、
・想定していたものと全く違うシステムが出来上がった
・せっかく作ったものの全然役に立たなかった
・予算が大幅にオーバーしてしまった
・開発スケジュールが大幅に遅延した
・最終的な納期に間に合わなかった
といったトラブルにつながりかねないほか、後から「実はこんな機能が欲しかった」とユーザーの隠れた要望が明らかになり、開発がやり直しになってコストや時間が無駄になってしまう可能性もあります。
このようなリスクを避け、ユーザーが求める成果物を決められた期間内に完成させるためには、要件定義の段階でユーザーとベンダーが綿密な打ち合わせを重ね、お互いに納得するまでニーズや方向性のすり合わせを行う必要があります。
「要求定義」と「要件定義」の違い
要件定義とよく似た言葉に「要求定義」がありますが、この2つは別物であることに注意しましょう。
「要求定義」とは、解決したい課題、システム導入の目的、欲しい機能など、システム化によって実現したい要求事項を整理する工程のことです。
本来は実際にシステムを使う側であるユーザーが主体となって実施する作業ですが、ユーザーの言葉の裏にある潜在的なニーズを掘り起こすべく、ベンダーがヒアリングという形で代行する場合もあります。
一方「要件定義」とは、ユーザー側の要求定義の内容を受けて、それらの要求をどのような方法で実現すべきか定める工程を指します。
予算や納期の関係でユーザー側の要求をすべて叶えることは難しいため、ベンダー側の方で改めて要求事項を整理して本当に必要なものだけに絞り込み、その対応方法を明確にしていきます。
つまり、「要求定義」でシステム導入後の希望を明らかにし、「要件定義」でその希望を実現するための方法や手順を定めていく、という流れになります。
「要件定義」と「基本設計」の違い
もう1つ、要件定義と混同しやすい工程として「基本設計」があります。
「基本設計」とは、要件定義の内容を受けて、実際にシステムを動かす部分の仕様を決定する工程です。
要件定義の工程でユーザーからの要求をもとに実装すべき機能や性能を定めたら、基本設計の工程でそれぞれの機能がどのようなものか、何をする機能なのか、機能同士はどのようにつながるのか、各機能の役割についてさらに具体化していきます。
要件定義が「言葉」でシステムに必要な機能を明確化するプロセスだとするなら、基本設計は開発すべき内容を「図」で視覚的にユーザー側へ共有し、システムの完成イメージをすり合わせていくプロセスであるといえます。
２．要件定義の責任はユーザー（発注者）にある
ユーザーの要求を実現するための具体的な方法を検討していくのが要件定義ですが、要件定義の最終的な責任はユーザー（発注者）側にあることを忘れないようにしましょう。
もちろん、ベンダー側もIT分野の専門知識やノウハウを活かして、要件定義がスムーズに進むよう積極的に支援を行う必要があります。
しかし、元々は「何のためにシステムを導入するのか？」「システムを使って何を実現したいのか？」といったユーザーの要望が要件定義の出発点となっていることから、システム開発を依頼した側、すなわちユーザーこそが要件定義の責任を負うべきなのです。
「この要望を伝え忘れていた」「システム化の目的があやふやだった」という責任の所在はユーザー側にあるのだという前提をしっかりと念頭に置き、ベンダーにすべて任せきりにせず能動的な姿勢で要件定義に取り組んでいくことが大切です。
３．要件定義の進め方
要件定義は、基本的に以下3ステップに沿って進めていきます。
①ユーザーから要求をヒアリングする
②要求内容を整理する
③要件定義書を作成する
ユーザーから要求をヒアリングする
要件定義は、ユーザーの要求をヒアリングするところからスタートします。
ヒアリングでは、
「現状どのようなプロセスで業務をこなしており、どのような課題を抱えているのか？」
「システム化でどのような課題を解決し、何を実現したいのか？」
などを聞き出し、現状の課題やシステム開発の目的を明確にしていきます。
既にユーザーの方で要求定義が行われていた場合でも、まだ言語化しきれていない潜在的なニーズが存在するかもしれないので、要求事項が漏れなく出揃っているかベンダー側の視点からしっかりと確認することが重要になります。
要求内容を整理する
ユーザーの要求をヒアリングによって明確にできたら、次はその要求がシステムで実現可能な内容かどうか1つずつ吟味していきます。
要件定義ではどうしても「あれも欲しい、これも欲しい」と要求が膨らみがちですが、プロジェクトの予算やスケジュールの都合上すべての要求を実現できるとは限らないため、必ず実現したい内容なのか、できれば実現したい内容なのか、ユーザーとよく話し合って要求内容に優先順位をつけていきましょう。
実現性の高さや導入のしやすさなどを考慮しながら要求内容を整理していくことで、ユーザーのニーズを満たしつつ、現実的に無理のない範囲でプロジェクトを進めていくことができます。
要件定義書を作成する
要求内容の整理を行ってシステムに関する要件が固まったら、いよいよ要件定義書としてドキュメント化していきます。
要件定義書には、ユーザーからヒアリングした解決すべき課題や開発目的だけではなく、要望を実現するために必要なシステムの全体像や具体的な機能など、これまでに整理したすべての内容を盛り込みます。
これから開発していくシステムの完成イメージについて、ユーザーや開発メンバー全員でズレなく認識を共有できるよう、ITに関する専門知識が無い人でも理解しやすい内容にまとめることが大切です。
４．要件定義書に必要な項目
システム開発案件によって要件定義書に盛り込むべき項目は様々ですが、ここでは一般的に必要な項目を挙げていきます。
なお、要件定義書には具体的にどのような内容を記載する必要があるのか、書き方を詳しく知りたい方は、こちらの記事も併せてご参照ください。
システム導入の背景・目的
プロジェクトを進めるにあたり、関係者の間で認識の相違が生じて方向性が脱線しないよう、そのシステムを何のために導入するのか、システム化によってどのような課題を解決し、どのような目標を達成したいのかについて、誰が見ても分かりやすい形で記載します。
システムの概要
最終的にどのようなシステムを構築するのか、成果物の具体的なイメージを共有できるように、システム全体の構成図や用途・対象ユーザーといった情報を記載します。
業務要件
業務要件とは、システム化の対象となる現状の業務プロセス（As-Is）を分析し、そこに潜む問題点を洗い出して新たに実現すべき業務の流れ（To-Be）を明らかにしたものです。
システムの技術的なハードルは意識せず、あくまでも業務そのものにフォーカスし、システム導入後に実現したい業務の詳細な手順や担当者、業務全体の流れなどを記載します。
システム要件
システム要件とは、業務要件で定められた内容を実現するために、システムにどのような機能や性能が求められるかを明確にしたものです。
予算や技術的な制約条件を踏まえ、業務要件で明確化した「業務上の要望」の中からシステム化するもの・しないものを選別し、どのような形でシステムへ落とし込んでいくべきか、システム開発の方向性について記載します。
機能要件
機能要件とは、システム要件で決定した方向性に基づき、具体的にどのような機能が必要になるかを定めたものです。
扱うデータの種類・構造やシステムが処理可能な内容、画面レイアウト、操作方法、帳票の出力形式などを記載します。
非機能要件
非機能要件とは、システムの機能面以外で検討すべき要件のことです。
セキュリティやパフォーマンス、可用性、拡張性など、ユーザーの目には触れない「システムの裏側」の要件について定めていきます。
対象範囲が幅広いため、情報処理推進機構（IPA）が策定した「非機能要求グレード」の6項目（「可用性」「性能・拡張性」「運用・保守性」「移行性」「セキュリティ」「システム環境・エコロジー」）に沿って記載するケースが多いです。
技術要件
技術要件とは、IPAの「非機能要求グレード」とは別に、システム開発においてどのような技術を用いるかについて定めたものです。
内容としては、システムの基盤となるプラットフォームや、特定のフレームワークのような使用技術、採用するデータベース、システムを構築するために活用される開発言語などを記載します。
予算、人員、スケジュールなど
要件定義以降の開発計画について、予算、人員、スケジュール、作業場所、使用する機器などの具体的な計画内容を記載します。
５．要件定義に必要なスキル
要件定義を的確に行うために必要となる主要3スキルについて見ていきましょう。
ユーザーの意図を正しく把握できる
要件定義では、ユーザーから適切に要求を引き出し、正確に意図を汲み取るヒアリングスキルがとりわけ重要です。
すべてのユーザーが要求内容を細部に渡るまで理路整然と説明できるわけではないので、ヒアリングを通してユーザーが上手く言語化しきれなかった部分や、ユーザー自身も気づいていないニーズも補完しながら、相手の要望を的確に把握できる能力が求められます。
ちなみに、ユーザーの要望を正しく把握するうえで重要な足がかりとなるのが、相手の業界に対する知識や業務への理解です。
ユーザーが属する業界特有のルールや取り扱う業務内容への理解が十分であればあるほど、相手は今何に困っていて、どのような改善を望んでいるのか想像がつきやすくなります。
要求内容が実現可能かどうかイメージできる
要件定義を適切に行うには、ユーザーの要求が実現可能かどうか判断できる力も必要になります。
そのためにはシステム開発に関する技術と知識、経験が欠かせません。
実際、要件定義の担当者が「できる」と思って案件を受注したものの、予想外に開発が難航してトラブルが続出する「炎上案件」は残念ながら数多くあります。
たとえユーザーから無理難題な要求を出された場合でも、代替案を提示するなどして要件定義の段階でしっかりと断っておけば、その後のプロジェクトも円滑に進めることができます。
第三者にも正確に伝わるように要件を文章化できる
ユーザーの要求をもとに実現可能なシステムを具体的にイメージできただけでは、要件定義としては不十分です。
ユーザーや開発に携わるメンバー全員が同じ共通認識を持ってプロジェクトに取り組めるよう、誰が読んでも理解できる要件定義書などのドキュメントを作成する必要があります。
ドキュメントの作成は何かと手間がかかりますが、ここで不備があるとその後の設計や開発段階で手戻りが発生し、余分な時間やコストがかかってプロジェクトが失敗しかねないため、要件を正確に言語化して具体的な文章に落とし込める能力は非常に重要です。
６．要件定義をスムーズに進めるポイント
ここでは、要件定義を上手に進めるために意識したい6つのポイントをご紹介します。
5W2Hでユーザーの要求を正確に引き出す
ユーザーの要求を正しく引き出すためにはヒアリングが重要ですが、「5W2H」を意識するとヒアリング精度が格段に向上します。
内容の抜け漏れや曖昧さが生じないよう、以下の観点を意識しながらヒアリングを行いましょう。
Why：なぜシステム化が必要なのか？背景・目的は？
What：現状の課題や改善したいポイントは何か？何を実現したいのか？
Where：どの部分にシステムを導入するのか？開発範囲は？
Who：システムの利用者や運用者は誰か？
When：いつまでにシステムを開発する必要があるのか？
How：どのように要求を実現するのか？
How much：予算はどのくらいか？
ユーザーの現行システムや業務フローを把握する
ユーザーがシステム化によって叶えたい要望は実に様々なものがありますが、多くは現行のシステムや業務フローに問題があり、その問題を解決したいがためにプロジェクトを立ち上げています。
つまり、要件定義段階で必要になるのは、既に社内で使われているシステムや現在用いられている業務フローについて正しく理解し、その中でどの部分に問題があってどのように解決すべきかを明らかにすることになります。
中には、現行システムの設計書通りに業務を行っていないケースもあるので、要件定義の精度をさらに高めるなら、システムの利用者や保守担当者からのヒアリング調査も必要になってきます。
ミーティングの必要回数を予測する
要件定義において何かと悩みの種となるのが、ミーティングの回数です。
週に何度もミーティングの時間を設けることは業務都合を考えても現実的ではありませんし、逆に回数が少なすぎても「要件を決めきれない」「関係者が出席できず確認が進まない」といった事態になりかねません。
何回ミーティングを開催すれば要件が固まるのか、適切な回数は一概には言えないものの、システムの機能や業務フローごとに打ち合わせ内容を区切り、一度のミーティングで検討すべき範囲をなるべく狭めることで、大まかながらも打ち合わせに必要な回数が見えてくるようになります。
ユーザーの要求と要件定義書が一致しているか確認する
ユーザーの要求を土台として要件定義書が完成したら、抜け漏れや認識のズレがないか、ユーザーとベンダーの双方ですり合わせを行うことが大切です。
万が一両者の間で認識の違いがあったまま開発が本格的にスタートしてしまうと、後の工程で手戻りが発生して納期の遅れや予算オーバーにつながってしまいます。
このような事態を防ぐためにも、要件定義書の内容をじっくりと読み込み、ユーザーの要求事項が満遍なく反映されているかどうか慎重に確認するようにしましょう。
プロジェクト内で役割分担を明確にする
ユーザー側とベンダー側の役割分担を明確に決めておくことも、要件定義をスムーズに進めていくためには欠かせません。
役割分担を曖昧なままにしておくと、やらなくてもよい仕事が増えて本来の業務に支障をきたす可能性があります。
例えば、現行業務の洗い出しや将来的なビジョン策定など、元々はユーザー側が行わなくてはならない業務をベンダー側が引き取って作業するといったケースです。
そのため、WBSなどを活用してすべてのタスクに担当者と期限を割り振り、誰がいつまでに何をすべきかはっきりしていない業務を無くすよう心がけましょう。
誰が見ても理解しやすい要件定義書を作る
要件定義書というのは、誰か1人だけが見るものではありません。
エンジニアといったシステム開発に携わるメンバーはもちろんのこと、IT分野の専門知識があまり豊富ではないユーザーなど、関係者となる何人もの人が目を通すものです。
そして、各関係者の間で専門知識レベルに差があるということは、認識のズレが発生しやすいということに他なりません。
認識のズレを放置したままプロジェクトを進めてしまうと、後々想定外のシステムが出来上がって、「思っていたものと違う」「こんなはずではなかった」とクレームにつながる恐れがあります。
そのため、要件定義書を作成する際は、ユーザーが最終的な成果物を具体的にイメージできるよう、ITに関する専門知識が無くてもすんなり理解できるほど説明を分かりやすく工夫することが大切です。
７．まとめ －良い要件定義書には要求の「叶え方」が書かれている
いかがでしたでしょうか？
要件定義の目的は、ヒアリングを通してユーザーから掘り起こした要求内容を明確にまとめることだけではありません。
その要求をどのようにして実現するかという「答え」を具体的なドキュメントに落とし込み、ユーザーに理解してもらって初めて要件定義は完了します。
ユーザーとベンダーの間で十分すぎるくらいにコミュニケーションを取りながら、ポイントを押さえた要件定義を行って、システム開発プロジェクトを成功に導きましょう。
お電話・FAXでのお問い合わせはこちら
03-5828-7501
03-5830-2910
【受付時間】平日 9:00~18:00
フォームでのお問い合わせはこちら
この記事を書いた人
Y.M（マーケティング室）
2020年に株式会社コンピュータマネジメントに新卒入社。
CPサイトのリニューアルに携わりつつ、会社としては初のブログを創設した。
現在は「情シス支援」をテーマに、月3本ペースでブログ更新を継続中。
