社内スタートアップによる組織の成長に伴い発生する痛みとその解決策について45分拡大版 #devsumi #devsumiB
273 likes45,002 views
Developers summit 2015の20-B-5での発表資料になります。
![スプリントバックログの内訳例
[開発] ○○実装タスク 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](https://image.slidesharecdn.com/developerssummit2015v1-150219233102-conversion-gate02/85/45-devsumi-devsumiB-49-320.jpg)
![スプリントバックログの内訳例
[開発] ○○実装タスク 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](https://image.slidesharecdn.com/developerssummit2015v1-150219233102-conversion-gate02/85/45-devsumi-devsumiB-62-320.jpg)
More Related Content
What's hot (20)
Similar to 社内スタートアップによる組織の成長に伴い発生する痛みとその解決策について45分拡大版 #devsumi #devsumiB (20)
More from Itsuki Kuroda (13)
Recently uploaded (6)
社内スタートアップによる組織の成長に伴い発生する痛みとその解決策について45分拡大版 #devsumi #devsumiB
- 1. 社内スタートアップに よる組織の成長に伴い 発生する痛みと、その 解決策について 拡大版 20分→45分 Recruit Holdings Recruit Institute of Technology Media Technology Lab Itsuki KURODA @i2key Scrum&LEAN STARTUP導入 20-B-5
- 2. Recruit Holdings Recruit Institute of Technology Media Technology Lab 黒田 樹 (@i2key) <= Follow me :-) ! 前職ではSIerで官公庁系大規模システムのアーキテクト。 現在は、全世界でシリーズ累計1000万DLのアプリ cameranシリーズの開発全体責任者（開発、採用、組織構 築、プロセスetc）社内でリーンスタートアップやアジャイル の導入を推進しています。 http://mtl.recruit.co.jp
- 13. •･ プロジェクト開始時の体制 • プロデューサー • エンジニア（サーバ） • エンジニア（iOS）※常駐外部パートナー • デザイナー • チームは、メンバー全員の打ち合わせで全ての課題が解 決できる規模だった。 • ウォーターフォールではない、アジャイルのような何か。
- 17. 開発規模大きいし、 まずは・・・
- 18. エンジニア増加！！
- 19. 今度はディレクターネック
- 20. ディレクター増加！！ 5
- 22. アライアンス担当増加！！
- 23. デザイナもデザイナも！
- 24. エンジニアも、もっと！！
- 25. どうなるか・・・
- 26. ちょw体制wwwwwwwww プロデューサー デザイナ エンジニア Before アライアンス デザイナ エンジニア ディレクター プロデューサー Lead Engineer Server Engineer iOS Engineer Android Engineer After ＼(^o^)／
- 27. 何が起きるのか・・・??
- 28. ・目標に対する成長スピードの鈍化 ・やるべきことに着手できていない焦り ・日々発生する最優先タスクに振り回される現場。 （「最優先」の中で最優先とか・・・。） ・毎日行われる進 会議というなの大検討会＆浪費される時間 ・伝言ゲームによるコミュニケーションコストの肥大化 ・プロデューサー - エンジニア間の発注者-受注者的関係性 ・プロデューサー - エンジニア間の関係性の悪化（ギスギスする） ・技術的負債の山 ・日々詰み上がるバグの山を解決するだけで時間が過ぎていく。 ・現場まで降りてこない方針。価値観。文脈。現場判断出来ない。
- 29. コミュニケーション① Lead Engineer Server Engineer iOS Engineer Android Engineer Engineer team プロデューサー ディレクター プロデューサー team ①この仕様ってこ れでいいのかな？ ②ちょっと確認し てみますね ③ここの仕様で質問 きたのですが、こう 回答していいすか？ ④じゃ、それで。 ⑤あざーす！ ⑥うお・・・wこれインパクト でけえ・・。サーバエンジニア 以外にも影響でるな・・・。 ⑦りょーかいで す・・・ ⑦りょーかいで す・・・ 伝言ゲーム
- 30. コミュニケーション② Lead Engineer Server Engineer iOS Engineer Android Engineer Engineer team プロデューサー ディレクター プロデューサー team ①この機能なるは やでいれよ！ ②ワイヤー作って 調整しますー ③仕様理解しました。各エン ジニアにディスパッチして工 数の見積もりを依頼します。 ④全部やったら1ヶ月くらいか かるね。（今やってるの全部 手をとめたらね） ④うーん、2週間くらいか なぁ。（今やってる開発作 業はどうなるんだろ・・・） ⑤現在着手中のもあると思う ので、バッファ詰んで1.5ヶ月 にしましょう。そう伝えます。 ⑥1.5ヶ月ですね。 了解です。 ⑦了解です。この間依 頼した機能はまだ出来 上がらないのかな。 ボトルネック
- 31. コミュニケーション③ Lead Engineer Server Engineer iOS Engineer Android Engineer Engineer team プロデューサー ディレクター プロデューサー team ①あそこの機能結構やっつけで作っ たのでリファクタリングしてコード 品質上げましょう。ついでにフレー ムワークのバージョンもあげましょ うか。 ②いいっすねー！やりま しょー！1週間くらいあればで きそうですね！ ③技術的負債を解消するためのタス クがあることを知らない。 知らないとこで タスク作成
- 32. コミュニケーション④ Lead Engineer Server Engineer iOS Engineer Android Engineer Engineer team プロデューサー ディレクター プロデューサー team ①競合が新機能い れた、やばい、こ れなるはやで！ ②ワイヤー作って 調整しますー ③仕様理解しました。各エン ジニアにディスパッチして工 数の見積もりを依頼します。 ④前回依頼あった実装まだ全 然おわってないのに・・・。 見積もりコストかなりかかる し・・・。2週間くらいかな。 ④1週間くらいかな。 ⑤（リファクタリング対象と実装箇 所が被るので、リファクタリングを 実施してから、本タスクは着手しま しょう。）実装には2週間くらいあ れば。 ⑥2週間ですね。了 解です。 ⑦了解です。この間依 頼した機能はまだ出来 上がらないのかな。 知らないとこで優先付け
- 33. コミュニケーション⑤ Lead Engineer Server Engineer iOS Engineer Android Engineer Engineer team プロデューサー ディレクター プロデューサー team ①このバグやばい！ なるはやでなおし て！！！ ②そんな重要なバグなのでしょ うか？了解です。最優先で対 処します。 ③了解です！すぐになおしま す。暫定対処は、すぐだけど、 本格対処は結構工数かかりそ うだなー。 ④今回は本格対処まで実施したいの で、時間結構かかります。暫定版は 明日リリースします。 ⑥了解です。 どんなバグでも最優先対応
- 34. コミュニケーション⑥ Lead Engineer Server Engineer iOS Engineer Android Engineer Engineer team プロデューサー ディレクター プロデューサー team ①まだ新機能がリ リースされない。 何やってんだ！！ ②そんなこといわれても、何 でもなるはやじゃないすか。 ③こんなに毎日終電や徹夜し てまで頑張ってるのに、なん で怒られなくてはならないの だろう・・・・ ギスギス・・・ ＼(^o^)／
- 35. 今なら言える失敗 • スケーラブルな組織設計でないのにスケールさせてしまった。管理 能力の高いチームは自らチームの成長を抑制するか、その代わりに 管理キャパシティをスケールさせる。 • バニティメトリクスに支配されていた。表面上のMAUを稼ぐのは人 を増やしてパワーを掛ければ稼げる（ので、人を増やしてしまう） • プロジェクト計画の方法論、サイクル、カレンダーが無い • 仕事の優先順位決定のメカニズムが無い • 明確に定められたバグトリアージとトラッキングが無い • コミュニケーションチャネル設計が無い
- 39. やりたいこと。これへの対処
- 43. 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
- 44. スクラム始めるアルアル • 見積もりを相対値でやらないといけない • プランニングポーカーしないといけない • インセプションデッキつくらないといけない • ベロシティを計測しないといけない • タスクはユーザーストーリーでかかないといけない • みんな自己組織化しないといけない 11
- 49. スプリントバックログの内訳例 [開発] ○○実装タスク 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
- 55. サーバーエンジニアを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
- 56. 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 スクラムマスター 交代 スクラムマスター 交代
- 57. 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
- 58. 今回の取り組みのようなスケールさせていく アジャイルな組織作りで参考にした文献・記事の一部 http://www.continuousagile.com/unblock/ea_matrix.html Matrix of Services ( MAXOS )
- 59. 今回の取り組みのようなスケールさせていく アジャイルな組織作りで参考にした文献・記事の一部 http://www.scaledagileframework.com Scaled Agile Framework ( SAFe )
- 60. 今回の取り組みのようなスケールさせていく アジャイルな組織作りで参考にした文献・記事の一部 Scaling Agile @ Spotify https://dl.dropboxusercontent.com/u/1018963/Articles/SpotifyScaling.pdf
- 62. スプリントバックログの内訳例 [開発] ○○実装タスク 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
- 63. Server 例外ログ 問い合わせ管理システム クラッシュログ 監視システム ユーザー メンバー バグトラッキング システム バグトリアージMMTTGG バグマネージメントMMTTGG iOS Engineer Android Engineer Server Engineer Daily Weekly iOS Engineer Android Engineer Server Engineer Product Owner Tester 一次切り分け
- 66. Quality + Cost + Delivery + Scope のバランシング デリバリーの認識を変える リリースマネージメント デリバリーは決まった日に 勝手にやってくるのだ それにのるかのらないかお前次第 17
- 67. Sprint #2Sprint #1 Sprint #3 ○○機能 ○○機能 ○○機能 バグ修正 バグ修正 バグ修正 3月1日（固定） 3月7日（固定） 3月14日（固定） 固定リリース タイミング 固定リリース タイミング 固定リリース タイミング 例：リリースタイミングは1週間毎にやってくる。そのときリ リースしたいものがあればリリース対象に入れる。 17
- 68. リリースカレンダー
- 70. Sprint #2Sprint #1 Sprint #3 ○○機能 3月1日（固定） 3月7日（固定） 3月14日（固定） 固定リリース タイミング 固定リリース タイミング 固定リリース タイミング リリース日優先タスクは こう対応するとみんな幸せになれる 技術的負債解消タスク 本来はこのくらいかかる予定だった なるはや リリース ク○コード 脱ク○コード 18
- 73. こうやりがち 責任・権限 作業を遂行する プロダクト マネージメント セールス 資金調達 アライアンス ： 採用 プロダクトオーナー タスク Product Owner ただの 作業者 お伺い 18
- 75. プロダクトオーナープロキシ 責任・権限 作業を遂行する プロダクト マネージメント セールス 資金調達 アライアンス ： 採用 プロダクトオーナー タスク Product Owner Proxy Product Owner 19
- 79. • スクラムを入れたから解決するのではなくて、見える化が進 むので結果的にアクションを打てるタイミングがはやくな り、問題を小さい段階で早期解決出来る。 • プロジェクトや開発の文脈により、解決すべき問題が違うた め本に書いてある通りのことをそのまま全部やろうしてもう まくいかない。プラクティス厨になるだけ。 • 価値観も大きく変わる。限られたリソースをどう有効に使う か。これが全てになる。その目線がそろった状態から、各種 プラクティスの導入を行うことが大事。 • メンバーを信頼することが大前提。 学び 19
- 82. 現在では • スクラムマスターは持ち回りの当番制 • 全員がスクラムマスターを出来るようになっているため、 各自が自走出来る状態になっている。 • 結果的に、スクラムマスター専業の稼働は減る。 • 自己組織化が進む。 • 振り返りから、プルリク駆動開発の実施やSlack+hubotに よるChatOpsも実施。良くあるプランニングポーカー等各 種プラクティスも後から導入。（良くある最近の開発手法） 20
- 83. 20
- 85. ひとときの平穏
- 86. しかし・・・
- 96. スタートアップマニュアル アントレプレナーの教科書 リーンスタートアップ 顧客開発モデルのトリセツ RUNNING LEAN LEAN UX LEAN Analytics リーン開発の現場 ： ： ： 先人の知恵に触れる
- 100. Hooked著者 Nir氏 (UX)
- 112. 顧客発見 顧客実証 顧客開拓 組織構築 Problem Solution Fit Product Market Fit Pivot Scaling Agile 実証済み 実証済み実証済み 実証済み 実証済み 実証済み 実証済み 実証済み 実証済み 実証済み 実証済み 実証済み 実証済み 実証済み 今自分達がスタートアップの どのフェーズに いるかを認識する 27
- 113. 顧客発見 顧客実証 顧客開拓 組織構築 Problem Solution Fit Product Market Fit Pivot Scaling Agile 実証済み 実証済み実証済み 実証済み 実証済み 実証済み 実証済み 実証済み 実証済み 実証済み 実証済み 実証済み 実証済み 実証済み 27
- 114. Agile 顧客発見 顧客実証 顧客開拓 組織構築 Problem Solution Fit Product Market Fit Pivot ユーザーの深い課題/ニーズを把握し 解決策を提示しそれが刺さっている ビジネスモデルの成立することが 実証できている （Engine of Growthが装着できている） 例）CAC < LTV Scaling 例）Retentionしている MAU右上がり 28
- 115. Agile 顧客発見 顧客実証 顧客開拓 組織構築 Problem Solution Fit Product Market Fit Pivot ユーザーの深い課題/ニーズを把握し 解決策を提示しそれが刺さっている ビジネスモデルの成立することが 実証できている （Engine of Growthが装着できている） 例）CAC < LTV Scaling 例）Retentionしている MAU右上がり ←いまココ（※当時） 28
- 121. 型を学ぶ
- 127. 計測例 •仮説 • SNS型サービスだが、ユーザのサインアップ率が悪 い。現在他人の投稿はクローズドでサインアップした ユーザーにしか見えない。サインアップしてないユーザ にも見えるようにすることでSNSのUXを事前体験・学 習させるとアカウント登録率があがるのはないか。 •MVP • サインアップ不要で他人の投稿を閲覧出来る機能を実 装しユーザ数%対象に公開して計測。 •学びたいこと • サインアップ率の上昇。及び、既存機能への悪影響 度。
- 143. Lean Canvas ＜ビジネス仮説＞ MVP Canvas ＜仮説検証MVPの設計＞ Product Backlog ＜MVP構築タスク＞ Out of Building!!! MVPがインタビューの場合 MVPがエンジニア稼働必要な場合 改善タスク ・改善目的A/Bテスト ・計測装置導入 メンテナンスタスク ・技術的負債解消 ・OSバージョンアップ対応 ・バグ対応 アライアンスタスク 直接仮説検証には 関係ないけど サービス維持に 必要なタスク 35
- 144. Lean Canvas ＜ビジネス仮説＞ MVP Canvas ＜仮説検証MVPの設計＞ Product Backlog ＜MVP構築タスク＞ 顧客 発見 顧客 実証 顧客 開拓 組織 構築 Problem Solution Fit Product Market Fit Pivot 35
- 146. この型をひたすら回すと・・・・ 36
- 151. Lean Canvas ＜ビジネス仮説＞ MVP Canvas ＜仮説検証MVPの設計＞ Product Backlog ＜MVP構築タスク＞ 10個の仮説 3個のMVP構築 （エンジニアタスク） 10個のMVP設計 7個のOutOfBuilding （プロダクトオーナータスク） LeanStartup以後 37
- 155. Lean Engineer 価値：仮説検証サイクルの速度を上げること コミット：サービスの成長 生産性：仮説検証できた回数/時間 Not Lean Engineer 価値：開発をやりきること コミット：開発の完遂 生産性：Step/時間 エンジニアの働き方 ＝成長のエンジン
- 158. Engine of Growth!!
- 159. ご清聴ありがとうございました！ 40