「読んだけど、よくわからなかった」
前回のInsight「『橋渡し役』は、どう育てるのか」で、BA人材の育成において「BABOKが体系化しているのは、問いの立て方のベストプラクティスだ」と述べた。すると当然、次の問いが生まれる。BABOKとは、具体的に何なのか。
BABOKに触れたことがある人からよく聞くのが、「読んでみたが、抽象的で実務にどう使えばいいかわからなかった」という反応だ。これはもっともな感想だ。BABOKは500ページを超える文書で、30のタスク、50以上のテクニック、6つの知識エリアが体系的に整理されている。初めて開いた人が圧倒されるのは無理もない。
しかし、BABOKの本質は分厚い知識体系にあるのではない。その根底に流れている一つの思想 ── 「ソリューションを決める前に、解くべき課題を正しく定義せよ」── を理解すれば、BABOKは実務で使える道具になる。
本稿では、BABOKの全体像を、このシリーズで論じてきた文脈 ── SaaSの泥沼、ビジネスとITの断絶、橋渡し役の育成 ── に引きつけて読み解く。
BABOKの正体 ── 「何を作るか」の前にある知識体系
一文で言えば
BABOK（Business Analysis Body of Knowledge）は、カナダに本部を置く国際的な非営利団体IIBA（International Institute of Business Analysis）が策定した、ビジネスアナリシスの知識体系だ。現行のv3は2015年に刊行されている (IIBA, 2015)。
BABOKが定義するビジネスアナリシスとは、「ニーズを定義し、ステークホルダーに価値を提供するソリューションを推奨することにより、エンタープライズにおけるチェンジを可能にする専門活動」だ。
この定義の中に、BABOKの本質が凝縮されている。注目すべきは語順だ。まず「ニーズを定義」し、次に「ソリューションを推奨」する。 ニーズの定義が先、ソリューションの選定が後。この順序こそが、BABOKが一貫して主張していることだ。
PMBOKとの違い ── 「何を作るか」と「なぜ作るか」
プロジェクトマネジメントの知識体系PMBOKを知っている人は多い。PMBOKは「決まったゴールに向けて、プロジェクトをどう管理するか」を体系化したものだ。一方、BABOKは「そもそもゴールは正しいのか。本当に解くべき課題は何か」を問うための知識体系だ。
PMBOKが「How（どうやるか）」の体系だとすれば、BABOKは「What / Why（何を、なぜやるか）」の体系だ。両者は対立するものではなく、補完関係にある。しかし、日本企業ではPMBOKは広く認知されている一方、BABOKはほとんど知られていない。「どうやるか」は体系化されているが、「何をやるべきか」の体系が欠けている。この非対称が、「言われた通りに作ったが使われない」という問題の構造的な背景にある。
6つの知識エリア ── 「問い」の地図
BABOKは、ビジネスアナリストが行う30のタスクを6つの知識エリアに整理している。これらは時系列のプロセスではなく、状況に応じて行き来する並列的な活動領域だ。
① ビジネスアナリシスの計画とモニタリング
ビジネスアナリシス活動そのものの進め方を計画し、モニタリングする領域だ。どのステークホルダーを巻き込むか、どのようなアプローチで課題を分析するか、ガバナンスをどう設計するか。他の5つの知識エリアすべての土台になる計画機能だ。
このシリーズの文脈で言えば、SaaSの導入判断を行う前に「誰を巻き込み、何を検討し、どういう順序で意思決定するか」を設計する活動に相当する。この計画がないまま導入が決まるから、泥沼が始まる。
② 引き出しとコラボレーション
ステークホルダーから情報を「引き出し」、関係者間の「コラボレーション」を促進する領域だ。ここで重要なのは、BABOKが「要求（ステークホルダーが自覚している要望）」と「ニーズ（本人すら自覚していない潜在的な課題）」を明確に区別していることだ。
ビジネス部門が「この業務をシステム化したい」と言うとき、それは「要求」だ。しかしその裏にある「なぜその業務が非効率なのか」「本当の困りごとは何か」は、しばしば本人も言語化できていない「ニーズ」だ。表面的な要求の奥にあるニーズを発見することこそ、ビジネスアナリシスの核心であり、BABOKはそのためのテクニック ── インタビュー、観察、ワークショップ、データマイニングなど ── を豊富に整理している。
③ 要求のライフサイクルマネジメント
引き出された要求を、プロジェクトのライフサイクルを通じて管理する領域だ。要求の優先順位づけ、変更管理、トレーサビリティ（要求がどのニーズに紐づいているかの追跡）を扱う。
一見地味な領域だが、実務的にはここが崩れると大きな痛みを生む。「最初に合意した要件が、いつの間にか膨張している」「なぜこの機能を作っているのか誰も説明できない」── こうした問題は、要求のライフサイクルが管理されていないことに起因する。
④ 戦略アナリシス
BABOKのv3で大きく拡充された領域だ。プロジェクトが始まる前の段階 ── 「なぜこのプロジェクトを行うのか」「組織の現状と将来のあるべき姿のギャップは何か」── を分析する。
これはまさに、このシリーズで繰り返し述べてきた「課題の再定義」に相当する。SaaSベンダーの提案を受け取る前に、自社の現状を分析し、あるべき姿を描き、そのギャップを特定する。ソリューションを選ぶのは、このギャップが明確になった後だ。BABOKは、この「ソリューションの前にある問い」を体系的に扱うフレームワークを提供している。
⑤ 要求アナリシスとデザイン定義
引き出された要求を構造化し、モデル化し、ソリューションの設計に落とし込む領域だ。プロセスモデル、データモデル、ユースケース、ビジネスルールの定義などが含まれる。
ここで重要なのは、BABOKが求めるのは複数の視点からの分析だということだ。一つの要求をデータの視点、プロセスの視点、ルールの視点から多角的に検証する。一面だけを見て判断すると、見落としが生じる。前回のInsightで「同じ内容をビジネス部門向けとシステム部門向けに説明資料を分けて作る」という育成手法を紹介したが、その根底にある考え方と同じだ。
⑥ ソリューション評価
導入されたソリューションが、当初のニーズを本当に満たしているかを評価する領域だ。v3で明確にプロジェクトの後にも拡張された点が重要だ。
「システムを入れた。でも使われない」── このシリーズの出発点となった問題に、BABOKは体系的に向き合っている。ソリューションのパフォーマンスを測定し、制約を特定し、改善策を推奨する。プロジェクトの完了がゴールではなく、価値の実現がゴールだという思想が、この知識エリアに反映されている。
6つのコアコンセプト ── BABOKの思考の骨格
6つの知識エリアを貫くのが、BABOKのコアコンセプトモデル（BACCM）だ。6つの概念が相互に関連し、ビジネスアナリシスのあらゆる場面で問いの軸になる (IIBA, 2015)。
チェンジ（Change） ── 組織にもたらす変革そのもの。何を変えようとしているのか。
ニーズ（Need） ── 対処すべき課題や機会。なぜ変える必要があるのか。
ソリューション（Solution） ── ニーズを満たす具体的な方法。どうやって変えるのか。
ステークホルダー（Stakeholder） ── 変革に利害関係を持つ人々。誰が関わるのか。
価値（Value） ── ステークホルダーにとっての便益。変えた結果、何が良くなるのか。
コンテキスト（Context） ── 変革が行われる環境や制約。どんな状況で変えるのか。
この6つの問いを、ソリューションを決める前に立てること。それがBABOKの思考の骨格だ。SaaS導入の場面に当てはめれば、「どのSaaSを入れるか」の前に「何を変えたいのか（チェンジ）」「なぜ変える必要があるのか（ニーズ）」「誰が影響を受けるのか（ステークホルダー）」「どんな制約があるのか（コンテキスト）」を問う。この問いが省略されるから、泥沼が始まる。
BABOKをどう「使う」か ── 教科書ではなくレンズとして
全部読む必要はない
BABOKを端から端まで読み通す必要はない。500ページの知識体系は、百科事典のように「必要な時に必要な箇所を参照する」使い方が想定されている。
実務で最も即効性があるのは、以下の2つの使い方だ。
第一に、「戦略アナリシス」の知識エリアを、プロジェクトの企画段階で参照する。 「なぜこのプロジェクトを行うのか」「現状とあるべき姿のギャップは何か」を構造的に考えるためのフレームワークとして使う。ベンダーの提案を受ける前に、このフレームワークで自社の課題を整理するだけで、「本当にこのソリューションが必要か」の判断精度は格段に上がる。
第二に、「引き出しとコラボレーション」のテクニック集を、ステークホルダーとの対話に活用する。 インタビュー、ワークショップ、観察、ドキュメント分析。BABOKは50以上のテクニックを整理している。すべてを使いこなす必要はないが、「表面的な要求の裏にあるニーズをどう引き出すか」の引き出しを増やすことは、BA的な役割を担う人材にとって大きな武器になる。
BACCM を「会議のチェックリスト」にする
コアコンセプトモデルの6つの問い ── チェンジ、ニーズ、ソリューション、ステークホルダー、価値、コンテキスト ── を、IT投資の意思決定会議のチェックリストとして使う。これだけで、「何のためにやるのか誰も説明できない」プロジェクトの発生率は大幅に下がる。
具体的には、新規のIT投資提案がある際に、起案者に以下の6問への回答を求める。
「何を変えようとしているのか」「なぜ今それを変える必要があるのか」「どのような方法で変えるのか」「誰がこの変革の影響を受けるのか」「変えた結果、誰にとって何が良くなるのか」「この変革を取り巻く制約や前提条件は何か」。
この6問に明確に答えられない提案は、まだ課題定義が不十分だということだ。答えを埋めるために対話を重ねること自体が、ビジネスアナリシスの実践になる。
BABOKの限界 ── そしてチェンジマネジメントとの接続
BABOKは強力な知識体系だが、万能ではない。課題を正しく定義し、最適なソリューションを推奨するところまでが守備範囲だ。そのソリューションを組織に実装し、人の行動を変え、定着させる ── つまりチェンジマネジメントの領域 ── は、BABOKの射程の外にある。
BABOKは「何を変えるべきか」を明らかにする。チェンジマネジメントは「どう変えるか」「人がどう受け入れるか」を設計する。両者が揃って初めて、変革は実現する。
このシリーズ全体を通じて論じてきた構造 ── データが「何が起きているか」を可視化し、ビジネスアナリシスが「何を変えるべきか」を定義し、チェンジマネジメントが「どう変えるか」を設計する ── は、まさにこの補完関係の上に成り立っている。
まとめ ── 「問い」が変革の起点になる
BABOKは、要件定義のマニュアルではない。「解くべき課題を正しく定義する力」を体系化した知識体系だ。
SaaSベンダーの提案を受けたとき。ビジネス部門から「システム化したい」と言われたとき。新しいプロジェクトの企画書を書くとき。そのすべての場面で、BABOKが問いかけるのは同じことだ。「ソリューションを決める前に、ニーズを定義したか」。
この問いを組織に定着させること。それが、「通じない」を越え、橋を架け、変革を前に進めるための、最も確実な一歩になる。