Management-concepts-requirement-collection
要件の収集
前書き
あらゆるタイプのプロジェクトに関しては、要件の収集が重要な役割を果たします。 要件の収集は、プロジェクトにとって重要なだけでなく、プロジェクト管理機能にとっても重要です。
プロジェクトにとって、プロジェクトが最終的に何を提供するかを理解することは、その成功のために重要です。 要件を通じて、プロジェクト管理者は、プロジェクトの最終納品と、最終納品がクライアントの特定の要件にどのように対処すべきかを決定できます。
要件の収集は非常に簡単に見えますが、驚くべきことに、これはほとんどのプロジェクトが間違った足から始まるプロジェクト段階の1つです。 一般に、失敗したプロジェクトの大部分は、要件の収集が間違っているか不十分であるために失敗しています。 これについては、次のセクションで説明します。
以下は、プロジェクト内の要件コレクションの場所を示す図です。
要件の重要性
例としてソフトウェア開発プロジェクトを取り上げましょう。 プロジェクトの開始が終了すると、ビジネスアナリストチームは急いで要件を収集します。 BA（ビジネスアナリスト）チームは、さまざまな方法を使用してプロジェクト要件をキャプチャし、プロジェクトチームに要件を渡します。 ビジネス要件が技術要件に変換されると、実装が開始されます。
上記のサイクルは非常に正常で問題のないように見えますが、現実は多少異なります。 ほとんどの場合、BAチームはプロジェクトに関連するすべての要件を把握できません。 彼らは常に要件の一部を見落としています。 プロジェクトの構築中、通常、クライアントはプロジェクトの要件のギャップを認識します。
プロジェクトチームは、これらの不足している要件を、追加のクライアント支払いやクライアント承認の変更要求なしで実装する必要があります。 BAチームの責任である場合、サービスプロバイダーは、不足している要件を実装するためのコストを負担しなければならない場合があります。 そのような場合、要件を満たさないための努力がプロジェクトのコストに大きな影響を与える場合、そのプロジェクトはサービスプロバイダーにとって金銭的な損失になる可能性があります。
したがって、要件収集プロセスは、プロジェクトの最も重要な段階です。
要件収集のプロセス
要件収集の目的で、ビジネスアナリストが使用する方法がいくつかあります。 これらの方法は通常、プロジェクトごとに、クライアント組織ごとに異なります。
通常、新しいシステムの要件は、システムの潜在的なエンドユーザーから収集されます。 これらの潜在的なエンドユーザーから要件を収集するために使用される方法は、エンドユーザーの性質によって異なります。 例として、エンドユーザーが多数いる場合は、要件の収集にワークショップ方式を使用できます。
この方法では、すべての潜在的なエンドユーザーがワークショップに参加するように求められます。 このワークショップでは、ビジネスアナリストがユーザーと連携し、新しいシステムの要件を収集します。 ワークショップセッションは、ユーザーのフィードバックを確認してキャプチャするために録画されることがあります。
ユーザーベースの数が非常に少ない場合、ビジネスアナリストは対面インタビューを行うことができます。 これは、ビジネスアナリストがすべての質問を尋ねたり、相互質問することもできるため、必要なすべての要件を見つける最も効果的な方法です。
質問者は要件収集プロセスに効果的に使用できますが、これはエンドユーザーと対話する唯一の方法ではありません。 質問者は、インタビューやワークショップのサポート機能として使用する必要があります。
上記の方法に加えて、特定の条件に使用できる他の多くの特定の方法があります。
要件収集を成功させるためのヒント
要件収集プロセスを成功させるためのヒントの一部を次に示します。
- 顧客の要件を知っていると思い込まないでください。 あなたが通常考えるものは、顧客が望むものとはかなり異なる可能性があります。 したがって、仮定や疑問がある場合は常に顧客に確認してください。
- 最初から関係するエンドユーザーを取得します。 あなたが何をするかについて彼らのサポートを得る。
- 初期レベルで、範囲を定義し、顧客の同意を得ます。 これにより、機能の範囲に集中することができます。
- 要件を収集しているときは、要件が現実的で、具体的で、測定可能であることを確認してください。
- 要件を明確に文書化することに焦点を当てます。 要件文書は、クライアントとサービスプロバイダーを合意に導く唯一の方法です。 したがって、このドキュメントに灰色の領域が存在しないようにする必要があります。 灰色の領域がある場合、これが潜在的なビジネス上の問題につながることを考慮してください。
- すべての要件が収集されるまで、ソリューションまたはテクノロジーについてクライアントに話さないでください。 要件について明確になるまで、クライアントに何かを約束したり指示したりする立場にはありません。
- 他のプロジェクトフェーズに進む前に、クライアントが要件文書を承認します。
- 必要に応じて、プロトタイプを作成して、要件を視覚的に示します。
結論
要件の収集は、プロジェクトの最も重要なステップです。 プロジェクトチームがソリューションに必要なすべての要件を把握できなかった場合、プロジェクトはリスクを伴い実行されます。 これにより、将来多くの紛争や意見の相違が生じる可能性があり、その結果、ビジネス関係が深刻なダメージを受ける可能性があります。
したがって、プロジェクトチームの主要な責任として要件の収集を行います。 要件が承認されるまで、ソリューションの性質について約束したりコメントしたりしないでください。
