納得度の高いプロダクト開発とは何だったのか。後編

こんにちは。武田(@tkdn)です。納得度の高いプロダクト開発とは何だったのか 前編では、プロダクト開発に際して直接的な関与ができていない原因は、自分の中の無知・無関心にあったというところで終えました。

後編ではプロダクトマネジメントを意識しながら、どうやってものを作ろうとしているかについて書いていきます。前編よりは実践的になっているはずです。取り組みのご参考にされてください。


プロダクトマネジメントを意識する

昨年 11 月にキリの良い大きなリリースがあったため 12 月から 3 つプロダクトを抱えたチームは二手に分かれ、私は au Web ポータル無料ゲームというプロダクトの担当となりました(ヘッドレス CMS による運用についてこのブログでも触れたプロダクトです)。

まず取り掛かったことはプロダクトオーナー(以降 PO)に張り付いた業務を剥がすことと、プロダクトマネジメントの理解でした。

PO はステークホルダーからは期限を迫られ、開発からはできるか分からんと言われ、事業部全体では数字が足りないと言われる。それだけならまだしも、ミーティングや調整が多く、肝心なプロダクトのことやプロダクトが提供するユーザー価値や収益バランスについて深く考える時間の余裕があまりなさそうでした。

同時にプロダクトマネジメントについて理解を深めることで、PO の負担を減らすだけでなく、プロダクトチームを正しいものづくりに持っていく必要があると考えたのです。前編でも一部引用したようにプロダクトマネジメントは非常に強力な書籍となり、ここまでの活動を支えています。

PO やプロダクトマネージャーに委任することなく、現場で正しいと思ったことはすべて現場で取り組もうと考えたのです。

関心を持つための根幹を定義する

プロダクトチームが施策の優先度や意思決定の場面で立ち戻るための指針を定義する PRD(プロダクト要求定義書)からまずは着手しました。これは太い指針がなければ必ず折れる、立ち戻る場所がなければ離散すると考えたからです。

  • プロダクトの目標
  • プロダクト立ち上がりの背景
  • ターゲットユーザー、ペルソナ
  • なぜ作っているのか
  • 何を作っているのか
  • どういった機能を提供しているのか

参考にしたリソースはいくつかありますが、Tably 及川さんの資料にある項目を一番参考にしています。

幸いにも 2020 年前半に UX 部門のメンバーを中心にプロダクトリブランディングのためのワーク(スクリーンショット下部の Miro)を行っており、ビジネス提供方針、NPS 調査結果などを踏まえたユーザーの根本的要求の定義やペルソナやターゲットセグメントなど多くの考察をすでに行っていました。

技術畑からするとむずがゆいような内容に触れなくてはいけない場面もありますが、ここを定義しないと納得感を得られる自信がなかったため歯を食いしばりました。現状「なぜ開発しているのか」に立ち戻る原点にはなっているかなと感じています。

最適なプロダクトのカタを見つける

開発に際してはモブプロを中心とした組織学習をベースにしており、ほとんど息を吸うように実践していましたが、ことプロダクトマネジメントとなると何から手を付ければ良いかわからない状態です。現状十分に回せているかと言われると怪しいところですし、プロダクトのカタをうまく回せる工夫を今も実践中といったところです(以下の画像は書籍、プロダクトマネジメントからのものです)。

1 では企業活動の戦略的意図を実現するため、プロダクトが扱う課題へブレイクダウンさせる必要があります。収益とプロダクトをつなげる接点となるので本来は PdM と強く持つべき接点ですがうまく実践できていないところです。

2 では 1 における共通目標達成のための現状把握です。3 はその共通目標に対するオプション目標(目標達成のためのエピックと言えるでしょう)を立て実行に移していきます。4 で結果を振り返り継続し最適化するか別のソリューションを考えるかなど実績ベースでカタを繰り返すことになります。

これらカタ実践の前に、ソリューション先行による施策をやめるようにしています。具体的には共通目標に紐付かない・現状分析のない機能追加やツール導入の撤廃です。 プロダクトが目指す目標を意識したエピックを切り、数値ベースの試算をしたうえでリリース後の効果検証を繰り返しています。

幸運にも KR とした数値がプロダクトの達成度と成功を測るために最適なメトリクスであったため、基本的にはその数値を追い続けることになりました。これまで PO やアナリストに任せていたところにも関心を寄せ、構想と実行が分離しない形でなぜ我々は手を動かしているかの納得を得ようとしています。

ただしくツールを使う、たとえば JIRA

プロダクトチームはスクラムを実践してきており、ワークフローの可視化や日々のイベントで JIRA を利用していましたが、JIRA にあるエピックはいつの間にか緩いカテゴリやラベリングといった使い方で本来の意味を失っていました。

カタでも触れたように共通目標のためのオプションはすべてエピックされるべきで、それぞれが何を達成するのか明文化しておく必要があります。JIRA のエピックを機能させるべく使い方も改めました。

  • エピックにはテンプレートを用意しなぜこれを推進するか明記する
  • エピックはロードマップで可視化しリファインメントしやすくしておく

(エピックを色分けせず色気が出てないのはご勘弁ください)

プロダクトを世に放つのは開発者である

これはポジショントークととらえられる可能性も多分にありそうですが、最終的にプロダクトを動かしリリースしているのはまごうことなく開発者です。プロダクトマネジメントトライアングルにある、プロダクト・ソフトウェアを起点とした根源的要素として開発者、ユーザー、ビジネス(収益)の 3 点で構成されていることからもよく分かります。

コードをアップデートする人たちこそが唯一厳密に欠くことのできないチーム要員だ。開発者は会社のすべての責務を担うことができる(常に効果的にとは行かないが)。

どこまでの責務を追うか・プロダクトマネジメントにあたるような業務まで手を伸ばすかは開発者それぞれですが、介入していったほうが圧倒的に納得感が高いはずですし、コミットできる深さも違うはずだと今は感じます。

課題はないのか

模索しながらなのでまだつかみきれていない部分や課題もたくさんあります。

誰と何をどこまでやるべきかは整理しきれていないので、開発者が踏み込んでよいか微妙なラインで取り組んでいます。前編にもあるとおり私たちは職能のプロが集まってひとつの事業もしくはプロダクトを支えていくことになるわけですが、別の職能のプロに任せるべきことにまで手を伸ばしていないかは気を遣っています。判断を誤ると気持ちの良いチームワークが果たせません。

また開発者の担当するタスクがいわゆる「開発」だけではなく、ミーティングのアジェンダ作成やファシリテート、施策効果のざっくりした試算も行うようになった反面、開発タスクが薄くなりすぎていることも懸念のひとつです。私自身もコードを書かないスプリントが 2 回以上続いたら、ちょっと気が触れるでしょう。

先日発表されていたプロダクトマネジメントクライテリアですが、自分たちではチェック項目がまったく埋められず旅の遠さに愕然としているところです。

まとめ

前編とは違って後編は取り組みを雑多に列挙していくような形になりました。

12 月から取り組んで結果どうなっているのかについて触れていませんでしたが、プロダクトの成果としての KR としていた数値目標は徐々に増加傾向にあり、始める前よりはまずまずの納得度を得られているんじゃないかなといったところです。

これまで実践してきたモブプロといった組織学習の中で得られた成功体験は間違いなく効いていて、重要なのは積み重ねられたチームでの学習の厚みであり、チームでの学習こそが不確実性を減らしていく のだとあらためて実感させられています。

前編後編と少し技術から離れたことを書きました。納得あるプロダクト開発を考えたい開発者にとって、少しでも役に立てられれば幸いです。後続のポストはがっつり技術的な投稿を期待して今日はここまでとしましょう。

最後まで読んでいただきありがとうございます。