こんにちは。李です。

現在は企業向け動画サービスのプロダクトマネージャーと、リクナビ進学アプリの開発ディレクターを担当しています。昨年度は新卒エンジニアとしてサーバーサイドを担当していましたが、今年の4月より上記業務を担当することになりました。

今回はエンジニアからプロダクトマネージャー（以下PM）へ転身するなかで、PM業務を何も知らなかった自分が、この9ヶ月間で取り組んできて良かった取り組みを紹介したいと思います。

PMの働き方は、チームの構成やメンバーの特徴に少なからぬ影響を受けると思います。事例紹介に入る前に、まずはチームの特徴を紹介します。

PMはいつでも臨機応変に動けるように、常に一定のパフォーマンスを発揮できることが求められると考えています。それを支えるのは心身の健康だと考えています。

PMは業務量も多いことから、長時間働くことが多いと思います。プロダクトを良くするためにやりたいはたくさんあるので、当然の結果だと思います。ただし、僕自身はどうすれば長時間働かなくて済むようにできるかをとても重視しています。人間は食事と睡眠なくては生きていけない生き物なので、24時間のうちそれらの時間は除外して行動設計を立てる必要があります。

僕自身は最低6時間寝なければ翌日に響くタイプなので、18時間から食事時間などを省いた16時間が活動時間として割ける上限値です。いつもこの16時間を上限値として考えるようにしています³⁾もちろんイコール業務時間ではないです。とはいえそんなこと言ってられない場合もあります。ただしそのような場面で多少の無理ができるためには、日頃から備えておく必要があると考えています。切り札は切らないことに意味があると聞いたことがありますが、どうすればそれを切らずに済むかを考えることは大事なプロセスだと考えています。

ずっと工学系だったこともあり、なんとなくビジネス書に触れる機会は少なかったのですが、プロジェクトを進めていく中でぶつかる壁には、書籍に解決の糸口が書かれていることが多くありました。食わず嫌いをしていましたが、組織論や経営に関しての本、問題解決手法の本などからは多くの学びを得られました。

特に、＜最高のリーダー、マネジャーがいつも考えているたったひとつのこと＞は、新米PMが抱えていそうなもやもやごとを一つずつ外していくかのように話が展開されていくため、読後感が良かったです。おすすめの本あれば紹介してください。

最高のリーダー、マネジャーがいつも考えているたったひとつのこと

社内のエンジニア有志で行われている、ドメイン駆動設計（以下DDD）の勉強会に参加していました。個人的な関心といったところもありますが、この勉強会からは多くの学びがありました

勉強会自体は章ごとに担当者を立て、持ち回りで発表を行うスタイルです。週に1時間で、前半30分で担当者が発表を行い後半30分で発表トピックに対して全員でディスカッションを行います。勉強会には様々なプロダクトからエンジニアが参加しており、自身の経験を交えて議論が行われます。僕自身は昨年度までエンジニアだったという背景もありますが、PMとして学べることがないだろうかと考えて参加していました。

PM自身は開発を行いませんが、自分たちがユーザーに届けているサービスがどのように作られているか、または作られるべきかといった観点は、サービス設計において生きる場面があると感じています。具体的にはプロジェクト立ち上がり時の役回りであったり、チームが使う共通の言語をどう整備するか？だったり、リファクタリングをいつ入れるのか？といったところは、わかりやすく効いてくると思いました。DDDは例が古くてわかりにくい箇所はあるもののそれぞれの役回りの観点から記述されており、何かしらの気付きが得られると思います。1人でやると心が折れるので、エンジニアが主催している場にちょっと顔を出すみたいな気持ちで始めてみると良さそうです。

オンラインコミュニケーションツールが充実してくると、ツール上で仕事が完結する場面が増えてきます。PMが仕様を記載しエンジニアがチケットを取るといったフローだけであれば、テキストコミュニケーションだけで完結します。

ただしどんな仕様がいいだろうかといったディスカッションや、こういうことやりたいんだけどといった話はテキストコミュニケーションではなかなか難しいと感じています。そういうときはFacetimeをかけるようにしています（要は電話）。直接会話することでもっと良いアイデアが出てきたり、潜在的なリスクを洗い出せたりと、テキストからこぼれ落ちる情報を拾い上げることができます。

電話をかける際には集中を妨げないように「13時〜15時の間に10分時間もらえますか？」など、事前にアポをとってかけています。また提示する時間帯も昼過ぎや夕方頃などの、仕事に区切りがあるタイミングで行えば気分転換にもなって効果的です。特にリモートワークは孤独を感じやすいので、メンバーと1対1で対話するということはチームの雰囲気を作るという観点でも重要だと感じています。

PMとして担当しているプロダクトでは、カスタマーサポート（以下CS）も担当しています。実際はサービスの規模が小さく、また、やる人がいないという外部要因から担当することになったのですが、結果的に担当して良かったと思います。

CSはユーザーと直接繋がれる数少ないチャネルです。この中で行われたやりとりは、サービスを改善する大きなヒントを秘めている可能性があります。将来的に規模が大きくなればPMがCSを行うことは非現実的ですが、CSからの問い合わせ内容は逐次把握していきたいと思います。

もともとタスク管理はやることをリスト状にただ並べただけのものを使っていたのですが、プロダクトを兼務し担当範囲が広がるにつれ、すぐにそのやり方では通用しなくなりました。

PMはチーム内でこぼれているボールは全て拾う振る舞いが求められるので、1日の中でも全く異なる業務を切り替えながら進めていく必要があります。一つのプロダクトでもなかなか慣れずに大変でしたが、9月より別プロダクトを兼任することになり頭を切り替える頻度が更に高まりました。差し込み対応などもエンジニア時代より増えるために、より柔軟なタスク管理の手法を考える必要がありました。

現在はGTDを取り入れて下記のように対応しています。

1. 2分以内で対応できるものはすぐに対応

2. すぐに対応できないものはタスク管理ツールに簡易的なメモ（いつまでに・何を・誰から・誰へ）とプロジェクトのラベルを添えて追加

3. 毎日朝と夕方に見直し、優先度を調整

やることは全てタスク管理ツールに記載されているという運用なので、優先度見直しのタイミングでタスクを入れ替え、ひとかたまりで着手できるようにしています。これでも実際あっぷあっぷになることがあるものの、それなりに機能しているように感じます。

現在会社ではトリプルディスプレイですが、一つのディスプレイは常に上記のタスク管理ツールだけを最大ウィンドウで表示するようにしています。そのディスプレイを見れば、何が残っていて次に何をすべきかが明確に分かる状態にしています。

PMは常にプロダクトのことを考えているものだといいますし、実際そうだと思います。仕事は誰かにお願いできても思考は誰かにお願いできません。そうと分かっているものの、慣れない間は日々の案件に追わてばかりでした。特にプロダクト引き継ぎを行った時期には引き継ぎ項目が多く、考える時間をほとんど設けられなくなっていました。

今は出社して30分間を最低限の時間として確保しています。この時間の中でプロダクトを触りながら気になることをメモしたり、次に何するかを考えたりしています。実際はこれでも全然足りませんが、朝一番のスケジュールとして組み込むことで考える時間が取れないといった状況を避けるようにしています。

プロジェクトを兼務する中で案件に追われてしまい、なかなか思う通りに仕事が進まない時期がありました。改善を測るためにはまず、現状がどうであるかを客観的に把握できる必要があります。何に時間がかかっているかを把握するために、１週間と期限を決めて、仕事を資料作成・打ち合わせ・調査・雑務・カスタマーサポートなどでラベル付けし、それぞれの時間を計測してみました。あとはその日の労働時間との比率を算出することで、どのラベルに何%割かれているかを可視化しました。

案の定打ち合わせが多かったのですが、資料作成や雑務の割合も目立っていました。何に多く時間がかかっているかが分かれば、あとはその要因を調査し対策を打つだけです。上述したタスク管理手法や考える時間をスケジュールに組み込むやり方は、この取り組みの中で生まれました。毎日行うことは大変なので、節目節目でやるのが良さそうです。

PMになることが決まり、多くの本や記事を読んでみましたが、結局やってみないとよく分からんなあと思うことが多くありました。よく分からないゆえに、とりあえず色んなことを試してみましたが、今回はその中でもやってみて良かったと思った取り組みだけをまとめてみました。ベテラン陣と話してると、それぞれのスタイルが見えたりしますが、スタイルがまだ身に付いていない新米の場合は、どれだけトライアンドエラーを繰り返しながら、自分のスタイルを確立していくかだと思います。また色々と試行錯誤をしてみます。