1人目のプロダクトマネージャーとしてプロダクト戦略を作った話
myTOKYOGASのプロダクトマネージャーをしている湯浅です。
私は2024年1月に入社しました。入社時点で配属となった組織では、開発手法としてスクラムを採用していましたが、日々のタスクに追われ、いわゆるプロダクトマネジメント機能の補強が必要な状況でした。私は、1人目のプロダクトマネージャーとして参画することになりました。
当記事は1人目のプロダクトマネージャーとして組織とプロダクト課題に取り組んだお話しです。
・新しくプロダクトマネージャーに着任した
・プロダクトマネージャーに任命されたが何から始めたらいいかわからないそんなシュチュエーションに置かれた方の参考になればと思います。
始めに
プロダクトマネージャーは介在する領域が広い職種です。
担当プロダクトにおけるプロダクトライフサイクルのフェーズや所属組織によって役割が大きく変わるため「何をする人？」と定義するのが難しいのが特徴だと思います。
当記事の取り組みを「プロダクトマネージャーの領域外では？」
と感じる方もいらっしゃると思いますが、その点ご了承ください。
また具体的にどのようにプロダクトを変更するかは、またの機会に紹介できたらと思います。
参画当初の状況と印象
myTOKYOGASはビジネス、デザイナー、エンジニアで構成される内製開発チームで運営されています。
※この記事では当チームを「開発チーム」と表記します。
・プロダクトがどこに向かうべきか定まらない
・開発チーム運営方法が本当にこれでいいのかわからない
このような課題感を参画当初インプットいただいたのですが、実情を把握するためチームミーティングに参加するとことにしました。
開発チームはスクラムを導入し試行錯誤しながら日々開発プロセスを改善している状況でした。
教科書にあるようなスクラムイベントを実施していて、チームでワークを行いインセプションデッキを作成も行なっていました。
中心メンバーも責任感をもって業務に取り組んでおりスプリントの回数を重ねれば良いチーム・プロダクトになっていくのでは？（その時点では判断が難しい）というのが参画当初の印象でした。
情報収集
情報量が少ないため課題を正確に把握できないと感じ、情報収集を改めて実施することにしました。
情報収集する事項は「組織状況」と「ドメイン知識」です。
組織状況の把握
まずはmyTOKYOGASに関わるメンバーに自己紹介を兼ねて雑談をすることから始めました。
対象は開発チームを構成するデザイナーやビジネス、エンジニア、加えてマーケティング担当などmyTOKYOGASに関わる周辺部門の方々です。
また過去検討事項やプロダクトバックログをチェック、定例会議出席によって組織がどのように構成され、動いているかを把握しました。
ドメイン知識の取得
新任プロダクトマネージャーが避けて通れないドメイン知識取得です。
企業や事業のビジネス構造の理解や、過去・現在のトレンド、顧客理解、プロダクトマネージャーでなくともドメイン知識の有無で業務パフォーマンスが大きく変わります。
入社するまでドメイン知識がほとんどなかったため、キャッチアップに苦労しました。
上長から共有してもらった社内資料や関連書籍を読んでドメイン知識を深めました。
情報収集をして見えてきたもの
myTOKYOGASの開発メンバーは顧客により良い体験を提供するため、日々カスタマーの声をサービスに反映し続けています。
顧客価値を実現しようと尽力する一方、このサービスが「東京ガスという企業」にどのような貢献をしているか定まっていませんでした。
開発案件の優先度を決める際も、優先順位付けが難しい場面がありました。
開発チーム内も「このプロダクトは何の意味があり何を提供しているのか？」という疑問を消すことができませんでした。
プロダクトと組織に不足していたもの
myTOKYOGASのコア機能は「使用量・料金を確認できること」であると共通認識がありつつも、東京ガスにどのようなビジネス価値を生み出しているか？それがプロダクトと組織として大きな問いになっていました。
myTOKYOGASは一般消費者向けの事業として運営されていますが、その事業へのどのような貢献をしていくかを明確化する必要がありました。
事業とプロダクトの戦略は同じ方向を向かないといけません。
今までmyTOKYOGASの運営に関係にヒアリングをしていましたが、事業戦略を担う組織まで対象を広げて情報収集をしました。
事業戦略上の重要事項へ紐づくようにプロダクト戦略を作成しました。
戦略作成する際に気をつけたこと
戦略を立てても実行できなければ絵に描いた餅です。
戦略が理解され、実現可能でなければなりません。
そのため2点に気をつけて戦略を作成しました。
メンバーの業務に紐付ける
戦略は様々なレイヤーと関係者に説明する必要があるため、抽象度が高くなります。
抽象度が高まると現場メンバーのイメージが湧きづらく、メンバーが動きづらいという問題が発生しがちです。
メンバーの協力が得られないと戦略実行が困難になるため、理解を得る必要があります。
そのため戦略を作成をする際に抽象度は保ちつつ、できるだけメンバーが取り組んでいる案件など現在の仕事に紐づくようにストーリーを作成しました。
実行可能性を担保する計画を立てる
今回の戦略を実行する際、現在運用していKGI・KPI、企画・開発プロセスを大きく変更する必要がありました。
目標指標とプロセス変更はメンバーの思考パターンを大きく変える事になり、負荷が高くなります。
戦略を策定していた当時から当面の間、開発チームは事業戦略として既に決定した開発案件の対応に追われ、新たに負荷をかけることは難しい状況でした。
そのため戦略を実行するために、部内の外のグループ員の協力を得て「施策検討チーム」を組織しました。
当チームで戦略実現をする案件の創出とロードマップを作成し、開発チームに渡すことで、プロセスを無理なくインストールする算段です。
現在は戦略チームでどんな案件を作るかを協議中です。
まだ道半ばではありますが、この取り組みを通じてmyTOKYOGASを利用者にとっても、事業にとっても価値のあるサービスにできればと思います。
みんなの矢印を揃えよう
今回の取り組みで、プロダクト戦略として組織の向かうべき矢印を作りました。
プロダクトに関わるメンバーは矢印向きが各人微妙に異なります。
矢印の向きが揃わないとチームのパワーは最大化できませんし、現場は混乱します。
皆さんの中には「当然のように矢印を定められている！」という方々もいらっしゃると思います。
ただ、定期的に矢印の向きを見直したり、メンバー各人の向きが揃っているかを確認することが必要だと思います。
・皆ですごい速さで全く違う角度に進んでしまっていた！
・進んでいるうちにみんなの見ている角度が変わっていた！
などを起こさないよう、定期的に角度の見直しとチームでの擦り合わせが大
切だと考えます。
これからもより良いプロダクトを作るためチーム全体で日々精進していきたいと思います。
最後まで読んでいただきありがとうございました。