1

2015年5月15日

ＧＭＯインターネット株式会社

次世代システム研究室

藤村 新

GTB2015

アジャイルとか

2

自己紹介

藤村 新 ふじむら あらた

アジャイルPM研究会所属

1.夢や実現したいことを言葉に出そう

2.自己投資しよう 3.まずは行動しよう

伝えたいこと

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

6

2015年の近況報告

7

1/1～5 カンボジア

8

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

9

2/28 Regional Scrum Gathering Tokyo 2015

• 開発モデルの作り方 ～守破離の破！～

10

3/19 PMI日本支部法人スポンサー連絡会

• アジャイルPMに関する意見交換会

11

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

12

5/29-30 Regional Scrum Gathering Vietnam 2015

• 参加予定(自費)

13

自己投資しよう

伝えたいこと(2回目)

14

アウトプットしよう

伝えたいこと

15

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

16

スライドをアップロード

17

フィードバック

18

楽天 Tech Talk

19

オフショア大學

20

私がやりたい事

21

＋ 正しく続ける

22

正しいものを(プロダクトディスカバリーフェーズ)

デザイン思考

顧客開発モデル

リーンスタートアップ

ビジネスモデルキャンバス(リーンキャンバス)

ユーザーエクスペリエンス(カスタマージャーニー)マップ

ユーザーストーリーマッピング

インセプションデッキ

23

正しくつくり(開発フェーズ)

アジャイル開発

スクラム

XP

ドメイン駆動設計

正しく続ける(運用フェーズ)

リーン開発

継続的デリバリー(CD)

今時インフラ

インフラCI

Immutable Infrastructure

24

ところで先週…

＿人人人人人人人人人人人人人＿

＞ 突然の自己組織化ゲーム ＜

￣Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y￣

1.リーダーを1人決めてください(リーダー以外はメンバーです)

2.リーダーは1人のメンバーから生年月日を聞いて、メンバーが生年月日順に並ぶように誘導してください

3.残りのメンバーでも同じことをしてください

何分かかりましたか？

1.リーダーはいません。全員がメンバーです

2.メンバー同士が協調して、プログラミング経験年数順に並んでください

何分かかりましたか？

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

31

自己組織化しよう

伝えたいこと

32

HRT重要

伝えたいこと

Humility Respect Trust

35

一番の下手くそでいよう

(Be the Worst)

伝えたいこと

37

休憩

https://www.flickr.com/photos/emiliokuffer/8359208711/

38

ピンポンゲーム

ワークショップ

39

■ルール

チーム全員が1つのピンポンボールに触れると1ポイント

ボールの受け渡しは一度ボールが宙に浮く必要がある(手渡禁止)

単位時間(120秒)でのスコアが高いチームが勝ち

■ステップ

1) 戦略を考えてスコアを見積もる(60秒)

2) 実行する(120秒)

3) スコアを計測して報告(60秒)

4) ふりかえり(60秒)

5) 1に戻る(5回実施します)

40

アジャイル開発概要

41

アジャイルの歴史

2001年から始まった

アジャイルの傘

アジャイルはもともと存

在した方法論を包括する

言葉

スクラムは1995年

価値や原則を包容する

方法論やアプローチならば、

すべてアジャイル

42

プロセスやツールよりも個人と対話を

包括的なドキュメントよりも動くソフトウェアを

契約交渉よりも顧客との協調を

計画に従うことよりも変化への対応を

アジャイルマニュフェスト

43

左記も重要

アジャイルマニュフェスト

左記のことがらに価値があることを認めながらも、

私たちは右記のことがらにより価値をおく。

44

プロセスやツールよりも個人と対話を

➡個人と対話よりもチームのビジョンと規律を

包括的なドキュメントよりも動くソフトウェアを

➡動くソフトウェアよりも有効で妥当な学習を

契約交渉よりも顧客との協調を

➡顧客との協調よりも顧客の開拓を

計画に従うことよりも変化への対応を

➡変化への対応よりも変化の提案を

アジャイルマニュフェスト(2.0)

45

Kent Beck(2010年)

XP, デザインパターン, TDD, Junit, …

署名は行われていない

何が変わったか

個人 ➡ チーム

手段 ➡ 目的

何をすべきか ➡ なぜすべきか

アジャイルマニュフェスト(2.0)

46

変動制と不確実性

役立つ変動性を受け入れよ

イテレーティブでインクリメンタルな開発を採用せよ

検査、適用、透明性を通じて変動性を活用せよ

あらゆる形の不確実性を同時に削除せよ

目的の不確実性(What)

手段の不確実性(How)

顧客の不確実性(Who)

アジャイルの原則

47

アジャイルの原則

http://www.agileproductdesign.com/downloads/patton_incremental_releases_handouts.pdf

イテレーティブ

インクリメンタル

48

予見と適応

選択肢を広げておく

最終責任時点を可能な限り先延ばしにする

事前に正しく行なうことは不可能だと認める

適応型で探索型のアプローチを好む

リーン・スタートアップ的なアプローチ

経済的に妥当なやり方で変化を受け入れる

初期に予見し過ぎない

予見的な事前の作業と適応型のジャストインタイムの作業とのバ

ランスを取る

事前の予見を最小化する

49

検証による学び

重要な想定をまず検証する

重要な想定の数を最小化する

複数の学習ループ(1日単位、スプリント単位など)を平行して活用する

すばやいフィードバックのためのワークフローをまとめる

仕掛中の作業(WIP)

作業は経済的に妥当なサイズにまとめよ

バッチサイズは1に近づける

在庫(WIP)を認識し、適切な流れで管理せよ

作業者の手待ち(キャパシティ)ではなく、作業の手待ち(実施したいのに何らかの原因

でできていない作業)に注目せよ

リレーにおいて、走者ではなくバトンを見ろ

遅延コストを考慮せよ

作業の手待ちの方が高くつく

50

進捗

リアルタイムの情報に適応して再計画せよ

計画に従うことが目的ではない

動作する資産を検証することで進捗を測れ

顧客にとって価値のある作業を終わらせたかどうかが重要

価値に主眼を置いたデリバリーに集中せよ

顧客は価値の高いフィーチャーから順に継続的に受け取れる

作業効率

すばやく進め、しかし、あわてるな

持続可能なペース

品質を作り込め

必要最低限の儀式を行え

必要なドキュメントは書く

エッセンシャルスクラム 図3.2より抜粋

51

シンプル

対象の問題を誰が見てもすぐに理

解できる

うまくやる方法をベストプラクティス

として利用できる

プロセスは不要

煩雑

対象の問題を理解するには、専門

知識と作業が必要

うまくやる方法は複数あるので、そ

れらをグッドプラクティスとして活用で

きる

WF, PMBOK

クネビンフレームワーク

52

複雑

対象の問題を理解するには、観察

するだけでは無理で、探査が必要

対象がどんな反応をするかを確か

めつつ、次の対応を考える。

プラクティスは出現する

アジャイル

カオス

対象を理解する事も難しい

まったく新しいプラクティスを考えな

ければならない

既存の知識は役に立たない

プロセスは無く、まず行動する

クネビンフレームワーク

53

まとめ

54

• アジャイル開発の歴史は古い

• 時代に合わせて解釈も変わってきている

• アジャイルの原則を理解する

• 計画駆動(WF)の原則との違いで考える

• アジャイル開発が適するのは対象が複雑な

場合のみ

• 適さないケースもある

55

リーン開発のカンバン

56

• 次研で一番活用されているのはカンバン • アジャイルなオフショア開発もカンバン

• カンバンはアジャイルソフトウェア開発におけるリーンなアプローチ • XPとスクラムは、イテレーションやスプリントと呼ばれ

る「期間」を区切ってチーム内に存在する在庫を制限するリーン手法

• カンバンは「WIP」(仕掛り)を直接制限するリーン手法

• 両者とも、ソフトウェアのモジュールではなく顧客の目でわかる機能ごとに開発を行い、「ふりかえり」という活動を通じて、現場のチームで改善活動を行う。

※「リーン開発の現場」 p.183 から抜粋

リーン開発のカンバンについて

59

• リーンという言葉は、TPS(トヨタ生産方式)が源流 • TPSの考え方は、リーン(ムダがない)というコンセプトで生

産方式を超えて抽象化され、さまざまな分野に適用された • リーン製品開発 • リーン・コンストラクション (建築) • リーン・サービス (サービス産業) • リーン・ソフトウェア開発 (アジャイル開発)

http://www.atmarkit.co.jp/ait/articles/1311/15/news015_3.html

60

• 3つのムダを無くす(リーン) • 間違ったものを作るというムダ • 「しなくてもいいことを効率的

にやってもムダである」 • 学び損ねるというムダ • 過度な作業切り替えによるムダ

61

昼休憩

https://www.flickr.com/photos/emiliokuffer/8359208711/

62

美味しいラーメンの作り方

ワークショップ

63

私からのお願い。

「美味しいラーメンを作ってください」

※チームで作業をしてください

1. 美味しいラーメンを作るために必要な作業を洗い出し、付箋に

書き出してください(5分)

2. 作業順に付箋を並べてください(5分)

3. チーム毎に発表してください(1分×6チーム)

64

スクラム概要

軽量 理解が容易 習得は困難

スクラムとは

66

全てのルールは

スクラムガイドに

書いてある

68

スクラムプラクティス

■役割

プロダクトオーナー(1人)

スクラムマスター

開発チーム(３～９人)

■作成物

プロダクトバックログ

スプリントバックログ

プロダクトインクリメント

■アクティビティ

スプリント(１～４週間)

スプリントプランニング(2～8時間)

デイリースクラム(15分)

スプリントレビュー(1～4時間)

レトロスペクティブ(1~3時間)

プロダクトバックログリファインメント

(作業時間の10%以下)

71

プロダクトオーナー

開発において行う投資に対する効果(ROI)を最大にすることに責任を持つ

バックログへの追加、削除、順位付けの最終的な責任を持つ

開発チームに機能を説明して理解してもらう責任がある

一人の人間が担当し、委員会のような合議制の体制にしてはいけない

開発チーム

3名以上、9名以下でないと効果が出にくい(7±2とも言われている)

実際に開発を行うチーム

職能横断的に様々な技能を持った人が集まり、自律的に行動する

自己組織化されたチーム

製品の価値を高めることに責任を持つ

役割

72

スクラムマスター

スクラムチーム全体が自律的に協働できるように場作りをする

ファシリテーター的な役割

開発チームが抱えている問題を取り除くために何でもやる

コーチとしてメンバーの相談に乗る

外部の割込みから守る

チームの障害を取り除くために外部との交渉を行う

プロダクトオーナーを支援する

製品のビジョン作りやバックログ管理など

サーバントリーダー

役割

74

プロダクトバックログ

製品へ追加する機能(要求)のリスト。

ユーザーの価値で書かれている必要がある

ユーザーストーリー形式

優先順位順に並んでいる必要がある

プロダクトオーナーが管理する

スプリントバックログ

プロダクトバックログから抜き出された、今回のスプリントで追加する機能の

リスト

スプリント計画でプロダクトオーナーの決めた順位と開発チームが決めた見

積もりの両方の情報を併せて抜き出される

一回のスプリントにだけ使用される

作成物

75

プロダクトインクリメント

一回のスプリントの成果であり、スプリントで完了した製品の機能

スプリントの終わりにはインクリメントが動く状態である必要がある

インクリメントは、「出荷判断可能ソフトウェア」の必要がある

プロダクトオーナーがレビューして、実際に製品をリリースするかどうか

を決定する

作成物

77

スプリント

反復(イテレーション)の単位

スプリントは1～4週間の時間枠(タイムボックス)

予定されている機能が完成できなくても延長されることはない

期間内で開発チームは「スプリントバックログ」の開発に集中し、動作する

製品(インクリメント)を作り出す

スプリントプランニング

スプリントの開始に先立って行われるミーティング

「プロダクトバックログ」から今回のスプリントで扱う「スプリントバックログ」を

抜き出して決定する。

その後開発チームが計画を詳細化し、タスクにまで分割する

開発チームのコミットメントが重要

アクティビティ

78

デイリースクラム(朝会)

メンバーは一人ずつ、「昨日やった事」、「今日やる事」、「困っている事」を

順に話す

上長への報告にならないように注意する

開発チームのコミットメントが重要(今日やる事)

15分で打ち切る

別途話し合いが必要な場合は朝会終了後に関係者のみで話す

スプリントレビュー

スプリントの終了時、関係者を呼び集めてできあがった製品のデモを行う

開発チームはプロダクトオーナーやステークホルダーからのフィードバックを

もらうことが重要

アクティビティ

79

レトロスペクティブ(ふりかえり)

このスプリントでうまくいったこと、うまくいかなかったこと、どうやったら次

のスプリントでよりうまくできるかを話し合う

KPT2(Keep, Problem, Try, To Do)形式で行われることが多い

「検査と適応」の機会となり、チーム学習、チーム改善の活動となる

プロダクトバックログリファインメント

「PBIの作成と改良(詳細の追加) 」、「PBIの見積もり」、「PBIの優先順位

付け」の3つのアクティビティの総称

プロダクトオーナー主導で行う共同作業

内外のステークホルダー、スクラムマスター、開発チーム

最終決断を下すのは、プロダクトオーナーの役割

デイリースクラムの後、スプリントレビュー中や、スプリント中に行う

アクティビティ

81

まとめ

82

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

• "スクラムの一部だけを導入することも可能だが、それはスクラムとは

言えない。"

• スクラム風

• "すべてをまとめたものがスクラムであり、その他の技法・方法論・プ

ラクティスのコンテナとして機能する。"

• XPとのハイブリッドが一般的

• 読むべき書籍

• アジャイルサムライ

• アジャイルな見積りと計画づくり(読書会やってます！)

• スクラム実践入門

• エッセンシャルスクラム

83

守破離とは

84

CSM研修で学んだ守破離

• 守 - ルールに従え - どうやるかを見て練習を繰り返す

• 破 - 工夫してみる - 原因と結果をつなげる実験

• 離 - ルールを忘れろ - 新しい技術を一瞬で考えて使える段階

85

スクラムにおける守破離 • 息をするようにスクラムのルールを行えるようにな

るまでが守 • スクラムのルールに従った上でアレンジしてみるの

が破

86

守破離の語源

87

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

88

• その後千利休が詠んだ(らしい) • 「規矩(きく)作法 守りつくして 破ると

も 離るるとても 本(もと)を忘るな」 • 『利休百首』

89

• そして千利休の茶道の修行観を、後世の川上不白(かわかみふはく)が表現した • 「守ハマモル、破ハヤブル、 離ハはなると申候。

弟子ニ敎ルハ此守 と申所計也。弟子守ヲ習盡し能成候へバ自然と自身よりヤブル。これ上手の段なり、さて、守るにても片輪、破るにても片輪、この二つを離れて名人なり、前の二つを合して離れてしかも二つを守ること也。 」 • 『不白筆記』

• 「守破離といふ事軍法用、尤用方違ひ候へ共、茶道に取て申候はば、守は下手〈略〉破は上手〈略〉離は名人」 • 横井淡所の『茶話抄』への添え書き

90

守破離とは 「道」

の指針

91

俺の守破離

92

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

93

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

94

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

95

プロセスの理解 ≠

スキル習得

96

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

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

98

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

99

CSPO研修受講

日時：2013年5月20日～21日

場所：株式会社ミクシィ

講師：ジェフ・パットン

100

プロダクトディスカバリを行なって、

プロダクトバックログを作るまでを

学んだ。

※スクラム開始前のフェーズ

※デザイン思考の話し

101

CSM研修受講

日時：2013年6月20日～21日

場所：ビジョンセンター日本橋

講師：江端一将、Sergey

102

スクラムの基礎を

座学とワークショップ

を通して学んだ。

103

• 勉強会、ワークショップ、イベントに参加

• アジャイルサムライ横浜道場

• POStudy

• レゴスクラム(見学)

• AEP読書会

• Scrum Masters Night

• Agile Japan 2014

• Regional Scrum Gathering Tokyo 2014

104

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

105

• 担当プロジェクトへ各種プラクティス導入

• リーンカンバン、WIP

• 朝会、ふりかえり、計画MTG

• グループ会社への導入支援

• インセプションデッキ

• 導入事例を書く、話す

• 採用ブログに書く

• 自社、他社に話す

• 部署内での啓蒙活動

• アジャイルな見積もりと計画づくりまとめ

• アジャイル開発取り組み状況

106

第1回アジャイルミーティング主催

日時：2013年10月9日

場所：GMO Yours

内容

1. PMIアジャイルPM研究会立ち上げプロジェクトの紹介

2. 次世代システム研究室

3. GMOリサーチ

4. GMO ECラボ

5. GMOペパボ

6. 交流会

107

108

• 次世代システム研究室では GMOベトナムラボセン

ター(ベトナム/ハノイ)と密接に連携しながらGMO

インターネットグループのシステム開発(オフショア

開発)に取り組んでいたが、必ずしもうまくいってい

るとは言えない状況だった

• オフショア開発プロセス改善に取り組むことになっ

たため、国内プロジェクトで実践していた各種プラ

クティスを導入するも問題多発

109

試行錯誤を重ね 辿り着いた

破 の境地

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

111

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

Rough Fill Closing

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

Rough Fill Closing

119

• ザックリ開発するフェーズ

• 7割程度の完成度を目指す

• 着手する前にザックリ開発工数を見積もっても

らう

Rough Fill Closing

121

• Roughフェーズでのアウトプットの完成度を上げ

るフェーズ

• 9割以上の完成度を目指す

Rough Fill Closing

123

• 完成させるフェーズ

• 日本側の発注者(エンジニア)が対応する

124

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

125

開発モデルを作ること ≒

破のフェーズ

126

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

127

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

128

• 十八代目 中村 勘三郎が19の時、唐十郎の巨大テントで「下町唐座」を見たときのこと

なんだこれは！？ 自分がやっている歌舞伎座での落ち着いた空気とは全く違うじゃないか！ でも待てよ、昔の歌舞伎はこうだったのでは？

129

• 早速親父(十七代目 中村 勘三郎)に直訴

これこそ歌舞伎の原点だ。 歌舞伎もこれに戻らなきゃいけない。 俺もあのような歌舞伎がしたい。

百年早い。 そんなことを考えてる間に百回稽古しろ。

130

• なんで親父は分かってくれないんだ！ • そんなモヤモヤしてた折、たまたまラジオから流

れてきた全国子供電話相談室での無着成恭(禅宗の僧侶、教育者)の回答を耳にする

型破りと形無しの違いはなんですか？

そりゃあんた、型がある人間が型を破ると『型破り』、型がない人間が型を破ったら『形無し』ですよ。

131

• 父の言う「百年早い」の意味が分かった

古典をしっかり学んで自分の形を作れ。 19や20の未熟者が土台もないのに新しいことをやるな。

• 2000年(45才)に平成中村座を上演

132

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

133

楽天 Tech Talkでの発表後、

134

135

• 同時に、あ、こういうモデルを考えだすのって、そんなご大層なも

のじゃないんだとか思った

• こんなん自分でも考えられるぜ！って言いたいのではなくて超

頭いい人が美しい理論のもとに弾きだした答えではなく、僕の

ような普通の人が苦しみ苦しみ抜いてその時々考えたことを

集めて体系化したという意味でなんだかすごい身近に感じた。

• というか、今自分のチームでも自分たちなりのKAIZENをいろ

いろしてるし、それをまとめればそれだけでひとつのモデルに

なるなー

http://daily.belltail.jp/?p=1880

136

そうなんです！

137

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

138

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

139

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

140

まとめ

141

• まずはしっかりと型を学ぼう(守)

• 型をしっかりと身に付けた上で、

現場の改善に取り組もう(破)

• 取り組んだ内容を体系化し、開発

モデルとしてアウトプットしよう

142

• 個人的には、試守破離がオススメ

• 試したからこそ守破離の大切さ

を痛感させられた

143

休憩

https://www.flickr.com/photos/brian_tomlinson/14678017291/

144

コインゲーム

ワークショップ

145

■ルール

利き腕と逆の手を使う

1枚ずつコインを全て裏返す

1人が最初の山と同じ状態にしたら、次の人が作業に入れる

■ステップ

1) 戦略を考えて作業時間を見積もる(60秒)

2) 見積もりを報告

3) 作業時間を計測する

4) 作業時間を報告

5) ふりかえり(60秒)

6) 1に戻る(5回実施します)

146

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

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

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

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

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

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

152

休憩

https://www.flickr.com/photos/emiliokuffer/8359208711/

153

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

154

リーン・スタートアップについて • 今回お話しする内容は、主にRunning Lean • Running Leanは複数の方法論の組み合わせ

• リーン・スタートアップ • エリック・リース • 顧客開発＋アジャイル開発＋リーン手法

• 顧客開発 • スティーブ・ブランク • 「アントレプレナーの教科書」 • 建物の外に出よ。

• ブートストラッピング • ビジョイ・ゴスワミ • 顧客からの収益で資金をまかなう

155

• Running Leanの本質は、3つの手順に分けられる 1. プランAを文章化する 2. プランで最もリスクの高い部分を見つける 3. プランを体系的にテストする

※RUNNING LEAN 2nd Edition P.165 Figure 14-2 から転載

156

手順1.プランAを文章化する

• 顧客を考えるフェーズ • リーン・キャンバスを書く • 最初は1枚のキャンバスにまとめる • その後、顧客セグメントごとにリーン・

キャンバスを書く • まずは一気に書く(15分以内) • 空欄があっても良い • 簡潔に書く • 今分かる範囲で書く

※RUNNING LEAN 2nd Edition P.27 Figure 3-1 から転載

リーン・キャンバス

158

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

• リーン・キャンバスを順番に並べて、どのビジネスモデルから手を付けるかを決めるフェーズ

• 最も大きなリスクは、誰も欲しくないものを作ること • リスクはステージによって決まる

• スタートアップには3つのステージがある

課題/解決フィット 製品/市場フィット 拡大

※RUNNING LEAN 2nd Edition P.8 Figure 1-3 から転載

159

第1ステージ：課題/解決フィット(P/S Fit)

• 解決に値する課題はあるか？ • アイデアは安くても、それに取り組むコストは高い

• それは顧客が必要としているものですか？(必要性)

• 顧客はお金を支払ってくれますか？支払ってくれないのであれば、誰が支払ってくれますか？(成長性)

• それは解決可能ですか？(実現性)

リーン・スタートアップについて

160

第2ステージ：製品/市場フィット(P/M Fit)

• 誰かに必要とされるものを構築したか？ • そのソリューションがどれだけ課題を解決しているか

をテストする • 定性的に検証する • 定量的に検証する

第3ステージ：拡大(Scale)

• どうやって成長を加速させるのか？

リーン・スタートアップについて

161

• リスクは3つのカテゴリに分けられる • 製品リスク(P) • 顧客リスク(C) • 市場リスク(M)

※RUNNING LEAN 2nd Edition P.50 Figure 4-1 から転載

リーン・スタートアップについて

手順3.プランを体系的にテストする

• 検証による学習ループ(実験)を行うフェーズ 1. アイデアや仮説を用意 2. 仮説をテストする製品を構築 3. 製品を顧客に提示して、反応を定性的、定量的

に計測 4. このデータを仮設の検証、反証の学習に使う 5. 再び構築に戻る

リーン・スタートアップについて

BMLループ

ステージ＼リスク 製品リスク(P) 顧客リスク(C) 市場リスク(M)

第1ステージ 課題/解決

フィット (P/S Fit)

課題を 理解する

解決に値する課題かどうかを確認する

不満を持っている人を特定する

既存の代替品から競合他社を特定し、ソリューションの価格を設定する

ソリューションを決定する

最小限のソリューション(MVP)を決定する

製品を今すぐに欲しいと思うアーリーアダプターに範囲を狭める

顧客の声を聞いて、価格をテストする(口約束)

第2ステージ 製品/市場

フィット (P/M Fit)

定性的に 検証する

MVPを構築して、小規模に検証する(UVPのデモ)

アウトバウンドチャネルから開始しても構わない

顧客の行動を見て、価格をテストする

定量的に 検証する

大規模に検証する 少しずつ拡大可能なインバウンドチャネルも構築/開発する

ビジネスモデルがうまくいくように、コスト構造を最適化する

ステージ(イテレーション)毎に実際にやること

1. 課題を理解する • 見込み客を見つける • 課題インタビュー

• 学習すべきこと • 製品リスク：何を解決するのか？(課

題) • 市場リスク：競合は誰なのか？(既存

の代替品) • 顧客リスク：誰が困っているのか？

(顧客セグメント)

2. ソリューションを決定する • デモを構築する • ソリューションインタビュー

• 学習すべきこと • 顧客リスク：誰が困っているのか？(アー

リーアダプター) • 製品リスク：課題をどのように解決するの

か？(ソリューション) • 市場リスク：どのような価格モデルにする

のか？(収益の流れ) • MVPを構築する

ステージ(イテレーション)毎に実際にやること

3. 定性的に検証する • ダッシュボードを構築する • MVPインタビュー

• 学習すべきこと • 製品リスク：製品の魅力は何か？(独自の

価値提案) • 顧客リスク：十分な顧客はいるか？(チャネ

ル) • 市場リスク：価格は適正か？(収益の流

れ) • UVPを実現する • 顧客ライフサイクルを検証する

ステージ(イテレーション)毎に実際にやること

4. 定量的に検証する • 機能を制限する

• 追加機能は独自の価値提案(UVP)を薄める • 進捗を計測する • 初期のトラクションを達成する

• ユーザーの40%が定着 • ショーン・エリスのテストを通過

• 製品が使えなくなった時残念に思うか？ • 成長エンジンを特定する

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

ステージ(イテレーション)毎に実際にやること

169

• 作ってみなくても分かることは多々ある • やみくもに作らない • 作らずに検証できないか考える • 作る場合でもMVPを意識する

• ケチな考えを持つ • 自分のお金でも作りますか？

• 課題ありき、顧客ありきで考える • ソリューションありきでは無い

なぜ導入したいのか？

170

休憩

https://www.flickr.com/photos/emiliokuffer/8359208711/

171

リーンキャンバス

ワークショップ

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

※RUNNING LEAN 2nd Edition P.27 Figure 3-1 から転載

リーン・キャンバス

174

• テーマは以下の3大欲求から選択 • 英語 • ダイエット • お金

• 1～5の順に書いてみる 1. 課題

• 既存の代替品 2. 顧客

• アーリーアダプター 3. 独自の価値提案

• ハイレベルコンセプト 4. ソリューション 5. 圧倒的な優位性

書いてみよう(個人)

175

インセプションデッキ

ワークショップ

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

177

インセプションデッキ • 10の手強い質問と課題から構成されている • 関係者全員の認識を合わせるために実施 • テンプレート

• https://github.com/agile-samurai-ja/support/tree/master/blank-inception-deck

178

背後にある考え

「しかるべき人をみんな同じ部屋に集めて、プロ

ジェクトにまつわる適切な質問をすれば、自分た

ちのプロジェクトに対する期待を共有して、認識

を合わせることができるはずだ」

作成にあたっては、ステークホルダーを巻き込むこ

とがとても重要

インセプションデッキ

我々はなぜここにいるのか?

• 大事な理由 #1

• 大事な理由 #2

• 大事な理由 #3

<#1 reason for doing this project> このプロジェクトを行う最大の理由をここに

エレベーターピッチ

• [必要性や機会を記述]を望んでいる

• [対象顧客]にとって

• [プロジェクト名]は

• [製品カテゴリ]に属しており

• [キーベネフィット, 購入への説得力ある理由]がある.

• [他の主要な競合製品]と違って

• 我々のプロジェクトは[主要な違いの記述]がある.

プロダクトボックス(外箱)

<製品名>

楽しい絵

<スローガン>

<利点 #1>

<利点 #2>

<利点 #3>

やらないことリスト

やる（スコープ内） やらない（スコープ外）

未解決

あなたのプロジェクトコミュニティ

コアチーム

<グループ#1>

<チーム#2>

<コミュニティ#3>

その他大勢！

... は常にあなたが考える以上に大きい!

テクニカルソリューション

危険!

範囲外

技術: - <言語> - <ライブラリ> - <ツール> - <その他技術要素>

夜も眠れないようなこと

• <恐ろしいこと #1>

• <恐ろしいこと #2>

• <恐ろしいこと #3>

どのくらい大きいのか？

出荷!

構築 UAT トレーニング

~3ヶ月 1週間 1 週間

これは想定です. 約束ではありません.

トレードオフ スライダー

典型的な４つの分類

フィーチャーが完了すること(スコープ)

予算内に収まること(予算)

時間通りに納入すること (時間)

高い品質、少ないバグ(品質)

ON OFF

その他の大事なこと

簡単に使えること

考えさせない!

詳細な証跡(なんでもログを取る)

<好きなのをいれる>

ON OFF

ON OFF

ON OFF

ON OFF

ON OFF

ON OFF

ON OFF

最初のリリース

出荷!

構築 UAT トレーニング

~3ヶ月 1 週間 1 週間

3 人, 3.5ヶ月, 250Kドル

189

エレベーターピッチを書いてみよう(個人)

[課題]を解決したい

[アーリーアダプター]向けの

[UVP]を実現する

[プロダクト名]です。

これは[ソリューション]ができ、

[既存の代替品]とは違って、

[圧倒的な優位性]が備わっています。 http://www.slideshare.net/kdmsnr/running-lean-17917258/68

190

ユーザーストーリーマッピング

ワークショップ

191

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

ユーザーストーリーマッピング

195

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

196

朝起きてから家を出るまで

■ステップ

1)ストーリーカードを書く

2)マッピングする

体験順に時系列で左右に整理

似た機能は上下に整理

基本機能は上へ、派生的な機能は下へ

3)フィーチャ(機能)名をつける

時系列のグループ毎に名前を付ける

今回、アクティビティ名はつけません

197

朝起きてから家を出るまで

5)MVPを決める

• 寝坊した時でもやる事を決める

6)MVPを発表する

198

ふりかえり

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

KPT2

200

ふりかえりをやってみよう(チーム) ■ステップ

1) Keepを付箋紙に書く

今日聞いて良かったこと、これからも続けたいこと

チームの皆に発表しながら貼る

１人１枚交代、全員が無くなるまで回す

2) Problemを付箋紙に書く

今日気付いた問題点(個人、チーム、講義など)

チームの皆に発表しながら貼る

3) Tryを付箋紙に書く

今後取り組みたい、改善したい、より良くしたいこと

チームの皆に発表しながら貼る

4) Tryの中から１枚だけTodoを選び、チームの皆にコミットメント

5) ふりかえりのサマリーをチーム毎に発表

201

まとめ

202

•まずはふりかえりを定期的に実施するところから始めてみよう

•検査!、適応!、透明性!

検査 適応 透明性

204

おわり