PMのミッションって何ですか？

こないだ、スタートアップを創業したばかりの知人や後輩とのアポが続いた日がありました。

どちらもいろんな話をしたけど、両方で出たのが

「PMのミッションって何なんでしょうね」

という話でした。

僕もよく悩んでいた話ですが、最近はちょっと考えが整理できてきてすっきりしたので書いてみます。

よく聞く疑問

PMと言うと、「ビジネスと技術を繋ぐこと」「円滑に進行させること」あたりが役割として思い浮かびますが、疑問はたくさんあって。

・どこまで権限を持つの？
・1つのプロダクトが会社のすべて。経営者との役割分担はどうすれば？
・エンジニアとデザイナーだけじゃダメ？PM必要？
・1人月分の仕事、ある？
・技術だけじゃなくセールスやお客さんのことも知ってて欲しい。無理？
・そもそも、どこにいるかわかんないし能力も測りにくい
・どうやって仕事ぶりを評価したらいい？

まあ簡単に言うと、「仕事としては具体的に何をするのか」「どんなスキルセットが必要か」「どんな権限と責任をもたせればいいのか」がよくわからんという話なのかなと思います。

PMは「成功の請負人」

僕の中で、ずっと昔からしっくり来ている表現がこれです。

PMは経営者から、「担当プロジェクトorプロダクトを成功に導くこと」を期待されているという考え方です。

「そんなの経営者だってそうやん」と思うかもしれませんが、
重要なポイントは「PMをアサインすれば、経営者はほぼ自動操縦でOK」ということです。

もちろん、経営者がやらないといけないこともあります。例えばこのあたりとか。

・PMから届くヘルプ要請に対して援護射撃や対処ができればやる
　　> 現行リソース内では解決できない問題
　　> 外部の力がないと解決が難しそうな難問やリスク
　　> 会社組織としての問題
・ゴールの認識が揃っているか定期的に確認する
・進行の品質やスピードに不満があればPMと話し合う
・メンバーをねぎらう（ｗ

とりあえず、PMが基本的に進行して困ってることをあげてくれるので、経営者はより抽象度と難易度の高い問題解決にフォーカスして成功確度を高めていくという感じです。

具体的な仕事内容は常に変化する

僕が思う大事なことは、「PMの仕事内容が固定化してる状態はまずい」ということです。

・事業や会社のフェーズ
・プロダクトを取り巻く社会環境
・現行のHigh-Priority案件の性質
・各メンバーのスキルセット
・各メンバーの成長目標

これだけのものが常に変化し続けているので、それをマネジメントする側の人間の仕事内容が変化しない訳がなくて。

PMが注力すべきことはどんどん変わるし、他のメンバーとのベストな役割分担も変化し続けます。

例えば...

【プロダクト立ち上げのKickOFF期】
不確実性のマネジメントと正確な言語化によるコミュニケーションに注力

【良い設計者がいないのがチームの課題】
設計や仕様のクオリティ・コントロールを自分or外部or仕組みで担保すること（と、採用）に注力

【ドタバタ期を抜けて強い組織作りをしたい】
メンバーが仕事から学習できてシェアしあえるような取り組みを根付かせたり、仕事や役割を委譲していくことに注力

無理やりまとめると、「成功にとって１番クリティカルなものを選んで対処すること」「怪しい現象に気付いて、問題を定義して、最適な解決が行われるように手配すること」が抽象的な仕事内容なのかなと思います。

逆に、仕事内容が固定化している場合は、きつい言い方をすると「仕事してる風」で、大事な問題がなかなか解決されていかないのでまずいです。

PMのスキルセットについて

これはよく聞かれるんですが、正直１番答えがないなと思ってます。

一応エンジニアやデザイナー同様、どの会社からもオファーがもらえるPMってのは存在して、そういう人は↓このあたりが強い人だなと思います。

・色んな背景や専門をもつ人と意思疎通ができる（まで諦めないｗ）こと
・新しいことや目の前の状況の要点を抑える精度とスピード
・課題マネジメント力

こういうタイプの人は、経営者なら少しディスカッションすれば判断できると思います。

難しいのは、世の中にはいろんなタイプの優秀なPMがいて、会社・事業によってPMに最低限求めるものが変わるので、PMのワークする/ワークしないは一概に言えない具合が大きいということです。。

とはいえ、僕的に確実に大事だと思うことは「歴史や人の話から学べること」かなと思います。

PMは新しいことに挑戦することが多いので、自分の経験以外から学ぶ術を持っていないと、全ての地雷を踏み抜いていくスタイルになってしまいます。

例えば初めてPMをやる人だって、ネット上にはPJ進行中に起きた悲劇だったり、職種間の連携がうまくいってないチームメンバーの悲鳴っていくらでも落ちているので、積極的にストーリーを収集して、失敗パターンを発見し、自分がやるときにはどう対策するかを考えれば、初案件でもけっこう上手に回せます。

「技術とデザインとビジネス全部知ってて欲しい！」という事情も、そのどれかが欠けているために悲劇が起きたという具体的なストーリーは世の中にたくさんあるので、まずはその悲劇が起きないようにすることに気を付けていれば大体クリアできるかなと思います。

PMの評価は難しいと思うけど、信頼・・ですかね

これは本当に難しいと思いますし僕もずっと「君の評価方法は難しいよ」と言われ続けてきました（ｗ）が、

客観的な評価方法が難しいだけで、評価観点は「事業・プロダクトの成果」と「経営者とチームメンバーからの信頼」の２つで決まりかなと思います。

特に信頼されていることは大事で、「あいつがちゃんとしてるから大丈夫」と言われる状態を常に志向して、足りない部分を補うことが必要かなと。

例えば、FinTechならリーガルわかってない時点で信頼して任すの怖いし、決済やセキュリティ面のQAを主導できないとリリース判断を任すの不安だと思います。仮説検証やロジックがあるわけでもなく要件が2転3転する人もメンバーからすると不安だったり、他にも色々です。

経営者からすると、PMにはプロダクトの成功を請け負ってもらうわけなので、仕事をしていく中で「こいつじゃアカンかも・・」という見極めは必要で、それを図る指標の1つが信頼かなあと思います。

上司・同僚・部下・メンバーあたりにヒアリングしてみると大体わかりますし、もし評価が著しく分散している人（上司評価は高いがメンバー評価は低いとか）はレポーティングが適切にできてないのでそもそもマネージャーには致命的みたいなポイントもあります。

この信頼っていう指標はセンシティブですが、「どのくらい信頼できると思っているか」はPMにはっきり伝える方が良いんじゃないかなと思います。理由や期待しているレベル感を一緒に伝えてあげれば問題ないかなと。

実際、もしPM本人に直接言わなかったとしても、結局は「重要なプロジェクトにアサインされるかどうか」で如実に伝わってしまうんですよね。「まだ不安だから軽めのやつで」という理由を隠したとしても、アサイン情報は誰もが知る情報なので隠すの無理だろうなと思ってます。

PMも神様ではないし人間として成長スピードの限界もあるので、期待水準の調整を経営者やメンバーと行うことで健全なチームが作れるかなと。

最後に

こんなところで一旦終わろうかと思います。もし気になる疑問に対して言及されてなかったりしたら、コメントでもDMでもいただければ記事にしてみようかなと思うのでお気軽にです。

あと申し訳程度に書いておきますが、大きすぎない会社での話を想定しています。（既に安定している事業のPMとか独立採算制取られてる会社でのPMは経験したことないのでわかりません）

今度はプロダクト開発チームとPMの関係の話とか、PMから見たデザイナーの話とかを書いてみようかなと思います。