なぜプロダクトマネージャーに？きっかけとなったプロジェクトを振り返ってみた
こんにちは！
エンジニア採用支援・組織支援を行うファインディで、フリーランスエンジニアと企業の業務委託案件をマッチングするFindy Freelanceのプロダクトマネージャーをしているしもはた （@t_shimo2）です。
今回、5月末〜6月上旬にかけてで、昨年秋頃から携わってきたプロジェクトが一段落したのでその振り返りをしてみようと思い立ち、本noteを書いています。
本noteを読むのに良さそうな人
- プロダクトに関する何かしらのプロジェクトを任されそうな人
- 役職としてはそうではないが、実際プロダクトマネージャーのような仕事をしている人
- プロダクトマネージャーに興味がある人
今思えば…プロダクトマネージャーを名乗ることの重要性
元々昨年夏頃から、事業成長に伴い、Findy Freelanceをご利用頂いているユーザー・企業向けの請求対応の改善の必要性、社内システム構築の必要性が言及されており、プロジェクトがスタートしていました。
そんな中で、当時自身が請求関連業務に携わっていたこともあり、開発ミーティングに参加することになり、気づいたら翌月には22件もissueを作成していた…！
というお話は初めて書いた以下noteにも書いていたりしますが、以下で書いた最初の3ヶ月はその後、本格的に組織図上もプロダクトマネジメントを担当するようになった今年からの話だったりするので、今回はその前の曖昧な立場で片手間で何でも屋として没頭していた時期のお話です。
当時の自分は、登録頂いたユーザーの対応アサインや、請求対応、契約締結対応等々、事業成長の中で間に落ちるボールを拾いまくる立場にいました。
そんな中で今度はプロダクトマネジメント（どちらかというと当時はプロジェクトマネジメント）のお仕事が間に落ちてきました。
（今でこそ組織図にもプロダクトマネジメントとして自分の名前がありますが、当時はひたすらオペレーションの量と質で勝負するフェーズだったためそこまでプロダクトマネジメントの重要度が高くない時期でした）
結果的にそのボールを拾い、既存の業務+αで開発企画業務をやっていくことになったわけですが、今振り返ってみると、プロジェクトを引き継いでその全体像を把握した時点で早々にプロダクトマネージャーを名乗り、メイン業務として腰を据えて取り組むことを決める、というのが最初の打ち手だったかなと思っています。
当時はそこまでの判断ができなかったため、最初は現場理解があったことを元にプロダクトバックログの優先順位を決める立場、スクラム開発におけるプロダクトオーナーのような立場から入っていく（ただし本当に最終意思決定責任を持っているかというと怪しい）という形になり、開発側からすると、結局誰に聞けば意思決定ができて話が進むのか？が曖昧な状況を生んでしまったと思います。
自分自身としてもプロダクトマネジメントに注力していくモチベーションと必要性があり、会社としてもプロダクトマネジメントが重要なフェーズであれば、まずはプロダクトマネージャーを名乗って自分の役割を定義し、片手間ではなくメイン業務として取り組んでいくことをおすすめします。
実際にプロジェクトに取り組んで、今思う大事だったこと
兎にも角にもプロジェクトを引き継いで進めていったのですが、そこからの学び、大事だったこととして、3つのことについてまとめたいと思います。
先程の「プロダクトマネージャーと名乗ること」以外にも、今振り返ると思い浮かぶのは、「目的の言語化」「口頭でのコミュニケーション」「トレードオフスライダーの設定」の3つです。
目的の言語化
本来、何かプロジェクトを始める上では、「なぜそれをやるのか？」「何のためにやるのか？」といういわゆるWhyの部分（もっと言えばCoreの部分）を考えていくことが重要ですが、当時はHowの部分にかなり意識が寄っていました。
結果としてスプレッドシートでつくっていたものを深く考えずに社内システムにトレースするような形で仕様策定し、後々実際の運用を考えるともっとこうすればスムーズなのでは？という意見が出て作り直した…というような苦い思い出もいくつかあったりします。
今だったら、最初にステークホルダーを集めてプロジェクトの目的を言語化し、関係各位の脳内のすり合わせをしてからやるだろうなと思い、今後に活かしたいと思っています。
口頭でのコミュニケーション
仮に目的が言語化されていれば、全てうまくいったのか？
答えは明確にNOです。
今回のプロジェクトは属人化していた請求関連の社内オペレーションの理解度が非常に重要となるものでした。
結果的にピーク時は1日数時間レベルの口頭でのすり合わせを開発メンバーと行い、「実際運用としてはこういう使い方をすることになる」「開発としてはこんなやり方もできるがどうだろう」というような会話を繰り返していました。
プロジェクトに入った当時はテキストコミュニケーション中心・補足が口頭、というスタイルでしたが、振り返ると当時全てをテキストに落とす時間も能力もなかったので、まず口頭ですり合わせ認識統一をする→その内容をテキストに落としていく、という形の方がスムーズだったと思っています。
結果として年明け〜プロジェクト一段落までの数ヶ月は凄まじい回数のSlackハドルミーティングを重ねることになりました。
プロダクトマネージャーとして、言語化してテキストに分かりやすく落とし込む力は非常に重要だと思っていますが、プロダクトマネージャーになっていきなりその力が付与されるわけでは当然ないので、まずは口頭でのコミュニケーションからテキストに落としていくことが大事だなと感じました。
その点、まずは議事録を取る、という新人あるある、やっぱり重要なんだなと再認識しました（月並み）
そういえば上記2点に加えてもう1点、「片手間でやらない」も大事でした笑
プロダクトマネジメントもプロジェクトマネジメントも、既存の業務+αでやるものではなかったですね…！
トレードオフ・スライダーの設定
「何を諦めるのかをはっきりさせる」
請求関連のシステム構築であったこともあり、事業部サイド・開発サイドのみならず、経理・管理部も巻き込んで社内のステークホルダーもそこそこいる状況でのプロジェクトでした。
管理部としては内部統制観点での仕組みを設けたシステム構築の必要性、
経理としては請求対応をスピーディに楽に行いたい、そのための要望、
事業部側としては上記よりも事業のトップラインに効く施策を挟み込みたい、
といったように、各所からの要望が相次ぐ状況が続きました。
気づいたら何ヶ月かに渡って、「来月いっぱいくらいでは一通りの実装が終わるかと思います」という言葉を使用することになっていました…
もちろん、上記全ての要望を叶えるためにスコープは常時MAXで時間もMAX！いつか終わればいいよ、というわけにもいかないので、結果的にはフェーズ1とフェーズ2で時期を分けて機能追加を進めていくこととなりました。
このあたり、当時は目の前のことでいっぱいいっぱいで、知識としてアジャイルサムライを読んでトレードオフ・スライダーの存在は知っていたのですが、その重要性を後から振り返って知る結果となりました。
というか今回挙げた3つ、全てアジャイルサムライに出てきた共通認識を持つための10の問いかけに表現は違えど出てきますね。
やっぱり名著ですね。また読み直そうと思います。
まとめ
プロダクトマネージャーになるきっかけとなったプロジェクトの振り返りから、以下のことについて本noteでは書いてみました。
プロダクトマネージャーとして名乗ることの重要性
実際にプロジェクトに取り組んでみて、今思う大事だったこと3つ
目的の言語化
口頭でのコミュニケーション
トレードオフ・スライダーの設定
アジャイルサムライは偉大
少しでも参考になれば幸いです。
そして、本プロジェクトでお世話になった社内外の皆さま、未熟ゆえ大変ご迷惑をおかけしましたが、本当にありがとうございました！！！
引き続きよろしくお願いいたします！！！
いつも最後に載せていますが、弊社絶賛採用中ですのでもしよろしければ以下もぜひご覧ください〜！
お待ちしています！！！
お読みいただきありがとうございました！
この記事が気に入ったらサポートをしてみませんか？