Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Similar to リーンスタートアップ、アジャイル開発導入事例
Similar to リーンスタートアップ、アジャイル開発導入事例 (20)
More from Arata Fujimura
More from Arata Fujimura (20)
リーンスタートアップ、アジャイル開発導入事例
- 3. 3 近況
- 5. 5 2/25 ザッパラス社セミナー • リーンスタートアップについて • アジャイル開発について • スクラムについて
- 6. 6 2/28 Regional Scrum Gathering Tokyo 2015 • 開発モデルの作り方 ～守破離の破！～
- 8. 8 4/16 Agile Japan 2015(予定) • アジャイルなオフショア開発
- 10. 10 • 正しいものを探す試み • CSPO研修で学んだこと • リーン・スタートアップについて • 次研導入プラクティス • 正しくつくる試み • CSM研修で学んだこと • カンバンについて • RFCモデル拡張事例 アジェンダ
- 11. 11 正しいものを探す試み
- 12. 12 CSPO研修受講 日時：2013年5月20日～21日 場所：株式会社ミクシィ 講師：ジェフ・パットン
- 13. 13 CSPO研修で学んだこと(導入状況) • カードモデリング(○) • ユーザー・ペルソナ(☓) • ユーザーストーリーマッピング(○) • リーン・スタートアップ(MVP)(△) • リーン・キャンバス(△) • 共感マップ(☓) • ユーザー・インタビュー(△) • ペーパープロトタイプ(△) • デザイン思考(IDEOの事例)(☓)
- 15. 15 リーン・スタートアップについて • 今回お話しする内容は、主にRunning Lean • Running Leanは複数の方法論の組み合わせ • リーン・スタートアップ • エリック・リース • 顧客開発＋アジャイル開発＋リーン手法 • 顧客開発 • スティーブ・ブランク • 「アントレプレナーの教科書」 • 建物の外に出よ。 • ブートストラッピング • ビジョイ・ゴスワミ • 顧客からの収益で資金をまかなう
- 16. 16 • Running Leanの本質は、3つの手順に分けられる 1. プランAを文章化する 2. プランで最もリスクの高い部分を見つける 3. プランを体系的にテストする ※RUNNING LEAN 2nd Edition P.165 Figure 14-2 から転載
- 17. 17 手順1.プランAを文章化する • 顧客を考えるフェーズ • リーン・キャンバスを書く • 最初は1枚のキャンバスにまとめる • その後、顧客セグメントごとにリーン・キャン バスを書く • まずは一気に書く(15分以内) • 空欄があっても良い • 簡潔に書く • 今分かる範囲で書く
- 18. ※RUNNING LEAN 2nd Edition P.27 Figure 3-1 から転載
- 19. 19 手順2.プランで最もリスクの高い部分を見つける • リーン・キャンバスを順番に並べて、どのビジネスモ デルから手を付けるかを決めるフェーズ • 最も大きなリスクは、誰も欲しくないものを作ること • リスクはステージによって決まる • スタートアップには3つのステージがある 課題/解決フィット 製品/市場フィット 拡大 ※RUNNING LEAN 2nd Edition P.8 Figure 1-3 から転載
- 20. 20 第1ステージ：課題/解決フィット(P/S Fit) • 解決に値する課題はあるか？ • アイデアは安くても、それに取り組むコストは高い • それは顧客が必要としているものですか？(必 要性) • 顧客はお金を支払ってくれますか？支払ってくれ ないのであれば、誰が支払ってくれますか？(成 長性) • それは解決可能ですか？(実現性)
- 21. 21 第2ステージ：製品/市場フィット(P/M Fit) • 誰かに必要とされるものを構築したか？ • そのソリューションがどれだけ課題を解決しているか をテストする • 定性的に検証する • 定量的に検証する 第3ステージ：拡大(Scale) • どうやって成長を加速させるのか？
- 22. 22 • リスクは3つのカテゴリに分けられる • 製品リスク(P) • 顧客リスク(C) • 市場リスク(M) ※RUNNING LEAN 2nd Edition P.50 Figure 4-1 から転載
- 23. 手順3.プランを体系的にテストする • 検証による学習ループ(実験)を行うフェーズ 1. アイデアや仮説を用意 2. 仮説をテストする製品を構築 3. 製品を顧客に提示して、反応を定性的、定量的 に計測 4. このデータを仮設の検証、反証の学習に使う 5. 再び構築に戻る
- 25. ステージ＼リスク 製品リスク(P) 顧客リスク(C) 市場リスク(M) 第1ステージ 課題/解決 フィット (P/S Fit) 課題を 理解する 解決に値する課題 かどうかを確認する 不満を持っている 人を特定する 既存の代替品から 競合他社を特定し、 ソリューションの価 格を設定する ソリューション を決定する 最小限のソリュー ション(MVP)を決定 する 製品を今すぐに欲 しいと思うアーリー アダプターに範囲 を狭める 顧客の声を聞いて、 価格をテストする (口約束) 第2ステージ 製品/市場 フィット (P/M Fit) 定性的に 検証する MVPを構築して、小 規模に検証する (UVPのデモ) アウトバウンドチャ ネルから開始して も構わない 顧客の行動を見て、 価格をテストする 定量的に 検証する 大規模に検証する 少しずつ拡大可能 なインバウンドチャ ネルも構築/開発 する ビジネスモデルが うまくいくように、 コスト構造を最適 化する
- 26. ステージ(イテレーション)毎に実際にやること 1. 課題を理解する • 見込み客を見つける • 課題インタビュー • 学習すべきこと • 製品リスク：何を解決するのか？(課題) • 市場リスク：競合は誰なのか？(既存の代 替品) • 顧客リスク：誰が困っているのか？(顧客セ グメント)
- 27. 2. ソリューションを決定する • デモを構築する • ソリューションインタビュー • 学習すべきこと • 顧客リスク：誰が困っているのか？(アー リーアダプター) • 製品リスク：課題をどのように解決するの か？(ソリューション) • 市場リスク：どのような価格モデルにする のか？(収益の流れ) • MVPを構築する
- 28. 3. 定性的に検証する • ダッシュボードを構築する • MVPインタビュー • 学習すべきこと • 製品リスク：製品の魅力は何か？(独自の 価値提案) • 顧客リスク：十分な顧客はいるか？(チャネ ル) • 市場リスク：価格は適正か？(収益の流 れ) • UVPを実現する • 顧客ライフサイクルを検証する
- 29. 4. 定量的に検証する • 機能を制限する • 追加機能は独自の価値提案(UVP)を薄める • 進捗を計測する • 初期のトラクションを達成する • ユーザーの40%が定着 • ショーン・エリスのテストを通過 • 製品が使えなくなった時残念に思うか？ • 成長エンジンを特定する • 粘着型：高い定着率 • ウィルス型：高い紹介率 • 支出型：高い利益率
- 30. 30 • 作ってみなくても分かることは多々ある • やみくもに作らない • 作らずに検証できないか考える • 作る場合でもMVPを意識する • ケチな考えを持つ • 自分のお金でも作りますか？ • 課題ありき、顧客ありきで考える • ソリューションありきでは無い なぜ導入したいのか？
- 31. 31 次研導入プラクティス
- 32. 32 • 実施プロジェクト • とくとくポイント(アプリ) • GMOコマース社 (新規サービス) • GMOアドパグループ (新規サービス) • 次研インターン(アプリ) • 利用ツール • LeanStack(https://leanstack.com/ ) • アッシュ・マウリャのSpark59が提供 リーン・キャンバス
- 34. 34 [LeanStackデモ]
- 35. 35 • 実施プロジェクト • GMOアドパグループサービス • 課題インタビュー • Z.com コンパネUI(新規) 1. モックアップ構築 2. ユーザーテスト 3. カスタマージャーニーマップ作成 インタビュー、ユーザーテスト
- 36. ストーリー Story Feeling 行動 Doing 思考 Thinking 課題 Problem 実施日時 被験者： 観察者： 対象製品： ペルソナ： 2015/3/30 Task1 Task2 Task3 Task4 Task5 xxxxxxx xxxxxxx xxxxxxx xxxxxxx
- 39. 39 • 実施プロジェクト • とくとくポイント(アプリ) • 次研インターン(アプリ) • テンプレート • POP(https://popapp.in/sketchpad/) • ツール • Prott(https://prottapp.com/ja/) (ペーパー)プロトタイピング
- 42. 42 [Prottデモ]
- 43. 43 インセプションデッキ • 10の手強い質問と課題から構成されている • 関係者全員の認識を合わせるために実施 • テンプレート • https://github.com/agile-samurai- ja/support/tree/master/blank- inception-deck
- 44. 44 • グループ支援チームのインセプションデッキ • 我々はなぜここにいるのか？ • GMOインターネットグループの各種プロ ジェクトを"成功"に導くために、HRT精神 と技術力で支援する。
- 45. 45 • エレベーターピッチ • [技術サポート]を望んでいる • [各種プロジェクト]にとって • [次研グループ支援チーム]は • [開発部署]に属しており • [幅広い技術力]がある。 • [他の開発部署]と違って • 我々のプロジェクトは[柔軟性とHRT 精神]がある。
- 47. 47 正しくつくる試み
- 48. 48 CSM研修の概要 日時：2013年6月20日～21日 場所：ビジョンセンター日本橋 講師：江端一将、Sergey
- 49. 49 CSM研修で学んだこと(導入状況) • アジャイルの歴史(×) • 守破離(△) • スクラム詳細(△) • 役割 • イベント • 作成物 • マインド • ポイントを使った見積もり(○)
- 50. 50 カンバンについて • 次研で一番活用されているのはカンバン • RFCモデルもカンバン • カンバンはアジャイルソフトウェア開発におけるリーンなア プローチ • XPとスクラムは、イテレーションやスプリントと呼ばれる 「期間」を区切ってチーム内に存在する在庫を制限する リーン手法 • カンバンは「WIP」(仕掛り)を直接制限するリーン手法 • 両者とも、ソフトウェアのモジュールではなく顧客の目で わかる機能ごとに開発を行い、「ふりかえり」という活動 を通じて、現場のチームで改善活動を行う。 ※「リーン開発の現場」 p.183 から抜粋
- 51. 51 • リーンという言葉は、TPS(トヨタ生産方式)が源流 • TPSの考え方は、リーン(ムダがない)というコンセプトで生 産方式を超えて抽象化され、さまざまな分野に適用された • リーン製品開発 • リーン・コンストラクション (建築) • リーン・サービス (サービス産業) • リーン・ソフトウェア開発 (アジャイル開発) http://www.atmarkit.co.jp/ait/articles/1311/15/news015_3.html
- 53. 53 RFCモデル拡張事例
- 56. 56 • ザックリ開発するフェーズ • 7割程度の完成度を目指す • 着手する前にザックリ開発工数を見積もっても らう
- 62. 62 複数プロジェクト並行開発事例 • 対象プロジェクト • スマホゲームC(2014年4月～) • スマホゲームN(2015年1月～) • スマホゲームS(2015年3月～) • 体制 • プロジェクト毎に日本側に専任を置き、各担当が仕様策定、発 注、受入を行う • 開発チーム(全員ベトナム人) • オフショア(ベトナム・ハノイ)：2～3人 • 日本側：1～2人 • 開発メンバーには1名リーダーを置き、リーダーがリソース、タスク 管理を行う • 開発チーム内で一次レビューを行う
- 64. 64 • 業務管理 • Trelloを用いて、優先順位をつけてバックログに積んでおく • スプリントは最短プロジェクトに合わせて1週間で実施 • 朝会にて一括で進捗報告を行う • 結果 • メンバー自体は並列業務を行う体制は取れたが、発注側の事情 で1つのプロジェクトにリソースを集中する必要があったため、当 初想定していたような並列開発状況にはならなかった • 特定のゲームの専任メンバーが発生してしまった • 自己組織化不足 • RFCモデルを使用した事で、常にバックログには優先順位の高い 作業が一意に並べられている状況になり、複数プロジェクトとい う理由での負荷増加は無かった • 切り替えオーバーヘッドはあり • 複数プロジェクトの開発でも期日等に関する意識は変わらず、期 日通りに完了するケースが多く見られた
- 65. 65 • 反省 • 単一プロジェクト開始時と同様に、プロジェクト新規参入時の オーバーヘッドは存在する • スプリントの開始時に全ての作業内容を準備できず、スプリント 中に都度依頼する運用となってしまった • プロジェクト専任を置かず、手の空いたメンバーがバックログから 優先度順に次々とタスクを取る事を想定していたが、うまくいか なかった • リーダーに作業の割り振りを任せており、リーダーとの認識の ズレがあった • 総括 • 開発チームの初期オーバーヘッドは各プロジェクト毎に発生はす るが、RFCモデルで発注・管理を行えば、複数プロジェクトを一つ の開発チームで担当しても、大きな混乱は発生しないと感じた • やはり受け入れ担当の負荷が高い • 兼任でも良いので、受入担当は2人以上が望ましいと感じた
- 67. 67 • 備考 • 今回は3ゲームプロジェクトと並行して、ベトナムラボHP改修も進 めてもらっていた • 結果として、圧倒的にベトナム主体で進めた方がスピードは速く、 発注側の負荷も低く、開発メンバーのモチベーションも高かった • 細かな指示をせずに目的のみを提示し、後は全て任せる事で非 常に自己組織化されたプロジェクトとなった 目指す形が見えた！ (RFCモデル関係ない…)
- 68. 68 ランシステム社との協働事例 • 対象プロジェクト • とくとくポイントアプリ開発 • 体制 • 発注側 • 国内で通常採用のベトナム人：1名 • ベトナム語ネイティブ • 日本語、英語：ビジネスレベル • オフショア側(ベトナム・ハノイ) • ランシステム社Androidアプリ開発エンジニア：1名 • ベトナム語ネイティブ • 英語：基礎レベル • 日本語：不可
- 70. 体制図
- 71. 71 • 仕様策定での工夫 • リーン・キャンバスを使ってなぜアプリを作るのかを明確 にした • ユーザーストーリーマッピングを行ってMVPを定義し、ム ダな機能の作りこみが発生しないように心がけた • ペーパープロトタイピングを行い、作る前に使い勝手の 検証を行うとともに、認識のズレや機能漏れの精査を 実施した
- 72. 72 • 開発環境での工夫 • ランシステム社のエンジニアに、ネットワーク周りの環境 構築が済んでいるラボセンターへ席を移してもらった • モックサーバ(node-easymock)を使ってもらう事によ り、API開発とアプリ開発を分離した • Prottのプレビューを使って画面遷移を理解してもらった
- 74. 74 • コミュニケーションでの工夫 • 最初にプロジェクトの目的の共有やアプリ全体の説明を 行うことにより、認識のズレを無くすよう心がけた • 必要に応じて仕様書や画面の翻訳を行った
- 75. 75 • 成果(現状まだ進行中) • 見積もり精度は高い(完了係数：1.17) • 見積もり精度は改善されてきている • 日本語の部分をベトナム語で説明したり、画面に表示 する内容やメッセージなどはコピペで対応できるように した結果、言語の壁が低くなったと考えている • 仕様を理解し、実装に集中できたため、アウトプットが 徐々に安定してきている • 自己組織化されてきている • 日本語ができないエンジニアでも、RFCモデルを使って 開発効率向上が実現できていると感じている
- 77. 77 • 課題 • BSE頼みな点が多く、BSEの能力にかなり依存する • 細かい仕様部分の説明はベトナム語 • 実際は8割ベトナム語、2割英語 • BSEが兼務(API開発や他の業務など)で、負荷が集中 • アプリエンジニアが1名だからこそうまくいっている • 日本語ができないエンジニアが複数になった場合で もうまくいくかは未知数 ウィさん様様！ (RFCモデル関係ない…)
- 78. 78 さいごに
- 79. 79 • 正しいものを正しくつくるというア プローチは続けていきたい • 3つのムダをなくしたい(リーン) • 間違ったものを作るというムダ • 「しなくてもいいことを効率的 にやってもムダである」 • 学び損ねるというムダ • 過度な作業切り替えによるムダ
- 80. 80 • 皆さんへの提案 • 試守破(離)がオススメ • 試したからこそ守破離の大切 さが分かる • 試した後こそが重要 • しっかりと型を学ぼう(守) • 型をしっかりと身に付けた上で、 現場の改善に取り組もう(破)
- 81. 81 試→破 ↓ 試→守→破