「正しいものを正しくつくる」プロダクト開発
まず市谷氏は、プロダクト開発とは何かを明確にするため、ソフトウェア開発との違いについて着目した。
「ソフトウェア開発は期待通りに動作することが大事だが、プロダクト開発では、ユーザーの⽬的を果たし価値をもたらすことが重要」だと市谷氏。ソフトウェア開発では要件や仕様といった「正解」が決まっているという前提を置こうとするのに対し、プロダクト開発はそもそも「ユーザーにとっての価値」とは何かが分からない。プロトタイプによる仮説検証や、MVP（実用最小限の製品）によって価値を確かめる必要がある。その際、スクラムで正しくつくるべきだが「開発チームとプロダクトオーナーの間での分断が起きやすい」という。
「開発チームの方はちゃんとスクラムをやっているつもりが、プロダクトオーナーは何をやっているか分からず『えいや』でプロダクトバックログをつくっていることがいまだにある」（市谷氏）
こうして出来上がるプロダクトは、ユーザーに役立つものではなくなってしまう。「間違ったものを正しくつくる」ことになってしまうと市谷氏は指摘する。
では、「正しいものを正しくつくる」とはどういうことか。市谷氏は、「プロダクトを『つくる』、それを『ユーザーに届ける』だけではまだ足りない。『アウトカム』が生み出せているかが重要」だと語る。
「ユーザーがプロダクトを利用することで目的を果たし、何らかの成果を手にすること。ここまで行き着くことがプロダクトづくりであると言えます」（市谷氏）
アウトカム（成果）とは何か？
アウトカムを「収益」だと捉える人もいるだろう。しかし市谷氏は収益は、プロダクトづくりを継続・発展させるために必要な「動力源」であり「結果」であるとの考えを述べた。「ご飯を食べるから動き、動きが取れてまたご飯をつくれる」というサイクルと同様だ。
ゆえに「収益だけを目標に置いてしまうと、不都合が起きる」。まるでバックミラーだけを見て運転するように動きが遅くなり、肝心の「アウトカム」の行方が不明瞭になるという。
そこで市谷氏は「前を見よう」というメッセージを発信。混乱しがちなアウトカム、つまり成果とは何かを捉えなおすことを推奨した。
では、プロダクト開発における成果とは何だろうか。市谷氏は3つの外せない要素を示した。
1つめは「ユーザー」である。ユーザーに価値や意味がもたらされている状態が1つの成果と言える。これは冒頭のソフトウェア開発との違いでも触れたとおりである。
ユーザーだけを見ればよいかというと、そうではない。ユーザーへの価値提供は、プロダクトを通して行う。そしてその価値は持続可能であるべきだ。「今月はサービスが動いているが、来月は分かりません」という訳にはいかない。そのため「プロダクトをつくるチームはもちろん、プロダクト自体も健全であるべき」と市谷氏は言う。
「ユーザー」「チーム」「プロダクト」の3つの健全性を保つことが、成果につながるのだ。
ここで「チームやプロダクトは成果ではなく手段なのではないか」という疑問に対して市谷氏は、以下のように補足した。
「プロダクト的な思考から言うと、この3つがそろわないとどうしようもない。チームが疲弊しきってはユーザーのうれしさを考えられません。プロダクトが負債で動かせない状態では、価値提供を約束し続けられるでしょうか」（市谷氏）
探索型プロダクト開発へ
「ユーザー」「チーム」「プロダクト」の健全性を維持・向上するにあたって難しいのが、3つを取り巻く環境に変化が伴うことだ。状況の変化に対応できるようなプロダクトづくりが求められる。はるか昔に分かったことを頼りに、ユーザーのニーズやチームの強みを判断しては正しいプロダクトは生まれない。
そこで市谷氏は「プロダクト探索に出かけましょう」と呼びかけた。
「分かっていることだけでプロダクトをつくり続けていては、ジリ貧になる。現時点では分かっていないことに踏み込んで、情報・知識を得なければいけない」（市谷氏）
つまり、プロダクト探索とは新たな学びを得る活動であり、その方法を身につけておくことが重要だ。
市谷氏は、「プロダクト探索の歩き方」のイメージを、下図に示した。
まず重要なのは「成果とは何かに向き合うこと」である（図左側）。市谷氏は「成果＝先述の3つだと捉えなくてもいい」という。収益との混同を避けつつ、「とにかくチームで合わせてください」と強調する。その成果に対して目標と評価指標を決める手法としては、OKRがフィットする。
続いて、成果をあげるためには「仮説を立てる」必要がある（図中央）。ユーザーにとっての課題や価値についての仮説はもちろん、チームやプロダクトに対しても仮説が必要だ。仮説立案には、調査によって情報を増やすことが第一歩になる。ユーザーを理解するためのアンケート・インタビュー調査や、チームを理解するためのふりかえり、プロダクトを把握するための計測といったリサーチが大事になる。その際、ユーザーに関しては仮説キャンバスを立てたり、プロダクトに関してはユーザーストーリーマッピングをやったりと、手法を使い分けることを推奨した。
そして、こうした探索活動はバックログに積んで、スクラム開発のサイクルの運営の中で扱えるようにしていくことが大事だ（図右側）。「OKR→仮説→バックログの流れをつくり、検査適応の運営をしていきましょう」と市谷氏。探索で分かったことはスプリント単位で把握し、探索活動自体もレトロスペクティブの対象とするのがよい。
このように「プロダクト探索においてやるべきこと」を見ていくと、決めごとが多く大変な準備が必要だと感じるかもしれない。しかしそれは「最適化の罠」だと市谷氏は忠告する。
「準備は必要だが、気づいたらずっと準備しているといった『最適化の罠』にはまらないようにしたい。まずは探索バックログの最初の1個を積むところから始めましょう」（市谷氏）
デブサミで得たヒントで「自分が」現場を変えていく
本セッションのまとめとして、市谷氏は「新しい成果を上げていくためには新しい武器（知識）が必要」と述べた。今までのナレッジだけでプロダクト開発に向き合うと、誤った判断を招く可能性がある。だからこそ、プロダクト探索を通して、学び続けることが重要なのだ。
その際、収益を目的と混同せず「ユーザー」「チーム」「プロダクト」に焦点を当てること、成果とは何かを定義しなおすことが重要であることを、今一度強調した。
「このようにそもそもどの方向に向かっていくのか決め直すことを『むきなおり』と呼びます。何のためにこのプロダクトづくりをやっているのか。それに合わせて成果も方向性も変え、忘れないように常に見直しをしましょう」（市谷氏）
最後に市谷氏は、久々のオフライン開催となったDevelopers Summit（デブサミ）に寄せて、開発者たちにメッセージを送った。
「デブサミは開催のたびに現場や組織を変えてきましたが、この場が世の中を変えるのではありません。皆さんがデブサミでヒントを得て、各々の現場に帰り、各々なりにいい感じに変えてきた。各自が頑張るんです。なので、誰かに成果を決めてもらう世界ではありません。今日の話のとおり、自分たちは何のために何を成果としてやっていくのかを考えてみてはどうでしょうか」（市谷氏）
