『プロダクトマネージャーのしごと』は本当にすばらしい本だった。
邦題にこそ『プロダクトマネージャー』という役割名が入っているが（※原題は『Product Management in Practice』）プロダクトはみんなで作るものであり、ソフトウェアエンジニアである自分もまたプロダクトマネジメントの重要な部分を担っている。常にではなくとも、すぐれたプロダクトマネージャとしての振る舞いが求められる場面や、役に立つ場面というのも多いと感じる。
この本から学んだことをよりしっかりと身につけ、実践していけるように、自分が学んだことをまとめてみる。
学んだことは、「過程にとらわれず、価値に集中せよ」「ユーザー価値とビジネス価値、シニアステークホルダーとチーム、すべてをつなげ」の大きく2つにまとめることができる。
以降はこの大きな2つの切り口から、学んだことをまとめていく。
過程にとらわれず、価値に集中せよ
僕が何よりもこの本に目を開かされたのは、過程にとらわれず、価値に集中することの重要性についてだ。
もちろん、僕もアジャイルの実践者として、「やり方にとらわれることの愚かさ、危険性」についてはそれなりに理解し、気をつけているつもりではいた。
だが、全然甘かったと思った！ すぐれたプロダクトマネージャというのは、本当に過程にとらわれず、価値に集中するものなのだ。
プロセスにとらわれないこと
プロダクトマネージャは常に、価値、またの名をアウトカムに目を向ける。
たとえば、何か「失敗」があったとき。すぐれたプロダクトマネージャはそこにある意図や感情よりも、アウトカムに目を向ける。
あるいは、「ロードマップ」が求められているとき。「ロードマップには機能ではなく、課題を書く」といった方法論も有用ではあるが、いきなりそれを持ち出しても仕方ない。
そうではなく、それが組織にとって何を意味するのかを明確にするために、求めている人に質問し、また作ったロードマップにもそれを明確に記す。そのロードマップから組織は何が得られ、何は得られないのかを明らかにする。
役割にとらわれないこと
この本によると、プロダクトマネージャはあいまいな仕事だ。そして、組織によってそれぞれ独自な仕事だ。
だから、役割期待を明らかにするには、周りの人と話すことが重要なのだ。プロダクトマネジメントの本に書いてあることをその通りにやるのが仕事じゃない。
ひるがえって、エンジニアである自分の周囲のプロダクトマネージャが「プロダクトマネージャらしいこと」をしてくれないと思うことがもしあったとしても、「プロダクトマネージャらしくないから」ではなく、「価値を作るために、なぜ、何をその人にしてほしいのか」といった切り口で率直に話したいと思う。
価値に集中すること
プロセスにも役割にもとらわれることのないすぐれたプロダクトマネージャは、常に顧客とビジネスインパクトから考える。
もちろん、そこに至る道筋は簡単じゃない（簡単だったらプロダクトマネージャは必要ない）。だから、道筋の候補は常に複数あり、変わり続ける優先順位を評価し続ける。
そして、ただ自分がそう考えるだけじゃない。ストーリーを作ったり、計画を立てたりといったチームの活動の中でも、常に戦略的なゴールと目的を会話の中心に置く。
そうすることで初めて、プロダクトチームは機能工場ではなく、プロダクトチームでいられる。
また、自分の時間の使い方についても、ゴールと優先順位を反映できているかに気を配る。すべてを最優先にしてしまって燃え尽きるのではなく、ゴールのために重要なことに時間を使い、最小限の労力で最大限のインパクトを出すことを目指す。それがチームや、ビジネスの持続性にとっても必要なことだからだ。
ユーザー価値とビジネス価値、シニアステークホルダーとチーム、すべてをつなげ
僕がこの本から学んだもう一つの大きなことは、プロダクトマネジメントには、「ユーザー価値」と「ビジネス価値」や、「シニアステークホルダー」と「チーム」といった、ときに矛盾したり、乖離したりしかねないものをつなぎ続けることが本当に重要だということだ。
今までもそれなりにプロダクトマネジメントに興味を持って学んできて、プロダクトマネージャが「つなぐ」役割であること、特にユーザとエンジニアの「翻訳者」のような中間者的立場に陥らず、両者を直接結びつけることが重要であることなどは知ってはいた。
だが、どうすればそれができるのかはよくわかっていなかった。この本にはその実践のヒントが山ほど書かれていた！
まず、ユーザーを知ること
プロダクトマネジメントでは、まず何よりもユーザーを知る必要がある。ユーザーを知らずに、ユーザーが使ってくれるプロダクトを作れるわけがない。当然のことだ。
『プロダクトマネージャーのしごと』を読んで、それが本当に重要であること、またどうすれば本当にユーザーを知ることができるのかのヒントが数多く得られた。
特に「ユーザーの現実に生きよ」という原則の観点からまとめられていたチェックリストには目を開かされた。ユーザーを知るとはこういうことか、と。
以下は、そのチェックリストからの引用だ。
- 自分のチームは少なくとも週1回はユーザーや顧客から直接学んでいるか？
- すべてのプロダクトに対する意思決定は、ビジネスゴールとユーザーニーズにもとづいているか？
- 自分のチームは、ユーザーニーズや行動に対する理解を深めるために、定期的に自分たちのプロダクトと、それと競合・関連するプロダクトを使っているか？
- ユーザーニーズと利用目的は実際の自分たちのユーザーのニーズと利用目的を反映してはっきりとまとめられているか？ それとも、ビジネスが想像するニーズや目的だけか？
これらのチェックリストには示唆が詰まっている。ユーザーと話す機会は「少なくとも」週1回であることや、すべての意思決定がビジネスゴール「と」ユーザーニーズにもとづいている必要があること。ユーザーを知るために、自分たちのプロダクトだけでなく、競合や関連プロダクトも使うこと。必要なのは想像ではなく現実のユーザーニーズであること。
色々あるけれど、出発点はとにかく、ユーザーと話すこと。
プロダクトマネージャだけでなく、プロダクトチーム全体が、継続的にユーザーと話し、学び続けていないなら、スタート地点にすら立っていないのだと思う。
明確にすること
効果的なプロダクトマネジメントにはコミュニケーションが不可欠だ。なかでも、明確なコミュニケーションが重要である、という主張からは勇気が得られた。
僕自身も、常々明確さを大事にしているからだ。それでも、明確さを保つのは難しく、心が折れそうになることもある。
先ほどと同様、「心地よさより明確さ」という原則の観点でまとめられたチェックリストを以下に引用しておく。
これらの記述からは、「伝わったはず」や「伝わるといいな」といった態度が排除されている。伝わるまでが自分の責任である、という覚悟が感じられる。
これはプロダクトマネージャに限らず、ソフトウェア開発に関わるすべての人に求められる態度だと思う。
伝え、学ぶこと
明確さを手に入れたら、プロダクトマネージャは異なる視点をつなぐことができる。伝え、また、学ぶのだ。
伝えることの重要性は、たとえば「自らを不要とせよ」という原則の一つに表れている。
自分がいなくてもチームが自ら正しい意思決定ができるように、予めプロダクトの意義や背景、ユーザーのことなどを伝えておく。伝えておく、というより、伝え続けている状態でいる、という方が正確かもしれない。
ドキュメントは不完全な「方がいい」という主張も面白い。その方がコラボレーションの余地があるからだ。これは伝えるということを超えて、チームとしてともに学び、知識を生み出すという態度だ。そのために、最初のドキュメントは1ページ1時間を上限とする、という指針が力強く、また心強い。
また、自分が発信するだけでなく、多様なステークホルダーの視点や協力を得る、ということも重要だ。そのために邪魔になるのが「守りの姿勢」で、役に立つのが「好奇心」だとこの本は説いている。「学ぶ姿勢」と言い換えてもいいだろう。
チームを守る、ユーザーを守る、プロダクトを守る。その対象がなんであれ「守る」という行動は邪魔になる。
一見、それらを守るのは正しく、美しくすら思える。しかし、「守る」ことは最終的にはうまくいかないのだ。
かわりに好奇心を持ち、教えてもらう。何かが脅かされているように見えるのは、おそらくそこに自分やチームが知らない・気づいていない何かがあるからだ。好奇心を持ってそれを探る。
誰かが何かおかしなことを言っているなと思ったら、「なぜですか？」と詰問するかわりに「やり方を見せてもらえますか？」と聞いてみる。
最後に、「シニアステークホルダーは必ずポーカーに勝つ」というフレーズがすごく印象的だった。その通りで、シニアステークホルダーに「影響」を与えようとしたり、ましてや「対立」しても意味がない。結局のところ、決めるのはその人だからだ。
だからそうではなく、「情報を知らせる」ことに集中する。シニアステークホルダーが知らない情報はきっとある。それを適切に伝えることに集中すれば、最善の意思決定が可能になる。また、ユーザーのことをはじめとして、逆にシニアステークホルダーから学ぶこともできるだろう。
すべてをつなぐ
こうして、本物のチームを作ることができ、真にビジネス価値とユーザー価値を両立させることができる。
ゴール、戦略、指標等は、綺麗に並んだ層ではない。ぐちゃぐちゃで、トレードオフが避けられない。
それでも、安易に局所解に陥ってはいけない。全体のバランスを見ながら、できる限り最高になる一手を探す。
そのためにまず、ゴールや戦略は、シンプルにしておく。誰もが暗唱できるくらいに。
一方、戦術的な会話の例として「デザインの選択」や「期日の交渉」などがある。これらは、それ自体にフォーカスしすぎない方がいい。そういった会話は、ユーザーニーズやビジネスゴールについての戦略的な会話にレベルアップする。
ユーザーは誰で、何を考えているのか。その結果としてすぐれたデザインが導かれる。ビジネスの状況と戦略はどうなっているのか。その結果として期日の必然性や、選択肢の幅が導かれる。
こうすれば、チームが戦略を理解するチャンスが得られる。
アウトカムとアウトプットはつながっている。「アウトプットよりもアウトカムを」ということがよく言われるが、対立構造でとらえない方がいい。本当はアウトカムの「ための」アウトプットなのだ。
ユーザーニーズとビジネスニーズもやはり、対立構造にしてはいけない。ビジネスニーズを満たす「ための」ユーザーニーズ、という構造に持ち込む必要がある（※ユーザーニーズを捏造するということではなく、探索して発見する、ということ）。
戦略と戦術、ユーザーニーズとビジネスニーズ、指標とユーザーストーリー、といったすべてをつなぐ。
それらの階層、要素を行き来しながら、最善手を探り続ける。それがプロダクトマネジメントなんだと学んだ。
プロダクトマネジメントも「でも、やるんだよ」なんだな
『アジャイルサムライ』（邦訳）の最後の方に「でも、やるんだよ！」というフレーズが出てくる。
これがとても好きで、「決して簡単なことじゃないし、色々うまくいかないこともあるだろうけど、それがやるべきことなら、がんばろうぜ」くらいの意味の励ましの言葉だと受け取っているのだけど、プロダクトマネジメントもそうなんだなと思う。
ビジネスの世界は混沌としていて、だからこそ、すばらしいプロダクトを生み出すための、やはり混沌としたプロダクトマネジメントという活動に価値がある。
やっていこうと思います。
