ドキュメントの種別を知る
学習の目的
この単元を完了すると、次のことができるようになります。
- プロジェクトにおけるドキュメントの役割を説明する。
- ビジネスアナリストが作成する主なドキュメントの種類を説明する。
ビジネスアナリストの成功の 3 大要素
「知るということは、単に知るだけのことではない。」― Mokokoma Mokhonoana (哲学者、著者)
Ursa Major の海外営業 VP である Ian Lin を覚えていますか? 彼が自分の目標を達成するためにビジネスアナリストの協力を要請したのは正しい判断でした。今ではチームの四半期の売上予測金額を確認して調整できるようになりました。この結果を短期間で成功させることができたのは BA のおかげです。
皆さんはこれまで学習した内容から、何が行われたかを推測できると思います。ビジネスアナリストがコミュニケーションスキルを適用して Ian (ステークホルダー) からニーズを引き出し、さまざまなレベルで複数のチームとの連携を成功させたのです。彼女は意図した結果を得るための商品に関する知識とスキルを持っていました。ただし、成功を達成するためにビジネスアナリストが行ったことがもう 1 つあります。それは、ステークホルダーとのコミュニケーションとコラボレーションのツールとしてドキュメントを使用することです。
プロジェクトの成功にコミュニケーションスキルが不可欠であることは学習しました。適切なコミュニケーションを行えば、ステークホルダー、開発チーム、プロジェクト管理チームの間に情報が行き渡り、全員が情報にアクセスできます。コラボレーションも鍵となります。チームメンバーはそれぞれ独自の視点、アイデア、目的を持っていて、BA はメンバー全員と効果的に連携してプロジェクトについて意思統一を図る必要があります。次にドキュメント化を行います。効果的なコミュニケーション、コラボレーション、ドキュメント化はビジネスアナリストの成功のための 3 大要素です。多くの場合、これを組み合わせることで、良い結果につながります。
ビジネスアナリストがまとめたり使用したりするドキュメントの種類をいくつか見てみましょう。
ドキュメントの種類
作成するドキュメントの種類は次のようなさまざまな要素によって異なります。
- プロジェクトの種別
- ビジネスニーズ
- 関係者のニーズ
- 思い込み
- 制約
ビジネスアナリストにとって重要になるドキュメントにはさまざまな種類のものがあります。その範囲は、印刷されたドキュメントから情報リポジトリやスクリーンショットのコレクション、会社や部門の情報を含む Web サイトやブログにまで及びます。各プロジェクトでは、最も適切な種類のドキュメントのみを作成して使用します。
具体的な例をいくつか見てみましょう。ビジネスアナリストが作成するその他のドキュメントの例については、この単元の「リソース」セクションを参照してください。
|
ドキュメント種別 |
内容 |
|
用語集 |
これはプロジェクトに関与するチーム間での理解を促進するための重要な用語と定義のリストです。 |
|
RACI チャート |
RACI は responsible (実行責任者)、accountable (説明責任者)、consulted (協業先)、informed (報告先) の頭文字です。これはビジネスアナリストの取り組みにおいて、誰が何に責任を持つかを示すマトリックスです。 Responsible (実行責任者): 活動や業務を実行する人。 Accountable (説明責任者): 結果の最終的な責任を持つ人。 Consulted (協業先): フィードバックを提供したり活動に貢献したりする必要がある人。 informed (報告先): 決定事項やアクションについて知る必要がある人。 |
|
インタビューと引き出しの記録 |
このドキュメントにはステークホルダーからの重要な情報を取得します。 |
|
ステークホルダー分析 |
このドキュメントでは次のことを特定します。
|
|
ユーザーストーリー |
ユーザーストーリーとは、ビジネスシステムを開発できるように、そのビジネスシステムで提供すべき機能を説明するものです。チケットまたは作業項目とも呼ばれます。その形式は、「[誰] として、私は [理由] のために [何] する必要があります」となっています。 |
|
使用事例 |
ユースケースでは、ユーザーの視点からシステム要件を特定、定義、整理します。 |
|
ビジネス分析計画 |
この計画には、プロジェクト全体で行われるビジネスアナリストのすべての活動がリストされます。 |
|
現状分析 |
現在のビジネスプロセスまたはドメインがよく理解されていない場合は、BA はプロジェクトの範囲を設定する前に改善すべき現在の状態を分析してドキュメント化します。 |
|
スコープステートメント仕様 |
これはあらゆるプロジェクトの最も基本的な成果物です。何を達成する必要があり、プロジェクトの完了や商品の提供のためにどのような作業を行う必要があるかを明確に定義します。 |
|
機能要件仕様 (FRS) |
エンドユーザーまたはエンドビジネスの視点から定義されたビジネス要件です。期待される結果を指定します。 |
|
システム要件仕様 (SRS) |
このドキュメントでは、完全なシステムがどのように機能すべきかの詳細を記述し、システムのハードウェア、ソフトウェア、機能、動作の要件を列挙します。 |
|
ギャップ分析ドキュメント |
このドキュメントは現在のプロセスと意図するプロセスのギャップを説明するものです。 |
|
変更要求ログ |
このドキュメントはプロジェクトのすべての変更要求のログで、要求の日付、要求者、その他の重要な情報が含まれます。 |
|
ワイヤーフレームとその他のビジュアルドキュメント |
このドキュメントにはユーザーインターフェースの表示が含まれています。通常、大まかなワイヤーフレームの形式が使用されます。 |
|
テスト計画、テストケース、またはユーザー受け入れテスト計画 |
このドキュメントでは、チームが機能要件を検証するために使用するテスト計画と詳細なテストケースについて説明します。 |
|
変更管理 |
このドキュメントでは、変更をビジネスに転送する方法について説明します。 |
ドキュメントについて考え方
ビジネスアナリストはプロジェクトのライフサイクル全体を通してドキュメントの作成と更新を行います。そのドキュメントはさまざまなプロジェクトのニーズを満たすもので、プロジェクトに関与する各種ステークホルダーによって使用され、さまざまな形式や媒体で提供されます。
結果を報告する
結果を報告するときには、全員が理解しやすい形式を使用します。また、更新しやすい形式にします。更新は必ず発生します。これが報告モデルになります。
最適な報告モデルを決定するときには、次の点について検討します。
- 対象者は誰か? 情報は対象者に対して適切か?
- 各ステークホルダーは何を必要としていて、情報をどのように理解するか?
- どの情報を伝えることが重要か?
- 従う必要がある規制や契約上の制約はあるか?
ステークホルダーに情報を提示するには、次の 3 つの方法があります。上記の質問への答えに応じて 1 つまたは複数の形式を使用します。
|
形式 |
内容 |
|
公式ドキュメント |
この形式は通常、組織のテンプレートに基づいていて、テキスト、マトリックス、図を含みます。 |
|
非公式ドキュメント |
この形式には、組織の正式なプロセスには含まれていないテキスト、マトリックス、図を含めることができます。 |
|
プレゼンテーション |
この形式は意思決定の裏付けとなる目標、ソリューション、情報の概要を示すのに最適です。 |
まとめ
ビジネスアナリストが何を行い、成功するためにどのようなスキルが必要かについて学習してきました。情報収集してアイデアやニーズを伝えるためにそれをドキュメント化することから、ステークホルダーとのコラボレーションまで、ビジネスアナリストはプロジェクトのライフサイクルにおいて重要な役割を果たします。エンタープライズソリューションの実装を成功させるには、この役割の効果を過小評価することはできません。
