概要
プロジェクトには、同時に進行するさまざまな要素があります。よい成果を上げるには、こういった要素をすべて適切なタイミングで、適切な場所にまとめなくてはなりません。
ビジネス要件定義書 (BRD) は、プロジェクトに伴うすべての事柄をまとめ、成功に必要なものをステークホルダーが理解できるようにする文書です。この記事では、ビジネス要件定義書のテンプレートを作る上での重要要素と、オンラインのソフトウェアで共有するメリットもご紹介します。
ワークフローで組織を効率化する方法
この電子書籍では、「今の働き方がうまくいかない理由」「柔軟なプロセスを構築する 7 つの重要ステップ」「一般的な戦略・運用ワークフローへのステップの適用方法」を紹介します。
要件定義とは
要件定義とは、システム開発やプロジェクトにおいて、実装すべき機能や満たすべき性能、制約条件などを明確にする作業です。開発プロセスの最上流に位置し、プロジェクト全体の方向性を決定づける重要な工程です。
要件定義が不十分な場合、後工程での手戻りやスケジュール遅延の原因となります。多くの IT プロジェクトが要件定義の不備を理由に計画通りに完了できていないというデータもあり、この工程の重要性は広く認識されています。
要件定義のプロセスは、大きく以下の 3 ステップで進行します。
ユーザーや業務担当者へのヒアリングを通じた要求の収集
収集した要求の整理と、実現可能な要件への落とし込み
要件定義書としてのドキュメント化とレビュー・承認
要件定義には「ビジネス要件」「システム要件」「機能要件」「非機能要件」など、複数の種類があります。本記事では、プロジェクトの全体像を俯瞰的に捉える「ビジネス要件定義書 (BRD)」に焦点を当てて解説します。
ビジネス要件定義書 (BRD) とは？
ビジネス要件定義書とは、新しいプロジェクトの成功に必要なものの詳細を書き出したレポートです。この文書ではプロジェクト目標や、プロジェクトライフサイクル中に期待される事柄、プロジェクト達成に必要なものなどがまとめられます。
ビジネス要件とシステム要件の違い
ビジネス要件とシステム要件は異なるもので、一般的に「要件定義書」と言うと、IT チームやシステム開発部のエンジニアが作成するシステム要件定義書を指すことが多くなっています。
ビジネス要件は、ビジネスまたはプロジェクト上の目標や目的を達成するために必要な要素や条件を指します。企業が何を達成したいのか、何を解決しようとしているのか、顧客の課題やニーズに焦点を当てたものです。
一方のシステム要件とは、ビジネス要件を満たすために必要な機能や性能を具体的に示したものです。技術的な側面に焦点が当たっているため、業務担当者へのヒアリングなどを適切に行い作成しなければなりません。
ビジネス要件定義書の構成要素
ビジネス要件定義書には、以下 7 つの要素が含まれます。
これらの詳細をまとめることによって、ビジネス要件定義書を読めばそれがどんなプロジェクトなのか、何をどう達成しようとしているのか、はっきりと理解できるようになります。
「もっと効率よくプロジェクトを進めたい」「無駄な作業をしている気がする」「チームメンバーの足並みが揃わない」
その悩み、Asana のプロジェクトマネジメント機能で解決できます。まずは30 日間無料で Asana の機能サービスをご利用ください。
Asana のプロジェクトマネジメント機能を試すビジネス要件に関連するその他の要件
ビジネス要件とシステム要件はすでに解説しましたが、ここではビジネス要件と関連するその他の要件についてまとめます。
ビジネス要件定義書ではプロジェクトの要件について説明します。情報を俯瞰的にまとめることで、ステークホルダーにプロジェクトの全体像を伝えます。
機能要件定義書 (Functional Requirements Document、FRD) は、プロジェクト内の特定のタスクの実行方法を詳しく説明するものです。ボードゲームに例えると、ビジネス要件定義書はゲームの内容と魅力を伝える外箱で、機能要件定義書はゲームのプレイ方法が書かれた説明書です。
機能要件の他にも、こんな要件があります。
ユーザー要件: ビジネス要件定義書よりも詳細な要件で、完成した成果物でユーザーは何ができるのかを説明するものです。
製品要件: ビジネス要件やユーザー要件よりもさらに詳細な要件で、完了したプロジェクトのゴールと機能を説明するものです。このドキュメントは、チームが製品の開発やマーケティングを行う際のガイドとなります。
非機能要件: 機能要件と同じくらい詳細な要件です。プロジェクトの運用方法や、完了したプロジェクトが意図する利用者体験などについて説明します。
上記以外にも、業務フローやプロセスを定義した「業務要件」も存在します。これはビジネス要件を実現するために、実際に業務がどのように行われるべきかを定義したものです。
ビジネス要件定義書の書き方
ビジネス要件定義書にはプロジェクトの詳細を書く必要がある一方で、内容を簡潔にとどめる必要もあります。作成時は、読者にできるだけ少ない言葉で、できるだけ多くの情報を与えることを心がけましょう。
プロジェクトに関わるステークホルダーから、プロジェクトを承認する経営層、最終的な成果の影響を受けるクライアントまで、ビジネス要件定義書は多くの人に読まれます。ここでは、先ほどご紹介した 7 つの要素それぞれについて、記述するときのポイントを解説します。
1. エグゼクティブサマリー
エグゼクティブサマリーとは、プロジェクトの概要と目的を大まかにまとめたものです。ビジネス要件定義書の全文を読む時間がない人も、エグゼクティブサマリーを読めば、そのプロジェクトによって何を達成しようとしているのか把握できます。
エグゼクティブサマリーはビジネス要件定義書の冒頭に書かれるものですが、書く順番としては他の要素をすべて書き終わってから書くのがよいでしょう。そうすることで、すべての内容を見直してから、包括的なエグゼクティブサマリーを書くことができます。
記事: エグゼクティブサマリーの書き方 (実例付)2. プロジェクト目標
プロジェクト目標とは、そのプロジェクトを実行に移すことによって達成したいビジネス目標のことです。どんな仕事も、始める前にプロジェクト目標を明確にし、それを使って進捗状況を測定できるようにしましょう。
プロジェクト目標は SMART 目標の書き方に従って設定しましょう。SMART とは、
Specific (具体的)
Measurable (測定可能)
Achievable (達成可能)
Realistic (現実的)
Time-bound (期限がある)
の頭文字を取ったものです。プロジェクト目標の達成状況を測定することで、目標達成のためにワークフローを調整する必要があるかどうか判断できます。
たとえば、目標が「顧客ベースの 10% 拡大」だった場合、四半期が終わるころに数値を確認すれば、目標を達成できたかどうか明確に把握できます。そしてそれまでに取ってきたアクションを振り返れば、何が原因で達成に至らなかったのか判断できるはずです。
毎日の仕事とプロジェクト目標のつながりを明確にすれば、パフォーマンスは向上します。Asana なら、各指標の達成度や達成状況を一目で把握し、チーム全体でシェアすることも可能です。
効果的な目標を設定する方法3. プロジェクトスコープ
プロジェクトスコープは、ビジネス要件定義書において、プロジェクトの範囲を明確にする役割を持ちます。プロジェクトスコープを定義することで、全員が共通認識を持ち、スコープクリープを防ぐことができます。
スコープクリープとは、プロジェクトが予定していた範囲を超えて拡大してしまい、コントロールが難しくなることを言います。
プロジェクトスコープでは、以下の点について要約します。
また、プロジェクト対象外のリストや、ビジネスプロセスやリスクの高い戦略など、そのプロジェクトに取り組むにあたり、避けてほしい特定の事柄に関するリストを作成してもよいでしょう。
4. ビジネス要件
ビジネス要件は、ビジネス要件定義書テンプレートのメインとなる要素です。この項目では、プロジェクトの達成に必要なアクションをリストアップします。
プロジェクトの複雑さによって、ビジネス要件の数は数個に収まることもあれば、多くなる場合もあるでしょう。
各要件はリストアップして説明するだけでなく、優先順位と重要度のランク付けをしましょう。そうすることで、読者はどの要件に優先して取り組むべきか把握できます。
たとえば、要件の 1 つが「ウェブサイトのコーディング」であった場合、これを最優先とし、重要度も「高」でランク付けしましょう。ウェブサイトのコーディングが完了するまでは、他の要件を完了させていく根拠がないためです。
プロジェクトの受付プロセスを構造化し、要件の優先順位付けを効率化した実例として、Asana 社内での取り組みが参考になります。フォームを活用した構造化データの収集やリクエストの優先順位付けにより、プロジェクトの要件整理がスムーズになりました。詳しくは Asana のプロジェクト受付プロセスの事例をご覧ください。
5. 主なステークホルダー
プロジェクトのステークホルダー (関係者) には、プロジェクトに関与するすべての人が含まれます。おそらくプロジェクトを理解するためにこのビジネス要件定義書を読む必要のある人は、ステークホルダーにあたるでしょう。
ステークホルダーの例として、以下が挙げられます。
プロジェクトに取り組むチームメンバー
プロジェクトを率いるプロジェクトマネージャー
プロジェクトを承認する経営層
完了したプロジェクトの影響を受けるクライアント
この項目では、各ステークホルダーの名前と役職をリストアップし、このプロジェクトにおけるそれぞれの役割を明確にします。読者はこの項目を読むことで、自分の他に誰が関わっているのか把握でき、チームのコミュニケーションが取りやすくなります。
記事: プロジェクトマネジメントにおける関係者の分析とその重要性ワークフローを構築することで、チーム間の認識のずれをなくし、スムーズな共同作業を実現します。Asana のワークフローは、毎日使うツールと連携して仕事を一元管理できるので、仕事の効率・生産性も向上します。
Asana のワークフローが選ばれる理由とは？6.プロジェクトの制約
プロジェクトの制約についてはプロジェクトスコープの項でも触れたかもしれませんが、ここではさらに詳細に説明します。読者はこの項目を読むことで、プロジェクトの全体像と、限界を把握できます。
制約の例として、以下のようなものが挙げられます。
チームのキャパシティ
期限
プロジェクトの制約は、ステークホルダーがプロジェクトの複雑さや、プロジェクト目標達成の難易度を把握するのに役立ちます。プロジェクトに関与する全員が、まずはプロジェクトの制約を確認すべきでしょう。
7. 費用便益分析
ビジネス要件定義書を費用便益分析で締めくくるのは、戦略的なやり方です。プロジェクトの承認を得るためにビジネス要件定義書を使用している場合は、この項目が決定的要因となる可能性があります。
クライアントや経営層にとってプロジェクト目標は大事ですが、利益が出ることを証明できなければ、すべて無意味と言っても過言ではないでしょう。
費用便益分析は以下の手順で作成します。
プロジェクトに関連するすべてのコストについて説明します
関連する利益について説明します
プロジェクトの推定コストを算出します
推定収益から推定コストを差し引いて、推定 ROI を算出します
ビジネス要件定義書のテンプレートと使用例
ここでは、ビジネス要件定義書のサンプル例をご紹介します。ここで紹介するのは、テクノロジー企業がマーケティングブログを始める場合の例です。
この文書では、プロジェクトマネージャーがプロジェクトの概要と、その目的を説明しています。また、プロジェクト目標と、スコープクリープ防止のためにプロジェクトスコープについてもまとめています。
そしてその後には、プロジェクト完了に必要なアクション、つまりビジネス要件がリストアップされています。ステークホルダー、プロジェクトの制約、費用便益分析と続いていきます。
自分のプロジェクトでもビジネス要件定義書を試してみたいという方は、以下の無料テンプレートをお試しください。
ビジネス要件定義書の無料テンプレート要件定義に必要なスキル
要件定義を効果的に進めるには、技術的な知識だけでなく、対人スキルやビジネススキルも求められます。ここでは、要件定義の担当者に特に重要な 4 つのスキルを紹介します。
コミュニケーション能力
ステークホルダーから要求を正確に引き出すためには、適切な質問力と傾聴力が不可欠です。相手の業務や課題を深く理解し、言語化されていない潜在的なニーズを汲み取ることが求められます。
論理的思考力
収集した要求を整理し、矛盾や抜け漏れがないかを検証するためには、論理的に物事を構造化する力が必要です。要件間の依存関係や優先順位を正しく判断することで、実現可能な要件定義書を作成できます。
ドキュメンテーション能力
要件を曖昧さなく文書化する能力は、プロジェクトの成否に直結します。読者が誰であっても同じ解釈ができるよう、具体的で明確な表現を使い、必要十分な情報を過不足なく記述することが重要です。
交渉・調整能力
限られた予算やスケジュールの中で、ステークホルダー間の利害を調整し、合意を形成する力が必要です。すべての要求を実現できない場合に、優先順位を付けて関係者の納得を得るスキルが求められます。
要件定義を成功させるポイント
要件定義の品質を高め、プロジェクトの成功確率を上げるためのポイントを紹介します。
スコープを明確にする
プロジェクトの範囲を早い段階で明確にし、関係者全員で合意することが重要です。スコープが曖昧なまま進めると、要件が際限なく膨らみ、プロジェクトの遅延やコスト超過の原因となります。
ステークホルダーとの密な連携
要件定義は発注側 (ユーザー) と受注側 (開発チーム) の共同作業です。定期的なレビューや確認の場を設け、認識のずれを早期に解消しましょう。
特に、業務の現場担当者からのヒアリングを丁寧に行うことが、的確な要件定義の第一歩です。
非機能要件を見落とさない
機能要件に注目しがちですが、性能、セキュリティ、可用性、拡張性といった非機能要件も同等に重要です。非機能要件は後から追加すると大きなコストが発生するため、初期段階で漏れなく定義することが求められます。
変更管理プロセスを確立する
プロジェクトの進行中に要件が変更されることは珍しくありません。変更のリクエスト方法、影響範囲の評価手順、承認フローを事前に定めておくことで、変更による混乱を最小限に抑えられます。
まとめ: 要件は共有することが大事
ビジネス要件定義書を作成する場合も、もっと詳細なものを作成する場合も、ステークホルダーとしっかりと情報共有することはプロジェクトの成功を左右する要素のひとつです。
適切に共有するためには、クラウド型ワークマネジメントツールで行うのが最適です。
Asana のようなプロジェクト管理ツールを使えば、ビジネス目標に優先順位を付けられ、見落としも防げます。プロジェクトが現在どのフェーズにあるのか、進捗確認も一目で行えるので、貴重な時間を有効活用できます。
Asana でチームのコミュニケーションを効率化し、プロジェクトマイルストーンをスムーズに達成しましょう。
実際に、Acerbis 社は 400〜1,100 タスクに及ぶ複雑な製造プロジェクトをステージゲートモデルで構造的に管理し、プロジェクトの進捗確認を数日から数分に短縮しました。要件定義書で整理した情報をチーム全体で共有することで、プロジェクトの可視化と迅速な意思決定を実現しています。詳しくは Acerbis 社の事例をご覧ください。
まずは無料トライアルを 30 日間お試しください。ツールに関するお問い合わせはセールスチームまで。
あらゆる仕事の課題解決に、Asana。
仕事を最大限効率化し、チームの生産性を上げるためには、Asana のプロジェクトマネジメント機能をお試しください。日々の業務と目標をつなげ、「誰が・何を・いつまでに行うのか」を可視化します。
