LTS社内では、定期的にビジネスアナリシス勉強会（以下、BA勉強会）が開催されています。そこでは、ビジネスアナリシスのナレッジ集BABOKの読み合わせをおこなおこない、それぞれの知見や経験を出し合っています。
その内容の一部を、章ごとに連載していきます。記事の前半部分は解説、後半部分は参加メンバーによる議論の一部をご紹介します。
読むのに勇気が必要？！なBABOKをみんなで読もう
BABOK （Business Analysis Body Of Knowledge）は、国際的なビジネスアナリシスの啓はつ団体であるIIBA刊行の、ビジネスアナリシスの知識体系を掲載した本です。ビジョンを実務に落とし込むためのフレームワークや、ビジネスアナリストに求められるコンピテンシーなどが掲載されています。
経験豊富なビジネスアナリスト達によって編纂された本書は、ビジネスアナリシスに関わる全ての人の教科書とも言えるので、一度は読んでみてほしいと個人的には考えています。
しかしこの本、約500ページと厚く、最初から最後まで読もうとするとかなり根気が必要です。実際にBA勉強会では、「途中で心が折れました…」「なかなか開く勇気がありません…」「使用されている言葉が独特で…」といった声が聞かれました。
BA勉強会では、集まったメンバー全員で読み合わせをおこなうことで、BABOKの内容を共有する場を設け、さらに各自の経験や知見を照らし合わせて気づいたことや感じたことを出し合い、意見交換をしています。
このコラムでは、BA勉強会でBABOKについて解説した内容と、勉強会に参加したメンバーの議論などをご紹介します。
BABOKガイドv3の目次
今回ご紹介するのは、「第1章：序論」（BABOKv3 p.1-10）の部分です。
この章は、1.1 BABOKガイドの目的、1.2 ビジネスアナリシスとは？、1.3 ビジネスアナリストとは？、1.4 BABOKガイドの構成、の4項目に分かれています。1つずつ見ていきましょう。
第１章：序論
BABOKガイドの目的
BABOKを開くと、最初に出てくるがこの本の目的パートです。
ビジネスアナリストという専門性を定義している本は、少ないのが実態です。業務分析をする際の手法論というより、マインドや全体的な視点がフレームワークとしてまとまっています。そのため、ビジネスアナリシスの詳細やビジネスアナリストの仕事を知りたいときは、この本を読むことをおススメします。
海外のビジネスアナリストに話を聞くと、「このBABOKはバイブルですよ」とおっしゃっていました。それくらい、グローバルでも浸透しています。
現在BABOKはv3が出ていますがv2の時点では、ビジネスアナリシスはプロジェクトの中に走る、さらに細かい単位の一つのプロジェクトとして定義されていました。プロジェクトの立ち上がりから終わりまでの決められた範囲内で、仕様や機能を決める要件定義をする、その要件定義したものに対して実際に開発に向けて、細かい仕様検討や要求の詳細を落とす、出来上がったプロダクトに対して、要求通りに仕上がっているのかという検証をする、というのが大まかな流れです。あくまで、プロジェクトの中だけの取り組みでした。
しかし、段々とビジネスアナリシスの領域が拡大しており、v3のアップデートではその点が反映されました。
大きな変更としては、プロジェクトの前と後にもビジネスアナリストのタスクが追加されています。プロジェクトの中で、計画として決められた範囲内のみの要求分析をするのではなく、プロジェクトが始まる前から「プロジェクトの目的」や「目指す姿」を分析するということになります。また、プロジェクトで成果物ができたところが着地点ではなく、プロジェクトを振り返って「目指す姿に近づくことができたのか」「利益に対して取り組みがどのように貢献したか」を断続的に追っていきます。
ビジネスアナリシスとは？
ビジネスアナリシス自体、個別のプロジェクトに閉じたものではなく、複数のプロジェクトを回していきながら、定常業務も回す中で実施されます。定常業務からフィードバックがあれば、それをプロジェクトに反映するような動きも見られます。
概念的には、TOGAF※1のエンタープライズアーキテクチャ※2の管理に近しいように思います。TOGAFはオープングループ実施する、アーキテクチャ設計と管理に特化した方法論です。会社のビジネスアーキテクチャからアプリやデータ、テクニカルアーキテクチャまでの一連の構造を把握し、改善案を提示し、ロードマップを作成する、といった活動があります。
引用：https://opengroup.or.jp/togaf.html
※2 エンタープライズアーキテクチャ：大企業や政府機関などといった巨大な組織の資源配置や業務手順、情報システムなどの標準化、全体最適化を進め、効率よい組織を生み出すための設計手法のこと。
引用：https://e-words.jp/w/%E3%82%A8%E3%83%B3%E3%82%BF%E3%83%BC%E3%83%97%E3%83%A9%E3%82%A4%E3%82%BA%E3%82%A2%E3%83%BC%E3%82%AD%E3%83%86%E3%82%AF%E3%83%81%E3%83%A3.html
少し脱線しますが、このBABOKには「エンタープライズの問題とゴールの理解」「チェンジの推進」など、少し分かりにくい表記の箇所もあります。例えば、以下のような用語があります。
- チェンジ（change）p.417…ニーズに対応して変える行為。イニシアチブ（initiative）p.411…チェンジ目標を達成するために実施する具体的なプロジェクト、プログラム、あるいは行動。
- 引き出し（elicitation）p.419…ステークホルダーその他の情報発生源から情報を繰り返して導き出し抽出すること。
理解し慣れるのに時間を要するかもしれませんが、自身の経験に照らし合わせて理解を深めることができると良いと思います。各言葉の定義も掲載されていますので、分からない場合は参照してみてください。
ビジネスアナリストとは？
ビジネスアナリシスとは何ぞやということが書いてあるのが、この項目になります。
ビジネスアナリストはとても簡単に言うと、まず、ユーザーに「こうなりたい」というニーズがあり、それに対して「こうしましょう」という道を示し、その変化に向けて実際にプロジェクトを進める役割を持つ人です。
専門職としても存在していますが、あくまでも役割です。肩書や組織は問わず、実際にビジネスアナリストとして活躍されている方を見ても、肩書や所属はさまざまです。
資料2のプロジェクト進行中の領域を中心にやっている人もいれば、その前後を専門とする人もいます。経験領域の濃淡は所属している組織や関わるプロジェクトにより生まれると思うので、全部をカバーし全部を経験して初めてビジネスアナリスト…というわけではありません。大切なことは、流れがすべて繋がっていることを意識することです。
ビジネスアナリストの主な活動としては、以下の5つがあります。
ここで、ビジネスの開発そのものはしないというのも特徴です。ビジネスアナリストは、あくまでも自分がこうしたいという事業化や起業家の側面は無く、伴走者という位置づけが強い役割です。
BABOKガイドの構成
ここでは、BABOKの構成が紹介されています。
続く2章は、「ビジネスアナリシスの主要コンセプト」ということで、BABOKガイドを理解するために必要な用語などが定義されています。
3~8章は、知識エリアと呼ばれており、ビジネスアナリシスの専門的で具体的な知見をまとめた領域を表し、この領域には図３の6つの知識エリアに区分されています。ただし、これらは時系列で並べられているわけでなく、並列の関係で行ったり来たりします。
そして、この知識エリアはタスクとしての区分ではなく、そのプロセスの進め方そのものの概念や管理として分かれています。例えば、「引き出しとコラボレーション」では、ユーザーから要求を引き出すプロセスです。情報収集や引き出しの結果を受けて、戦略をプランニングしていきます。
細かいタスクは、後々出てくると思うのでそこで触れたいと思います。
9章では、基礎コンピテンシーの部分で、ビジネスアナリシスの効果的な実践に役立つ立ち振る舞い、特性、個人的資質が記述されています。
そして10章は、テクニック部分で、ビジネスアナリシスのタスクを実行するための手段が、50のテクニックとして記述されています。
11章では、専門的視点としてビジネスアナリシスの作業を、5つの視点から記述されています。
勉強会に参加したメンバーの議論
ビジネスアナリストのプロジェクト前後におけるかかわりについて
何か質問や、メンバー同士で聞きたいことがある人はいますか。
v2とv3では、ビジネスアナリシスの範囲がプロジェクト前から始まり、プロジェクト後のソリューション評価まで継続していることが印象的でした。コンサルタントとしてプロジェクト後もかかわりを継続して、改善活動に携わっていくことは大事だと思いつつ、なかなかそれができていない現状があるのかなと思います。
システム導入したら終わりになってしまう。みなさん実際のプロジェクトではどうですか？
そうですね、私はあるお客様向けのシステム導入プロジェクトに要件定義から入って現在は運用を引き続きご支援しています。
その中で、ソリューション評価の「元々何がやりたかったかということに立ち戻って考えること」は理念としてはあります。しっかり情報やデータを出せているか、引き続き改善活動をやっていきましょうか、とか。
個人的には、ALM（アプリケーションライフサイクルマネジメント）※3にも興味がありまして…システム導入が終わりではないよという考え方です。
このビジネスアナリストの役割や目的に関しては、共感する部分も多くあわせて知識を深めたいと思っています。
私が担当していた案件の場合は、まさにいくつかのプロジェクトと定常業務が同時並行で走っていて、説明いただいた内容に当てはまるなと思いました。
ヘルプデスクのご支援も、おそらく定常業務のサポートという立ち位置ですが、やはり定常業務の中から現場の課題は出てくるので、来期はここに注力したいですねといったコミュニケーションができるのが理想かなと思います。
ありがとうございます。
プロジェクト後のソリューション評価や取り組みが結果を出せているかは、難しいですよね。
ビジネスアナリシスは、社内で自社のアーキテクチャを管理していくことが前提とされていますが、コンサルタントは切り取られたある領域・フェーズを任せていただくことが多いので、概念的にも全部が合致するわけではないんですよね。
海外のカンファレンスでは自社のアーキテクチャ管理をテーマにしたセッションを見かけます。
自社のビジネスプロセスの構造や、どのようなアプリケーションがあり、裏側にどのようなデータベースがあるのかが構造的に管理されており、そこからプロジェクトって切り出されているんですよね。
その場合、プロジェクト後のソリューション評価も、社内のアーキテクトと呼ばれるような人たちが管理しているようです。
なので、1人のビジネスアナリストがプロジェクト前からプロジェクト後まで全部やるというよりは、ある程度役割分担されているのかなと思います。
ジュニアビジネスアナリストにオススメの入門方法
BABOKって頭から読むと結構しんどいなと思う部分があって、特に最初のモニタリングの部分が難しく…これって結構経験を積んだシニアビジネスアナリストが担うところなのかなと感じました。
特に、エントリーしたてのジュニアビジネスアナリストは、どこから読むのがいいですか。
そうですね…。ECBA（ビジネスアナリスト入門資格）の資格を取得された、Cさんどう思いますか。
一番イメージしやすいのは、「引き出しとコラボレーション」だと思います。LTSのコンサルタントのほとんどは、ここを経験しているのかなと思います。あとは、「要求アナリシスとデザイン定義」や「要求のライフサイクルマネジメント」もイメージしやすいと思います。
実務的には、要求アナリシスやデザイン定義は頭に入れておくとよいと思います。 戦略アナリシスは、経験がなくても知識を頭に入れておくだけで、いざスタートするときにやり易いと思います。
ライター
エディター
自動車部品メーカーにて、グローバルで統一された品質管理の仕組みの構築・定着化を支援。産休・育休を経て、CLOVER Lightの立ち上げ、記事の企画・執筆を務める。現在、社内システム開発PJに携わりながら、アジャイル開発スクラムを勉強中。Scrum Alliance認定スクラムマスター（CSM）、アドバンスド認定スクラムマスター（A-CSM）、Outsystems Delivery Specialist保有。（2023年12月時点）
