初スクラップ！

「製品開発からリリースまでの間の断絶（顧客実証をしないこと）」は
アジャイルの文脈でもよく聞くことだった。「顧客開発」という名前がついていたとは！

「ある時点で重要な行動はわずかしかない。ここに集中する。他は無視する」は
複数のリーンスタートアップを作った著者の経験があってこその言葉だと思った。
「重要である」ことに気づけるか、いざ集中するとなったら集中できるかも大事なのではなかろうか。
今の仕事では見定められているかなぁ

続きが楽しみ！

1.1

早く作れて、要点がまとまったリーンキャンバス。
それぞれの枠が小さいので、簡潔な言葉で書けるのもうれしい。

「製品」とはビジネスモデルそのものであり、システムやアプリ単体のことではない。
これはぜひ覚えておきたい！

1.2

第1ステージ：Problem/Solution Fit
解決に値する課題（≒解決すべき課題？）はあるか
これに対応するのがMVP、なるほど

第2ステージ：Product/Market Fit
MVPがどれだけ必要とされているか

第3ステージ：Scale
ビジネスモデルの拡大、最適化

今やってる仕事だと、やっとMVPができたって感じかなぁ
たくさんのお客さんと関係をもって、業務の不満点や改善したい点を聞くことができた実感はあるし
それに対応した機能は作っているはず
しかし、導入はしてくれたものの実際の現場ではあまり使われていないところも多々あり、「本当に必要なのか、これまでの運用が結局スムーズでいいのでは」と思うことはあったので、PMFではまだないんだろう、と想像
というよりもそれを測る指標を持っていないのが問題？？

---

資金調達の話も出てきた
外部資金を調達するのはPMFしたときが一番いいらしい。起業家と投資家の目標（＝ビジネスの拡大）が一致している ため
投資してもらえるように、ビジネスモデルを十分に検証すべきで、それを最初に取り組むべき

1.3

検証の話
検証には、定性的検証と定量的検証があるらしい

この辺の話はちゃんと理解してできるようになりたい
仮説の正しさが他の人からは分からないし、数字で伝えるべきだよね

2.1

1年弱で出版できたのすごい
目次を改良しながら見込み客を発見しておいたことで、出版社のリスク軽減につながった
中身を少しずつ提供していくことで、よりよい本になった。

UVP = Unique Value Proposition (独自の価値提案)

3.1

複数の選択肢を考えておくのが大事（ここでは顧客セグメントを取り上げていた）
顧客セグメントは細かく分けておきたい。
確かに「働く人」というセグメントの中にもいろんな属性でセグメントが作られているはず

3.2

リーンキャンバスの書き方が紹介されていた。特に初期段階にフォーカスしてるっぽい？（アーリーアダプターを定義しようとしているところから）

UVPの作り方も紹介されている。
とにかくアーリーアダプターにリーチしたい、LPを見てほしいという気概を感じる。SEOの話まで出てきた
顧客との接点は初期から考えておくべき

MVPの段階から課金してもらうべき
無料だと顧客が製品を使う動機がなくて、フィードバックが生まれない。
価格を決めることで、「いくらなら売れる、売れそう」が分かる。
「無料だからとりあえず登録した」という人が多そうで、これは「見込み顧客」とは言いづらい（投資する側は少なくともそう思う）、というのもありそう。
トライアル期間を設けるのもいいね

海賊指標
https://bizdev.blog/aarrr/
「アー」と読むらしい

圧倒的な優位性、簡単にコピーできないもの

---

熱い話だった
何かの製品をテーマにリーンキャンバスを書いたり、今の仕事で作っているシステムをテーマにリーンキャンバスを書いてみたいなぁ
何かを始めるときに、この内容を知っていたらいろんな事の解像度が上がりそうな気がした
いずれは自分がファシリテーションできるようになって、悩んでいる人を助けたいな

4.1

リーンキャンバスを使って、機会費用と実費費用からリスクを定量化する

4.2

↓を考えてみる

• 課題を持っているであろう顧客セグメントを作り、優先順位をつける。また、各セグメントごとに上位の課題を3つあげる
• 顧客へのチャネルを見つける
• 粗利益を考える
• 市場規模を考える（市場が大きい顧客セグメントを探したい）
• 技術的に実現可能かどうか考える

4.3

ビジネスモデルは顧客以外のだれか1人以上と共有する
アドバイスは鵜呑みにしないようにしよう

5.1

いよいよ実験の準備

「課題チーム（課題を見つけたり検証する）」と「解決チーム（開発など）」を作る、2~3名で構成する
が、これらのチームは機能横断で動くべき
コミュニケーションコストを下げて、小さく早く作れるようにする

5.2

実験では「集中、学習、速度」のループを回すのが大事
リスクがなくなるまで何回も取り組む
「集中」がピンと来なかったが、「目の前の課題を解決することに集中する」と理解した
外堀を埋めるような行動はムダになることがあるのかもしれない

「想定」を「間違いがはっきりとわかる文（反証可能な仮説）」に変えていく
具体的で反復可能な行動 + 計測可能な成果目標

学習の進捗を伝えるためのダッシュボード
目標と反証可能な仮説が積み重なっていくと、我々がこれまでにどんなことをして何を学んだかが一目瞭然になりそう。
リスクとそれがどう解決したか、みたいなまとめになってビジネスモデルが洗練されていきそう（後にでてくる「拡張性のあるビジネスモデル」？）

5.3

実験は「イテレーション」となるようにしていく必要がある
実験の具体的な方法について
ふと↓を思い出した
https://www.ryuzee.com/faq/0031/

6.1

アンケートではなく、顧客と話をすること
アンケートは正しい質問と正しい答えがあることが前提になっているので、顧客の課題が発見しづらい
アンケートは、立てた仮説の検証をするときに使う

6.2

顧客にビジネスモデルをアピールするのではなく、どんな課題を持っているか、その課題を正しく理解することに努める
※ビジネスモデルの検証はアドバイザーにお願いすればいいよね、ということかな

インタビューから新しいことを学習できなくなるまで続ける
他にも具体的なインタビューの方法が紹介されていた
いかに「自然に、構えさせることなく」が大事だ、という印象を受けた（インタビュー場所に気をつけたり、録音しない（観察者のバイアス）など）

やはり、インタビューして課題を発見（理解）するのは大事だ
何年か前に、大学の学生さんにインタビューしに行ったのを思い出した

7.1

課題インタビューでは、「正しく課題を理解できているか」「顧客セグメントは合っていそうか」を検証する

7.2

課題に対する顧客の反応を計測する
LPやブログなどの反応を見る

7.4

具体的な課題インタビューの例
どんな段取りで、そこで何を聞きたいか
相手の身振り手振りから「どれくらい大変か」や「どれくらい解決したい課題か」を感じ取る

7.5

台本は週次でブラッシュアップする（思いもよらない課題が見つかったりする）
最終的に課題を1つにしたい。これがUVPになる

また、代替品も理解する必要がある
これから我々が作る製品と比較されるので

---

ここまでで、実際の製品は全く開発していないことに気が付いた
※LPなど簡単なものはあるかも

顧客の課題を発見/理解することがいかに大事かがよく分かった
どれだけ多くの人が課題を抱えていて、お金を払ってまで解決したい人がどれくらいいるかを調べることで
何を作るべきかがとても明確になる気がするし、成功の確率も高そうと感じた

とはいえ、並行して開発もしているはずで、「作るものがコロコロ変わる」というのはここから来ているのかもしれない
課題を学習するなかで、最優先の機能を実装していく

この辺の舵切り、相当難しいことなのでは！？