今回は #PM1年目を振り返る と題して新卒としての1年間をまとめた総括noteです。LINEにPMとして入社し、挫折したことや失敗、そこから学んだことをまとめていきます。#PM1年目を振り返るというハッシュタグを作ったのでよければ皆さんもまとめてみてください。同世代PMの悩みや学びをゆるやかに共有できると嬉しいです。

また内容としては、同世代のPMだけでなく、これからPMになる方にも参考にしていただけるといいなと思って書きました。若手PMを抱えるマネジメントレイヤーの方にもご覧いただいて、こんなこと考えているのかなど何か感じてもらえたらと幸いです。

本noteは構成は、新人PMとしての挫折と学びを3つに絞って書いています。そしてそれぞれについて具体例を用いて解説しています。拙文ですがどうぞよろしくお願いします。

・・・

1. 人を動かすことの難しさ

a. PMが意思決定者として形骸化している時がある
b. 認識のズレと情報の錯綜

LINEに入社して、いくつかのプロジェクトに関わって一番痛感したのは「人を動かすことの難しさ」でした。平均10人くらいのプロジェクトにアサインされていることが多いですが、初めてメンバーと会話するのがkick offで当然という環境にはしばらく慣れませんでした。初期の頃はメンバーが全員自分よりもずっと凄い人達なので、PMとしてプロジェクトを動かすことに気負っていたのだと思います。いまは割り切ってどんどん頼るようにしています。

a. PMが意思決定者として形骸化している時がある

エンジニアからの提案や意見に対して、僕はTechの知識に疎いため、背景や結果、懸念点などの理解に時間がかかることが多いです。しかし多くの場合、エンジニアは自分の中でイシューをすでに整理しているので、だんだんと説明コストをかけるのが手間になり、PMへの連絡が形骸化していっているなと感じることがありました。

これによりコミュニケーション自体が形骸化していき、信頼関係も築けなくなってしまうので、まずいなと気づきました。

そこで、自分の中で分からない点は分からないとはっきり伝え、問題点を理解をした上でPMとしての意思決定を伝えることで、ステークホルダーとのコミュニケーションが形式的にならず、信頼も得られるなと思いました。結果として今はエンジニアと話す時間も増え、力を合わせてより良い答えを出せる場面も増えてきました。

あとは単純に自分がテクニカルな分野に強くなる必要を改めて認識しました。よくBiz, UX, Techと言われますが、Tech分野の知識が圧倒的に足りない点がボトルネックになっているので、こちらについても今後は積極的に身につけていきたいと思っています。

b. 認識のズレと情報の錯綜

個別の会話が増えると、情報の鮮度の違いにより会話に齟齬が出始め、現場が混乱しますし、認識合わせのための不必要なコミュニケーションコストが発生してしまいます。それを防ぐために、話した内容は全てWIkiにまとめ、updateを各位に伝えるようにすることで「Wikiを灯台」とし、メンバーが迷った時にWikiを参照したら解決する状態を作ることが重要だと思いました。

また、大人数のプロジェクトになると、情報の問い合わせ先が混乱するため、Wikiに全員分の連絡先と共に、Role&Responsibilitiesを明文化しておくことなども重要だなと思いました。

2. 不確実性の低いプロジェクト実行の難しさ

a. いきなり自分の知らないところから刺されたりする
b. 企画の仕事の8割がErrorパターンを定義する仕事
c. 外部要因により、自分の手元に来た時には詰みかけてたりする
d. そもそも無理だったりする

a. いきなり自分の知らないところから刺されたりする
これは新人PMとして一番精神ダメージをくらってきた気がします。順調そうに見える（少なくとも主観ではそう）プロジェクトなのに、いきなり刺されたりします。あえて何に刺されるかは言いませんが、プロジェクトの障害はあらゆるところにあるのです。（下図: プロジェクトに関わる人）

問題は、プロジェクト進行中に刺されることではなく、手戻りが発生してしまうことです。ここで大事だと思ったのは企画段階におけるPMのビジョナリスト（spokesman)としての役割だと思いました。

まずはステークホルダーに企画を話し、実施にあたっての懸念点などを吸い上げ、出来るだけ事前に実施リスクを潰すことができます。会社によってステークホルダーの数や承認プロセスなども違うと思いますが、その順番なども大事です。例えば予算承認がないのに、キャンペーンの原資計算をしても意味はないですし、景表法上の整理がついていないのに、コンプラ・広告チェックはできません。ここら辺は会社の先輩側に話を聞きながらチェックリストを作って進めるのが一番早いと思っています。

b. 企画の仕事の8割がErrorパターンを定義する仕事
個人的な一番の反省と課題。仕様を書く際にErrorなどを全く考慮できていないひどい仕様書を書いてエンジニアを困らせてしまっていました。いまでもよく実装段階やQA段階で指摘されます。抜け漏れのない仕様を書くのは本当に難しいです。一つ解決に近づけるのは、なるべく早い段階でエンジニアレビューをもらうことですが、時間を奪ってしまうのであまり何度もできません。一つの考慮漏れ対応のためにメインの期待挙動やUIに影響を与えるリスクもあります。正直どうしたら「考慮漏れ」がなくなるのか未だに分からないです。

企画脳だとメインのストーリーばかり作り込んでしまうので、どうしても抜けてしまう。僕に足りないのは実装脳なのかなと思って最近プログラミング勉強をはじめました。ここは先輩PMの方の話などを伺いながらうまく仕様を詰めれるようになりたいです。

c. 外部要因により、自分の手元に来た時には詰みかけてたりする
d. そもそも無理だったりする
ここら辺はある程度の土壇場力と諦めも必要だなと学びました。ここでいう諦めとは投げ出すことではなく最低要件だけ満たして、他のところにリソースを使うという意味です。

3.「自分のせい」は無意味。 全体で考えることの大切さ

最後は内省の仕方の話です。いまの環境では毎月1on1があるのでその度に自分の課題や悩みなどの振り返りをしています。僕は多くのプロジェクトに関わる中でいくつもの失敗と改善を繰り返しました。その中で本質的でないなと思った振り返りの仕方について書きます。

まず僕ら新卒はまだまだ未熟です。なので身の回りの問題を「自分のせい」で思い込んでしまいがちです。「自分のせい」にすることは収まりが良いですし、謙虚で、何だか成長につながる気もします。

しかし、それはただの自己満足だと気付きました。あるプロジェクト全体で見たときにその問題の原因が「自分」にあるかどうかは重要ではないのです。一番重要なのは、その問題をいかに早く解決するかです。とはいえ、自分の成長のために振り返るのですから、自分という視点は大切です。そこでこんなフレームワークを教えてもらいました。

「誰が課題を抱えているか」、「それは解決可能かどうか」という軸でマトリクスを組んで課題を分解することで、より本質的な内省ができるようになってきたと思います。

極端な例ですが、スケジュールがないプロジェクトで良い企画を作れないのは当然です。それは自分に企画力がないからではなくそもそもリソースやスケジュールが足りないことが原因です。上のフレームワークと使って分解すれば、組織の課題として解決可能か考えることができます。そこで改善できるのであれば優先度を検討して対応するのが良いと思いますし、そもそも改善不可能であれば、条件を変えて再度検討するか、諦めて他のことにリソースを割いた方が良いです。

このように、根本的な原因を考えることをせずに全て自分の課題として整理するのは、課題に目を向けているようで、ただ課題解決プロセスを先送りしているだけに過ぎません。また副次的ですがこのような考え方をするようになったことで、解決不可能な課題と向き合わなくて済むので、精神的に楽になった側面もあります。

・・・

たまに、「メンバーからしたらこんな新卒PMじゃなくて、強いシニアPMと働きたいだろうなぁ」とか思いながら働いてました。正直結構辛い時もありました。

もう3月も終わりに差し掛かるこのタイミングで、このnoteを書いて色々棚卸できたので、4月からも引き続き頑張りたいなと思いました。

大嶋泰斗