hikoharu's blog

エンジニアリング、プロダクトについて考えていること。twitter: @hikoharu06

プロダクトマネージャーはSlack（ゆとり）が大事

プロダクトマネージャー

はじめに

プロダクトマネージャーをやっていると楽しい一方で、MTGや問い合わせ多くて、忙しすぎるという声をよく聞きます。

そこで本来集中すべきことは何かと、それを阻害する忙しさにどう対処するべきかまとめてみました。

PMの実態

組織内でPMが大変そうと思われる。周りからなりたくない職種と思われるのは危ないサインだと思います。

プロダクトマネージャーというとミニCEOと呼ばれたり、花形とか言われますが、実態としては割と忙殺されていて、職場でも「あの人すごいと思うんだけど、なりたいかと言われると、、、」 みたいに見られているのが多いんじゃないかと思います。

PMが忙しいパターンとそれぞれについて、どうやったらPMのゆとりを作れるかを考察します。

なお、自分がやって成果が出たというものばかりではなく やりたい or 改善中のものも含まれています

よくあるケースと処方箋について

PMが全部把握したいマンになっているケース

バックログのタスクの進捗は全部自分が把握していないと気がすまないし、MTGに全て参加しないと気がすまないタイプ とりあえずプロダクトに関わるから、、という理由でMTG参加依頼が大量に飛んでくる

一日がMTGとslackのメンションをさばくので気づけば終わっている、、、

処方箋
  • まず意識としてPMは主役ではなく、支える存在だという自覚を持ちましょう。プロダクトの全責任を取る役割だとしても、全てをPMが知ったり、やる必要はありません。
  • 組織内のPMの役割としてやること、やらないことを明確にしましょう
PMがタスク持ちすぎなケース

エンジニアに開発に集中してほしいばかりに、必要以上にエンジニアの仕事を巻き取っているケース

問い合わせだったり、プロジェクトマネジメントだったりがよくあるケース

処方箋
  • 開発チームを自己組織化していくように働きかけていきましょう
  • 開発チームとPMの期待値合わせをしましょう。本来は開発チームがやるべきタスクをPMがやっていると思っていても、その認識は双方で異なっているかもしれません。
  • 危なくなったら、単一障害点になる可能性があると開発チームに話しましょう
PMがコミュニケーションのハブになっているケース

PMはロール上色々な情報が入ってくるし、元々コミュニケーションが得意な人が多い。そこで「あいつに言ったら、背景もわかっているしよしなにやってくれる」的な見られ方で必要以上にハブとして使われているケース

特にデザイナー、Biz、Devの間や、異なる職能の開発チームの間に入ることが多いと思います

処方箋

大体こういう問題が起きるのは職能別組織（サーバーサイド、クライアント、インフラなどで開発チームが分かれている。マーケ組織も別）になっていて、ドメインと組織の見え方が違う時に起きます。

なので事業部組織に移行することで、一定の効果を見込めるのですが、PMのコミュニケーションコストの問題は解決しても、他の部分でトレードオフがあるのと、何より時間がかかり、PMの力だけで何とかできる問題でもないので、ここではもう少し地に足着いた方法を説明します。

直接解決できるというものではないのですが、第一歩としてはPMの仕事、やりたいと思っていることを周りに理解してもらうということです。 いわゆる関係の質の向上ですね

PMってただでさえ何者なのか明確でなく、加えて事業、組織によって役割全然違うので、職種に対する周囲の理解のハードルが非常に高いんですね。

PMという職種に何を期待すればいいかが皆わからないので、結果として他の職種に期待できないことを依頼せざるを得ないみたいな構造になっているという仮説です。

なので

  • PMは組織の中でどういう役割で、どうバリューを出していこうと考えているか
  • 実際に日頃何を考えて、どういう仕事をしているか

を明確にして、理解を助けるだけでも改善の方向に向かっていくと思っています。（ここ検証中）

実際に今やっていること

  • PMに関するドキュメント（ポエム的なもの）を発信していきましょう
  • 自分の分報でも、作業用スレッドでもいいので、積極的に取り組んでいること、考えていることをslackなどで実況中継していきましょう。思考プロセスを全て文字に起こして、見てもらうのが大事

おわりに

プロダクトマネージャーはプロダクトの全責任を負う人 という言葉が拡大解釈されて、何でもプロダクトマネージャーに任せればいいやというのは危ないサインです。

プロダクトマネージャーは、おそらくプロダクトに関して一番必要な情報を持っていて正確な判断をできる確率が高いと思います。

そこに判断を寄せるというのはある種正しいとは思うのですが、

これはプロダクトマネージャーが単一障害点になる可能性があるのと、組織として各メンバーにオーナーシップが生まれにくいという構造をトレードオフとして選択しているとも言えます。

スタートアップなどで人数が少ないうちは良いと思うんですが、10→100フェーズで組織が50人とか超えてくると、このトレードオフは厳しいなと、、

とはいえサッカーとかだと成熟したチームでも、特定のキーマンにボールを集中させるということもあるので、組織によって最適解は異なるという話になってしまいますが

ちなみにこの記事が大変わかりやすいです

プロダクトマネージャーは攻守の要（ボランチ）だと思う - Quest PM

ただどんな状況でも言えるのが、プロダクトマネージャーやっていると情報集まってくるし、重要な決断をすることが多いので、ついつい全能感を感じがちで、「俺がいないとプロダクトの進捗が止まる」 みたいなこと思ってしまうことが多いです。

そういう時には自戒をこめて、下記を思い出すようにしています。

エンジニアがいないと何も作れず、営業がいないと何も売れない、デザイナーがいないとプロダクトはわけのわからないものになる。
しかしプロダクトマネージャーがいない世界では、みんながその隙間を埋め、なんとかやっていきます。
プロダクトマネージャーはいなくてもいいのです。
長い目で見ればプロダクトマネジメントが成否を分けますが、プロダクトマネジメントは、
ほかには合うところがなかった変わり者と不合格者の集まりです。

世界で闘うプロダクトマネージャーになるための本　より

あと、もう一つプロダクトマネージャーとして肝に命じておくべきことが

グロースしていく中でプロダクトも組織もどんどん形を変えていきます。それによってこれまで上手くいっていたものが、組織が大きくなって上手くいかなくなるといった問題が大量に起こります。

プロダクトマネージャーというロールは他に比べて解決策の引き出しがとても多いのが特徴だと思います。

だからこそ、同じことをずっとやっていてはダメで、常に余裕を持って新しい問題を探し続けていないと、プロダクト全体の進化が遅くなってしまうと思います。

プロダクトに対してオーナーシップを持って、何でもやるというマインドを持ちつつも、やらないことを増やしていく（チームを強くして、移譲していく）。そしてそのslack（ゆとり）で新しいフェーズの問題を見つけ、解決していくのがPMの重要なミッションなのではないかと

プロダクトマネージャーはプロダクトのWhat,Whyを扱い、プロダクトを作っていくが実は
プロダクトを改善するエンジンを作ることこそが最も大事なのかもしれない

PMはスタートアップCEOに学べ！200枚超えスライドで贈る馬田隆明の白熱教室 | CAREER HACK

What,Whyを決めるというのはエンジンの中の１つの役割にすぎません。エンジンを設計して、どの部分をPM自身が担っていくかはとても重要なテーマです。