この国では犬が

本と芝居とソフトウェア

世界に価値のあるプロダクトを届けたい

(この記事は、いわばセルフコーチングのメモ、というか議事録のようなものです)

世界に価値のあるプロダクトを届けたい。

これが僕の行動原理だ。
ということについては、大学を卒業して働き始めるかどうかといった頃に気づき始めたと思う。以降、この認識にほぼ「ブレ」はなく、時とともに「鮮明」になってきた、と感じている。当初はこのように言語化できてはいなかったが、10年以上の時を経るにつれて、焦点が合って、輪郭がはっきりしてきた感じだ。

ということは、たぶんそういうことなのだろう。
こだわるつもりはないが、そういうことだ、と当座認めてもよいとは思う。

僕の行動原理にはもう一つある。
これは、人なら誰しもそう、という気もするが、僕は特にこれが強いと思うので、あえて言及しておく。

自分が楽しく、幸福を感じていたい。

繰り返しにはなるが、これは人なら誰しもそうだとは思う。
ただ、世界に価値のあるプロダクトを届けることが唯一絶対の原理ではない、ということが言いたかった。自分が楽しく、幸福を感じられる方法で、その限りにおいて、世界に価値のあるプロダクトを届けたい、ということだ。

さて、それがわかったいま、何をするとよいだろうか。

「組織をよくする」ことに目が向きがちだと自認している。
自分の正式な守備範囲外のことであっても、ついつい首を突っ込んでしまう。よりよくしようと思ってしまう。

これは、自分が所属する組織が、より価値のあるプロダクトを届けられるようにするためにそうしている。
つまり、組織が主語になっているということだ。

組織が主語、を所与の条件としてシンプルに考えるなら、経営をするとよい、という結論におそらくなる。
経営とは、組織を主語にすることそのものであり、また組織の行く先を定めることでもあるからだ。

だが、そう簡単な話だろうか。

一見して、条件が2つあることに気づく。
まず、自ら経営を行うことが、本当に「自分が所属する組織が、より価値のあるプロダクトを届けられるようにする」ための最善の方法か、ということ。それから、経営を(十分)楽しく、幸福だと感じられるか、ということだ。

これら2つの条件には、因果に近い相関関係がある。わかりやすい言い方として「経営の才能」があるならば(「才能」という概念自体の当否は保留として)、前者は満たせるし、後者もそれなり以上には満たせるだろう。
一方、「経営の才能」がなかったとすれば、まず前者が容易には満たせない。才能を補うための努力をするとして、後者、つまりそれがどれだけ楽しく、幸福だと感じられるかも、せいぜい不透明といったところだ。

では、経営の才能とはなんだろうか、どうすればそれがわかるだろうか、ということを考えることもできるが、これはいったん保留とする。

実は、「経営をするとよい」という単純な結論には、もう一つ見落としている条件がある。

「世界に価値のあるプロダクトを届ける」ための単位(ユニット)が「組織」である、という前提だ。
この前提にはたぶん、それなりのバイアスがある。現代において、会社員として給与をもらうことが、安定的に生活するためのとても有力な手段であること。その手段に乗っかってこれまで生活してきたこと。

僕は無意識のうちに「組織」を所与と思い込んでいるが、おそらく実はそうではない。

もし「組織」というよりどころがなかったら、世界に価値のあるプロダクトを届けるために、僕はどうするのだろうか。

これは考えてみる価値のある問いだ。ただ、既存の組織に頼らずに、「自分が楽しく、幸福を感じられる」状態でいることはそう簡単ではない。それを満たしながら、価値のあるプロダクトを届けるということをも満たす方法を見出すのは、この記事の中では難しそうだ。

この記事は、下記を認識できたことを成果として、終わりとしたい。

  • 僕は、世界に価値のあるプロダクトを届けたい。これが行動原理だ。
  • また、自分が楽しく、幸福を感じていたい。これも重要で、譲れない。
    • なお、どちらが第一原理かは明確になっていない。
  • 「組織」を主語として考える習い性を見るに、「経営」をするとよさそうに思える。
  • しかし、「経営の才能」があるかどうかはわからない。そのため、本当に経営をするとよいかも現時点ではわからない。
    • 「経営の才能」がなかった場合、「(組織が)世界に価値のあるプロダクトを届ける」ために貢献する方法として、経営よりもよい方法がある可能性が高いし、「楽しさや幸福」についても概ね同じだろうからだ。
  • また、「組織」は究極的には所与ではない。組織を所与としないケースのことも考えてみる価値がある。
    • これは簡単ではなさそうなテーマに思える。また、今までこれについて真剣に考えてみたこともほとんどない。

2023年のふりかえり

今年もふりかえりブログを書く。

なんだかんだ、2013年にブログを始めてから今年まで、11年間続けているのだな。

やったこと

昨年末には、こう書いていた。

なんとなくだけど、社会にひらいていくのが次の新しいことという気はしている。
基本的に内向的というか、引きこもり気質というか、本質的に一人が好きみたいなところがあるんだけど、いやこの「本質的に一人が好き」っていうやつの解像度をもうちょっと上げてもいい頃合いなんだと思う。「本質的に一人が好き」だったら、こうやってブログ書いて公開したりしないと思うんですよね。だとしたら、の先に何か新しい可能性があるような気がしている。

う〜〜〜ん、どうだろう。

正直、あんまりひらいた感覚はない。

まあ、まだまだ若い業界(ソフトウェア業界のこと)ということもあってシニアと見なされるような立場になってきて、人を育てるとか、組織をよくするみたいなところに今まで以上に目が向いてきて、自分なりにやれることをやって。
これも言うなれば、社会にひらき始めている、とは言えるだろう。

わかったこと

でもどうだろうな、こんなものなのかな。
一つの会社の中で、組織のことを考えたり、周りの人を育てたりといったことが、なんとなく思い描いていた「社会にひらく」ことだったろうか。

そして、これがあまり向いているとも思えない。
いや、正確には、得意不得意はともかく、あまり好きではない、と言った方がいいか。

嫌いでもないんだけど、特に好きではない。
人を育てたり、組織を作ったり、といったことが。うん、別に嫌いではないんですけどね、必要ならやるし。

これをしっかり認識した一年だったと思う。

自分が何が好きか、ということを考えたとき、良くも悪くもというのか、昔からほとんど変わっていないことに気づく。
価値のあるものを生み出すことだ。

たぶん、この自分の本質は、子どもの頃に初詣で世界平和を願っていたり(価値のあるもの)や、漫画を描いたり、曲を作っていたりしていた(生み出す)頃からまったく変わっていない。

なーんか、人って変わらないんだな。

もちろん、強く願って行動すれば、変われることもあるだろう。
でも、僕は今のところ、これを強く変えたいとは思っていない。

次にやること

幸い、「価値のあるものを生み出すこと」は、自分だけでなく、周りの人たちや社会にとっても利益こそあれ、不利益はあまりない。と思う。
であれば、素直にそれを楽しんだらいいのだろう。

組織を作ったり、人を育てることも、見方を変えれば、価値を生み出していると言えなくもない。というか、言える。
ただ、今の自分の認識では、生み出している感触、手触り感というものがないんだよな。平たくいうと、自分で手を動かしたい、みたいなことなのだろう。

それを否定しても仕方ない。
否定するよりも、認識して、受け入れて、生かすというのか、「それならばこうしよう」を見出すのが王道というものだろう。

ただ、今の自分は、「価値」に強く目を向けた結果、「生み出す」の方をないがしろにするような状態になりがちに思える。
組織だったり、人だったりということに、吸い寄せられていく。ただ、それは心の底からやりたいことではない。(少なくとも、部分的には)

来年は、一つのトライとして、あえて「生み出すこと」に意識的に集中するようにしてみようかな。
そのとき、「価値」を多少ないがしろにしているように思えたとしても、心を鬼にして(?)「生み出すこと」の方を選んでみる。

それが王道を進む一つの方法なんじゃないかと思う。
試してみれば、何かがわかる。今の認識が更新されて、価値を大事にした方が本当にいいことがわかるかもしれないし。逆にやっぱり、「生み出すこと」を大事にした方が自分も幸せだし、周囲も幸せになるということがはっきりとわかるかもしれない。

螺旋を一周して帰ってきた感じ。
わくわくするな。

加点法で生きる

加点法で生きると、幸せを感じやすいのではないか。

そして、僕は普段から加点法で生きている。と思う。

昨日からなんとなく京都に一泊で来ていて、来るまでは大きな目的もなく、期待もなく、来てはみたものの楽しめるのだろうかというなぜか不安のようなものさえあった。

加点法なので、その時点では0点だ。
いや、まあ京都に行くというワクワクで、40点くらいはあったかもしれないか。

京都に着いて、10年前に眼鏡を買った店に行った。そこでとても気に入る眼鏡を買うことができた。
ここであっさり100点に到達した。

そうすると、ここからはボーナスタイムだ。

大学の頃の先輩が教えてくれたおでん屋さんに行ったところ、これがまたべらぼうによく、120点。足し合わせると220点だ。

こうなってくると、もう何があっても大抵大丈夫だ。

ホテルのシャワーが快適で、30点。ベッドも快適で、30点。
実は部屋に入ったとき若干臭ったが、加点法なので気にしなければいいだけだ。しばらく窓を開けていたら、爽やかな空気になった。

今朝は雨が降っていた。
京都の街を散歩しようと思っていたので、減点法だともしかしたら減点になるところかもしれない。

しかし、加点法なので「雨の京都を楽しめる」、20点。さらに、小雨になってきて歩きやすくなってきたので10点。
やがて雨はやんだ。なんだかんだ快適なので、20点。たぶん、初めからこの天気だった場合よりも合計点は高い。

これで330点ということになるのかな。
まあ、昨日の記憶は減衰しつつあるので3割くらいは割引になりそうだが、今日は他にも色々といいことがあったので、現在値でも300点くらいはあると思う。

ものごとのいいところを見る。

100点に達するまでは、多少の不快や不満を感じるかもしれないが、100点を超えてしまえば、ボーナスタイムなのだ。
基本的には、いいことしかなくなる。それが加点法の世界だ。

普段は、ちゃんと起きて、それなりに元気に1日を過ごすことができれば100点だと思っている。
だから、平日でもだいたい150点くらいにはなる。何か特にいいことがあった日は200点だ。

平日の朝、たいていあまり調子がよくないのは、単に夜型で朝が苦手だからだと思っていたけど、加点法で生きているから、というのもあるのかもしれない。
こればっかりは、加点法の弱みかもしれないな。

プロダクトマネージャーをチームの一員にする

この記事は、Uzabase Advent Calendar 2023の10日目の記事です。

昨日の記事は@itsukiyさんの「YAGNIから受け取ったメッセージ」でした。


まえおき

現在僕が所属するユーザベースでは、エンジニア、デザイナー、プロダクトマネージャーは別の組織に所属していて、チームとしてプロダクトを開発・運用する日々の活動はエンジニアからなるプロダクトチームのメンバーが中心となって行っています。

デザイナーやプロダクトマネージャーは兼務であることも多く、日常の多くの時間を共にしてはいません。
もちろん、その時間にデザイナーやプロダクトマネージャーもそれぞれがプロダクトにまつわる活動をしているわけですが、いわゆる全員同席状態、常に自然とチームとしての意識を持ちやすい状態ではない、ということです。

それでも、僕はデザイナーやプロダクトマネージャーを含めた「チーム」として考え、行動することが成功するプロダクトづくりのためにとても重要だと考えています。

それを実現するために、(現状のデフォルトとしての)エンジニアからなる開発チームとして、どのようにプロダクトマネージャーと付き合っていくのがよいか、ということを書きます。(今回はプロダクトマネージャーにフォーカスします)
これから書くことには実績のあることだけでなく、仮説も含まれますが、僕が実現していきたいチームの姿として書いてみます。

外部のステークホルダーではなく、チームの一員

この記事で言いたいことを一言でまとめると、「プロダクトマネージャーを、外部のステークホルダーではなくチームの一員にしよう」ということです。

しかし、日々の活動の中には、プロダクトマネージャーをステークホルダー的に、下手をすると「発注者」のように扱ってしまいかねない数々の罠があります。
ここからは、プロダクトマネージャーをチームの一員にしたいという前提で、「やってしまいがちだが、避けるべきこと」を「Dont's」、「かわりにこうしよう」を「Do's」というかたちで対比させながら記していきます。(なお、記事中の画像はすべてDALL·Eで生成しました)

意思決定に必要な情報を引き出す

Don'ts: 意思決定を委ねる

すべてを知っているプロダクトマネージャーとその他の人たち

プロダクトマネージャーは、その知識や経験から、どのような機能に取り組むか、どのような順序で取り組むか、どのような仕様にするかといったことについて決める能力が高いことが多いです。
僕がいる会社では特にこの傾向があるようです。プロダクトがB2B SaaSで、プロダクトマネージャーは営業や、CSといった職種の経験があるケースが多く、ユーザーと話したことも多ければ、自らユーザーとしての視点も強く持っているからだと思います。

だからといって、エンジニアから「どうしますか?」といった聞き方をし、意思決定を委ねてばかりでは、いつまで経ってもプロダクトマネージャーがいないと何も決められないままです。
意思決定を委ねてしまうことは、もともとある情報の偏りがならされないこと、意思決定をする経験の量自体にも偏りが出ることという2つの偏りにつながり、悪循環が生じるからです。

Do's: 意思決定に必要な情報を引き出す

プロダクトマネージャーと対話しながら意思決定するチーム

「どうしますか?」という質問は、たとえば「どうするのがいいと思いますか?」と言い換えることができます。

前者は決定そのものを委ねているのに対して、後者は決定のために必要な情報を引き出そうとする態度に一歩踏み出しています。
そこでプロダクトマネージャーが「○○するのがいいと思います」と言ったら、たとえばこういう風に続けることができます。「××だからですか?」、「その場合、ユーザーはどう嬉しいんでしょうか?」、「△△という場合についてはどうでしょうか?」。

こうすれば、チームはユーザーや、プロダクトを取り巻く環境について学ぶことができます。
さらには、プロダクトマネージャーを孤独にすることなく、プロダクトマネージャーを含むチームの共同責任において意思決定を行うことができます。

「どうしますか?」と「どうするのがいいと思いますか?」は小さな違いですが、重要な違いです。
チームが学び続ければ、やがて「こうしませんか?」と言えることも増えていくでしょう。

補足

これは「合議」や「全員の納得」を最重要視することとは違います。
結果として議論が盛り上がったり、全員が納得できる結論が導かれることも多くなるでしょうが、それ自体が目的ではありません。

チームがお互いに学び合って成長し、知りうる情報を最大限活用して意思決定し、エンジニアとしてコードだけではなく、プロダクトにコミットできるようになっていくことが目的です。

プロダクトマネージャーを情報源とのコネクターにする

Don'ts: プロダクトマネージャーを情報のボトルネックにする

外の世界とのやりとりはプロダクトマネージャーを通じて行う様子

プロダクトマネージャーはたいてい、エンジニアが知らないさまざまなことを知っています。

ユーザーのこと、ビジネスのこと、ステークホルダーのこと。
プロダクトが使われる世界のことも、組織のさまざまな事情も、多くの場合、一番知っているのはプロダクトマネージャーです。

だからといって、チームが情報を得るための源泉を、プロダクトマネージャーだけに限定していては危険です。

チームが情報を得る能力が、プロダクトマネージャーの能力(可処分時間、コミュニケーション力、情報処理力等のすべて)を上限としてしまうからです。
プロダクトマネージャーがボトルネックになっている状態です。それでは量も、多様性も足りません。

また、ユーザーや他部署とのやりとりの間にプロダクトマネージャーを挟んでいては、コミュニケーションの階層が増えることから、効率もスピードも落ち、お互いを知る機会も失ってしまいます。

最後に、プロダクトマネージャーが窓口になることで、受発注的な関係にも陥りやすくなってしまいます。
本当はユーザーとビジネスのためのプロダクトを作るチームのはずなのに、ユーザーとビジネスのことを考えているのはプロダクトマネージャーだけで、チームは言われたものを作るだけ、という状態です。

Do's: プロダクトマネージャーを情報源とのコネクターにする

プロダクトマネージャーのサポートで、自由に会話する人たち

プロダクトマネージャーには、情報のボトルネックではなく、情報源とのコネクターになってもらいましょう。

プロダクトマネージャーに頼んで、営業やCSの人を紹介してもらったり、一緒にユーザーと会わせてもらったり。

エンジニアと他部署のメンバーが直接つながれば、必要なことは直接やり取りしたり、CSの人とのつながりができれば、ユーザーに会わせてもらったり、といったこともできるようになります。

チーム全体が、プロダクトを取り巻く環境とすばやく、豊かなやり取りができるようになり、早く、多くのことを学べるようにます。

補足

個人的な考えですが、最近、文字通り「すべての」メンバーが「直接」ユーザーを知るべきだと思うようになりました。

以前は「開発に集中したいスペシャリストがいてもいいはずだ」と思っていました。しかし、スペシャリストであっても、ユーザーに直接会う経験は持った方が絶対にいいと感じています。

誰が、どういう環境で、どういう目的のためにプロダクトを使うのかということについて、直接ユーザーに会うことで得られる情報が圧倒的に多いからです。
量的にも、質的にも、人づてに聞くのと比べて、非常に大きな差があります。(このことについての解像度がまだ低く、これ以上うまく言語化できないのですが……)

その人自身が有用な情報を得られるという点でも、チームの人たちとのコミュニケーションが取りやすくなるという点でも、投資対効果が抜群に高いのが「ユーザーに会う」だということです。

もちろん、人によって頻度や濃淡は違っていいと思います。

一緒に仕事に取り組む機会を作る

Don'ts: すべての仕事を分担する

プロダクトマネージャーと別の時間を過ごすチーム

エンジニアのチームとプロダクトマネージャーとが同じ部屋で同じ時間を過ごしていない場合、コミュニケーションを取るまでの腰が重くなったり、非同期的なやり取りが中心になったりしやすいです。
「ここまではプロダクトマネージャーの仕事」「ここからはエンジニアの仕事」のように、境界線を引くような様子も、意識的にも無意識的にも、表れてきます。

すべての仕事を一緒にやる必要はないかもしれませんが、一方で、すべての仕事を分担するのも決して効果的とは言えません。

本当は、お互いの仕事の内容や、やり方から学べることがたくさんあり、結果的にチーム全体の成果ももっと大きくできるはずです。

Do's: 一緒に仕事に取り組む機会を作る

プロダクトマネージャーと一緒に仕事をするチーム

プログラマペアプログラミングやモブプログラミングをするように、プロダクトマネージャーとも、様々な仕事に「一緒に取り組む」機会を作ることができます。

たとえば、リリース計画やイテレーション計画。あるいは、受け入れテスト。プロダクトマネージャーにモブプログラミング自体に参加してもらうこともできます。

これは、「作った計画を説明して見てもらう」であったり、逆に「受け入れテストの定義をしてもらう」ということとは違います。
計画でも、受け入れテストでも、同じ時間、同じ場所で、一緒に計画を作り、一緒に受け入れテストを書く。プロセスも、成果物への責任も共同所有します。

補足1

計画や受け入れテストの例でいうと、もしかしたら、見積もりはあらかじめ済ませておいたり、受け入れテストの自動化コードを書くことはプログラマやテストエンジニアだけでやってもいいかもしれません。
必ず100%の作業を一緒にやろうという話ではありません。

もちろん、一緒にやるのもよいでしょう。

補足2

こういう取り組みは初めはエンジニアから提案し、プロダクトマネージャーに協力してもらうというかたちになることが多いと思います。

その場合、プロダクトマネージャーは慣れないことをしているわけなので、はじめはうまくできなくても大丈夫であることをしっかりと伝え、またやり方についても少しずつ伝えながら徐々に慣れていってもらうとよいでしょう。
一緒に取り組む時間や内容についても、少しずつ増やしたり、少しずつ複雑なものに取り組むようにしていくのがおすすめです。

また、一緒に取り組み続けることで、やがて本当に効果的な分担が見つかり、再び分担するのがよいということになっていくかもしれません。

補足3

最近は、「プロダクトマネージャーへの進捗報告」や、「プロダクトマネージャーが捕まらなくて困っている」などが、このDon'tsが生じているサインだと考えています。

「進捗報告」が必要になるのは、そもそもうまく分担できていないから。(上下関係になってしまっている)
プロダクトマネージャーが捕まらなくて困るのは、そもそも十分な目的と情報の共有・同期ができていないから。

どちらも、「一緒に取り組む時間を増やす」という方法で緩和・解消していけるのではないかという仮説を持っています。(※まだ実績が少なく、仮説レベルです)

お互いに学び合う

Don'ts: エンジニアだけが学ぶ

プロダクトマネージャーから学ぶエンジニアたち

エンジニアリングはすべてを具体化していく仕事なので、自然とプロダクトマネージャーから情報を「引き出す」側に回ることが多くなります。

すべてが具体化された「コード」を書くためには、不足している情報を発見し、聞き出し、確定させていく必要があるからです。

たとえば、エラー処理一つとっても、どうあるべきかを決めるには、ユーザーからどのように使われるかを知る必要があります。
作業の優先順位を決めるにも、ユーザーやビジネスから、どちらがより望まれているのかを知る必要があります。

これらの情報をプロダクトマネージャーに求めること自体が間違っているわけではありません。

しかし、聞く側・聞かれる側という関係が固定化してしまうと、他のDon'tsを誘発し、受発注的な関係に陥ってしまうリスクがあります。
また、エンジニアが知っていることの中には、プロダクトマネージャーも知っていればもっと適切でタイムリーな行動や意思決定ができることもあるはずです。

Do's: お互いに学び合う

お互いに学び合うチームとエンジニアたち

エンジニアがプロダクトマネージャーから学ぶように、プロダクトマネージャーにもエンジニアから学んでもらいましょう。

プロダクトマネージャーには特に好奇心や他職種のことを学ぶ意欲の強い人が多く、エンジニアが思っている以上に学びたがっている可能性が高いと思います。

計画のこと、テストのこと、リリースのこと。どういう理由、どういう考え方で、何をやっているのか。どこにどういうリスクがあり、また機会があるのか。
そういったことを、折に触れて、聞かれなくても、共有していくことはできます。

プロダクトマネージャーが何かを聞いてくれたら、怖い上司や取引先に伝えるようにではなく、すぐ隣の席の同僚に伝えるように、知っていることを気前よく伝えましょう。

文化や慣行、考え方の違いもあるでしょう。驚かせてしまうこともあるかもしれません。
それでも、いや、だからこそ、それらを伝え、学び合うことが、チームになるためには必要です。

補足

これは、デザイナーなどの他職種との間でも同様だと思います。
相手から学ぶことと、相手に学んでもらうことの両方ができているかを問うことは多くの場面で有効です。

おわりに

この記事では、エンジニアとプロダクトマネージャーが日常的には(一見)チームとして活動していない組織で、それでもチームになっていきたいとき、どうすればチームになっていけるかを書きました。

意思決定に必要な情報を引き出す、プロダクトマネージャーを情報源とのコネクターにする、一緒に仕事に取り組む機会を作る、お互いに学び合う。
これらの行動が、プロダクトマネージャーをチームの一員にし、チーム全体として強くなっていくために有効だと考えています。

そもそもなぜチームになっていきたいのか、ということについては特別に取り上げて触れてはいませんが、それぞれのDon'tsやDo'sの中である程度は表現できたのではないかと思います。

僕自身もまだまだ日々考えたり、試してはうまくいったり、いかなかったりしているところなので、記事へのフィードバックや、「自分(たち)はこうしているよ」といったコメントをお寄せいただけるととても嬉しいです。

『プロダクトマネージャーのしごと』から学んだこと

プロダクトマネージャーのしごと』は本当にすばらしい本だった。

邦題にこそ『プロダクトマネージャー』という役割名が入っているが(※原題は『Product Management in Practice』)プロダクトはみんなで作るものであり、ソフトウェアエンジニアである自分もまたプロダクトマネジメントの重要な部分を担っている。常にではなくとも、すぐれたプロダクトマネージャとしての振る舞いが求められる場面や、役に立つ場面というのも多いと感じる。
この本から学んだことをよりしっかりと身につけ、実践していけるように、自分が学んだことをまとめてみる。

学んだことは、「過程にとらわれず、価値に集中せよ」「ユーザー価値とビジネス価値、シニアステークホルダーとチーム、すべてをつなげ」の大きく2つにまとめることができる。
以降はこの大きな2つの切り口から、学んだことをまとめていく。

過程にとらわれず、価値に集中せよ

僕が何よりもこの本に目を開かされたのは、過程にとらわれず、価値に集中することの重要性についてだ。

もちろん、僕もアジャイルの実践者として、「やり方にとらわれることの愚かさ、危険性」についてはそれなりに理解し、気をつけているつもりではいた。
だが、全然甘かったと思った! すぐれたプロダクトマネージャというのは、本当に過程にとらわれず、価値に集中するものなのだ。

プロセスにとらわれないこと

プロダクトマネージャは常に、価値、またの名をアウトカムに目を向ける。

たとえば、何か「失敗」があったとき。すぐれたプロダクトマネージャはそこにある意図や感情よりも、アウトカムに目を向ける。

あるいは、「ロードマップ」が求められているとき。「ロードマップには機能ではなく、課題を書く」といった方法論も有用ではあるが、いきなりそれを持ち出しても仕方ない。
そうではなく、それが組織にとって何を意味するのかを明確にするために、求めている人に質問し、また作ったロードマップにもそれを明確に記す。そのロードマップから組織は何が得られ、何は得られないのかを明らかにする。

役割にとらわれないこと

この本によると、プロダクトマネージャはあいまいな仕事だ。そして、組織によってそれぞれ独自な仕事だ。
だから、役割期待を明らかにするには、周りの人と話すことが重要なのだ。プロダクトマネジメントの本に書いてあることをその通りにやるのが仕事じゃない。

ひるがえって、エンジニアである自分の周囲のプロダクトマネージャが「プロダクトマネージャらしいこと」をしてくれないと思うことがもしあったとしても、「プロダクトマネージャらしくないから」ではなく、「価値を作るために、なぜ、何をその人にしてほしいのか」といった切り口で率直に話したいと思う。

価値に集中すること

プロセスにも役割にもとらわれることのないすぐれたプロダクトマネージャは、常に顧客とビジネスインパクトから考える。
もちろん、そこに至る道筋は簡単じゃない(簡単だったらプロダクトマネージャは必要ない)。だから、道筋の候補は常に複数あり、変わり続ける優先順位を評価し続ける。

そして、ただ自分がそう考えるだけじゃない。ストーリーを作ったり、計画を立てたりといったチームの活動の中でも、常に戦略的なゴールと目的を会話の中心に置く。
そうすることで初めて、プロダクトチームは機能工場ではなく、プロダクトチームでいられる。

また、自分の時間の使い方についても、ゴールと優先順位を反映できているかに気を配る。すべてを最優先にしてしまって燃え尽きるのではなく、ゴールのために重要なことに時間を使い、最小限の労力で最大限のインパクトを出すことを目指す。それがチームや、ビジネスの持続性にとっても必要なことだからだ。

ユーザー価値とビジネス価値、シニアステークホルダーとチーム、すべてをつなげ

僕がこの本から学んだもう一つの大きなことは、プロダクトマネジメントには、「ユーザー価値」と「ビジネス価値」や、「シニアステークホルダー」と「チーム」といった、ときに矛盾したり、乖離したりしかねないものをつなぎ続けることが本当に重要だということだ。

今までもそれなりにプロダクトマネジメントに興味を持って学んできて、プロダクトマネージャが「つなぐ」役割であること、特にユーザとエンジニアの「翻訳者」のような中間者的立場に陥らず、両者を直接結びつけることが重要であることなどは知ってはいた。
だが、どうすればそれができるのかはよくわかっていなかった。この本にはその実践のヒントが山ほど書かれていた!

まず、ユーザーを知ること

プロダクトマネジメントでは、まず何よりもユーザーを知る必要がある。ユーザーを知らずに、ユーザーが使ってくれるプロダクトを作れるわけがない。当然のことだ。

『プロダクトマネージャーのしごと』を読んで、それが本当に重要であること、またどうすれば本当にユーザーを知ることができるのかのヒントが数多く得られた。

特に「ユーザーの現実に生きよ」という原則の観点からまとめられていたチェックリストには目を開かされた。ユーザーを知るとはこういうことか、と。
以下は、そのチェックリストからの引用だ。

  • 自分のチームは少なくとも週1回はユーザーや顧客から直接学んでいるか?
  • すべてのプロダクトに対する意思決定は、ビジネスゴールとユーザーニーズにもとづいているか?
  • 自分のチームは、ユーザーニーズや行動に対する理解を深めるために、定期的に自分たちのプロダクトと、それと競合・関連するプロダクトを使っているか?
  • ユーザーニーズと利用目的は実際の自分たちのユーザーのニーズと利用目的を反映してはっきりとまとめられているか? それとも、ビジネスが想像するニーズや目的だけか?

これらのチェックリストには示唆が詰まっている。ユーザーと話す機会は「少なくとも」週1回であることや、すべての意思決定がビジネスゴール「」ユーザーニーズにもとづいている必要があること。ユーザーを知るために、自分たちのプロダクトだけでなく、競合や関連プロダクトも使うこと。必要なのは想像ではなく現実のユーザーニーズであること。

色々あるけれど、出発点はとにかく、ユーザーと話すこと。
プロダクトマネージャだけでなく、プロダクトチーム全体が、継続的にユーザーと話し、学び続けていないなら、スタート地点にすら立っていないのだと思う。

明確にすること

効果的なプロダクトマネジメントにはコミュニケーションが不可欠だ。なかでも、明確なコミュニケーションが重要である、という主張からは勇気が得られた。
僕自身も、常々明確さを大事にしているからだ。それでも、明確さを保つのは難しく、心が折れそうになることもある。

先ほどと同様、「心地よさより明確さ」という原則の観点でまとめられたチェックリストを以下に引用しておく。

  • やっていることとその理由をチームが明確に理解をしているか確かめるために、必要な質問や会話のファシリテーションをしているか?
  • ユーザーやビジネスにとってより大きなアウトカムを得られそうだと思ったとき、他のチームやプロダクトマネージャーに積極的に働きかけにいくか?
  • 連絡してきたステークホルダーにすばやく、思慮深く反応しているか?
  • 解決策になりそうなことを探しているとき、いつも選択肢をいくつか示して、それぞれのトレードオフステークホルダーに説明しているか?

これらの記述からは、「伝わったはず」や「伝わるといいな」といった態度が排除されている。伝わるまでが自分の責任である、という覚悟が感じられる。
これはプロダクトマネージャに限らず、ソフトウェア開発に関わるすべての人に求められる態度だと思う。

伝え、学ぶこと

明確さを手に入れたら、プロダクトマネージャは異なる視点をつなぐことができる。伝え、また、学ぶのだ。

伝えることの重要性は、たとえば「自らを不要とせよ」という原則の一つに表れている。
自分がいなくてもチームが自ら正しい意思決定ができるように、予めプロダクトの意義や背景、ユーザーのことなどを伝えておく。伝えておく、というより、伝え続けている状態でいる、という方が正確かもしれない。

ドキュメントは不完全な「方がいい」という主張も面白い。その方がコラボレーションの余地があるからだ。これは伝えるということを超えて、チームとしてともに学び、知識を生み出すという態度だ。そのために、最初のドキュメントは1ページ1時間を上限とする、という指針が力強く、また心強い。

また、自分が発信するだけでなく、多様なステークホルダーの視点や協力を得る、ということも重要だ。そのために邪魔になるのが「守りの姿勢」で、役に立つのが「好奇心」だとこの本は説いている。「学ぶ姿勢」と言い換えてもいいだろう。

チームを守る、ユーザーを守る、プロダクトを守る。その対象がなんであれ「守る」という行動は邪魔になる。
一見、それらを守るのは正しく、美しくすら思える。しかし、「守る」ことは最終的にはうまくいかないのだ。

かわりに好奇心を持ち、教えてもらう。何かが脅かされているように見えるのは、おそらくそこに自分やチームが知らない・気づいていない何かがあるからだ。好奇心を持ってそれを探る。
誰かが何かおかしなことを言っているなと思ったら、「なぜですか?」と詰問するかわりに「やり方を見せてもらえますか?」と聞いてみる。

最後に、「シニアステークホルダーは必ずポーカーに勝つ」というフレーズがすごく印象的だった。その通りで、シニアステークホルダーに「影響」を与えようとしたり、ましてや「対立」しても意味がない。結局のところ、決めるのはその人だからだ。
だからそうではなく、「情報を知らせる」ことに集中する。シニアステークホルダーが知らない情報はきっとある。それを適切に伝えることに集中すれば、最善の意思決定が可能になる。また、ユーザーのことをはじめとして、逆にシニアステークホルダーから学ぶこともできるだろう。

すべてをつなぐ

こうして、本物のチームを作ることができ、真にビジネス価値とユーザー価値を両立させることができる。

ゴール、戦略、指標等は、綺麗に並んだ層ではない。ぐちゃぐちゃで、トレードオフが避けられない。
それでも、安易に局所解に陥ってはいけない。全体のバランスを見ながら、できる限り最高になる一手を探す。
そのためにまず、ゴールや戦略は、シンプルにしておく。誰もが暗唱できるくらいに。

一方、戦術的な会話の例として「デザインの選択」や「期日の交渉」などがある。これらは、それ自体にフォーカスしすぎない方がいい。そういった会話は、ユーザーニーズやビジネスゴールについての戦略的な会話にレベルアップする。
ユーザーは誰で、何を考えているのか。その結果としてすぐれたデザインが導かれる。ビジネスの状況と戦略はどうなっているのか。その結果として期日の必然性や、選択肢の幅が導かれる。
こうすれば、チームが戦略を理解するチャンスが得られる。

アウトカムとアウトプットはつながっている。「アウトプットよりもアウトカムを」ということがよく言われるが、対立構造でとらえない方がいい。本当はアウトカムの「ための」アウトプットなのだ。

ユーザーニーズとビジネスニーズもやはり、対立構造にしてはいけない。ビジネスニーズを満たす「ための」ユーザーニーズ、という構造に持ち込む必要がある(※ユーザーニーズを捏造するということではなく、探索して発見する、ということ)。

戦略と戦術、ユーザーニーズとビジネスニーズ、指標とユーザーストーリー、といったすべてをつなぐ。
それらの階層、要素を行き来しながら、最善手を探り続ける。それがプロダクトマネジメントなんだと学んだ。

プロダクトマネジメントも「でも、やるんだよ」なんだな

アジャイルサムライ』(邦訳)の最後の方に「でも、やるんだよ!」というフレーズが出てくる。
これがとても好きで、「決して簡単なことじゃないし、色々うまくいかないこともあるだろうけど、それがやるべきことなら、がんばろうぜ」くらいの意味の励ましの言葉だと受け取っているのだけど、プロダクトマネジメントもそうなんだなと思う。

ビジネスの世界は混沌としていて、だからこそ、すばらしいプロダクトを生み出すための、やはり混沌としたプロダクトマネジメントという活動に価値がある。
やっていこうと思います。