多くのアジャイルソフトウェア開発プラクティスの文献にあるものと、アジャイルチームが実際に直面するものにはギャップがある。このギャップを埋めるべく、その役割と価値を担い、状況を変えていくことが、アジャイルなプロジェクトにおけるアナリストの役割だ。（少なからず聞いたことがあるが）「インチキアナリストなんて必要ない」と態度に出してしまうのは、言うまでもなく間違いだ。この記事では、ありがちな状況として、開発チーム寄りではなく業務寄りになるような場合でも、ビジネスアナリストはアジャイルなチームワークと実用的な連携を行うことができる、ということを主張していく。
なぜ、ビジネスアナリストの役割に心を砕いているのか？
アナリストが居なければ、実際問題としてギャップが発生してしまうというのが私の主張だからだ。例えば、
- より大きな組織的問題を調査するのは誰だろうか？
- 経営者の要求（最終的にソフトウェア開発の費用を払う顧客）と「ユーザ」（ひどい用語だがそれはまた別の話）のニーズとの間に横たわる対立を、彼らの作業が効率的になるように明確にしていくのは誰だろうか？
- 一定のやり方で仕事をしている1500人もの人間がいる中、新しく作りあげたソフトウェアが彼らの労働形態を大きく変えてしまう、という事実を明確にするのは誰だろうか？
- こういった人達に、起きた変化がビジネスをスムースに継続させることを請け合い、組織上の新しい手続きを設計する手助けするのは誰だろうか？
- 顧客との入念なコミュニケーションが不足しているせいで、ビジネスが無駄骨に終わりそうだという判断するのは誰だろうか？
- まだまだ続けることはできるが、状況は理解してもらえたと思う
Alan Cooper氏は、Agile2008で素晴らしい発表(リンク)をしてくれた。彼は、アジャイルプロジェクトにはインタラクションデザイン、つまり、人間がどように振る舞うべきかを理解する必要性を説いており、最終的な成果物が実稼働環境で効果的に動作することを保証するための技術的なガイドラインには、顧客が考えつくように手助けできる人がいるべきだと、情熱的に話してくれた。
この役割は理想的かつ効果的に言えばビジネスアナリストが引き受けるべきもので、本来そうすべきだったもの、というのが私の主張だ。幅広いビジネス的な要求を理解し、この要求を技術的な話題に終始するチームメンバーに対して筋道立てて説明する、という私たちがずっと訓練してきたことの一部にすぎない。伝統的に、人間の要求に取り組んできたのはビジネスアナリストという人種だったのだ。
ビジネスアナリストはチーム成功に貢献する
私が強く信じているのは、この役割の重要性に重きを置いていないことが、今日の多くのアジャイルチームにおける一つの大きなギャップとなっていることだ。多くの組織では、アナリストという役割には足かせがはめられている。それは組織の構造上の問題で、マネジメントの後押しが無いことが原因となって、効率的な任務の遂行を約束できなくしている。ビジネスアナリストは、顧客の代弁者（技術者というより、ビジネス的なソリューションを提供するチームの一部）と考える必要がある。政治的な権限を与えられ、特定の領域の見識を信頼されているビジネスアナリストは、理想的には情報技術グループではなく、業務改善を行う領域に向けて報告するべきだ。こうすることで、ビジネスアナリストは、「技術の信者」としての技術グループの一部と認知されるのではなく、明確なビジネス価値に基づいて変化を推し進める権限を与えられるようなる。
システムアナリストの場合は？
システムアナリストではなく、ビジネスアナリストについて話しているという違いに注目して欲しい。「システムアナリスト」が活躍する場はどこにあるのだろうか？システムアナリストはしばしば効果的にビジネス分析をするためのスキルを持っている。ビジネスアナリストとシステムアナリストそれぞれの視点に基づいて考えれば、その役割は異なるものだ。ビジネスアナリストは、ビジネス的な要求に注目し、それを理解することで成り立っているが、一方、システムアナリストは、通常、技術寄りのスタンスであり、技術的な解決方法に拘っている。時として、実際にビジネス上の問題を解決するための弊害となるぐらいに（「わぉ、私はいい解決方法を知っているよ!」）。システムアナリストはよいビジネスアナリストとなり得る。しかし、技術的な解決方法への拘りが本来の目的の邪魔していないかについて慎重になる必要がある。
何故アナリストを使うのか？「顧客」が必要なのだ
アナリストは、ビジネス変革の遂行が成功するように気に掛けてくれている数多の「ステークホルダ」と親しくなることに時間を使う。アナリストは、ビジネス的要求を多次元的に理解する必要がある。最終的なゴールと目的を経営陣と議論することもあれば、新規であったり変更されたビジネスプロセスに法律や訴訟上の影響がないかを法務部と一緒に確認したり、オフィスや倉庫のレイアウトに変更が無いかを調達部門と一緒に確認したり、原材料や製品が配送されるまでのフローに影響を与える可能性がないかを確認したり、はたまた、新しい承認フローには潜在的にボトルネックが生じる可能性があると考えている管理職と...挙げればきりがない。
分析調査をしていく過程で、こういったビジネス上の問題を解決するためには、技術的な投資するべきであることが明らかになる。この時点で、アナリストの役割は多少変化し、技術的に実現可能かどうかの議論に関わるようになる。つまり「自社開発か既製品の購入か」であったり、内製か外注かといった議論のことである。この段階では、伝統的なビジネスアナリストの役割というのは投資対効果を検討することに関与することにあり、アジャイル手法を使っていても、組織にもたらされるビジネス上の利益がプロジェクトにはあると説明すべき、という点では同様である。こういった評価を得ずにいると、アジャイルのバックログ管理で必要とされる継続的な優先順位付けで全体像を見失う可能性があり、結果的に要求が形骸化することになる。
決定が下され、技術的なことに幾らか投資することになると、アナリストの役割はまた変化する。要求の番人となり、ストーリを取りまとめ、そのガイド役となる。ここではユーザや顧客になりかわり、技術的な解決方法を取ることに価値があるビジネス的要求を明確にし、他のチームメンバーと協調し解決していくことで、アナリストはアジャイルプロジェクトに活発に関わり、アジャイルソフトウェア開発プロジェクトチームにとって重要なメンバーとなる。
アナリストはストーリを取りまとめるために、チームにとっては顧客の代弁者として行動し、ユーザストーリの定義をファシリテートし、数多くのステークホルダ達にとってはプロジェクトの代弁者になりながら、プロジェクトチームと共に働く。この「顧客」という言葉は、多くのアジャイル関連の文献では安易に言及されているが、均質な特徴を持った個人ということはなく、むしろ、不特定の多くの「ステークホルダ」を指す。「ステークホルダ」は非常に多様で、矛盾があり、負けず嫌いで、時としてビジネス的要求が何なのか、何が「完了」しているかについてすら見解が一致せず否定的である。
ここで言いたいのは、私が「オンサイト顧客」を信頼していない、ということではない。アジャイル開発プロセスを成功させるためにははオンサイト顧客が必要であると強く信じているということだ。我々が直面する難問には、多くの顧客の声が寄せられ、そこにはしばしば矛盾のある注文が含まれている。アナリストは、いかなる状況でも素早くノイズをフィルタし、プロジェクトに関わる正しい顧客の代弁者として手助けする必要がある。
では実際にアナリスト何をするのか？
アジャイルプロジェクトでは、アナリストはストーリの番人でもある。つまり、開発の過程をガイドしながら、チーム間のコミュニケーションをファシリテートもするし、プロジェクトを開始した時の幅広い調査に基づいて「こうしたらどうなりますか？」といった質問を投げかけたり調査し顧客の担当者を手助もする。また、背後にある正式な組織体に則って、ステークホルダ達の複雑な政治的影響力の関係を理解すること、そして、競争優位性や顧客満足が求められていることを理解し実在のクライアント(提供されたシステムのサービス料を実際に払う人)に接近し資金を引き出す能力 - つまりはビジネスとして成功するために必要な全てを行う。
アナリストには広範囲にわたる調査力と対人交渉力、物事を吟味したり批判しながら考える能力と、顧客の担当者が最終的にシステムを作り上げられるように、多様なモデリング技術とその他のツールを使い、ストーリを把握する手助けをすることが求められている。アナリストは一連のストーリを明確な形で表現し、それが理解しやすい方法で「完了」しているのかどうか明確にする。また、テスタや顧客と共に受け入れ基準をストーリ全体の戦略に基づいて確認しつつ明確にする。
最高のアナリストはストーリを検証するすべての受け入れに関わり、システムの相互作用に関する設計に積極的に関わる。彼らは、いろいろな方法で幅広くユーザ達にシステムを使ってもらうことが必要になることを理解している。そして、相違する要求を理解し、本質的に異なるステークホルダが作業できるように、設計で吸収するように相違をならしておく。
アジャイルアナリストはよい設計者でもある。はるかに深い理解をもってシステムへの要件を文書化する。画面フローの持つ意味を理解し、処理フローを実情に見合ったものにし、色やフォントであったり画面レイアウトや応答速度についても、システムを使う人の生産性に影響することを知っている。働く人が仕事で使いたいと思うような、真に使いやすいシステムを作る機会を窺っていて、直感的で自然なインタフェースを作る手助けをするために力を尽くしている。理想を言えば、インタフェースは見えないものであり、使う人がそこにあるとさえ気付かないように簡易であるべきだが。
伝統的な分析手法である「howの前にwhat」という手法はアジャイルプロジェクトでは使えない。アジャイル開発プロセスが持つ生産性の高いイテレーティブなサイクルでは、ほとんどの場合「how」を提示することで「what」を理解する。
見た目と雰囲気に関しては、アジャイルアナリストはシステムの使い勝手に取り組み、そこに焦点を当てる手助けをする。
アジャイルアナリストは、プロジェクトチームと一緒に働くことによって本当のビジネス価値を顕在化し、顧客の仕事を楽にし、より生産的になる何かに顧客が気付く手伝いをし、それによって高い満足感をもたらし、顧客に何度も何度も取引したいと思わせる「引力」をもたらすことに力を注いでいる。
アナリストの役割は誰が行うべきか？
スクラムプロジェクトにおいて、プロダクトオーナーであったり顧客の代弁者は、顧客に成り代わって行動する権限とサポートが得られるのであれば、完璧にアジャイルアナリストの役割に適している。アナリストというものは、積極的にプロダクトバックログを管理し、優先順位を確認する立場にある。ステークホルダとの関係を築き、技術的な実体を把握することで、アナリストはプロジェクトにおける価値の提供を管理することができる。
アジャイルアナリストはプロジェクトチームにおいて、積極的かつ生産性の高いメンバーである必要がある。長ったらしい「やっておかなければいけないこと」をリストにした巻物を作ろうとするのではなく、多くの顧客の生の声を、「あなたの考えているのは...」という問いかけを常に投げかけて導きながら代弁し、自分たちがもたらすプロダクトが、顧客の多様で矛盾している要求に対応できることを確認しながら、欠陥について確認と理解し、過去から現在におけるユーザストーリに基づいて、手順と課題についてプロジェクトチーム全体で議論、検討しする。
アナリストの役割は成功に必要不可欠である
技術は人の要求を満たす為に存在している！
-- Malcolm Watson氏, メルボルンにある Pronto Software 社の開発マネージャ
ビジネスアナリストのコミュニティは、現実世界での価値と顧客満足をもたらすシステムを作りあげるために、アジャイルチームのアクティブな参加者となり、一定の水準を満たすように踏み出す必要がある。課題を、そこに潜む要求が理解できるように構成要素まで紐解いたり、競争上の優位性と顧客満足を生み出すせるような解決方法をもたらせるようにプロジェクトチームの積極的な一員として働くことで、こういった行動は「アナリスト」の役割の一部として還元される。
補足: ここで私が語る「アナリスト」とは誰のことか?
国際ビジネスアナリスト協会(リンク)(IIBA) では、ビジネスアナリストを「業務プロセスや方針、情報システムを変更できるようにを要求を引き出し、分析し、コミュニケーションをとり、確認することで、関係者の間の調整弁として働く者」と定義している。(リンク)
ビジネスアナリストの役割は"普遍的なコミュニケータ"と説明することができるだろう。様々なステークホルダの考え方をはっきりとした明確な方法で理解し代弁すること、発見的な方法で経営者を支援し、それにより突発的で不明瞭なビジネス的要求を明らかにすること、そして、明確になった要求に本当の価値を与えることなどだ。この役割は、現在使われている開発手法や、BABoK? (Business Analysis Body of Knowledge)(リンク)の最新版が明確に認めている価値や、アジャイル手法の重要性や、アジャイルプロジェクトで活発に更新されているビジネス分析手法であっても超越する。
国際ビジネスアナリスト協会(IIBA)について
国際ビジネスアナリスト協会は、自らを「プロフェッショナルなビジネスアナリスト達のための世界を代表する協会」と謳っている職業団体だ。IIBAは世界13カ国に78の支部を持ち、44カ国に7128人の会員を持つ。その使命は「ビジネスアナリスト向けの開発と保守標準の資格検定することと、その検定機関となること」である。
IIBAはBABoK(TM)を策定しており、これは、プロフェッショナルなビジネスアナリストが持つべき幅広い技術と能力の知識体系と言えるだろう。BABoK(TM)は方法論を選ぶものではなく、バージョン2.0となってからは、アジャイル手法がソフトウェア開発のビジネス的な問題を解決することについて明白に重要な貢献をしている。
IIBAはビジネスアナリストの資格試験を行っており、認定ビジネスアナリストプロフェッショナル(CBAP?)は、BABoK?周辺の知識と実務経験を持っていることを証明するものである。
著者について
Shane Hastie氏は、オーストラリアとニュージーランドを基点にソフトウェア教育のトレーニングとコンサルティングを行っている。アジャイル手法、ソフトウェア開発マネジメント、ビジネス分析、ソフトウェアテスト、といった教育コースやコンサルティングサービスを行っている。Shane氏は認定ビジネスアナリストプロフェッショナル(CBAP(TM))と、2007年に情報管理の修士の学位を取得している。彼が修士で行った研究は、オーストラリアでERPベンダがAgile手法を実践することで得られる利益についてだった。また、認定スクラムマスタも取得している(2008年12月2日)。Shane氏は25年以上にわたり、金融業界から航空会社、製薬会社、艦隊運用、通信業界まで手広くビジネス的な問題を技術的に解決してきた実績がある。