プロダクトマネージャーのしごとを読んだ

背景

先日リファレンスチェックを実施していただき自分の弱みに触れる時間があった。
どうも自分は技術思考にかなり寄っているらしく緊急対応然り何かトラブルが発生した場合に、人とコミュニケーションを取って解決するのではなく、技術で突破しようとする癖があるらしい。
そういったフィードバックをいただいた訳だが、改めて自分のやり方を考えてみると確かに当てはまった。納期に間に合わなさそうとなると設計を変更して工数を短縮するし、フロントの描画が遅いとなるとコンポーネントの最適化に走る。
そこで、技術以外の解決方法という思考を身につけるため、手に取った本がプロダクトマネージャーのしごとだった。

www.oreilly.co.jp

そもそもなんで技術寄りになってしまうのか

理由は非常に単純で楽だから。
コミュニケーションをとって折半案を出すというのは、対人になる。
特にリモートだと非同期コミュニケーションが常に発生する為より難易度が向上する。
対して技術でどうにかするというのは、自分との同期コミュニケーションになるので、凄く楽。
ただ、それが本当にプロダクトに良い影響を与えてるとは限らない。
悪い影響を与える方が大きい可能性があるということを本書を読んで気付かされた。

アウトカムを意識する

アウトカムのためのアウトプットというキーワードが本書に登場するが、まずこれが出来ていなかった。
役員会で機能と納期が決定されており、それを突破するためにひたすら実装するというスタイルでやってきた。
役員レベルで決まっていることになるので基本的に意見を覆すことは絶対にできない。
そこにはアウトカムを意識した開発はなく、よくわからないけど依頼されたから実装するというスタイルに陥っていた。
無駄になった機能の数は計り知れない。
この経験からプロダクトオーナーのような現場と上層部の認識をすり合わせる役目が必要なのだと感じた。

無理に権限を超えない

エンジニアの採用が行き詰まっていたので、エンジニア専用の企業noteを作成し文化を外部公開し応募者数を上げようとした事がある。
これは権限を超えた行為であり、かなりの代償を伴うことを知った。
メールの文言を一語一句役員が管理する会社だったので、外部に公開する文書に関しては厳しいレビューが入る。
エンジニアが自分達で運用し公開するくらいの温度感で考えていたので、当初考えていたコストと全く違った。
一つの物事にコストを割り当てると、もう一つの物事からは引かれることになる。
その結果発生するのは、プロダクトの質の低下。
無理に権限を超えて解決しようとすると本来の役目がおろそかになりかねないので注意が必要。

曖昧にする部分と確定させる部分をハンドリングする

本書には危険ワードの紹介として「よさそうですね」という言葉が載っている。
実際に実施するかしないか、ふわふわとした言葉なので確定させた方がいいとのこと。
役員が隣で働いているような職場なので、この状況は頻繁に発生していた。この言葉を発した人間が高い権限を有している時は特に警戒すべき(その人の発言で180度ガラッと変わる可能性があるので)。
要件に関しては確定ばかりさせるのも良くない。
あえて曖昧にしてチームに持ち込みメンバーの成長を促す必要性もある。このことから、あえて曖昧にする部分と確定させる部分を自分の中で落とし込んでいく必要性がある。

好奇心は武器

人と円滑にコミュニケーションを取るためのコツはなんなのだろう。
その回答の一つが本書に記載されている「好奇心」である。
相手に興味を持って話しかけるか、そうでないかでは雲泥の差がある。
興味がない相手と会話するときは、双方伝える労力が大きくなるだろう。いざという時の味方を増やすために、普段から好奇心を持ち相手に接する事が重要。

言い方一つ

「なぜ、こんなことをしたんですか？」と「いい感じですね！チームがどのように、そのアイデアに行き着いたのか教えていただけませんか？」
どちらが答えやすいだろうか。
大半の人は後者と答えるだろう。
どちらの質問も、聞いてることは同じようなことである。
しかし、感触がまるっきり違う。
言い方一つで良い方向にも悪い方向にも行くのがコミュニケーションの難しさ。
これはプロダクトマネージャーとか関係なく使うべきテクニックなので少しずつ慣れていこうと思う。

まとめ

「プロダクトマネージャのしごと」は技術でなくコミュニケーションを使った解決方法を学ぶことができる。より運営寄りというかプロダクト寄りというかアウトカムを意識した志向も身につけていきたい。解決方法は増えるに越したことがない。
技術・マネジメント両方で思考できたらと思う。