Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.

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

社内勉強会で発表した資料です。

  • Identifiez-vous pour voir les commentaires

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

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

×