大企業のあるべきプロダクトマネジメントむけて交通整備している話
こんにちは、天崎です！
この記事は、丸井グループ・marui unite・Mutureの有志メンバーによるアドベントカレンダーの17日目の記事です。
１はじめに
私の役割
私は丸井グループで、当社が発行するクレジットカードの、カード会員むけアプリや会員サイトの企画・運営・開発を行うプロダクト部で、PdMをやらせていただいています。
以前より、アプリの一部プロジェクトのPdMを任せて頂いておりましたが、今年の10月にmarui unite（マルイユナイト）という会社が設立され、そのタイミングでアプリだけでなく会員サイトまで見るようになりました💦
なお、会社設立を含む、これまでの取り組みの全体像については、新会社のCPOのかねはらさんが、先日詳細にnoteにまとめてくださっていますので、あわせてぜひご覧ください
今日の内容
私自身、PdMとしてまだまだ日々勉強中の身ではございますが、周囲の有識者に助けてもらいながらPdMとして課題と向き合い「大企業のプロダクトマネジメント」がどうあるべきかを日々模索しています。
上記のかねはらさんの記事にもあるように、ここ数年で丸井グループのトランスフォーメーションはどんどん前進しています。
これはとっても喜ばしい事で（私の感覚では）社員は急激に水を得た魚みたいなかんじになっています！直近でも、新会社もスタートして組織改編が行われたとで、今まで当たり前のように進行してきたこれまでのやり方に、実はびしろがあるのでは？という部分で新たに解像度があがった部分があり、まだ道半ばですが課題改善に向けてのメスを入れ始めているあれこれを一部共有します。
2. 実際に起きていた事と改善トライアル
ケース１：会社の方向性は明確な一方、チームの活動方針は曖昧
起きていたこと
そもそも、今会社がどんな方向を向いているか？何に力を入れていきたいのか？という大きなビジネスの方向性については経営層でも議論のうえ社内外に定期的に情報発信されており、会社のめざす方向性にむけて常に社員の目線もそちらに向いているというのは、丸井グループの良いところと感じています。
一方で、これまではアプリやネットのプロダクトを担う自分たちのチームが「今期自分たちがどこに力を入れるのか」という事を明確な方針が必ずしも示されていませんでした。
目標が全くなかったわけではないのですが「今期中にA案件の施策をローンチする」というような形で、どちらかと言うとアウトプットな考え方の目標設定がされており「会社として〇〇が重要なので、〇〇に注力していく」と言ったようなテーマやアウトカムによった目標設定は必ずしもされていなかったかと思います
というのも、会社の重点テーマに関してどの部署でどんな施策を検討しているのかや、その進捗状況は断片的な情報しかオープンになっていない事も少なくありません。
本当は、全部署の全資料がオープンになっていたら良いのですが、センシティブな情報が含まれていたり、まだ交渉中の取引先との商談情報などがドキュメントに記載されている事もあるため、企画段階の資料は該当部署内や一部のメンバーに留められている事がよくあります。そういった資料管理を想定してか共有フォルダの管理も厳格で、基本的には自部門のフォルダのみアクセス可能で、他部門のファイル閲覧は基本的にはできなくなっているのが現状です。もちろん、管理職以上が参加する会議体で、進捗のシェアはありますが、それ以外には該当部署に「教えて～」と、聞きに行かないと情報が入ってこないケースも多くあります。
改善のトライアル
取り組み1：情報収集と経営層との対話
私たちのようなプロダクトサイドと、企画立案を行うビジネスサイドは、会社の方向性を鑑みながら一体となって動いていく必要があるので、各部門で何を考えて何をしようとしているかを捉えて、方向性をまとめる必要がありました。
そこで、まず（クローズドになっていたものも含め）各部門で検討中の施策の資料を取り寄せました。そのうち、今期アプリや会員サイトなどのプロダクトが関連しそうな施策をピックアップし、一部は対象部門に詳細なヒアリングや温度感の確認も行いました。
加えて、それらの情報をもとにビジネスサイドの経営層とも対話しながら、課題感やステータスを鑑み、複数のテーマに対してどのような優先度をつけていくべきかを話し合いました。
取り組み2：プロダクトロードマップの策定
上記の内容を活動方針として、利用拡大、会員獲得、継続利用、の主に３つの要素に分解したうえで、ビジネスサイドの戦略に沿った形で各テーマとKGIを設定、プロダクトロードマップという形で作成しました。
それをビジネスサイドの経営層や管理職にも明示したのと、私たちプロダクトサイドの内部のメンバー向けにも期初に説明、疑問点などを解消する会を設けました。
「今期は私たちは〇〇に注力します！」「逆にこのロードマップに書いていない事は基本的にはやりません」という事を明確に示したのは、もしかするとはじめてのことだったかもしれません。
ケース２：ひっ迫する開発リソース
起きていたこと
これまでは、ビジネスサイドの各企画部門の担当者から、社内のシステム部門への担当者への企画に対する開発金額の見積依頼が、日々 五月雨式に来ていて、システム部門担当者の仕事の3-４割が見積算出という状況でした。
なぜそんなに多くの見積算出依頼が発生するのかと言うと、各企画部門にはそれぞれ別の目標があり、自分たちの目標を達成するためにも、早く見積算出を行ったうえで、「ビジネスサイドの経営層との対話や企画決裁を進めていきたい。」という力学が強く働き、結果的に大量の見積算出のやりとりが発生し、開発現場のリソースがひっ迫。
これまではロードマップもなかったですし、たとえ何のテーマに紐づくのかわからない意図が不明な施策が来たとしても、開発現場は真面目なので真摯に対応していました。これらの構造的な課題が、現場間での「受発注のような関係」や「上意下達的なコミュニケーション」を生みやすい状況にあったかと思います。
自分たちの目標に向かって施策を推進するビジネスサイドも熱量があって良いと思いますし、これまでそれに限られたリソースの中で対応してきた開発部門もすごいと思います。ただ少し交通整備が必要でした。
改善トライアル
取り組み1：企画の一次受けのプロセスの見直し
新しい取り組みとして、一次受けプロセスを見直しました。
これまでは、知らないうちに企画部門と開発部門の現場スタッフ同士でのやりとりが発生し、見えないところでリソースが割かれているケースもありました。
そこで、スタッフ同士のやりとりを廃止し、企画の最初の相談は管理職以上が統合的に判断して見積算出のやりとりを実施する。という運用に変更しました。
まだ新しい運用をはじめて間もないのですが、滑り出しの感触としては、
企画の精度が荒いものがそのまま現場におりる事も減りそう。
ビジネスを統合的に判断できる管理職が内容を確認しているので「A案件とB案件は一緒にやった方が良さそう」とか「これは今は保留にすべき」といった企画の統廃合がうまくできそう。
結果、現場のリソースひっ迫が解消できるのではないか？？と感じています。
一方で全ての企画を一次受けするPdMの私や他の管理職はちょっと大変ですが、現場がやるべきことに集中できるような環境がつくれるのであればとても有意義な取り組みであると思っています。
取り組み2：概算見積による企画決裁
さらに、企画の開発の工数見積についても、ルールを変更しています。この工数見積もりは何に使われるかというと、企画を実行するか否かの経営の判断に使われます。つまり費用対効果を図るときの「費用はどれくらいなんだ？」というのに使われます。
つまり、こと細かな詳細見積がなくても、だいたいいくらくらいで開発できるのかがわかればジャッジできるわけです。
ところが、企画の判断は概算見積で可能なのにも関わらず、これまで暗黙的に、時間をかけて詳細見積を算出し決裁資料に正確に記載する。というルールになっていました。
詳細見積を出すために、まだ企画のGOが出ていない施策に対して、現場は一生懸命大きなコミュニケーションやドキュメント作成に多くの時間を費やす・・・という実態がありました。そこで、企画段階では詳細見積を出すのではなく、概算見積を算出し、決裁資料のコストの欄にも、概算見積を記載して企画の実行か否かをジャッジする運用に変更しました。
結果、企画立案から実行のジャッジを行うまでのリードタイムも大幅に変更できるのではないかと考えております。
ケース３：企画部門から開発部門へのバケツリレー
起きていたこと
先で記載した通り、これまでの企画部門の頭の中は「急いで詳細見積を算出するために、細かい内容詰めて開発部門（プロダクトサイド）に依頼をするのだ！」という事が多かったですし、開発（プロダクトサイド）も「リソースがひっ迫していてUXを検討している暇がないので、言われた内容で詳細見積を出してどんどんさばいていかないとまわらない！」という状態に陥ることもありました。
そのため、ビジネスサイド（企画部門）がプロダクトサイドに一方的に依頼を送ってしまうことになり背景や目的が十分に共有されなかったり、逆にプロダクトサイドからシステムやUX的な考慮点についてビジネスサイドと相談しながら企画をブラッシュアップする時間が取れないこともありました。
結果的に、あとから考慮モレが発見され手戻りがあったり、開発途中でUXの問題点に気づくも新施策の公開時期をどうしてもずらせずに、継ぎはぎの応急処置的なUXでしかたなくファーストリリースを行う…なんてことも・・・。
改善トライアル
取り組み1：探索フェーズにてビジネスサイドの解像度をあげる
そもそも企画の趣旨や背景をより理解したうえで、リリースの優先順位やMVPを特定するべきなので、今現場で何が起こっているのかやユーザーインサイトの解像度を上げる必要あり、いきなり「何をつくる？」ではなくて「どんな価値を創出すべき？」という要求の整理を明確にしていくことが大事。と ここ数年で私は学びました。
となったときに、プロダクトサイドのメンバーがまずは現場に足を運び、ビジネス観点やユーザー観点で課題の解像度を上げつつ、開発観点で考慮点がないかなども考えながら目線合わせをしていく必要があります。
例えば直近でも、コールセンターに問合せが多いお手続きについて、アプリや会員サイトでデジタル完結できるようにする施策があったときに、資料上の数字やデータを確認するだけでなく、メンバーが実際にコールセンターに足を運んで現場に直接ヒアリングを行うなどしています。
取り組み2：横断的で継続的な連携とリズム
上記に記載した通り、企画の精度を向上するための調査段階で、ビジネスサイドとプロダクトサイドのメンバーが連携していくわけですが、意思決定の場や目線合わせの場も重要です。
私たちのチームは、スクラムのフレームワークを採用しており、直近ではスプリントレビューの場にはステークホルダーとして、該当の企画部門のメンバーや担当役員も参加頂く事をお願いをしています。
以前はスポットでご報告をすると言った関係製でしたが、企画（ビジネスサイド）の知見でレビューにはいってもらうことで、継続的に各観点が入った議論や意思決定ができるサイクルも生まれました。
開発する段階においても、各ビジネス部門と一体となって統合的にＵＸ構築していく必要があるので、プロトタイプや開発途中の成果物を確認するタイミングでも同様で、ローンチまでビジネスとプロダクトのメンバーが一体となった進行がスタートしています。
最近では、企画部門の役員とプロダクトサイドの役員などの上位レイヤーや、チームメンバーやパートナーベンダーメンバーが一度に集まってプロトタイプを囲って、議論するシーンが見られるようになり、プロダクトを中心に良い議論がされている場面が少しづつ見られるようになってきました
3.思ったことと今後について
おそらく、大企業のプロダクトマネジメントも一般的なプロダクトマネジメントとやっている事は一緒で、
①情報を集めて活動方針（ロードマップ）を整備する
②ロードマップに基づき企画の交通整備（統廃合）や優先度を精査する
③ビジネスサイドとプロダクトサイドと横ぐしで進行していく。
という部分は、同じなんだと思います。違いがあるとすれば、大企業で大きな組織の場合、関わる人数も当然多く組織も昨日単位で分断していることが多いと思いますので、プロダクトマネージャーとして必要な動きとして
①組織の壁を跨いで情報をちゃんととってきてまとめられる
②ビジネスの温度感を常に察知しながら、プロダクトサイドと繋ぐ
③各部門の力学を理解して、調整や交渉などできるといった能力がより求められていると思います。
特に③は、社内ではよく「仁義をきる」という表現をするのですが、例えば施策の優先度のトレードオフが発生しそうな場合に、PdMとしてその該当の各企画部門になるべく納得性高く説明し、ビジネスサイドとプロダクトサイドの友好的な関係を保ちつつ、高いアウトカムを得るために施策の優先度は妥協せずにあるべき進行を担保できるようなネゴシエーション的なスキルも重要であると感じています。今日記載させて頂いた取組は、まだはじまったばかりのトライアルの内容も含まれますので、継続的にブラッシュアップしながら進めていきますし、新たな課題も出てくるかもしれませんが、順番に良くしていきます
さいごに
以前は「多様なスキルが求められるＰｄＭは自分に務まるんだろうか、時間をかけて頑張るしかない！」と思っていましたが、あるべきに向けて周囲を巻き込んだり、臆せず他部門の上位レイヤーと対話する事は自分の少し得意な分野な気もするので、自分の得意を活かしてもう少し自信をもってすすめていくでもいいかなと思い始めました。
チームメンバーや専門人材などの有識者にも、それから上司にも助けてもらいながら、プロダクトや組織をもっともっと良い方向にどんどん進めていければなと思っています。
良いプロダクトをユーザーに届けていくため、みんなで協力しながらスピード感をもって現場から課題解決を推進していきます。
ここまで読んでいただきありがとうございました！
みなさまよいおとしを✨