新米プロダクトマネージャーとしてやってみてよかった取り組み10選

リ ヒソン
205

この記事は RECRUIT MARKETING PARTNERS Advent Calendar 2015 の投稿記事です。

こんにちは。李です。

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

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

前提

PMの働き方は、チームの構成やメンバーの特徴に少なからぬ影響を受けると思います。事例紹介に入る前に、まずはチームの特徴を紹介します。
  • 少人数である
    • PM/Dir、デザイナー、サーバー、インフラ、フロントエンド、iOS、Androidそれぞれ1名。計5、6名で構成されています。
  • リモートワーク主体である
    • それぞれが週1〜3日の間で出社しており、全員が対面で集まるのは週に1日です。
  • 多くのメンバーがプロダクトを兼任している
    • 1人2つ以上のサービスを担当しているメンバーがほとんどです。

1. 徹底して情報を共有する

上記のようなチームの特徴から、プロジェクトスタート時より徹底して情報を共有することを心がけていました。

PMとして担当しているプロダクトは今年の5月からプロジェクトが動き出し、8月にリリースを迎えました。特にリリースを迎えるまでの間はすべてのミーティングの議事録を作成し、メンバーが閲覧可能な場所に置いていました。デザインや開発に関わることはもちろんですが、広報や人事との打ち合わせ、社内のセキュリティ部門や内部統制との打ち合わせなども全て議事録として起こしていました1)数えてみると、4ヶ月で83件記録していました。

全ての情報をメンバーが把握する必要はないものの、欲しいと思った時にすぐにアクセスできる状態に整えることは必要だと考えていました。記録した情報は、週次で行っている対面の定例の場にて口頭で共有していました。自分たちが作っているサービスがどのような状況であるかを、目線を合わせて進められたと思います。

議事録やドキュメントの作成行為そのものは、価値を生まない作業なので効率化を図っています。はじめのうちは要点がまとまらない上に時間もかかっていましたが、数をこなす中で少しずつ改善してきました。現在はアジェンダと確認ポイントを事前にまとめておき、打ち合わせの中でアジェンダの下に直接記述していくやり方を取っています。打ち合わせ終了後にはその下書きを見ながら何が話されていたかを整理し、次に何を行えば良いか?という観点を重視し、多少見やすく整える程度に留めています2)現在は打ち合わせ終了後15分ほどにまで短縮できています。

2. 活動限界を意識する

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

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

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

3. ビジネス書を読む

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

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

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

4. ソフトウェア設計手法を学ぶ

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

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

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

5. 電話をかける

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

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

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

6. カスタマーサポートを担当する

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

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

7. タスク管理のスタイルを身に付ける

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

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

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

1. 2分以内で対応できるものはすぐに対応
2. すぐに対応できないものはタスク管理ツールに簡易的なメモ(いつまでに・何を・誰から・誰へ)とプロジェクトのラベルを添えて追加
3. 毎日朝と夕方に見直し、優先度を調整

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

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

8. 考える時間をスケジュールに組み込む

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

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

9. 自分の仕事を計測する

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

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

10. 外に出る

ずっとチームの中で閉じて活動していると自分のチームを客観的に捉えられなくなります。客観的に捉えられないということは、チームやプロダクトをより良くする糸口を掴められないということへと繋がるため、特に新米のPMは積極的に外に出て行くべきだと考えています。社外の人とも話すことで視野を広く持てるようになります。

最近はネット上でもPM界隈が盛り上がりを見せており、交流の場も増えてきています。僕は下記のslackチャンネルに入りながら交流の場などに参加するようになりました。

プロダクトマネジメント(あるいはオーナシップ)に関心のあるひとが集まるSlack Teamを作成した

特にPMはエンジニアほどネットへの露出が多くない職種だと感じています。それゆえにリアルな場に出席し、同年代のPMと会話したりその道のベテランと会話することは生々しい知見が得られてとても有意義だと感じています。次はぜひ登壇者として参加したいです。

最後に

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

脚注

脚注
1 数えてみると、4ヶ月で83件記録していました。
2 現在は打ち合わせ終了後15分ほどにまで短縮できています。
3 もちろんイコール業務時間ではないです