GMOテクノロジーブートキャンプ2015(アジャイル編)

GTB2015 アジャイルとか 2015年5月15日 ＧＭＯインターネット株式会社 次世代システム研究室 藤村 新 1

自己紹介 2

藤村 新 ふじむら あらた アジャイルPM研究会所属

伝えたいこと 1.夢や実現したいこ とを言葉に出そう 2.自己投資しよう 3.まずは行動しよう

マリッサ・メイヤーに会いたい

2015年の近況報告 6

1/1～5 カンボジア 7

2/25 ザッパラス社セミナー • リーンスタートアップについて • アジャイル開発について • スクラムについて 8

2/28 Regional Scrum Gathering Tokyo 2015 • 開発モデルの作り方 ～守破離の破！～ 9

3/19 PMI日本支部法人スポンサー連絡会 • アジャイルPMに関する意見交換会 10

4/16 Agile Japan 2015 • アジャイルなオフショア開発 11

5/29-30 Regional Scrum Gathering Vietnam 2015 • 参加予定(自費) 12

伝えたいこと(2回目) 自己投資しよう 13

伝えたいこと アウトプットしよう 14

アジャイルなオフショア開発という テーマで社内発表(2014/9/29) 15

スライドをアップロード 16

フィードバック 17

楽天 Tech Talk 18

オフショア大學 19

私がやりたい事 20

＋ 正しく続ける 21

 正しいものを(プロダクトディスカバリーフェーズ)  デザイン思考  顧客開発モデル  リーンスタートアップ  ビジネスモデルキャンバス(リーンキャンバス)  ユーザーエクスペリエンス(カスタマージャーニー)マップ  ユーザーストーリーマッピング  インセプションデッキ 22

 正しくつくり(開発フェーズ)  アジャイル開発  スクラム  XP  ドメイン駆動設計  正しく続ける(運用フェーズ)  リーン開発  継続的デリバリー(CD)  今時インフラ  インフラCI  Immutable Infrastructure 23

ところで先週… 24

＿人人人人人人人人人人人人人＿ ＞ 突然の自己組織化ゲーム ＜ ￣Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y￣

1.リーダーを1人決めてください(リー ダー以外はメンバーです) 2.リーダーは1人のメンバーから生年月 日を聞いて、メンバーが生年月日順 に並ぶように誘導してください 3.残りのメンバーでも同じことをしてく ださい

何分かかりましたか？

1.リーダーはいません。全員がメン バーです 2.メンバー同士が協調して、プログ ラミング経験年数順に並んでくだ さい

何分かかりましたか？

自分のチーム、覚えてますか？

伝えたいこと 自己組織化しよう 31

伝えたいこと HRT重要 32

Humility Respect Trust

伝えたいこと 一番の下手くそでいよう (Be the Worst) 35

休憩 https://www.flickr.com/photos/emiliokuffer/8359208711/ 37

ワークショップ ピンポンゲーム 38

■ルール  チーム全員が1つのピンポンボールに触れると1ポイント  ボールの受け渡しは一度ボールが宙に浮く必要がある(手渡禁止)  単位時間(120秒)でのスコアが高いチームが勝ち ■ステップ 1) 戦略を考えてスコアを見積もる(60秒) 2) 実行する(120秒) 3) スコアを計測して報告(60秒) 4) ふりかえり(60秒) 5) 1に戻る(5回実施します) 39

アジャイル開発概要 40

アジャイルの歴史 2001年から始まった アジャイルの傘 アジャイルはもともと存 在した方法論を包括する 言葉 スクラムは1995年 価値や原則を包容する 方法論やアプローチならば、 すべてアジャイル 41

アジャイルマニュフェスト  プロセスやツールよりも個人と対話を  包括的なドキュメントよりも動くソフトウェアを  契約交渉よりも顧客との協調を  計画に従うことよりも変化への対応を 42

アジャイルマニュフェスト 左記も重要 左記のことがらに価値があることを認めながらも、 私たちは右記のことがらにより価値をおく。 43

アジャイルマニュフェスト(2.0)  プロセスやツールよりも個人と対話を ➡個人と対話よりもチームのビジョンと規律を  包括的なドキュメントよりも動くソフトウェアを ➡動くソフトウェアよりも有効で妥当な学習を  契約交渉よりも顧客との協調を ➡顧客との協調よりも顧客の開拓を  計画に従うことよりも変化への対応を ➡変化への対応よりも変化の提案を 44

アジャイルマニュフェスト(2.0)  Kent Beck(2010年)  XP, デザインパターン, TDD, Junit, …  署名は行われていない  何が変わったか  個人 ➡ チーム  手段 ➡ 目的  何をすべきか ➡ なぜすべきか 45

アジャイルの原則  変動制と不確実性  役立つ変動性を受け入れよ  イテレーティブでインクリメンタルな開発を採用せよ  検査、適用、透明性を通じて変動性を活用せよ  あらゆる形の不確実性を同時に削除せよ  目的の不確実性(What)  手段の不確実性(How)  顧客の不確実性(Who) 46

アジャイルの原則 インクリメンタル イテレーティブ http://www.agileproductdesign.com/downloads/patton_incremental_releases_handouts.pdf 47

 予見と適応  選択肢を広げておく  最終責任時点を可能な限り先延ばしにする  事前に正しく行なうことは不可能だと認める  適応型で探索型のアプローチを好む  リーン・スタートアップ的なアプローチ  経済的に妥当なやり方で変化を受け入れる  初期に予見し過ぎない  予見的な事前の作業と適応型のジャストインタイムの作業とのバ ランスを取る  事前の予見を最小化する 48

 検証による学び  重要な想定をまず検証する   重要な想定の数を最小化する  複数の学習ループ(1日単位、スプリント単位など)を平行して活用する  すばやいフィードバックのためのワークフローをまとめる 仕掛中の作業(WIP)  作業は経済的に妥当なサイズにまとめよ  バッチサイズは1に近づける  在庫(WIP)を認識し、適切な流れで管理せよ  作業者の手待ち(キャパシティ)ではなく、作業の手待ち(実施したいのに何らかの原因 でできていない作業)に注目せよ   リレーにおいて、走者ではなくバトンを見ろ 遅延コストを考慮せよ  作業の手待ちの方が高くつく 49

 進捗  リアルタイムの情報に適応して再計画せよ   動作する資産を検証することで進捗を測れ   顧客にとって価値のある作業を終わらせたかどうかが重要 価値に主眼を置いたデリバリーに集中せよ   計画に従うことが目的ではない 顧客は価値の高いフィーチャーから順に継続的に受け取れる 作業効率  すばやく進め、しかし、あわてるな  持続可能なペース  品質を作り込め  必要最低限の儀式を行え  必要なドキュメントは書く エッセンシャルスクラム 図3.2より抜粋 50

クネビンフレームワーク シンプル 対象の問題を誰が見てもすぐに理 解できる うまくやる方法をベストプラクティス として利用できる プロセスは不要 煩雑 対象の問題を理解するには、専門 知識と作業が必要 うまくやる方法は複数あるので、そ れらをグッドプラクティスとして活用で きる WF, PMBOK 51

クネビンフレームワーク 複雑 対象の問題を理解するには、観察 するだけでは無理で、探査が必要 対象がどんな反応をするかを確か めつつ、次の対応を考える。 プラクティスは出現する アジャイル カオス 対象を理解する事も難しい まったく新しいプラクティスを考えな ければならない 既存の知識は役に立たない プロセスは無く、まず行動する 52

まとめ 53

• アジャイル開発の歴史は古い • 時代に合わせて解釈も変わってきている • アジャイルの原則を理解する • 計画駆動(WF)の原則との違いで考える • アジャイル開発が適するのは対象が複雑な 場合のみ • 適さないケースもある 54

リーン開発のカンバン 55

リーン開発のカンバンについて • 次研で一番活用されているのはカンバン • アジャイルなオフショア開発もカンバン • カンバンはアジャイルソフトウェア開発におけるリーンな アプローチ • XPとスクラムは、イテレーションやスプリントと呼ばれ る「期間」を区切ってチーム内に存在する在庫を制 限するリーン手法 • カンバンは「WIP」(仕掛り)を直接制限するリーン手 法 • 両者とも、ソフトウェアのモジュールではなく顧客の 目でわかる機能ごとに開発を行い、「ふりかえり」と いう活動を通じて、現場のチームで改善活動を行う。 ※「リーン開発の現場」 p.183 から抜粋 56

• リーンという言葉は、TPS(トヨタ生産方式)が源流 • TPSの考え方は、リーン(ムダがない)というコンセプトで生 産方式を超えて抽象化され、さまざまな分野に適用された • リーン製品開発 • リーン・コンストラクション (建築) • リーン・サービス (サービス産業) • リーン・ソフトウェア開発 (アジャイル開発) http://www.atmarkit.co.jp/ait/articles/1311/15/news015_3.html 59

• 3つのムダを無くす(リーン) • 間違ったものを作るというムダ • 「しなくてもいいことを効率的 にやってもムダである」 • 学び損ねるというムダ • 過度な作業切り替えによるムダ 60

昼休憩 https://www.flickr.com/photos/emiliokuffer/8359208711/ 61

ワークショップ 美味しいラーメンの作り方 62

私からのお願い。 「美味しいラーメンを作ってください」 ※チームで作業をしてください 1. 美味しいラーメンを作るために必要な作業を洗い出し、付箋に 書き出してください(5分) 2. 作業順に付箋を並べてください(5分) 3. チーム毎に発表してください(1分×6チーム) 63

スクラム概要 64

スクラムとは 軽量 理解が容易 習得は困難

全てのルールは スクラムガイドに 書いてある 66

スクラムプラクティス ■役割 ■アクティビティ  プロダクトオーナー(1人)  スプリント(１～４週間)  スクラムマスター  スプリントプランニング(2～8時間)  開発チーム(３～９人)  デイリースクラム(15分)  スプリントレビュー(1～4時間)  レトロスペクティブ(1~3時間)  プロダクトバックログリファインメント ■作成物  プロダクトバックログ  スプリントバックログ  プロダクトインクリメント (作業時間の10%以下) 68

役割  プロダクトオーナー  開発において行う投資に対する効果(ROI)を最大にすることに責任を持つ  バックログへの追加、削除、順位付けの最終的な責任を持つ  開発チームに機能を説明して理解してもらう責任がある  一人の人間が担当し、委員会のような合議制の体制にしてはいけない  開発チーム  3名以上、9名以下でないと効果が出にくい(7±2とも言われている)  実際に開発を行うチーム  職能横断的に様々な技能を持った人が集まり、自律的に行動する   自己組織化されたチーム 製品の価値を高めることに責任を持つ 71

役割  スクラムマスター  スクラムチーム全体が自律的に協働できるように場作りをする    開発チームが抱えている問題を取り除くために何でもやる  コーチとしてメンバーの相談に乗る  外部の割込みから守る  チームの障害を取り除くために外部との交渉を行う プロダクトオーナーを支援する   ファシリテーター的な役割 製品のビジョン作りやバックログ管理など サーバントリーダー 72

作成物  プロダクトバックログ  製品へ追加する機能(要求)のリスト。  ユーザーの価値で書かれている必要がある  ユーザーストーリー形式  優先順位順に並んでいる必要がある  プロダクトオーナーが管理する  スプリントバックログ  プロダクトバックログから抜き出された、今回のスプリントで追加する機能の リスト  スプリント計画でプロダクトオーナーの決めた順位と開発チームが決めた見 積もりの両方の情報を併せて抜き出される  一回のスプリントにだけ使用される 74

作成物  プロダクトインクリメント  一回のスプリントの成果であり、スプリントで完了した製品の機能  スプリントの終わりにはインクリメントが動く状態である必要がある  インクリメントは、「出荷判断可能ソフトウェア」の必要がある  プロダクトオーナーがレビューして、実際に製品をリリースするかどうか を決定する 75

アクティビティ  スプリント  反復(イテレーション)の単位  スプリントは1～4週間の時間枠(タイムボックス)  予定されている機能が完成できなくても延長されることはない  期間内で開発チームは「スプリントバックログ」の開発に集中し、動作する 製品(インクリメント)を作り出す  スプリントプランニング  スプリントの開始に先立って行われるミーティング  「プロダクトバックログ」から今回のスプリントで扱う「スプリントバックログ」を 抜き出して決定する。  その後開発チームが計画を詳細化し、タスクにまで分割する  開発チームのコミットメントが重要 77

アクティビティ  デイリースクラム(朝会)  メンバーは一人ずつ、「昨日やった事」、「今日やる事」、「困っている事」を 順に話す  上長への報告にならないように注意する  開発チームのコミットメントが重要(今日やる事)  15分で打ち切る  別途話し合いが必要な場合は朝会終了後に関係者のみで話す  スプリントレビュー  スプリントの終了時、関係者を呼び集めてできあがった製品のデモを行う  開発チームはプロダクトオーナーやステークホルダーからのフィードバックを もらうことが重要 78

アクティビティ  レトロスペクティブ(ふりかえり)  このスプリントでうまくいったこと、うまくいかなかったこと、どうやったら次 のスプリントでよりうまくできるかを話し合う  KPT2(Keep, Problem, Try, To Do)形式で行われることが多い  「検査と適応」の機会となり、チーム学習、チーム改善の活動となる  プロダクトバックログリファインメント  「PBIの作成と改良(詳細の追加) 」、「PBIの見積もり」、「PBIの優先順位 付け」の3つのアクティビティの総称   プロダクトオーナー主導で行う共同作業  内外のステークホルダー、スクラムマスター、開発チーム  最終決断を下すのは、プロダクトオーナーの役割 デイリースクラムの後、スプリントレビュー中や、スプリント中に行う 79

まとめ 81

• 全てのルールはスクラムガイドに書いてある • "スクラムの一部だけを導入することも可能だが、それはスクラムとは 言えない。" • • スクラム風 "すべてをまとめたものがスクラムであり、その他の技法・方法論・プ ラクティスのコンテナとして機能する。" • • XPとのハイブリッドが一般的 読むべき書籍 • アジャイルサムライ • アジャイルな見積りと計画づくり(読書会やってます！) • スクラム実践入門 • エッセンシャルスクラム 82

守破離とは 83

CSM研修で学んだ守破離 • 守 - ルールに従え - どうやるかを見て練習を繰り返す • 破 - 工夫してみる - 原因と結果をつなげる実験 • 離 - ルールを忘れろ - 新しい技術を一瞬で考えて使える段階 84

スクラムにおける守破離 • 息をするようにスクラムのルールを行えるようにな るまでが守 • スクラムのルールに従った上でアレンジしてみるの が破 85

守破離の語源 86

• 元々は武田信玄に仕えた武将、高坂昌 信(こうさかまさのぶ)の『甲陽軍鑑(こう ようぐんかん) 』に記された兵法用語 87

• その後千利休が詠んだ(らしい) • 「規矩(きく)作法 守りつくして 破ると も 離るるとても 本(もと)を忘るな」 • 『利休百首』 88

• そして千利休の茶道の修行観 を、後世の川上不白(かわか みふはく)が表現した • • 「守ハマモル、破ハヤブル、 離ハはなると申候。 弟子ニ敎ルハ此守 と申所計也。弟子守ヲ習盡 し能成候へバ自然と自身よりヤブル。これ上手 の段なり、さて、守るにても片輪、破るにても片 輪、この二つを離れて名人なり、前の二つを合 して離れてしかも二つを守ること也。 」 • 『不白筆記』 「守破離といふ事軍法用、尤用方違ひ候へ共、 茶道に取て申候はば、守は下手〈略〉破は上手 〈略〉離は名人」 • 横井淡所の『茶話抄』への添え書き 89

守破離とは 「道」 の指針 90

俺の守破離 91

とりあえずやってみた (お試しフェーズ) 92

• 「アジャイルサムライ」と「アジャイルな見積りと計画 づくり」を読んだだけで、ソシャゲプロジェクトへア ジャイル開発初導入！ - アジャイル開発を体感できた - 自分が分かっていないということが分かった 93

• 「スクラムガイド」と「塹壕よりScrumとXP」を読んだ だけで、ECツール開発プロジェクトへスクラム"風" 初導入！ - スクラムを体感できた - プラクティス厨じゃダメだということが分かった 94

プロセスの理解 ≠ スキル習得 95

本格的に学びたい (守フェーズ) 96

PMIアジャイルPM研究会立ち上げプロジェクト参画

マスター・ センセイ との 出会い 98

CSPO研修受講  日時：2013年5月20日～21日  場所：株式会社ミクシィ  講師：ジェフ・パットン 99

プロダクトディスカバリを行なって、 プロダクトバックログを作るまでを 学んだ。 ※スクラム開始前のフェーズ ※デザイン思考の話し 100

CSM研修受講  日時：2013年6月20日～21日  場所：ビジョンセンター日本橋  講師：江端一将、Sergey 101

スクラムの基礎を 座学とワークショップ を通して学んだ。 102

• 勉強会、ワークショップ、イベントに参加 • アジャイルサムライ横浜道場 • POStudy • レゴスクラム(見学) • AEP読書会 • Scrum Masters Night • Agile Japan 2014 • Regional Scrum Gathering Tokyo 2014 103

アウトプット！ アウトプット！ アウトプット！ 104

• • 担当プロジェクトへ各種プラクティス導入 • リーンカンバン、WIP • 朝会、ふりかえり、計画MTG グループ会社への導入支援 • • • インセプションデッキ 導入事例を書く、話す • 採用ブログに書く • 自社、他社に話す 部署内での啓蒙活動 • アジャイルな見積もりと計画づくりまとめ • アジャイル開発取り組み状況 105

第1回アジャイルミーティング主催  日時：2013年10月9日  場所：GMO Yours  内容 1. PMIアジャイルPM研究会立ち上げプロジェクトの紹介 2. 次世代システム研究室 3. GMOリサーチ 4. GMO ECラボ 5. GMOペパボ 6. 交流会 106

107

• 次世代システム研究室では GMOベトナムラボセン ター(ベトナム/ハノイ)と密接に連携しながらGMO インターネットグループのシステム開発(オフショア 開発)に取り組んでいたが、必ずしもうまくいってい るとは言えない状況だった • オフショア開発プロセス改善に取り組むことになっ たため、国内プロジェクトで実践していた各種プラ クティスを導入するも問題多発 108

試行錯誤を重ね 辿り着いた 破 の境地 109

頑張っても 効果が薄い事を 諦めてみた

111

これら改善施策を 盛り込んだ 開発モデルを 考えてみた。

Rough Fill Closing

ベースは リーン開発の カンバン

Rough Fill Closing

• ザックリ開発するフェーズ • 7割程度の完成度を目指す • 着手する前にザックリ開発工数を見積もっても らう 119

Rough Fill Closing

• Roughフェーズでのアウトプットの完成度を上げ るフェーズ • 9割以上の完成度を目指す 121

Rough Fill Closing

• 完成させるフェーズ • 日本側の発注者(エンジニア)が対応する 123

開発モデルを作るということ 124

開発モデルを作ること ≒ 破のフェーズ 125

破＞＞＞＞＞＞＞ ＞超えられない壁＞ ＞＞＞＞＞＞＞＞ ＞＞＞＞＞自己流 126

形を持つ人 だけが、 形を破れる 127

• 十八代目 中村 勘三郎が19の時、唐十郎の巨 大テントで「下町唐座」を見たときのこと なんだこれは！？ 自分がやっている歌舞伎座での 落ち着いた空気とは全く違うじゃ ないか！ でも待てよ、昔の歌舞伎はこう だったのでは？ 128

• 早速親父(十七代目 中村 勘三郎)に直訴 これこそ歌舞伎の原点だ。 歌舞伎もこれに戻らなきゃいけない。 俺もあのような歌舞伎がしたい。 百年早い。 そんなことを考えてる間に百回稽古 しろ。 129

• なんで親父は分かってくれないんだ！ • そんなモヤモヤしてた折、たまたまラジオから流 れてきた全国子供電話相談室での無着成恭(禅 宗の僧侶、教育者)の回答を耳にする 型破りと形無しの違いはなんですか？ そりゃあんた、型がある人間が型を 破ると『型破り』、型がない人間が型 を破ったら『形無し』ですよ。 130

• 父の言う「百年早い」の意味が分かった 古典をしっかり学んで自分の形を作 れ。 19や20の未熟者が土台もないのに 新しいことをやるな。 • 2000年(45才)に平成中村座を上演 131

形無し開発モデルは 百害あって一利なし。 型破り開発モデルを 編み出そう！ 132

楽天 Tech Talkでの発表後、 133

134

• 同時に、あ、こういうモデルを考えだすのって、そんなご大層なも のじゃないんだとか思った • こんなん自分でも考えられるぜ！って言いたいのではなくて超 頭いい人が美しい理論のもとに弾きだした答えではなく、僕の ような普通の人が苦しみ苦しみ抜いてその時々考えたことを 集めて体系化したという意味でなんだかすごい身近に感じた。 • というか、今自分のチームでも自分たちなりのKAIZENをいろ いろしてるし、それをまとめればそれだけでひとつのモデルに なるなー http://daily.belltail.jp/?p=1880 135

そうなんです！ 136

新しい開発モデル を考えるなんて 大層なものじゃない んです！ (※ただし守済に限る) 137

現場のカイゼンを 体系化して言語化 すれば、それも立派 な開発モデル。 (※ただし守済に限る) 138

ぜひこの事を話したいと思い 今回の公募セッションに 応募しました。 おさかなさんありがとう。 ※新卒1年目の方でした… 139

まとめ 140

• まずはしっかりと型を学ぼう(守) • 型をしっかりと身に付けた上で、 現場の改善に取り組もう(破) • 取り組んだ内容を体系化し、開発 モデルとしてアウトプットしよう 141

• 個人的には、試守破離がオススメ • 試したからこそ守破離の大切さ を痛感させられた 142

休憩 https://www.flickr.com/photos/brian_tomlinson/14678017291/ 143

ワークショップ コインゲーム 144

■ルール  利き腕と逆の手を使う  1枚ずつコインを全て裏返す  1人が最初の山と同じ状態にしたら、次の人が作業に入れる ■ステップ 1) 戦略を考えて作業時間を見積もる(60秒) 2) 見積もりを報告 3) 作業時間を計測する 4) 作業時間を報告 5) ふりかえり(60秒) 6) 1に戻る(5回実施します) 145

新企画、新機能開発の進め方 146

http://www.slideshare.net/papanda/ss-31975018/55 147

http://www.slideshare.net/papanda/ss-31975018/56 148

http://www.slideshare.net/papanda/ss-31975018/57 149

http://www.slideshare.net/papanda/ss-31975018/58 150

http://www.slideshare.net/papanda/ss-31975018/59 151

休憩 https://www.flickr.com/photos/emiliokuffer/8359208711/ 152

リーンスタートアップとは 153

リーン・スタートアップについて • 今回お話しする内容は、主にRunning Lean • Running Leanは複数の方法論の組み合わせ • リーン・スタートアップ • エリック・リース • 顧客開発＋アジャイル開発＋リーン手法 • 顧客開発 • スティーブ・ブランク • 「アントレプレナーの教科書」 • 建物の外に出よ。 • ブートストラッピング • ビジョイ・ゴスワミ • 顧客からの収益で資金をまかなう 154

• Running Leanの本質は、3つの手順に分けられる 1. プランAを文章化する 2. プランで最もリスクの高い部分を見つける 3. プランを体系的にテストする ※RUNNING LEAN 2nd Edition P.165 Figure 14-2 から転載 155

手順1.プランAを文章化する • 顧客を考えるフェーズ • リーン・キャンバスを書く • 最初は1枚のキャンバスにまとめる • その後、顧客セグメントごとにリーン・ キャンバスを書く • まずは一気に書く(15分以内) • 空欄があっても良い • 簡潔に書く • 今分かる範囲で書く 156

リーン・キャンバス ※RUNNING LEAN 2nd Edition P.27 Figure 3-1 から転載

手順2.プランで最もリスクの高い部分を見つける • リーン・キャンバスを順番に並べて、どのビジネスモ デルから手を付けるかを決めるフェーズ • 最も大きなリスクは、誰も欲しくないものを作ること • リスクはステージによって決まる • スタートアップには3つのステージがある 課題/解決フィット 製品/市場フィット 拡大 ※RUNNING LEAN 2nd Edition P.8 Figure 1-3 から転載 158

リーン・スタートアップについて 第1ステージ：課題/解決フィット(P/S Fit) • 解決に値する課題はあるか？ • アイデアは安くても、それに取り組むコストは高い • それは顧客が必要としているものですか？(必 要性) • 顧客はお金を支払ってくれますか？支払ってくれ ないのであれば、誰が支払ってくれますか？(成 長性) • それは解決可能ですか？(実現性) 159

リーン・スタートアップについて 第2ステージ：製品/市場フィット(P/M Fit) • 誰かに必要とされるものを構築したか？ • そのソリューションがどれだけ課題を解決しているか をテストする • 定性的に検証する • 定量的に検証する 第3ステージ：拡大(Scale) • どうやって成長を加速させるのか？ 160

リーン・スタートアップについて • リスクは3つのカテゴリに分けられる • 製品リスク(P) • 顧客リスク(C) • 市場リスク(M) ※RUNNING LEAN 2nd Edition P.50 Figure 4-1 から転載 161

リーン・スタートアップについて 手順3.プランを体系的にテストする • 検証による学習ループ(実験)を行うフェーズ 1. アイデアや仮説を用意 2. 仮説をテストする製品を構築 3. 製品を顧客に提示して、反応を定性的、定量的 に計測 4. このデータを仮設の検証、反証の学習に使う 5. 再び構築に戻る

BMLループ

ステージ＼リスク 課題を 理解する 第1ステージ 課題/解決 フィット (P/S Fit) ソリューション を決定する 第2ステージ 製品/市場 フィット (P/M Fit) 定性的に 検証する 定量的に 検証する 製品リスク(P) 顧客リスク(C) 市場リスク(M) 解決に値する課題 かどうかを確認する 不満を持っている 人を特定する 既存の代替品から 競合他社を特定し、 ソリューションの価 格を設定する 最小限のソリュー ション(MVP)を決定 する 製品を今すぐに欲 しいと思うアーリー アダプターに範囲 を狭める 顧客の声を聞いて、 価格をテストする (口約束) MVPを構築して、小 規模に検証する (UVPのデモ) アウトバウンドチャ ネルから開始して も構わない 顧客の行動を見て、 価格をテストする 大規模に検証する 少しずつ拡大可能 なインバウンドチャ ネルも構築/開発 する ビジネスモデルが うまくいくように、 コスト構造を最適 化する

ステージ(イテレーション)毎に実際にやること 1. 課題を理解する • 見込み客を見つける • 課題インタビュー • 学習すべきこと • 製品リスク：何を解決するのか？(課 題) • 市場リスク：競合は誰なのか？(既存 の代替品) • 顧客リスク：誰が困っているのか？ (顧客セグメント)

ステージ(イテレーション)毎に実際にやること 2. ソリューションを決定する • デモを構築する • ソリューションインタビュー • 学習すべきこと • 顧客リスク：誰が困っているのか？(アー リーアダプター) • 製品リスク：課題をどのように解決するの か？(ソリューション) • 市場リスク：どのような価格モデルにする のか？(収益の流れ) • MVPを構築する

ステージ(イテレーション)毎に実際にやること 3. 定性的に検証する • ダッシュボードを構築する • MVPインタビュー • 学習すべきこと • 製品リスク：製品の魅力は何か？(独自の 価値提案) • 顧客リスク：十分な顧客はいるか？(チャネ ル) • 市場リスク：価格は適正か？(収益の流 れ) • UVPを実現する • 顧客ライフサイクルを検証する

ステージ(イテレーション)毎に実際にやること 4. 定量的に検証する • 機能を制限する • 追加機能は独自の価値提案(UVP)を薄める • 進捗を計測する • 初期のトラクションを達成する • ユーザーの40%が定着 • ショーン・エリスのテストを通過 • 製品が使えなくなった時残念に思うか？ • 成長エンジンを特定する • 粘着型：高い定着率 • ウィルス型：高い紹介率 • 支出型：高い利益率

なぜ導入したいのか？ • 作ってみなくても分かることは多々ある • やみくもに作らない • 作らずに検証できないか考える • 作る場合でもMVPを意識する • ケチな考えを持つ • 自分のお金でも作りますか？ • 課題ありき、顧客ありきで考える • ソリューションありきでは無い 169

休憩 https://www.flickr.com/photos/emiliokuffer/8359208711/ 170

ワークショップ リーンキャンバス 171

http://www.slideshare.net/papanda/ss-31975018/55 172

リーン・キャンバス ※RUNNING LEAN 2nd Edition P.27 Figure 3-1 から転載

書いてみよう(個人) • テーマは以下の3大欲求から選択 • 英語 • ダイエット • お金 • 1～5の順に書いてみる 1. 課題 • 既存の代替品 2. 顧客 • アーリーアダプター 3. 独自の価値提案 • ハイレベルコンセプト 4. ソリューション 5. 圧倒的な優位性 174

ワークショップ インセプションデッキ 175

http://www.slideshare.net/papanda/ss-31975018/58 176

インセプションデッキ • 10の手強い質問と課題から構成されている • 関係者全員の認識を合わせるために実施 • テンプレート • https://github.com/agile-samuraija/support/tree/master/blankinception-deck 177

• https://github.com/agile-samurai-

インセプションデッキ  背後にある考え  「しかるべき人をみんな同じ部屋に集めて、プロ ジェクトにまつわる適切な質問をすれば、自分た ちのプロジェクトに対する期待を共有して、認識 を合わせることができるはずだ」  作成にあたっては、ステークホルダーを巻き込むこ とがとても重要 178

我々はなぜここにいるのか? • 大事な理由 #1 • 大事な理由 #2 • 大事な理由 #3 このプロジェクトを行う最大の理由をここに <#1 reason for doing this project>

エレベーターピッチ • • • • [必要性や機会を記述]を望んでいる [対象顧客]にとって [プロジェクト名]は [製品カテゴリ]に属しており • [キーベネフィット, 購入への説得力ある理由]がある. • [他の主要な競合製品]と違って • 我々のプロジェクトは[主要な違いの記述]がある.

プロダクトボックス(外箱) <製品名> 楽しい絵 <スローガン> <利点 #1> <利点 #2> <利点 #3>

やらないことリスト やる（スコープ内） やらない（スコープ外） 未解決

あなたのプロジェクトコミュニティ <コミュニティ#3> <チーム#2> コアチーム <グループ#1> その他大勢！ ... は常にあなたが考える以上に大きい!

テクニカルソリューション 技術: - <言語> - <ライブラリ> - <ツール> - <その他技術要素> 危険! 範囲外

夜も眠れないようなこと • <恐ろしいこと #1> • <恐ろしいこと #2> • <恐ろしいこと #3>

どのくらい大きいのか？ 出荷! 構築 ~3ヶ月 UAT 1週間 トレーニング 1 週間 これは想定です. 約束ではありません.

トレードオフ スライダー 典型的な４つの分類 ON OFF ON OFF ON OFF ON OFF フィーチャーが完了すること(スコー プ) 予算内に収まること(予算) 時間通りに納入すること (時間) 高い品質、少ないバグ(品質) その他の大事なこと ON OFF 簡単に使えること ON OFF 考えさせない! ON OFF ON OFF 詳細な証跡(なんでもログを取る) <好きなのをいれる>

最初のリリース 出荷! 構築 ~3ヶ月 UAT 1 週間 トレーニング 1 週間 3 人, 3.5ヶ月, 250Kドル

エレベーターピッチを書いてみよう(個人) [課題]を解決したい [アーリーアダプター]向けの [UVP]を実現する [プロダクト名]です。 これは[ソリューション]ができ、 [既存の代替品]とは違って、 [圧倒的な優位性]が備わっています。 http://www.slideshare.net/kdmsnr/running-lean-17917258/68 189

ワークショップ ユーザーストーリーマッピング 190

ユーザーストーリーマッピング • ユーザーストーリーマッピングとは、 ユーザーストーリーを利用者ごとの 時系列(X軸)と優先順位(Y軸) の2軸にマッピングし、ユーザース トーリーの網羅性を高めたり MVP(実用最小限の製品)を洗い 出すために実施するプラクティス 191

早速チームでやってみよう！ 195

朝起きてから家を出るまで ■ステップ 1) ストーリーカードを書く 2) マッピングする  体験順に時系列で左右に整理  似た機能は上下に整理  基本機能は上へ、派生的な機能は下へ 3) フィーチャ(機能)名をつける  時系列のグループ毎に名前を付ける  今回、アクティビティ名はつけません 196

朝起きてから家を出るまで 5)MVPを決める • 寝坊した時でもやる事を決める 6)MVPを発表する 197

ふりかえり 198

KPT2 http://blog.livedoor.jp/tech_blog/archives/744170.html

ふりかえりをやってみよう(チーム) ■ステップ 1) Keepを付箋紙に書く  今日聞いて良かったこと、これからも続けたいこと  チームの皆に発表しながら貼る  １人１枚交代、全員が無くなるまで回す 2) Problemを付箋紙に書く  今日気付いた問題点(個人、チーム、講義など)  チームの皆に発表しながら貼る 3) Tryを付箋紙に書く  今後取り組みたい、改善したい、より良くしたいこと  チームの皆に発表しながら貼る 4) Tryの中から１枚だけTodoを選び、チームの皆にコミットメント 5) ふりかえりのサマリーをチーム毎に発表 200

まとめ 201

• まずはふりかえりを定 期的に実施するところ から始めてみよう • 検査!、適応!、透明性! 202

検査 適応 透明性

おわり 204