BrSEの有効なツールー業務分析（Business Analize）

Truong Van Vu -

オフショア開発に不可欠な役割としてはブリッジSEです。技術力不足による品質の不安定さや言語・文化の違いによるコミュニケーションロスを防ぐために、ブリッジSEが活躍します。

BrSEの主な役割は下記のようにと広く知られていると思います。

  • 依頼主となる日本企業の担当者とのコミュニケーション
  • 作業進捗報告
  • 納品物の検品・修正

具体的な仕事：

  • 現地スタッフへの説明
  • 設計書作成
  • 開発の進捗管理
  • 納品物の受け入れ確認
  • 依頼先への報告作成・翻訳

しかし、上記の各仕事をうまくできるBrSEは多くないと思います。大きな理由としては依頼主から要求された要件を「よく」把握しないからだと考えられます。もちろん、コミュニケーション、IT知識、マネージャー、文化理解などのスキルも不可欠なものですが、
ただ、技術、言語、マネジメントばかりに目を向ける癖があって、自分が開発するシステムの本来となる目的を軽く見てしまい、オフショア開発チームと説明するときも、不足で結局、開発チームが目的を完全に知らない間にシステムを作ってしまうのです。
つまり、システムの背景・関連事物・将来の実用をしっかりと把握しないといけません。要はシステムの業務分析が必要となります。プロジェクトはどこからいつから始まるか、またはどんなプロダクト・どう完成するかをつかめるのがBrSEの一番大きなチャレンジだと思います。
あらゆる種類の質問に対応するために、ビジネスプロセス分析をするための重要な手法のいくつかを紹介いたします。

ステップ１：プロジェクトに関するすべての情報を収集する

プロジェクトに関連するすべての詳細を収集するのは、BrSEの責任でプロジェクトに関係する人々（プロジェクトマネージャー、プロジェクトスポンサー、マネージャー、または事業主）に質問することです。
質問事項は以下であげられます。

  • プロジェクトの範囲と境界
  • 組織の現在の問題点
  • プロジェクトのリスクと制約
  • より広範な組織の背景

このすべての情報を収集したら、プロジェクトの自分のポジションで、業務分析ために次のようなチェックリストを作成するといいでしょう。

  • 以前の経験から、現在のプロジェクトに利用できるもの
  • 現在のプロジェクトに必要な文書化と計画
  • プロジェクトの最終結果について利害関係者（依頼主など）と話し合う
  • プロジェクトに関与しているメンバーを整理する
  • クライアントからの要求のソリューションを探すため、依頼主とのミーティングを調整する
  • 期待される成果物とは何であり、どのような形式で必要とされるか
  • プロジェクトのアイデアを改善するために参照できる既存のドキュメントがあるか
  • プロジェクトに適した方法論（アジャイルまたはウォーターフォール）を確認する

ステップ２：関連者を特定し、レビュー会議を設定する

２番目のステップでは、プロジェクトマネージャー/利害関係者/チームメンバーとのレビューMTGを設定することです。 不明確な議題は、プロジェクトの失敗につながる可能性があるかを討論する。

  • プロジェクトから何が期待されるかを具体的に説明する
  • プロジェクトマネージャー/利害関係者/チームメンバーを会議に招待し、プロジェクトに関連する質問をする
  • まったく新しいプロジェクトに取り組んでいる可能性が非常に高いで、その場合は、プロジェクトマネージャーに問い合わせるか、以前にそのドメインで働いたことのある担当者に伺えばいい情報がいただけるでしょう

ステップ３：プロジェクトに関連するすべてのドキュメントを分析する

次に、以下のプロジェクト関連のすべてのドキュメントを適切に分析する必要がある

  • ビジネスプロセスのドキュメント
  • ビジネスおよびシステム要件ドキュメント
  • ユーザーストーリー
  • チャートとフロー図
  • プロジェクト計画
  • 組織図
  • 戦略文書と事業計画
  • ポリシーと法律

ビジネス要件ドキュメントに隠されている情報を明確にし、現在のシステム、プロセス、手順、および運用とのギャップを追跡していく。 提供されたドキュメントが古くなっている可能性があるため、発見した情報を検証する、または依頼主に質問する

ステップ４：新しく発見したすべての事実と情報を記録する

調査と分析から、プロジェクトで変更または実装する必要のある、プロジェクトに関連する多くの有用な情報を見つけることができる。見つけた時点でそれらを記録する。記録手法は現行のドキュメントにハイライト付けか新しくバージョンつけでもいいでしょう。
主に、検討できるのは下記となるでしょう。

  • レポート要件を含むビジネス要件
  • ビジネスプロセスとサポートシステム
  • 機能要件と非機能要件
  • 現在プロジェクトに影響を与えている問題とリスク

ステップ５．問題のドメインを理解する

上記のステップで通してプロジェクトの十分な洞察が得られたかと思います。そこでプロジェクト内の問題のあるドメインを特定する、明確にする必要があります。（自分が曖昧なら聞いた他人も曖昧で受け取る）

  • 正確にどのビジネス機能が影響を受けるか
  • 業務に影響を与えるリスクと要因
  • プロジェクトに影響を与えるポリシーと制約
  • プロジェクトの重要度を決定する価値
  • 問題の領域について簡単に説明する文書-例：年次報告書（文書内場合、直接依頼主に伺う）
  • 望ましい結果を達成するために現在ビジネスをブロックしている問題
  • 提案されたソリューションでは、問題のドメインに違いがあるか

ステップ６：ビジネス要件を提示する

すべてのビジネス要件を収集し、問題のドメインを理解した後、次のステップは、利害関係者またはプロジェクトマネージャーにビジネス要件を提示することです。 次のような要件を提示するために使用できる多くの手法があります

  • 表またはスプレッドシート
  • ダイアグラムまたはグラフ
  • プロトタイプまたはシミュレーション
  • 構造化テキストテンプレートまたは構造化文書

※業務分析にプロセスの概要をすばやく説明する用語集

  • 目的：要求された要件に必要なビジネス分析アクティビティの目的
  • 範囲：含まれるものと除外されるもの
  • 根本原因：特定された問題の根本原因
  • 現状：変更の必要性を引き起こす問題
  • 活動計画：活動の理由、成果物、および納期
  • 利害関係者の関与計画：利害関係者の関与プロセスの概要
  • 品質管理：プロジェクトの成果物の品質を保証する活動
  • 目標条件：特定された重大な問題にどのように対処するかの条件

※業務分析のために有効なコツ

  • MTGで質問する
  • 利害関係者のMTGまたはレビューの前に準備する
  • 変化と新しい経験に適応できる
  • 期待を管理する
  • フィードバックに返信する

ベトナムの方に有効な参考資料：https://thinhnotes.com/chuyen-nghe-ba/ky-nang-can-co-cua-nguoi-lam-ba-tap-cuoi/