シン・正しいものを正しくつくる (MVP Edition)

シン・正しいものを正しくつくる MVP Edition Ichitani Toshihiro 市⾕聡啓

市⾕ 聡啓 Ichitani Toshihiro 「正しいものを正しくつくる」⽀援、 「組織を芯からアジャイルにする」⽀援 (株式会社レッドジャーニー) 特に専⾨は 「仮説検証、アジャイル開発、組織アジャイル」 https://ichitani.com/

• https://ichitani.com/

「正しいものを正しくつくる」とは︖

30秒で誰でも だったらこれで 思いつくコンセプト いいんじゃね (浅すぎ) (思いつき) まちがったものを… どこかの誰かに 何も読み取れない 聞いたような話 50枚のパワポ (デジャブ) (屏⾵のトラ)

数ヶ⽉先までタスク が積み上がった計画 (ムダに精密な計画) チームもプロセスも 技術も整っていない (無謀なやってみよう) まちがいながら… ⼀個⼀個Mgrへの 確認と承認が必要 (堅牢すぎる管理) 役割分担の境界が 住んでる世界の境界 (チーム内サイロ)

間違ったものを間違いながらつくる Photo credit: Kylie_Jaxxon on Visual Hunt / CC BY-SA

• https://visualhunt.co/a4/f824b2af

俺たちの “Scrum” で プロダクトオーナー スクラムマスター 開発者 プロダクトバックログ ステークホルダー デイリースクラム スプリント スプリント プランニング レビュー スプリントバックログ スプリント インクリメント スプリント レトロスペクティブ 正しくつくる︕

俺たちの “Scrum” は プロダクトオーナー プロダクトバックログ スクラムマスター 開発者 正しいものを︖ ステークホルダー デイリースクラム スプリント スプリント プランニング レビュー 正しくつくる スプリントバックログ スプリント インクリメント スプリント レトロスペクティブ 正しいものを連れてきてくれるのか︖

プロダクトオーナー スクラムマスター 開発者 プロダクトバックログ ステークホルダー デイリースクラム スプリント スプリント プランニング レビュー スプリントバックログ スプリント インクリメント スプリント レトロスペクティブ

プロダクトオーナー スクラムマスター 開発者 プロダクトバックログ 何作るべき︖ 詳細な仕様を︖ デイリースクラム 進みは⼤丈夫︖ ステークホルダー スプリント プランニング スプリントバックログ スプリント スプリント チーム内 受託開発 レビュー インクリメント スプリント レトロスペクティブ

間違ったものを正しくつくる Photo credit: Kylie_Jaxxon on Visual Hunt / CC BY-SA

• https://visualhunt.co/a4/f824b2af

「正しいものを正しくつくる」とは︖

世の中にあるはずの「正解」を ⾒つけ出すこと︖ Photo on VisualHunt.com

• https://visualhunt.com/re6/2648d7eb

⾃分たちの信じたい「正解」を どうにかして証明すること︖ Photo on VisualHunt.com

• https://visualhunt.com/re6/2648d7eb

「正しいものを正しくつくる」とは 世界の中で「整合を取る」こと

整合される 整合する もの もの （整合先） （整合元） 左と右の⼀致をつくること

整合される もの （整合先） 価値 整合する もの （整合元） 左と右の⼀致によって はじめて「価値」がうまれる

整合するべきことが 「仕様」と「ソフトウェア」の⼀致だとしたら ちゃんと動く︕ 仕様 （整合先） ソフトウェア （整合元） 創出される価値 とは 「仕様通りに動くソフトウェア」 （ソフトウェアが期待通りに動くこと）

… あなたが⽣み出したい価値とは何︖

「ソフトウェア」と「プロダクト」は違う ソフトウェア プロダクト ・役割は期待 (仕様) 通りに 動くこと ・役割は利⽤⽬的を果たして 価値をもたらすこと ・前提として必要なのは、 要件定義であり仕様決定 ・前提として必要なのは、 価値とは何か︖の仮説検証 ・「作る」→「使える」 ・「使う(試す)」→「作る」 ・担い⼿は、 ソフトウェア開発チーム ・担い⼿は、 プロダクトチーム

「プロダクト」作りに適した状況を作れている︖ プロダクト ・役割は利⽤⽬的を果たして 価値をもたらすこと ・前提として必要なのは、 価値とは何か︖の仮説検証 ・「使う(試す)」→「作る」 ・担い⼿は、 プロダクトチーム どう作るかだけに 躍起になっている… 要件とか仕様という⾔葉が ⾶び交いがち 作ることが⽬的になっている SIや受託開発の経験者の 割合のほうが多い構成

もし⽬指していることが 「ユーザーに価値があると感じてもらえる」 プロダクトを作り出すことならば 利⽤価値 ︖︖︖ （整合先） プロダクト （整合元） 整合する「先」は何になる︖

そもそも 誰のこと︖ どんな状況 の話︖ 困りごとの解消︖ 今までにない 楽しさ︖⾯⽩さ︖ 利⽤価値 ︖︖︖ （整合先） プロダクト （整合元） 整合先が「はっきりとしていない」なら そもそもその特定から始める必要がある

ソフトウェア プロダクト ・役割は期待 (仕様) 通りに 動くこと Add! ・期待がはっきりしてるから ・役割は利⽤⽬的を果たして 価値をもたらすこと Add! ・そもそも何と整合取れば 要件も仕様もあらかじめ どんな価値があるか 決められる はっきりとはしていない ・前提として必要なのは、 要件定義であり仕様決定 ・前提として必要なのは、 価値とは何か︖の仮説検証 ・「作る」→「使える」 ・「使う(試す)」→「作る」 ・担い⼿は、 ソフトウェア開発チーム ・担い⼿は、 プロダクトチーム

ソフトウェア プロダクト ・役割は期待 (仕様) 通りに 動くこと Add! ・期待がはっきりしてるから ・役割は利⽤⽬的を果たして 価値をもたらすこと Add! ・そもそも何と整合取れば 要件も仕様もあらかじめ どんな価値があるか 決められる はっきりとはしていない ・前提として必要なのは、 とはいえ、端から端まで 要件定義であり仕様決定 明確なわけでもない… ・「作る」→「使える」 だから「仮説検証ゼロ」 では済まないんですよ ・担い⼿は、 ソフトウェア開発チーム ・前提として必要なのは、 「これが価値です」と 価値とは何か︖の仮説検証 誰かが⽰すわけではない。 だから、何が価値となり ・「使う(試す)」→「作る」 うるか⾃分たちで仮説を ・担い⼿は、 置いていくんですよ プロダクトチーム

そもそも 誰のこと︖ どんな状況 の話︖ ︖︖︖ （整合先） 困りごとの解消︖ 今までにない 楽しさ︖⾯⽩さ︖ えっと.. たぶんこんな感じ︖ ところで 仕様は何︖ 早く仕様頂戴 ソフトウェア （整合元） もちろんこんな状態で ”プロダクト” を作っても 使われない、価値がない、売れない

整合先 (左側) の解像度を上げる 価値探索 に出よう Toshihiro Ichitani All Rights Reserved. Photo via Austin Ban via VisualHunt.com

そもそも「何とあっていれば良いのか」の 解像度を上げるためには︖ ︖︖︖ （整合先） (たいてい「ぼんやり」としたところから始まる)

様々な⾓度 (観点) から光をあてて、 少しずつ⾒えるようにしていく (= 解像度を上げる) この課題はどうでも いいみたい… ⼀番課題が現れる ︖︖︖ 状況が⾒えてきた （整合先）こういう解決策では この状況に課題が ダメみたい あるようだ 価値⾃体と価値となる条件、価値にならない条件 この両者の「⾒分け」をつけられるようにする

では、どんな観点で条件を 特定していけば良いのか︖

もし、あなたが ⾃分の⼝座にあるお⾦(1000万円) で プロダクトを作るとしたら、どんな観点が OKであれば、Goしますか︖

もし、あなたが ⾃分の⼝座にあるお⾦(1000万円) で プロダクトを作るとしたら、どんな観点が OKであれば、Goしますか︖ 本当に回収できるの︖ どのくらい儲かるの︖ 誰向けに作るの︖ そもそも何つくるの︖ そんなのもう世の中にあるのでは︖ なんでそんなかかるの︖ どうやってユーザーと出会うの︖ 本当に使う⼈いるの︖ 売れなかったらどうするの︖ つまり、⾒るべき観点は⼭程ある︕

「すべての観点を満たしてこい︕」 な〜んて、まさか⾔わないですよね 絶対儲かる やつ︕︕︕︕ 「あらかじめの正解を出せ」と⾔っているのと同じになる

最⼩限の観点で本質を⾒分けられるか だからこそ、「仮説検証」を重視する とはいえ、あらゆる観点を試すほどのお⾦も時間もかけられない ︖︖︖ 価値 （整合先） 少なくとも、”ここ”⾒ておけば 「価値がある」と判断できる観点を持っておく

「か - かた - かたち」で観る か 本質 思考・原理・構想 かた 実体 理解・法則性・技術 かたち 現象 感覚・形態 「建築代謝論 か・かた・かたち」(菊⽵清訓)

「か - かた - かたち」で観る 実現のプロセス か 本質 思考・原理・構想 かた 実体 理解・法則性・技術 かたち 現象 感覚・形態 理解のプロセス 「建築代謝論 か・かた・かたち」(菊⽵清訓)

「か - かた - かたち」でプロダクトを観る か 本質 課題 どんな課題やニーズを扱うか それは誰にとってのことか かた 実体 機能 どのように課題やニーズを 具体的に充⾜させるのか かたち 形態 現象 機能を扱える様にするのに 適した利⽤形態とは何か

観るべき対象・状況に「光」をあてて可視化する⼿段 「仮説キャンバス」 ⽬的 われわれはなぜこの事業をやるのか︖ 実現⼿段 提案価値を 実現するのに 必要な⼿段と は何か︖ ビジョン 中⻑期的に顧客にどういう状況に なってもらいたいか︖ 優位性 提案価値 顕在課題 代替⼿段 状況 提案価値や 実現⼿段の提供 に貢献する リソースが何か あるか われわれは 顧客をどんな 解決状態に するのか︖ (何ができるよ うになるのか) 顧客が気づいて いる課題やニー ズに何があるか 課題を解決する為 どのような状況 にある顧客が 対象なのか (課題が最も 発⽣する状況 とは) 評価指標 どうなればこの 事業が進捗して いると判断でき るのか︖ (指標と基準値) 収益モデル どうやって儲けるのか︖ に顧客が現状、 取っている⼿段に 何があるか︖ (さらに現状⼿段へ の不満はあるか) 潜在課題 多くの顧客が 気づけていない 課題、解決を 諦めている課題 に何があるか チャネル 状況にあげた⼈ たちに出会うた めの⼿段は何か 市場規模 対象となる市場の規模感は︖ 傾向 同じ状況にある ⼈が⼀致して ⾏うことはある か

仮説キャンバス (1.0) 優位性 実現 提案 ⼿段 価値 代替 ⼿段 と 不満 顕在 課題 仮説キャンバス for miro 右から左の関連線が引きやすいように再配置 潜在 課題 状況

「仮説キャンバス」で 「か - かた - かたち」の整合を観る ⽬的 われわれはなぜこの事業をやるのか︖ 実現⼿段 かた 提案価値を 実現するのに 必要な⼿段と は何か︖ 中⻑期的に顧客にどういう状況に なってもらいたいか︖ 優位性 提案価値 顕在課題 代替⼿段 状況 提案価値や 実現⼿段の提供 に貢献する リソースが何か あるか われわれは 顧客をどんな 解決状態に するのか︖ (何ができるよ うになるのか) かち 顧客が気づいて いる課題やニー ズに何があるか 課題を解決する為 どのような状況 にある顧客が 対象なのか (課題が最も 発⽣する状況 とは) （機能） かたち ビジョン （価値） 評価指標 どうなればこの 事業が進捗して いると判断でき るのか︖ (指標と基準値) （形態） 収益モデル どうやって儲けるのか︖ か（課題） に顧客が現状、 取っている⼿段に 何があるか︖ (さらに現状⼿段へ の不満はあるか) 潜在課題 多くの顧客が 気づけていない 課題、解決を 諦めている課題 に何があるか チャネル 状況にあげた⼈ たちに出会うた めの⼿段は何か 市場規模 対象となる市場の規模感は︖ 傾向 同じ状況にある ⼈が⼀致して ⾏うことはある か

「か - かた - かたち」からさらに解像度を上げて 「整合を⾒る」- 「仮説の⼀本線」 ⽬的 われわれはなぜこの事業をやるのか︖ 実現⼿段 提案価値を 実現するのに 必要な⼿段と は何か︖ 5 ビジョン 中⻑期的に顧客にどういう状況に なってもらいたいか︖ 優位性 提案価値 顕在課題 代替⼿段 状況 提案価値や 実現⼿段の提供 に貢献する リソースが何か あるか われわれは 顧客をどんな 解決状態に するのか︖ (何ができるよ うになるのか) 顧客が気づいて いる課題やニー ズに何があるか 課題を解決する為 どのような状況 にある顧客が 対象なのか (課題が最も 発⽣する状況 とは) 評価指標 どうなればこの 事業が進捗して いると判断でき るのか︖ (指標と基準値) 収益モデル どうやって儲けるのか︖ 4 2 潜在課題 多くの顧客が 気づけていない 課題、解決を 諦めている課題 に何があるか に顧客が現状、 取っている⼿段に 何があるか︖ 3 (さらに現状⼿段へ の不満はあるか) チャネル 状況にあげた⼈ たちに出会うた めの⼿段は何か 市場規模 対象となる市場の規模感は︖ 1 傾向 同じ状況にある ⼈が⼀致して ⾏うことはある か

「か - かた - かたち」の整合で「かち」を導く どんな課題やニーズを扱うか それは誰にとってのことか 課題 か 利⽤から新たな 課題を検出する 課題と機能は 整合するか 価値 かち 形態 機能を扱える様にするのに 適した利⽤形態とは何か 機能 かたち かた 機能と形態は 整合するか どのように課題やニーズを 具体的に充⾜させるのか

「仮説」が⽴ったら「検証」する どのくらい確かに ⾔えることなのか︖ 仮説 （整合先） プロダクト （整合元） 仮説の「確からしさ」を得るための活動 =「仮説検証」

仮説検証で確かめる「整合」= t PSFが成り⽴つ領域を ⼗分に広げられるか か-かた-かたちの⼀致を インタビューやプロトタイプ、 MVPなどによって検証する Product-Market-Fit 期待するビジネス規模に到達 するためにチャネルや利⽤体験向上 に関する検証を⾏う fi Problem-Solution-Fit

PSF PMF No t 不確実性⾼ 解決するべき課題、 課題に対して提供する そのアーリアダプター ソリューションの の特定もできていない 有⽤性、有意性を ため、確からしさが インタビューレベルで 何もない段階。 確かめる段階。PSFの インタビュー検証を 第⼀段階を得るための 繰り返し実施する。 活動であり、速度が 数が求められる。 期待される インタビュー検証 fi fi 課題探索 fi fi tの仮説検証を「段階的」に進める インタビュー検証 PSF向け プロトタイプを⽤いて 疑似体験が伴う検証に よってPSFのリアリティ を⾼める段階。 形態も検証の対象に⼊り 始める プロトタイプ検証 PS t実現 不確実性中 実体験が可能な検証によって PSFを確認する最終段階 MVP検証 PM t実現 不確実性低 チャネル検証

「検証実験」と「探索実験」 仮説検証とは「仮説が合っていることを確認する」だけの活動ではない 今まではなかった試みならば「検証によって新たな切り⼝と出会う」 活動でもある。検証によって「仮説 (左側)」を育てていこう。 インタビュー 検証 プロトタイプ 検証 思っていた課題は、⼤した優先度では なかったが検証によって別の課題に遭遇 プロトタイプで形にするからこそ、 あるいは体験が伴うからこそ、 新たな課題や切り⼝にも遭遇できる 「検証実験（当てる実験）」だけではなく、 「探索実験（やってみる／試してみる実験）」を数多く⾏おう

左側が整ったら、右側に着⼿する 検証した「仮説」に 適した「プロダクト」を準備する 仮説 （整合先） プロダクト （整合元） PSF-PMFの確からしさが⼀定得られたところで 「提案価値の実現」を具体化する

MVPがもたらす 「デットエンド」ルートを回避しよう Cli ff Toshihiro Ichitani All Rights Reserved. Hanger Photo via Mars Williams via Visual hunt

「MVP」とは学習⼿段である MVPとはここまで⾒てきたとおり、あくまで左側の 仮説の検証のため、学ぶために適⽤する⼿段 そのため、必ずしもソフトウェアを作って検証する とは限らない (ex コンシェルジュMVP、オズの魔法使い) 仮説 （整合先） MVPによる検証 (⼿段はソフトウェア、⼈⼒、混合様々) プロダクト （整合元）

「MVP」と「価値提供」を区別する 実際にはMVPをソフトウェアとして実現することが多く 「動くモノ」が具体化することで検証→価値提供を 「なし崩し」的に⾏ってしまうケースがある これは、ビジネスモデルの検証がまだ終わっていないのに ビジネス⾃体を始めてしまうに他ならない (早速収益が問われる) 仮説 （整合先） MVPによる検証 (⼿段はソフトウェア、⼈⼒、混合様々) プロダクト （整合元） MVPとして価値提供︖

左右の整合が取れず、邪悪な展開になる 左側の「 tの可能性」がまだ分かっていない中で、MVPを価値提供 として運⽤し始めると、「右側に引っ張られる」ことになる むしろ、「プロダクト(右)に合うような顧客(左)を⾒つけよ」に 問題がすりかわる（= 営業をもっと頑張る…） 邪悪な⼒学 まだ整合 していない ︖︖︖ （整合先） MVPによる検証 fi (⼿段はソフトウェア、⼈⼒、混合様々) プロダクト （整合元） MVPとして価値提供

「MVP」vs「MKP」 検証・学習⼿段と、価値提供の⼿段を常に⾒分けること ソフトウェア的には同⼀でも、果たす役割としては異なる Minimum Viable Product Most Knowledgeable Product ・ tの検証、学習の為の 最⼩限の実⾏可能物 ・価値提供の為に最⼤限学習 結果を踏まえたプロダクト 分かっていないこと 分かっていないこと MVPで「分かる(学んだ)」 分かっていること 領域を増やしていく MVP MKP か・かた・かたちで 最も最適な範囲を提供 fi このあたりの区別をつけておかないと「検証のためにラフに作ったモノ」と 「価値提供のために持続性が問われるモノ」との間の⽬的不整合に後々悩まされることになる

ということで「正しくつくる」 MVPベースでの構築か、MKP観点での構築かを選び、右側をつくる 焦点は勿論「左側」との整合を取りながらつくり進めること ユーザー （整合先） プロダクト （整合元） 「プロダクト」をつくるときの「左側」って︖ もちろん、「ユーザー」ですよ︕ 整合先を特定するために仮説検証を繰り返してきたわけです

POがユーザーの代弁者になる つまり、プロダクトとして作るべきものが整合しているかを ユーザーの反応でもって把握、判断しながら作り進める ただし、ユーザーを常にスプリント活動に巻き込むのは難しい ユーザー でありPO （整合先） プロダクト （整合元） ゆえに、プロダクトオーナーがユーザーの代弁者となり、 スプリント活動において整合が取れているかどうかを担う 勿論仮説検証を⾏ってきたからこそ、ユーザーを憑依させられる

スプリントレビューでの論点は2つ ということでスプリントレビューで巻き込む相⼿も分かってくる 参加者には以下のいずれかのフィードバックを期待したい ① 「仮説」に合致する「プロダクト」となるためのフィードバック ② 「仮説」⾃体へのフィードバック ② 仮説 （整合先） プロダクト （整合元） ① プロダクトを作り進める中で仮説⾃体への疑義や新たな発⾒が 得られることがある。②が挙がった場合、追加検証するか決める

ユーザー、プロダクト、チームの健全性を保つ 価値創出を持続するには、ユーザー、プロダクト、両者の整合を 保つために活動する「チーム」⾃体の健全性を保つことも必要 マンネリ感、持続不可能なペース配分、 なんとなく後ろ向きな雰囲気、相互信頼の低下… チームが不健全になっていないか、 チーム ファイブフィンガーやふりかえりで状態検知 ユーザー、プロダクト、チーム、どれか⼀つでも⽋けたら 価値創出は持続しない。3者の健全性を保つ運営が前提となる

さて、ここまで「整合を取る」を中⼼に ⾒てきたわけですが、いくつかの気づきが得られます これは「新規事業」に限った話ではないですよね︕ 新規事業=新たに整合先と整合元を作る 既存事業=整合できているのかを捉え直す そもそも既存事業の整合を⾒直し、 価値向上の余地を⾒出す為の考えでもある

「右側」からの発⾒や導きもある 「左側」を整合先として出発はするが、価値創出を継続する中で 「右側」から「新たな仮説」の発⾒や考えにも⾄る 例えば、ユーザーが残した⾏動データから、ユーザー⾃⾝も気づいていない潜在的な意図を 汲み取り、プロダクトのほうから実現できていない⾏動提案や学習⽀援を⾏う等 新たな価値の関する仮説を⽴てる、つまり左側を拡充し、再び 適しているかどうかの検証を⾏い、プロダクトを拡張させていく 新たな仮説 ユーザー （整合先） プロダクト （整合元）

… ⼀⽅、そもそもの組織体制⾃体が障壁として現れることもよくある 整合を取る先が広がるほど難易度が上がる 実際のところ左右の整合だけでは済まず、そもそもの営みについて 「上⻑」と整合を取らなければならない︖ 「評価」と整合を取らなければならない︖ 「組織」と整合を取らなければならない︖ といった「整合先」が現れることはよくあること。 これらの「整合先」が増えるにつれて我々の活動は難易度が上がっていく。 上⻑ 評価 組織 そもそも、すべての整合を取ることが正解とは限らない。本質的な整合先を 残し、その他の調整はプロダクト作りの範疇外でどうにかする必要もある （to be continued .. 組織を芯からアジャイルにする）

「正しいものを正しくつくる」とは︖

「正しいものを正しくつくる」とは ・世の中にあるはずの「正解」を⾒つけてきて「回答」する ことではない ・⾃分たち⾃⾝で正解となりうる「整合先」⾃体を⾒出し、 適した「整合元」を作り出すこと ・さらに、時間とともに現れる変化を捉え「整合」を維持する ・その為には⾃分たち⾃⾝の「健全性」をも整合する必要がある ・「変化」を⾃分たちで起こそう

さいごに

知⾏合⼀（ちこうごういつ） という⾔葉があります。

「知は⾏の始なり、 ⾏は知の成るなり」 （知ることは⾏為の始めであり、 ⾏為は知ることの完成である）」 「伝習録」

「知る」ことと、「⾏う」ことは、 分離不可能であり、 ⾏動を伴わない知識とは、 「知らない」と同様であるとされます (万物の理を極めてから実践に向かう「知先⾏後」への 批判でもある)

「左」と「右」で「整合を取る」とは 「知⾏合⼀」が意図することと、 整合するものと⾔えます。

みなさんのチームや組織では、 正しいものを正しくつくれていますか

「シン・正しいものを正しくつくる」の Full Edition の 希望はこちらのgoogle formからどうぞ https://forms.gle/7LAiSXAayo73vbAb7 本内容についてのご質問や、実践の相談なども いつでも当⽅までお寄せ下さい

• https://forms.gle/7LAiSXAayo73vbAb7