プロダクトづくりのコアを言語化した「正しいものを正しくつくる」
ちょうど2年前に読んだ本ですが、振り返る機会があったので読書メモを残しておこうと思います。
最初にタイトルを見た時は、あらゆる側面で不確実性が高いプロダクトづくりという営みにおいて"正しい"なんて本当にあるのか？、なんてちょっと捻くれた捉え方をしていたのですが、同僚から強く勧められので読んでみたら、まあひたすらに名著でした。
振り返ってみると、プロダクトづくりの仕事をし始めてから最初の数年は「どうやってうまく作るか」に集中していた気がします。でもそれ以前にもっと大事なのは「なぜ作るか」「これは正しいものなのか」（=顧客の課題を解決し経済的な価値を生むものなのか）であって、そのことを強く再認識させられたキッカケのひとつが本書でした。
個人的には
・プロダクトマネジメント - ビルドトラップを避け顧客に価値を届ける
・解像度を上げる
・エンジニアリング組織論への招待
と並んで、プロダクトづくりに携わる人にとって必読書だと思っています。
以下、本書から印象に残った点を抜粋・コメントしておきます。
現在の私たちが手がけるプロダクトづくりは、 誰かの頭の中に正解イメージがあってそれをうまく取り出してコードにしていくという開発ではない、ということだ（７）。誰の頭の中にも正解がない。プロダクトオーナーの頭の中にもない。ユーザーの頭の中にも直接的な正解があるわけではない。今まで解決できなかった問題、まだ誰も味わったことがない新しい体験、そういったものに対してプロダクトとして何があれば正解なのかなんて、誰にもわかるはずがない。つまり、いま私たちが作ろうとしているプロダクトとは、「どうあるべきか本当のところ誰にもわからないが、なんとかして形に仕立てていく」、そういう開発になる。
アジャイル開発を表現する言葉には、「インクリメンタル」 と「イテレーティブ」 というものがある。インクリメンタル、つまり「少しずつ」かたちづくっていく。それをイテレーティブ、つまり「反復的な活動によって」という表現だ。
つまりアジャイル開発とは、ユーザーにプロダクトを「価値があるモノなのか」「必要な機能は何なのか」「どういう形であれば使えるのか」試してもらいながら開発を進められる、というものだ。わざわざ試行錯誤を前提とした進め方をするのは、自分たちの作っているプロダクトが間違っている可能性があり、その修整を織り込むためにほかならない。
自分達がつくっているものは間違っている可能性がある、という認識が大事。
○不確実性に適応するための「正しく作る」あり方は、共通の軸「ミッション」の共通理解、余白の戦略、スプリント強度を高める戦術、全体への共通理解を統べる作戦。
○ミッションの共通理解を得るためのインセプションデッキづくり。
○余白の戦略とは、調整の余白、期間の余白、受け入れの余白からなる。余白でもって、不確実性を受け止める。
○スプリント強度を高める戦術とは、開発の確実性をスプリントの前で確保する行動。すなわち、背骨で駆動する開発と、プロダクトづくりの状況をクリーンに保つ５つの条件を実践する。
正しく作ろうとして失敗することは１度や２度ではない。むしろ、放置したままで大きな事故になる前に、 小さく失敗することを繰り返し、少しずつ良くなることを意識 したい。状態として、チームはスプリントごとに大小様々な失敗を犯すし、問題を抱えることになる。そうした状態を悲観的にではなく、むしろ常と捉える。
小さく失敗を続けて、強度を高める。
プロダクトオーナーは、プロダクトのビジョンを描く立ち位置に最も近い。ビジョン、つまり「プロダクトを通じて世の中にどのような変化をもたらすか」 を描く。
ビジョンの次に、ミッションの定義が必要だ。ミッションとは、「これが実現できなければ自分たちの存在意義が問われる」という使命にあたる。チームが自律的に動くためには、果たすべきミッションの形成と理解が必要だ。
ただただアウトプットし続けること、あるいは大量のアウトプットを生み出すことが、アウトカムにつながるわけではない。アウトカムにつなげるためのアウトプットとは何か？すなわち何を作ればよいのか？が問われることになる。 いくら開発のやり方を正しくしたところで、間違ったもの（ユーザーにとって価値のないもの） を作っている限りは、その意義は薄い。アウトカムを生み出す正しいものを見定めて作る必要がある。
正しく作ったとして、作っているものが間違っていたら全て水の泡。
開発チームのミッションを「正しく作ること」、プロダクトオーナーのミッションを「正しいものを探すこと」と分けていると、お互いに境界を越えられない。あくまでミッションは共通で、「プロダクトを通じて実現したいことを形にする」になる。そのために、開発チームもプロダクトオーナーも、それぞれの視座を個々の役割レベルからひとつ高く持ち、プロダクトの目的レベル（プロダクトを通じて何を実現しなければならないのか） で自分たちの活動を捉える必要がある。
プロダクトオーナーと開発チームの間の「ミッションの境界線」を形成してしまう２つの境界には、「作る」と「作らない」の境界、アウトプットとアウトカムの境界がある。お互いが越境し、チームとして効果的に動いていくためには、行動指針や意思決定のための共通の「基準」 が必要になる。基準がなければ、お互いが思いつくままに考え動いているだけで、ただ混沌が深まる一方となる。そうなれば、かえってアウトカムどころかアウトプットさえまともに上がらなくなってしまう。
わかる。とても大事。
プロダクトの検証を旅になぞらえると、それは探検に似ていると言えるだろう。向かいたい方向（ビジョン） はある。しかし、その過程で何が起きるのかすべてを事前に見通すことはできない。目的地（ゴール） までの明快な地図などない。だからこそ、入念な現在地点の確認（今どこまでわかっているのか）、次にどこまでいくか（次に何を把握しようとするのか）、そのための作戦を立てて、遂行できるようにする。そうでなければ検証活動は曖昧なものになり、時間ばかりが過ぎて何もわかったことが増えていない、ということが容易に起こるだろう。
情報は多ければ多いほど良いというものではない。 情報と知識は違う。情報とは事実であり、データに過ぎない。それが意味があると識別できてこそ有用な知識になる。獲得した情報の中から自分たちが必要な情報を識別し、取り出すのは、対象が多くなればなるほど当然困難になる。検証は、最小限の活動で学びが最大となることを指針としたい。
いくらやり方が正しく、かつそれを計画的に進めていたとしても、その検証活動で「何を学ぶつもりなのか」 がなければ、その活動自体の意義は乏しい。
自分たちは「何がわかっていないかが、わかっていない」 という可能性がある前提に立ってプロダクトづくりに臨みたい。この前提に立てば、常に今見えている以外の仮説はないのか、選択肢はないのか、というアンテナを立たせることができる。
「何がわかっていないか」「何を学びたいか」を明確にしないと、検証活動は意味をなさない。
ネガティブな結果、つまり「正しくないこと」の学びを積み重ねていき、そうした正しくないことを「除外」することで、結果的に正しさを残していく。これが、プロダクトづくりにおける仮説検証の戦略となる。すなわち、「正しくないものを作らない」 だ（図４）。
仮説検証では「正しくないものを作らない」戦略を取る。「正しくないもの」の理解から、プロダクトについての基準の輪郭を浮かび上がらせる。
「仮説」と一口に言っても複数の分類がある。その仮説が、 想定ユーザーの課題に関する仮説（課題仮説） を指しているのか、 どのようなソリューションが有効なのかというソリューション仮説 を指しているのかで大きく意味が異なる。
「正しいものを正しく作る」というと、前提として絶対的な正しさがあり、それを探し求めるようなイメージがあるだろう。だが、そのようなスタンスで探索したところで絶対的に正しいという証明はできないため、意思決定ができない状態に陥ってしまう。ゆえに、仮説検証型アジャイル開発では、「正しくないものを作らない」という戦略になると第５章で述べた。検証を行うと、「対象ではない」「（仮説と） 合致しない」という情報が獲得できていく。そうした、正しくないと判断できる情報を蓄積しつつ、その反面から確からしいと考えられる仮説を立てる。この両軸で、プロダクトづくりの方向性を見定めていく。
探索の中で「正しくないもの」を除外していき、徐々に「"正しそう"なもの」を見つけていくこと。
何が正しいのかほとんどわかっていない状況で作り込みをするのはムダである。精密なプロダクトではなくて、検証の回数をできるだけ重ねるようにする。最も早い検証とは、作らないことだ。
探索が「ユーザーに体験してもらわないとこれ以上の検証はできない（検証してもわかることが増えない）」 という壁に当たり、なおかつ「その検証のためにはソフトウェアを作る必要がある」 という判断に達したとき、初めてＭＶＰの開発を行うことになる。
うんうん。
プロダクトのあり方として方向性に迷うならば、事業の目的へと立ち返る。例えば、捉えた課題仮説をより特定し、深掘りしていったことで、確かにユーザーに必要とされるプロダクトの構想は描けたが、課題のサイズがそれほど大きくない、つまり市場規模が想定より小さいということがわかったとする。そのまま課題解決まで進めていくのか、それとも立ち止まるべきなのか？ こうした時に、事業の目的に立ち返り、このプロダクトを通じて何を実現したかったのかを問い直すようにしよう。事業の狙いによって、目先の課題解決を追いかけていくのか、プロダクトの構想をやり直すのか、判断するわけだ。プロダクトレベルでは「正しいものを見出した」と言えるかもしれない。だが、事業の観点からは、そんな規模のビジネスを構想しているわけではない、といった判断もありえる。
世の中の要請に応えるために組織があり、組織はそのために事業を立ち上げ、事業の中核にはプロダクトがあり、プロダクトを形づくっていくためにプロジェクトを立ち上げる、という入れ子が成り立つ。この縦構造を行き来して（９）、適宜意思決定の基準を手に入れるのだ。
視座をプロダクトから事業の観点へとひとつ上げてみる。このプロダクトはいったいどういう事業の狙いの下で構想してきたのか。プロダクトは、事業からするとあくまでその狙いを実現する手段でしかない。つまり、手段は変えようがある。事業の狙いから捉え直すことで、全く異なる課題仮説、状況仮説を描くことが可能だ。
方向性が定まらない場合、「プロダクト」から「事業」に視座を切り替えて考えることで意思決定する。