新卒2年目エンジニアが新機能開発でプロダクトマネージャーへの第一歩を踏み出した話

新卒採用でエンジニア志望の学生と話していると、こんな声をよく聞きます。

入社直後はエンジニアとしてキャリアをスタートさせ、プロダクトマネジメントにも挑戦したい

しかし、エンジニアからプロダクトマネジメント領域に手を広げていく上で、具体的にどういった取り組みをすればいいのかといった実例は少ないように思います。

僕は新卒2年目でエンジニアとして、社内プロダクト「SEARCH WRITE」 のフロントエンド 開発を担っています。一方、事業を作れるようになりたいという希望から、プロダクトマネージャーへの転身を徐々に進めている段階です。

今回プロダクトマネージャーへの第一歩として、SEARCH WRITEの新機能の企画からリリースまでをプロダクトマネージャー役として関わりました。その経験をお伝えし、駆け出しのプロダクトマネージャーがまずどのようなことをやっていけばいいのか、ひとつの参考にしていただければと思います。

プロダクトマネージャー役の仕事内容

ユーザーストーリーマップの作成

まずは新機能を作るにあたって、「なぜ作るのか」を言語化することから始めました。これまでエンジニアとしてSEARCH WRITEに関わってきていましたが、サービス全体の中でユーザーがどういった流れで各機能を使用するのかといった視点を持っていませんでした。新機能を作る上で、ユーザーにどのような価値を提供できるのかをカスタマーサクセスにヒアリングしました。ユーザーストーリマッピングを行い、目的からストーリーに分解しました

UX・UIの設計

次に、事業部(営業やカスタマーサクセス・サポートなどのビジネス側の部署。プロダクト開発においてはステークホルダーの位置付け)やプロダクトマネージャーと相談しながら、どういった機能が必要かを設計しました。不要な機能まで作りすぎることのないよう、まずは必要最小限のコア部分だけを考えていくことを意識しました。コア部分の機能をリストアップできたら、UI担当者に依頼してワイヤーフレームを作成しました。

プロダクトバックログの作成

PLAN-Bではスクラム開発を採用しているので、開発チームと相談しながらプロダクトバックログを作成しました。仕様を定義し、開発で必要な作業を洗い出します。その過程で新しく実装を行うだけではなく、既存の処理の修正なども必要になることが明らかになりました。それぞれの作業に対して完了条件を定義し、プロダクトバックログアイテムをリストアップしました。

スプリントの計画

プロダクトバックログの作成が終われば、実際に開発を行っていくフェーズになります。開発チームと相談しながら各プロダクトバックログアイテムの工数を見積もり、1週間のスプリントごとに着手していく順番を計画しました。開発スケジュールやリリース日などを周知し、事業部と開発チームで情報の齟齬が発生しないように結節点としての役割を意識しました。

フィードバック会の実施

修正による大きな手戻りが後から発生するのを防ぐため、事業部の方々に開発途中の新機能を実際に見てもらう機会を作ります。PLAN-Bのプロダクト開発では週次でスプリントレビューの時間を設けており、成果物を実際の画面で動かしながら確認を行っています。今回はセールスやカスタマーサクセスなどのメンバーもスプリントレビューに参加していただくことで、開発途中から適宜フィードバックをもらいました。その結果早めに修正点をプロダクトバックログに反映することができ、スムーズに開発を進めていくことができました。

プロダクトマネージャー役をやってよかったこと

プロダクトへの理解が深まった

これまでSEARCH WRITEを開発者の視点でしか見ていませんでしたが、今回の経験を通してプロダクト全体を見渡せる視野が身につきました。ユーザーにどのような価値を提供するのか。コストはどれくらい必要になるのか。プロダクトマネージャーとしての「眼」を養うことができました。それに伴ってSEARCH WRITEというプロダクトへの理解や当事者意識が上がったように思います。プロダクトの成功を自分が起点となって作っていきたいなという意識が芽生えました。

いつもより開発がスムーズだった

今回はプロダクトマネージャー役を担う一方で、新機能のフロントエンド開発も行いました。プロダクトマネージャー役として仕様に深く関わっていることから、普段より実装もスムーズに行うことができました。ユースケースを想像しプロダクト全体を見渡す視野を身につけることで、エンジニアとしてもよりよい開発ができる利点があるな、という気づきがありました。

工数削減の提案ができた

成果として一番大きかったのが、事業部に行った提案が受け入れられ、工数削減に貢献できたことです。当初、新機能をリリースするにあたって新しい価格プランを用意しようとしていました。しかし、新たなプランの開発には追加で3スプリント(3週間)程度必要で、またプロダクト戦略の一貫性を損なうリスクを孕むものでした。そこで、コストを下げて新機能を既存のプランに組み込む方法を提案しました。その結果、予定より早くリリースができ、既存プランのお客様にも新機能を提供することができました。プロダクトマネージャー役としてバリューを発揮できたなと思っています。

プロダクトマネージャー役をやる上で苦労したこと

場面ごとに説明力が求められた

プロダクトを運営していく上で、様々なステークホルダーと合意をとっていくことが不可欠です。プロダクトマネージャー役を担うようになって、いくつもの会議に出席するようになりました。それぞれの会議では出席者も議論の前提も違うので、場面に合わせて説明や提案の仕方を工夫する必要がありました。また「あれ、同じ話何回もしてない？」といったことはよくありました。ステークホルダーの合意を得られるように、ときには根気よく自分の意見を発信していくことが大切だなと思いました。

プライシングの議論がなかなか前に進まなかった

文章で書くと万事スムーズに進んだように思われるかもしれませんが、実際はなかなかうまく進まないことの連続でした。特に意思決定に時間がかかったのが前述した価格プランの設計です。
事業部の要求と開発チームの思惑がなかなか合わなかったり、自分のいないところで思わぬ方向に議論が進んでいたりして、なかなか前に進まない期間がありました。今ふりかえると意思決定を他者に委ねすぎていたなという反省があります。ステークホルダーの意見を聞きながらも常に議論の中心となり、最終的にはプロダクトマネージャーが決断への糸口を示すべきだという学びがありました。

まとめ

プロダクトマネージャー役として無事新機能をリリースできた一番の要因は、ステークホルダー全員に協力していただいたことだと思います。プロダクトの成功には各所の協力が欠かせないので、開発チームと事業部の双方とコミュニケーションをとり、その結節点となっていくことが最重要です。しかし同時に、自らの考えを提案し、周りを巻き込みながら意思決定を行っていく強さもプロダクトマネージャーには必要だなと実感しました。