LTSコラム

アジャイルへの適用を迫られる海外のビジネスアナリスト(後編)~BBC2017から見るビジネスアナリシスの最新動向~

こんにちは。LTSの大井はるかです。前編に引き続き、今回もBBC2017(Building Business Capability)のレポートをお送りします。前編「アジャイルへの適用を迫られる海外のビジネスアナリスト~BBC2017から見るビジネスアナリシスの最新動向~」では、世界のビジネスアナリストはアジャイルメソッドの導入に大きな関心を寄せていることをお伝えしました。後編では、さらに踏み込んで、アジャイルメソッドが導入された環境で求められるビジネスアナリスト像についてレポートしたいと思います。

アジャイルの世界はこれまでと異なる思想

アジャイルメソッドが導入された環境でビジネスアナリストはどうあるべきかを考えるには、企業がウォーターフォール型からアジャイル型に移行することで、何がどのように変化するのか理解しておくことが欠かせません。コラム本編に入る前に、まず2つの方法論の違いについてお話します。

これまで企業が採用してきたウォーターフォールと、近年導入を進めているアジャイルでは、思想が根本的に異なります。
ウォーターフォールは建築の方法論に由来を持つ開発方法論です。“計画通りに正確に製造する”という思想で、最初にしっかりとすべての要件を決めて計画を立て、その通りに各工程でものを作りこんでいく進め方が特徴です。ウォーターフォールは計画の順守が原則で、プロジェクトの成否はQCD(計画で定められた要件を計画した期間、予算内で実装できているか)で計測されます。

このQCD全体を管理するのがプロジェクトマネージャーであり、QCDのうち、主にQualityの観点から、ビジネス側の要求が要件としてしっかりと計画に反映されること、そして計画された要件が実装されることを担保するのがビジネスアナリストです。ウォーターフォール型ではプロジェクトマネージャーとビジネスアナリストが協力して、QCDを担保することがプロジェクト成否の鍵を握ります。

 

 

それに対して、アジャイルは“その時に必要な機能をタイムリーにリリースする”という思想を持ちます。しっかりと計画を立てても長い開発期間の間に要件が陳腐化してしまうというウォーターフォールの欠点を補うために考案された方法論です。
アジャイル型のプロジェクトでは、開発対象のシステムを小さなパーツに分解し、より優先順位が高いパーツから順に作ってリリースしていきます。初期計画を立てないわけではありませんが、その時点では大まかなことだけを決めておき、実装に向けた各パーツの細かな設計はあくまで各パーツの開発直前に行います。この開発工程において、どのパーツから作るか決める人をプロダクトオーナー、プロダクトオーナーの指示に基づいて素早く開発からリリースまで進められるように開発チームを指揮する人をスクラムマスターと呼びます。このプロダクトオーナーとスクラムマスター率いる開発チームが連携して開発を進めます。

 

 

アジャイル型の開発は計画が変わることが前提のため、計画に対するQCDの実績で成否を評価することが出来ません。代わりに、リリースしたシステムがビジネスにどれだけ貢献したかで評価されます。そのため、アジャイル型の開発では、プロダクトオーナーが顧客や市場、自社の状況をしっかりと把握して、妥当な優先順位を決められることが、プロジェクトを成功させる肝となります。

アジャイルな世界で求められるビジネスアナリストとは

さて、話を戻して、ここからは本題であるBBC2017で話されていた今後のビジネスアナリスト像についてお話していきます。
前述のようにウォーターフォール型からアジャイル型に移行するには多くの変化を伴いますが、何より大きな変化は、プロジェクトの成否を判断基準が「QCDの順守」から「ビジネスへの貢献度」へと変わり、貢献度が高くなるよう開発対象の要件が流動的になることです。
これは、開発チームを擁するIT側だけではなく、要求を出すビジネス側にとっても大きな変化です。これまでは計画時にビジネスアナリストに要求を伝え、その後は任せていれば開発が進みました。しかし今後はプロダクトオーナーとして、開発期間中ずっと市場や開発チームの状況を踏まえながら、要求の優先順位を判断し続けていくことになります。

顧客ニーズや市場の変化をタイムリーに要求に反映させることが出来るのは、ビジネス側にとって大きなメリットです。しかし、現業のマネジメントでただでさえ忙しいビジネス側がコンスタントに要求を出していくのはとても骨が折れる作業でもあります。そもそも、すべてのビジネス部門が「自分たちのあるべき状態」をイメージして積極的に要求を出せるわけでもないですし、ビジネス上の要求をシステムの機能として反映させるITリテラシーが足りないこともあります。ビジネス側にとって、アジャイル環境下でコンスタントに開発側に要求を出し続けるというのは相応に負担がかかるのです。

 

 

変わるのは要求を出すタイミングだけではありません。要求の伝え方も変わります。これまで、開発チームはビジネスアナリストから渡された仕様書に基づいて指示通りにコードを書いてきました。しかし、アジャイルでは開発を始めるギリギリまで厳密に要求を決めませんし、きちんと指示文書を作ることも少ないと言われています。そのため、ビジネス側が開発チームに対して「自分たちは今どこに向かっているのか」、「何故この機能が必要なのか」を明確に説明し、文脈を理解してもらわないといけません。これなしでは、開発チームは地図もコンパスも持たずに、ただ指示に従って歩き続けることになってしまいます(実際に、BBC2017で開発チームがビジネス側の意図を理解しないまま開発を進めて失敗した、または現在進行形で困っているという話を複数聞きました)。

アジャイル型への移行に伴い、ビジネスアナリストにはこうしたビジネス側に足りない余力やスキルを補いつつ、ビジネス側の意図と文脈を読み取り、ビジネス側と開発チームの間にあるコミュニケーションの狭間を埋める役割が期待されています。本質的にはこれまでとあまり役割が変わっていないようにも見えますが、従来の「指示された要求を守る」姿勢から、よりビジネス側に歩み寄った「ビジネス部門の代弁者」的な姿勢が求められます。

ビジネス部門の代弁者となるために

ビジネスアナリストがビジネス部門の代弁者として立ち振る舞うためには、自社にとっての「顧客への提供価値を理解すること」が欠かせません。
アジャイルでは外部環境の変化に合わせて柔軟に開発優先順位を変えていきますが、この外部環境の中で最も大きな影響を及ぼすのが「顧客」です。今後は、ビジネス部門だけでなくビジネスアナリスト自身も、自社が顧客にどのようなサービスを提供していて、そのサービスは顧客のどのようなニーズを満たしているか理解することが必要になります。
BBC2017では、顧客を理解するためにカスタマージャーニーマップの手法の紹介や、データを通して顧客動向を理解することの重要性を説くセッションが目立ちました。ビジネス部門のように直接的に顧客と関係を築くわけではありませんが、データやビジネスプロセス越しにビジネスアナリストも顧客を見て仕事をするようになりそうです。この要素は、事業全体のビジネスプロセスやデータの構造理解や、カスタマーエクスペリエンスの分析といったスキルを養うことで強化できます。

ビジネス、そして顧客に対する理解を深めることは、ビジネスアナリストの新しい価値を生み出すかもしれません。ビジネスアナリストは「アナリスト」という名前がつくくらいなので、分析的な仕事に強みがあります。例えば、複数部門から出てくる要求の矛盾点を検証したり、想定される要求が実際の業務に反映されたときにどうなるか分析したりするなどが該当します。この分析的な思考を活かす対象に「顧客への価値」が加わると、これまでビジネス部門から言われた要求を精査するだけではなく、「どういう要求が求められているのか」「どういう要求があればビジネス上の課題を解決できるのか」といった問題解決型の提案ができるようになるかもしれません。

最近では顧客に関するデータからニーズや動向を分析し、ビジネス部門の意思決定をリードするビジネスアナリストも出てきています。従来のビジネスアナリストにとって、ビジネス部門を理解し歩み寄るマインドを持てるかどうかが、アジャイル型の環境への適用を左右する大きな鍵となりそうです。

ビジネスアナリストはコラボレーションを生み出せるか

「顧客への提供価値の理解」と並んで、これからのビジネスアナリストに必要な要素となるのが、「コラボレーションの場を作ること」です。
アジャイル型のプロジェクトでは、ビジネス側、開発チームの双方が状況や文脈を共有しながら、短期的な開発を繰り返してききます。この状況や文脈が共有された状況を作り出すこと、そのためのコミュニケーションがビジネスアナリストに期待されています。

現時点ではまだ、アジャイルメソドロジーを適用した環境でビジネスアナリストがどのように立ち振る舞うのか明確なモデルが定まっていません。BBC2017で見かけたアジャイル型の開発をしっかり進めている企業の事例を見ても、ある会社ではビジネスアナリストがビジネス部門になり代わってプロダクトオーナーを務めていますし、別の会社ではスクラムマスターやプロダクトオーナーと共にプロジェクトメンバーの一員になっています。

このように体制は企業によりけりですが、どこも共通しているのは、ビジネスアナリストを体制に組み込むことで、プロジェクト内のコミュニケーションを円滑にし、お互いの強みを生かしながら連携して1つのものを作る=コラボレーションを実現させようとしていることです。

 

 

実は、欧米企業は日本企業と比べても部門間のサイロが激しく、IT部門とビジネス部門の距離も近いとは言えません(だからこそビジネスアナリストのような専門職が成り立ちます)。欧米企業がアジャイル開発を組織内に広げていく際の大きな妨げとなるのが、このサイロの壁だと聞きます。
そして、ビジネスアナリストには、両者がこのサイロの壁を越えてコラボレーションを生み出せるよう、間に入って双方向なコミュニケーションを成立させることが期待されています。
コラボレーションを生み出すためにビジネスアナリストが強化すべきスキルとして、BBC2017ではステークホルダーアナリシス、ステークホルダーマネジメント、プレゼンテーション、ファシリテーション、そしてストーリーテリングが紹介されていました。伝える力はこれまでのビジネスアナリストにとっても重要なスキルでしたが、関係者を1つのストーリー上に載せて“巻き込む力”もまた、欠かせないスキルとなりそうです。

このように、アジャイル型への移行に向けてビジネスアナリストには変化が求められていますが、本質的な役割は変わりませんし、またその存在価値はむしろ高まることが予想されます。BBC2017では、組織としても、ビジネスアナリスト個人としても変化に適応しようとする様子が見られました。来年のBBC2018では更に進んだ議論がなされると思いますので、その時まで引き続き追っていきたいと思います。
日本では海外ほどアジャイルの話題は出ていませんが、アジリティが重要であることは世界共通のテーマです。本レポートが皆さんにとって、日本ではどのようなアジリティを高める取り組みが出来るのか考えるきっかけになれば嬉しく思います。

以上でBBC2017レポートでした。前編後編にわたり、お付き合いくださってありがとうございました。

 

 

お気軽にお問い合わせください

03-5312-7010

お電話でのお問い合わせ受付時間 9:30〜18:00