はじめに
僕のこれまでの経歴は、営業職を2年ほど経験した後、わずかなマーケティングの経験のみ。Webデザインはもちろん、エンジニアリングについても浅く理解している(つもり)程度でした。
他職種からプロダクトマネージャーになったばかりの方、これからプロダクトマネージャーを目指す方向けに、非エンジニアの僕がプロダクトマネージャーとして働くなかで、実際につまずいた内容とその解決方法をご紹介します。
1.プロダクトマネージャーの仕事が何かわからない問題
何をする職種？
プロダクトマネージャーは、何をする職種なのか恥ずかしながら僕もプロダクトマネージャーになるまでは知りませんでした。
業務内容はあげればたくさんありますが、一言で言うと「プロダクトに対して全責任を負う仕事」だと考えています。プロダクトマネージャーの立場によって変わってくるとは思いますが、責任範囲は施策の進行の遅れや施策の価値など、プロダクトに関わること全てです。
企業や環境によって担うべき役割が変わってくる
そのため、いかに自分が組織の全体最適を取れる業務を担うか考えて意思決定をしないといけないことが多いです。
それもこれも、プロダクトをよくするため、施策がうまくいくための動きだと言えます。
業務範囲はエンジニアがやらないことすべて
施策の仕様決定、スケジュール設定、リリース後の数値集計、Nextアクションの選定、エンジニアの施策の進行を阻害する個々のタスク整理、スケジュール調整、時にはリリース前に行う検証のテストケース作成も行います。
予定通りに進行するか否かは、プロダクトマネージャーの立ち回りにかかっていると言えるでしょう。
2.プロジェクトのスケジュール感がつかめない問題
デザイナーの工数感がわからない
仕様のたたきが完成し、いざデザインを作成しよう、ワイヤーフレームを作成しようとなった時にそれを作成するデザイナーの工数感がわからない問題に直面しました。初めのうちは特に仕様検討段階でデザイナーと密にコミュニケーションをとり、わからないところは補ってもらいましょう。
エンジニアの工数感がわからない
デザインが決まり、仕様共有の際にプロジェクトのスケジュールも同時に確定させます。その前段階でおおよその工数感を出した上で臨みたい思った時に次にぶつかる壁が、エンジニアの工数感がわからないと言う問題です。
考えてもわからない問題なので、これもエンジニアに「こういうことをやりたいのですが、どのくらいかかりますか？」と聞くのが手取り早いです。
最低限、担当エンジニアが現在どこにリソースを割いているか？着手可能なタイミングはいつなのか？把握した上で仕様共有に臨みましょう。
スケジュール遅れにどう対応するべきかわからない
慣れないうちは、プランニング段階での仕様詰めの甘さによるスケジュールの遅延をよく起こしてしまいました。対策として、仕様を自分の中でFIXする前に、先輩プロダクトマネージャーや一緒に作るデザイナーやエンジニアに共有して、フィードバックをもらうことを徹底することにしました。そうすることで仕様の抜け漏れに早期に気づけたり、自分にはなかった発想を得ることがスムーズにできるようになり、仕様策定における遅延が減るようになりました。
3.一人で考えすぎてしまう問題
わからないものはいくら考えてもわからない
お願いされたタスクや、ミーティングで理解しきれないワードが何度も出てくることがあります。その時は、まず自分で考えた上で間違っていないか確認しましょう。時と場合にもよりますが、ミーティング中でも聞いてしまっても良いと思います。ただし、一度聞いたことを二度質問することのないようにする心がけは必要です。
致命的な認識のズレを避けるために確認はこまめにとる
プロジェクトが進行していく中で、実際に作るメンバーや施策を依頼してきた上長と仕様認識がズレる事態が発生することがあります。
誤った認識で実装が進行していた場合、例えば、作り直しといった追加工数が発生してしまうことがあります。
そこで、こまめに「こういうことであってますよね？」というコミュニケーションをとることが効果的です。
オープンなところでコミュニケーションをとるようにする
プロジェクトは複数人で進行するものです。決定事項や変更点などの共有が漏れてしまうことで、スケジュールの遅延につながってしまうことがあります。そのため、決定事項はSlackなど社内SNSで共有するようにしましょう。それによって、多くの人からフィードバックを得られる機会にもつながりますし、進捗の共有も同時にできるので心がけても良いかもしれません。
4.施策が太っちゃう問題
この仕様はなぜこうしたのか？
解決策を一生懸命考えて一つ提示したとしても、先輩プロダクトマネージャーからよく「なぜこの選択肢を取ったの？他の選択肢の方が優れているよね」と言い負かされることが多く悔しい思いをしました。エウレカのプロダクトマネージャーは「なぜこの問題を解決するか」だけでなく「どう解決するか」も考える仕事です。そのため、なぜと問われることが多いです。
なぜこうなったのか？を伝える上で、
・検討した選択肢を並べる
・工数感、ユーザビリティー、ビジネスインパクトなど検討要素に評価(◯、△、×など)をつけ理由を添える
こうして解決策としての仕様パターンに優先度を付けて、話し合いをすることで、自身の頭の中を整理できるとともにチームで議論がしやすくなり、今やるべきことが明確になるのでオススメです。
これもやれるんじゃない？あれもやりたいね！
あれもこれもやろうとすると当然リリースまでのスケジュールは後ろに押します。
アメリカのStandish Groupの調査によると、ソフトウェアの場合64%の機能は使われていないと言われています。アプリケーションの場合も同じことがいえると思っていて、工数をかけて実装したところでそれはユーザにとって必要のない機能だったということもしばしばあります。
小さく出して素早くフィードバック(メトリクス、VoC)を得ることで改善のチャンスが生まれます。
ユーザーが必要としている機能を提供するということは、プロジェクトの進行において最も意識している部分です。
これもやりたい！ってことが出てきたら、現状のリソースやビジネスインパクトを踏まえて優先度づけをしてバックログにしまっておきましょう。Nextアクションを練る際に何をやるか？工数感はどのくらいか？などの話から生まれるコミュニケーションコストを削減することができます。
※参照:Standish Group Chaos Reports Revisited
https://theagileexecutive.com/2010/01/11/standish-group-chaos-reports-revisited/
まとめ
・プランニング段階で出た思考や口頭での決定事項に関しては文字に起こす、仕様書は常に最新のものにアップグレードしておく
・一人で考えすぎず積極的に周りの力を借りる
・今何をやるのか？を考えた後に、何をやらないのかを考える
・プロダクト、プロジェクトに関しての全ての責任は自分にあることを常に意識する
以上4点を常に意識した上で業務に臨んでいます。
これからプロダクトマネージャーとして、1人のビジネスマンとして成長し続けるために最も大切なことは、「プロダクトやプロジェクトにおけるすべての責任は自分にある」ということをいかに常に意識して業務に望むことができるか、だとこの約半年間で感じました。
幸いなことに、今在籍しているエウレカはプロダクトマネージャーの評価基準があり、目指すべき指標が整いつつあります。新卒非エンジニアのプロダクトマネージャーの良い例になれるよう引き続き励もうと思います。
読んでくださりありがとうございました。