要件定義とは？要件定義書の記載項目や作成時のコツを解説

「要件定義をどのように進めれば良いかわからない」
「決めないといけないことが多すぎて整理できない」

要件定義はプロジェクトを進める上で基本となる重要なポイントで、プロジェクトの進め方を決めなければ、開発・制作や制作が滞ることが懸念されます。

本記事では、要件定義の概要と進め方、作成時のコツについて解説します。要件定義の進め方に悩んでいる方は、ぜひ参考にしてみてください。

そもそも要件定義とは

要件定義とは、クライアントへのヒアリング調査をもとに、構築するシステムの概要と実現するための方向性・手順を設定することです。

ヒアリング調査をもとに、以下の要点を設定します。

• 構築するシステムの概要
• 制作にかかる予算
• スケジュール
• 作業メンバー
• 作業工程

要件定義は、クライアントの要求を満たした成果物を構築するために欠かせない作業です。またプロジェクトの実行過程で要件定義書を見返すことで、方向性の脱線を防止できます。

要件定義の重要性

システム開発における要件定義は、システム開発プロジェクトの成功を左右するプロジェクトの核となる部分です。

一般的なシステム開発は、以下の流れでおこなわれます。

• 要件定義
• システム設計
• 実装
• テスト

万が一、要件がまとまらないままプロジェクトを開始すると、トラブルにつながる恐れがあります。例えば、設計・実装・テストのいずれかで大規模な修正が入ったり、最終的に納期に間に合わなかったりなどです。

また完成した成果物がクライアントの求めるものとずれているなど、企業の信用問題に発展するケースもあります。クライアントが求める成果物を、決められた期間内に完成させるためには、要件定義でニーズと方向性をすり合わせることが大切です。

そのためにも、十分な準備期間を設けて要件定義をおこなうことが大切です。

「要求定義」との違い

「要件定義」似た言葉として「要求定義」がありますが、こちらはクライアントが解決したい課題、システム導入の目的、欲しい機能など、システム化によって実現したい要求事項を整理する工程です。一方で「要件定義」とは、ユーザー側の要求定義の内容を受けて、それらの要求をどのような方法で実現すべきか定める工程です。

「要求定義」でシステム導入によって実現を希望する内容を明らかにし、「要件定義」でその希望を実現するための方法や手順を定めていく、という順序で進めていきます。

「基本設計」との違い

「基本設計」は、要件定義の内容を受けて、実際にシステムを動かす部分の仕様を決定する工程です。主にユーザーから見える部分（画面や操作方法など）の設計が中心となります。要件定義で決まった「何」を、「どのように」実現するかの大枠を決めるのが基本設計といえます。

最終的な成果物は要件定義書

要件定義の最終的な成果物は、プロジェクトメンバーに共有する資料の他に、要件定義書が挙げられます。要件定義書とは、クライアントの要求とプロジェクトの手順を擦り合わせた結果を記載したもので、開発側が作成するケースが一般的です。

開発作業に着手する前にクライアント側へ提出するため、システムの概要や搭載機能などを詳細に記載する必要があります。またクライアントがシステム開発の専門知識を持っていない場合を想定し、専門用語を避けたり、解説用の資料もあわせて作成したりなどの配慮が求められます。

要件定義の進め方

正確な要件定義を実施するためにも、基本的な進め方を理解しておく必要があります。

要件定義の基本手順は、以下の3ステップです。

1. クライアントから要求をヒアリング
2. 現状把握と分析
3. 課題・目標を明確化する
4. システム全体の構成を明確化する
5. システムに取り入れる機能の要件を定義する
6. 要件定義書を作成

本章では、各工程で押さえておくべき要点を解説します。

ステップ1.クライアントから要求をヒアリング

要件定義の段階でまず行うのは、要求のヒアリングです。一般的にはクライアントとの接点が多い、営業部門が担当します。

ヒアリングでは、「クライアントがどのような業務プロセスを利用しているのか」、「システムによってどのように変化させたいのか」などを聞き出します。

まずはシステムの大枠となる機能をヒアリングし、徐々に詳細な要求へと移行することで、抜け漏れや認識のずれを防止できます。

また、ヒアリングの段階では要求の実現可否をあまり考慮しないことがおすすめです。要求がでそろっていない段階で開発工程を考慮すると、のちに解決策が見つかった場合に、要件を変更する手間が発生するためです。

まずはクライアントの要求を漏れなく収集し、具体的なイメージを完成させるようにしましょう。

ステップ2.現状把握と分析

要求定義が完了したら、現状の把握と分析を行います。具体的には、クライアントからのヒアリングを通じて、現状の問題点やニーズの把握が大切です。

例えば、現在のシステムで困っている点や、今後の改善点、さらにはクライアントが期待する成果物のイメージを明確にすることが求められます。ヒアリングの内容をもとに、現状の課題や不足している機能を特定し、それに基づいて次のアクションを決定しましょう。

現状分析がしっかり行われていないと、後々にプロジェクトの方向性が一致しなくなるケースや、方向性のずれによる手戻りが生じるケースもあります。

この段階でプロジェクトのゴールやクライアントの期待に対する理解を深め、プロジェクトを成功に導く大きなポイントといえます。

ステップ3.課題・目標を明確化する

現状把握と分析を終えたら、開発のための課題と目標を明らかにします。このステップはプロジェクトの方向性を決定し、どのような開発するのかを決定することで方向性のブレをなくすことが目的です。

まず、どのような課題を解決するためにシステムを開発するのかを明らかにします。その上で、目標を設定し、開発のゴールを共有します。

課題や目標が明確になると、プロジェクトチームのメンバー間で共通理解が生まれます。また、計画が途中で変更される可能性があっても、目標が共有されていれば大きな修正が必要になることを防げます。

クライアントとチームが一致した方向を向くことで、スムーズなプロジェクト進行が可能です。このプロセスにより、システム開発における優先順位も明確化され、効率的に進められます。

ステップ4.システム全体の構成を明確化する

システム全体の構成を明確にすることも要件定義の大切なステップです。この段階では、システムを構成する要素やそれぞれの役割を洗い出し、どのような構成要素が必要かを決定します。

システムの構成要素には、利用者が使用するデバイスやシステムが動作する環境が含まれます。例えば、Webサーバーやデータベースなどです。

構成を決定することで、システム開発が目標に適した形で進められます。不要な要素を排除し、システム開発を効率的に進められるように、要件定義の段階で構成を明確にしておきましょう。

これにより、後々の要件漏れや不必要なコストを防ぎ、プロジェクトのスムーズな進行が実現します。

ステップ5.システムに取り入れる機能の要件を定義する

システムの構成要件を確認できたら、システムに必要な機能要件を明らかにしていきます。機能要件とは、システムが提供すべき具体的な機能であり、業務の効率化や問題解決に直結します。

この段階では、現行システムのAsIsモデルと、新しいシステムのToBeモデルを比較し、改善点を洗い出すことが重要です。業務フローを視覚化することによって、システム導入後の効果を予測しやすくなります。

また、機能要件の定義とともに、非機能要件も定義しましょう。先ほども解説した通り、非機能要件はパフォーマンスやセキュリティ、拡張性など、システムの品質に関する要件です。

機能要件と非機能要件を分けて定義することで、システム開発の方針がより明確になり、プロジェクトをスムーズに進行できます。

以下の記事では、要件整理のコツについて紹介しています。ぜひ本記事とあわせて参考にしてみてください。

ステップ6.要件定義書を作成

システムの要件が定まったら、いよいよ要件定義書を作成します。要件定義書にはこれまでに整理した内容に加え、開発スケジュールや予算なども盛り込みます。

また、プロジェクトメンバーの作業スピードやリソースを考慮し、より具体的な要件定義書を目指しましょう。

完成した要件定義書は、社内のみならずクライアント側にも提出します。開発の知識がない人でも理解できるよう専門用語は省き、必要に応じて補足資料の作成が大切です。

要件定義書の構成や内容は、開発するシステムやクライアントのニーズによって異なります。そのためヒアリング結果を考慮し、認識のずれを埋められる要件定義書を目指しましょう。

要件定義書の作成に参考となるサンプル

参考として、官公庁の作成した要件定義書を紹介します。

厚生労働省	「雇用の質」データベース要件定義書
農林水産省	動物検疫支援システム オンライン連携機能構築 システム要件定義書
環境省	浄化槽台帳システムプロジェクト 機能要件定義書

いずれも要件定義書のお手本となるものですので、ぜひ参考にしてみてください。

要件定義書に記載すべき項目

要件定義書に記載すべき項目は以下の通りです。

• システムに関する要件
• 業務要件
• 機能に関する要件
• 非機能に関する要件
• 技術要件
• プロジェクト計画

システムに関する要件

1つ目の記載内容は、要件定義書の要ともなるシステムに関する要件です。開発工程でどのようなシステムを構築するのかや、開発形態などを詳細に記載します。

具体的には以下の内容を盛り込みます。

• システムの基本概要（システム全体の構成図、用途、対象ユーザー）
• システムを開発する目的
• 開発したシステムから得られるメリット
• 使用するプログラミング言語

上記の内容は、システム開発における大枠の部分です。案件を受注する段階で基本項目が完成するため、比較的短期間で作成できます。

業務要件 (As-Is / To-Be)

システム化の対象となる業務の流れを整理します。現状の業務（As-Is）と、システム導入後の理想の業務（To-Be）を対比させることで、システムが解決すべき課題が明確になります。

• 現状の業務フロー (As-Is)：現在の業務手順、課題点
• あるべき業務フロー (To-Be)：システム導入によって実現する新しい業務手順

機能に関する要件

機能に関する要件では、クライアントが成果物に求める機能やレイアウトなどを記載します。

機能に関する要件の内容は、システムの実装工程におけるゴールとなるため、クライアントと発注側に加え、SE（システムエンジニア）の認識がそろうまで調節を繰り返します。

具体的な記載内容は、以下のとおりです。

• レイアウトなどのUI要件
• システム・データの種類
• システムの構造や処理内容
• 外部との連携機能

ただクライアントの要求によっては、上記以外の記載内容が必要になる場合もあります。ヒアリング調査を繰り返し、両者が納得できる機能要件を見つけましょう。

非機能に関する要件

非機能に関する要件とは、システムの機能以外で求められる要件のことを指します。例えば、システムの性能やセキュリティ、保守・運用サービスなどです。

非機能に関する要件は、システム開発において重要度の高い項目ですが、具体的なイメージを持てていないクライアントが多く見られます。

そのため、開発側が積極的にヒアリングを行い、具体的なイメージを描くことが大切です。また、非機能に関する要件はヒアリングを繰り返した場合でも認識のずれが生じやすい傾向があります。

システム開発後のトラブルを防止するためにも、要件定義書に加え追加資料を作成するなどして、クライアントと細かい打ち合わせをしましょう。

技術要件

システム開発に用いる技術や、開発を進める上での前提条件を記載します。

• 開発言語、フレームワーク、データベース
• インフラ環境：サーバー、OS、ネットワーク構成
• 制約条件：利用必須の既存システム、法規制、社内セキュリティポリシーなど

プロジェクト計画

プロジェクトを円滑に進行させるための、体制やスケジュール、予算などを明記します。

• 開発体制：プロジェクトメンバーとそれぞれの役割
• スケジュール：各工程の開始・終了予定日、マイルストーン
• 概算予算：開発にかかる費用の見積もり
• 納品物一覧：成果物として納品するドキュメントやプログラムの一覧

要件定義に必要な3つのスキル

要件定義には、以下の3つのスキルが必要です。

1. クライアントの意図を正しく把握できる
2. 要求内容が実現可能かイメージできる
3. 第三者にも正確に伝わるように要件を文章化できる

それぞれ順番に解説します。

1.クライアントの意図を正しく把握できる

要件定義の出発点は、クライアントの要望を正確に理解することです。ただ話を聞くだけでは不十分であり、クライアントが抱える課題や要望を正確に理解し、必要な情報を引き出す「ヒアリング力」が求められます。

中には、技術的な説明が苦手であったり、伝えたいことがうまく表現できなかったりするクライアントも少なくありません。こうした場合、こちらから積極的に質問を投げかけ、相手の意図を汲み取る姿勢を大切にしましょう。

要件定義は、単に聞き取った内容をそのまま記録する作業ではありません。クライアントの背景や目的、期待する成果物を深く理解し、その情報を元に最適なシステムを設計する必要があります。表面的な要望だけでなく、その背景にあるビジネス課題まで捉えることで、プロジェクトの価値を最大化する提案が可能になります。

2.要求内容が実現可能かイメージできる

クライアントの要望が、技術的に実現可能かどうかを冷静に判断するスキルも極めて重要です。システム開発に関する幅広い知識と豊富な経験に基づき、「できること」と「できないこと」を的確に見極める力が求められます。

よくある失敗例が、安易に「できます」と答えてしまい、開発段階で技術的な問題が多発してプロジェクトが炎上するケースです。要望を実現するための工数やリスクを正確に見積もり、もし実現が難しい場合は、代替案を提示できる判断力がプロジェクトを成功に導きます。

3.第三者にも正確に伝わるように要件を文章化できる

ヒアリングで固めた要件は、誰が読んでも同じように理解できるように「要件定義書」などのドキュメントに落とし込む必要があります。これは、クライアント、開発メンバー、デザイナーなど、プロジェクトに関わる全員の共通認識の土台となります。

専門用語を多用するのではなく、図や表を効果的に使い、誰にとっても分かりやすい文章でまとめる能力が求められます。ここで認識のズレが生じると、後工程で手戻りが発生する大きな原因にもなり得るため、明確で誤解のないドキュメントを作成する力が求められます。

プロジェクトを成功させるための要件定義のコツ

ここでは、プロジェクトを成功させるための要件定義のコツを紹介します。具体的には、以下のようなコツを意識することで、プロジェクトが成功する確率を高められます。

• 5W2Hで要求を正確に引き出す
• 要件定義書と要求定義書のすり合わせ
• クライアントの既存システム・業務を把握する
• 作成した要件定義書をステークホルダーに共有する

コツをしっかりと把握して、スムーズにプロジェクトを進行できるようにしましょう。

5W2Hで要求を正確に引き出す

5W2Hでユーザーの要求を正確に引き出すこともポイントです。5W2Hとは、What・Why・Where・Who・When・How・How muchの観点から必要事項をヒアリング・分析する手法を指します。

この手法を意識すると、内容の抜け漏れや曖昧さを防止でき、ヒアリングの精度が格段に向上します。

5W2Hを活用した質問例は、以下のとおりです。

• What：システムで何を解決するのか
• Why：何のためにシステムを開発するのか・目的は何か
• Where：どの部分にシステムを導入するのか
• Who：誰がシステムを利用・運用するのか
• When：いつまでに開発し導入するのか
• How：どのように課題を解決したいのか
• How much：システム開発の予算はいくらか

すべての質問が5W2Hに置き換えられるとは限りませんが、多くの場面で活用できます。また、クライアントの要求を正確に引き出すためには、こちらから的確な質問を投げることも大切です。

要件定義書と要求定義書のすり合わせ

要件定義書が完成した段階で要求定義書とすり合わせることもポイントです。

要求定義書とは、クライアントが「どのようなシステムを求めているのか」を定義したものです。開発側の観点が盛り込まれず、純粋に「どのようなことを実現したいのか」といったニーズが記載されます。

そこで、要件定義書と要求定義書をすり合わせることで、抜け漏れやずれの把握が可能です。要件定義で定めたプロジェクトが、クライアントのニーズを満たせるかどうかをチェックしましょう。

認識のずれや要求の漏れがあるままプロジェクトを開始すると、手戻りが発生して時間やコストが無駄になる恐れがあります。こうした事態を防ぐためにも、事前にすり合わせをしつつ、クライアントの要求を満たしたシステムになるのかを再確認することが大切です。

クライアントの既存システム・業務を把握する

クライアントの既存システム・業務を把握することも大切なポイントです。

企業の業務は、複数の業務と連携して進められるケースが一般的です。システムも同様で、複数の管理システムが連携して業務をサポートします。

そのため、新たに開発するシステムが既存システム・業務と連携できるよう、事前に調査することが大切です。

しかし、長年利用しているシステムでは、情報のブラックボックス化や知識のある人が部門におらず、調査が難航する恐れもあります。この場合、可能な限り調査を進めつつ、リスクとして現行のシステム開発に盛り込むことが重要です。

要件定義はシステムの開発のみならず、納品後の運用を見据えて必要事項を明確にしましょう。

作成した要件定義書をステークホルダーに共有する

作成した要件定義書は、ステークホルダーにも共有しましょう。

システム開発のプロジェクトでは、設計からシステムの構築、運用までを複数の企業で分担するケースもあります。担当者が変われば伝達した情報が劣化していくように、担当企業が変われば要件の認識にずれが生じる恐れがあります。

作業担当者の認識のずれは、作業の手戻りを引き起こすため、事前に関係者を集めて情報共有を行いましょう。

単に要件定義書を配布するのではなく、クライアント企業の現状やシステム開発の経緯など、バックグラウンドも共有し、担当者間の理解度の溝を埋めることが大切です。

プロジェクト管理ツールならLychee Redmineがおすすめ

Lychee Redmineには、プロジェクトを成功に導くための豊富な機能が備わっています。
各プランで使用できる機能やユーザー数、月額料金は以下の表を参考にしてください。

プラン	月額料金	利用機能
フリー	無料	基本機能 カンバン
スタンダード	900円	基本機能 ガントチャート カンバン ダッシュボード
プレミアム	1,400円	基本機能 ガントチャート カンバン ダッシュボード 工数リソース管理 EVM コスト管理  CCPM
ビジネス［無料トライアルはこちらをお試しできます］	2,100円	基本機能 ガントチャート カンバン ダッシュボード 工数リソース管理 EVM コスト管理 CCPM プロジェクトレポート カスタムフィールド チケット関連図 グループの階層化機能

フリープランは基本機能（ワークフロー・通知設定・ファイル共有・Wiki）とカンバン機能の限定された機能しか利用できませんが、有料プランはガントチャートをはじめさらに多くの機能が利用できます。

有料プランは30日間の無料トライアル期間を提供しているので、リスクなく始められ、その価値を実感できるはずです。ぜひ一度お試しで使い、操作性を確かめてみましょう。

要件定義を行いプロジェクトを成功へ導こう

本記事では、要件定義の意味や必要な項目、良い要件定義書の条件などについて解説しました。

要件定義書が完成してやっと、プロジェクト開発の入り口に立てます。しっかりとクラインとのニーズを要件定義に落とし込み、プロジェクトを成功に導きましょう。

システム開発では、業務効率を上げるプロジェクト管理ツールがおすすめです。中でもLychee Redmineには様々な機能があり、フリープランでガントチャートやカンバンを利用できます。

要件定義書で定義したクライアントへの解決策をLychee Redmineで実現してみてはいかがでしょうか。