プロジェクト管理手法 
「要件定義とは一体どのような用語？」
「どのように要件定義を進めればいいの？」
システム開発の現場でたびたび耳にする要件定義について、上記の疑問をお持ちの方も多いでしょう。
要件定義とは、クライアントのニーズを整理し、構築するシステムの概要と実現するための方向性・手順を設定することを指します。
この記事では、要件定義の概要と進め方、作成時のコツを解説します。
要件定義とは？
ヒアリング調査をもとに、以下の要点を設定します。
- 構築するシステムの概要
- 制作にかかる予算
- スケジュール
- 作業メンバー
- 作業工程
要件定義は、クライアントの要求を満たした成果物を構築するために欠かせない作業です。またプロジェクトの実行過程に要件定義書を見返すことで、方向性の脱線を防止できます。
合わせて読みたい
【初心者必見】要件定義とは？詳細や具体的な進め方を徹底解説
システムエンジニアの現場では必要不可欠な「要件定義」。これからプロジェクトの流れを組み立てるために理解したい方も多いのではないでしょうか。当記事では、要件定義の.....
要件定義はプロジェクト成功の鍵
要件定義は、システム開発プロジェクトの成功を左右する大きな要因です。
一般的なシステム開発は、以下の流れでおこなわれます。
- 要件定義
- システム設計
- 実装
- テスト
万が一、要件がまとまらないままプロジェクトを開始すると、トラブルにつながる恐れがあります。
例えば、設計・実装・テストのいずれかで大規模な修正が入ったり、最終的に納期に間に合わなかったりなどです。
また完成した成果物がクライアントの求めるものとずれているなど、企業の信用問題に発展するケースもあります。
クライアントが求める成果物を、決められた期間内に完成させるためには、要件定義でニーズと方向性をすり合わせることが大切です。
そのためにも、十分な準備期間を設けて要件定義をおこなうことが大切です。
最終的な成果物は要件定義書
要件定義の最終的な成果物は、プロジェクトメンバーに共有する資料の他に、要件定義書が挙げられます。
要件定義書とは、クライアントの要求とプロジェクトの手順を擦り合わせた結果を記載したもので、開発側が作成するケースが一般的です。
開発作業に着手する前にクライアント側へ提出するため、システムの概要や搭載機能などを詳細に記載する必要があります。
またクライアントがシステム開発の専門知識を持っていない場合を想定し、専門用語を避けたり、解説用の資料もあわせて作成したりなどの配慮が求められます。
要件定義書に記載すべき3つの項目
- システムに関する要件
- 機能に関する要件
- 非機能に関する要件
要件定義書の構成や内容は、開発するシステムやクライアントのニーズによっても異なります。
そのためヒアリング結果を考慮し、認識のずれを埋められる要件定義書を目指しましょう。
合わせて読みたい
システム開発の入り口!? 良い要件定義書の条件とは
要件定義書がなければシステム開発は始まりません。本当にクライアントのニーズに答えられる要件定義書とは何なのでしょうか。要件定義書に必要な項目や記載するときのポイ.....
1.システムに関する要件
1つ目の記載内容は、要件定義書の要とも言うべきシステムに関する要件です。
開発工程でどのようなシステムを構築するのか、また開発形態などを詳細に記載します。
具体的には、以下5つの内容を盛り込みます。
- システムの基本概要
- システムを開発する目的
- 開発したシステムから得られるメリット
- 使用するプログラミング言語
- システム導入後の業務の変化
上記の内容は、システム開発における大枠の部分です。
案件を受注する段階で基本項目が完成するため、比較的短期間で作成できるでしょう。
2.機能に関する要件
機能に関する要件では、クライアントが成果物に求める機能やレイアウトなどを記載します。
機能に関する要件の内容は、システムの実装工程におけるゴールとなるため、クライアントと発注側に加え、SE（システムエンジニア）の認識がそろうまで調節を繰り返します。
具体的な記載内容は、以下のとおりです。
- レイアウトなどのUI要件
- システム・データの種類
- システムの構造や処理内容
- 外部との連携機能
ただクライアントの要求によっては、上記以外の記載内容が必要になる場合もあります。
ヒアリング調査を繰り返し、両者が納得できる機能要件を見つけ出すと良いでしょう。
3.非機能に関する要件
非機能に関する要件とは、システムの機能以外で求められる要件のことを指します。
たとえば、システムの性能やセキュリティ、保守・運用サービスなどです。
非機能に関する要件は、システム開発において重要度の高い項目ですが、具体的なイメージを持てていないクライアントが多く見られます。
そのため、開発側が積極的にヒアリングをおこない、具体的なイメージを描くことが大切です。
また非機能に関する要件は、ヒアリングを繰り返した場合でも認識のずれが生じやすい傾向があります。
システム開発後のトラブルを防止するためにも、要件定義書に加え追加資料を作成するなどして、クライアントと細かい打ち合わせをすると良いでしょう。
要件定義の進め方
要件定義書の基本手順は、以下の3ステップです。
- クライアントから要求をヒアリング
- 要求を細分化して整理する
- 要件定義書を作成
本章では、各工程で押さえておくべき要点を解説します。
ステップ1.クライアントから要求をヒアリング
まずおこなうのは、要求のヒアリングです。
一般的にはクライアントとの接点が多い、営業部門が担当します。
ヒアリングでは、「クライアントが現状どのようなプロセスで業務をこなしているのか」、「システムによってどのように変化させたいのか」などを聞き出します。
まずはシステムの大枠となる機能をヒアリングし、徐々に詳細な要求へと移行することで、抜け漏れや認識のずれを防止できます。
またヒアリングの段階では、要求の実現可否をあまり考慮しないことがおすすめです。
要求がでそろっていない段階で開発工程を考慮すると、のちに解決策が見つかった場合に、要件を変更する手間が発生するためです。
まずはクライアントの要求を漏れなく収集し、具体的なイメージを完成させることに尽力すると良いでしょう。
ステップ2.要求を細分化して整理する
続いてクライアントの要求を、実際に搭載する機能レベルにまで細分化し、要件へと転換させます。
ただし要求の中には、実現が難しいものや実現できない項目もあるはずです。
そのため細分化する段階で、それぞれに優先順位をつけることが大切です。
一般的なシステム開発では、クライアントの要求を「必須要件」と「希望要件」の2種類に分類します。
前者は文字どおり、必ずシステムへ盛り込む要件で、後者は可能であれば盛り込む要件のことです。
このように要求を細分化し、優先順位をつけることで、クライアントのニーズを満たしつつ現実的に開発が可能なシステム像を明確にできるでしょう。
ステップ3.要件定義書を作成
システムの要件が定まったら、いよいよ要件定義書を作成します。
要件定義書にはこれまでに整理した内容に加え、開発スケジュールや予算なども盛り込みます。
またプロジェクトメンバーの作業スピードやリソースを考慮し、より具体的な要件定義書を目指しましょう。
完成した要件定義書は、社内のみならずクライアント側にも提出します。
開発の知識がない人でも理解できるよう専門用語は省き、必要に応じて補足資料を作成することが大切です。
プロジェクトを成功させるための要件定義のコツ
滞りなく開発作業を進めるためにも、以下4つのポイントを抑え要件定義をおこないましょう。
- 5W2Hで要求を正確に引き出す
- 要件定義書と要求定義書のすり合わせ
- クライアントの既存システム・業務を把握する
- 作成した要件定義書をステークホルダーに共有する
合わせて読みたい
要件定義とは？失敗しないためのポイントとツールを詳しく解説
要件定義を失敗したくない方に向けて、要件定義のポイントやおすすめツールを解説。要件定義はシステム開発における要とも呼べる存在です。この記事を参考に要件定義のポイ.....
5W2Hで要求を正確に引き出す
1つ目のポイントは、5W2Hでユーザーの要求を正確に引き出すことです。
5W2Hとは、What・Why・Where・Who・When・How・How muchの観点から必要事項をヒアリング・分析する手法を指します。
この手法を意識すると、内容の抜け漏れや曖昧さを防止でき、ヒアリングの精度が格段に向上します。
5W2Hを活用した質問例は、以下のとおりです。
- What：システムで何を解決するのか
- Why：何のためにシステムを開発するのか・目的は何か
- Where：どの部分にシステムを導入するのか
- Who：誰がシステムを利用・運用するのか
- When：いつまでに開発し導入するのか
- How：どのように課題を解決したいのか
- How much：システム開発の予算はいくらか
すべての質問に5W2Hが当てはまるわけではありませんが、多くの場面で活用できるでしょう。
またクライアントの要求を正確に引き出すためには、こちらから的確な質問を投げることも大切です。
そのためヒアリングの内容を記録し、次回のプロジェクトに活かしていくと良いでしょう。
要件定義書と要求定義書のすり合わせ
2つ目のポイントは、要件定義書が完成した段階で要求定義書とすり合わせることです。
要求定義書とは、クライアントが「どのようなシステムを求めているのか」を定義したものです。
開発側の視点が盛り込まれていないため、純粋なニーズ（Want〜したい）が記載されます。
要件定義書と要求定義書をすり合わせることで、抜け漏れやずれを把握できます。
万が一認識のずれや要求の漏れがあるままプロジェクトを開始すると、手戻りが発生して時間やコストが無駄になる恐れがあります。
こうした事態を防ぐためにも、事前にすり合わせをおこない、クライアントの要求を満たしたシステムになるのかを再確認してください。
クライアントの既存システム・業務を把握する
3つ目のポイントは、クライアントの既存システム・業務を把握することです。
企業の業務は、複数の業務と連携して進められるケースが一般的です。
システムも同様で、複数の管理システムが連携して業務をサポートします。
そのため、新たに開発するシステムが既存システム・業務と連携できるよう、事前に調査することが大切です。
しかし、長年利用しているシステムでは、情報のブラックボックス化や知識のある人が部門におらず、調査が難航する恐れもあります。
この場合、可能な限り調査を進めつつ、リスクとして現行のシステム開発に盛り込むことが重要です。
要件定義はシステムの開発のみならず、納品後の運用を見据えて必要事項を明確にしましょう。
作成した要件定義書をステークホルダーに共有する
4つ目のポイントは、作成した要件定義書をステークホルダーにも共有することです。
システム開発のプロジェクトでは、設計からシステムの構築、運用までを複数の会社で分担するケースもあります。
担当者が変われば、伝達した情報が劣化していくように、担当会社が変われば、要件の認識にずれが生じる恐れがあります。
作業担当者の認識のずれは、作業の手戻りを引き起こすため、事前に関係者を集めて情報共有をおこないましょう。
単に要件定義書を配布するのではなく、クライアント企業の現状やシステム開発の経緯など、バックグラウンドも共有し、担当者間の理解度の溝を埋めることが大切です。
要件定義をおこないプロジェクトを成功へ導こう
要件定義とは、クライアントへのヒアリング調査をもとに、構築するシステムの概要と実現するための方向性・手順を設定することです。
成果物の品質を確保しつつ、作業の手元りやトラブルを回避するために欠かせない業務です。
基本的な進め方は、以下のとおりです。
- 要求をヒアリング
- 要求を細分化して整理する
- 要件定義書を作成
要件定義の内容は、クライアントの要求や開発するシステムによって大きく異なります。
そのため本記事で解説した4つのポイントを押さえ、システム開発のプロジェクトを成功へ導いてください。
プロジェクト管理手法
仕事効率化・生産性アップ
Redmine
調査レポート
Lychee Redmine活用
Lychee Redmine活用
仕事効率化・生産性アップ
