第一部ロードマップ

■Running Leanの本質
　- プランAを文章化する。
　- プランで最もリスクの高い部分を見つける。
　- プランを体系的にテストする。

ビジョンの書き出しと共有をまず初めにやるべきだが、不確実性が原因でプランAは変更の可能性があるため、この段階で事業計画書を作るより「リーンキャンバス」などの一枚ペラを用いて、「高速、簡潔、携帯」を優先してビジョンの共有ができるものを持つことべきである。

ここでのポイントとしては、この段階（製品、サービス、事業のイメージ段階）だと下記の状態であると示されています。

あなたの「製品」は製品では「ない」

また、この段階の開発者（イメージを抱いている人、企業家）は主にソリューションに焦点を当ててしまっているが、投資家（将来のステークホルダーになる人）は、ソリューションに興味がありません。この段階での開発者（イメージを抱いている人、企業家）のやることとしては、最高のソリューションを構築するだけでなく、ビジネスモデルの全体像を把握して、各要素をうまくまとめることとしている。

ビジネスモデルを「製品」として考えれば、より大きな力になります。

実際にソリューションだけに焦点がいってしまい、リリース後の運用や保守、開発プロセスなどソリューションが世に出され、生きていくための工程を考慮していないことが多くあるため、私は上記の考え方に非常に共感しました。別に、開発初期の段階で答えはいらないんです。でも、ソリューション以外にも考えないといけないことはいっぱいあるよ。しかもステークホルダーには、その外部要素の方が需要なんだよ。と伝えている端的なワードのように思えました。

スタートアップの最も大きなリスクとは、誰も欲しくないものを作ること

リスクを回避するために取り組む、ステージを用意しています。

第１ステージ：課題/解決フィット（Problem/Solution Fit）
第２ステージ：製品/市場フィット（Product/Market Fit）
第３ステージ：拡大（Scale）

ステージの中での役割も明確に示しています。

第１と第２ステージ：「集中：検証による学習　実験：ピボット」
第３ステージ：「集中：成長　実験：最適化」

ピボットとは、学習を続けながらスタートアップの方向性を変更すること。つまり、うまくいくプランを探すこと。最適化はプランを加速すること。

製品段階をいきなり第３ステージにするのでなく「第２ステージ： 製品/市場フィット」での試行錯誤を一つのポイントとすることで、「第３ステージ：拡大（Scale）」に行くか、行かないかの判断をする機会を作ることができるのだと思いました。そこで、「第３ステージ：拡大（Scale）」に行くと判断ができたら資金調達をする事前準備が内部的に整ったので、投資家（ステークホルダ）にも説明をしやすくなっており、ビジネス拡大を狙っていける。

実験とは学習のループ

下記のサイクルを回すことです。

本書では

実験：ビジネスモデルの仮説の検証や反証に使うもの。
イテレーション：その実験を複数まとめて、
　　　　　　　　製品/市場フィットなどの目標に近づけるためのもの

と位置付けています。

■課題/解決フィット
　-　課題を理解する。
　-　ソリューションを決定する。
■製品/市場フィット
　-　定性的に検証する。
　-　定量的に検証する。

個人的には、「課題を理解する。」ここが一番のポイントではないかと思います。そしてその課題をチームとして共有することがアジャイルな開発（スクラム開発）に合致しているなと感じました。

上記の実例として、本書の出版までをまとめています。そこで一番印象的だったのは、下記のワードでした。

大規模なソフトウェアと同じように、
書籍も完成することはありません。
ただリリースされるのみです。

でもリリースされるため、そのソフトウェアや書籍もリリース後もよりよく改修や改良されるようになります。まずは世の中に出す（ソフトウェアを完成させる）ことがゴールであり、スタートなんだと改めて考えさせられました。

第二部プランAを文書化する

リーンキャンバスを書くまえに、製品の見込み客のブレインストーミングから始めます。

あらゆる人をターゲットにした製品を効果的に
設計・構築・出荷することはできません。

顧客：製品にお金を払ってくれる人
ユーザー：製品にお金を払ってくれません

顧客とユーザーを区別しましょう。
顧客セグメントを細かく分けましょう。
最初は全てを1枚のキャンバスにまとめましょう。
顧客セグメントごとにリーンキャンバスを書きましょう。

上記の考えをベースに顧客を想定していきます。一番面白いと思ったのは、顧客をセグメントごとに分けて、リーンキャンバスを作成することです。ある顧客にターゲットを絞って作るのでなく、セグメント別に複数作ることを目指しているのが驚きポイントでした。

この次に、リーンキャンバスを作成します。作成の際の注意点。

一気にスケッチしましょう。
空欄があっても構いません。
簡潔に書きましょう。
今わかる範囲で考えましょう。
顧客主導型を使いましょう。

著者がリーンキャンバスを書く順番

■課題
　- 上位1-3の課題をあげましょう。
　- 既存の代替品を列挙しましょう。

■顧客セグメント
　- ユーザーを特定しましょう。
　- アーリーアダプターに狙いを定めましょう。

■UVP（独自の価値提案）
　- 変わったものにしましょう。
       ただし、その違いが重要なものに限ります。
　- アーリーアダプターをターゲットに縞そう。
　- 成功ストーリーに注目しましょう。
　- 言葉をよく選んで使いましょう。
　- 誰が、何を、なぜに答えましょう。
　- 優れたUVPを調べてみましょう。
　- ハイコンセプトピッチを作りましょう。

■ソリューション
　- 課題とソリューションの統合はできるだけ遅らせましょう。

■チャネル
　- 無料と有料
　- インバウンドとアウトバウンド
　- 直販と自動化
　- 直接と間接（他人に任せる前に、自分で売らなければならない）
　- 紹介の前に定着（価値を広める製品が必要）

■収益の流れ
　- 学習するのに大勢のユーザーは必要ありません。
       優れた顧客が数名いればいいのです。
　- 価格は製品の一部
　- 価格が顧客を決定する
　- 課金は最初の検証

■コスト構造
　- 将来のコストを正確に計算することはできない。
　- AARRR（海賊指標）
　- 獲得
　- アクティベーション
　- 定着
　- 収益
　- 紹介

■圧倒的な優位性
　- コピーする価値のあるものはコピーされる。
　- 本物圧倒的な優位性は簡単にコピーされない。

第三部プランで最もリスクの高い部分を見つける

ダグラス・ハバードの「How to Measure Anything」より不確実とリスクについて引用しています。

不確実：確実性のないこと。複数の結果が存在すること。
リスク：損失や失敗などの好ましくない結果になり得る不確実な状態

リーンキャンパスを用いて、リスクとなる不確実を明確化して、リスクに優先順位をつけて、どこから手をつけるかを決定します。

■リスクのカテゴリ
　- 製品リスク：正しく製品を作る
　- 顧客リスク：顧客への経路を作る
　- 市場リスク：実現可能なビジネスを作る。

複数のリーンキャンバスから優先順位を決める際に、著者がポイントにしていることは、十分に大きな市場を持ち、製品の周りにビジネスを構築でき、その製品に必要都する顧客に近づけるようなビジネスモデルを見つけ出すこと。と示されています。また、その際に基準としているポイントは下記になります。

1.顧客の不満レベル（課題）
2.近づきやすさ（チャネル）
3.価格と粗利益（収益の流れとコスト構造）
4.市場規模（顧客セグメント）
5.技術的実現可能性（ソリューション）

またビジネスモデルを構築する際に、下記のことを示しています。

ビジネスモデルは最低でも
自分以外の誰か1人と共有しなければいけません。

でも、アドバイザーの言葉を「決定」や「検証」と思わないで、リスクの特定や優先順位をつけるための手段だと考えることが重要としています。あくまでもビジネスを所有しているのは「私（あなた）」であるからこそ、答えをすぐに出せなくてもステークホルダー（アドバイザー）との対話を経て、成功へと向かっていくと思います。

リーンキャンパスを用いた開発において、考慮すること一覧です。

課題チームと解決チームを作る
小規模ではなく最小のチームで開始する。
に必要な3つの要素：開発、デザイン、マーケティング
課題/解決チームの外部委託は慎重に
効果的な実験
速度、学習、集中を最大化する。
主要指標と目標を特定する。
学習に必要な最も小さいことをやる。
反証可能な仮説
定性的検証と定量的検証
結果を具体的な行動に結びつける
わかりやすいダッシュボードを作る
学習を早めにしょっちゅう伝える

また、各ステージで試すことになります。

■各ステージで試すこと
　- ステージ１：課題を解決する(UNDERSTAND PROBLEM)
　- ステージ２：ソリューションを決定する(DEFINE SOLUTION)
　- ステージ３：定性的に検証する(VALIDATE QUALITATIVELY)
　- ステージ４：定量的に検証する(VERIFY QUANTITATIVELY)

また、リスクについての詳細です。詳しくは下記で説明されます。

■製品リスク
　- 解決に値する課題かどうかを確認します。
　- 最小のソリューション（MVP）を決定します。
　- MVPを構築して、小規模に検証します。（UVPのデモ）
　- 大規模に検証します。

■顧客リスク
　- 不満を持っている人を特定します。
　- 製品を今すぐに欲しいと思うアーリーアダプターに範囲を狭めます。
　- アウトバウンドチャネルから開始しても構いません。
　- ただし、少しずつ拡大可能なインバウンドチャネルも
       構築/開発をしましょう。早ければ早いほどいいでしょう。

■市場リスク
　- 既存の代替品から競合他者を特定して、
       ソリューションの価格を設定します。
　- 顧客の声を聞いて、価格をテストします。（口約束）
　- 顧客の行動を見て、価格をテストします。
　- ビジネスモデルがうまくいくように、コスト構造を最適化します。

第四部プランを体系的にテストする

■顧客インタビューの準備

高速に学習するには顧客と話をすることです。
分析したりコードをリリースしたいするのではなく、人と話をするのです。

この段階では、定量的な質問をするための質問（調査したいこと）が明確になっていないため、まずは定性的に調査をし「仮説->検証」を繰り返し、定量的な検証のための準備をします。

でも、人と話をするのは簡単ではないため。。。下記に著書に記載されている「何を話せばいいのか？」に対するコツが記載します。

ピッチではなく学習を中心に考えましょう
顧客に何が欲しいのかを聞いてはいけません。行動を観察するのです。
台本に合わせて会話をしましょう。
網を広く投げましょう。
直接面会してインタビューしましょう。
知り合いから始めましょう。
誰かと一緒に行きましょう。
中立的な場所を選びましょう。
十分な時間をもらいましょう。
謝礼や贈り物をしないようにしましょう。
インタビューを録音しないようにしましょう。
インタビュー後すぐに文章化しましょう。
30 - 60人にインタビューしましょう。
インタビューのスケジュール調整を委託してみましょう。

また、本章で印象的だったのは「週末で何か作れるのに、どうして数週間もかけて顧客と話をするのか」の回答です。「早めのリリース、しょっちゅうリリース」からのフィードバックをもらうことがソフトウェアには可能ですが、その「小さな」リリース開発がほんとに「小さい」とは言えないかもしれません。学習する段階では、別にコードがしっかりしている必要もなく、モックアップや紙でも構いません。初期の段階では、見込み客との会話（インタビュー）を通じて、学習をすることが重要なためです。もちろんCI/CDの環境は必要ですが、最初からそこを準備するのでなく、まずは開発するものの方向性を見極める作業が必要なんだなと改めて思いました。誰だって手戻りは嫌です。

■課題インタビュー

ソリューションを考える前に顧客の世界観を理解しなければいけません。

「課題と顧客セグメント」の仮説検証をするために、課題インタビューをしなければなりません。また、下記のリスクにも取り組む必要があります。

製品リスク：何を解決するのか？（課題）
市場リスク：競合は誰なのか？（既存の代替品）
顧客リスク：誰が困っているのか（顧客セグメント）

課題インタビューの台本

インタビュー結果の分析、台本の改良、終了条件について。。。

結果を週次でレビューしましょう。
アーリーアダプターから始めましょう。
課題を洗練しましょう。
既存の代替品を理解しましょう。
顧客が使う言葉に注目しましょう。

ポイントは、アーリーアダプタを見つけることです。その中で「鍵となる」言葉を見つけ言葉からアーリーアダプターに近く経路を特定することがこの段階では必要になる。

■課題インタビューの終了条件
　- アーリーアダプタとなる顧客が特手できた。
　- 「絶対に必要」な課題が見つかった。
　- 現在の故客の解決方法がわかった。

そして、上記の終了条件を満たすことができればここでの作業は終了となります。

■ソリューションインタビュー

実際の製品を作る前に、「デモ」を使ってソリューションをテストします。

ここで学習すべきことは、下記となります。

顧客リスク：誰が困っているのか（アーリーアダプタ）
製品リスク：課題をどのように解決するのか？（ソリューション）
市場リスク：どのような価値モデルにするのか？（収益の流れ）

また、テストをする際の気にしないといけないガイドラインも示されています。ちなみに、デモの目的は顧客にソリューションの「デモ」を見せて、課題が解決できるかどうかを検証することです。顧客は課題について説明するのは得意ですが、ソリューションを思い浮かべるのは不得意なため、デモを通じて、課題に対するソリューションになっているかを検証します。

■ソリューションテストのガイドライン
　- デモは実現可能でなければいけません。
　- デモは本物に見えなければいけません。
　- デモは高速に反復する必要があります。
　- デモは無駄を最小化しましょう。
　- デモは本物に見えるデータを使わなければいけません。

顧客に「絶対に必要」な課題があると説得することはできませんが、あなたの製品に「適切な」価格があると説得することはできます。そして、あなたは顧客が考えているよりも、その価格は高いのです。だからこそ、価格のことは顧客に聞かずに、ただ伝えるだけにします。この段階では学習をするためのアーリーアダプターとの信頼関係を構築することが必要な段階で、まだ価格を確定することができません。また、価格設定は製品の一部であり、顧客セグメントを定義してしまうため、この段階で確定するようなものではないらしいです。

その中で、アーリーアダプターが使ってもらう状態になるように登録障壁を下げてもらうためことが必要です。下記をアピールする必要があります。

商品
希少性
アンカリング
度胸

そして、インタビューをできる環境が整ったら、実際にソリューションインタビューをしましょう。

インタビュー結果の分析、台本の改良、終了条件について。。。

結果を週次でレビューしましょう。
機能を追加/削除しましょう。
前回の仮説を確認しましょう。
価格設定を改良しましょう。

この後に製品を実際に作成していくため、まずはこの段階で何を作るのかを明確にしましょう。

■課題インタビューの終了条件
　- アーリーアダプターの顧客情報が特定できた。
　- 「絶対に必要」な課題がわかった。
　- 課題を理解するのに必要な最小限の機能が定義できた。
　- 顧客が支払ってくれる価格がわかった。
　- （概算で）うまく行きそうなビジネスが構築できた。

そして、上記の終了条件を満たすことができればここでの作業は終了となります。

■バージョン1.0をリリース

スコープを小さくせして、
要求とリリースのサイクルを小さくすれば、学習を加速できます。

フィードバックの回数を多くするためにはMVPを本質的なものだけにする必要があり、機能を盛り込みすぎると顧客への提供スピードが遅くなってしまいます。だからこそ、MVP縮小化する必要がある。

■MVP縮小化の方法
　1.白紙から始めましょう。
　2.最上位の課題から着手しましょう。
　3.「あればうれしい」や「必要ない」は削除しましょう。
　4.２位と３位の課題のモックアップに対して、
　　手順３を繰り返しましょう。
　5.顧客の機能要求を検討しましょう。
　6.初日から課金しましょう。ただし、徴収は30日後です。
　7.最適化ではなく学習に集中しましょう。

また、サイクルを早くするためにはCI/CDの構築です。例えば、開発時にレトロスペクティブのタイミングで実際の製品の動きを確認できたら、素早く内部でフィードバックをもらえます。また、顧客からの問い合わせがあった場合も検証として同等の環境が使えると、確認も容易になります。

■計測の準備

顧客ライフサイクルは可視化するだけでなく、
計測できなければいけません。

この段階だと「製品/市場フィット」前の時期に差し掛かっています。定性的な学習を経て、そこで得た知見を今度は定量的に検証（実際は定性的調査をするために定量的検証を構築する感じです。）をしていく時期です。まだ最適化をする段階ではないです。行動につながる指標を利用して顧客ライフサイクルを可視化して計測する時期なのです。

行動につながる指標とは、
観察結果を具体的に反復可能な行動につなげるものです。

面白いなと思ったのは、行動につながる指標の反対に虚栄の指標としてアクセス数やダウンロード数をあげています。指標ではあるのですが、目的に関係しない指標だと意味がないということです。

理想的なコンバージョンダッシュボードとは、
分析とカスタマーリレーションシップマネージメント（CRM）を
合わせ持つもです。

つまり、数字の裏にある人の声が見えるようにしないといけないのです。

■人の声が必要な理由
　- 指標はそれ単体では何も説明しません。
　- ユーザーの方からやって来るわけではありません。
　- すべての指標は等価ではありません。

具体例として、アクセス数などがわかる分析ツールだと、あまりに詳細（ミクロ）な部分を分析してしまい、マクロ視点がかけてしまいます。だからこそ、ミクロ要素とマクロ要素（ユーザ属性、端末情報など）他の情報と組み合わせた分析ツールを利用することをお勧めしている。

■MVPインタビュー

見ず知らずの人に流通チャネルで実用最小限の製品を販売する前に、
仲のいいアーリーアダプターに直接販売してみましょう。

ここでは下記の質問の答えを求めることが重要になります。

製品リスク：製品の魅力は何か？（独自の価値提案）
顧客リスク：十分な顧客いるか？（チャネル）
市場リスク：価格は適切か？（収益の流れ）

■MVPインタビューの流れ
1.歓迎（2分間）
2.ランディングページの提供（2分間）
3.価格ページの提示（3分間）
4.登録とアクティベーション（15分間）
5.まとめ（2分間）
6.結果の文書化（5分間）

インタビューを通じて、質問の回答を見つけましょう。最後にこのステップで結果を見つけられないといけないなと思った一文を記載します。

こちらに興味を持った見込み客を
20分のインタビューで説得できないのであれば、
ランディングページに到着した見ず知らずの訪問者を
8秒で説得できるわけがありません。

つまり、見込み客だからこそ、見込みになった理由がプロダクトに反映されているのか、そしてそれが彼らの問題を解決できているのかを、この20分で開発者は理解しないといけないのです。

■顧客ライフサイクルの検証

初期の顧客が登録してくれました。
何度もやり取りをして、コンバージョンファネルを
うまく最後までたどり着いてもらいましょう。

顧客からの学習の近道は、顧客に話しかけることです。

■理由
　- 気にかけていることが伝わります。
　- 問い合わせが多すぎるという問題はありません。
　- テクニカルサポートは継続的な学習のフィードバックループです。
　- テクニカルサポートは顧客開発です。
　- テクニカルサポートはマーケティングです。
　- 投票ツールによるフィードバックは使いません。

上記のように学習をするように顧客との対話をする期間として試用期間を設けます。試用期間での優先事項を明記します。

■獲得とアクティベーション：学習できるだけのトラフィックを稼ぐ
　- ファンネルを掘り下げる
　- ユーザに連絡しましょう
　- 予期しないエラーをキャッチして通知しましょう。

■定着：試用期間中にユーザーに戻ってきてもらって、製品を使ってもらう
　- 丁寧なリマインダーを送信しましょう。
　- インタビュー相手に協力を求めましょう。

■収益：お金を支払ってもらう
　- 決済システムを実施しましょう。
　- 支払った顧客に電話しましょう。
　- 「売り損ねた」見込み客に話を聞きましょう。

■紹介：推薦の声をもらう
　- 推薦の声をお願いしましょう。

上記を行うためにローチンを行うことになります。では、ローチンをする前にやるべきこと。

■ローチン前にやるべきこと
　1.結果を頻繁にレビューする。
　2.もっとも重要な課題から着手する・
　3.可能な限り小さなことをやる。
　4.確実に改善する。
　5.コンバージョンダッシュボードを監視する。

では、ローチンをするための条件をみましょう。

■ローチンの条件（アーリーアダプターが以下のことをできるようにする）
　- 独自の価値提案（UVP）を明確に理解している。
　- 本サービスに登録するつもりがある。
　- 価格モデルを受け入れている。
　- アクティベーションの流れをうまく通り抜けている。
　- 好意的な推薦の声を提供してくれる。

ローチンする目的は、あくまでも学習に「ちょうど十分」なトラフィックを獲得することです。だからこそ、ローチン前にフィードバックをもらえる状態を作っていくことが必要なのです。

■機能の押し売りはやめよう

本当の見込み客がいる優れた市場では、
市場がスタートアップから製品を引っ張る。

ポイントはこのタイミングで、機能を作りすぎてはいけません。

■理由
　- 追加機能は独自の価値提案（UVP）を薄めます。
　- すぐにMVPに見切りをつけてはいけません。
　- 機能には隠れたコストがあります。
　- 顧客は本当に欲しいものを分かってはいません。

その上で、作業開発フローを下記のように定義しています。

バックログ　→　作業中　→　完了　→　検証による学習

完了の次に検証のステージを設けることで、完了を明確に定義する必要が出てきます。そうすることで、曖昧な完了で次の機能開発をしてしまう状況を防ぐことができます。

では実際の開発サイクルになります。コードに取り掛かるタイミングは結構後の方になります。まずは方向性を合わせることが重要になりそうです。

■機能ライフサイクル
■■課題を理解する
　1.バックログ
　　a.顧客からの要望
　　b.内部からの要望　＊解決に値する課題か？を判断する。
■■ソリューションを決定する
　1.モックアップ
　2.デモ
　3.コード
■■定性的に検証する
　1.部分的展開
　2.定性的検証  ＊MVPインタビュー
■■定量的に検証する
　1.全面展開
　2.定量的検証

■製品/市場フィットの計測

製品/市場フィットを計算する指標を定義します。
製品/市場フィットとは、市場を満足できる製品のある状態のことだ。

計測方法の考え方
人が欲しがるものを作る指標は、定着になる。とし、定着を指標として図ることが求められる。また、そこでの利用ツールはアンケート調査であり学習よりも検証に効果的であるとしている。

アクティベーションの済んだユーザが毎月40%以上いれば、
初期のトラクションがあると言えるます。

また、収益については、

収益は最初の検証ですが、定着は究極的な検証

としています。

■人が欲しがるものを作ったか？
　- コンバージョンダッシュボードを毎週レビューする。
　- 目標とバックログの優先順位をつける。
　- 大胆な仮説を作る。
　- 機能を追加/削除する。
　- 価値指標を監視する。
　- ショーン・エリスのテストを実施する。

■初期のトラクションの終了条件
　- ユーザーの40%が定着した
　- ショーン・エリスのテストを通過した。

初期のトラクションが終了すると、次にビジネスの拡大に集中できるようになります。ここではビジネス拡大させるための3つの成長のエンジンを紹介します。

粘着型：高い定着率
ウイルス型：高い紹介率
支出型：高い利益率

この成長エンジンは時間によって適切なものが変わっていきます。そのために、時期によってどのように成長エンジンを見極める方が大切になります。

■成長エンジンのガイドライン
　1.価値指標の検証から着手しましょう。
　2.顧客の製品に対する態度を理解しましょう。
　3.調整するエンジンを選択しましょう。

今までのリーンキャンパスの検証をまとめると、下記のワークフローとなります。複数のリーンキャンパスを作成して、その中で実際に課題インタビューをするキャンバスを決めます。また、その結果を踏まえて、MVPインタビューするキャンバスを決めます。また、その結果を踏まえて、製品/市場フィットの段階となり、商品の定性的検証や定量的検証を行いプロダクトをより顧客の課題解決ができるように調整をしていきます。

定着は王様

最初の重要なマイルストーンは、みんなの欲しい物をつるくることです。これは繰り返しの利用やエンゲージメント（価値指標）で計測します。

つまり、プロダクト（サービス）を使い続けてもらうことこそ、リーンのゴールであり、スタート地点ではないでしょうか。

■結論

あらゆるスタートアップっは2つの時代に分けれる。
製品/市場フィット前（BPMF:Before Product/Market Fit）
製品/市場フィット後（APMF:After Product/Market Fit）

APMFで直面するのは「キャズム」です。そこを超えるためには、

各自が専門家になるのではなく、実験を通じた継続的な学習の文化を作ることが大切になります。つまり、顧客価値の創造や理解は、みんなの責任ということです。

と記載されています。

つまり、リーンキャンパスを用いた開発は、実験と学習はプロダクトや企業活動において、全て共通する考えであり、不確実な世の中で戦うための一つの武器であることがわかりました。

感想

ソフトウェアエンジニアをしていると専門性を突き詰めたい気持ちになるし、ソフトウェアエンジニアである以上、専門家は必須の条件だと思います。でも、企業活動として、ソフトウェアエンジニアをする以上、

私が作る（改修する）プロダクトは、誰かの課題を解決する物

であることを忘れてはいけないのだなと思いました。実際にプロダクトを作る際に詳細（情報の返し方）は、作り方は複数あるため、詳細側からはどのように作っていいかわからないことがたくさんあります。もちろん、先に作ってプロダクトオーナーなどに確認して修正することは可能ですが、その際に修正するコストが発生します。いくら修正に時間が掛からなくても（半日くらいとして）それを10回くらいやったら。。。私ならその会社をやめてしまいます。エンジニアが安心して開発することができなくなってしまいます。だからこそ、一つ上のレイヤーから全体を眺めながら、プロダクト（ビジネス）の方向性を決める方が、全員が幸せになれるような気がしました。

もちろん、このような手法を取り入れるためには、企業やチームが学習と実験を理解する必要があります。一度決まった仕様は変えられない環境ではこの手法も使えないですよね。だからこそ、ソフトウェアエンジニア側からの働きが必要なんだなと思いました。なぜならビジネス側（プログラミンが書けない人など）からすると、小さく初めて実験する -> 学習が、簡単にできるとは思っていないからかなと思いました。ハードやソフトウェアがないとそもそもビジネスは課題解決ができません。それを通じて、検証はできますが、課題解決のためのプロダクトを作れるわけではないので。そして、一度仕様を固めて最適化をすると、もう容易に変更はできません。ビジネス側の人は結局仕様が容易に変更できないタイミングで、プロダクトに興味を抱き意見をあれこれ言えるようになるからそのような結果になるのは必然かなと思いました。

つまり、リーンを用いた開発をするには「実験 -> 学習」を中心に据えて、この概念をチーム（エンジニアだけでなく、ビジネスを含め）で協力できる体勢を作っていけば、不確実なソフトウェア開発でもなんとか戦っていけるのではないかと希望をもらうことができました。

やっぱりビジネスとエンジニアには壁はあるんだな。
でも、壁の突破の仕方はないわけではないことがわかりました。