要件管理について知っておくべきすべてのこと

金曜日の夜、あなたはピザを注文しようとしています。片手には携帯電話、反対の手には友達からのリクエストのリストを掴んでいます。しかし、まずはみんなの好みを考慮して、どんなピザを注文するか決めなければなりません。サラミ？チーズ？ベジタリアン？

何やら、ピザの注文が、最新の製品リリースのための要件管理に似ている気がしてきました。同様に、要件管理では、利害関係者の声に耳を傾け、彼らのニーズに応える最善の方法を理解することがすべてなのです。

要件管理とは？

要件管理は、プロジェクトの最終成果物が顧客や社内の利害関係者のニーズを満たすことを確認する方法です。この場合、要件とは、利害関係者が製品に求めるもの、または必要とするもののことです。利害関係者は、社内 (他部門のパートナーなど) であることもあれば、社外 (顧客やクライアントなど) であることもあります。

要件管理は、ソフトウェア製品や機能の開発に携わる開発チームで最もよく使用されますが、より一般的にプロジェクト管理にも適用可能です。たとえば、顧客が製品をうまく使用できるようにするための機能や、他部門のパートナーがビジネス目標を達成するための、製品や製品の特定の側面などが要件となりえます。

製品の開発に着手する前に、利害関係者が必要とするものを確実に提供するために、正確な要件について話し合い、合意する必要があります。要件管理は、プロジェクトのライフサイクルを通じて、要件の文書化と優先順位付け、変更点の追跡、利害関係者との連携に役立ちます。また、変化していく要件を管理し、プロジェクトがスコープ内に収まるようにする助けにもなります。

要件とは？

要件とは、ある機能または製品を完成させるために、実行する必要のあるコンポーネントのことです。言い換えれば、利害関係者のニーズを満たすために、製品が備えているべき、あるいは行うべきことです。ソフトウェア製品には、要件が何百も存在するかもしれません。しかし、製品に要件がいくつあるかにかかわらず、すべての要件は以下のような条件を持ち合わせます。

• 必要: ビジネス目標あるいは製品目標の達成のために、この要件が必要である。

• 具体的: 要件は詳細に定められていて、目的が明確である。

• 理解しやすい: 要件は明確に書かれていて、簡単に理解できる。

• 正確: その要件が対処すべき課題や必要性について、正確な情報が十分に備わっている。つまり、単に何をすべきかを記述するのではなく、なぜその要件が大切なのかを明確にする必要がある。

• 実現可能: 現在のテックスタックとコードインフラストラクチャで実現できることを確認するために、要件を調査する必要がある。

• テスト可能: ユーザーテスト、A/B テスト、その他の方法で要件をテストできること。

実際の例をご紹介します。あるアプリを作成しているとします。その際に、アプリ全体を英語、中国語、日本語、フランス語に翻訳することが要件の 1 つとなるかもしれません。それは、これらの言語が主要なビジネス市場と合致しているからです。

• この要件は、会社の主要な市場でアプリをリリースし、ビジネス目標を達成するために必要なものです。

• どの言語が必要なのか、そして、アプリ全体を翻訳する必要があると述べているので、具体的です。

• 技術的な詳細には触れず、チームメンバーや他部門の利害関係者が理解できるように書かれているので、理解しやすいです。

• 英語、中国語、日本語、フランス語が会社の主要な市場であり、なぜその要件が重要なのかを明確に述べているため、正確です。

• 他の言語でプロトタイプやテストケースをすでに作っているので、ローカライズが可能で、期待通りのパフォーマンスが得られるとわかっているため、実現可能 です。

• 翻訳された各バージョンの正確さをテストし、確認する体制が整っているので、テスト可能です。

要件管理が重要な理由とは？

優れた製品を生み出すには、要件管理が必要なのです。その理由は以下のとおりです。

• 正しい機能を提供する。ユーザーがどのように製品に接するかを理解することにより、要件管理プロセスは、ユーザーのニーズを定義する役に立ちます。それにより、第一に、顧客の本質的なニーズと成果物を一致させることができるのです。

• ビジネス目標に沿う。要件を文書化し、優先順位をつけるにあたり、各要件がビジネス目標全体に沿ったものであることを確認します。たとえば、アプリを 12 の言語に翻訳するという要件は、国際市場に進出するというビジネス目標をサポートするものです。要件がビジネス目標をサポートしていない場合、リソースを別のどこかに投資する必要があるか、あるいは、その要件が重要だという正当な理由があるという意味でしょう。

• スコープクリープを防ぐ。定義された要件は、プロジェクトのスコープとして機能します。境界を設定し、どのような目標と成果物に向かって仕事していくのかを正確に決めてくれます。事前に要件を定義しておくことで、障害となる可能性のあるものを特定し、利害関係者が要件を追加しようとした場合にも、それを押しとどめることができます。

• 障害を避ける。製品の作成とは、ソフトウェア開発、設計、テストはもちろん、複雑なコードスタックやエンジニアリングシステムもあり、複雑なものです。要件管理は、コードスタックの制約の中で製品を開発する方法を計画し、製品開発プロセスの各段階で達成する必要があることを追跡する役に立ちます。

要件管理の責任者は誰か？

要件管理の責任者は、個々のプロジェクトやチームによって異なります。しかし通常、開発チームの要件を管理するのは、プロダクトオーナーまたはプロダクトマネージャーです。この 2 つの役割は似ていますが、プロダクトオーナーがスクラムチームの標準的な役割であるのに対し、プロダクトマネージャーは、チームがアジャイル手法を使用しているかどうかに関わらず、より普遍的な役割です。製品開発ではなく、より一般的なプロジェクトに取り組んでいる場合、プロジェクトマネージャーが要件管理を担当します。

要件管理では、チームとプロジェクトの利害関係者の間で、部門横断的なコラボレーションが必要です。利害関係者からフィードバックを収集し、彼らと協力して各要件を理解し、各要件にどう対応するか、チームが計画するのを支援する必要があります。つまり、そのすべての中心となるプロジェクトの要件管理の担当者は、強力なコラボレーション能力を持ち、部門横断的なコミュニケーションに秀でた人であるべきなのです。

要件のさまざまな種類とは？

要件には大きく分けて、ビジネス要件、ユーザー要件、システム要件の 3 種類があります。仕事に着手する前にさまざまな種類の要件を定義することが大切なのは、それにより、どのような利害関係者とのコラボレーションが必要かが決まるからです。

これらのさまざまな種類の要件の概要は、以下のとおりです。

ビジネス 要件

ビジネス要件とは、製品が提供する、全体的なビジネス目標や評価基準のことです。製品がしなければならないことに限らず、社内外の利害関係者を満足させるために、ビジネスがする必要のあることです。

たとえば、オンライン通販のビジネスに携わっていて、セールスチームがコンテンツマネジメントシステム (CMS) を使ってウェブサイトの製品ページを作成・更新しているとします。在庫の増加に対応するために、製品チームは CMS の検索機能を強化することにしました。このプロジェクトが合致しているビジネス要件は、「第 1 四半期に製品の在庫を 50% 増加させる」のようになります。

ユーザー要件

ユーザー要件とは、ユーザーが製品に何を求め、どのように製品に接するかを定義するものです。ユーザーが困っていること、達成したいアクション、そして、そのユーザーが困っていることをどう解決するか、あるいは、そのアクション達成に、製品がどう役に立つのかを詳細に説明します。

アジャイルチームは通常、ユーザー要件をユーザーストーリーとしてフォーマット化します。ユーザーストーリーとは、エンドユーザーの視点から書かれた、ソフトウェア機能の非公式な説明です。ユーザーストーリーは、「[ペルソナ]として、[ソフトウェア目標]を達成し、[結果]を得たい」という形式をとります。

ここで、先ほどの CMS の例に戻りましょう。ここでは、エンドユーザーの視点で書かれたユーザーストーリーの例を紹介します。この例では、CMS を使用して業務を遂行するセールス担当者です。

「セールス担当として、CMS で特定の商品リストを、簡単に検索して見つけ、増え続けるオンライン在庫を更新・管理できるようにしたい。」

システム要件

システム要件は、製品が何をするかを定義するものです。ユーザー要件がユーザーの視点から製品機能の「なぜ」「何を」のアウトラインを示すのに対し、システム要件はエンジニアリングチームの視点から、その機能を「どのように」構築するかを定義するものだと考えてください。

システム要件は、多くの場合、機能要件と非機能要件に分けられます。機能要件は製品が何をするかを定義し、非機能要件は製品がどの程度その機能を発揮できるかを定義します。つまり、非機能要件は通常、セキュリティ、パフォーマンス、信頼性に関係したものだということです。

たとえば、エンジニアリングチームは、先述の CMS のユーザー要件を、次のようにシステム要件に分解できます。

機能要件

• 各製品リストには、製品タイプ、作成日、作成者、URL、公開ステータスが保存される。

• ドロップダウンメニューから製品タイプを選択しない限り、新しい製品を作成することはできない。

• 検索バーには、製品タイプ、作成日、作成者、URL、公開ステータスという追加のフィルターを適用するオプションがある。

• 同時に複数のフィルターを選択できる。

非機能要件

• 検索結果は 5 秒以内に表示される。

• 検索結果は 100% 正確なものである。

要件管理プロセスの 6 つのステップ

要件管理は、負担に感じる必要はありません。チームのために標準化されたプロセスを作成すれば、いつどの利害関係者に連絡すればいいか悩むことなく、毎回同じステップを踏むだけでいいのです。

足がかりとして、そのプロセスを 6 つのステップにまとめました。実際に試してみて自分のチームに合った方法を見つけたら、それに従って要件管理プロセスをカスタマイズしてください。

1. 要件を収集する

プロジェクトの要件を定義する前に、まずは要件を収集する必要があります。この段階では、収集した要件がプロジェクトに組み込まれるわけではありません。これは利害関係者や顧客とつながり、彼らのニーズをよりよく知るためのチャンスとなります。

これには、複数のアプローチ方法があります。利害関係者に直接会って、作成中の製品や機能について説明すると共に、彼らの支援やビジネス目標の達成のためにプロジェクトに何を求めているかを尋ねられます。その際に、利害関係者の協力を得て、要件を作成し、彼らのニーズを完全に理解できるのです。また、利害関係者と非同期的なコミュニケーションをとることで、会議の時間を短縮することもできます。さらに、エンドユーザーからの要件を理解する必要がある場合には、ユーザーテストを実施したり、ユーザーリサーチチームに連絡を取ったりする必要があるかもしれません。

このような会話の中で、期待することを利害関係者と共に検討し、彼らが求める要件が必ずしも製品に組み込まれるとは限らないことを理解してもらうようにしましょう。最終的に、どの要件が最も重要で追求すべきか、優先順位をつけたり選択をしたりすることは、あなたとあなたのチーム次第です。

2. 要件を分析する

次に、これらのフィードバックをすべて整理し、どの要件が製品やビジネス目標に合っているかを判断します。最終的にすべての要件は、お客様収益の増加、新しい市場への進出、顧客満足度の向上など、全体的なビジネス目標に貢献する必要があります。

3. 要件を定義する

要件を分析し、目標に合っているものを選び出したら、次は要件を明確に定義して、チームが必要な情報をすべて持っていることを確認します。これにより、製品や機能の完成のために、開発チームが達成すべきすべてのコンポーネントのアウトラインが把握できます。

その方法の 1 つが、要件ごとにユーザーストーリーを作成し、ユーザーが何を必要とし、製品にどう接するかを明確にすることです。そうすると、これらのユーザー要件を、より具体的なシステム要件に分解することができます。その際に、各要件を満たすのに十分な背景情報を確保するために、利害関係者から追加の情報を収集する必要があるかもしれません。

4. 要件を文書化する

要件を文書化して追跡するには、1 つの決まった方法があるわけではありません。皆様の製品チームはこれまで、ソフトウェア要件仕様書 (SRS)、製品要件定義書 (PRD)、要件トレーサビリティマトリクス (RTM) などを使用してきたかもしれません。

しかし、チームがプロジェクトの全要件をリアルタイムで把握するには、Asana などのプロジェクト管理ツールを使ってみてください。つまり、もう古いスプレッドシートを要件として使う必要はなく、その代わりに、チームと利害関係者は、各要件の最新の概要を見ることができるのです。また、プロジェクトに取り組みながら各要件のステータスを追跡したり、進捗があったときに利害関係者に報告する、自動化の設定なども可能です。

また、Asana は、より専門的なアプリや、Jira や GitHub などの要件管理ツールとの連携が可能です。これは、デベロッパーツールへのアクセス権限を持っていない利害関係者と仕事をする場合に特に便利です。

5. 要件に優先順位をつける

要件を書き出したら、チームと一緒に優先順位を決め、どう取り組んでいくかを計画します。優先度を設定することにより、特に他の妨げになっているタスクがある場合に、最も重要なタスクから取り組めるようになります。

チームがアジャイルを使用している場合は、製品バックログに要件を追加し、次のスプリントに含めるタスクを決定するために、スプリント計画セッションを開催しましょう。スプリントで作業しない場合でも問題ありません。プロジェクトのタイムラインを作成し、各要件をいつまでに完了すべきか、また依存関係があるかどうかを明確にできます。

6. 変化に対する準備を計画する

要件管理とは、プロジェクト開始前に要件を計画するだけではありません。プロジェクトの進行中に変化する要件に対応することも含まれます。つまり、プロジェクトのスコープに影響を与えるような追加タスクを、どのように組み込むかを計画する必要があるのです。

1 つのオプションとして、変更管理プロセスの作成が挙げられます。これは、プロジェクトのスコープに影響を与えるような新しい要件を、利害関係者が申請する可能性を提供し、その要求を誰が承認または拒否すべきかを規定するものです。また、変更管理プロセスは、プロジェクト期間中に要件がどう変更されたかを文書化し、追跡することで、変更による影響を後で測定するのにも役立ちます。

要件管理を効率化するためのツール

要件管理には、変更される可能性のある不確定部分が多くありますが、制御不能というわけではありません。適切なツールを使用すれば、プロジェクトのライフサイクルを通じて、誰にいつ相談し、要件をどのように文書化し、整理するかを明確にした、繰り返し可能なプロセスを設定することができます。

Asana で要件を追跡する場合、プロジェクトごとに、要件を管理するための標準的なテンプレートを作成できます。つまり、毎回一からプロセスを開始するのではなく、定義済みのワークフローを再利用し、重要な部分を忘れることなく安心して作業を進められるのです。