ビジネス分析プロセス フロー: ステップバイステップのチュートリアル
チャールズ・ムーア
⚡ スマートサマリー
ビジネス分析プロセスフローは、プロジェクトの開始から要件の承認まで、ビジネスアナリストをガイドします。これには、要件の発見、ステークホルダーレビュー、文書分析、問題領域の明確化、プロジェクトマネージャーやスポンサーへの構造化されたプレゼンテーションが含まれます。
ビジネス分析プロセスで従うべき手順は何ですか?
以下は、ビジネス分析プロセスに含まれる手順です。初日のビジネス分析プロセスから計画段階の終了までをガイドします。
ステップ 1) プロジェクトに関するすべての情報を収集する
それは、 ビジネスアナリスト プロジェクトに関係する人々（プロジェクトマネージャー、プロジェクトスポンサー、機能マネージャー、または事業主）に質問することで、プロジェクトに関するあらゆる詳細情報を収集する責任。
収集する情報は、以下のトピックを網羅する必要があります。
- プロジェクトの範囲と境界
- 組織に影響を与える現在の要因
- プロジェクトのリスクと制約
- より広範な組織コンテキスト
プロジェクトに積極的に関わっているステークホルダーを特定します。これは、 ステークホルダーのニーズ分析.
この情報を収集した後、プロジェクトにおける自分の役割を分析し、ビジネスアナリストとして含めることができるチェックリストを作成します。例えば、以下のような項目です。
- 過去の経験から得た教訓を現在のプロジェクトにどのように活かせるか
- 現在のプロジェクトに必要な文書作成と計画
- プロジェクトの起こりうる結果について関係者と話し合う
- プロジェクトに関わるメンバーを特定する
- 追加の情報が必要な場合は、クライアントおよび関係者との会議を手配してください。
- 期待される成果物とその提出形式
- プロジェクトをより深く理解するために、既存のドキュメントを参照することができます。
- 方法論（アジャイルまたはウォーターフォールプロジェクトに最も適したもの
ステップ2）利害関係者を特定し、 Rev会議の様子
2番目のステップでは、 反省会 プロジェクトマネージャー、関係者、チームメンバーとの連携が重要です。議題が不明確だと、プロジェクトの失敗につながることがよくあります。
- プロジェクトに期待されることを具体的に述べてください。
- プロジェクトマネージャー、関係者、チームメンバーを会議に参加させ、プロジェクトに関連する質問をしてください。
- 全く新しいプロジェクトに取り組む場合は、プロジェクトマネージャー、または以前にその分野で働いた経験のある担当者に相談してください。
ステップ3）プロジェクト関連文書をすべて分析する
次に、適切に 分析する プロジェクトに関連するすべての文書、例えば：
- ビジネスプロセスの文書化
- ビジネスおよびシステム要件ドキュメント
- ビジネスケース
- チャートとフロー図
- プロジェクト計画
- 組織図
- 戦略文書と事業計画
- 政策と法律
ビジネス要件文書に隠された情報を明らかにし、 trac現在のシステム、プロセス、手順、および運用とのギャップを特定してください。提供された文書は古い情報である可能性があるため、最終的な情報として扱う前に、発見したすべての事実を検証してください。
ステップ4）発見したすべての事実と情報を記録する
調査と分析の過程で、プロジェクトに関して変更や実施が必要な多くの有益な事実が明らかになるでしょう。後で確認できるよう、すべての発見を記録しておきましょう。
- レポート要件を含むビジネス要件
- ビジネスプロセスとそれを支えるシステム
- 機能要件と非機能要件
- 現在プロジェクトに影響を与えている問題とリスク
ステップ5）問題領域を理解する
この時点でプロジェクトをしっかりと理解しているので、 問題のドメインを特定する調べるべきこと：
- どの業務機能が影響を受けるか
- 事業に影響を与えるリスクと要因
- プロジェクトに影響を与えるポリシーと制約
- プロジェクトの重要度を決定する値
- 現在ビジネス活動をサポートするシステム
- 問題領域を要約した文書、例えば年次報告書など
- 現在、事業が望ましい成果を達成することを阻害している問題点
- 提案された変更が問題領域に違いをもたらすかどうか
ステップ6）ビジネス要件を提示する
すべてのビジネス要件を収集し、問題領域を理解したら、次のステップは ビジネス要件の提示 関係者またはプロジェクトマネージャーに対して。一般的なプレゼンテーション手法には以下が含まれます。
- テーブルまたはスプレッドシート
- 図またはグラフ
- プロトタイプまたはシミュレーション
- 構造化テキストテンプレートまたは構造化文
ビジネスアナリストのプロセスを簡単に概観できる用語集：
- 目的： 提案されたイニシアチブに必要なビジネス分析活動の目的を定義します。
- 範囲： 含める成果物と除外する成果物を定義します
- 根本的な原因： 特定された問題の根本原因を定義する
- 現状： 変化の必要性を引き起こす問題点を定義する
- 計画されている活動: 活動の理由、成果物、納期を定義します。
- ステークホルダーエンゲージメント計画： ステークホルダーエンゲージメントプロセスの概要を説明します。
- 品質管理： プロジェクト成果物の品質を確保するための活動について説明します。
- Target 調子： 特定された重要な問題にどのように対処するかを定義する。
ビジネス アナリストのための簡単なヒント
- 会議で質問する
- 利害関係者との会議やレビューの前に準備を整える
- 変化や新しい経験に適応する
- 期待を管理する
- フィードバックに返信する
ビジネス分析プロセス中に作成される一般的な成果物
あらゆるビジネス分析プロセスは、プロジェクトチーム、スポンサー、監査人が参照できる一連の文書を残します。 trac話を戻しましょう。これらの成果物を一貫して作成することが、プロジェクト間でプロセスを再現可能にする鍵となります。
- ビジネス分析計画： 分析作業のアプローチ、スケジュール、および関係者との連携計画について説明します。
- 利害関係者登録簿： すべての関係者とその役割、影響力、期待、および希望するコミュニケーションチャネルを一覧表示します。
- ビジネス要件ドキュメント (BRD): 技術的な知識を持たない関係者にも理解できる言葉で、高度なビジネスニーズ、目標、成功基準を明確に示します。
- 機能要件と非機能要件： BRD（ビジネス要件定義書）を、開発者やテスターが参考にできるシステム動作、品質特性、制約事項に変換する。
- プロセスモデルとユースケース： BPMN図、UMLユースケース、またはアクティビティ図を使用して、現状のワークフローと将来のワークフローを示します。
- 要件 Trac脆弱性マトリックス（RTM）： すべての要件を、その発生源、設計要素、およびそれを検証するテストにリンクさせる。
- 変更要求ログ： スコープへの変更内容とその影響、決定事項、承認者をすべて記録し、監査証跡を完全な形で保持します。
これらの成果物は、Confluence、SharePoint、または専用の要件管理ツールなどの共有リポジトリに保存し、すべてのチームメンバーが同じバージョンで作業できるようにする必要があります。
ビジネス分析プロセスで避けるべきよくある間違い
経験豊富なビジネスアナリストでさえ、納期プレッシャーの中で同じ落とし穴にはまってしまうことがあります。以下のミスに注意することで、プロジェクト後半での手戻りや予期せぬ範囲変更のほとんどを防ぐことができます。
- ジュムping 問題提起をする前に解決策を考える： 根本原因を理解する前にシステム、ツール、または機能を提案すると、高額な手戻りが発生し、真のビジネスニーズを解決しないソリューションにつながる。
- スキップping 利害関係者による検証： システムを使用する人々の承認を得ずに要件を記録すると、ユーザー受け入れテストの段階で初めて明らかになる欠陥が生じる。
- 要件を静的なものとして扱う： プロジェクト中にビジネスニーズが変化する。要件リポジトリを維持管理しないビジネスアナリストと trac実現可能性マトリックスはすぐに範囲の制御を失ってしまう。
- コラボレーションではなく、過剰な文書化： 誰も読まない200ページものBRD（ビジネス要件定義書）を作成するよりも、定期的な作業セッションとビジュアルモデルを組み合わせた短い文書を作成する方がはるかに良い。
- 幸せな道だけに焦点を当てる： 例外処理、エラー処理、非機能要件の欠落は、欠陥を本番環境に持ち込み、ユーザーとの信頼関係を損なう。
- 孤立した状態での作業： 開発者、テスター、運用チームが参加しない要件分析では、共同レビューで発見できたはずの実現可能性リスクや下流工程における制約を見落としてしまう。
- 曖昧な表現や不明瞭な言葉遣い： 「ユーザーフレンドリー」「高速」「柔軟性」といった言葉は、測定可能な受容基準がなければ、実際にその機能が実証されたときに初めて意見の相違を生じさせる。
ビジネス分析プロセスを支援する人気ツール
適切なツールセットは、要件定義から承認まで、ビジネス分析プロセスのあらゆる段階をサポートします。多くのチームは、軽量なバックログツール、モデリングツール、およびドキュメントプラットフォームを組み合わせて使用しています。
- ジラと Azure DevOps: Tracアジャイル開発チーム全体でエピック、ユーザーストーリー、および欠陥を把握し、要件をスプリント作業に結び付けます。
- Confluence、SharePoint、そして Notion: ビジネス分析計画、会議議事録、決定事項、およびビジネス要件定義書（BRD）は、関係者がアクセスできる検索可能な場所に保管してください。
- Microsoft Visio, Lucidchart、そしてdraw.io： ワークフローと引き継ぎを可視化するBPMNプロセスフロー、ユースケース図、およびデータモデルを作成します。
- ジャマ・コネクト、 IBM ドア、 Modern Requirements、そしてVisure： ベースラインを使用して要件を大規模に管理し、 trac規制対象プロジェクトにおける実現可能性および影響分析。
- Miro そして壁画： リモートでの発見、ユーザー体験マップの作成を容易にするping、およびアフィニティマップping リアルタイムで開催されるワークショップ。
- バルサミクと Figma: 開発開始前に、ビジネスユーザーと提案された画面を検証するための、低忠実度ワイヤーフレームと高忠実度プロトタイプを作成する。
小規模チームは、Jira、Confluence、 Lucidchart大規模なプログラムや規制対象プログラムでは、専用の要件管理ツールを一度追加します。 trac妥当性、基準値、および監査証跡が必須となる。
