プロダクトマネージャーはWhy, Whatの責任を持つが、Howはどうだろう
プロダクトマネージャーの仕事を端的に表す表現として、
プロダクトマネージャーは
Why(なぜ作るのか), What(なにを作るのか)に責任を持つ
という表現を1度は耳にしたことがあるのではないでしょうか。
一方で、この表現に尾ひれがつく形で、
Howについてはプロダクトマネージャーは関係しない
Howはエンジニアに責任がある
Howは設計/実装であり、仕様はプロダクトマネージャーが定めるべき
など、主観的ではありつつも、こういったニュアンスの表現を見かけることが多く、個人的に度々違和感を覚える表現でもあります。
そこで、このnoteにおいてはプロダクトマネジメントにおけるWhy, What以外の領域である「How」に注目し、プロダクトマネジメントとHowの関係性について解説をしていきます。
プロダクトチームをつくるという仕事
Why, Whatを元に、How = どうやって作るのかを考えていくことになります。この「プロダクトを作る」にあたっては、
設計 / 実装
UIデザイン
品質保証
etc…
などの、様々な専門性を掛け合わせ具現化をしていく必要がありますが、これを実現できる専門家チーム = 「プロダクトチーム」 であり、このプロダクトチームがHowを担うことになります。
あれ…じゃあやっぱりHowはプロダクトマネージャーは関係ないのでは…？と思われるかもしれませんが、当然これで話が終わるわけではございません。
プロダクトマネジメントクライテリアには、以下のような記載があります。
プロダクトマネジメントには大きく2つのテーマがあります。
🎁 A. プロダクトをつくる仕事
👩👩👧👧 B. プロダクトチームをつくる仕事
プロダクトマネジメントは、プロダクトをつくることだけが仕事なのではなく、「プロダクトチーム」をつくることもまた重要な仕事の1つなのです。
プロダクトチームとは
一口にプロダクトチームといっても、実際にはいくつかのパターンが存在します。この分類については諸説あるものの、ここではSVPG社の記事に基づく形で3つのパターンに整理をします。
・プロダクトチーム
プロダクトチームは部門という枠を超えているチームです（プロダクト、デザイン、エンジニアリング）。彼らは（アウトプットではなく）結果に焦点を置いて成果が図られます。そして、彼らは与えられた課題の最良の解法を見つけるためにエンパワーされています。この文脈の中でのプロダクトチームの目的は、顧客が喜ぶ方法で問題を解決し、かつビジネスにもなるようにする、ということです。
・フィーチャーチーム
ここでは、フィーチャーチームのより確立された定義を少し曲げていますが、これらのチームがアウトプットに焦点を全て当てていることを強調できるため、この用語を使用しています。フィーチャー（機能）、そして時々プロジェクトは、通常ロードマップと呼ばれる優先リストの形式でチームに提供されます。
・デリバリーチーム
「開発チーム」、「スクラムチーム」または「エンジニアリングチーム」とも呼ばれ、会社がSAFeのようなものを実行している場合、残念ながらこれはあなたのチームです。このチームには、何人かのデベロッパーとプロダクトオーナーがいます。このモデルのプロダクトオーナーは、私が「バックログ管理者」と呼んでいるものです。
これをもう少し噛み砕くと、以下のように整理がされます。
「プロダクトチーム」が扱う対象
→ 広義のプロダクトを扱い、アウトカムにフォーカスしている「デリバリーチーム」「フィーチャーチーム」
→ 狭義のプロダクトを扱い、アウトプットにフォーカスしている
なお、広義/狭義のプロダクトの定義としては以下の通りです。
狭義のプロダクト: プロダクトチームによるアウトプットである成果物
広義のプロダクト: アウトプットとそれに付随する広義の活動 ≒ 事業
この定義における「プロダクトチーム」によって、持続的に価値のあるプロダクトを生み出せる状態を目指していくわけですが、これと同時に「プロダクト志向」なチームを実現していくことも重要になります。
これについても、プロダクトマネジメントクライテリアにて触れられており、「プロダクト志向」とは以下のように定義されています。
プロダクトチームに所属する全員がプロダクトをまるで自分の子どものように愛し、自分の担当領域だけではなく、プロダクト全体のことを考える状態を「プロダクト志向」と呼びます。プロダクト志向なチームでは、プロダクトを良くするために部署の垣根を超えてお互いが能動的に関わりますが、意思決定者は 5.1. プロダクトの粒度と責任範囲 で記載した通り決まっていて、意思決定者の決定が尊重されます。
このような「プロダクト志向」なチームこそが、プロダクトを成功させることができると述べられており、先程の話と合わせてプロダクトマネージャーは「プロダクト志向なプロダクトチーム」をチームと共に実現していく動きが求められます。
⚠️ あくまでここまでの話は、不確実性に向き合い続けるプロダクトであることを前提としていますが、作るべきものが明確であったり、期限付きプロジェクトなどの場合は、デリバリー/フィーチャーチームの方が適切であるケースももちろんあります。
ただし、一般的に機能型組織においてプロダクトマネージャーは人事権を持たないとされているため、実際にはチームに対する人事権を持つ方と共に「プロダクトチーム」の実現に向けて、継続的な対話と啓蒙をしていくことになるでしょう。
プロダクトチームをつくる
では、「プロダクトチーム」を実現していくにあたって、どのようなチーム構成とするのがよいでしょうか。冒頭にて、プロダクトをつくるためには
設計 / 実装
UIデザイン
品質保証
etc…
といった専門性が必要となると述べましたが、これを職種に置き換えると、
エンジニア
UIデザイナー
QA
となります。仮にデリバリーもしくはフィーチャーチームであれば、このチーム構成で十分なアウトプットを行っていくことが可能です。
では、「プロダクトチーム」を実現するためには、どのようにすればよいでしょうか。
このとき大事になるポイントとしては、「プロダクトチーム」においてBiz/User/Techの3つの柱がバランスよく成立していることです。
決して、Biz、User、Techの3人の担当者がいるわけではありません。UXデザインをするためにはUserの柱に軸足を置きながらも各OSのレギュレーション（Tech）や事業目標（Biz）を知らなければいけません。1つの柱のことしか分からず、プロダクトの成功に向かう3つの柱の交差領域での議論ができない人はプロダクトチームにおいては主体的に動くことができないジュニアメンバーです。
つまり、プロダクトチームの形は単純な職種の構成によって決定されるわけではなく、企業規模や事業ドメイン、組織カルチャーや職種比率など様々な要因を元に、この3つの柱をどのようにして成立させていくかを考えていくことが重要になります。
例えば、エキスパートレベルのドメイン理解が求められる性質のプロダクトであったり、ロール毎のJDが明確に定義され、これを満たす人材が十分に所属しているような成熟した企業などにおいては、
(テクニカル)プロダクトマネージャー / プロダクトオーナー
プロジェクトマネージャー / スクラムマスター
などの役割をチームに組み入れつつ、他機能型組織と継続的な連携をとっていくことで1つのプロダクトチームを形成していくことができます。
(そして比較的この形は一般化されつつあるのではないでしょうか。)
別の例としては、開発者向けのプロダクトであったり、プロダクト志向なエンジニアリングカルチャーの会社の場合、
エンジニア
サービスリード
テクニカルリード
マネージャー / リーダー
デザイナー
QA
のようにエンジニアのロールを細分化することで、「技術」を中心に据えつつも、他領域に対してそれぞれ責任範囲を広げていくことができます。
(もちろん、これはエンジニアに限らずデザイナーなどにおいても同様です。)
「どのようなプロダクトチームを実現していきたいか？」
チーム及びマネージャーと継続的な対話を行い、共に考えながら歩みを進めていくことで、最終的なプロダクト志向なプロダクトチームの実現へとつなげていくことが出来るでしょう。
Howとはどこからを指すのか
プロダクトマネージャーとプロダクトチームの関わりにおいては、Howが記された「仕様」をだれが書くべきか論を避けては通ることはできません。
アジャイル開発にも関わらずで「仕様を決めきってください！」と言ってしまうエンジニアさんがいるとチームは一気にワークしなくなる。開発する機能を決めるのはプロダクトマネージャーだけど、仕様を決めるのはエンジニアと一緒にやる必要がある。ここまだ理解されないことがあるのは耳にしますね🤔
— Shin Sasaki@PM Club主催者 (@shin_sasaki19) March 17, 2022
上記のような話が出た場合、それは「デリバリーチーム」もしくは「フィーチャーチーム」であるシグナルかもしれません。
「仕様」とは一口にいっても、要求仕様、詳細仕様、インターフェイス仕様….など多種多様な「仕様」が実際には存在します。
この「仕様」を理解するにあたっては、「要求」と「仕様」の関係性を正しく知ることが重要です。
要求と要求仕様の違い
「要求」と「仕様」の関係性については、様々な記事にて解説がされているところではありますが、ソフトウェア工学を専攻していた身としては、これの一部分である「要求工学」における定義が厳密性もあり良いと思っていますので、こちらを引用していきながら説明をしていきます。
まず「要求」及び「仕様」については以下のように定義がされています。
要求は利用環境から見たソフトウェアが実現すべき目標である。
また仕様はソフトウェアが利用環境に対して必要とされる機能を提供するための境界条件である。
そして、「要求」と「仕様」の関係性については、以下のようにモデル化がされています。
このモデルにならうことで、
Why, What → 上半分の「問題領域」に該当
How → 下半分の「ソリューション領域」に該当
という形で整理ができ、例えばプロダクトマネジメントであれば「問題領域」における「要求」を定義することであると言えるでしょう。
一方で、「要求仕様」は「ソリューション領域」に属しており、「ソリューション知識」を注入することで作られるものであることが分かります。
(※ 要求仕様 = 与えられた要求を満足する仕様)
ここで大事なこととしては
「要求(定義)」と「要求仕様」は似て非なるもの
「要求(定義)」はWhy, What、「要求仕様」はHowである
ということです。
誰が要求仕様を書くのか？
先程のプロセスモデルは、ベンダーへ発注を行う際に必要となる「要求仕様」を定める際のプロセスが元となっており、ベンダーはこれを満たすように "アウトプット" を行い、納品をしていくという関係性にあります。
この関係性は、 "アウトプット" にフォーカスをする「デリバリーチーム」や「フィーチャーチーム」に近い構造であり、このような場合はプロダクトマネージャーが要求仕様まで全てを定めたうえで、チームに対して開発を依頼するという、一般的には「社内受託」と呼ばれる関係性となるでしょう。
一方で、 "アウトカム" にフォーカスをした「プロダクトチーム」の場合、このチームは要求仕様含むソリューション領域全般を担っており、以下のように整理をすることができます。
「要求仕様」は、PRDなどの「要求」をインプットとした、プロダクトチームが、プロダクトチームの知識を合わせて作成をするドキュメント
プロダクトマネージャーは、「要求仕様」の作成を支援し、「要求」と「要求仕様」との追跡性を管理する
つまり、チームがなににフォーカスしているかによって、要求仕様を書くことを「プロダクトマネージャー」に求められることもあれば「プロダクトチーム」で作り上げていくこともあります。
ですが、残念ながらプロダクトマネージャーはHowの領域においてはプロではありません。
プロダクトの価値を最大限引き出していくためにも、ここはチーム側で要求仕様を定めていけるように、プロダクトマネージャーは「プロダクトチームをつくる仕事」により注力をしていきたいところですね。
ℹ️ なお、実際にはプロダクトマネージャーがチームのPOやPjMのロールを兼任していたり、チーム付けの(テクニカル)プロダクトマネージャーというロールが存在するケースもあるでしょう。このような場合は、プロダクトマネージャーがチームに所属している状態であるといえ、引き続きプロダクトマネージャーが要求仕様の作成についてもリードしていくのがよいでしょう。
💡 個人的な経験ではありますが、PRDを元に、エンジニアがDesign Docを記述し、デザイナーがUI仕様を定め、QAが詳細仕様を決定していく、というプロダクトチームに所属していたことがあるのですが、これは非常にうまく回っていました。
おわりに
プロダクトチームの成熟度が上がっていくことで、HowはもちろんWhy, Whatについてもプロダクトチームと共に考え、移譲を進めていくことで、プロダクトマネージャーはより良い問いを探すことに時間を使うことが出来る、良いサイクルを加速させていくことができるでしょう。
本当に優秀なPMとEMとタッグを組むと、PMはProductを通して何を実現したいのか、つまりWhyだけ語る。ニュアンスまで含めて、熱く語る。
— Yoshitaka Miyata / 宮田善孝 (@zenkou_1211) February 4, 2022
そして、PMとEMがフラットに議論し、Whatを決める。Howは完全にEMが責任を持ち、スケジュールも含め、PMは共有を受けるだけ。
スキルと信頼があれば、これが究極。
さて、この結論を伝えたいがために大変長々とした文章を書いてしまいましたが、曽根原春樹さんが端的な一言で表現しておりましたので、最後にこちらを紹介させていただきます。
PDMの責任範囲は「WhyとWhatを決め、How、Who、Whenを関係各所と決め、Doで常に状況を把握して意思決定する」ことだと言う。
Twitterの@yukagilで今後も定期的に何らかのナレッジを共有していければと思っておりますので、よければフォローよろしくおねがいします🤝
(noteに対するご意見ご感想や、その他よもやま話ももちろん大歓迎です！)
いいなと思ったら応援しよう！
