こんにちは。ExaWizards という会社でPM（プロダクトマネージャー）をしている宮田(twitterアカウントは@miyattiです)です。エクサウィザーズ に入社してもうすぐで２年になります。いろいろやってきましたけど、最近はずっと「CareWiz 話すと記録」というプロダクトのゼロイチのPMをやっています。

今回はエクサウィザーズ でやっているプロダクト開発のプロセスの一例を紹介させていただきます。

エクサウィザーズ 自体なんの会社なの？コンサルの会社でしょ？と言われることもあったりしますが、実際は社会課題解決xAIなプロダクトを複数立ち上げていて、割と泥臭くいくつかのチームにわかれてそれぞれにPOやPdMががんばってプロダクトの企画開発をやっています。

なので、その中心となるPMによってやり方は千差万別というのが正直なところです。今回は私が担当する「CareWiz 話すと記録」の立ち上げ期（ゼロイチ）におけるPM（企画開発）プロセスをご紹介してみたいと思います。

「CareWiz 話すと記録」のご紹介

まずプロダクトについて簡単にご紹介。軽く前述したように弊社エクサウィザーズ のミッションは「AIを用いた社会課題解決を通じて幸せな社会を実現する」というもので、そのためにいくつかAIプロダクトを複数の社会課題解決のために同時進行で開発しています。

この話すと記録もその一つで、人手不足、間接業務の増加が問題となってる介護業界で少しでも楽に仕事をしていただこうと、今まで紙に書いたりPCに座って入力していた介護記録を、実際に介助しながらでも手ぶらで「ながら入力」ができるように音声入力で記録できるiPhoneアプリをつくっています。現在はすでに販売開始しており、いくつかの施設でご利用いただき、いろいろご意見をいただきながらも便利に使っていただいている状況です。

詳細はサイトをみていただくとして、まぁこういったB2Bな業務支援ツールをこのチームは作っているんだなという認識だけもっていただければ十分です。ただポイントは、B2Bといってもパソコンデスクの前に座って使うツールを作っているのではなく、非常にアグレッシブに動く現場で、しかも今までITツールをあまり使ってくることがなかったお客様もご利用になるアプリになるということ。

このため、UI/UXへのこだわり、このサービスがそもそも受け入れられるのだろうか？という不確実性の中で企画がスタートしているというのがポイントです。

ニーズが確実にあるか不透明、不確実。そんな状況を打破するために、プロダクトの成功確度をあげるために以下のようなPMプロセスをおこなってきました。

PMプロセスの全体像

ではここから実際にうちのチームでやった＆これからやっていくPMプロセスをご説明します。まず全体像を図解したものが下の図になります。が、これをいきなり細かく説明しても意味不明なので、いくつか段階に分けて説明できればとおもいます。

この企画開発プロセスを6つのレイヤーに分解して順番に紹介していきます。レイヤ−１が一番基本となる考え方で、下のレイヤーになるにしたがって長期的な時間軸のプロセスになっていく形になります。

まぁ何のこっちゃなところもあると思うので、とりあえず上の図はほっておいて次の説明をよみはじめていただければありがたいです。

レイヤー１　段階的 仮説検証プロセス

プロダクト開発の基本はなんでしょう？とりあえずリリースすること？違います。お金と時間をかけていきなりプロダクトを作る前に、きちんとコスパよく仮説検証プロセスを行うことです。

それをEric Ries氏は著書「リーンスタートアップ」の中で構築-計測-学習のフィードバックループを提唱しました。この最小のフレームワークは、きわめてわかりやすく様々な場所で引用されることが多いので、ご存知の方も多いでしょう。

うちのチームでも基本はこれです。作るだけで終わりがちな仕事を、お金をかけて本気のものを作る前に、仮説を立てて無駄なものを作らないようにすることを忘れない。そして作った後にそれがどんな結果になったか、きちんと良いプロダクトになりそうなのかを測定し成功確度を推測するのを忘れない。

例えばそもそもお客様は業務（介護記録）をすごく困っていると感じているのだろうか？そのためにこんな便利なアプリがあったらどうでしょう？というデザインモックをつくり実際に介護施設の方に見せる。そうするとただ困ってますか？と聞くよりリアルな感想が聞けたりします。そんな仮説検証をずっと繰り返してきています。

認識しなければいけないのは、プロダクトがほっといても売れるPMFになる前の状態は、すべての行動は仮説を検証するためにやるもので、これですぐにお金儲けしようとしすぎないことを、この仮説検証プロセスが基本であることを認識することで、忘れないようにしています。

レイヤー２　段階的 解像度向上プロセス

レイヤー１の仮説検証プロセスをずっとまわしつづけ、いい感じのプロダクトがみえてくるようになるまでやる、といえばそれがPMプロセスであるといってもいいのですし、いろいろ長期的に複雑な戦略を考えすぎてわけわからなくなって、自分たちがプロダクトを開発しているという実感をもてずに、計画に従うだけの仕事をしている感じになるぐらいならレイヤー１だけくりかえしてたほうがいいと思います。

しかし仮説検証自体もただがむしゃらに思いついた仮説をかたっぱしからやればいいというわけでもないです。そのために役立つフレームワークとしてこれ以降のレイヤーの考え方がでてきます。まずはレイヤー２ 仮説検証の解像度向上プロセスをご説明します。

仮説検証はただがむしゃらにやればいいということではなく、効率的にやる必要があります。そのためにはまず全体像をつかむような抽象度の高い仮説検証からだんだんと部分的な、具体的な検証をすることで不確実性を低減するのがいいと考えています。

その実践として「センスアンドレスポンド」です。 別に小難しい話ではなく、ようはお客様・マーケットを感じて知って（Sense）全体像を理解し、それをうけて確実にお客様にたいして何か役立つだろうと思ったものを具体的に作ってお客様にそれを見せる・反応して（Respond)お客様がどういう風に変化するかを確認することで、不確実な検証をさけて確実な仮説検証をしていきましょうということです。

このSense&Respondというフレームワーク、考え方は数十年前から制御理論で用いられた概念らしいのですが、これをPMの考え方として紹介したのはおそらくLeanUXの著者としても有名なJeff Gothelfと Josh Seidenの「SENSE & RESPOND」のようです。

ポイントはSenseは全体が対象、Respondは個別が対象というところ。お客様・市場はこういうことかな？という全体に対する仮説検証をおこない、理解してものをつくるときは反応をみるために小さく個別に仮説検証をするという段階をふむことで、無駄なく効率的に検証できて仮説の確実性を徐々に高めていきます。

自分たちの具体例をあげると、Senseとして介護施設のお客様に対して個別インタビュー調査を行なったり、マーケットデータを集めて(Learn)、仮説としてのカスタマージャーニーマップやペルソナを作り全体像はこうなんではないかと推測します。さらにそこから具体的な機能アイディアをたくさんだしリスト化(Build)し、チーム内でどのアイディアがいけてるか議論します（Measure)

その後Respondとして最も優先度の高いアイディア「記録を簡単に共有できる画面」の詳細仕様を議論し（Learn)　具体的にラフデザインのプロトタイプにし（Build）、お客様に見せて受け入れられるかの個別に反応をみます(Measure)。

いきなりチーム内で状況を把握したり優先順位をつけずに、モックを思いつきで作るのではなく、また調査するだけして満足してお客様の反応を確認したりしないとかはよくないです。

どの段階でもこのセンスアンドレスポンドのリズムは保つのが重要と考えてます。

レイヤー３　段階的 アウトプットプロセス

次に大事なこととして、「ディスカバリー＆デリバリー」があります。Sense&Respondを繰り返すことによって全体感をみながら少しずつお客様の解像度を上げる形で仮説検証はできていきますが、それでも一番最初の仮説検証はきちんと全体を感知しながらやっても間違う検証をやってしまいがちです。それはしょうがない。サイクルは何度も回して少しずつ精度を高めるもの。このアプリでも最初は全然違う方向性の仮説をたてていた時期もありました（内容は内緒）。

よくやりがちなのはこの怪しい仮説をいきなり実装してしまって、多くの人に使ってもらう形で検証をしてしまうこと。そんな怪しい仮説をいきなりリリースして多くの人に使ってもらうのは、仮説検証が目的とはいえ間違っている可能性が高いものを頑張って作ることになっちゃいますし、何かトラブルがおきたときのサポートをすることを考えるとコスパが悪いです。

なので、あってるかわからない段階でのSense&Respondではいきなりちゃんとしたものをつくるのではなく、デザインだけのプロトタイプなどをつくって限られた人にその感想をきくなどして仮説を検証します。この段階をDiscoveryといったりします。

そしてある程度反応がよいなとわかれば、いよいよきちんと開発して、多くの人に使ってもらうことで検証します。この段階をDeliveryといっています。

このプロセスの考え方は、Jeff Gothelf氏の「Lean UX」などで紹介されたデュアルトラックアジャイルの考え方に基づいています。（デュアルトラックアジャイルについては後述）

実例をあげると、このアプリも最初はデザインモックの状態でAIなどの実装もしない状態でお客様に見せて（ただし実際にスマホの画面としてみせることで臨場感をあげる）実際に使うイメージをもってもらうところからはじめ、その後アプリの安定性は度外視したけどAIは動いているワーキングプロトタイプを使ってもらい、その後全部ゼロから安定的なプロダクトをデリバリーとして作るという流れをとっています。

こうやって、ゆるめにしかしひとつひとつ質の高い検証をし確実性の高いプロダクトを探し（Discovery) これはあってそうだなと見つかったらさらに確度を高めるために多くの人に提供（Delivery）して数で検証する。

この２つのトラックを行なうことで着実に仮説の確実性を高めていけます。

Sense&Respondとの違いについて

Sense -> Respondも Discovery-> Deliveryと同じ感じがする、どちらも不確実性を下げていく流れだよね？というの意味では確かに同じです。ただSense&RespondはSenseの段階ではあくまで計画やアイディアのリストといったまだお客様には見せない中間生成物を作る過程で、Respondまでいってはじめてお客様に見せるものができます。それに対しDiscoveryもDeliveryもそれぞれお客様に見せるものは作るのが前提で、そのクオリティがLo-FiかHi-Fiかの違いがあると言った感じです。ただ、DiscoveryフェーズではSenseの工程に重きがおかれがち、DeliveryフェーズではRespondの工程に重きが置かれがちといった相関関係はあるきがします。

ダブルダイヤモンドとの類似性

ダブルダイヤモンドとは2005年に英国デザイン協議会で初めて導入された、2つのダイヤモンドを描くように発散と収束を行う有名な手法です。（こちらの記事など参照）

今回のレイヤー２と３の図をかくにあたりこのダブルダイヤモンドを意識してまとめています。ただ、細かいところで用語をあえて違う使い方をしていたりします。ダブルダイヤモンドのDiscoverは問題の洗い出しという形で使われる言葉ですが、レイヤー３ででてくるDiscoveryは問題だけでなくざっくりしたソリューションまで見つける段階としています。ダブルダイヤモンドでのDiscoveryはこのレイヤー２のSenseに近い（そしてDeliveryはRespondに近い）と思っています。

デュアルトラックアジャイルについて

このDiscovery->Deliveryはプロダクトの一番最初の立ち上げ段階においてはリニアに順番にやっていくのがいいと考えていて、そうやってきてますが、ある程度プロダクトの形がみえてきて、追加機能をどんどん実装していくフェーズになると、並行してやっていきます。そうなると、いわゆる世間一般で言われるデュアルトラックアジャイルというものに近くなっていると思っています

Discoveryで日々アイディアレベルの仮説検証を行いこれはDeliveryレベルの仮説検証にしていいものをリスト（バックログ）化しておき、Deliveryは常にそのリスト（バックログ）をみてそのから開発をともなう仮説検証をするアイディアをピックアップする。

こういう形でやると、同時進行でそれぞれのプロセスをすすめることが可能で効率よく仮説検証をすすめることができます。今現在のチームの運用はこちらになってます。

レイヤー４　段階的 PMF達成プロセス

さらに長期的な視点でのPMプロセスを紹介します。それがスタートアップフィットジャーニーです。

確実性を高めながら仮説検証プロセスを回す、これをまたやりつづけていればプロダクト開発としては大丈夫か?といわれるとまだ不安は残ります。それは何がゴールなのかよくわからなくなったりするからです。いつになったらこのプロダクトは「売れる」ようになるの？ある日突然なのか？

そこで焦っていきなり売れる検証をしはじめるのはよくありません。どうしたら売れるようになるのか？というのは一番難易度が高い、不確実性が最も高いゴールです。いきなりそこにいくのではなく、確実に達成できそうな、そしてもっとも先に確認しておかなければいけない目標から順番にゴールにしていくのが効率がいいです。

そのようなゴールを分割してマイルストーンにした長期的なロードマップのようなものをチームでもつことにより、自分たちの長期的な道のりでの立ち位置を確認するようにしています。

とはいえ、これはいわゆる機能開発ロードマップや中期計画のようにいつどんな機能を開発するのかといった具体的なガントチャートのようなものではありません。

スタートアップ・フィット・ジャーニーとよばれる、プロダクトの登り方のおおまかなマイルストーンを設定したものです。

このフレームワーク自体は、著名実業家であり投資家であるMarc Andreessenがブログで言及したことが始まりらしいですが、細かく進化してきていてこのスタートアップフィットジャーニーという言葉とともに直接参照させてもらってるのがPM論などで著名な馬田氏のこの記事によります。

このロードマップではゴールをPMFとします。PMF（Product/Market Fit）とは、プロダクトがマーケットにフィットした状態のことを指し、ここに到ればプロダクトはほっておいても崖から岩がころがっていくかのように勝手に広がって（売れて）いく状態になります。これ以降はこれ以降でいろいろと別の問題が待ち受けているのですが、いったんプロダクトのゼロイチとしてのゴールはここを目指すことと言えます。

ここに至るまでに３つのマイルストーンをおいているものがこのジャーニーになります。Phase1としてはCPF(Customer/Problem Fit)を目指す段階。想定している課題がお客様の中に存在しているかをメインの仮説検証のテーマにおく段階。

それが正しいとわかったら、今度はPhase2としてその課題に対するソリューション案が妥当かどうかを検証するPSF(Problem/Solution Fit)を目指す段階。

そしてそれもある程度正しいとなったら、こんどはそのラフに作ってあるソリューションを完成度を高めてプロダクトに仕立てられるか検証するSPF（Solution/Product Fit）を目指す段階。

そして最後にそのプロダクトがほっておいても勝手に売れていくような市場が見つかり、売れる仕組みを構築できているPMF（Product/Market Fit)を目指す段階。

どのフェーズでも、レイヤー３までの仮説検証サイクルをまわすことにはかわらないのですが、「どんな仮説」を検証していくのがスムーズに効率よく不確実性を下げることができるか、ということを理解できるプロセスの考え方になります。

たとえばよくあるのは、このアプリがお客様にうけいれられるか検証しよう！といきなり始まるプロジェクト。そのまえに、そもそもこちらが想定しているお客様の悩みが本当に存在しているのか？それを確認するフェーズ（CPF）がまず必要ですよね、とか、プロダクトがいけてる状態かわからないけどとりあえず営業かけまくって売れる方法を考えようとしはじめるとか。

そういった状況を防ぐとともに、チームとしてあとどういう段階をへればゼロイチは完成するのか？といったこと長期的な観点で今いる位置を確認し、安心する物としても使います。

「話すと記録」では自分たちは今まさにPSFを検証している段階と認識しており、そろそろそれも見え始めたのでSPFに向かっていくか、などを議論しているところです。

また、この図はループの矢印もつけています。CPFからPMFまでの流れは通常一方向であるといえます。しかしこのPMFまでのステップは１プロダクトにつき１度とは限らないと思っています。これは次のレイヤーで説明したいと思います。

レイヤー５　段階的 マーケット拡大プロセス

イノベーター理論というものを聞いたことありますか？ 消費者の新商品購入に対する態度を分類したもので、購入の早い順からイノベータ、アーリー・アドプター(オピニオンリーダー)、アーリー・マジョリティ、レイト・マジョリティ、ラガードにわけられるというものです。

レイヤー４でCPFからPMFまで行っていくプロセスを紹介しましたが、これはこの分類ごとに行っていくものだと考えていて、そのためPMFは一つのプロダクトで顧客タイプごとに繰り返す必要があるケースが多い。

最初はイノベーターに対してPMFまでがんばります。が、それはあくでもイノベーターに対するPMFで、そのまま他の層にもそのまま売れていく受け入れられるとは限りません。

話すと記録でも、まずは感度の高いスタッフのみなさま、もしくは大きい課題をかかえている皆様に対して受け入れられるアプリを開発していってPMFを狙って行ってます。が、おそらく今のままの機能だけでは、まだ昔ながらのやり方でいいと思っている皆様にそのまま受け入れられる可能性は低いと考えていて、別の機能を検討していかなければと考えていたりします。

ただ、とはいえ、CPFとかは1回だけにして、PSFも何回もやるべきではないとは思っています。層がかわるたびにCPFつまり課題が存在しているか？という段階から調べ直しているとあまりにも効率が悪いプロダクト開発になります。どの層にも共通して存在する課題の確認を初期におこなっていれば、そのあとの層でのPMFを狙っていく段階で最初のCPFからやり直す必要はない場合が多いと思います。（もし毎回CPFから始めなければいけないのだとすると、もはやそれはプロダクトではなく、受託開発や、個別のプロダクト群といったものになるきがします。）

というところで、感度が高い人から低い人まで、CPFからPMFの流れを繰り返し、市場全部を獲得していくというプロセスがこのレイヤーです。

レイヤー６　段階的 VISION達成プロセス

この最後のレイヤー６が紹介してきたプロセスのなかでは最も長期的な視点をもつものになります。

このフレームワークはスタートアップフィットジャーニーでもご紹介させていただいた馬田氏の著書「未来を実装する」やMarc J Epstein氏の「社会的インパクトとは何か」また玉村雅敏氏編著の「社会イノベーションの科学」など複数の社会イノベーションを論じた本に紹介された考え方になります。

このプロセスのフレームワークを認識する最も大事な意味は「私たちのゴールは完璧なプロダクトを出す（Outputs)ことではない。ユーザーに行動変化（Outcomes)をさせ、最終的に世界を変えること(Impact)でチームが持っているVISIONに近づくことだ。」ということを認識することです。

特にエクサウィザーズは「社会課題解決を通じて幸せな社会を実現すること」をミッションとしている会社です。プロダクト開発によって最終的に本当に幸せな社会をつくるVisionを常に夢物語ではなく現実的なゴールとして意識することが大事と考えています。

そしてそこからロードマップとして逆算して、どういう風にひとりひとりのユーザーを行動変化させたらいいのか、そのためになにを作ればいいのか、そのためにどんなチームを作ればいいのかを考えロードマップ（戦略）を立てます。

Outcomesには短期と中期があります。また、ImpactはOutcomesの最終と考えてもいいと思います。短期は実際に行動変化する前段階の先行指標で、このアウトプットで自分の課題が解決するのかもしれないと予期するようになったかなどを確認します。中期は実際に行動変化が起きて個人単位でなんらかの効果がでたかを客観的に確認。そして最終OutcomesとしてのImpactでは会社そして社会に金銭的もしくは社会的な効果をもたらしたかどうかを確認します。

どこまでを目標にするかはレイヤー４で示したスタートアップフィットジャーニーの段階やレイヤー５のイノベーター理論によるどこの属性を狙う段階かによって変わります。イノベーター層でのCPFやPSFの段階では実際のImpactをだすところまでを目標にするべきではなく、まずはユーザーの認識が変わりそうかといったところを現実的な目標設定にするのがいいです。PMFを達成するぞという段階ではビジネスインパクトをどう達成するかを目標にし、さらにイノベーターだけでなくアーリーアダプター、そしてさらにラガードまで狙い、全ての市場に対してプロダクトを提供する段階において、今度は社会全体を変革し、VISIONを達成することを目指すようになります。

ただ、CPFやPSFなど初期の段階から世の中をどういう方向に変化させたいのかというVisionをチームで持つのはだいじです。それによってImpactが何かを思い描きそこから逆算でOutcomesやOutputsの目標をたてることができるからです。

このVisionはチームの活動がはじまる前に、このプロダクトを作りたいと思っている人がすでにもっているものです。しかし実際はそこでとまるものではなく、日々のSense&Respondの仮説検証のなかで、少しずつ具体的なイメージになっていくものです。そしてその変化していくVisionをもとに、アイディア自体もかわりますし、アイディアの優先順位付、開発タスクの優先順位も変化させます。

話すと記録でも初期にチームでVisionの認識のすりあわせを行いました。うちのチームにはずっと介護畑で仕事をされてきたドメインスペシャリストがお二人いるのですが、その方を中心に5年後10年後、介護業界をどういう方向にしていきたいのか?という話し合いをし、そこに向かうには最初の一歩はどうすればいいか?というのを決めていきました。

Outputs に関する目標は実は一番不確実性は低いので、短期的な最初に達成できる中間目標としてたてることができます。要はリリースを安全に行うことです。もちろんこれ自体は不確実性低いなんて簡単にいうことができないくらい難しいものですが、このあとにつながるOutcomeやImpactはさらに難易度が高い目標なので比較すると不確実性が低いといえます。Outputをきちんとだしたところでユーザーが行動変化してくれるとは限らないですし、さらにそのあと社会にImpactを与えるかどうかはもっとわかりません。なので段階的にOutput,Outcome,Impactと目標をたてるのがいいと思います。

注意するべきなのは、他のレイヤーでもそうですが、決してこれは確定的な長期計画というわけではありません。日々の活動でどんどん中身は変化していくものですし、変化していくべきと考えています。

繰り返しになりますが、固定した計画を立てることが重要なのではなく、チームは自分たちは長期的にはただものづくりをするだけでなく、世の中をかえるためにやっているのだということを認識することが大事です。

また、短期的な指標としてOKRを設定するのがとても大事です。実際のところチームの目標としてはこのOKRを定期的にたて、具体的にどのようにユーザーに行動変化をしてもらうか、そのためにどのようなOutputが最適なのか、その仮説検証をどうすればいいかということを考えることで日々の仕事はすすんでいきます。

直近のOKRとしては、PSFをめざしているので「いかに使ってもらっている皆様が継続して使い続けたいと最初の１ヶ月目の感想でいってもらえるようになるか？」などを設定してそこに向かっていろんなアクションプランを考えたりしていました。

また、このレイヤーをInnovation&Revolutionといってもいいかとおもいます。イノベーターを対象に社会変化が起こせたことをInnovationであるとするなら最終的に市場全体の行動変化を起こし、社会を変化させればRevolutionになるかなと思っています。そしてここまでいけばエクサウィザーズ が掲げるミッション「AIを用いた社会課題解決を通じて幸せな社会を実現する」が達成できます。

まとめ

以上６つのレイヤーでのプロセスを統合する形でプロダクト企画開発をすすめてきました。それをまとめたのが上記の図になります。

(実は細かいところでまだ説明しきれてないプロセスなども上の図には含まれているのですが、流石に長すぎるのでいったんこの辺で説明をやめておきます。このあと別記事か宮田個人のnoteで、もう少し詳細なプロセス紹介についてかくかもしれません。)

どのレイヤーでも繰り返し「仮説の不確実性を段階的に低減させ、プロダクトの成功の確度を上げること」を基本としこのプロセスは考えられています。

ここまで書いてきたことは、決して机上の空論ではなく話すと記録チームで実際にやってきたプロセスばかりになります。まぁぶっちゃけるともともと最初からこういったプロセスを全部考えてやってきたわけではなく、あとから整理し直した部分もありますが、おおまかPMプロセスを最初から考えて、実際に徐々に不確実性を減らしながらここまですすめてきました。

最初は本当に、介護業界のお客様は記録に関する困りごとはあるのだろうか？という課題仮説に対する怪しさの検証からはじまり、それは確かにそうだとわかると、だんだんとアウトプットのレベルをデザインモックから実際に開発された動くモノへと進化させつつ、ソリューションが使われるかの検証を行い、それがいけそうかもとわかってくると、どうやったら売れる仕組みになるだろう？どうやったらお客様が本当に業務が楽になると感じて、世の中がかわっていくだろう？ということをプロセスに沿って順当に悩んでいってるわけです。

こういったプロセスにこだわってきた理由としては、自分の中で再現度の高いプロダクトマネジメントを行いたいという思いがあるからです。以前別の記事のインタビューでも言及したのですが、プロダクト開発は決して天才の思いつきだけでつくっていくべきものではなく、どんな人でもある一定のやり方に沿ってやっていればいいものが作れると信じていて、そうした試みこそがスタートアップ全体のプロダクトのレベルをあげるものになると考えています。

今回紹介したプロセスは自分で考えたものはほとんどなく偉大な先人が考えたありものの組み合わせです。（個別のプロセスは各章で紹介した方々のものによりますが、全体の統合という意味では著名なアジャイルコーチであるJeff Patton氏およびそのJeff氏の考えを紹介いただいた日本のアジャイルコーチ川口 恭伸氏によるところが大きいです）

ぜひこの記事を参考にしていただくのも嬉しいですが、いろんなPM本やUX本を読んでみなさん自分なりのPMプロセスを設計し、再現度の高いPMをやっていっていただけるといいなと思っております。

あと、最後の最後にちゃぶ台をひっくり返すことをいうのですが、PMプロセスとして大事なのは、壮大な全体のプロセスも重要ですが、あまり机上の空論にとらわれすぎて何がなんだかわからず前に進めなくなるぐらいなら、レイヤー１のシンプルな仮説検証のみ頭にいれて泥臭く物事にぶつかり続けることをおすすめします。

今回書いてきた話も強調してきたように、シンプルな仮説検証プロセスを組み合わせてできています。一番大事なのはPMF、売れるようになる段階までは実直に仮説検証を繰り返すことだと思っています。これからもいろいろ考え方は変わるかもなとは思ってるのですが、ここだけは多分永遠にかわらず取り組み続けていくつもりです。