新規事業とアジャイル(ダイジェスト版)

コーチングの一環で20分ほどセッションをしたときの資料です

1. 新規事業とアジャイル (ダイジェスト版) 2020/10/13 株式会社アトラクタ 吉羽龍太郎
2. 吉羽龍太郎 / Yoshiba Ryutaro クラウドコンピューティング、DevOps、インフラ構築自動化、アジャイル 開発、組織改革を中心にオンサイトでのコンサルティングとトレーニン グを提供。Scrum Alliance認定チームコーチ(CTC) / 認定スクラムプロ フェショナル(CSP) / 認定スクラムマスター(CSM) / 認定スクラムプロ ダクトオーナー(CSPO)。青山学院大学非常勤講師 3
3. 結論: 新規事業を進める場合のポイント ✤ 何が分からないのかすら分からないこともある。過度に詳細な計画にしない ✤ 適切な問題を扱っているか、顧客はいるかが重要 ✤ 顧客が関心を持つのは、自分の課題の解決であり、ソリューションそのものではない ✤ 仮説と検証の繰り返し ✤ 急いでたくさん作らない。機能の多さは成功につながらない ✤ 投資モデルを変える(100打数10安打1ホームランなら上等) ✤ アジャイルとはフィードバックサイクルの集合体 ✤ 最初から人が多すぎると無駄な仕事を生むのでスモールチームで進める 5
4. 問題の分類(クネビンフレームワーク) Created in 1999 by Dave Snowden 問題を把握するために試行錯誤(探 索)を行い、それによって状況を把握・ 理解する領域。そのあとに次の対応を 考えていく。この場合、うまくやる方法 はあとからわかることになる 正解が1つではないものの、比較的予測 しやすい領域。状況を専門家が分析して 理解し、取り得る手を検討して進めてい く。うまくやる方法は複数あるためそれを グッドプラクティスとして活用していく 革新的なことが求められる領域で正し い答えもわからないので、まず行動し てから理解していくしかない領域。既存 の知識が役に立たないこともある 正解が存在し変化の少ない領域。状況 を理解・分類し、ベストプラクティスに 基づいて進めていく 6
5. 問題の分類(クネビンフレームワーク) これまでの知識を 生かしにくい これまでの知識を 生かしやすい 問題を把握するために試行錯誤(探 索)を行い、それによって状況を把握・ 理解する領域。そのあとに次の対応を 考えていく。この場合、うまくやる方法 はあとからわかることになる 正解が1つではないものの、比較的予測 しやすい領域。状況を専門家が分析して 理解し、取り得る手を検討して進めてい く。うまくやる方法は複数あるためそれを グッドプラクティスとして活用していく 革新的なことが求められる領域で正し い答えもわからないので、まず行動し てから理解していくしかない領域。既存 の知識が役に立たないこともある 正解が存在し変化の少ない領域。状況 を理解・分類し、ベストプラクティスに 基づいて進めていく 7
6. 問題の分類(クネビンフレームワーク) 知識創造 知識整理 問題を把握するために試行錯誤(探 索)を行い、それによって状況を把握・ 理解する領域。そのあとに次の対応を 考えていく。この場合、うまくやる方法 はあとからわかることになる 正解が1つではないものの、比較的予測 しやすい領域。状況を専門家が分析して 理解し、取り得る手を検討して進めてい く。うまくやる方法は複数あるためそれを グッドプラクティスとして活用していく 革新的なことが求められる領域で正し い答えもわからないので、まず行動し てから理解していくしかない領域。既存 の知識が役に立たないこともある 正解が存在し変化の少ない領域。状況 を理解・分類し、ベストプラクティスに 基づいて進めていく 8
7. 問題の分類(クネビンフレームワーク) 知識創造を増やす 成功率を上げる 問題を把握するために試行錯誤(探 索)を行い、それによって状況を把握・ 理解する領域。そのあとに次の対応を 考えていく。この場合、うまくやる方法 はあとからわかることになる 正解が1つではないものの、比較的予測 しやすい領域。状況を専門家が分析して 理解し、取り得る手を検討して進めてい く。うまくやる方法は複数あるためそれを グッドプラクティスとして活用していく 革新的なことが求められる領域で正し い答えもわからないので、まず行動し てから理解していくしかない領域。既存 の知識が役に立たないこともある 正解が存在し変化の少ない領域。状況 を理解・分類し、ベストプラクティスに 基づいて進めていく 9
8. 問題の分類(クネビンフレームワーク) プロダクト プロジェクト 問題を把握するために試行錯誤(探 索)を行い、それによって状況を把握・ 理解する領域。そのあとに次の対応を 考えていく。この場合、うまくやる方法 はあとからわかることになる 正解が1つではないものの、比較的予測 しやすい領域。状況を専門家が分析して 理解し、取り得る手を検討して進めてい く。うまくやる方法は複数あるためそれを グッドプラクティスとして活用していく 革新的なことが求められる領域で正し い答えもわからないので、まず行動し てから理解していくしかない領域。既存 の知識が役に立たないこともある 正解が存在し変化の少ない領域。状況 を理解・分類し、ベストプラクティスに 基づいて進めていく 10
9. 問題の分類(クネビンフレームワーク) 低 予測可能性 高 予測可能性 問題を把握するために試行錯誤(探 索)を行い、それによって状況を把握・ 理解する領域。そのあとに次の対応を 考えていく。この場合、うまくやる方法 はあとからわかることになる 正解が1つではないものの、比較的予測 しやすい領域。状況を専門家が分析して 理解し、取り得る手を検討して進めてい く。うまくやる方法は複数あるためそれを グッドプラクティスとして活用していく 革新的なことが求められる領域で正し い答えもわからないので、まず行動し てから理解していくしかない領域。既存 の知識が役に立たないこともある 正解が存在し変化の少ない領域。状況 を理解・分類し、ベストプラクティスに 基づいて進めていく 11
10. 問題の分類(クネビンフレームワーク) アジャイル ウォーターフォール 問題を把握するために試行錯誤(探 索)を行い、それによって状況を把握・ 理解する領域。そのあとに次の対応を 考えていく。この場合、うまくやる方法 はあとからわかることになる 正解が1つではないものの、比較的予測 しやすい領域。状況を専門家が分析して 理解し、取り得る手を検討して進めてい く。うまくやる方法は複数あるためそれを グッドプラクティスとして活用していく 革新的なことが求められる領域で正し い答えもわからないので、まず行動し てから理解していくしかない領域。既存 の知識が役に立たないこともある 正解が存在し変化の少ない領域。状況 を理解・分類し、ベストプラクティスに 基づいて進めていく 12
11. 複雑な領域・カオスな領域で計画主導型プロセスを使うと? ✤ バッチサイズが大きすぎて、有効性が分からないムダなものをたくさん作ってしまう ✤ 計画を守ることが重視されて、変化のインセンティブがない。体制上も変化しにくい ✤ 作ったものにフィードバックできるタイミングが遅く、回数も少ない ✤ そもそもフィードバックしても取り入れられないこともある ✤ リスクは後半ほど顕在化するが、その時点で多額のお金を消費してしまっている ✤ 作っているものの有効性が検証できるまでにかかる金額と時間が大きすぎる ✤ 結果として、市場での競争優位性は得られない 13
12. 複雑な領域・カオスな領域で計画主導型プロセスを使うと? ✤ バッチサイズが大きすぎて、有効性が分からないムダなものをたくさん作ってしまう ✤ 計画を守ることが重視されて、変化のインセンティブがない。体制上も変化しにくい ✤ 作ったものにフィードバックできるタイミングが遅く、回数も少ない プロジェクトの完遂が最大の「目標」になってしまい、 ✤ そもそもフィードバックしても取り入れられないこともある 成果を後回しにしがち ✤ リスクは後半ほど顕在化するが、その時点で多額のお金を消費してしまっている ✤ 作っているものの有効性が検証できるまでにかかる金額と時間が大きすぎる ✤ 結果として、市場での競争優位性は得られない 14
13. 実際のところ新規ビジネスを成功させるのは難しい… ✤ 失敗の確率(スタートアップの場合) ✤ 投資がすべて水の泡になる => 30-40% ✤ 期待したROIを達成できなかった => 70-80% ✤ 宣言どおりの結果がでなかった => 90-95% 90%!? failure defined as return on investment Why Companies Fail--and How Their Founders Can Bounce Back (http://hbswk.hbs.edu/item/6591.html) 15
14. スタートアップ失敗の理由 ニーズがない 資金が尽きた 適切じゃないチーム 競合に負けた 価格・コスト 不親切な製品 ビジネスモデル欠如 稚拙なマーケティング 顧客無視 時期を逸した フォーカスの欠如 チームと投資家の不仲 ピボットが裏目 情熱の欠如 地理的拡大の失敗 投資家の関心が得られない 法律面での課題 ネットワークの未活用 燃え尽き ピボット失敗 23% 42% 29% 19% 18% 17% 17% 14% 14% 13% 最大の問題はニーズのないものを作ること 13% 13% 10% 9% 9% 8% 8% 8% https://www.cbinsights.com/research/startup-failure-reasons-top/ 8% 7% 0% 12.5% 25% 37.5% 50% 16
15. プロダクト価値の思い込み アイデアで盛り 上がる 思った通りの結 果がでない… なんとか頑張っ てリリース 作ろうとすると 課題が山積み ビジネス アイデアを考える 計画をたてる 技術 開発を行う なかったことに する ローンチ!! 年度末の報告 失敗したプロダクトを廃止できないと、人が分散してしまい、重要なところに集中できなくなる 17
16. 新規ビジネスビッグバン一発勝負で良いか? 収益 リリース 期間は長い 回収できるか分からない 時間 0 累積損失額(投資額) ? ? 最初に使うお金が大きい ? 18
17. 新規ビジネスビッグバン一発勝負で良いか? 収益 リリース 期間は長い 0 回収できるか分からない => ビジネスの作り方そのものを変えていく必要時間 累積損失額(投資額) ? ? 最初に使うお金が大きい ? 19
18. 新規ビジネスビッグバン一発勝負で良いか? 収益 リリース 期間は長い 0 回収できるか分からない => クラウドとアジャイルの適切な活用 累積損失額(投資額) 時間 ? ? 最初に使うお金が大きい ? 20
19. それでも失敗する
20. Amazonが撤退した(主な)事業 ✤ 1999→2000 アマゾン・オークションズ ✤ 2011→2015 アマゾン・ローカル ✤ 1999→2007 Zショップス ✤ 2011→2015 テストドライブ(アプリの購入前試用) ✤ 2004→2008 検索エンジンA9 ✤ 2012→2015 ミュージック・インポーター ✤ 2006→2013 アスクビル(Q&Aサイト) ✤ 2014→2015 ファイアフォン ✤ 2006→2015 アンボックス(TVや映画の購入・レンタル) ✤ 2014→2015 アマゾン・エレメンツ ✤ 2007→2012 エンドレス・ドットコム(靴とハンドバックのサイト) ✤ 2014→2015 アマゾン・ローカルレジスター(モバイル決済) ✤ 2007→2014 アマゾン・ウェブペイ(P2P送金) ✤ 2014→2015 アマゾン・ウォレット ✤ 2009→2012 ペイフレーズ(合言葉による決済) ✤ 2015→2015 アマゾン・デスティネーションズ(宿泊予約) ✤ 2010→2016 マイハビット(会員制タイムセール) ベイン・アンド・カンパニーによる分析 22
21. 失敗を受け入れる ✤ 「実験はその性質からしても失敗しやすいものですが、それでもやるべ きだと思います。何十回も失敗するかもしれませんが、一つ大きな成 功をすれば十分取り返せるのですから」 ✤ 「継続して実験を行わない会社や、失敗を許容しない会社は、最終的に は絶望的な状況に追い込まれます。(略)一方、常に賭け続けてむしろ賭 け金を引き上げていくような会社は、実は社運そのものを賭けるような ことはしないので、勝ち残ります」 ✤ 「失敗は、当社が他社と一線を画している分野だと思います。当社は、お そらく世界一失敗に適した場所です。(略)失敗と革新は対の関係にあ り、切り離すことはできません」 24
22. スタートアップのファネル ✤ CBINSIGHTSの調査結果 ✤ 米国に本社を置く、2008〜2010年のいずれかに 最初のシード資金を調達したハイテク企業を 2018年8月31日まで追跡調査 ✤ シードから次のラウンドに進んだのが48% ✤ ユニコーンになったのは1% https://www.cbinsights.com/research/venture-capital-funnel-2/ 25
23. 新規事業への投資の仕方を変える ラウンド名 シード アーリー 概要 おおよその金額感 起業前。アイデア段階 1千万円以下 起業直後。解決すべき問題を定めてプロトタイプやMVPを用意 5千万円以下 シリーズA ビジネスモデルを確立していく 数千万円〜数億円 シリーズB ビジネスを拡大していく 数億円〜十億 シリーズC 企業の拡大(IPAやM&A) 数億円〜数十億 ※投資家によってラウンド名や金額には相違がある 26
24. プロダクト開発の流れ 問題を設定しなおす ① 解決したい問題を 見つける 繰り返す ② 問題とソリューション の仮説を評価する ③ ソリューションを 作る ④ ソリューションを 評価する ⑤ スケールする 繰り返す ソリューションを設定しなおす デザイン思考など リーンスタートアップなど アジャイル開発 少人数 安価 大人数 高価 27
25. 注力しがちな領域(間違い) 問題を設定しなおす ① 解決したい問題を 見つける 繰り返す ② 問題とソリューション の仮説を評価する 注力しがちな領域 ③ ソリューションを 作る ④ ソリューションを 評価する ⑤ スケールする 繰り返す ソリューションを設定しなおす デザイン思考など リーンスタートアップなど アジャイル開発 少人数 安価 大人数 高価 28
26. 機能が多くても使われないという事実 ✤ いつも使う 7% よく使う 16% たまに使う 13% 米国スタンディッシュグループの調査 ✤ まったく使わない 45% ほとんど使わない 19% 2002年実施 ✤ 64%の機能はほとんど、もしくはまったく使 われない ✤ 一方でiPhone発売時にはテキストのコピー ペースト機能すらなかった ✤ 機能が増えると顧客満足度が下がるという 調査結果もある ✤ 使われること自体は品質の1つ 29
27. 本当に重要なのはどこ? 問題を設定しなおす ① 解決したい問題を 見つける 繰り返す ② 問題とソリューション の仮説を評価する ③ ソリューションを 作る ④ ソリューションを 評価する ⑤ スケールする 繰り返す ソリューションを設定しなおす デザイン思考など リーンスタートアップなど アジャイル開発 少人数 安価 大人数 高価 30
28. 思い込みで(大規模に)作らない
29. うまくたくさん作ることが最重要なわけではない ✤ Outcome (成果)やImpact(インパクト)の方が重要 ✤ 成果と生産性を比べてみると (生産性 = 生産量 / 投下時間 つまりベロシティ) ✤ ✤ 成果はでないが生産性は高い = ゴミの高速生産 ✤ 成果はでてるが生産性は低い = なにか問題でも? ✤ 成果はでてないし生産性も低い = つらい人生… もっとチーム全体が成果とインパクトにフォーカスする必要性 32
30. フィードバックループを素早く回し続ける
31. アジャイルとはフィードバックサイクルの集合体 1〜4週間 1〜4週間 1〜4週間 1〜4週間 1〜4週間 ✤ 大事だと思う要求から順番に実現していく(ときには不要なものを削除する) ✤ 作る(Build)、測定する(Measure)、学習する(Learn)の繰り返し ✤ 何が今やるべき大事なことなのかビジネス側は優先順位判断をし続ける(ビジネス側の継続的関与) ✤ 要求の中身も優先順位もすべて変化する可能性があり、それに対応する 34
32. アジャイルとはフィードバックサイクルの集合体 つまり1度作ったら終わりではなく、ずっと変わり続ける 1〜4週間 1〜4週間 1〜4週間 1〜4週間 1〜4週間 ✤ 大事だと思う要求から順番に実現していく(ときには不要なものを削除する) ✤ 作る(Build)、測定する(Measure)、学習する(Learn)の繰り返し ✤ 何が今やるべき大事なことなのかビジネス側は優先順位判断をし続ける(ビジネス側の継続的関与) ✤ 要求の中身も優先順位もすべて変化する可能性があり、それに対応する 35
33. メンローイノベーション社でのア ジャイル開発の様子
34. Hunter社でのアジャイル 開発の様子
35. クロスファンクショナルで持続するスモールチーム ✤ 運搬のムダ、手待ちのムダを避けるために、スモールチームですべてのことを行う。チームは長く維持する ✤ これによって待ち時間が減り、素早い対応が可能になる。チームの能力は継続的に向上する ✤ すなわち複雑で変化が激しい領域で戦うには、内製化が必須といえる ✤ 持続するチームであるがゆえに能力の底上げに定常的に時間を使える(道場、ペア作業、研修など) 38
36. アジャイルではマネージャーの役割が変化する 39
37. 従来型とアジャイル型の価値観の違い 予測型プロセス 経験型プロセス プロジェクトの成功率 高くしたい 高くなくてもいい プロダクトの収益 スコープ外 高くしたい ポートフォリオの成功率 スコープ外 高くしたい リードタイム 長くても良い 短くする 既存プラクティスの適用 適用する 適用性を検証する 新規プラクティスの適用 避ける 適用性を検証する フィードバックサイクル ない場合もある 短くしたい 40
38. 結論: 新規事業を進める場合のポイント ✤ 何が分からないのかすら分からないこともある。過度に詳細な計画にしない ✤ 適切な問題を扱っているか、顧客はいるかが重要 ✤ 顧客が関心を持つのは、自分の課題の解決であり、ソリューションそのものではない ✤ 仮説と検証の繰り返し ✤ 急いでたくさん作らない。機能の多さは成功につながらない ✤ 投資モデルを変える(100打数10安打1ホームランなら上等) ✤ アジャイルとはフィードバックサイクルの集合体 ✤ 最初から人が多すぎると無駄な仕事を生むのでスモールチームで進める 41
No comments...
Attractor Inc. Founder / CTO / Agile Coach / Certified Team Coach / Certified Scrum Professional / Certified ScrumMaster / Certified Scrum Product Owner Twitter : @ryuzee Web : https://www.attractor.co.jp/ Web : http://www.ryuzee.com/

Related Slides