ハイブリッド型プロジェクトでのBAの身の処し方
昔のブログで、アジャイルなプロジェクトやチームにおけるBA（Business Analyst）の役割についてのいくつかの参考資料のまとめエントリを書いていました。
そこでピックアップした資料群は、どちらかというとトラディショナルなBAがアジャイルの文脈にどう対応していくかという観点のものが多かったと思います。しかしながら、現実にはもう少しハイブリッドな環境（←実際には過渡期を含めてこのような環境の中でどうしていくかというのは非常に大きな課題だと思っています）に直面することも多く、そこでどう考えるべきかということを、以下の記事を参考にして整理してみたいと思います。
基本的にこの記事をベースに以下に展開していますが、元記事には執筆者の過去エントリや関連記事へのリンクなども豊富ですので、興味を持たれた方は是非、元記事をご覧になることをおすすめします。
TraditionalとAgileのハイブリッドの３形態
ハイブリッドなアプローチの是非については諸々議論のあるところだとは思いますが、一旦ここではその点については判断を留保しておきます。ただ、いずれにしても現実問題として世の中にはハイブリッドなアプローチを取らざるを得ない状況もあるだろうということを受け入れた上で、その中で最大限の成果を出すためにBAとしてどう身を処していくかというのが今回のポイントです。
上にリンクを貼り付けた記事の中では、ハイブリッド型のプロジェクトを３つの類型に分けています。
- フランケンシュタイン型
- 異種交配型
- コンボ型
以下、それぞれについてその特徴とそこでのBAのあり方についてみていきましょう。
フランケンシュタイン型
これはあまり望ましくない形ではありますが、現実にはよくある（そしてみんなを悩ませる）かもしれない形ですね。
イメージとして言葉にすると、「今度のプロジェクトではアジャイル開発を採用するよ。でも、開発に着手する前にユーザから要件についてのサインオフをもらおうね。あ、それから、期限通りにすべての機能をリリースするのは必須ね！」みたいな感じのプロジェクト。ほんと、悪夢ですね。
こういうプロジェクトに放り込まれたBAの悲劇としては、
- アジャイルの名のもとに十分な時間を割り当てられない状態で、事前にすべての要件を詳細に定義するという非現実的な期待に応えなければならない
- 期限通りの全機能リリースをコミットさせられた開発チームが要件の変更を受け入れてくれない結果、ユーザのフラストレーションが溜まる（その板挟みになる）
- 結果として、ユーザやビジネスのニーズに応えられないということも含む全般的なプロジェクトリスクの増大
BAの身の処し方
フランケンシュタイン型のプロジェクトにおいては、BAとしてはそのリスクを叫び続けるくらいしかできることがありません。そんな中での一番の戦略は、最初からそんなプロジェクトにアサインされないようにすることです。
異種交配型
これは、トラディショナルとアジャイルが入り混じっているという点ではフランケンシュタイン型と同じですが、プラクティスの取捨選択において、インテグレイティブ・シンキング（Integrative Thinking）に基づいた考え方が適用されているという点で異なるアプローチとなります。
適切に「異種交配」が行われれば、BAとしてもその考え方に則って自分の身の処し方を考えることができます。基本的に、この考え方がうまくいく場合はイテレーションによるリズムの中で必要な要件を必要な時に定義し、またその優先順位を適宜見直していくことが可能になっていると思われます。
コンボ型
これは大規模プロジェクトでよく見られるタイプのやつですね。アーキテクチャーとかセキュリティとかがっちりやりたいところはトラディショナルで、それ以外の要件の変動がありそうなところはアジャイルで、みたいな形。いわゆるWater-agile-fallってやつもこの分類に入るかもしれません。
BAの身の処し方
ここでは、計画駆動のフェーズとアジャイルなフェーズを分けて考えましょう。それぞれのフェーズによって求められる能力や必要な成果物のあり方、仕事のやり方が異なってきます。
従って、コンボ型プロジェクトの場合は、それぞれのフェーズによってそれに適したBAをアサインすることでより大きな成果が得られることもあるかもしれません。
