社内スタートアップによる組織の成長に伴い発生する痛みとその解決策について45分拡大版 #devsumi #devsumiB

27,678 views

Published on

Developers summit 2015の20-B-5での発表資料になります。

Published in: Technology

社内スタートアップによる組織の成長に伴い発生する痛みとその解決策について45分拡大版 #devsumi #devsumiB

  1. 1. 社内スタートアップに よる組織の成長に伴い 発生する痛みと、その 解決策について 拡大版 20分→45分 Recruit Holdings Recruit Institute of Technology Media Technology Lab Itsuki KURODA @i2key Scrum&LEAN STARTUP導入 20-B-5
  2. 2. Recruit Holdings Recruit Institute of Technology Media Technology Lab 黒田 樹 (@i2key) <= Follow me :-) ! 前職ではSIerで官公庁系大規模システムのアーキテクト。 現在は、全世界でシリーズ累計1000万DLのアプリ cameranシリーズの開発全体責任者(開発、採用、組織構 築、プロセスetc)社内でリーンスタートアップやアジャイル の導入を推進しています。 http://mtl.recruit.co.jp
  3. 3. cameranというアプリにおける 組織拡大に伴い発生した数々の問題とその対処方法につ いての発表になります。
  4. 4. 60% Agile Scrum 40% LEAN STARTUP
  5. 5. いろいろな文脈によって 制約になるものがちがう 書籍アジャイルサムライより引用
  6. 6. 例えば 死守 死守 死守 コストと品質と仕様を満たせれ ば納期は遅れても多めにみるよ 書籍アジャイルサムライより引用
  7. 7. 死守 死守 死守 納期守るために 若干品質は捨てよう! 書籍アジャイルサムライより引用
  8. 8. ÃフßァØッ!!?? 死守 死守 死守死守 書籍アジャイルサムライより引用
  9. 9. 嫌な予感しか しないwwwwww 死守 死守 死守死守 書籍アジャイルサムライより引用
  10. 10. 今回はtoC向けの社内スタートアップ (責任が自己完結可能)でありスコー プで開発をコントロールし易い文脈 自由が効き易い 死守 死守 死守 書籍アジャイルサムライより引用 俺を使ってくれ!
  11. 11. 第一部 ヒットからカオスへ 突然の大ヒット。 全ての連鎖の始まりがここに。 第二部 師との出会い 恩師との出会い。 そして我々は本当のスクラムを知る。 第三部 俺たちはリーンだ! 様々な師達に教えを受け、 リーンスタートアップを会得 そして、自分達のプロセスに昇華 第四部 リーンのその先にあったもの エンジニアの新しい働き方
  12. 12. 第一部 ヒットからカオスへ 突然の大ヒット。 全ての連鎖の始まりがここに。 第二部 師との出会い 恩師との出会い。 そして我々は本当のスクラムを知る。 第三部 俺たちはリーンだ! 様々な師達に教えを受け、 リーンスタートアップを会得 そして、自分達のプロセスに昇華 第四部 リーンのその先にあったもの エンジニアの新しい働き方
  13. 13. •・ プロジェクト開始時の体制 • プロデューサー • エンジニア(サーバ) • エンジニア(iOS)※常駐外部パートナー • デザイナー • チームは、メンバー全員の打ち合わせで全ての課題が解 決できる規模だった。 • ウォーターフォールではない、アジャイルのような何か。
  14. 14. 大ヒット御礼!!!! 広告・ブースト無しで、 リリース3日で50万DL 10日で100万DL ※今回はヒット後の組織成長の話なので、 そのヒットを作り込んだ過程は省きます (結果的に後から振り返るとものすごく顧客開発してました)
  15. 15. 突然の大ヒットにより、このままイケソウな兆しを 感じた上層部は、更に追加投資することにした。 ! 元々、地道に検証しながら進めて行こうとしていた 画像SNS化計画をその資金でフルスロットル開発す ることが決定。※2ミリもリーンじゃない。 超特大開発の 幕開け
  16. 16. 開発規模大きいし、 まずは・・・
  17. 17. エンジニア増加!!
  18. 18. 今度はディレクターネック
  19. 19. ディレクター増加!! 5
  20. 20. 今度はディレクタがアライ アンスに手が回らない
  21. 21. アライアンス担当増加!!
  22. 22. デザイナもデザイナも!
  23. 23. エンジニアも、もっと!!
  24. 24. どうなるか・・・
  25. 25. ちょw体制wwwwwwwww プロデューサー デザイナ エンジニア Before アライアンス デザイナ エンジニア ディレクター プロデューサー Lead Engineer Server Engineer iOS Engineer Android Engineer After \(^o^)/
  26. 26. 何が起きるのか・・・??
  27. 27. ・目標に対する成長スピードの鈍化 ・やるべきことに着手できていない焦り ・日々発生する最優先タスクに振り回される現場。 (「最優先」の中で最優先とか・・・。) ・毎日行われる進 会議というなの大検討会&浪費される時間 ・伝言ゲームによるコミュニケーションコストの肥大化 ・プロデューサー - エンジニア間の発注者-受注者的関係性 ・プロデューサー - エンジニア間の関係性の悪化(ギスギスする) ・技術的負債の山 ・日々詰み上がるバグの山を解決するだけで時間が過ぎていく。 ・現場まで降りてこない方針。価値観。文脈。現場判断出来ない。
  28. 28. コミュニケーション① Lead Engineer Server Engineer iOS Engineer Android Engineer Engineer team プロデューサー ディレクター プロデューサー team ①この仕様ってこ れでいいのかな? ②ちょっと確認し てみますね ③ここの仕様で質問 きたのですが、こう 回答していいすか? ④じゃ、それで。 ⑤あざーす! ⑥うお・・・wこれインパクト でけえ・・。サーバエンジニア 以外にも影響でるな・・・。 ⑦りょーかいで す・・・ ⑦りょーかいで す・・・ 伝言ゲーム
  29. 29. コミュニケーション② Lead Engineer Server Engineer iOS Engineer Android Engineer Engineer team プロデューサー ディレクター プロデューサー team ①この機能なるは やでいれよ! ②ワイヤー作って 調整しますー ③仕様理解しました。各エン ジニアにディスパッチして工 数の見積もりを依頼します。 ④全部やったら1ヶ月くらいか かるね。(今やってるの全部 手をとめたらね) ④うーん、2週間くらいか なぁ。(今やってる開発作 業はどうなるんだろ・・・) ⑤現在着手中のもあると思う ので、バッファ詰んで1.5ヶ月 にしましょう。そう伝えます。 ⑥1.5ヶ月ですね。 了解です。 ⑦了解です。この間依 頼した機能はまだ出来 上がらないのかな。 ボトルネック
  30. 30. コミュニケーション③ Lead Engineer Server Engineer iOS Engineer Android Engineer Engineer team プロデューサー ディレクター プロデューサー team ①あそこの機能結構やっつけで作っ たのでリファクタリングしてコード 品質上げましょう。ついでにフレー ムワークのバージョンもあげましょ うか。 ②いいっすねー!やりま しょー!1週間くらいあればで きそうですね! ③技術的負債を解消するためのタス クがあることを知らない。 知らないとこで タスク作成
  31. 31. コミュニケーション④ Lead Engineer Server Engineer iOS Engineer Android Engineer Engineer team プロデューサー ディレクター プロデューサー team ①競合が新機能い れた、やばい、こ れなるはやで! ②ワイヤー作って 調整しますー ③仕様理解しました。各エン ジニアにディスパッチして工 数の見積もりを依頼します。 ④前回依頼あった実装まだ全 然おわってないのに・・・。 見積もりコストかなりかかる し・・・。2週間くらいかな。 ④1週間くらいかな。 ⑤(リファクタリング対象と実装箇 所が被るので、リファクタリングを 実施してから、本タスクは着手しま しょう。)実装には2週間くらいあ れば。 ⑥2週間ですね。了 解です。 ⑦了解です。この間依 頼した機能はまだ出来 上がらないのかな。 知らないとこで優先付け
  32. 32. コミュニケーション⑤ Lead Engineer Server Engineer iOS Engineer Android Engineer Engineer team プロデューサー ディレクター プロデューサー team ①このバグやばい! なるはやでなおし て!!! ②そんな重要なバグなのでしょ うか?了解です。最優先で対 処します。 ③了解です!すぐになおしま す。暫定対処は、すぐだけど、 本格対処は結構工数かかりそ うだなー。 ④今回は本格対処まで実施したいの で、時間結構かかります。暫定版は 明日リリースします。 ⑥了解です。 どんなバグでも最優先対応
  33. 33. コミュニケーション⑥ Lead Engineer Server Engineer iOS Engineer Android Engineer Engineer team プロデューサー ディレクター プロデューサー team ①まだ新機能がリ リースされない。 何やってんだ!! ②そんなこといわれても、何 でもなるはやじゃないすか。 ③こんなに毎日終電や徹夜し てまで頑張ってるのに、なん で怒られなくてはならないの だろう・・・・ ギスギス・・・ \(^o^)/
  34. 34. 今なら言える失敗 • スケーラブルな組織設計でないのにスケールさせてしまった。管理 能力の高いチームは自らチームの成長を抑制するか、その代わりに 管理キャパシティをスケールさせる。 • バニティメトリクスに支配されていた。表面上のMAUを稼ぐのは人 を増やしてパワーを掛ければ稼げる(ので、人を増やしてしまう) • プロジェクト計画の方法論、サイクル、カレンダーが無い • 仕事の優先順位決定のメカニズムが無い • 明確に定められたバグトリアージとトラッキングが無い • コミュニケーションチャネル設計が無い
  35. 35. 少人数でならうまく行く 「ウォーターフォールではない何か」を 「アジャイルにやってます」と言って プラクティスのつまみ食いしてただけ。 少人数ならどんなやり方だって それっぽくうまくいくので勘違いしがち。
  36. 36. 第一部 ヒットからカオスへ 突然の大ヒット。 全ての連鎖の始まりがここに。 第二部 師との出会い 恩師との出会い。 そして我々は本当のスクラムを知る。 第三部 俺たちはリーンだ! 様々な師達に教えを受け、 リーンスタートアップを会得 そして、自分達のプロセスに昇華 第四部 リーンのその先にあったもの とてもシンプルな真意と それを支える価値観に触れる
  37. 37. 師 USスタートアップの現場で使われている 組織の成長にあわせたアジャイルを 導入するためにメンターとして 500Startupsのメンター でもあるJames Levine氏を師として招く https://www.linkedin.com/in/jamesdlevine/ja
  38. 38. やりたいこと。これへの対処
  39. 39. チームを昔のように小さくする。 みんなで顔を合わせれば 問題は大抵解決するような規模に。 エンジニアをとりまとめるような エンジニアリーダーロールを廃止する。 全エンジニアが直接プロダクトオーナーと コミュニケーションするようにチームをフラット化する。 仕事の見える化 タスクおよびそれの規模感の見える化により、 優先付けやトレードオフが機能するようにする。 10
  40. 40. スクラムを 一定のサイクルで仕事が行われるコンテナ として採用し、 それが機能してから XP等の各種プラクティスをプラグインとして あとから入れて行こうという方針で進めた。 ! 今解決したいのは、ペアプロしたいわけじゃないし TDDしたいわけじゃない。 何でも最優先を脱却し、 トレードオフをフェアに機能させること。 10
  41. 41. 「リーン開発の現場」より スクラム XP 10
  42. 42. iOSエンジニアからScrumチーム化 Lead Engineer Server Engineer iOS Engineer Android Engineer Server Engineer Android Engineer iOS Scrum team Lead Engineer 兼務 旧Engineer team 旧Engineer team Scrum Master プロデューサー ディレクター PO team Product Owner Sub PO 旧プロデューサー team iOS team Product Backlog Lead Engineerが1st Sprintのスクラムマス ターに。 10
  43. 43. スクラム始めるアルアル • 見積もりを相対値でやらないといけない • プランニングポーカーしないといけない • インセプションデッキつくらないといけない • ベロシティを計測しないといけない • タスクはユーザーストーリーでかかないといけない • みんな自己組織化しないといけない 11
  44. 44. んなこたぁーない! 開発のコンテキストにより、 価値観や必要なプラクティスは変わるし、 型にはめたって意味ない。 最初こんなのどれもやらなかった。 11
  45. 45. 今回のケースで大事なこと タスクの優先順位付け サービスをグロースさせるために、 リソースが適した優先順位で 優先すべき箇所に使われている状態を作ること 11
  46. 46. 優先順位付けするために必要なもの ・優先順位付けを行うための判断材料があること  そのために、見える化が必要   エンジニアの時間を使っていること全て見える化    休み、会議、定常業務、バグ改修、開発タスク、    「ちょっといいですかこれってどうなってますっけ」    による損失の見える化   その見積もり    理想日見積もり。相対値はチーム練度上がったら。    8時間=1日=1pt ! ・優先順位付けするサイクル・リズムが必要  プランニング、デイリー、レビュー、レトロスペクティブ 11
  47. 47. http://www.acunote.com 12
  48. 48. スプリントバックログの内訳例 [開発] ○○実装タスク 2pt    ○○実装タスク 1pt    ○○実装タスク 1pt    ○○実装タスク 1pt [バグ] 既知バグ対応タイムボックス 1pt    今後発生するバグ対応タイムボックス 1pt [MTG]プランニングミーティング 0.5pt    デイリースクラム 0.5pt    レビュー/リリースミーティング 0.5pt    レトロスペクティブ 0.5pt [休暇] 2/20デブサミ参加 1pt 1sprint = 2weeksの場合 営業日は10日→上限10pt エンジニア1名分 ※4人チームならこれをx4 12
  49. 49. 開発タスク管理 全てのタスクは理想日にて見積もり。 1スプリントの稼働日の合計を出し、 それに合わせてスプリントバックログ にタスクを入れていく。 ! 相対値見積もりは実施していない。 12
  50. 50. 以下の2つにわけて固定のタイムボック ス化しバグ対応コストを管理。 ・将来発生する作業の予約 ・既知のバグ修正 バグ対応タイムボックス内で優先順位順 にバグを改修していく。 ! 開発タスクとバグ対応タスクに割く、時 間の割合はプロダクトオーナーが状況に 応じてバランスをとる バグ対応コスト管理 12
  51. 51. ミーティングコスト管理 全てのミーティングをコスト管理。 ! 何時間もかけたミーティングを行うと、 このスプリントで作ることが出来る機能 が減ることを意識させる。 ! 振り返りにて、ミーティングを減らす方 向にバイアスがかかる。 13
  52. 52. 休暇予定管理 全ての見積もりが稼働日換算なので、 有給をとる日は、コストとして扱う。 13
  53. 53. このやり方を サーバチーム、Androidチームへ、スケール 13
  54. 54. サーバーエンジニアをScrumチーム化 Server Engineer Android EngineerLead Engineer 兼務 Scrum Master Server Scrum team 旧Engineer team iOS Scrum team Scrum Master PO team Product Owner Sub PO iOS team Product Backlog Server team Product Backlog スクラムマスター 交代 Lead Engineerが1st Sprintのスクラムマス ターになり、スクラム ウェイを伝達していく。 13
  55. 55. AndroidエンジニアをScrumチーム化 Android Engineer Scrum Master Server Scrum team Android Scrum team iOS Scrum team Scrum Master PO team Product Owner Sub PO iOS team Product Backlog Server team Product Backlog Scrum Master Android team Product Backlog スクラムマスター 交代 スクラムマスター 交代
  56. 56. Scrumチーム間の連携のためScrum of Scrums Scrum Master Server Scrum team Android Scrum team iOS Scrum team Scrum Master PO team Product Owner Sub PO iOS team Product Backlog Server team Product Backlog Android team Product Backlog Scrum Master Scrum of Scrums スクラムマスター 交代 スクラムマスター 交代 スクラムマスター 交代 15
  57. 57. 今回の取り組みのようなスケールさせていく アジャイルな組織作りで参考にした文献・記事の一部 http://www.continuousagile.com/unblock/ea_matrix.html Matrix of Services ( MAXOS )
  58. 58. 今回の取り組みのようなスケールさせていく アジャイルな組織作りで参考にした文献・記事の一部 http://www.scaledagileframework.com Scaled Agile Framework ( SAFe )
  59. 59. 今回の取り組みのようなスケールさせていく アジャイルな組織作りで参考にした文献・記事の一部 Scaling Agile @ Spotify https://dl.dropboxusercontent.com/u/1018963/Articles/SpotifyScaling.pdf
  60. 60. バグが出るたびに最優先タスクになる状況からの脱却 なんだか毎日バグなおしてるだけでおわる状況の脱却 バグの優先順位を決めるメカニズムを作る バグマネージメント 16
  61. 61. スプリントバックログの内訳例 [開発] ○○実装タスク 2pt    ○○実装タスク 1pt    ○○実装タスク 1pt    ○○実装タスク 1pt [バグ] 既知バグ対応タイムボックス 1pt    今後発生するバグ対応タイムボックス 1pt [MTG]プランニングミーティング 0.5pt    デイリースクラム 0.5pt    レビュー/リリースミーティング 0.5pt    レトロスペクティブ 0.5pt [休暇] 2/20デブサミ参加 1pt 1sprint = 2weeksの場合 営業日は10日→上限10pt エンジニア1名分 ※4人チームならこれをx4 ここのタイムボックスで 対応するために、優先順位を決める 16
  62. 62. Server 例外ログ 問い合わせ管理システム クラッシュログ 監視システム ユーザー メンバー バグトラッキング システム バグトリアージMMTTGG バグマネージメントMMTTGG iOS Engineer Android Engineer Server Engineer Daily Weekly iOS Engineer Android Engineer Server Engineer Product Owner Tester 一次切り分け
  63. 63. バグトリアージMTG ■参加者 iOSエンジニア、Androidエンジニア、サーバエンジニア各1名 ! ■内容 災害医療での1次切り分け。 クリティカルかどうかだけの切り分けを毎日15分くらいで実 施。 切り分けが目的であり、調査・改修は行わない。切り分けのた めに調査時間が必要になるのであればSprintのポイントに工数 として発生タイミングで計上。 クリティカルの場合は、ProductOwner相談の上、即時対応 16
  64. 64. バグマネージメントMTG ■参加者
 ProductOwner、テスター、iOS、Android、サーバ各1名 
 ■アジェンダ ●前回のこのミーティング以降に発生したクリティカルバグ対 応について ・振り返り ・不具合の分析・歯止め(試験観点追加) ・プロセスの改善(1次切り分けロジック、対応フロー等) ●優先度の高いYouTrack上のバグの確認 ・内容の確認 ●その他バグの優先度の見直し ●必要に応じてバグマネジメントプロセスの改善 17
  65. 65. Quality + Cost + Delivery + Scope のバランシング デリバリーの認識を変える リリースマネージメント デリバリーは決まった日に 勝手にやってくるのだ それにのるかのらないかお前次第 17
  66. 66. Sprint #2Sprint #1 Sprint #3 ○○機能 ○○機能 ○○機能 バグ修正 バグ修正 バグ修正 3月1日(固定) 3月7日(固定) 3月14日(固定) 固定リリース タイミング 固定リリース タイミング 固定リリース タイミング 例:リリースタイミングは1週間毎にやってくる。そのときリ リースしたいものがあればリリース対象に入れる。 17
  67. 67. リリースカレンダー
  68. 68. そんな悠長なこと言ってらんないんだって!某社とアラ イアンスを組んでしまって、急遽、明後日までにリリー スしてもらわないと困るんだよ! ではリリース日を優先でク○コードで リリースしまっせ!その代わりにリリース後に技術的 負債改修期間が必須です。 http://doda.jp/engineer/it/guide/001/19b.html 参考:「技術的負債」の返済ルールを作る 株式会社ドワンゴ清水氏 Product Owner Engineer 書籍アジャイルサムライより引用 書籍アジャイルサムライより引用 17
  69. 69. Sprint #2Sprint #1 Sprint #3 ○○機能 3月1日(固定) 3月7日(固定) 3月14日(固定) 固定リリース タイミング 固定リリース タイミング 固定リリース タイミング リリース日優先タスクは こう対応するとみんな幸せになれる 技術的負債解消タスク 本来はこのくらいかかる予定だった なるはや リリース ク○コード 脱ク○コード 18
  70. 70. プロダクトオーナー負荷分散 ある程度、サービス規模が大きくなってくると プロダクトオーナーがプロダクト自身に向き合う時間が 取り難くなってくる。 →ステークホルダーマネージメントの増大 →各種調整業務(期待値、目標、コミット、etc) プランニング等に出席できないことが増える。 開発チームがプロダクトオーナーに話しかけることが 出来なくなってしまう。 18
  71. 71. プロダクトオーナータスク 責任・権限 作業を遂行する プロダクト マネージメント セールス 資金調達 アライアンス : 採用 プロダクトオーナー タスク Product Owner ただの 作業者 18
  72. 72. こうやりがち 責任・権限 作業を遂行する プロダクト マネージメント セールス 資金調達 アライアンス : 採用 プロダクトオーナー タスク Product Owner ただの 作業者 お伺い 18
  73. 73. 増えるとこうなる (スケーラブルじゃない) 責任・権限 作業を遂行する プロダクト マネージメント セールス 資金調達 アライアンス : 採用 プロダクトオーナー タスク Product Owner お伺い ボトルネック 19
  74. 74. プロダクトオーナープロキシ 責任・権限 作業を遂行する プロダクト マネージメント セールス 資金調達 アライアンス : 採用 プロダクトオーナー タスク Product Owner Proxy Product Owner 19
  75. 75. プロダクトオーナープロキシ 特定の状況でプロダクトオーナーの代理になれる人 プロダクトオーナーの代わりに、開発チー ムとのプロダクトバックログに関するやり とりを支援。 プロキシは意思決定の権限(バックログの 優先順位決定、仕様決定等)が与えられ、 正当な理由なくその決定は覆さない。 プロダクト全体の最終的な責任自体は、プ ロダクトオーナーが持っている。 書籍アジャイルサムライより引用 19
  76. 76. これらの結果:得たもの Product Owner目線 ・働き方のリズムが出来る ・エンジニアの状況がみえる ・自分のオーダーの規模感が知れる ・大体いつ何がリリースできそうかわかる ・意思決定する際の材料が増えた ! Engineer目線 ・タスクがどんどん詰め込まれることが無くなった ・なんでも最優先がなくなった ・スカンクワークではなく技術的負債対策に臨める ・トレードオフによりQCD調整がききやすくなる 19
  77. 77. これらの結果:失ったもの アジャイルは時に残酷 ・Scrumにより個人の生産性も可視化される  進 が思わしくない場合にも、日々のデイリーMTGにて  消化ポイントが0のままであることを報告し続けることに。  (問題の可視化だから良いのだけど) ・生産性をチーム単位で見るべきだが、メンバとしては、  個人単位でも見えてしまい、生産性が低い場合は、  居づらさ・気まずさが発生する。  本来この可視化の効果により得られるメリットは大きいが  可視化しすぎる状況について来れないエンジニアも出てくる ・能動的に動かなければならなく、他責に出来ない。 ・みんながこの働き方を好きなわけではない。 19
  78. 78. • スクラムを入れたから解決するのではなくて、見える化が進 むので結果的にアクションを打てるタイミングがはやくな り、問題を小さい段階で早期解決出来る。 • プロジェクトや開発の文脈により、解決すべき問題が違うた め本に書いてある通りのことをそのまま全部やろうしてもう まくいかない。プラクティス厨になるだけ。 • 価値観も大きく変わる。限られたリソースをどう有効に使う か。これが全てになる。その目線がそろった状態から、各種 プラクティスの導入を行うことが大事。 • メンバーを信頼することが大前提。 学び 19
  79. 79. 信頼が大事・信頼出来るメンバーを集めること ・信頼してもらうためにパフォーマンスを出すこと それがないと、 権限委譲も、トレードオフもなんも成立しない。 プロダクトオーナープロキシーとかもってのほか。 見積もり=コミットになっちまう。 アジャイルも、根底から崩れる。 幼稚園みたいなこというけど 20
  80. 80. 信頼が無いチーム 「見積もりはコミットじゃなくただの予測だ」だと? こんなやり方してたら、エンジニアがサボってたら リリースどんどん遅れてく一方じゃないか。 なんで信頼出来ない人をメンバにいれてるの? 今のメンバでやる必然性はなに? 我々にそんなお金ないよね? 書籍アジャイルサムライより引用 信頼出来る奴を チームに入�れることが アーリーステージに 最も大事なこと!! 20
  81. 81. 現在では • スクラムマスターは持ち回りの当番制 • 全員がスクラムマスターを出来るようになっているため、 各自が自走出来る状態になっている。 • 結果的に、スクラムマスター専業の稼働は減る。 • 自己組織化が進む。 • 振り返りから、プルリク駆動開発の実施やSlack+hubotに よるChatOpsも実施。良くあるプランニングポーカー等各 種プラクティスも後から導入。(良くある最近の開発手法) 20
  82. 82. 20
  83. 83. 大きな変化 「エンジニアさん!数値確認したいので、 ○○のデータとってください!」 ↓ 非エンジニアのプロダクトオーナーが 副問い合わせとか駆使して 自らSQLを叩いて数値確認をしている (こういうのを見ると自動化してあげたくなる) 20
  84. 84. ひとときの平穏
  85. 85. しかし・・・
  86. 86. 元々の課題だった 成長スピードの鈍化が 改善されない・・・
  87. 87. そもそも・・・ 今やっているタスクは本当に 成長に寄与するものなのか
  88. 88. 第一部 ヒットからカオスへ 突然の大ヒット。 全ての連鎖の始まりがここに。 第二部 師との出会い 恩師との出会い。 そして我々は本当のスクラムを知る。 第三部 俺たちはリーンだ! 様々な師達に教えを受け、 リーンスタートアップを会得 そして、自分達のプロセスに昇華 第四部 リーンのその先にあったもの エンジニアの新しい働き方 22
  89. 89. 新たな問題 プロダクトバックログに起票されるタスクが本当にやるべ きことなのか。やるべき理由はあるのか。 ! もっと効率よく出来ないのか ! そのタスク(機能)をリリースしたあとの効果はタスク(機 能)毎にわかるのか。結果から学びを得ているのか。 ! やっていることはサービスの成長に直結しているのか。 22
  90. 90. 新たな問題 プロダクトバックログに起票されるタスクが本当にやるべ きことなのか。やるべき理由はあるのか。 ! もっと効率よく出来ないのか ! そのタスク(機能)をリリースしたあとの効果はタスク(機 能)毎にわかるのか。結果から学びを得ているのか。 ! やっていることはサービスの成長に直結しているのか。 この要件ってエンジニアの 有限な時間使ってまでやる意味あんの? この要件ってビジネス目標に 寄与すんの?何なの?自己満なの? 22
  91. 91. LEAN STARTUPという 考え方があるらしい LEAN STARTUPという 考え方があるらしい 22
  92. 92. 「全ては仮説・思い込み」 という見地にたつ。 その仮説を細かく分解して、 一つ一つ検証し実証することで 不確実性の高いビジネスの リスクを潰していく考え方。 23
  93. 93. 明日から使えるリーンフレーズ 「プロダクトバックログの この機能の実装が必要である エビデンスはありますか?」 23
  94. 94. 「お前の中ではそうなんだろうな お前の中ではな」 明日から使えるリーンフレーズ 23
  95. 95. スタートアップマニュアル アントレプレナーの教科書 リーンスタートアップ 顧客開発モデルのトリセツ RUNNING LEAN LEAN UX LEAN Analytics リーン開発の現場    :    :    : 先人の知恵に触れる
  96. 96. 可能な限り1次ソースの師達に教えをこう http://mtl.recruit.co.jp 25
  97. 97. 500Startupsメンター James氏 (LeanStartup)
  98. 98. Pivotal Labs Janice氏 (Lean UX)
  99. 99. Hooked著者 Nir氏 (UX)
  100. 100. Lean Analytics著者 Alistair氏 (Lean Analytics)
  101. 101. IDEO @SFオフィス デザインシンキング ワークショップ (デザインシンキング)
  102. 102. 全ての意思決定において 無駄の無い判断をしていること ・思い込みを排除し全てを仮説と捉える ・コストに対する学びを最大化する ・失敗による損失を最小化する   成功を保証するプロセス ! そのために、効率的(例:小さく/短く/安く)に 仮説を検証して学びを得る(ことが多い) 真意 25
  103. 103. 全ての意思決定において 無駄の無い判断をしていること ・思い込みを排除し全てを仮説と捉える ・コストに対する学びを最大化する ・失敗による損失を最小化する   成功を保証するプロセス ! そのために、効率的(例:小さく/短く/安く)に 仮説を検証して学びを得る(ことが多い) 真意 当時は真意を2ミリも 理解できていないけど・・・ 浅い理解
  104. 104. ファイル同期がいかに便利か、どのように動作す るのかのプロモーション動画を作成し、Youtube にアップロード。HackerNewsに流して、 事前登録者数をモニタリングでニーズを実証。 開発リソース使うまえに仮説を小さく実証する例 26
  105. 105. サンフランシスコにある自分のオフィスのMTG ルームを人が泊まれるようにして、Googleに広告 を出して、人が応募してきて、お金を払って、泊ま るのかを検証。 開発リソース使うまえに仮説を小さく実証する例 26
  106. 106. 例)写真加工アプリにフィルタ購入機能を作ろう!!やりた いことの実装工数は3人月くらいかかりそうです。 ! あなたがこのプロダクトのオーナーならどうしますか? ! ①フィルタ購入機能を3人月かけて実装する  (一切購入されないリスクそのまま) ②フィルタ購入するボタン(ダミー)を用意して、全体のユー ザーの10%に表示して確認し、本当に購入ボタンが押された 回数を測定してから開発着手の判断をする。工数は2人日。 (本当に購入されるのかのみを検証) ②のほうが無駄の無い判断してるぽい 機能追加ではこんな感じ 26
  107. 107. 100円で 購入 100円で 購入 現在開発中です! 近日リリース予定です! <ポップアップ> ユーザー全体の10%にだけ 表示されるボタン
  108. 108. 顧客開発モデルに則って現状の理解をする。 ビジネス仮説を全てLeanCanvasに書き出す。 既に実証済みのことと、そうでないこを明らかにする 顧客セグメントを明らかにする 市場タイプを選ぶ 顧客との関係 キーパートナー 売上/プライシング 顧客理解 トラフィック/競合分析 顧客の行動測定 アドバイザリーボードメンバーの選定開始    :    : 顧客開発でやるべきこと Lean Canvas 27
  109. 109. LEAN CANVAS 顧客は誰?課題は何? 解決策は? 価値は何? 圧倒的優位性は何? コスト構造は? 売り上げは? 顧客にリーチするための チャネルは 何を測る? 27
  110. 110. LEAN CANVAS 顧客は誰?課題は何? 解決策は? 価値は何? 圧倒的優位性は何? コスト構造は? 売り上げは? 顧客にリーチするための チャネルは 何を測る? 27 ① ①③ ④
  111. 111. 顧客発見 顧客実証 顧客開拓 組織構築 Problem Solution Fit Product Market Fit Pivot Scaling Agile 実証済み 実証済み実証済み 実証済み 実証済み 実証済み 実証済み 実証済み 実証済み 実証済み 実証済み 実証済み 実証済み 実証済み 今自分達がスタートアップの どのフェーズに いるかを認識する 27
  112. 112. 顧客発見 顧客実証 顧客開拓 組織構築 Problem Solution Fit Product Market Fit Pivot Scaling Agile 実証済み 実証済み実証済み 実証済み 実証済み 実証済み 実証済み 実証済み 実証済み 実証済み 実証済み 実証済み 実証済み 実証済み 27
  113. 113.   Agile 顧客発見 顧客実証 顧客開拓 組織構築 Problem Solution Fit Product Market Fit Pivot ユーザーの深い課題/ニーズを把握し 解決策を提示しそれが刺さっている ビジネスモデルの成立することが 実証できている (Engine of Growthが装着できている) 例)CAC < LTV Scaling 例)Retentionしている MAU右上がり 28
  114. 114.   Agile 顧客発見 顧客実証 顧客開拓 組織構築 Problem Solution Fit Product Market Fit Pivot ユーザーの深い課題/ニーズを把握し 解決策を提示しそれが刺さっている ビジネスモデルの成立することが 実証できている (Engine of Growthが装着できている) 例)CAC < LTV Scaling 例)Retentionしている MAU右上がり ←いまココ(※当時) 28
  115. 115. まだ実証出来ていない仮説に対して リスクの高い順に優先順位をつけて実証していく 実証済 実証済 実証済 実証済 28
  116. 116. じゃあ、どうやって 仮説を検証するの??? MVPってのがあってな バックリした例としては、さっきの DropBoxの動画 AirBnBのオフィス 写真アプリのダミー購入ボタン 書籍アジャイルサムライより引用 書籍アジャイルサムライより引用 28
  117. 117. MVPとはMinimum Viable Product(検証可能な最小限の製品)。 Productと言ってるけど製品じゃなくてよい。 目的である仮説を検証できればよいので、 それができるものならなんでもMVPと言ってよい(と思う) Build->Measure->Learn MVP ビジネスアイデアを仮説として捉えて 検証するためのプロセス。 仮説検証のためのMVPをBuildして それを元にMeasureし、 その結果得られたデータからLearnする。 29
  118. 118. MVPで検証する MVPで検証する MVPで検証する MVPで検証する MVPで検証する MVPで検証する MVPで検証する MVPで検証する MVPで検証する MVPで検証する こういう場合もあるし 29
  119. 119. 1つのMVPで 全ての仮説を検証する こういう場合もある 29
  120. 120. 型を学ぶ
  121. 121. アジャイル開発 Scrum コホート分析/ファネル分析/ A/Bテスト基盤 MVP Canvas 仮説検証設計 我々の仮説検証サイクルの型 30
  122. 122. アジャイル開発 Scrum コホート分析/ファネル分析/ A/Bテスト基盤 MVP Canvas 仮説検証設計 済 我々の仮説検証サイクルの型
  123. 123. アジャイル開発 Scrum コホート分析/ファネル分析/ A/Bテスト基盤 MVP Canvas 仮説検証設計 我々の仮説検証サイクルの型
  124. 124. 実装した機能(MVP)毎に効果を検証する コホートAにリリース 結果数値をウォッチ コホートBにリリース 結果数値をウォッチ コホートCにリリース 結果数値をウォッチ やったことの単位に結果を見ること 全部同時にリリースした場合、合計値でユーザー数などを 見ていても何が寄与したのかが見えない。
  125. 125. https://www.leanplum.com A/BテストプラットフォームとしてLeanplumを採用
  126. 126. 計測例 •仮説 • SNS型サービスだが、ユーザのサインアップ率が悪 い。現在他人の投稿はクローズドでサインアップした ユーザーにしか見えない。サインアップしてないユーザ にも見えるようにすることでSNSのUXを事前体験・学 習させるとアカウント登録率があがるのはないか。 •MVP • サインアップ不要で他人の投稿を閲覧出来る機能を実 装しユーザ数%対象に公開して計測。 •学びたいこと • サインアップ率の上昇。及び、既存機能への悪影響 度。
  127. 127. 実装した機能毎にコホートxA/Bテストを行い、 様々なトレードオフを意識して判断する。
  128. 128. http://www.localytics.jp 全体の指標モニタリングのために Localytics採用(GAの代わり)
  129. 129. リリース後はコホートで対象バージョンの リテンション等を計測。この画面は7日間継続率。 ※サンプルデータです!
  130. 130. ver1から参加したユーザー ver2から参加したユーザー ver3から参加したユーザー フォロワー数▲人のユーザー フォロワー数■人のユーザー フォロワー数●人のユーザー このように縦に見ないほうがよい場合がある
  131. 131. コホート分析の例 ・Version○○から使い始めた人の継続率 ・○○機能をβ公開しているユーザーの継続率 ・○○に「いいね」した人の継続率 ・○○した人の継続率 ・フォロワー○○人の人の継続率 ・○○をフォローしている人の継続率 ! 何で測るか Localytics最高。 MixPanelやLeanPlumもよい。コホートを作って、そこに向 けてプッシュが打てるものもある。
  132. 132. アジャイル開発 Scrum コホート分析/ファネル分析/ A/Bテスト基盤 MVP Canvas 仮説検証設計 我々のLeanStartupの型
  133. 133. リーンスタートアップとは科学的アプローチというけれど、 その場合、実験の計画の思考プロセスは逆。 こうじゃなく 実際の思考プロセスは こう考えて計画する
  134. 134. ①仮説 ②何を学ぶのか ③必要なデータは? ④どうやって計測する? ⑤必要なものは? ⑥どう構築するか? 思考プロセス
  135. 135. ①仮説 ②何を学ぶのか ③必要なデータは? ④どうやって計測する? ⑤必要なものは? ⑥どう構築するか? (MVP案1)A/Bテスト (MVP案2)ティザーページ (MVP案3)ユーザインタビュー 思考プロセス
  136. 136. ⑥どう構築するか? (MVP案1)A/Bテスト (MVP案2)ティザーページ (MVP案3)ユーザインタビュー もっとも効果的に学びが得られるMVPはどれか選択する ・費用対効果 ・期間 ・工数 ・この検証方法により回避できる将来のリスク ・この検証方法により逆に発生する将来のリスク 思考プロセス
  137. 137. ⑫仮説を調整する ⑪学ぶ ⑩データを元に検証 ⑨計測する ⑧完成したMVP ⑦構築する (MVP)A/Bテスト 実証プロセス
  138. 138. http://www.slideshare.net/aerodynamic/mvp-canvas この一連の思考プロセス・実証プロセスを 髙橋さんとフォーマット化!
  139. 139. http://www.slideshare.net/aerodynamic/mvp-canvas 仮説 何を学ぶのか 仮説実証に 必要なデータ 条件 MVP構築に 必要なコスト 仮説実証に 必要な時間 回避/発生する 将来のリスク 結果と、得た学び MVPのタイプ ・紙プロト ・インタビュー ・A/Bテスト ・動くデモ etc 何を作るのか どうやってそのMVPで実証するのか 35
  140. 140. LeanCanvas - MVPCanvas - Scrum 型の整理 35
  141. 141. Lean Canvas <ビジネス仮説> MVP Canvas <仮説検証MVPの設計> Product Backlog <MVP構築タスク> Out of Building!!! MVPがインタビューの場合 MVPがエンジニア稼働必要な場合 改善タスク ・改善目的A/Bテスト ・計測装置導入 メンテナンスタスク ・技術的負債解消 ・OSバージョンアップ対応 ・バグ対応 アライアンスタスク 直接仮説検証には 関係ないけど サービス維持に 必要なタスク 35
  142. 142. Lean Canvas <ビジネス仮説> MVP Canvas <仮説検証MVPの設計> Product Backlog <MVP構築タスク> 顧客 発見 顧客 実証 顧客 開拓 組織 構築 Problem Solution Fit Product Market Fit Pivot 35
  143. 143. 第一部 ヒットからカオスへ 突然の大ヒット。 全ての連鎖の始まりがここに。 第二部 師との出会い 恩師との出会い。 そして我々は本当のスクラムを知る。 第三部 俺たちはリーンだ! 様々な師達に教えを受け、 リーンスタートアップを会得 そして、自分達のプロセスに昇華 第四部 リーンのその先にあったもの エンジニアの新しい働き方 35
  144. 144. この型をひたすら回すと・・・・ 36
  145. 145. プロダクトバックログが最小化されていく =やらないことが最大化されていく エンジニアの働き方(活躍出来る場所)に 一部変化が出てくる =エンジニアが成長のエンジンになる 36
  146. 146. プロダクトバックログが最小化されていく =やらないことが最大化されていく エンジニアの働き方(活躍出来る場所)に 一部変化が出てくる =エンジニアが成長のエンジンになる 36
  147. 147. LeanStartup以前の Product Backlog LeanStartup以後の Product Backlog ・○○検証用モック作成 ・○○検証用ダミーボタン実装 ・検証済み○○機能本実装 ・検証済み○○機能本実装 ・リファラル向上改善 ・登録ファネル改善 ・計測基盤実装 ・コホートに対するプッシュ実装 ・○○機能実装 ・○○機能実装 ・○○機能実装 ・○○機能実装 ・○○機能実装 ・○○機能実装 ・○○機能実装 ・○○機能実装 ・○○機能実装 ・○○機能実装 ・○○機能実装 36
  148. 148. Product Backlog <開発タスク> 10個ひらめいた! Product Owner 10個のエンジニアタスク LeanStartup以前 37
  149. 149. Lean Canvas <ビジネス仮説> MVP Canvas <仮説検証MVPの設計> Product Backlog <MVP構築タスク> 10個の仮説 3個のMVP構築 (エンジニアタスク) 10個のMVP設計 7個のOutOfBuilding (プロダクトオーナータスク) LeanStartup以後 37
  150. 150. 新規機能追加コスト > 仮説検証コスト 新規機能追加コスト < 仮説検証コスト 37
  151. 151. プロダクトバックログが最小化されていく =やらないことが最大化されていく =エンジニアの開発タスクが減る =エンジニア体制の縮小(最適化)  or 技術的負債解消に当てる時間  or エンジニアドリブンで改善する時間    37
  152. 152. プロダクトバックログが最小化されていく =やらないことが最大化されていく エンジニアの働き方(活躍出来る場所)に 一部変化が出てくる =エンジニアが成長のエンジンになる 38
  153. 153. Lean Engineer 価値:仮説検証サイクルの速度を上げること コミット:サービスの成長 生産性:仮説検証できた回数/時間 Not Lean Engineer 価値:開発をやりきること コミット:開発の完遂 生産性:Step/時間 エンジニアの働き方 =成長のエンジン
  154. 154. 成長のエンジンたるエンジニア 本質的なサービスの成長に寄与するエンジニア  →よりハイレイヤーなKPIにコミットする !   例えば【継続率】【チャーンレート改善】など !   その数値を改善するために、自身で仮説をたて、   MVPで検証を行う。全てを自身で行えるため、   高いスピード感でKPIを向上させることが出来る。 数値にコミット出来るため、 権限と成果責任がエンジニアに発生する。 成果責任があるからこそ、 実行することを実行する人が決めることが出来る!
  155. 155. あと数日で退会しそうなユーザーを退会させない あと数日で退会してしまいそうなユーザーの母集団に対して、 コホートをきり、そこに対してアクションをするような仕組み を実装し再びサービスの価値を感じるようにしてもらい退会率 を下げる。 退会率減少にコミットしたエンジニアが 自ら仮説をたて実装して検証していく 例えば・・
  156. 156. Engine of Growth!!
  157. 157. ご清聴ありがとうございました! 40

×