信頼残高ゼロのプロダクトマネージャーのチームビルディング

2020年9月15日 23:19

はじめに

プロダクトマネージャーは一体何をすれば良いのか？というのは特にプロダクトマネージャーを始めたばかりの人にとっては頭を抱える問題かもしれません。実際にプロダクトマネージャーのカバー範囲は広く、また組織によってその役割も様々です。加えて、プロジェクトの規模によっては同じ役割の人間が周りにいなく、相談する相手がいない状況もあり得ます。
ただし、孤独な役割である事は確かですが、決して孤独に過ごせという事ではなく、いかに仲間を増やしていくかというのがプロダクトマネージャーの重要なスキルの一つなのかなあと思います。

僕が現在のチームにプロダクトマネージャーとして参画したタイミングは中途で入社して間も無く、ちょうどリニューアル案件がひと段落した頃でした。さあ、これからどうしようか？と思い悩みながらもそこから半年ほど経って少しづつチームとして成長してきた中で自分の振り返りとして書いてみた次第です。プロダクトマネージャーを始めたばかりの人に何かしら役に立てば幸いです。

読後感

・プロダクトマネージャーを始めた人が最初にどういう事を気にすれば良いのかが分かる
・プロダクトマネージャーの観点でチームビルディングで気にしておくと良い事が分かる

少し長くなってしまったので面倒な人は「まとめ」から読んでもらうと良いかもしれません。

プロダクトマネージャーの役割

言葉の通り、プロダクトをマネージする（どうにかする）という役割が求められます。その時々によって力を入れるパートに変化はあれど、サービスの成功に責任を負うという根源的な事に変わりはありません。

カバー範囲が広いというのは、サービスの方向性を作るにあたり、戦略からデザイン、開発、集客などプロダクトに関わる全ての領域にプロダクトマネージャーは責任を持つ必要があるからです。もちろん全ての権限を持っているわけではないし、現時点で全てに精通している必要もありません。（ただし、各パートで共通の言語でコミュニケーションはしなくてはいけないし、その努力もしないといけないですが。）

よくプロダクトマネージャーは「ミニCEOだ」なんて表現もされますが、これだけカバーする範囲が広いという事はそれだけの責任があるという事でもあります。

何でも屋、なんて言葉では片付けられない大変さがプロダクトマネージャーには求められます。「広く、深い」という難易度の高さですね・・・本当に大変。

一つの仮説

プロダクトマネージメントにおいて、いかに素早くプロダクトをデリバリーするかという事はとても優先順位の高い事だと思っています。そしてそれは自分が思っている以上に容易ではなく、試行錯誤しないといけない事です。

もしも、これからチームを組成する、もしくはプロダクトマネージャーというロールを設置する事になった時に、まず最初にやらないといけない事は「開発チームの力を最大化するための取り組み」だと僕は思っています。
効率良くプロダクトの開発を進める事は、結果としてその後のチームの成長にも繋がってくるはずです。少し言い方を変えると開発チームを強くするというのは投資であり、そしてそれは福利となって後々効いてきます。

そういったこともあり、まずは開発チームの事柄に取り組む事が良いのでは無いかという仮説からはじめました。

開発チームの力を最大化する

僕自身はエンジニアではないため、実装自体に関与出来ることはほとんどありません。ただし、開発効率を上げるための仕組みは作れると思っています。実際に自分で実施したことは大きくは以下の4点です。

1.開発プロセスの整備

2.優先順位をしっかりと決める

3.プロダクトにおける課題発見

4.コミュニケーションのデザイン

当たり前の事にも思えるかもしれませんが、入社してすぐの頃、現在のチームではこういった事をやっていました。正直、いきなり転職して入ってきた人間の信頼残高なんて限りなくゼロに近いですからとにかく認めてもらいたい、役に立てることはないだろうか？という気持ちもありました。そしてこういう取り組みを行う事で外からは見えないチームの課題も見つかっていきます。

また、これまでの経験則や知見などから「こういったら上手くいくだろうな」という勘もありましたが、最終的にはチームのど真ん中に入らないと分からない事もあるので、まずは仮説を元に色々と試していった感じです。

開発プロセスの整備

開発プロセスにおける課題は大きく以下の2点でした。

・タスクの可視化と更新
・不規則な開発サイクル

スクラム開発でのスプリントの概念とプロダクトバックログ、スプリントバックログの要素を取り入れる事でここら辺を解決出来そうだなと思ったので、受け入れられるか分からないけどしれっと提案してみたような気がします（記憶が曖昧でもしかしたら多少強引だったかもしれないけど）

▲当時の会議帯設計のメモ

開発サイクルを一定にする事で区切りを強制的に作り、リズム感を生み出します。終わりが見えない状態で足元の事だけをずっと頑張るのは短期間であれば良いのですが、この先中長期で開発を続ける事を考えるとあまり良い状態ではないように思いました。

また、それらを実現するために開発チーム全体で見た時にバックログの全量とそれが更新されているかどうかを明確にしておく事で、この後どれくらいのタスクが想定されているのかを正しく把握する事が出来ます。
リニューアルで積み重なって整理が止まってしまったチケットの山を地道に見ながら1週間くらいかけて別のタスク管理ツールに引越しさせてた気がします。その後、常時チケットが更新されている状態を作りました。この時点では仕様も背景も把握しきれていないので大分周りの人には助けてもらいました。
また、カンバンを朝会で見る習慣にした事で、カンバンの更新もチームで行うようになり、カンバンを見れば大体の状況は分かる所まで変更できたので、私のレポーティングも大分楽になりました。

移管自体は問題なかったのでスクラムに合わせた仕様が結構強めなJIRAにシフトさせています。ある程度、仕様の強制力があるツールの方が、使った事ない人にとってはインプットも兼ねるかなという理由です。あとは色々とJIRAの方が都合が良かったというのもありますが。いずれにせよ、プロジェクトの状況に合わせて目的を達成できる物を選ぶのが良いと思います。

また、タイミングを見て朝会やデイリーのリファインメントについてはファシリテートは持ち回り制にしました。開発プロセスをアップデートしていくのは最終的には開発チーム全体として頑張る所なので、年次に関係なく発言、推進していきやすい環境を早めに作りたいと思っていたので。（あとはファシリテートが当番制になれば僕が寝坊したとしても誰かがやってくれるはずという目論見）

加えて開発Readyの定義もこのタイミングで定義しています。「何を」「どこまでやれば」開発に進めるという認識を揃える事で手戻りやちょっとした食い違いを防ぐという効果があります。

▲開発フローの整理

開発プロセスの整備のまとめ

・定期的なイベント（会議）を再設計した
→会話するタイミングを一定にし、ファシリテートも全員でやる

・バックログの整理を行い、カンバンで確認、常時最新状態にした
→進捗の共有を楽にする。情報の透明度を上げる

・開発フローを定義した
不要な手戻りや認識の違いを解消するための共通ルールの策定

優先順位をしっかりと決める

プロダクト開発において、エンジニアリングだけではなくビジネス観点でも優先順位を決めていく必要があります。一番良くないのは、チームでの議論がされず、偏った状態でバックログが出来上がっていく事です。
ただし、この時点ではまだチームにおける「ものさし」が定義されていませんでした。まずはインプットした情報を元に、事業的にインパクトがあるかそうではないか、致命的なバグ、もしくは仕様変更か、をスプリントが始まる前日に関係者で整理する時間を作りました。

優先順位をスコアリングして定量的にインパクトを測るやり方もありますが、現時点ではまだそこまでやる必要もないためある程度の「ゆるさ」は残しています。どこまで仕組み化をするかは事業のフェーズやチームの規模にもよると思いますが、大事なのは優先順決めが有機的に機能しているかどうかだと思います。

優先順位のまとめ

必要な事が何かを明確にするため、事業インパクトとbugfixの濃淡をつけた
→急いでやらなくても良い事は後回しにする

プロダクトにおける課題発見

入社してすぐに実際にサービスを使ってくれているユーザーの方と話す機会があったのは助かった事の一つです。入社してまだ半月も経ってない頃、オフラインのイベントでユーザーにリニューアルしたばかりのアプリを使ってもらうユーザーリサーチをゲリラ的に行いました。仕様の理解も浅い中で、むしろ自分よりも使いこなしているユーザーに質問されたらという恐怖と、それでも実際に使っている人の声を聞くという純粋な好奇心と半々です。ただ、今のチームのテックリードとデザイナーと数名のインタビューが出来たのはとても良い経験でした。何よりこのタイミングでこういった機会に恵まれたのは「運が良かった」と思います。

その後もユーザーリサーチを実際に自分でやる事で見えてくる物はたくさんありました。想定以上にプロダクトの機能が理解されていなかったり、予想外の使い方をしていたり、当初の運営側の狙いとは反するケースも見えてきました。僕自身、経験はあった物のやはりユーザーリサーチは自分で設計して、自分でインタビューを行うという事をやらないといけないと思います。特に自分が新参者であった場合や、サービスがまだ世の中に知られていないフェーズの頃は苦手でもなんでも経験しておいた方が良いです。曖昧な言い方ではありますが「勘」を掴むためには「経験する」のが近道であることは間違い無いので。

ちなみにこの時点でのユーザーリサーチですが、極端にコストをかけなくても良いと思っています。対象となりそうな社内の人間に声をかける、友人に声をかける、などでも十分だと思います。実際に僕は、社内の人間、地元の友達、前職の同僚、などに手伝ってもらいました。幸か不幸かコロナの影響でリモートワークがメインとなっていたこともあり、zoomを使って協力してもらった感じです。手伝ってもらった方々には感謝です。（少し脱線しますがリモートワークの一番のメリットはオンラインでのユーザーインタビューのハードルが下がったことかもしれません）

感覚を掴むのと同時に、いくつかの機能の検証のために仮説を立てて機能改善を進めました。A/Bテストをやるには少し時間がかかる状態だったので、仮説を立てて機能をリリースして大雑把に検証をしました。（大雑把なのは適当、ではなくスピード優先で進めたという意味。恐らく。）

機能を改善して検証をするにあたっては仮説と振り返り、またやる意味というのをしっかりとチームで理解する必要があります。これに関してはドキュメントをテンプレート化して認識を合わせる方が後々楽になります。思い返すコストも積み重なるとしんどいので。
（テンプレート化についての詳細は別途書いていたものがあるので興味がある方はこちらをどうぞ。）

定量的な結果が出てくると徐々に「これは良い」「これは違っていた」という知見がチームに溜まってきます。まだまだやり切れてはいないですが引き続きやっていきたいと思います。また、現状では分析コストが高い状態ではあるのでここもなんとか自動化していきたいなと思っています。

プロダクトにおける課題発見のまとめ

・ユーザーリサーチは積極的に行った
→プロダクトにおける勘所を養うためにはまずはあの手この手でやってみる
→一般ユーザーではなく知り合いに協力してもらう形でもこの時点では十分

・勘所が理解出来たら機能改善で定量的に検証してみた
→仮説をチームに理解してもらう
→まずはやってみて大きな流れを把握する
→要件などはテンプレ化して、コミュニケーションコストを下げる
→やった事に対して定量的な結果を見る、検証の考察をまとめる

コミュニケーションのデザイン

少し抽象度の高い見出しですが、やった事としては目的とゴールを言語化した事と、開発プロセスを振り返る場を作る事でした。

まずはアジャイルのドキュメントであるインセプションデッキをチームで議論しながら作りました。全てを作る必要はないと思ったので、主には「エレベーターピッチ」と「我々はなぜここにいるのか？」です。
インセプションデッキという形を選んだのは単純に僕自身が慣れ親しんだ物という理由だけなので、別のフォーマットでも問題はないと思います。

とは言え、チームで共通の認識を持ちたかったのは

・どういった人に向けて、どんなサービスを作るのか？
・ビジネスとして達成したいことはなんなのか？

ということです。
冒頭に述べたように開発チームの力を最大化するというのは、議論ができる強いチームにするという事です。そのために我々には「ものさし」が必要でした。
もちろん、この「ものさし」はこの先間違うこともあるかもしれないし、外部要因により変えなくてはいけないこともあると思います。ただし、世の中確実な正解があるわけでもないので大事なのは一度「ものさし」を作る事で行動指針を意識する事だと思っています。作っては壊す、という事を恐れないチームになっていきたいものです。

また、定期的な振り返りをKPT方式で継続しています。どんな事でも良いと思っていますが、Keep、Problem、Tryで隔週毎に書き出して、最終的にチームで解決するProblemをTry化するのをメンバーで話して決めています。開始してしばらく経ったのでやり方をもう少し工夫しても良いかなと思っています。プロセスの変更の合意をこの場を使ってする事で納得感を持てるようにしています。ここを起点に、やり方を変えたり、これまでやっていた事をやめたりなどの議論が活発になっていくと良いなと思います。

コミュニケーションのデザインのまとめ

目的とゴールを定めた
→共通の行動指針となる「ものさし」を作る
→なんでやるのかを明確にする事で動きやすくする

定期的な振り返りをはじめた
→プロセス変更の合意の場所を作る

まとめ