「アジャイルなプロダクトづくり」をよんで
アジャイルなプロダクトづくり 価値探索型のプロダクト開発のはじめかた
を読んだので感想を書いてみる。
「なんちゃってスクラム」とか、「うちのアジャイルはミニウォーターフォールじゃないか」とか、そういった悩みを抱えている人にパラダイムシフトを起こすような一冊じゃないかと思う。
この本は、ストーリー＋解説型で進んでいく。
さらに主人公が既存プロダクトを扱う部分と、新規プロダクトを扱う部分との２つのストーリーがある。
この２つのストーリーに分けて感想を書いてみようと思う。
既存プロダクトのストーリーを読んで
何を達成したいのか
いま積み上げられているPBIは、いまやろうとしていることは、いつの情報に基づいているのか。どんな根拠があり、何を達成しようとしているのか。
プロダクト開発ではよくあることではないかと思う。
チケットは「要望対応」とカテゴライズされ、「●●の部分を赤字にする」とか、「●●の項目を追加する」とか、そんなPBIが大量に積み上げられ、消化されていく光景を私も目にしたことがある。（当事者でもある。汗）
ここで「探索」をしよう、というのがこの本の主張である。
チームの中で考えていることは「仮説」であり、これを検証することで学びを得て、本当に成し遂げたいことへのステップがようやく考えられる、といったイメージである。
形態仮説（顧客の解像度をあげる）
課題仮説（解決する価値のある課題か。バーニングニーズはどこか。）
機能仮説（このソリューションはFitするか）
この３つの仮説を反復する。
CPF〜PMFの考え方とも似ているように感じる。
ここをすっ飛ばして機能のPBIを積み上げていっていないか。
新規プロダクトでは考えられることも多い気がするが、既存プロダクトの1PBI単位でこれを考えられていることは少ないような気がする。
こんなとき、サービスブループリントとか、カスタマージャーニーマップとか、そういったものがメンテナンスされていると形態仮説を立てやすいと思う。
チームが目指すものはなにか
KPIだけをゴールとしていないか、という問いである。
私は、KGIがあり、KPIがあり、チームはKPIを目指していくようなイメージを持っていた。
ただ、これだけでは「何を目指しているのか」を見失ってしまう。
KSF（Key Success Factor）重要成功要因を定め、そこからKPIに分解していくという考え方だ。
このプロダクトで成し遂げたいことは何か、目指すものはそこに紐づいていなくちゃいけない。
市谷さんがよく話している「バックミラーだけを見て運転するようなもの」というやつだ。
現状の把握と、向かう先の定義
目指す場所に向かっていくにあたり、現状を把握していなければ、目標へのGapを埋める算段がたてられない。
ユーザー、チーム、プロダクトの3軸の視点で、FromとToを捉える必要がある。
私としては、まずは「ユーザー」に目を向けたいと思った。
プロダクトの４階層の「Why」でもあり、「誰を」「どんな状態に」したいのかという強い意志と解像度が必要だと思う。
それを明確にすることで、「その状態を実現するためには、チームはどういう状態であり、プロダクトはどうなっているべきなのか」を考えられると思った。
スクラムを実践する上でのPBIの単位
スクラムを実践していると、スプリントに収まる範囲でPBIに取り組む。
そうすると、ユーザーに価値をもたらずはずのPBIが1スプリントに収まるように細分化され、断片化した結果、ユーザーに価値が提供されないスプリントが爆誕する。
この部分では、現実的に運用をするうえでどう進めるのか思い悩む。
どれだけ最小のユーザー価値を定義しても、その価値やチームの状態によっては、1スプリントで達成できないこともあるのではないかと思う。
そこで、個人的には1スプリントで必ずデプロイする必要はないのではないかと考えている。
仮説を検証し学びを得るために短期間でリリースするのであって、既にユーザー価値に対する確度の高いPBIや、その時のチームにとっての重要仮説なのであれば、複数スプリントに渡っても良いのではないかという考えだ。（十分に小さい単位であることは前提として。）
ふりかえりとむきなおり
ふりかえりはよく実践されているが、むきなおりを定期的に実践しているチームは少ないのではないかと思う。
ふりかえりでは、スプリントで起こったことに対して振り返り、次につなげる。
一方で「このまま進んで、本当に成し遂げたいことが達成できるのか」あるいは「”成し遂げたいこと”に再定義する余地はないか」という問いに定期的に答えられているか。
むきなおりは、PdMとしてロードマップを日々考えていくうえでも最重要であると思う。
インセプションデッキは定期的に見直されているか、日々の仮説検証で得られた「学び」は、私たちが向かう先とその道筋に反映できているのか。
こういうときにリサーチスキルやリサーチ観点があると役に立つように思う。
新規プロダクトのストーリーを読んで
コトの検証をしよう
MVPの策定に伴い、プロトタイプで検証するのはよくある光景である。
ただ、ここにモノだけでなくコトの検証を盛り込むことがポイントであるという。
私はOMOを思い出した。いまやソフトウェアだけで人に感動を与えたり、バーニングな課題を解決することは難しいと感じている。
画面の中で動くモノだけではなく、オフラインもフル活用して検証に挑むことで、深いインサイトが得られるのだと思う。
プロダクトレビューをしよう
スクラムを実践していれば、スプリントレビューを行う。
スプリントレビューでは主にスプリントでつくられたインクリメントに対してのフィードバックを得る。
プロダクトレビューは、スプリントレビューとは違い、プロダクト全体の流れをレビューするものである。
これも上記で記載した「コトの検証」と似た考え方で、”部分的”に学びを得るのではなく、全体の流れに対する学びを得るということだと思う。
ここの検証を怠ると、そもそもの画面設計やドメインモデリングが最適でないままローンチしてしまうことも考えられる。
そして、その画面設計やドメインモデリングの根本部分は、ローンチ後に修正するとなると膨大な工数がかかる。（体験談…）
まとめ
ストーリーが全体的にとてもリアルで実践的だった。
アジャイルとは、単に「リリースがはやい」だけではないのだと、そんなメッセージを感じた。
プロダクトをつくっていると、目先の要望やタスクを達成してやった気になってしまうことがある。
顧客の要望をすぐに叶えれば、喜ばれるしモチベーションにもつながる。
しかし、その根には技術的負債、デザイン負債が増え、取り戻そうと思った時には取り返しのつかないことになっていたりもする、ような気がする。
ユーザー、チーム、プロダクトの3軸を健全に保ち、何を目指しているのかに常にチーム全体で向き合いたいと思う。