目次
ウォーターフォールで要件定義は大切
ウォーターフォールで要件定義が大切なのは前の記事で説明した通りです。
でもじゃあ要件定義はどうやって正確にやるのさ？を解説します。
概要
要件定義を正確に行うには、プロジェクトの最初に十分なコミュニケーションを行い、顧客や関係者のニーズを的確に理解することが重要です。以下のステップを踏むと、より正確な要件定義ができる可能性が高まります。
1. 関係者と徹底的なヒアリングを行う
目的: 顧客や関係者が本当に求めていることを引き出すため。
方法:
ヒアリングシートを事前に用意し、具体的な質問を準備する。
使いたい機能だけでなく、解決したい問題や達成したいゴールを明確にする。
利用シーンやターゲットユーザーについても詳しく聞き取る。
2. 現状分析と課題の整理
目的: 顧客が抱える現在の問題や課題を具体的に理解すること。
方法:
顧客の業務プロセスやシステムの現状を把握し、問題点を洗い出す。
ユーザビリティやパフォーマンス、拡張性など、現状で不足している要素を整理する。
顧客の希望が明確に反映されるよう、優先順位をつけたリストを作成する。
3. ユーザー視点で要件を具体化する
目的: 顧客やユーザーにとって必要な機能や使いやすさを明確にする。
方法:
ユーザーが実際にどう操作するかを想定し、ユーザーストーリーやユースケース（利用シナリオ）を作成する。
それぞれのシナリオに沿った要件を洗い出すことで、具体的な機能が見えてきます。
4. 非機能要件の確認
目的: システムの品質面や技術的要件を正確に定めること。
方法:
パフォーマンス要件（レスポンス速度や同時アクセス数など）、セキュリティ要件（アクセス制限やデータ保護など）、運用要件（保守や障害対応など）を具体的に確認。
こうした非機能要件も明確にすることで、後からの変更を防ぐことができます。
5. モックアップやプロトタイプの作成
目的: 実際の画面イメージや操作感を共有し、要件の認識を一致させるため。
方法:
画面のモックアップや、簡易プロトタイプを作成して、顧客に確認してもらう。
これにより、具体的な画面や操作を通じて要件が正確かどうかを検証し、見落としや誤解を防ぐことができます。
6. 要件確認と合意（ドキュメント化）
目的: 要件を明文化し、関係者全員が同じ認識を持つこと。
方法:
要件定義書を作成し、全ての関係者にレビューと確認を依頼する。
署名や承認を得ることで、要件の範囲を確定し、後からの変更リスクを最小化します。
7. スコープ管理
目的: プロジェクトの途中で要件がぶれないようにするため。
方法:
追加要件や変更が必要な場合、必ず影響範囲とコスト、スケジュールを考慮し、関係者の合意を得る。
変更管理のプロセスを事前に設定しておくと、要件定義がずれるリスクを低減できます。
これらのプロセスを丁寧に行うことで、要件定義がより正確で顧客の期待に合ったものとなり、プロジェクトがスムーズに進行しやすくなります。
ポイント さすがに要求が多すぎ・大きすぎで手に余る場合
客「ここにNetflixみたいなサイトがありますよね」
開発「はい」
客「このサイトにYoutube liveやTwitchみたいなLive配信機能をつけてください！」
開発「え！？」
開発「（難易度高過ぎワロタ）」
こういうデカい機能、もしくは難易度は高くなくてもたくさんの要求をもらうことはあります。こういう場合、その要求をフェイズに分け、扱い安いようにしましょう。
例えば「Live機能を追加する」に関しては、例えば元々内部ユーザ（社内の人間）だけに公開（一般には非公開）、有料ユーザだけに動画を公開する機能（非有料ユーザには非公開）があるとしましょう。
この既存機能を使用して次のようにフェイズが分けられます。
フェイズ1 内部ユーザ限定でベータ版Live機能公開
フェイズ2 有料ユーザ限定でLive機能を公開
フェイズ3 全ユーザにLive機能を公開
このとき、仮に新機能であるLive機能に問題があっても、フェイズ1でその問題があぶり出せれば、最終目標であるフェイズ3が始まるまでに修正が可能です。
こういうふうに段階的やり方で進めるとプロジェクトが扱い安くなりますよ。
