Download as PDF, PPTX
![34
[LeanStackデモ]](https://image.slidesharecdn.com/random-150331204829-conversion-gate01/75/slide-34-2048.jpg)
![42
[Prottデモ]](https://image.slidesharecdn.com/random-150331204829-conversion-gate01/75/slide-42-2048.jpg)
![45
• エレベーターピッチ
• [技術サポート]を望んでいる
• [各種プロジェクト]にとって
• [次研グループ支援チーム]は
• [開発部署]に属しており
• [幅広い技術力]がある。
• [他の開発部署]と違って
• 我々のプロジェクトは[柔軟性とHRT
精神]がある。](https://image.slidesharecdn.com/random-150331204829-conversion-gate01/75/slide-45-2048.jpg)
![73
[node-easymockデモ]](https://image.slidesharecdn.com/random-150331204829-conversion-gate01/75/slide-73-2048.jpg)
![76
[trello, RFCツールデモ]](https://image.slidesharecdn.com/random-150331204829-conversion-gate01/75/slide-76-2048.jpg)
More Related Content
リーンスタートアップ、アジャイル開発導入事例
- 1.
- 2.
- 3.
- 4.
- 5. 5 2/25 ザッパラス社セミナー • リーンスタートアップについて •アジャイル開発について • スクラムについて
- 6. 6 2/28 Regional ScrumGathering Tokyo 2015 • 開発モデルの作り方 ～守破離の破！～
- 7.
- 8. 8 4/16 Agile Japan2015(予定) • アジャイルなオフショア開発
- 9.
- 10. 10 • 正しいものを探す試み • CSPO研修で学んだこと •リーン・スタートアップについて • 次研導入プラクティス • 正しくつくる試み • CSM研修で学んだこと • カンバンについて • RFCモデル拡張事例 アジェンダ
- 11.
- 12.
- 13. 13 CSPO研修で学んだこと(導入状況) • カードモデリング(○) • ユーザー・ペルソナ(☓) •ユーザーストーリーマッピング(○) • リーン・スタートアップ(MVP)(△) • リーン・キャンバス(△) • 共感マップ(☓) • ユーザー・インタビュー(△) • ペーパープロトタイプ(△) • デザイン思考(IDEOの事例)(☓)
- 14.
- 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 2ndEdition 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.
- 32. 32 • 実施プロジェクト • とくとくポイント(アプリ) •GMOコマース社 (新規サービス) • GMOアドパグループ (新規サービス) • 次研インターン(アプリ) • 利用ツール • LeanStack(https://leanstack.com/ ) • アッシュ・マウリャのSpark59が提供 リーン・キャンバス
- 34.
- 35. 35 • 実施プロジェクト • GMOアドパグループサービス •課題インタビュー • Z.com コンパネUI(新規) 1. モックアップ構築 2. ユーザーテスト 3. カスタマージャーニーマップ作成 インタビュー、ユーザーテスト
- 36. ストーリー Story Feeling 行動 Doing 思考 Thinking 課題 Problem 実施日時 被験者： 観察者： 対象製品： ペルソナ： 2015/3/30 Task1 Task2Task3 Task4 Task5 xxxxxxx xxxxxxx xxxxxxx xxxxxxx
- 37.
- 38.
- 39. 39 • 実施プロジェクト • とくとくポイント(アプリ) •次研インターン(アプリ) • テンプレート • POP(https://popapp.in/sketchpad/) • ツール • Prott(https://prottapp.com/ja/) (ペーパー)プロトタイピング
- 42.
- 43. 43 インセプションデッキ • 10の手強い質問と課題から構成されている • 関係者全員の認識を合わせるために実施 •テンプレート • https://github.com/agile-samurai- ja/support/tree/master/blank- inception-deck
- 44. 44 • グループ支援チームのインセプションデッキ • 我々はなぜここにいるのか？ •GMOインターネットグループの各種プロ ジェクトを"成功"に導くために、HRT精神 と技術力で支援する。
- 45. 45 • エレベーターピッチ • [技術サポート]を望んでいる •[各種プロジェクト]にとって • [次研グループ支援チーム]は • [開発部署]に属しており • [幅広い技術力]がある。 • [他の開発部署]と違って • 我々のプロジェクトは[柔軟性とHRT 精神]がある。
- 46.
- 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.
- 55.
- 56. 56 • ザックリ開発するフェーズ • 7割程度の完成度を目指す •着手する前にザックリ開発工数を見積もっても らう
- 57.
- 58.
- 59.
- 60.
- 61.
- 62. 62 複数プロジェクト並行開発事例 • 対象プロジェクト • スマホゲームC(2014年4月～) •スマホゲームN(2015年1月～) • スマホゲームS(2015年3月～) • 体制 • プロジェクト毎に日本側に専任を置き、各担当が仕様策定、発 注、受入を行う • 開発チーム(全員ベトナム人) • オフショア(ベトナム・ハノイ)：2～3人 • 日本側：1～2人 • 開発メンバーには1名リーダーを置き、リーダーがリソース、タスク 管理を行う • 開発チーム内で一次レビューを行う
- 63.
- 64. 64 • 業務管理 • Trelloを用いて、優先順位をつけてバックログに積んでおく •スプリントは最短プロジェクトに合わせて1週間で実施 • 朝会にて一括で進捗報告を行う • 結果 • メンバー自体は並列業務を行う体制は取れたが、発注側の事情 で1つのプロジェクトにリソースを集中する必要があったため、当 初想定していたような並列開発状況にはならなかった • 特定のゲームの専任メンバーが発生してしまった • 自己組織化不足 • RFCモデルを使用した事で、常にバックログには優先順位の高い 作業が一意に並べられている状況になり、複数プロジェクトとい う理由での負荷増加は無かった • 切り替えオーバーヘッドはあり • 複数プロジェクトの開発でも期日等に関する意識は変わらず、期 日通りに完了するケースが多く見られた
- 65. 65 • 反省 • 単一プロジェクト開始時と同様に、プロジェクト新規参入時の オーバーヘッドは存在する •スプリントの開始時に全ての作業内容を準備できず、スプリント 中に都度依頼する運用となってしまった • プロジェクト専任を置かず、手の空いたメンバーがバックログから 優先度順に次々とタスクを取る事を想定していたが、うまくいか なかった • リーダーに作業の割り振りを任せており、リーダーとの認識の ズレがあった • 総括 • 開発チームの初期オーバーヘッドは各プロジェクト毎に発生はす るが、RFCモデルで発注・管理を行えば、複数プロジェクトを一つ の開発チームで担当しても、大きな混乱は発生しないと感じた • やはり受け入れ担当の負荷が高い • 兼任でも良いので、受入担当は2人以上が望ましいと感じた
- 66.
- 67. 67 • 備考 • 今回は3ゲームプロジェクトと並行して、ベトナムラボHP改修も進 めてもらっていた •結果として、圧倒的にベトナム主体で進めた方がスピードは速く、 発注側の負荷も低く、開発メンバーのモチベーションも高かった • 細かな指示をせずに目的のみを提示し、後は全て任せる事で非 常に自己組織化されたプロジェクトとなった 目指す形が見えた！ (RFCモデル関係ない…)
- 68. 68 ランシステム社との協働事例 • 対象プロジェクト • とくとくポイントアプリ開発 •体制 • 発注側 • 国内で通常採用のベトナム人：1名 • ベトナム語ネイティブ • 日本語、英語：ビジネスレベル • オフショア側(ベトナム・ハノイ) • ランシステム社Androidアプリ開発エンジニア：1名 • ベトナム語ネイティブ • 英語：基礎レベル • 日本語：不可
- 69.
- 70.
- 71. 71 • 仕様策定での工夫 • リーン・キャンバスを使ってなぜアプリを作るのかを明確 にした •ユーザーストーリーマッピングを行ってMVPを定義し、ム ダな機能の作りこみが発生しないように心がけた • ペーパープロトタイピングを行い、作る前に使い勝手の 検証を行うとともに、認識のズレや機能漏れの精査を 実施した
- 72. 72 • 開発環境での工夫 • ランシステム社のエンジニアに、ネットワーク周りの環境 構築が済んでいるラボセンターへ席を移してもらった •モックサーバ(node-easymock)を使ってもらう事によ り、API開発とアプリ開発を分離した • Prottのプレビューを使って画面遷移を理解してもらった
- 73.
- 74. 74 • コミュニケーションでの工夫 • 最初にプロジェクトの目的の共有やアプリ全体の説明を 行うことにより、認識のズレを無くすよう心がけた •必要に応じて仕様書や画面の翻訳を行った
- 75. 75 • 成果(現状まだ進行中) • 見積もり精度は高い(完了係数：1.17) •見積もり精度は改善されてきている • 日本語の部分をベトナム語で説明したり、画面に表示 する内容やメッセージなどはコピペで対応できるように した結果、言語の壁が低くなったと考えている • 仕様を理解し、実装に集中できたため、アウトプットが 徐々に安定してきている • 自己組織化されてきている • 日本語ができないエンジニアでも、RFCモデルを使って 開発効率向上が実現できていると感じている
- 76.
- 77. 77 • 課題 • BSE頼みな点が多く、BSEの能力にかなり依存する •細かい仕様部分の説明はベトナム語 • 実際は8割ベトナム語、2割英語 • BSEが兼務(API開発や他の業務など)で、負荷が集中 • アプリエンジニアが1名だからこそうまくいっている • 日本語ができないエンジニアが複数になった場合で もうまくいくかは未知数 ウィさん様様！ (RFCモデル関係ない…)
- 78.
- 79. 79 • 正しいものを正しくつくるというア プローチは続けていきたい • 3つのムダをなくしたい(リーン) •間違ったものを作るというムダ • 「しなくてもいいことを効率的 にやってもムダである」 • 学び損ねるというムダ • 過度な作業切り替えによるムダ
- 80. 80 • 皆さんへの提案 • 試守破(離)がオススメ •試したからこそ守破離の大切 さが分かる • 試した後こそが重要 • しっかりと型を学ぼう(守) • 型をしっかりと身に付けた上で、 現場の改善に取り組もう(破)
- 81.
- 82.