最近、IIBAよりBABOK(R)のアジャイル拡張版が正式に発表されましたので、連載で解説いたします。
このアジャイル拡張版の最も重要な点は、IIBAが独自に開発したものではなく、アジャイルアライアンス（Agile Alliance）との共同開発だということです。従来のスクラム開発では小規模のソフト開発が多かったため、特にビジネスアナリシスまたはビジネスアナリストのサポートをさほど必要としていませんでした。スクラムチームの中のユーザー（もしくは顧客）出身のプロダクトオーナーがいれば十分ソフト開発が成功していたのです。
ところが最近、スクラムなどのアジャイル手法を規模の大きなソフト開発に適用する試みが増えてきたため、従来のプロダクトオーナーではステークホルダー全体の要求をまとめることが難しくなり、やはりビジネスアナリストのサポートもしくはプロダクトオーナーがビジネスアナリシスのノウハウ・スキルを必要とするようになったのです。 ですからこのアジャイル拡張版が想定する対象読者は下記の2つです。
- アジャイル開発を対象とするビジネスアナリスト
- ビジネスアナリシスを必要とするアジャイル開発者
それゆえ、IIBAとアジャイルアライアンスが共同でこの「BABOKアジャイル拡張版」を作成したのです。
参考：アジャイルアライアンスの「Agile Extension to the BABOK」の解説ページ
それでは、まず第1章イントロダクションです。（以下、清水の試訳）
1.3 ビジネスアナリシスにとって、アジャイル開発は何を意味するのか？
他のアプローチによく似て、ビジネスアナリシスはアジャイル開発プロジェクトの成功の中心となります。ビジネスアナリシスは様々なグループの顧客が単一の声で話すことを可能にしなければいけません。すべてのアジャイルプロジェクトは、ビジネスアナリストとして定義された役割を持っているとは限りません。しかし、アジャイルプロジェクトはすべてビジネスアナリシスを実行してます。ビジネスアナリシスはアジャイルチームの複数のメンバーによって行われているかもしれません。
アジャイル開発の世界では、ソフトウェア要求はビジネスニーズの連続的な調査を通じて開発されています。要求は、引き出され、計画し、定義し、受け入れ基準を定め、優先順位を付け、開発し、結果をレビューするという反復的なプロセスによって洗練されます。要求の計画および分析の反復的なプロセス全体にわたって、ビジネスアナリシス実践者は、ビジネス目標が時間にわたって発展し変わるとともに、ユーザによって要求された製品の特徴が、絶えずそのビジネス目標とリンクすることを確実にしなければなりません。これは、新しいソフトウェア開発、既存のソフトウェア、ソフトウェアの移植およびデータのメンテナンスあるいは既製(COTS)ソフトウェアのインプリメンテーションにおいて当てはまります。さらに、制約のない環境の中の小さいもしくは単純なソフトウェア開発、および特定産業での非常に大規模なミッションクリティカルなソフトウェア・プロジェクトにも当てはまります。アジャイルなビジネスアナリシスは、主にプロジェクト/製品をスポンサーおよび顧客に提供するビジネスバリューを増加させることになります。
アジャイルなビジネスアナリシスはアジャイルマニフェスト(www.agilemanifesto.org)の価値および法則と密接に関係します。すなわち、
- プロセスやツールよりも個人との対話に価値を置きます。
- 我々は価値のあるソフトウェアをできるだけ早い段階から継続的に引き渡すことによってお客様の満足度を高めることをもっとも優先します。
- 動いているソフトウェアこそが進捗の最も重要な尺度です。
アジャイルなビジネスアナリシスは、適切な時に、正しい情報が詳細で正しいレベルで開発チームに利用可能であることを確実にしてくれます。ですから開発チームは適正な製品を構築することができるのです。
アジャイルなビジネスアナリシスの技術は、アジャイルな環境の中で大きな変更はありません。しかしながら、タイミング、そして、それらはどのように使用されるか、異なります。ペルソナ、データモデル、ユースケース、ストーリマップ、ビジネスルールのようなテクニックは使用され続けますが、できるだけ軽量にします。手短に使えるダイアグラム、マップ、リストのようなテクニックは、ソフトウェア開発に時間をかける厳密な仕様よりも、アジャイルなプロジェクトにより多くの価値を提供する傾向があります。厳密でないテクニック、特定のイテレーションのためにソフトウェアを構築する唯一の目的のために開発されており、イテレーションの間だけチームが理解できればよいのです。一方、長期間使用されるテクニックは、開発の範囲外でも利用されることを意図しています。長期間使用されるテクニックは、ソフトウェアが行うこと、なぜそれを行うのかをコミュニケートするために使用されるビジネスケース、憲章およびドキュメンテーションなどが含まれるでしょう。
Agileは、ビジネスアナリシスがビジネスによって提供される頻繁なフィードバックから利益を得るよい機会です。ビジネス・ステイクホルダーと連続のイテレーションの結果を再検討することによって、アナリストは以下の機会を持てます。
- 製品のビジネスニーズの密接な関係を維持することを確実にするために製品要求を精錬する、
- プロジェクトの初期でリスクを識別し緩和する、そして
- 正しいソリューションが届けられることを確実にします。
アジャイルなプロジェクトでは、可能な場合は常に、ハイリスクのアイテムは初期のイテレーションにアドレスされます。ですから、チームは問題を緩和することが可能になります。また、可能なら要求を再加工し、プロジェクトの後々まで、リスクの高いアイテムがアドレスされないことのないようにできます。リスク発見を促進しチームが有効なリスク緩和に集中し続けるのを支援することは、アジャイルチームにおけるビジネスアナリストの役割の中心です。
反復する開発プロセスはビジネスアナリシスを効率よく実行できる大変よい機会です。計画駆動プロジェクトでは、要求は開発フェーズに先立って開発されます。リスク要素が発見され、ビジネス・ニーズが変化するとともに、ある要求は変更されるかまたは完全に除去されるかもしれません。その場合、それらの要求に対する作業は無駄になってしまいます。ジャストインタイム要求を採用すれば、より少ない要求の再加工ですみます。なぜなら現在のリリースのために求められた要求のみが詳細に定義され、開発されるからです（無駄のない要求が実現します：清水コメント）。