システムやソフトウェア、Webサイトの開発において非常に重要なプロセスである要件定義ですが、
要件定義がまとまらず次のステップに進めない、時間がかかりすぎてプロジェクトが頓挫してしまった、という話をよく耳にします。
せっかく立ち上げたプロジェクトですし、それまでに費用も工数も掛けています。是非とも成功させたいですよね。
本記事では要件定義がまとまらず困っているシステム開発部門のプロジェクトマネージャーの方へ向けて解決方法を解説していきます。
また、プロジェクトにおいては開発側とユーザー側、双方の協力が必須です。
ユーザー部門の担当者の方にもプロジェクトを円滑に進めるためのポイントとして参考にしていただければ幸いです。
目次
要件定義はなぜまとまらない？
はじめに、どのような場合に要件定義がまとまらないのか、よくある事例を書き出してみます。
- ユーザー側から『要求と違うものが作られている』とクレームが入る
- 要件定義の進行中に考慮漏れが発覚し、やり直しになる
- 最終的にユーザー側が決定してくれない
- 要件定義後期で最終決裁者がNoを出した
どうでしょうか。
近しいご経験や思い当たることがありましたでしょうか。
これらの課題はそれぞれ下記の方法で解決できます。
- 要求と要件は違うことを理解する
- 5W2Hを意識して要求を書き出す
- ゴールを明確に決めておく
- 会議体、進め方、決裁者を決めておく
次の章では各解決策について具体的に解説していきます。
要求定義を整理するための解決策
１．要求と要件は違うことを理解する
まず、ユーザー側から『要求と違うものが作られている』とクレームが入るケースについて見ていきます。
当然のことながら、ユーザー側の気持ちとして「予算内でより多くの要求を実現したい」というニーズがあります。
しかし要件定義はユーザー側のてんこ盛りになった要求を必要なものだけに絞り込み、シンプルなものに変換する工程なのです。
プロジェクトにおける要求と要件の違いについてわかりやすく下図に表しました。
| 意味 | 定義する目的 | |
| 要求 | システムがユーザーに求める仕様 | ユーザーの視点からシステムの概要を具体化する |
| 要件 | 開発者がシステムを構築するための仕様 | 開発者の視点から必要な機能や非機能をわかりやすくまとめる |
要件はシンプルであるほどプロジェクトの成功率は高くなります。その事実をユーザー側にも理解しておいてもらうことも重要です。
要求と要件の違いについてはこちらの記事も参考にしてください。
２．5W2Hを意識して要求を書き出す
次に、要件定義の進行中に考慮漏れが発覚し、やり直しになるケースについて見ていきます。
考慮漏れは、ユーザー側と開発側のコミュニケーション不足や認識齟齬から生まれます。
これらを解決するためにはユーザー側の要求を開発側が「明確に文書化し共有すること」が重要です。
明確に文書化するためには下図の5W2Hを意識しましょう。
| 5W | When(いつ) | 課題解決をいつまでに行うか |
| Where(どこで) | どこを対象にするのか | |
| Who(誰が) | 課題解決に誰の協力が必要か | |
| What(何を) | 解決すべき課題は何か | |
| Why(なぜ) | なぜ課題解決したいのか | |
| 2H | How(どのように) | どのように課題を解決するか |
| How much(どのくらい) | 課題解決にどのくらい予算がいるのか |
文書化したものを確認しながらユーザー側と仕様を詰めていきます。
書いていない事項はシステム化されないこともユーザー側に伝えておくことも重要です。
３．ゴールを明確に決めておく
続いて、ユーザー側が最終的に決定してくれないケースについて見ていきます。
要件定義工程は「要件定義書にユーザー側と開発側が共に合意すること」で完了します。
要件定義書に記載される内容は「ユーザー側が考えるゴール」ですが、要件定義書を作成するのは開発者側です。
ここに要件定義の難しさがあります。
そもそもユーザー側がゴールについて共通認識を持てていない場合、開発者側がいくら要件をまとめてもユーザー側は落としどころが分からないという状態です。
また、開発側がユーザーが考えるゴールについて理解できていない場合は、ユーザー側が「要求と違う」と感じてしまうでしょう。
このようなことを回避するためには、ユーザー側が考えるゴールを「プロジェクトを立ち上げる目的」として
「ビジネス要求」「ステークホルダー要求」「ソリューション要求」「移行要求」といった内容を文書に落とし込み、ユーザー側と事前に合意しておく必要があります。
| ビジネス要求 | 企業の目的および目標またはニーズを概要レベルで表現した要求 | |
| ステークホルダー要求 | 特定のステークホルダーや特定のステークホルダーのクラスのニーズについて表現した要求 | |
| ソリューション要求 | ビジネス要求やステークホルダー要求に適合するソリューションの特徴について記述下要求 | |
|
・ソフトウェアソリューションの場合 |
機能要求 | ソリューションがマネジメントする振る舞いと情報を記述した要求 |
| 非機能要求 | ソリューションの振る舞いまたは機能性に直接には関係しない条件を把握し、ソリューションが有効に存続するための環境的条件や、システムが備えているべき品質について記述した要求 | |
| 移行要求 | 現在の状態から、企業の望む未来の状態への移行を円滑に進めるために、ソリューションが備えておくべき能力を記述した要求 | |
参照：BABOK概要と最新動向～BAが日本を変える～ P29.要求の分類
このステップを踏むことによりユーザー側の決裁者も考えを整理することができ、決定しやすくなるでしょう。
さらにユーザー側と開発側でイメージの共有が可能になるため、同じゴールを目指すことが可能になります。
４．会議体、進め方、決裁者を決めておく
最後に解説するのは、要件定義後期になって真の決裁者が現れ、これまで詰めてきた仕様を覆され振り出しに戻るケースです。
これを防ぐためには真の決裁者が誰なのかということを事前に決めておく必要があります。
また、プロジェクトの会議体や進め方、コミュニケーションルールについてもユーザー側と事前に合意しておくと良いでしょう。
決めておくべきルールについては下図を参考にしてください。
| 会議体 | 呼称(キックオフ会議、進捗会議など) |
| 出席者 | |
| 会議目的 | |
| 開催頻度 | |
| 進め方 | ファシリテーター |
| 多数決の有効性、最終決定者など | |
| ブレーンストーミング法の活用など | |
| コミュニケーションルール | 議事録作成・通知方法のルール |
| メールのルール(件名の設定方法など) | |
| 利用するプロジェクト管理ツールと運用ルール |
まとめ
本記事では要件定義を整理するための解決方法について解説してきました。
要件定義はプロジェクトの成功を握る重要な工程ですが、多くのプロジェクトマネージャーが難しいと感じる難関でもあります。
IT人材教育研修QualityRoomではプロジェクト成功のヒントとなるようなブログ記事を掲載していますが、
プロジェクトメンバーのIT専門知識を高めることがプロジェクト成功の近道と考えているからです。
更なる近道としてはプロジェクトメンバーへのIT研修をおすすめします。
QualityRoomは、様々な業界をサポートしてきたITコンサルタントが監修するIT研修をご用意しています。
画一的な研修ではなく、企業様にヒアリングを行い、課題に合わせた研修をご提供致します。
また、IT初心者からプロジェクト推進者、経営層までITレベルやポジションに合わせた教育が可能です。
知識は活用、継承ができるため、現行プロジェクトだけでの活用ではなく企業の資産となり得ます。
IT人材育成研修QualityRoomをぜひご活用ください。
製造業で10年ほど品質管理、品質保証を経験したのち、IT業界にキャリアチェンジ。
業務IT化や、IT人材育成についてなど、IT業界以外の方にもわかりやすい記事を書くことを心掛けています。
メルマガ登録
