リーンスタートアップ、アジャイル開発導入事例

1

2015年3月30日

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

次世代システム研究室

藤村新

リーンスタートアップ、

アジャイルオフショア開発導入事例

～正しいものを正しくつくる～

2015年1Q 次世代システム研究室研究発表会

藤村新ふじむらあらた

アジャイルPM研究会所属

3

近況

4

1/1～5 カンボジア

5

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

6

2/28 Regional Scrum Gathering Tokyo 2015

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

7

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

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

8

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

9

テーマ

正しいものを正しくつくる!!

10

• 正しいものを探す試み

• CSPO研修で学んだこと

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

• 次研導入プラクティス

• 正しくつくる試み

• CSM研修で学んだこと

• カンバンについて

• RFCモデル拡張事例

アジェンダ

11

正しいものを探す試み

12

CSPO研修受講

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

場所：株式会社ミクシィ

講師：ジェフ・パットン

13

CSPO研修で学んだこと(導入状況)

• カードモデリング(○) • ユーザー・ペルソナ(☓) • ユーザーストーリーマッピング(○) • リーン・スタートアップ(MVP)(△) • リーン・キャンバス(△) • 共感マップ(☓) • ユーザー・インタビュー(△) • ペーパープロトタイプ(△) • デザイン思考(IDEOの事例)(☓)

14 ※CSPO研修配布資料から抜粋

• 最小のOutput(製品の機能等)で最大のOutcome(成果)を得る事を重視する

15

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

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

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

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

16

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

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

17

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

• 顧客を考えるフェーズ • リーン・キャンバスを書く

• 最初は1枚のキャンバスにまとめる • その後、顧客セグメントごとにリーン・キャン

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

19

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

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

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

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

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


20

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

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

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

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

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

21

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

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

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

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

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

22

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


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

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

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

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

第1ステージ課題/解決

フィット (P/S Fit)

課題を理解する

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

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

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

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

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

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

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

第2ステージ製品/市場

フィット (P/M Fit)

定性的に検証する

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

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

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

定量的に検証する

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

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

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

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

• 学習すべきこと • 製品リスク：何を解決するのか？(課題) • 市場リスク：競合は誰なのか？(既存の代

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

グメント)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

30

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

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

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

なぜ導入したいのか？

31

次研導入プラクティス

32

• 実施プロジェクト • とくとくポイント(アプリ) • GMOコマース社 (新規サービス) • GMOアドパグループ (新規サービス) • 次研インターン(アプリ)

• 利用ツール • LeanStack(https://leanstack.com/ ) • アッシュ・マウリャのSpark59が提供

リーン・キャンバス

34

[LeanStackデモ]

35

• 実施プロジェクト • GMOアドパグループサービス

• 課題インタビュー • Z.com コンパネUI(新規)

1. モックアップ構築 2. ユーザーテスト 3. カスタマージャーニーマップ作成

インタビュー、ユーザーテスト

ストーリー Story Feeling

行動 Doing

思考 Thinking

課題 Problem

実施日時被験者：

観察者：

対象製品：

ペルソナ： 2015/3/30

Task1 Task2 Task3 Task4 Task5

xxxxxxx

xxxxxxx

xxxxxxx

xxxxxxx

37

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

• ジェフ・パットンが発案

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

※赤い線より上がMVP(実用最小限の製品)

39

• 実施プロジェクト • とくとくポイント(アプリ) • 次研インターン(アプリ)

• テンプレート • POP(https://popapp.in/sketchpad/)

• ツール • Prott(https://prottapp.com/ja/)

(ペーパー)プロトタイピング

42

[Prottデモ]

43

インセプションデッキ

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

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

44

• グループ支援チームのインセプションデッキ • 我々はなぜここにいるのか？

• GMOインターネットグループの各種プロジェクトを"成功"に導くために、HRT精神と技術力で支援する。

45

• エレベーターピッチ • [技術サポート]を望んでいる • [各種プロジェクト]にとって • [次研グループ支援チーム]は • [開発部署]に属しており • [幅広い技術力]がある。 • [他の開発部署]と違って • 我々のプロジェクトは[柔軟性とHRT

精神]がある。

46 https://www.flickr.com/photos/wwarby/3297205226/

47

正しくつくる試み

48

CSM研修の概要

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

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

講師：江端一将、Sergey

49

CSM研修で学んだこと(導入状況)

• アジャイルの歴史(×) • 守破離(△) • スクラム詳細(△)

• 役割 • イベント • 作成物 • マインド

• ポイントを使った見積もり(○)

50

カンバンについて • 次研で一番活用されているのはカンバン

• RFCモデルもカンバン • カンバンはアジャイルソフトウェア開発におけるリーンなア

プローチ • XPとスクラムは、イテレーションやスプリントと呼ばれる

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

• カンバンは「WIP」(仕掛り)を直接制限するリーン手法 • 両者とも、ソフトウェアのモジュールではなく顧客の目で

わかる機能ごとに開発を行い、「ふりかえり」という活動を通じて、現場のチームで改善活動を行う。

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

51

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

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

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

53

RFCモデル拡張事例

Rough Fill Closing

56

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

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

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

らう

Rough Fill Closing

58

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

るフェーズ

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

Rough Fill Closing

60

• 完成させるフェーズ

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

プロジェクトの規模/複雑さ

内

小中

次研

外

初期導入プロジェクト (1ゲーム)

ランシステム社との協働事例

(アプリ開発)

複数プロジェクト並行開発事例

(3ゲーム)

GMOメディア社に期待？

今後狙ってる領域

62

複数プロジェクト並行開発事例 • 対象プロジェクト

• スマホゲームC(2014年4月～) • スマホゲームN(2015年1月～) • スマホゲームS(2015年3月～)

• 体制 • プロジェクト毎に日本側に専任を置き、各担当が仕様策定、発

注、受入を行う • 開発チーム(全員ベトナム人)

• オフショア(ベトナム・ハノイ)：2～3人 • 日本側：1～2人

• 開発メンバーには1名リーダーを置き、リーダーがリソース、タスク管理を行う

• 開発チーム内で一次レビューを行う

S専任

C専任

N専任

リーダー

日本

仕様策定・発注・受入



リソース・タスク管理

ベトナム

開発チーム

当初思い描いていた体制図

64

• 業務管理 • Trelloを用いて、優先順位をつけてバックログに積んでおく • スプリントは最短プロジェクトに合わせて1週間で実施 • 朝会にて一括で進捗報告を行う

• 結果 • メンバー自体は並列業務を行う体制は取れたが、発注側の事情

で1つのプロジェクトにリソースを集中する必要があったため、当初想定していたような並列開発状況にはならなかった

• 特定のゲームの専任メンバーが発生してしまった • 自己組織化不足

• RFCモデルを使用した事で、常にバックログには優先順位の高い作業が一意に並べられている状況になり、複数プロジェクトという理由での負荷増加は無かった • 切り替えオーバーヘッドはあり

• 複数プロジェクトの開発でも期日等に関する意識は変わらず、期日通りに完了するケースが多く見られた

65

• 反省 • 単一プロジェクト開始時と同様に、プロジェクト新規参入時の

オーバーヘッドは存在する • スプリントの開始時に全ての作業内容を準備できず、スプリント

中に都度依頼する運用となってしまった • プロジェクト専任を置かず、手の空いたメンバーがバックログから

優先度順に次々とタスクを取る事を想定していたが、うまくいかなかった • リーダーに作業の割り振りを任せており、リーダーとの認識の

ズレがあった • 総括

• 開発チームの初期オーバーヘッドは各プロジェクト毎に発生はするが、RFCモデルで発注・管理を行えば、複数プロジェクトを一つの開発チームで担当しても、大きな混乱は発生しないと感じた

• やはり受け入れ担当の負荷が高い • 兼任でも良いので、受入担当は2人以上が望ましいと感じた

S専任

C専任

N専任

リーダー

日本




リソース・タスク管理

ベトナム

開発チーム

実際の体制図

67

• 備考 • 今回は3ゲームプロジェクトと並行して、ベトナムラボHP改修も進

めてもらっていた • 結果として、圧倒的にベトナム主体で進めた方がスピードは速く、

発注側の負荷も低く、開発メンバーのモチベーションも高かった • 細かな指示をせずに目的のみを提示し、後は全て任せる事で非

常に自己組織化されたプロジェクトとなった

目指す形が見えた！ (RFCモデル関係ない…)

68

ランシステム社との協働事例 • 対象プロジェクト

• とくとくポイントアプリ開発 • 体制

• 発注側 • 国内で通常採用のベトナム人：1名

• ベトナム語ネイティブ • 日本語、英語：ビジネスレベル

• オフショア側(ベトナム・ハノイ) • ランシステム社Androidアプリ開発エンジニア：1名

• ベトナム語ネイティブ • 英語：基礎レベル • 日本語：不可

69

ウィさんレポート(アプリ開発の事例まとめ)

体制図

71

• 仕様策定での工夫 • リーン・キャンバスを使ってなぜアプリを作るのかを明確

にした • ユーザーストーリーマッピングを行ってMVPを定義し、ム

ダな機能の作りこみが発生しないように心がけた • ペーパープロトタイピングを行い、作る前に使い勝手の

検証を行うとともに、認識のズレや機能漏れの精査を実施した

72

• 開発環境での工夫 • ランシステム社のエンジニアに、ネットワーク周りの環境

構築が済んでいるラボセンターへ席を移してもらった • モックサーバ(node-easymock)を使ってもらう事によ

り、API開発とアプリ開発を分離した • Prottのプレビューを使って画面遷移を理解してもらった

73

[node-easymockデモ]

74

• コミュニケーションでの工夫 • 最初にプロジェクトの目的の共有やアプリ全体の説明を

行うことにより、認識のズレを無くすよう心がけた • 必要に応じて仕様書や画面の翻訳を行った

75

• 成果(現状まだ進行中) • 見積もり精度は高い(完了係数：1.17)

• 見積もり精度は改善されてきている

• 日本語の部分をベトナム語で説明したり、画面に表示する内容やメッセージなどはコピペで対応できるようにした結果、言語の壁が低くなったと考えている

• 仕様を理解し、実装に集中できたため、アウトプットが徐々に安定してきている • 自己組織化されてきている

• 日本語ができないエンジニアでも、RFCモデルを使って開発効率向上が実現できていると感じている

76

[trello, RFCツールデモ]

77

• 課題 • BSE頼みな点が多く、BSEの能力にかなり依存する

• 細かい仕様部分の説明はベトナム語 • 実際は8割ベトナム語、2割英語

• BSEが兼務(API開発や他の業務など)で、負荷が集中 • アプリエンジニアが1名だからこそうまくいっている

• 日本語ができないエンジニアが複数になった場合でもうまくいくかは未知数

ウィさん様様！ (RFCモデル関係ない…)

78

さいごに

79

• 正しいものを正しくつくるというアプローチは続けていきたい

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

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

80

• 皆さんへの提案 • 試守破(離)がオススメ • 試したからこそ守破離の大切

さが分かる • 試した後こそが重要

• しっかりと型を学ぼう(守) • 型をしっかりと身に付けた上で、

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

81

試→破 ↓

試→守→破

82

ご清聴、ありがとうございました

リーンスタートアップ、アジャイル開発導入事例

Engineering

Transcript of リーンスタートアップ、アジャイル開発導入事例