ベストプラクティスは誰かの体験談
こんにちは、プロダクトマネージャーのひまらつ（@himara2）です。
なにか方針を決めたり仕事のフローを定義したりするとき、ベストプラクティスがあるのはとてもありがたいものです。ベストプラクティスは最善・最良とされるものんまとめで、業界標準と同じような意味合いを持ちます。ただしその使い方には注意が必要で、目的を見失うと逆に振り回されてしまうとも感じています。
普段の仕事でベストプラクティスとどう向き合うべきなのか？このnoteではそのあたりを整理してみます。
ベストプラクティスは誰かの体験談
ベストプラクティスはまず何かしらの課題があり、それを解決するための方法を体系的にまとめたものです。過去の先達たちのノウハウに基づいています。導入する際にはそのベストプラクティスが何を解決するために考えられたのか、その課題の背景や当時の状況はどうだったのかなどを考慮する必要があります。
例えば優先度決めのフレームワークは多々ありますが、どれがフィットするかは組織によって違います。スタートアップなのか大企業なのか、意思決定者は一人なのか複数人なのか、ビジネスが得意なチームなのかプロダクトが得意なチームなのか。組織の状況によって課題は細く違う。業界を牽引している企業が採用しているから真似してみるのではなく、自分の組織の課題は何かを深掘りし、それを解決する手段として選ぶとよりパフォーマンスが出ます。
私はプロダクトマネージャーになる前はエンジニアをやっていました。大企業で作るサービスと個人開発のサービスとでは当然ながらフィットする設計パターンは違います。ゴツいアーキテクチャを個人開発に適用してもtoo muchになり、本質でない部分に時間がかかってしまいます。何のために導入するのか、目的意識が必要です（慣れたアーキテクチャで統一する、勉強目的など理由があればもちろんアリ）。
ベストプラクティスは体系的にまとまっているので便利ですが、大元の思想を理解していないと振り回されることになります。何か新しい課題が出たとき、そのプラクティスの理解度が低いと急に困ってしまいます。パッケージをそのまま使う分には良いんですが、カスタマイズして使おうとすると内容や意図を理解する必要が出てきます。
プロダクトマネージャーの役割・キャリアも多様
少し話がそれますが、プロダクトマネージャーのキャリアでも同じ様なことを思います。いろんなプロダクトマネージャーと話していると、その人のバックグラウンドによって考え方や動き方がかなり違ってくるなと感じます。例えば技術について、エンジニア出身のプロダクトマネージャーであれば技術への理解をテコに活躍する場を見つける一方、セールス出身で技術に詳しくなければ技術領域は信頼できるエンジニアのパートナーに任せて得意な数字の領域で勝負する。または働く環境の違いで、経営陣との距離が近ければ意思決定に多くの時間を割くが、階層化されている組織ではステークホルダーとの擦り合わせがより重要だったりする。
輝かしいプロダクトマネージャーの先輩たちのインタビューは読んでいてとても面白いですが、自分に反映する前には立ち止まって環境や自身の背景を考えると良いと思います。すべてにおいて完璧な人間はおらず、自分の強みを最大限活かすのを推してます（強みを見つけるために色々真似して試してみること自体はナイス）。
組織によって信じる神が違う
数字を何よりも正とする会社がある一方で、感覚を最重視する会社もあります。どちらも正解です。これは会社の色、ひいては経営者の考え方に大きく影響されます。
プロダクトは多くの場合で事業の肝になっているので、最終的には経営に近いところで意思決定されます。経営陣がどういう考えか、何を大切にしているかの影響をとても受けやすいといえます。自分が信じるものと会社のカルチャーがあまりに違うと不幸が起きるので、会社のバリューやミッションをよく読み事前に擦り合わせておくと良いです。実際に働いてみないと分からない部分も多いですが、副業や知り合いを探して聞くなど、精度を高める方法もありそうです。
カルチャーマッチが大事なのは何もプロダクトマネージャーに限ったことではありませんが、意思決定という不確かな判断が求められる職種なのでカルチャーマッチの重要性は増している気がします。すべてをロジックで説明できなくて、リスクがあって、それでも意思決定して前に進むタイミングがあります。その時に根底の価値観を共通できていると素早く判断できますし、素早い判断ができれば打席に立つ回数を増やせます。
ベストプラクティスが力を発揮するとき
ベストプラクティスが有効なときももちろんあります。ゼロから何か仕組みを作るとき、先達の方々の体系的な情報はとても役立ちます。
目の前にある課題には取り組めますが、難しいのは認知できていない問題があることです。ある道を進むとその先に別の問題がある。現在地からは見えないことも多く、進んでみてはじめて次の問題に直面します。
新たな問題を見つけたときに柔軟に進路変更できればよいのですが、コードベースのアーキテクチャなどは後から変更が難しいですし、優先度決めフレームワークようなプロセス的なものでも移行に時間がかかります。ベストプラクティスはこういったまだ見ぬ問題の解決もパッケージされているので、沿っておくと道を滑らかに進むことができます。導入時点では意図が分からなかったパーツに、時間を経て感謝することがよくあります。
なにかの問題解決を考えるとき、チームの共通言語としてフレームワークの知識があると議論しやすくなります。「このフレームワークのこの考え方は私たちの問題のヒントになるよね」みたいな。フレームワークの一部だけを取り出して都合の良いように改変して適用するのは賛否あるようですが、個人的には目の前の課題を解決するのが重要なのでアリだと思っています。ただ、その場その場でそれをやるとツギハギなものが出来て一貫性が失われるので、「将来的にはこうしたい。いまはいったんこの部分だけ取り入れる」のように長期の方向性含めて話せると良いのかなとは思っています。
ベストプラクティスとの向き合い方
バイブルにしている「プロダクトマネージャーのしごと 第2版」から引用します。
どんな状況でも使えるベストプラクティスによる成功にとっては、ベストプラクティスに従わない物事や人はすべて敵にみえるようになります。
（中略）
ベストプラクティスに関する会話は、たいてい楽観主義と希望に溢れて始まります。でもベストプラクティスが組織の既存の慣習やリズムと衝突するのは避けられないので、すぐに諦めと不満にとってかわられます。なぜベストプラクティスがうまくいかないんだ？誰のせいだ？わかっていないのは誰だ？そのような会話はたいていなんの助けにもならない残酷で断定的な結論で終わることになります。
ベストプラクティスはとても有効です。ただ、それを導入すること・従わせることが目的になると不協和音が生じます。自分たちの解決したい課題はなんなのか、なぜそれを導入する必要があるのかを見極め、良きツールとして付き合っていくのが良いのかなと思っています。
おわりに
ここまで書いてみて、ベストプラクティスとフレームワークが文中で混在していることに気づきました。この2つは自分のなかでは近い位置にあって、フレームワークに運用ガイドを添えたものがベストプラクティス、みたいなイメージでいます。このあたりの細かい定義というよりは「誰かが作った最強のメソッド」を盲信的に従うと不備が生じる、みたいなことを書きたかったつもりです。
先輩たちの知恵を生かしつつ、自分たちだからこそできる判断も大事にしていきたいと思っています。
プロダクトマネージャーをやりながら学んだことを「PdM日記」と名付けて書いてます。よければ読んでみてください:)
X (Twitter): @himara2