1年を振り返る、マネーフォワード京都開発部で実践したプロダクトマネジメントのプロセス
こんにちは！マネーフォワード クラウド会計Plusのプロダクトオーナーをやっている杉浦です。
プロダクトマネージャー Advent Calendar 2020の20日目ですが、日々実践しているプロダクト全体像を描く、ユーザーの課題を見つけてエピックを作る、開発チームに渡すユーザーストーリーに落とし込むまでを紹介したいと思います。（書き始めるとかなりの長編になることがわかったので、プロダクト、エピック、ストーリーと分けて文章にすることにしました。）
ざっくり私のキャリア説明
新卒で上場企業経理部に就職、会計の可能性を信じてマネーフォワード経理部に転職後、2019年7月よりマネーフォワード クラウド会計Plus（以下、会計Plus）のプロダクトオーナーへ
経理をやっていて良かったと思えるような世界を作るため奮闘中
振り返って1年ちょっと前、POになった時は気がはやってばかりで、何をしたらいいか全くわからなかったんです。
このnoteでは、そんな1年前の私に「とりあえずこれ、参考にしてみたら？」という内容を目指しました。
プロセス通りにやってどうにかなる類のものではないと分かりつつも、一歩踏み出す参考にという感じです。
注：会計PlusはB2Bのプロダクトであり、スクラムで開発しています。
状況が違って参考にならない場合もあると思いますが、ユーザーの課題解決へ向けて一つでも参考になれば幸いです。
また自身の文脈に置き換えやすいように、私がよく自分に問いかけている内容も書いています。
プロダクト全体像をつくる
まずはプロダクトがどこに向かって行って、誰に価値を届けるのかを考えていきたいと思います。
このプロダクトのパート全体で言えることは、POはユーザー価値とビジネス価値の両方に責任を持つ役割として、議論をリードしつつ、両者を繋いでチームを作る働きが大事だと思っています。
またインセプションデッキやキックオフを開くなど今回書いた内容以外にもやったこと、やると良いことはあるのですが、プロダクトをユーザーに届けるまでに特にフォーカスすべきだと思ったところに絞って書いています。
ここでは『INSPIRED』を参考に進めています。
1.プロダクトビジョンをつくる
目的
ミッションを実現する説得力のある未来像を描く(1)
主に誰と
事業責任者、テックリード、有識者
ざっくりプロセス
1. ブレストで発散
2. まとめながら収束
3. できたものを壁打ち
どれくらい時間をかけて
頭出しから含めると3ヶ月以上時間を掛けていた
ツール
オフライン：ホワイトボード、付箋
オンライン：MURAL、Googleスライド（全体共有用に共通）
問い
実現したい、何回でも話したいと思えるビジョンになったか？
ビジネスサイド、開発共に納得するビジョンとなったか？
まず3年後、自社のミッション・ビジョンを念頭に、どんな世界を作って、どんな価値をユーザーに届けたいのか具体化していきます。
手順はシンプルに、
1.ブレストで発散
2.まとめながら収束
3.できたものを壁打ち
を繰り返していきました。
ブレスト段階から共有相手と一緒に行うこともあれば、事前に考えて共有して整理するでも状況に応じて対応すると良いと思います。（往々にして事業責任者もPOも忙しくて中々時間が合わないですよね...）
（こんな形でペタペタやりながら情報を整理しています）
ミーティングの進め方は以前書いたこちらもご参考下さい
私は元々経理部なので、ユーザーペインを軸に書き始めることが多いですが、as is/to beやマインドマップ、因果を繋いでビジョンまでのストーリーを作る(2)、システム思考等、使えるものは全て使うつもりで考えています。 あくまでフレームワークは気付いていないことに気付くために使うようにしています。
中でも壁打ちは大事にしていて、テックリード、デザイナー、ビジネスサイド、有識者と壁打ちをして、一人の考えではなく皆で目指したい世界にするよう細心の注意をはらってます。
参考文献
(1) マーティ・ケーガン, 神月謙一訳. 『INSPIRED 熱狂させる製品を生み出すプロダクトマネジメント』, 日本能率協会マネジメントセンター, 2019
(2) 楠木建.『ストーリーとしての競争戦略 優れた戦略の条件』. 東洋経済新報社, 2012
2.プロダクト戦略をつくる
目的
どのようにビジョン（あるいはマイルストーン）を達成するのか明らかにする(1)
主に誰と
事業責任者、テックリード、有識者、(プロセスの2以降から)開発チーム
ざっくりプロセス
1. ビジョンを元に最初に届けたいユーザー・市場を特定する
2. プロダクトのユーザーストーリーマッピングを行う(2)
1〜2の間、随時必要に応じてヒアリング等行いユーザーの解像度を上げる
3. プロダクトのMVPを決める
4. 開発チームで付箋にポイントを付ける
5. 付箋に優先順位をつける
どれくらい時間をかけて
ビジョンと並行して約2,3ヶ月掛けていた
ツール
オフライン：ホワイトボード、壁、付箋
オンライン：MURAL、ProductBoard
問い
やらないと決めたことはなにか？
描いたプロダクトを作って自分で売れると言えるか？
チームで共通理解を作れたか？
次にもう少し近い時間軸に目を移し、ビジョンに向かってユーザー価値とビジネス目標を達成するために何をどの順番で実現すべきかすり合わせます。
このユーザーストーリーマッピング（以下、USM）で作った付箋１枚１枚はこの後エピック作成のタイトルになります。
（プロダクトUSMの付箋がエピックの集合になり、エピックUSMがストーリーの集合になる）
2-1. ビジョンを元に、最初に届けたいユーザー・市場を特定する
製品開発で得られるあらゆる教訓の中で最も基本的な１つは、すべての人を同時に喜ばせようとすれば、ほぼ確実に誰も喜ばせられないということだ。（3）
『INSPIRED』の製品戦略の一番最初に書いてあるこの言葉ドキッとしますよね。ただ実際この言葉は本質を突いているなぁと思います。
マネーフォワードでPOの大先輩である廣原さんから、プロダクトづくりとプレゼントを贈ることは似ていると教えてもらったことがあります。本当に喜んでもらうプレゼントを贈ろうとしたら「誰でも」ではなく、「あなたに」を突き詰めないといけない、戦略も同じだと思って考えています。
ビジョンを達成するためにまずどのマーケット、ユーザーに価値を届けるか特定していきます。私はバックグラウンドがマーケットの専門家ではないので、ここでは事業責任者と密に進めるようにしています。
ユーザーの解像度が高くなければ誰に届けるか判断するための情報も足りないので、必要に応じてユーザーヒアリングを繰り返します。（どこかでユーザーヒアリングをどのように行ってるか文章化しておきたい...）
また、この段階でデザイナーも巻き込みペルソナを作るようにしています。
会計Plus開発の初期でも、最初にIPOマーケットの顧客に届けることを決め、ペルソナを作りました。これは開発チームだけでなく、セールス、サポートと広く共通の認識を作るのに役立ちました。
2-2. プロダクトのユーザーストーリーマッピングを行う
ユーザー・市場が特定されれば、どんなプロダクトを届けるかの解像度も上がってきます。プロダクトの全体像をUSMによって可視化します。
USMでは以下のプロセスで進めることが多いです。
1. 大きなストーリー（背骨）を作る
2. 登場人物を出す（先のペルソナと多くは被る）
3. ストーリーのボディを作る
ここではあくまでプロダクトレベルでの可視化がしたいことであり、一回で完成品（そもそもUSMの完成とは...？）を作ることは出来ません。
大きなストーリー、登場人物、ストーリーのどれも細かくなりすぎないように詰めていきます。
この時に重要なのは、完璧主義はさっさと捨ててしまうことだと思っています。ジェフ・パットンは『ユーザーストーリーマッピング』内のダビンチならどうする？の章で、繰り返しながら修正していく過程の大切さを紹介しています。最初から完璧を目指すのではなく、USMの中で情報を増やし、学習して、最終的により良いものを届ける。気長に気楽にやっていきます。
（実際には積み上げていってもモナリザは完成しない）
（繰り返し徐々に形にしていくことで、作品はできあがる）
引用元：Don’t Know What I Want, But I Know How to Get It
2-3. プロダクトのMVPを決める
全体像が具体化されてきたらMVPのラインを決めます。
ここまで喜ばれるプロダクトを考えてきたのだから順番に作ってけば？と思うかもしれませんが、あくまで仮説です。本当に価値あるものか、早くFBをもらい学習するためにMVPを決めます。
MVPを決める際に注意することは、価値を達成する尖ったものにすることです。
（ピラミッドの底を作るのではなく、刺さる部分の薄いピラミッドを作る）
引用元：MVP（Minimum Viable Product）とは？実践するメリットと検証方法
MVPのラインは、リリース前であれば、最小限の構成でFBを貰いにいくライン、リリースには最低入れたいライン、リリースブロックにはしないがUXのためにも届けたいラインを引きました。
私は実際にユーザーとして業務を体験しペインをよく感じていたため、MVPのラインを決めるときは、このラインで業務が薄く通せるからFBもらえる、このラインまであれば業務が普通に回せる、と付箋の上下をしていました。
この時、MVPと思えるものはどんな条件なんだろう？とずっと考えていたのですが、PMconfで近澤 良さんの講演を聞いて「これだ！」と思ったのが、Burning Needsという概念です。ユーザーの切実なペインを解消し、ビジネス価値もある。そのバランスをMVPではいつも探してます。
なおリリース後からは、ストーリー毎に断続的にリリースをするため、ここまで厳密にラインを引くことはしませんでした。
ただUSM→MVPの流れを簡易に行うと、全体像がどうしてもぼやける印象があります。リリース後も改めて目指すプロダクトの価値を再認識するという意味ではUSMからやり直したほうが良いように考えています。
また、いつでもやるべきことの方がたくさんあります。やらないことをはっきりさせるという意味でもMVPはしっかり決めたいと思います。
2-4. 開発チームで付箋にポイントを付ける
ここでは開発チームがリードし、付箋（エピック）を実現可能性の面からも評価します。
手順はざっくり、
1. 基準となるエピックを選ぶ
2. エピックに対し相対的に大きい小さいでざっくりポイントを付ける
とシンプルです。
目的はリスクを早く洗い出すことのため、ポイントを精緻に付けることは考えません。（フィボナッチ数を使うのもそのため）
ここでポイントが大きいということは、何かしら見通しのついていないもの（開発チームがビジネスロジックをわからない等）がある、技術的に難易度が高いということがわかるので、次の優先順位で重要な指標として使います。
またそもそも付箋の内容が大きすぎて分割すべきと判断するときもあると思います。
私自身まだ試行錯誤しているのですが、普段からこの記事の方法を参考にしています。
2-5. 付箋に優先順位をつける
最後に何から作っていくかを決めていきます。
重要度やリスクが高いものを上に持ってきて、早くチームで学習できるように優先順位をつけていきます。
またリリース後からは、ビジネスサイドの関係者を集め、並び替えながら理由を説明しています。ユーザー価値、ビジネス価値、リスクを反映させて優先順位を一緒につけることで、双方が納得感を持って動けるよう注意しています。（この前準備としてトレードオフスライダーを揃えておくこともしています）
ここではMURALのボードを例として用意しましたが、会計PlusではProductBoardを利用しており、ProductBoardのFEATURESからも同じように優先順位の並び替えを行うことが出来ます。
（ProductBoardではユーザーフィードバックをエピックに紐付けて管理することが可能で優先順位判断の助けにできます）
参考文献
(1)マーティ・ケーガン, 神月謙一訳. 『INSPIRED 熱狂させる製品を生み出すプロダクトマネジメント』, 日本能率協会マネジメントセンター, 2019
(2)Jeff Patton, 長尾 高弘 訳.『ユーザーストーリーマッピング』.オライリージャパン, 2015
(3)マーティ・ケーガン, 神月謙一訳. 『INSPIRED 熱狂させる製品を生み出すプロダクトマネジメント』2019. Kindle版 No.1901-1902
3.ステークホルダー共有
あとはこれをステークホルダーに広く共有します。
プロダクトオーナーはプロダクトのビジョン・戦略を広める役割として何度も何度も話すようにしています（と言いつつ前期は言い足りなくてブレかねないシーンもあったなと反省...）
リリース前後には、セールス、カスタマーサポート、カスタマーサクセスに説明会、勉強会を開催し、会社のイベントや半期総会などタイミングがあれば前に出て話すようにしていました。
リリース後はスプリントレビューのタイミングや半期のキックオフで伝えるようにしています。
前に出て自分の言葉で伝え続けることが部署に限定されないプロダクトチームを作るために必要なことなんだと思います。
最後に
拙いながら私の1年間の学びをまとめさせていただきました。少しでも参考になったら嬉しいです。
本当はもっと詳細を書きたかったのですが、その場合1プロセスで1記事にしないと、とてもじゃないが無理だと後から気付きました...
プロダクトマネージャー Advent Calendar 2020
明日は久津 佑介 / グロービスさんです！楽しみですね！
この記事が気に入ったらサポートをしてみませんか？