要件コレクション

前書き

あらゆるタイプのプロジェクトに関しては、要件の収集が重要な役割を果たします。要件の収集は、プロジェクトにとって重要であるだけでなく、プロジェクト管理機能にとっても重要です。

プロジェクトにとって、プロジェクトが最終的に何を提供するかを理解することは、プロジェクトの成功にとって重要です。要件を通じて、プロジェクト管理者は、プロジェクトの最終納品と、最終納品がクライアントの特定の要件にどのように対処するかを決定できます。

要件の収集は非常に簡単に見えますが、驚くべきことに、これはほとんどのプロジェクトが間違った足で始まるプロジェクトフェーズの1つです。一般に、失敗したプロジェクトの大部分は、要件の収集が間違っているか不十分なために失敗しています。これについては、次のセクションで説明します。

以下は、要件コレクションがプロジェクトのどこにあるかを示す図です。

要件の重要性

例としてソフトウェア開発プロジェクトを取り上げましょう。プロジェクトの開始が終了すると、ビジネスアナリストチームは要件の収集を急いでいます。BA（ビジネスアナリスト）チームは、さまざまな方法を使用してプロジェクト要件を取得し、その要件をプロジェクトチームに渡します。ビジネス要件が技術要件に変換されると、実装が開始されます。

上記のサイクルは非常に正常で問題がないように見えますが、実際は多少異なります。ほとんどの場合、BAチームはプロジェクトに関連するすべての要件を把握することはできません。彼らは常に要件の一部を見落としています。プロジェクトの構築中に、通常、クライアントはプロジェクトの要件のギャップを認識します。

プロジェクトチームは、追加のクライアントへの支払いやクライアントが承認した変更要求なしで、これらの不足している要件を実装する必要があります。BAチームの過失である場合、サービスプロバイダーは、不足している要件を実装するためのコストを負担しなければならない場合があります。このような場合、要件を満たしていないための努力がプロジェクトのコストに大きな影響を与える場合、プロジェクトはサービスプロバイダーにとって経済的損失となる可能性があります。

したがって、要件収集プロセスは、プロジェクトの最も重要なフェーズです。

要件収集のプロセス

要件収集の目的で、ビジネスアナリストが使用する方法がいくつかあります。これらの方法は通常、プロジェクトごとに、またクライアント組織ごとに異なります。

通常、新しいシステムの要件は、システムの潜在的なエンドユーザーから収集されます。これらの潜在的なエンドユーザーから要件を収集するために使用される方法は、エンドユーザーの性質によって異なります。例として、エンドユーザーが多数いる場合は、ワークショップ方式を要件収集に使用できます。

この方法では、すべての潜在的なエンドユーザーがワークショップに参加するように求められます。このワークショップでは、ビジネスアナリストがユーザーと関わり、新しいシステムの要件を収集します。ワークショップセッションは、ユーザーのフィードバックを確認およびキャプチャするためにビデオ録画される場合があります。

ユーザーベースが非常に少ない場合、ビジネスアナリストは対面インタビューを実行できます。これは、ビジネスアナリストがすべての質問をしたり、相互に質問したりできるため、必要なすべての要件を見つけるための最も効果的な方法です。

質問者は要件収集プロセスに効果的に使用できますが、これがエンドユーザーと対話する唯一の方法ではありません。質問者は、インタビューやワークショップのサポート機能として使用する必要があります。

上記の方法に加えて、特定の条件に使用できる他の多くの特定の方法があります。

要件収集を成功させるためのヒント

以下は、要件収集プロセスを成功させるためのヒントの一部です。

顧客の要件を知っていると思い込まないでください。あなたが通常考えることは、顧客が望んでいることとはかなり異なる可能性があります。したがって、思い込みや疑問がある場合は、必ずお客様に確認してください。
最初からエンドユーザーを関与させます。あなたがしていることに対する彼らのサポートを得る。
初期レベルでは、スコープを定義し、顧客の同意を得ます。これは、機能の範囲にうまく集中するのに役立ちます。
要件を収集する過程で、要件が現実的で、具体的で、測定可能であることを確認してください。
要件ドキュメントを明確にすることに重点を置きます。要件文書は、クライアントとサービスプロバイダーを合意に導く唯一の方法です。したがって、このドキュメントには灰色の領域があってはなりません。灰色の領域がある場合は、これが潜在的なビジネス上の問題につながると考えてください。
すべての要件が収集されるまで、ソリューションやテクノロジーについてクライアントに話さないでください。要件が明確になるまで、クライアントに何かを約束したり示したりする立場にはありません。
他のプロジェクトフェーズに進む前に、クライアントによって承認された要件ドキュメントを入手してください。
必要に応じて、要件を視覚的に説明するためのプロトタイプを作成します。

結論

要件の収集は、プロジェクトの最も重要なステップです。プロジェクトチームがソリューションに必要なすべての要件を把握できなかった場合、プロジェクトはリスクを伴いながら実行されます。これにより、将来的に多くの紛争や意見の不一致が生じる可能性があり、その結果、取引関係が著しく損なわれる可能性があります。

したがって、要件の収集をプロジェクトチームの主要な責任として受け止めてください。要件が承認されるまで、ソリューションの性質について約束したりコメントしたりしないでください。