ビジネスアナリスト

この領域について

中核となる能力

• 01要求の引き出し

  人が言ったことを記録するのではなく、必要としているものを引き出すこと。誘導せずに聞き取ること、寡黙な専門家が話すワークショップを運営すること、実際に行われている作業を観察すること、そして当たり前すぎて口にされない手順の抜けに気づくことです。

• 02課題の枠づけ

  依頼とその背後にある必要を切り分け、手段ではなく成果の言葉で課題を述べること。解決策として書かれた要求は、エンジニアリングチームが提案しえたより良い解決策を封じるもので、仕様における最も一般的な欠陥です。

• 03プロセス分析

  今日の業務がどう流れ、どこで滞り、どこでやり直され、どこで人が非公式な回避策を作っているかを記述すること。主経路より例外のほうが重要です。誰も名指ししなければ、新しいシステムが下手に扱うのはその例外だからです。

• 04要求の定義

  二人が読んで同じ結論に至るように必要を表すこと。検証可能で、曖昧さがなく、暗黙の解決策を含まず、それを正当化する事業上の成果まで辿れること。そして本当に任意であるものは、そうと分かる形で示すことです。

• 05受入基準

  要求が満たされたと示すものは何かを、境界条件と主経路以外の経路を含めて、事前に定義すること。実装後に書かれた基準は、必要とされたものではなく作られたものを記述しており、それは別の、はるかに役に立たない成果物です。

• 06業務ルールとデータ定義

  挙動を支配する条件分岐、適格性の規則、計算、妥当性の制約を、それらが扱うデータの意味、出所、所有、ライフサイクルとともに捉えること。デシジョンテーブルは、文章が覆い隠していた抜けをたいてい露わにします。

• 07ギャップ分析

  現状と目指す状態を比べ、何を変えなければならないのかを正確に特定すること。システムの中だけでなく、しばしばその周囲のプロセスと役割分担においても同様です。ソフトウェアが単独で事業成果をもたらすことはまれで、システムの境界で止まる分析は、なぜ成果が現れなかったのかを取り逃がしがちです。

• 08トレーサビリティ

  事業目標から要求、実装、テストへのつながりを保ち、変更の影響を評価できるようにし、根拠のない作業が見えるようにすること。これがあることで、スコープの削減が当て推量ではなく検討された判断になります。

• 09相手に応じた翻訳

  事業上の制約を、設計判断の助けになる形でエンジニアに説明し、技術的な制約を、それが自分にとって何を意味するかという形で関係者に説明すること。両方向が必要で、片方だけに堪能なアナリストは、一方の側が静かに無視する仕様を生みます。

よくあるご質問

よくあるご質問

ビジネスアナリストとプロジェクトマネージャーの違いは何ですか

答える問いが違います。ビジネスアナリストは何を作るべきか、なぜかに関心を持ちます。背後にある課題、要求、ルール、データ、受け入れの基準です。プロジェクトマネージャーは合意された一連の作業を届けることに関心を持ちます。順序、依存関係、リスク、期間、報告です。両者は同じ関係者と話すため混同されがちですが、責任の対象が異なります。一方は定義の正しさに、もう一方は到達に責任を負います。1人が両方を担う場合、たいてい圧縮されるのは分析の側です。デリバリーの圧力のほうが大きな声を持つからです。

ビジネスアナリストとプロダクトオーナーやプロダクトマネージャーの違いは何ですか

意図された区別は権限です。プロダクトオーナーやプロダクトマネージャーは、何を行う価値があり、どの順で行うかを決め、その成果の価値に責任を負います。ビジネスアナリストは、選ばれたものが何をしなければならないかを確立し仕様化し、その定義が正確で網羅的であることに責任を負います。実際にはこの境界は業界で合意されていません。プロダクトオーナー自身に分析を求める組織もあれば、事実上優先順位を決めているアナリストを置く組織もあり、肩書きの使い方も企業ごとに一貫していません。どちらを採用する場合でも、御社の体制の中で優先順位づけの権限を誰が持つのかを事前に明確にしておく価値があります。そこが両者の本当に異なる点だからです。

アジャイルなチームにビジネスアナリストは今も必要ですか

不要だという想定は、妥当な観察から来ています。アジャイルの実践は大規模な事前仕様を対話に置き換え、多くの文書が役に立たなくなりました。消えなかったのは、複雑な業務領域を理解し、矛盾する関係者の見解を解きほぐし、テストできる精度で挙動を述べる仕事です。単純な領域なら、プロダクトオーナーと関与の深いチームがそれを吸収できます。規制上の制約、入り組んだルール、あるいは誰も挙動を完全には知らないシステムを抱える領域では、それは相当な分量の仕事であり、担当を定めないままにすると、スプリントの途中で複数の人によって部分的に行われることになりがちです。

ビジネスアナリストはデータアナリストと同じですか

違います。ただし肩書きは緩やかに使われ、実際に両方にまたがる職務もあります。データアナリストはデータを解釈して、何が起きたのかという問いに答え、主にクエリ、統計、レポーティングを扱います。ビジネスアナリストはシステムが何をすべきかを定義し、データは成果物としてではなく、プロセスが実際にどう振る舞っているかについての証拠として用います。クエリを書けるビジネスアナリストは多く、それは大きな強みですが、経験がレポーティングだけの候補者が要求の仕事をしてきたとは限りません。

ビジネスアナリストはどれだけの文書を作るべきですか

作る人と検証する人が同じ理解に至るのに十分な量で、それ以上は不要です。適切な水準は、誤ったときのコストによって変わります。規制のある計算、不可逆なデータ移行、他組織が依存するインターフェースは、社内画面の調整とは違う精度に値します。判断に情報を与えるためではなく手続きを満たすために存在する文書は、この分野で最もよく知られた無駄であり、その分量が分析の徹底ぶりの証拠と取り違えられがちです。

ビジネスアナリストに技術的なスキルは必要ですか

本番のコードを書く必要はありませんが、技術的な理解力は成果物の質を大きく高めます。データベーススキーマを読むこと、前提を確かめるクエリを書くこと、APIが何を表現でき何を表現できないかを理解すること、アーキテクチャの議論について行くこと — いずれもアナリストが伝聞ではなく確認することを可能にします。業務領域の知識も少なくとも同じくらい重要です。その領域を理解しているアナリストは誤った答えを誤りと見抜けますが、それは一般的な分析技法では得られない能力です。

ビジネスアナリストは既存の開発チームとどのように働きますか

開発体制の拡張という形態では、アナリストはお客様の既存のプロセス — バックログ、リファインメントの場、文書化の基準、関係者との関係 — の中で働き、作業を指示するのはお客様です。プロダクトの所有、事業上の優先順位、ロードマップは終始お客様に残り、増えた分析の体制はそれらの判断を支えるものであって、決して置き換えるものではありません。Talent.IDの役割は雇用に限られます。雇用関係を保持し、給与支払いと従業員福利厚生を運用し、タレント管理を担い、雇用している本人との継続的な関係を維持します。