近年、プロダクトマネージャーが脚光を浴びるようになりました。その役割は企業によってマチマチですが、プロジェクトマネージャーと比べると、提供するサービスの仕様決定やマーケティングのコントロールをより強く求められます。
それらはマインドセットなどのソフトスキルに依存していることも多いようです。そのスキルを学ぶべくベテランプロダクトマネージャーにインタビューしてみたところ、聞いた通りにはうまく実践できないと答えてくれました。
実は、プロダクトマネージャーが担当する幅広い仕事のうち、ある部分のタスクやテクニックは「ビジネスアナリスト」の役割であるとして知識の体系化が進んでいます。
そこで今回は、ビジネスニーズの整理からソリューションの決定に焦点を当てて、ビジネスアナリストが持つ知識の体系をお話しします。
1.ビジネスアナリシスとは
国際的に活動している非営利団体IIBA（International Institute of Business Analysis）は、ビジネスアナリシスを次のように説明しています。
ビジネスアナリシスは、ニーズを定義し、ステークホルダーに価値を提供するソリューションを推奨することにより、エンタープライズにチェンジを引き起こすことを可能にする専門活動である。
http://www.iiba-japan.org/about/Business-Analysis.html
カタカナが多すぎて少しイメージしにくいですね。自由な意訳で恐縮ですが、私は次のように理解しています。
「ビジネスアナリシスは、ビジネス機会や改善したい世の中の課題を特定し、ある状況（競争相手、顧客層、技術、業務プロセス、売上など）に対して、ステークホルダーに具体的な改善方法を提案することにより、管理された計画的な変化を可能にする専門活動である。」
2.BABOKガイドとは
上記の専門活動について体系的にまとめられた書籍がビジネスアナリシス知識体系ガイド（BABOKガイド）です。
BABOKガイド Version3.0では、当該ガイドを次のように説明しています。
本書BABOKガイドの内容は、ビジネスアナリシスのやり方をまとめた世界的に認められた標準である。ビジネスアナリシスの知識エリアをはじめ、タスク、基礎コンピテンシー、テクニック、専門視点について記述し、ビジネスアナリシスへのアプローチ方法を説明する。
BABOKガイド Version3.0
私は経験豊富なベテランが持っている知識が、BABOKガイドで体系化されていることに価値を感じています。
しかし、手順書のようにタスクが順番に並んで書かれいてないため入門書としては難易度が高いです。
私は辞書のような使い方をしていますが、それには基礎的な知識が欠かせません。
3.プロダクトマネージャーに役立つビジネスアナリシス入門
BABOKガイドには、多くの知識が凝縮されています。ビジネスアナリシスを理解するためには、BABOKガイドの全体像を把握することが重要です。
一方で、目下のプロジェクトに活かしていくには、全体像の把握よりも具体的なテクニックや、いつ何をすべきかといった情報が必要と考えます。
そこで本記事では、私自身がプロダクトマネージャーを努めるにあたり、BABOKガイド Version3.0をベースに役に立ったことをお伝えします。
(1)プロダクトを形作る３つの要素をドキュメントで管理する
例として、ピザをインターネットで注文するためにWebサイトを構築するプロジェクトを立てたとします。
開発にあたり、プロダクトを説明する資料（たとえば要求仕様やDesign Docと呼ばれるようなもの）には何を書きますか？
まずはビジネスニーズではないでしょうか。「現在は電話のみ注文を受け付けているけれど、受注拡大のためにインターネットでの注文を受け付けたい」などがそれにあたります。
「Webサイトを作って注文を受け付ける」「支払いはピザを渡したときに受け取る。Webサイトでは作り込まない」など、Webサイトで何ができるかと実現しなくてもよいことを整理するのは重要です。これらの要素は、BABOKガイドでは「BACCM（ビジネスアナリシス・コア・コンセプト・モデル）」として定義されています。
BACCMには６個のコア・コンセプトがあります。対処すべき問題または機会（ビジネスニーズ）をあるコンテキストにおいて、ひとつ以上のニーズを満たす具体的な方法（Webサイトでできること／やらないこと）を「ソリューション」と定義しています。残り４つは「チェンジ」「ステークホルダー」「価値」そして「コンテキスト」です。
ニーズとソリューションは、多くのプロジェクトで管理されています。ベテランはその２つに加えて、プロダクトを説明する資料に「コンテキストを書きます。ソリューションの定義を思い出してください。「あるコンテキストにおいて」と書かれています。これは、コンテキストが違えば具体的な方法も変わってしまうからです。
ピザ注文サイトの例では、どのようなことがコンテキストになるのでしょうか。競争相手、顧客層などがイメージしやすいかと思いますが、もう少し考えてみると「ピザは食べ物である。ピザは熱々が美味しい」といったこともコンテキストといえるのです。
コンテキストは当たり前のこととして管理対象から外しがちですが、情報収集とドキュメント化をしっかりと行うことが、手戻りのないプロダクト開発への近道です。
(2)要求は引き出す
BABOKガイドでは、要求は「引き出し、分析し、妥当性を確認」するものだと書かれています。
要求はヒアリングではなくelicit、つまり「引き出す、誘い出す」必要があります。保守開発などの場面で課題が明らかな場合を除き、具体的な要求を説明することができるステークホルダーは普通はいないものです。
要求を引き出すためには、ヒアリングだけでは十分ではありません。さまざまなテクニックを駆使しましょう。
BABOKガイドでは、引き出しのためのテクニックが紹介されています。インタビュー、ブレーンストーミング、プロセス・モデリング、プロトタイピングなどです。
もうひとつ重要なことは、要求は「分析し、妥当性を確認」しなければならない性質のものだということです。
BABOKガイドには、要求は「トレースし、維持し、優先順位をつけ、評価する」必要があると書かれています。ここでいう「維持」とは、「ライフサイクル全体を通じて要求とデザインを正確かつ最新に保ち、状況に応じた再利用を容易にする」ことです。
過去のプロジェクトを振り返ってみてください。次のようなことはありませんでしたか？
- 実装された機能について、裏付けとなる要求が何だったのか思い出せない
- 対応すべき要求と決まったが、実装段階で要求の本来の意図が思い出せない
- 要求によって実装された機能が、戦略全体との整合がとれていない
- 合意された要求は、ビジネスリスクや機会、制約に変更を与えるものだったが、そのことに 気づいたのは実装した後だった
BABOKガイドには、このような問題を回避するためのテクニックや、行った方がよいタスク、管理した方がよい成果物がまとめられています。
まとめ
プロダクトマネージャーは簡単な仕事ではありません。プロジェクトの旗振りにあたってプロダクトのコア・コンセプトを軸として仕様を適切に決定する必要があります。
そのための情報を日頃から集めて整理し、また変更された場合には、その内容をチームメンバーやステークホルダーに、理由も含めて漏れなく伝えなければなりません。
本記事が、プロジェクトを成功させるためのヒントをBABOKガイドから抽出する際の手引きとなれば幸いです。
