超上流の知識体系「BABOK(Business Analysis Body of Knowledge)」が、注目を集めている。雑誌やWebでも、BABOKに関する記事は増えているし、取材先でも、「BABOK」という言葉を、当たり前のように耳にするようになった。

 BABOKを開発・出版しているのは、カナダのIIBAという団体だ。昨年12月7日には、IIBAの日本支部が、BABOKの日本語版である「ビジネスアナリシス知識体系ガイド(BABOKガイド)Version 2.0」」を発行している。

 実は、筆者は、2008年12月23日にIIBA日本支部が正式に発足する前に、支部を設立するための準備室にメンバーとして参加していた。この当時は、BABOKという言葉も、BABOKが対象としているBA(ビジネスアナリシス)という言葉も、世間にはほとんど知られていなかった。“プチブーム”のような今の状況は、当時を思えば、なかなか感慨深いものがある。

 BABOKは、BAとして行うべき活動を、体系的にまとめたものである。BAとは、簡単に言えば、ユーザーの様々な要求を分析し、問題解決のためのソリューションを提示する活動のことである。BABOKは、PM(プロジェクトマネジメント)における「PMBOK」のように、BAという活動の“バイブル”に当たる。

 超上流工程の「リファレンス」をはじめて提示したという意味で、BABOKには極めて大きな意義がある。しかし、2006年7月にバージョン1.6を最初にリリースしてから4年しかたっていないこともあり、BABOKにはまだ課題も多い。その一つが、「基本的な考え方がウォーターフォール型になっていること」(BAやBABOKに詳しいコンサルタントの宗 雅彦氏)である。

アジャイル型にうまく適用できない可能性がある

 BABOKでは、BAの活動を7つの知識エリアに分類し、各知識エリアで使えるタスク/テクニックを記述しているが、実行の順番までは定義していない。あくまでも“知識体系”という位置付けであり、プロセスや方法論ではないからだ。

 とは言うものの、BABOKには、

(1)「エンタープライズアナリシス」知識エリアで、スコープやビジネス要求を定義する
(2)「要求アナリシス」知識エリアで要求仕様を作成する
(3)「要求のマネジメントとコミュニケーション」知識エリアで要求を管理する

という大きな構造がある。宗氏は、「これはウォーターフォール型の考え方そのもの。BABOKがウォーターフォール型を想定しているのは一目瞭然」と語る。

 言うまでもないが、ウォーターフォール型とは、開発工程をいくつかのフェーズに分割して,前フェーズの成果物を次のフェーズの入力としながらフェーズを順番に実行していく、最も典型的な開発プロセスである。

 だが、最近では、特に欧米を中心に、ウォーターフォール型ではないアジャイル型の開発プロセスが急速に普及している。実際、宗氏によれば、米国でアジャイルを適用したことがある組織の割合は、69%にも及ぶという(「Agile Adoption Survey 2008」の調査結果)。日本でも、先駆的なユーザー企業を中心に、アジャイル開発プロジェクトは増えている。

 ウォーターフォール型を想定している今のBABOKは、急増するアジャイル型プロジェクトにうまく適用できない可能性があるのだ。

アジャイルに対応するよう、BABOKを拡張へ

 この問題は、実はIIBAも認識していて、昨年末からBABOKのアジャイル拡張プロジェクトを本格化させている。宗氏もこのプロジェクトのメンバーの1人である。

 このプロジェクトでは、10人近いメンバーが、BABOKにアジャイル的な考え方をどう取り込むべきかを議論している。「アジャイル型では、BAの活動は反復ごとに行うことになる。そのときに、誰がBAの活動を担うのか、といったことを議論している」(宗氏)。BABOK開発の責任者であるIIBAのケビン・ブレナン氏によれば、プロジェクトの成果は、今年中か来年早々にドキュメントとしてリリースする予定で、BABOKの次のバージョンにも反映される。

 BABOKが広く普及するかどうかは、プロジェクトの現場にうまく適用できるどうかが大きなポイントとなる。その意味で、ウォーターフォール型だけではなくアジャイル型にも適用しやすくなれば、BABOKの普及に拍車がかかるかもしれない。

 なお、ITproでは現在、宗氏の連載「超上流の知識体系、BABOK全解説」を掲載している。この連載では、BABOKの中身や活用方法などを分かりやすく解説していく予定だが、連載の中で、次世代BABOKの方向性として、BABOKのアジャイル拡張についても触れる予定である。連載にも、ぜひ期待していただきたい。