記事の内容

システム開発プロジェクトで
Business Analyst(BA)というロールに出会ったことはありますか？

本記事ではその謎のロールについて紹介します。

BAの役割

BAの一般的な役割

まず、一般的にBAという時、その役割は多種多様です。
それでも世界で働くBAたちに共通する特徴を上げるなら、以下になるようです。

戦術レベルを決める役割
お客さんなどに達成したい目標がある場合、その達成に向けて変化を起こすための下地を用意する役割
お客さんのニーズを、解決策を実装する担当者(開発者など)が理解できる言語に翻訳する

BAのサブタイプごとの役割

大きく分けると2タイプ

ビジネス領域で働くBA
技術領域で働くBA

ビジネス領域で働くBAのイメージ：
お客さん「全社員にフルタイムのリモートワークをできるようにしたい」
BA「ありうるリスクと課題は〇〇です」
BA「解決策は△△です」
BA「実現のためには××のプロセスをAからBに変更すべきです」
BA「目標実現までのステップは□□です」

技術領域で働くBAのイメージ：
例：お客さん「新しいPOSシステムを導入したい」
BA「〇〇という要件なら××のようなシステムがよいと考えられます」

小さく分けると5タイプ

ビジネスプロセス系(Business Process Analyst)
ビジネスプロセスをモデリングする
As-isとto-beのモデルを比較する
ギャップ分析を行い、目標の達成までのステップを計画する
要件系(Requirement Analyst)
ユーザーから要件を抽出する。収集というより抽出。ユーザーに対して良い質問をし、要件を引き出す。それをドキュメント化する。
そして要件を分析する。詳細を詰める。
ビジネス側の担当者とIT側の担当者の間の溝をブリッジする。
ITを使った手段によって課題を解決する。
機能の設計に携わることがある。
要件定義をすることがある。
システム系(System Analyst)
要件系とは異なり、要件の抽出とニーズの分析はしない。
解決策を形にするために必要なものの仕様の全てを取りまとめる。例えば、勤務時間管理システムを実装するための、インフラからアプリケーションまでの仕様を取りまとめる。
開発者、アーキテクトと協力しつつ働く。
データ系(Data Analyst)
論理データモデリングをする人
ビジネスの仕組みやITシステム内、データウェアハウス内に存在するデータの種類、データ間のリレーションを定義する
データをドキュメント化する。
システム間のデータをマッピング(対応づけ)する。
UX系(User Experience Analyst)
UIの見た目とインラクションを設計する。
少ない労力で目標を達成できること、また簡単に使えることを重視する。
エンドユーザーの行動や思考を理解しようとする。

このようにBAと一口にいってもその役割は多様。大抵はその中の一部の領域にアサインされます。

BAにおいて重要なスキル

以下にBAにおいて重要なスキルを列挙しました。もちろん、ある程度他の職種にも当てはまりそうですし、実際にアサインされた役割によっては不要なものもあるでしょう。

コミュニケーション
文書、口頭の両面におけるコミュニケーションのスキル。
これはBAがビジネス領域のチームと技術領域のチームをブリッジする仲介者であるため。
課題解決
プロジェクトの進行中に起きた課題を定義し、解決策を検討する。
整理
様々な会議や話し合いから、後に参照できる記録を残していく几帳面さ。
複数のプロジェクトで働く場合や、色んな人々と働いていても混乱しない。
交渉
ステークホルダー間で見解がずれている場合に、二つの立場に折り合いをつけ、合意に至ることをサポートする。
ファシリテーション
会議におけるスキル。会議の目標が達成できるように議論を導く。
批判的思考
多くの選択肢を分析する必要があるため。また、最終的に選ばれた解決策が全てのステークホルダーのニーズを満たすことを保証するため。

システム系BAの役割の詳細(個人的経験+ネット情報ベース)

以下では個人的経験とネット情報をもとにBAのやっていることを記述します。

ネット情報：https://quizlet.com/411134663/ecba-master-set-flash-cards/?i=2fcfoi&x=1jqt

設計のライフサイクル管理

BA用語を調べると要件の管理requirement lifecycle managementという用語が見受けられました。外部仕様も同様に管理されることもあるようです。

設計のライフサイクルに沿って、役割を書くと以下の通りです。

1-1.仕様と仕様間の依存関係を特定する。
1-2.過去や関連する仕様との整合性を保つ。
　↓
2.仕様を正確にドキュメント化する。
　↓
3.実装する機能の優先順位をつける。リソースやスケジュールに制約がある場合、どれを先に/後に実装するかを選択する。
　↓
4.仕様を運用する。仕様を設計者や開発者に伝える。仕様が曖昧に定義されており、開発者が実装方法を判断できない場合、BAが調査して明確化する。既存の設計書や過去の会議録を調べ、それでも曖昧な場合にお客さんに確認する。
　↓
5.開発者が実装する。並行してBAがテストケースを作成し、実装後にテストする。
　↓
6.仕様に変更が依頼された場合、その別の仕様への影響を調査する。関係する仕様に対して必要な変更を特定する。

各ステップの解説

このセクションでは上記のステップの詳細を説明します。
ただし、個人的経験ベースなので、一般的でないかもしれません。ご注意ください。
(そういうのが要らない人はスキップしてください)

前提：
体制として、バックエンドの設計担当とフロントエンドの設計担当、開発担当がそれぞれ別の会社。webアプリ開発ではたまにある体制。

この場合、会社間にコミュニケーションをとりづらく、認識齟齬が起きることがあります。このような認識齟齬をブリッジするのがBAの役割だと思っています。

1, 2について

これはハイレベルな(高い抽象度の)話なので、仕様変更の仮想の例を挙げます。例えば、SNSのウェブアプリがあったとする。あるページは、当初全ログインユーザーが閲覧できた。その機能を設計書に書いており、開発者にも伝えます。しかし仕様変更が起きて、課金ユーザーだけがボタンをクリックして遷移できる仕様になった。無料アカウントの人がボタンを押したらエラーが表示される機能をバックエンドで実装するようになった。となると、そもそも100人未満の人にはボタンを表示しないというフロントエンド側の仕様変更も考えられる。つまり、押しても絶対にエラーになるボタンは除去するということ。このようにして、BAは仕様の変更を捉え、関連する仕様の変更を見つけます。

4について

一般的なのかは不明ですが、私の案件では開発者が開発する際、仕様について質問がそこそこ生じます。仮想の例：ボタンはオプトインかオプトアウトか？　

このようなコミュニケーションのタスクがあるのはアジャイル開発の方針ゆえかなと推察します。つまり、プロセスやツールよりも個人と対話を、包括的ドキュメントより動くソフトウェアを、という方針に従っているということです。実際、自分の案件のユーザーストーリーは最初から微に入り細を穿つように仕様を書いていなさそうです。初手で詳細なドキュメントを作るより、必要な場合にのみ人間がコミュニケーションして仕様を明確化する方が、開発スピードを速められるのかもしれません。

質問が発生した時のBAのプロセスをハイレベルに描くと以下のようになります。
手元の外部設計書など調べるべきドキュメントを特定
-->手元の情報から明確な点/不明確な点を切り分け
-->不明確な点は、テクニカルリードと議論して開発に必要かつ不明確な論点をさらに特定
-->設計担当者に確認
-->開発者への伝達&ドキュメントの更新

開発が遅れないようBAが捌きます。

このプロセスにおけるベターなプラクティスを備忘録として記載します。

機能の実装をフロントエンド側とバックエンド側のどちらでやるかを判別する(たまにどっちも実装が未想定の場合があるため)。
開発者からの質問の論点に含まれないが機能の実装に必要な仕様を特定する。そしてお客さんに一度の会議内で質問し明確化しきる。これは会社をまたぐコミュニケーションのラリーが1つ増える度、1,2日ほど実装が遅れるためです。
スムーズに仕様を明確化するための質問の仕方について。お客さんとの確認の会議では、どこが不明確かを認識してもらうため、モックアップを見せつつ示したり、特定の動作シナリオの前提条件について手間を惜しまず説明した方がよいと感じています。

6について

アジャイル開発の場合、イテレーションごとに仕様の変更や追加が起きえます。

例えば、ユーザビリティの観点から、ユースケース間で仕様が統一されていることが望ましい場合があります。フォントがページ間で違ってたらダメとか。共通の仕様に対し変更があった場合、インパクトを受ける機能を特定しにいきます。

アジャイル開発における仕様変更への対応

上記で書いたとおり、BAはアプリの仕様変更に伴う別の仕様への影響調査を行います。影響調査の際には仕様間の関係を理解することが重要です。そこで、仕様間の関係とは何かを説明します。

仕様とは

仕様はレベルごとに存在する。
すなわち、要件のレベル、機能のレベル、実装のレベル、さらにイテレーションごとの仕様がある。BAは、これらの異なるレベル間/同一レベル内の仕様の関係を捉えていきます。私のケースでは、実装レベルの仕様、イテレーションごとの仕様を把握します。

仕様間の関係性のサブタイプ

異なるレベル間の関係

由来＝仕様Aと仕様Bの間で抽象度が異なるという関係
例えば
仕様A：ユーザーが買い物をする
仕様B：ユーザーが商品を選択し、支払いを完了し、配送方法を決定する

同じレベル内の関係

依存=仕様Aが意味を持つには、仕様Bが存在する必要があるという関係
例えば
かごから商品を消す機能(仕様A)は意味をもつには、ショッピングサイトで、商品をかごに入れる機能(仕様B)が必要

省力＝要件Aが実装されることで、要件Bの実装が簡単になるという関係

仕様間の関係を把握することは大切

繰り返しですが、仕様間の関係を把握することが大切です。
(これは仕様のトレーサビリティと呼ばれます)

理由1：仕様間の依存関係の情報が、仕様変更の影響調査の際に役に立つ。
理由2：仕様変更時にかかる工数を検討する際も役立つ。
理由3：仕様間の不整合に気づきやすくなる。

仮想の例：フロントエンドの設計担当者、バックエンドの設計担当者の間で、想定している仕様の不整合がありうる。イメージとしては、前者は商品価格の単位(100円の円)をデータベースから取得して表示すると想定して画面設計をしていたが、後者はHTMLで静的に実装する想定でAPIのI/O設計をしていた、など。この場合、どちらかの方法で機能を実装するかを話し合って合意する必要がある。BAとして、このような仕様間の不整合を発見し、設計担当者のお客様に仕様について確認し最終化します。

おわりに

以上がBAの紹介でした。
もしBAにアサインされた時、参考になれば幸いです。
BAの役割についてはBABOKという本に体系化されているそうですので、そちらも参考にされるとよいかもしれません。

参考にした情報