Zenn
Open11

プロダクト開発の進め方

nabetsunabetsu

リーン志向

  • サービス（プロダクト）開発において、価値の検証に重きを置く
  • 無駄を徹底して排除する

MVP(Most Viable Product)は直訳すると「必要最小限の機能」で、意味としては顧客からのフィードバックを得ることができるレベルの製品。つまり、

  • 良いアイデアを思いついた、かなり良さそうだ。
  • しかし、実際にお客さんが価値を感じてくれるかわからない。
  • だからできるだけ手間の少なく、短期間で作れる製品でお客さんからフィードバックを得て、このアイデアを進めるか決めよう。

上記の通り提供できる価値の検証に重きを置いている

  • Testable
  • Usable
  • Lovable

徐々に機能を作りこみ、顧客からのフィードバックを受けて価値を高める

MVPの色々な形態

種類 内容 検証できる仮説 実例
ランディングページ サービスはないままLPだけ作る。候補者にメールリストなどに登録してもらう 市場仮説 Airbnb, Spotify
デモ動画 動画で説明する 市場仮説 Dropbox
プレオーダー リリース前に購入を募る。クラウドファンディングなど 市場仮説 :--
プロトタイプ 実際に動くものをつくってみる :--
オズの魔法使い 外側だけアプリを作り、中身の処理は人間で行う 価値仮説 Zappos
コンシェルジュ 製品と同じ成果を人間の手で提供する 価値仮説 :--
社内ツール 元々社内のために使ったツールを外部に提供する 価値仮説 Facebook, Twitter, Slack

参考資料

nabetsunabetsu

アジャイル

シーケンシャル開発 アジャイル開発
長いリリースサイクル 短いリリースサイクル
長いリリースサイクルにわたって大きなバッチで実行する 短いリリースサイクルの中で小さいバッチで実行する
事前の詳細なプランニング 事前の大まかなプランニングとジャストインタイムの詳細なプランニング
事前の詳細な要求獲得 事前の大まかな要求獲得とジャストインタイムでの要求の詳細化
事前の設計 創発的な設計
最後にテストする 継続的な自動テスト（開発に統合）
不定期の構造化コラボレーション 頻繁な構造化コラボレーション
アプローチ全体が理想主義的で、事前に取り決められていて、制御志向 アプローチ全体が実証主義的で、臨機応変で、改善志向

アジャイルの恩恵

  • リリースサイクルが短いことで顧客からすぐにフィードバックを得られるようになり、迅速に軌道修正が可能になる
  • 小さいバッチで開発を行うことでフィードバックループがタイトになり、エラーの検出修正をより迅速に、低いコストでできるようになる
  • ジャストインタイムのプランニングでは

複雑さと不確実性に対処

  • 現在の状況
    • ビジネスを成功させるための正解が明確ではない
    • 一時的に正しくても状況がすぐに変わる

Cynefin(クネビン)

Cynefinは解決するべき問題領域を5つに分解し、それぞれで効果が期待できる

複雑な世界を捉えるためのカネヴィンフレームワーク(Cynefin Framework)

アジャイルにおける計画

  • 階層を分けたプランニング(プランニングオニオン)
    • それぞれでフォーカスが異なる
    • それぞれの実施結果ををより上位の層にフィードバックして、計画を修正する

参考資料

nabetsunabetsu

要求とマーケット不安

  • プロダクトを成長させるために納期よりも重要なのは「何を作るか」
  • 「何を作るか」が正しかったのかどうかは市場に機能をリリースして初めてわかる

マーケット不安はいつ削減できるか

  • 仮説検証における仮説とは「このようにしたらビジネスが成立する」というビジネスモデル全体のことを指す
  • 仮説を出す時点ではうまく行くのかは分からないので、「確実にうまく行くか」という視点で見るのではなく、「仮説として成立しているか」を精査すべき
  • 仮説を出した後のすべての工程は検証であり、仮説を構成する不確実性を少しずつ減らしていく
  • 仮説を出した時点では不確実性が最大で、これを少しずつ効率的に不確実性を減らしていくのが基本的な進め方
  • そのため、できるだけ少ない費用で大きく不確実性を減らせるものが初期段階の取り組みとしてふさわしい

リーンキャンバスによる仮説の作り方

  • 仮説が仮説として成立するためにビジネスが成立してできあがった後のイメージが非常に重要になる

  • このイメージがなければ、検証するためのアクションが発見できず、仮説として成立しない

  • 「仮説」が「仮説」として成り立っているかどうかを明らかにするためのフォーマットが「リーンキャンバス」

  • リーンキャンバスで重要なのが考える順番が決められていることであり、この順番に従うことで新規ビジネスを考えるときに陥りがちなミスを抑制できる

考える順番 項目 内容
1 顧客の課題 どんな痛み・ニーズを感じているか。
熱烈な飢えや痛みのようなものでなければ顧客はお金を支払うことは少ない
2 顧客セグメント 誰がどれぐらいそれを感じているか
どんな人が課題を感じているのか、それはどのぐらいの人数がいるのか。
3 独自の価値 他にはない独自の価値は何か
どんなに強いニーズであっても、他にたくさんの代替手段があればそちらに流れてしまう。「すごく安く」や「すごく簡単」のように他には見せられない価値が必要
4 解決策 どのようにその痛みを解決するか
ニーズを満たし、独自の価値のある解決策であるかを確かめながら、解決策をシンプルな言葉で表現する。これがMVP(顧客の痛みを解決していることを検証するための最小限の製品)になる
5 チャネル どこから顧客をどのくらいの値段で連れてくるか
顧客セグメントが十分にいても、簡単に獲得できなければビジネスは大きくならない。どの媒体かどのくらいの人をいくらで獲得するのかを想定しておく
6 収益の流れ お金はいつどのようにいくら支払ってもらうのか
サービスに対して誰に、いつ、いくらくらい支払ってもらうかを想定する。顧客が少なくても切実（痛みが強ければ）多くの金額を支払ってくれ、ビジネスが成立する可能性がある。
7 コスト構造 売上に対してどんなコストがどれだけかかるか
収益が生まれてもそれに応じてかかるコストがどれだけあるかによって利益率が決まる。顧客あたりのコストが大きすぎればどんなに良いサービスでも価格をあげざるを得ない
8 測定項目 何がどれくらいならうまくいっているか
今まで想定した仮説がうまくいっているかを図るための数値は何で、どれくらいだったら良いのか。最大３つ程度の売上以外の数値項目を設定する
9 競合優位性 なぜ自分たちがそれをやるとうまくいくのか
なぜ自分たちがそれをやるとうまくいくのか。また、これが成功するとなぜ他の競合が自分たちを模倣できないのか
nabetsunabetsu

不確実性の扱い

プロジェクトの開始時点が一番不確実性が高い
不確実性は以下の2種類に分けることができる。

  • 目的不確実性

    • この製品を作ったら売れるのか（これをつくるべきなのか）わからない

  • 方法不確実性

    • この製品を作れるのか（時間通りに作れるのか）わからない

アジャイル開発ではこの2つの不確実性を同時に（イテレーションの繰り返しの中で）減らしていく。


エンジニアリング組織論への招待より

案件の進め方

  • 効率的に（少ない費用で大きく）不確実性を減らしたい
  • プロジェクトのフォーカスはどちらなのか。不確実性が大きいのはどちらなのか

目的不確実性を減らすにはユーザからの何らかのフィードバックを得ないといけない
そのための方法は必ずしも実際にプロダクトを作ることだけでなく、LPを作って市場ニーズだけを把握するなど、いろいろな手法がある。

nabetsunabetsu

Running Leanとは

  • 成功したスタートアップの2/3が当初のプランを途中で大幅に変更している。
  • つまり、スタートアップが成功するのは最初のプランが優れていたからではなく、リソースを使い切る前にうまくいくプランを見つけたから。

スタートアップの難しさ(プロダクト開発の難しさ)

  • 古典的な製品中心の手法ではソフトウェアをリリースするまで顧客実証を行わない
  • 最初の要求段階で顧客にヒアリングをしてからソリューションを構築する間数ヶ月間顧客から離れてしまう（断絶がある）
nabetsunabetsu

ロードマップ

メタ原則

  1. プランAを文書化する
  2. プランで最もリスクの高い部分を見つける
  3. プランを体系的にテストする
  • ビジョンは理念や意義の形成に必要だが、リーンスタートアップでは信念ではなく事実でビジョンを裏付ける
  • 最初のビジョンはその大部分がテストされていない仮定や仮説に基づいており、Running Leanではこのビジョンを体系的にテストすることで、事実でビジョンを裏付ける

1. プランAを文書化する

最初のステップは頭の中にあるビジョンを言語化して、少なくとも一人の人間と共有すること。
前述の通りプランA(最初のアイデア)は間違っていると証明されることがよくあるため、従来の事業計画書より柔軟なものが必要。(テストしていない仮説に対して60ページもの事業計画書をわざわざ時間かけて書くのは時間の無駄)

具体的にはリーンキャンバスを活用する。


https://neoschronos.com/insights/how-to-create-your-business-model-lean-canvas-edition/

  • 高速性
    • 数週間かかる事業計画書と異なり半日もあれば複数のビジネスモデルの概要がかける
  • 簡潔性
    • シンプルに要点をまとめることができる（説明される側にとっても簡単に理解でき、また作るときにも製品の本質をまとめる練習にもなる）
  • 携帯性
    • 簡単に他者に共有が可能で、頻繁な更新も可能

あなたの「プロダクト」は「プロダクト」ではない

リーンキャンバスにおいてソリューションの面積は全体の1/9もない。

起業家はソリューションに夢中になるものだが、顧客が興味を持つのはソリューションではなく、自身の課題。
まずやるべきことはソリューションだけに注力するのではなく、ビジネスモデルの全体像を把握して、プロダクトを構成する各要素をうまくまとめること。

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

成功するプロダクトを構築するために必要なのは、リスクを緩和すること。

スタートアップの3つのステージ

スタートアップのステージとして大きく以下3つのステージに分けることができる


Stage: Becoming a Lean Startup Guru

  • 第一ステージ
    • 重要な質問
      • 解決に値する課題はあるか
    • 検討事項
      • それは顧客が必要としているものか(必要性)
      • 顧客はお金を支払ってくれるか。支払ってくれないのであれば誰が支払ってくれるか(成長性)
      • それは解決可能か(実現性)
    • 解決方法
      • 定性的な顧客観察とインタビュー


スタートアップ・フィット・ジャーニー　今どの段階にいて、何に取り組むべきかのガイド