これは興味深い質問で、理解には時間がかかるかもしれません。まず、これらの用語や分野はどこから始まったのか、また、いくつかの一般的なフレームワークの中で、どのように説明されているのかを見てみましょう。

キャリアを始めた時、「ビジネスアナリスト」私は呼ばれていました。しかし、当時は今のIT企業で見られるような「ビジネス分析」をほとんどする事はありませんでした。。正直に言うと、プロダクトマネジメントとして今、教えていることも、ほとんどやっていませんでした。営業から要件を集め、ソリューションを考えて設計し、仕様書を開発に連携して構築してもらうのが私の仕事でした。

銀行などの金融サービス会社に移った後も、私は「ビジネスアナリスト」と呼ばれていました。金融サービスを離れてしてスタートアップで働くまでプロダクト・マネージャーとは呼ばれませんでした。やっていた仕事は、すべて同じ内容だったのですが、スタートアップでは違う役職名になりました。私はこの 「プロダクトマネージャー」という名前が好きでした、なぜなら役職に重みがあるように思えたし、シリコンバレーの他のテック企業がビジネスアナリストの役割が会社ごとに異なっているのに対して、キャリアパスがはっきりと用意されいてるようにみえたのです。

それから数年経つまで、プロダクトオーナーという言葉を聞いたことがありませんでした。初めてプロダクトオーナーという言葉を聞いたとき、その言葉の意味を他の人に尋ねました。すると、プロダクトマネージャーと同じで、スクラムで使われる用語だと教えてくれました。私たちはスクラムを何年も使っていましたが、私はプロダクトマネージャーと呼ばれていました。その後、プロダクトオーナーについて、ほとんど考えたことがありませんでした。

でもそれは、SAFeフレームワークを使っている会社で初めてプロダクトマネジメントを教えるまでのことでした。ある大手銀行でワークショップをしていたとき、参加者の一人が「ありがとうございます」と話かけてきました。

「プロダクトオーナーもユーザーと話をするように教えて頂いているのですが、私の仕事はプロダクトオーナーです。プロダクトマネージャーが、すべてのユーザーと会話をして、何が要件かを私に伝えます。私は要件からユーザーストーリーを書き出し、チームと協力してソリューションを実行することに自分の時間を費やしています。私は混乱しています。」

この出来事を境に、どのようにして、ここにたどり着いたのかを理解するために、2つの役割の違いや、考え方の違いを掘り下げ始めました。

プロダクトマネジメントの歴史は1931年まで遡ります。ヒューレット・パッカードが、1940年代にプロダクトマネジメントを導入し、プロダクトごとに組織化した最初のテック企業の一つです。シリコンバレーのほとんどの企業には最初からプロダクトマネージャーがいて、80年代、90年代にそこで働いていた私の友人の多くは、確かにプロダクトマネージャーでした。この分野は新しいものではありませんが、より多くの企業がソフトウェア組織に移行し、プロダクトを中心としたビジネスを始めるようになり、この分野は急速に進化しています。

スクラムが登場したのは、2001年にアジャイル宣言が書かれる少し前のことです。スクラムはプロダクトオーナーという概念を導入しました。これは、顧客の代理人であり、何を構築する必要があるかの要件を開発者に伝える人でした。これらのプロセスの生みの親の多くの人が企業でコンサルタントとして働いていた初期の頃は、プロダクトオーナーは顧客、つまりチームと一緒に座って仕事のバックログに優先順位をつけるビジネスの内部の人でした。実際、Scrum Allianceの認定スクラムプロダクトオーナー認定の2017年の学習目標には、「プロダクトオーナーの役割は、一般的には顧客、つまりプロダクトマネージャーなどの顧客の代表者が担っていることを教える 」と書かれています。

ほとんどのスクラムの文献でプロダクトオーナーの役割を見てみると、主に以下の3つの責任を担います。

  • プロダクト・バックログを定義し、開発チームのために実行可能なユーザーストーリーを作成します(誰がユーザーストーリーを作成するかはスクラムのトレーニング内容によって異なっています)
  • バックログのタスクをグルーミング(整理)して優先順位をつける。
  • 完成したユーザーストーリーを元にテストをして、作ったものが基準を満たしているかを確認します。

講師や運営組織によってカリキュラムは変わりますが、プロダクトオーナーを認定するための2日間のコースでは、主にこれらに焦点が当てられています。スクラムには、プロダクトオーナーとして何をすべきかというプロセスやルールについての情報が多く含まれていますが、成功するプロダクトを作るための多くの重要な疑問への回答は明確になっていません。その多くは、「正しいものを構築しているのが、どうやって分かるのか?」

ここでプロダクトマネジメントの出番です。良いプロダクトマネージャーは、真の顧客とビジネスの価値を検証する方法、はっきりと結果重視の目標に対して仕事に優先順位を付ける方法、プロダクトが市場で成功するための不確実性を減らすために必要なプロセスは何かを発見する方法を身につけています。

プロダクトマネジメントのこのような知識が無いと、スクラムのプロダクトオーナーの役割を果たすことはできますが、、正しいものを構築しているかどうかは分かりません。

筆者注:プロダクトオーナーは、スクラム チームでの役割です。プロダクトマネジメントは職種です。

スクラムチームを取り上げても、組織のプロセスとしてのスクラムを取り上げても、プロダクトマネージャーであることに変わりはありません。プロダクトマネジメントとスクラムはうまく連携しますが、プロダクトマネジメントはスクラムに依存しているわけではありません。どのようなフレームワークやプロセスでも存在できますし、存在すべきです。

最近、開発者が別の部署に移ってしまったプロダクトオーナーが、私のところに来て、社内でプロダクト担当の居場所は無くなったのかもと心配していました。プロダクトオーナーの全体的アイデンティティは、開発者のチームに依存しているように見えました。

プロダクトマネージャーの役割と責任は、自分の状況やプロダクトの段階によって変わります。スクラムチームがない場合や小規模なチームでは、未定義のプロダクトの問題発見と同時に戦略と検証作業を行うことになるかもしれません。スクラムチームがあれば、よりソリューションの実行に集中できるかもしれません。プロダクトマネージャーを束ねるプロダクトマネージャーとして、プロダクトの大局の戦略をリードし、問題発見と実行がうまくいくようにチームをコーチングするかもしれません。

SAFeのフレームワークでは、これを違う形で教えていて、フレームワーク全体の中で最弱点の一つだと思います。SAFeでは、プロダクトマネージャーはプロダクトオーナーのマネージャーであり、外部とのやりとりや仕事に責任を持ちます。顧客と話をし、構築するプロダクトの要件やスコープを定義し、それをプロダクトオーナーに伝えます。プロダクトオーナーは、内部と向き合い、ソリューションのコンポーネントを定義し、開発者と協力してプロダクトをローンチする役割を担っています。

訳者注:
Program Backlog(プログラムバックログ):
SAFeの用語。 Program Backlogは、今後のFeatureやEnablerのための保持領域であり、それらのFeatureや Enablerはユーザーのニーズへの対応、ビジネスのメリットとなること、Architectural Runwayの構築を目的としています。

Enabler(イネーブラー):https://www.scaledagileframework.com/ SAFeの図番のエンジ色を参考のこと。Enablerは、今後の開発において必要となるもの補助します。調査、インフラストラクチャー、コンプライアンス、アーキテクチャー開発が含 まれます。

エマージェントデザイン( emergent design ):
旧来は先にデザインを含めて設計していたのに対し、機能を開発していくなかでデザインを設計すること。アジャイルにおける機能開発とデザイン設計の仕組み。

これまで何十ものSAFeを取り入れているチームをトレーニングしてきましたが、うまく機能しているのを見たことがありません。プロダクトオーナーはよく問題を理解していないため、ユーザーとの関係性を断ち切り、ユーザーの問題を解決する本当に効果的なソリューションを作成できていませんでした。プロダクトマネージャーは基本的に要件をウォーターフォールで落としているだけで、チームはソリューションが正しいかどうかを証明できません。誰も検証作業をしていません。

私は、プロダクトオーナーには両方をこなす時間がないという意見をたくさん聞いてきましたが、現在の状況では、その通りだと思います。私の知り合いのプロダクトオーナーは、週に40時間もユーザーストーリーを書いています。その時点で、それらのユーザーストーリーに価値があるのか?何に対して優先順位をつけているのか?それが問題を解決することをどうやって知っているのだろうか?と自問しないといけません。

もし誰か一人が、毎週、ユーザーストーリーを書くことだけに時間を費やしている場合、それはビルドトラップに陥っています。リリースするアイテムの量に集中しすぎて、品質が取り残されています。

優れた戦略フレームワークがあり、重要ないくつかのゴールへのはっきりとした優先順位付けをしていれば、効果的に顧客と話して、顧客の問題を理解し、チームと一緒にソリューションの定義ができるようになります。

Scrum.orgのCEOでさえ、不本意ながらもこれに同意しています。Scrum.org はまた、プロダクトオーナーは半分の時間を顧客と話し、半分の時間をチームとの作業に費やすべきだと言っています。私はこの分割に100%賛成しているわけではありませんが、方向性は良いと思います。外部と内部の仕事の量は、プロダクトの成熟度と成功度に応じて変化します。一度にすべての作業を行うべきではありません。

クライアントに、上級職のプロダクトマネージャー(VPやプロダクトリーダー、中間管理職)が、市場調査、企業目標や戦略の理解、プロダクトの成功の現状を見ながら、チームのビジョンや戦略を定義することに集中するように私は指導しています。スクラムチームを持たない、または小規模なチーム(例えばUXデザイナー1名と開発者1名)を持つプロダクトマネージャーは、将来のプロダクトの戦略を検証し、それに貢献します。方向性を検証したら、この人たちを中心により大きなスクラムチームを作り、ソリューションを構築していきます。

プロダクトの段階に応じて、チームサイズにも柔軟性を持たせることが重要です。もしあなたがディスカバリーモード(問題とソリューションを発見する段階)にある間、プロダクト・マネージャーに大規模なスクラムチームのバックログを与えても、彼らはそのバックログを埋め続けるでしょう。しかし、開発者に仕事を流し続けることと、方向性を確認するための仕事をすることの間で、プロダクトマネージャーは悩むことになるでしょう。その結果、どちらもうまくいきません。

ビジネスや顧客のために価値を生み出すプロダクトを作りたいのであれば、社内に優れたプロダクト・マネジメントの基礎が必要です。社員のキャリアパスを確保したいのであれば、社員がより上の役割へ成長できるように、このような基盤を与える必要があります。そのためには、自分たちが全員プロダクトマネージャーであることを忘れないようにしましょう。スクラムチームでプロダクトオーナーの役割を果たしていることが多いかもしれませんが、プロダクトマネージャーのように考え、正しいものを構築しているかどうかを検証する必要があります。

SAFe:アジャイルのフレームワークの一つ

引用元

Product Manager vs. Product Owner