1st Conference(アジャイル初心者向けのカンファレンス)にて、Erin McManus氏とRyan McKergow氏がis there a future for business analysis?と題した講演を行い、組織がアジャイルを導入するときのビジネス分析の役割について話をした。InfoQは両氏にインタビューし、ビジネス分析の必要性、ビジネスアナリストの役割がアジャイルによってどのように影響を受けるか、どのような変化が生まれるか、そしてアジャイルチーム向けの具体的なビジネス分析の実践について話を聞いた。
InfoQ: 組織がアジャイルを導入してもビジネス分析は必要でしょうか。
McKergow: はい。ビジネス分析はアジャイル開発においても重要です。ビジネス分析は批判的思考であり、届けている価値に対する挑戦なのです。私たちが解決しようとしている問題はなんなのか、なぜ、ソリューションとしてソフトウエアを解決しているのか。
また、ビジネス分析には行政の規制の変化や企業の方針、業界標準のような組織の持つ複雑さへの理解も含まれます。アジャイルは従来の方法と比べてことなるアプローチを採用するからといって、これらの領域のことを忘れるということではありません。
McManus: Ryanと私が伝えているのはソフトウエア開発に対する考え方は進化し続けているのでソフトウエア開発チームの役割も進化する必要があるということです。とりわけ、アジャイルの導入では、将来、それぞれの役割がどうなるのかを考えるのは重要です。アジャイルな組織でもビジネス分析は絶対に必要です。
InfoQ: アジャイルはビジネスアナリストにどのような影響を与えますか。
McKergow: ソフトウエア開発のその他の役割と同様、アジャイルはビジネスアナリストが提供する価値に対して挑戦を突きつけます。"この役割の専門家は必要なのだろうか"。それゆえ、アジャイルは横断的なチームを推し進めるのです。ソフトウエア開発に必要なすべてのスキルセットはチーム内にありますが、必ずしも専任の純粋な専門家が必要だということではありません。純粋なビジネスアナリストが必要か。純粋なテスターが必要か。このふたつは単なる例で、もっと多くの役割が挑戦を受けます。
InfoQ: アジャイルを導入したときに現れるビジネス分析の変化について例を教えてください。
McManus: アジャイルはチーム内の協力を推し進めます。その中でビジネス分析の変化の例として、共有の言葉を作るためのツールを手に入れるということがあります。これは振る舞い駆動開発(BDD)の導入でも見られます。ビジネスアナリストはBDDのフォーマットであるGiven, When, Thenを使って受け入れ条件を記述するようになります。このようなシナリオを書くことで複雑な機能性を扱えるようになり、非技術者が理解できる言語でコミュニケーションができるようになります。
また、分析が完了するタイミングとその量についても変化が見られます。リーンな製造業の"ジャストインタイム"なアプローチで分析が行われるのです。必要なとき必要なことが行われるようになります。これによって分析プロセスに無駄がなくなるのです。
McKergow: 私の視点からは、従来型のビジネスアナリストからT型のアナリストへの変化と見えます。分析の専門家かもしれませんが、そのスキルはアジャイルのより広い範囲で活用できるのです。
McManus: 賛成です。開発プロセスにはたくさんの協力があります。ビジネスアナリストがテスターになって開発チームが機能の要件をすべて満たしているかを確認するケースやプロダクトオーナー代理になって、ビジネスサイドの代表として機能を閉じるケースを見てきました。アジャイルチームには引き受けるべきさまざまな責任があります。"私の仕事ではありません"というのが通用しないのです。できるならやる、ということに挑戦しているのです。特別な知識が必要ではない仕事には専門家は必要ないのです。
McKergow: 私は最近テスターの役割をにないました。主に手動の探索的テストですが、システム間のデータの流れを考える興味深い学習機会となりました。システムのデータを更新するなら、関連するシステムを更新も更新されるということが確信できました。また、SQLの知識の更新もできました。データベースに問い合わせるというのは分析にとって便利なスキルだということもわかりました。特に、どのくらいのユーザーが特定の機能を使っているのかという定量的な分析に便利でした。
McManus: 変化によって私もある種のT型のスキルを手に入れました。優れたビジネスアナリストは顧客と顧客がソフトウエアをどのように使うかについてより自覚的です。ビジネスがその製品を欲しがる理由だけでなく、その製品が解決しようとする課題や顧客の製品の使い方について理解することに興味を持つのです。
ビジネスアナリストはチームの動きに影響を与える面白いポジションです。プロダクトオーナーと緊密に働き、開発チームと緊密に働き、意思決定についての共通認識を駆動するのはチームに製品に対するオーナーシップを持っていると感じさせるための素晴らしい方法です。共通の目的を確立するのにも役に立ちます。
このように、ビジネスアナリストがT型になってチームにさらなる価値を提供するのはさまざまな経路があります。
InfoQ: ビジネスアナリストではなく、アジャイルチームが自分たちで分析をやるのはどうでしょうか。
McKergow: チームが自分たちで分析をしたいというのは、素晴らしいことです。それを止めるものはありません。ビジネスアナリストにとって挑戦となるようなことにはとても面白いでしょう。しかし、ビジネスアナリストの不在は詳細な分析業務を避けることの言い訳にはならないということも覚えておく必要があります。規制や政策の調査、複雑なビジネスプロセスの理解などです。誰かがこのようなことに責任を持つ必要があります。
McManus: 私はビジネスアナリストのいないチームと働いたことがあります。そのときは不自然だとは思いませんでした。開発者が自分たちで顧客にインタビューし、ソリューションを開発したのです。このような環境では専門のビジネスアナリストは不要です。
InfoQ: アジャイルチームにおすすめの具体的なビジネスアナリストの実践はありますか。
McKergow: チームの誰もが使える方法があります。私のおすすめは以下です。
- 受け入れテスト駆動開発のスリーアミーゴス - ビジネスアナリストの代わりにビジネスオーナーを巻き込む。開発者とテスターとプロダクトオーナーで開発しようと計画していることについて話します。それぞれのストーリーの受け入れ条件の細部まで話し合います。3つの異なる視点の協力を強化するのです。InfoQはスリーアミーゴスの考案者に対するGeorge Dinwiddie on the three amigosというインタビュー記事があります。
- ストーリーキックオフ - 上と同じようですが、特にストーリーの開発開始に特化しています。どのようなストーリーを開発するかを皆で議論します。私はこの技術について自分の会社のサイトにHow to introduce Story Kickoffs to your teamという記事を書いています。.
- デザインスタジオ - チームが一緒に製品を設計できるようにするための手法であり、私も最近使いました。チームが問題の理解についてワイヤフレームを書き、異なる設計からそれぞれの考えを弾ませながら進め、最終的な設計に落とし込みます。Jason Furnell氏はこのプロセスについて包括的にFacilitating Collaborative Design Workshopsという記事でまとめています。
もし、ビジネス分析が必要な状況であれば、これらの技術を使ってみてください。スキルを広げ多くの価値を提供できるでしょう。
Rate this Article
- Editor Review
- Chief Editor Action