Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

新規事業が対峙する現実からエンジニアリングを俯瞰する #devsumiB #devsumi

23,721 views

Published on

Developers summit 2017の 【16-B-7】セッションのスライドです。

Published in: Engineering

新規事業が対峙する現実からエンジニアリングを俯瞰する #devsumiB #devsumi

  1. 1. 新規事業が対峙 する現実から エンジニアリン グを俯瞰する RECRUIT TECHNOLOGIES IT Management Division Development 2 , DevOps0G Kuroda Itsuki @i2key
  2. 2. 本スライドの主語:大企業内の新規事業 文脈により事情は大きく変わると思うので、 正解はないと思います。 考え方の取っ掛かりにしていただければ。 ※注意 想定読者 ・ビジネスに対峙するエンジニアリーダー的な人 ・ビジネスに価値貢献するとか、価値を作るといいつつ、 それ以上具体的に言語化できない人 ・よかれと思う改善提案がビジネス側の理解を得られず悶々 としている人
  3. 3. 越境の足跡 見えてきた勘所 現場に還る
  4. 4. 越境の足跡 見えてきた勘所 現場に還る
  5. 5. エンジニアリングビジネス PBL リリー ス プランニ ング 振り返り MTG レビュー デイリー MTG Sprint/2weeks 開発タスク/Day エンジニアチーム全員の稼働を簡単にムダに出来るポジションだからこそ、プロダクトオー ナー・プロダクトマネージャ採用基準は厳しい(あるべき) 僕の考えた最強 の機能リスト PBLの質、超重要。 (やる必然性・エビデンスの有無) 施策に対するコスト責任をおえている、もしくは、他の施策と濁り無く施策効果を単体で計測できる 環境がないと実施内容が大きくてキラキラするバイアスが発生することがある。 実際の数値で施策の結果を評価できないため賑やかなものを作りたくなる。(各種構造上の問題) どんなに開発チームがスペシャルでも、チームに  をインプットすると 結局、価値をうまない  がチームからアウトプットされる
  6. 6. エンジニアリングビジネス PBL リリー ス プランニ ング 振り返り MTG レビュー デイリー MTG Sprint/2weeks 開発タスク/Day 計測 構築 学習 デー タ アイ デア ビジネス 仮説リスト 全部、思い込みだと前提におく 思い込みにより発生する各種ムダを 省くためにリーンにやる http://www.slideshare.net/i2key/45-developers-summit-2015-devsumi-devsumib http://www.slideshare.net/i2key/devsumi-natsumic7 ※(元)僕の考えた 最強の機能リスト
  7. 7. 従来の プロダクトバックログ 仮説検証型の プロダクトバックログ ・仮説A検証用モック作成 ・仮説B検証用ダミーボタン実装 ・検証済み○○機能本実装 ・検証済み○○機能本実装 ・リファラル向上改善 ・登録ファネル改善 ・計測基盤実装 ・コホートに対するプッシュ実装 ・○○機能実装 ・○○機能実装 ・○○機能実装 ・○○機能実装 ・○○機能実装 ・○○機能実装 ・○○機能実装 ・○○機能実装 ・○○機能実装 ・○○機能実装 ・○○機能実装 わざわざ開発せずに インタビューやエンジニアリング以外で検証できそう 根拠無し 根拠無し 根拠無し 事前検証 (エビデンス収集) 実証後の実装
  8. 8. 国内x企業内新規事業→海外xスタートアップ 出資先海外スタートアップ の日本市場グロース支援 www.slideshare.net/i2key/bp-leanstartup/42
  9. 9. リクルートジョブズリクルート住まい カンパニー リクルート住まい カンパニー RECRUIT VENTURESTechLab PAAK RECRUIT VENTURES RECRUIT VENTURES RECRUIT VENTURES (全拠点生放送) http://www.slideshare.net/i2key/leanstartup-devlove-leanstartup http://l-orem.com/lean-startup-18-anti-patterns/ 多くの新規事業の現場から 見えてきたアンチパターン集 エンジニアなのに・・・ 膨大な量のビジネス企画のシャワーを浴びる RECRUIT VENTURES、リクルートグループ各社での布教活動(いっ ぱい)/各種審査員/新規事業アイデアの壁打ちメンター(大量)/etc
  10. 10. エンジニアリング ビジネス PBL リリー ス プランニ ング 振り返り MTG レビュー デイリー MTG Sprint/2weeks 開発タスク/Day 計測 構築 学習 デー タ アイ デア ビジネス 仮説リスト セールス / マーケ プランニ ング 実行 学習 役割の視野を広げる
  11. 11. 時間軸の視野を広げる
  12. 12. 越境の足跡 見えてきた勘所 現場に還る
  13. 13. この視界から エンジニアリングを見てみる これ
  14. 14. 見えてきた勘所 ビジネスモデルから エンジニアリングを見る
  15. 15. ビジネスモデル ↓ エンジニアリングの座組
  16. 16. https://www.youtube.com/watch?v=-WTZ2frEiZUhttps://www.youtube.com/watch?v=QKgBsEISAbM https://www.youtube.com/watch?v=DVVQGdcYY88 Geoffrey Moore Keynote: The Future of Enterprise IT (part 1,2,3) http://www.gartner.com/it-glossary/bimodal/ System of Engagement Bimodal IT BusinessCapabilityCentric https://martinfowler.com/bliki/BusinessCapabilityCentric.html 一般論
  17. 17. Bi-modal IT Bimodal IT Mode1 Mode2 別名 System of Record(SoR) System of Engagement(SoE) 適正 基幹系・勘定系、 ミッションクリティカルな機能・システム (決済システム、顧客管理等) 正解が無い中、柔軟に変化をしながら走り続 ける必要がある機能・サービス (スマホアプリ、ウェブサービスのフロント) 目的 信頼性、安定性 定めた仕様に従って安定性や品質を担保し ながら開発していく必要がある 俊敏性、速度 フィードバックに基づいて速やかに改善を加 え、頻繁にリリースする 価値・評価 費用対効果、コスト 売上、ブランド、UX アプローチ ウォーターフォール、V-model、重量IID アジャイル、リーン、カンバン、軽量IID 調達 エンタープライズサプライヤー、 長期的な取引 小さい、新しいベンダー、短期間の取引 メンバ適正 従来のプロセス、プロジェクトが得意 新しくて不確実なプロジェクトが得意 組織/文化 開発部門・計画型 ビジネス&開発混在・探索型 サイクルタイム 数ヶ月 数日、数週間 Geoffrey Moore “SOEs operating on top of and in touch with SORs” 企業内のIT戦略として適材適所で SoRとSoEが共存していきましょうという話
  18. 18. とっかかりポイント どこで売上が発生しているか ・エンジニアの書いたコード上で売上がたつ ・エンジニアの書いたコード上で売上がたたない
  19. 19. 検索条件 入力画面 検索結果 一覧画面 詳細画面 予約画面 口コミ SEO SEM ETC サービス トップ 画面 if(isBooked){ } 口コミ SEO SEM ETC 成果課金型 広告枠検索サービス ¥0 利用者 クライアント マッチング サービス CVR改善 = 売上直結 エンジニアの書いたコード上で売上がたつ例 CPA改善 = 売上直結 流入数
  20. 20. 検索条件 入力画面 検索結果 一覧画面 詳細画面 予約画面 口コミ SEO SEM ETC サービス トップ 画面 if(isBooked){ } 口コミ SEO SEM ETC 成果課金型 広告枠検索サービス ¥0 利用者 クライアント マッチング サービス CVR改善 = 売上直結 エンジニアの書いたコード上で売上がたつ例 水漏れ補修 水漏れ補修 水漏れ補修 水漏れ補修 CPA改善 = 売上直結 流入数 エンジニアによるプロダクト改善が売上目標に直接寄与 = エンジニアが成長のエンジン(になりやすい) = エンジニアのビジネス貢献が可視化しやすい = 数値目標を持ったプロダクトチームが  じゃんじゃん改善サイクルを回すとよいパターン = アジャイルとか超導入しやすい座組(結果が売上で出る) (憧れのエンジニア文化がある会社はこのモデル多め)
  21. 21. エンジニアリングへのビジネス期待 安定性 or 俊敏性 どちらなのか Bimodal IT Mode1 Mode2 別名 System of Record(SoR) System of Engagement(SoE) 適正 基幹系・勘定系、 ミッションクリティカルな機能・システム (決済システム、顧客管理等) 正解が無い中、柔軟に変化をしながら走り続 ける必要がある機能・サービス (スマホアプリ、ウェブサービスのフロント) 目的 信頼性、安定性 定めた仕様に従って安定性や品質を担保し ながら開発していく必要がある 俊敏性、速度 フィードバックに基づいて速やかに改善を加 え、頻繁にリリースする 価値・評価 費用対効果、コスト 売上、ブランド、UX アプローチ ウォーターフォール、V-model、重量IID アジャイル、リーン、カンバン、軽量IID 調達 エンタープライズサプライヤー、 長期的な取引 小さい、新しいベンダー、短期間の取引 メンバ適正 従来のプロセス、プロジェクトが得意 新しくて不確実なプロジェクトが得意 組織/文化 開発部門・計画型 ビジネス&開発混在・探索型 サイクルタイム 数ヶ月 数日、数週間 Geoffrey Moore “SOEs operating on top of and in touch with SORs”
  22. 22. 検索条件 入力画面 検索結果 一覧画面 詳細画面 予約画面 口コミ SEO SEM ETC サービス トップ 画面 if(isBooked){ } 口コミ SEO SEM ETC 純広告枠 (営業商品)検索サービス ¥0 利用者 クライアント マッチング サービス CVR改善 = 次回発注への信頼獲得 = 売上直結ではない 営業 エンジニアの書いたコード上で売上がたたない例 CV数 流入数
  23. 23. 検索条件 入力画面 検索結果 一覧画面 詳細画面 予約画面 口コミ SEO SEM ETC サービス トップ 画面 if(isBooked){ } 口コミ SEO SEM ETC 純広告枠 (営業商品)検索サービス ¥0 利用者 クライアント マッチング サービス CVR改善 = 次回発注への信頼獲得 = 売上直結ではない 営業 エンジニアの書いたコード上で売上がたたない例 CV数 流入数 売上 CVR・QCD 流入数 CV数 マーケ プロダクト 営業 パワーバランスこうなりがち 売上 > 流入数・CV数 > CVR・QCD (営業)     (マーケ)       (プロダクト)
  24. 24. 検索条件 入力画面 検索結果 一覧画面 詳細画面 予約画面 口コミ SEO SEM ETC サービス トップ 画面 if(isBooked){ } 口コミ SEO SEM ETC 純広告枠 (営業商品)検索サービス ¥0 利用者 クライアント マッチング サービス CVR改善 = 次回発注への信頼獲得 = 売上直結ではない 営業 エンジニアの書いたコード上で売上がたたない例 CV数 流入数 売上 CVR・QCD 流入数 CV数 マーケ プロダクト 営業 パワーバランスこうなりがち 売上 > 流入数・CV数 > CVR・QCD (営業)     (マーケ)       (プロダクト) CTO及びそれに準ずる人がいれば その人が説明責任を持ち均衡を保ってくれるはずだが・・・ 大企業内新規事業だとそうもいかず・・・
  25. 25. 検索条件 入力画面 検索結果 一覧画面 詳細画面 予約画面 口コミ SEO SEM ETC サービス トップ 画面 if(isBooked){ } 口コミ SEO SEM ETC 純広告枠 (営業商品)検索サービス ¥0 利用者 クライアント マッチング サービス CVR改善 = 次回発注への信頼獲得 = 売上直結ではない 営業 エンジニアの書いたコード上で売上がたたない例 CV数 流入数 売上 CVR・QCD 流入数 CV数 マーケ プロダクト 営業 営業が売上に直接的に寄与 = 営業が成長エンジン( 売上○○円/人 予測可能) エンジニアは顧客単価を上げるための商品開発で寄与 & 改善・安定運用(CVR向上・QCD) 顧客単価UP貢献 12
  26. 26. 検索条件 入力画面 検索結果 一覧画面 詳細画面 予約画面 口コミ SEO SEM ETC サービス トップ 画面 if(isBooked){ } 口コミ SEO SEM ETC 純広告枠 (営業商品)検索サービス ¥0 利用者 クライアント マッチング サービス CVR改善 = 次回発注への信頼獲得 = 売上直結ではない 営業 エンジニアの書いたコード上で売上がたたない例 CV数 流入数 売上 CVR・QCD 流入数 CV数 マーケ プロダクト 営業 営業が売上に直接的に寄与 = 営業が成長エンジン( 売上○○円/人 予測可能) エンジニアは顧客単価を上げるための商品開発で寄与 & 改善・安定運用(CVR向上・QCD) 顧客単価UP貢献 ビジネス貢献を説明できず(理解されず)に ここだけに極端にフォーカスがあたると・・・・ 12
  27. 27. 検索条件 入力画面 検索結果 一覧画面 詳細画面 予約画面 口コミ SEO SEM ETC サービス トップ 画面 if(isBooked){ } 口コミ SEO SEM ETC 純広告枠 (営業商品)検索サービス ¥0 利用者 クライアント マッチング サービス CVR改善 = 次回発注への信頼獲得 = 売上直結ではない 営業 エンジニアの書いたコード上で売上がたたない例 エンジニアのビジネス貢献が可視化しにくい = トラブルだけが目立つようになる = できて当たり前(減点主義)のパラダイム = エンジニアはコスト削減や生産性向上のようなビジネス指標 から程遠い目標設定になる = QCDSの制約の雁字搦めになるので、エンジニア側は壁を作 りディフェンシブになりだす = 本来、俊敏に仮説検証回したい目的に反して、組織がスロー ダウンしていく 12
  28. 28. Bimodal IT Mode1 Mode2 別名 System of Record(SoR) System of Engagement(SoE) 適正 基幹系・勘定系、 ミッションクリティカルな機能・システム (決済システム、顧客管理等) 正解が無い中、柔軟に変化をしながら走り続 ける必要がある機能・サービス (スマホアプリ、ウェブサービスのフロント) 目的 信頼性、安定性 定めた仕様に従って安定性や品質を担保し ながら開発していく必要がある 俊敏性、速度 フィードバックに基づいて速やかに改善を加 え、頻繁にリリースする 価値・評価 費用対効果、コスト 売上、ブランド、UX アプローチ ウォーターフォール、V-model、重量IID アジャイル、リーン、カンバン、軽量IID 調達 エンタープライズサプライヤー、 長期的な取引 小さい、新しいベンダー、短期間の取引 メンバ適正 従来のプロセス、プロジェクトが得意 新しくて不確実なプロジェクトが得意 組織/文化 開発部門・計画型 ビジネス&開発混在・探索型 サイクルタイム 数ヶ月 数日、数週間 Geoffrey Moore “SOEs operating on top of and in touch with SORs” エンジニアのビジネス貢献を正しく説明できないと 本来の目的に反してコスト効率のパラダイムに引力が働くことがある (ビジネスー開発間の信頼関係・理解等他にも要因あるが) ビジネス貢献を 抜きにした 過剰な QCD評価
  29. 29. 放置していると組織としての慣性は、 ビジネス部門と開発部門 の社内受発注な関係に向かいやすい じゃあ、どーすんのか (本来は信頼関係があればよいが) ビジネス側・エンジニア側が共通の目標を持ち それぞれの貢献を可視化できるようにする (or お互いの目標も持ちそれに貢献する) ※結果に対して自分のアクションで影響を与える アジャイルやDevOpsで言われている 同じ責任や目標を持ったクロスファンクショナルな スモールチームと結局は同じこと。
  30. 30. OKRでも概念的なKPIツリーでもなんでも良いですが、 そこで、ひとつのやりかたとしてアラインメントマップ https://martinfowler.com/bliki/AlignmentMap.html
  31. 31. 例) パフォーマンス(IT成果)が良くない のにカスタマー継続率(ビジネス成果) は好調。IT成果が実はビジネス成果に 影響をあまり与えていない or 与えるレベルまでいっていないと 予想できる。 https://martinfowler.com/bliki/AlignmentMap.html 振り返りとしてビジネス、ITそれぞれが別々に成果を評価しマージする。 すべてのITの活動がビジネス成果に影響を与えるわけではないが、 この結果から議論の機会になる
  32. 32. 見えてきた勘所 ビジネスフェーズから エンジニアリングを見る
  33. 33. ビジネスフェーズ ↓ 求められる プロダクト品質 エンジニア像
  34. 34. 充足 不充足 満足 不満足 顧客の満足感 物理的な充足度 魅力品質 当たり前品質 アーリーアダプターには ここ弱めにするか。とか マネタイズ検証時には 必要だね。とか Minimum Sellable Product 性能品質 魅力品質 性能品質 当たり前品質 不充足でも不満には思わないが、 充足されれば満足 <例> ハイレゾ音源(あれば良いが、なくても 不満ではない)、曲面液晶など 不充足だと不満、充足されると満足 <例> バッテリーの持ち(稼働時間が長ければ 満足、短いと不満)、重量など 不充足だと不満、充足されて当たり前 <例> 通話音声(音が良くて当たり前、聞き 取りづらいと不満) 狩野モデル
  35. 35. 深い課題を抱えた顧客がいるか その課題の解決策は妥当か 顧客発見 顧客実証 顧客開拓 組織構築 [ニーズ検証] [売って検証] [リーチ検証] [本格拡大] 独自な価値提供を出来ているか 顧客は本当に買ってくれるか コスト構造に無理がないか 独自な価値提供を出来ているか 最適な売り方の検証 最適な価格設定の検証 独自な価値提供を出来ているか Problem Solution Fit Product Market Fit Scaling Retention CAC < LTV 最大LTVセグメントの比率 課題解決可能 な最小限 売り方最適化 / 売上最大化売る ビジネス フェーズ 狩野 モデル 魅力的品質 最低限の性能品質 魅力的品質 当たり前品質 アップセルに向けた性能品質 魅力的品質 当たり前品質 指標値例 検証アク ション 検証 ポイント MVP 目標 MVP作って壊す MVP 品質 最低限の 売れる状態 セグメントに応じて売れる状態 検証が既存ユーザに影響与えない
  36. 36. ビジネスフェーズからエンジニア像を俯瞰してみる (ユニークなValuePropositionが技術ではない場合の例) Problem / Solu,on Fit Product / Market Fit Scaling 100% %me Scale MySQL MVP iOS iOS KPI 検証用のMVPを 高速に実装 ビジネス文脈を意識した 品質担保&成長貢献 セグメントに応じた 性能向上 顧客発見 顧客実証 顧客開拓
  37. 37. 見えてきた勘所 ビジネス仮説検証プロセス から エンジニアリングを見る
  38. 38. 仮説検証プロセス ↓ エンジニアリングによる 仮説検証基盤構築
  39. 39. 仮説検証基盤要件 方法 既存のユーザへの影響 を最小化 ユーザーを任意の属性でセグメン トする機能 管理コンソールの実装 既存のユーザへの影響 を最小化 ユーザーセグメントに対して機能 の出し分けを可能にする 事業フェーズが進めば進むほど、既にたくさん使われ ているプロダクトで仮説検証をすることになるため必 要最低限の影響範囲で仮説検証をする Feature Flag、A/Bテスト、Private Beta Test、Dark Launch、etc 検証結果が濁らないこ と 仮説や施策単位に各種数値を 計測出来る機能 (例)CV数が目標の場合、マーケの頑張りなのか、プロ ダクト改善によるCVR向上なのか切り分けができない コホート分析 検証方法の改善が出来 ること 検証ポイントまでユーザが漏れず に到達できていること UI上の問題で検証ポイントまでユーザが到達していな いのに、検証失敗とする事案がある ファネル分析 : : : DevOps系プラクティス見れば基本ソレ
  40. 40. 見えてきた勘所 予算計画のリズムから エンジニアリングを見る
  41. 41. 1年 1年 1年 予算のリズム ↓ 開発のリズム(ほんとに?????) 答え持っていないのでここは 誰かご教授願いたいです (課題提起プレゼンwwww) 次年度予算計画 次年度予算計画 次年度予算計画
  42. 42. Bimodal IT Mode1 Mode2 別名 System of Record(SoR) System of Engagement(SoE) 適正 基幹系・勘定系、 ミッションクリティカルな機能・システム (決済システム、顧客管理等) 正解が無い中、柔軟に変化をしながら走り続 ける必要がある機能・サービス (スマホアプリ、ウェブサービスのフロント) 目的 信頼性、安定性 定めた仕様に従って安定性や品質を担保し ながら開発していく必要がある 俊敏性、速度 フィードバックに基づいて速やかに改善を加 え、頻繁にリリースする 価値・評価 費用対効果、コスト 売上、ブランド、UX アプローチ ウォーターフォール、V-model、重量IID アジャイル、リーン、カンバン、軽量IID 調達 エンタープライズサプライヤー、 長期的な取引 小さい、新しいベンダー、短期間の取引 メンバ適正 従来のプロセス、プロジェクトが得意 新しくて不確実なプロジェクトが得意 組織/文化 開発部門・計画型 ビジネス&開発混在・探索型 サイクルタイム 数ヶ月 数日、数週間 本当は、俊敏性や速度を持ってやりたいのに、 結果的に重厚長大な計画駆動型になってしまう場合もある 年次予算計画の圧 本当は、こうしたいのに
  43. 43. エンタープライズの場合、年次の予算計画があり、 ベースとなるサイクルタイムは年になる。 1年先の未来の状況を事前に予想して計画しないとならない。 そして、それを1年後まで大幅に変更することはない。 計画の実行に固執すると「発見」による変更がきかなくなる 1年 1年 1年 新規事業なのに年次計画駆動になるバイアス 予算:目的のために確保する資金の合計(活動に費やせる金額の上限) 戦略:実際にやることを定義するもの 予算は戦略をどのように実現するべきか計画するのもではない 顧客に価値を届けるこのと成否を予測したり評価したりするのもではない。 課題:年次プロセス以外で資金調達する方法がない
  44. 44. 課題:年次プロセス以外で資金調達する方法がない →「発見」による軌道修正が不可能 →より多くの予算を確保するために多大な労力をかけて最高のビジネスプ ランを計画(予想w)しないとならない 事例1:新規事業組織部門としてバジェットは年次固定で持ち つつ、それを部門内で資金調達型で各新規事業へ配分していく。 各事業にステージ(調達額上限)を設定。同時に撤退のルールも 決め予算の「選択と集中」を行う。 http://www.slideshare.net/i2key/bp-leanstartup#94 19
  45. 45. 事例2:前述の新規事業単位での資金調達よりも、細かい現場 での機能追加レベルでの資金調達法。 MVP Canvasにより仮説検証の学びに対するコストの 説明責任を設ける。(活動基準会計) バジェットの使い方を意味のないキラキラ機能追加ではなく、 どのような学びがあるかをベースに議論する。 http://www.slideshare.net/i2key/45-developers-summit-2015-devsumi-devsumib#141 19
  46. 46. 一般論 脱予算経営 Beyond Budget Management 等いわれていますが、ここらへんの取り組みでうまくいっ ている事例等ありましたら、ご教授いただきたいで す!!!!!誰か! お願い!!!! 19
  47. 47. 越境の足跡 見えてきた勘所 現場に還る
  48. 48. 提案 サービス ¥0 クライアント 企業従業員 クライアント BtoB 従業員向け SaaS型 サービス 営業 time (月) : : : 受注率 継続率 継続率 BtoBのSaaSモデル
  49. 49. xxx画面 xxx画面 xxx画面 CV画面 サービス トップ 画面 if(isConverted){ } ○○改善 = 受注率向上 □□改善 = 継続率向上  のキードライバが見えていない コード上なのかリアルなのか? ?
  50. 50. 最適な売り方、 最適な価格設定の 検証フェーズ
  51. 51. ・営業が売上立てるモデル   ↓ ・商品開発において受注率・継続率の  キードライバーとして見えるものが無い   ↓ ・キードライバーを発見する  仮説検証のトライ回数最大化   ↓ ・仮説検証の速度の最大化  (本番デプロイ回数/日)   ※リリースまでのリードタイム最小化 最適な売り方、 最適な価格設定の 検証フェーズ
  52. 52. ・フェーズ的に売り物を使って  仮説検証していく   ↓ ・MVPは当たり前品質、性能品質必要  (競合同等の機能品質がないと買ってもらえない   →検証したい価格設定の検証ができない)   ↓ ・仮説検証の質を最大化   ↓ ・プロダクト品質 ・既存ユーザに仮説検証で  迷惑をかけない仕組み ・濁らない計測 最適な売り方、 最適な価格設定の 検証フェーズ
  53. 53. 仮説検証トライ回数最大化 仮説検証トライ品質最大化 (デプロイ回数/日) http://i2key.hateblo.jp/entry/2016/12/07/153146
  54. 54. 仮説検証トライ回数最大化 仮説検証トライ品質最大化 (デプロイ回数/日) プロセス品質向上 = 手戻り防止 = フロー効率あげる リードタイム削減 =フロー効率あげる プロセスタイムの削減 =フロー効率あげる 仮説品質向上 = 手戻り防止 = フロー効率あげる 計測品質向上 = 手戻り防止 = フロー効率あげる 実装品質向上 = 手戻り防止 = フロー効率あげる http://i2key.hateblo.jp/entry/2016/12/07/153146
  55. 55. リソース効率 フロー効率 This is Lean The Efficiency Matrix ① ② ③ ④ Efficient islands 効率的な島々 Wasteland 荒廃した地 Efficient ocean 効率的な海 The perfect state High HighLow Low https://www.amazon.co.jp/dp/919803930X/ ①あなたはここにいると思っている ②実際には多分ここ ③まずはフロー効率化からはじめて ④その後にリソース効率化をしていく 例)稼働率100%のチーム   機能がリリースされるまでのリードタイム長い 例)稼働率は100%ではないチーム   機能がリリースされるまでのリードタイム短い Variation リソース効率 (例)稼働率100% フロー効率 (例)機能リリースまでのリードタイムの短さ
  56. 56. リソース効率 フロー効率 This is Lean The Efficiency Matrix ① ② ③ ④ Efficient islands 効率的な島々 Wasteland 荒廃した地 Efficient ocean 効率的な海 The perfect state High HighLow Low https://www.amazon.co.jp/dp/919803930X/ ①あなたはここにいると思っている ②実際には多分ここ ③まずはフロー効率化からはじめて ④その後にリソース効率化をしていく 例)稼働率100%のチーム   機能がリリースされるまでのリードタイム長い 例)稼働率は100%ではないチーム   機能がリリースされるまでのリードタイム短い Variation
  57. 57. バックエンド エンジニア フロント エンジニア プロダクト オーナー 顧客 Feedback 承認レビュー 仕様確認 API開発 API開発 Front開発 デプロイ待ち 待ち フロー効率をあげていく 学ぶ(顧客のフィードバックを得る)までのリードタイム エンジニア (フロント&バックエンド) フロント エンジニア プロダクト オーナー 顧客 Feedback 承認条件 API開発 Front開発 デプロイ 待ち 待ち 待ち ※先に提示された条件をパスすれば リリース承認というルールにする等 ※フルスタック()な振る舞い をすることで引き継ぎによる ムダが減る ※ここにきて手戻りが 発生することも 学ぶ(顧客のフィードバックを得る)までのリードタイム
  58. 58. 待ち行列理論 ・100%の利用率の高速道路は、駐車場といっしょ ・100%利用率のサーバは? ・稼働率100%のチームは? スループットを最大化ではなくチームに最適化する ・処理中のもの量の最小化 ・処理中のもののサイズを最小化 チームへの負荷を調整 ・たくさんのこと同時にしない ・タスク管理ではなく、チームのペースを管理する 仕事の許容量を制限する ・スコープボックスではなくタイムボックス ・プッシュ型ではなくプル型でやる フロー効率を高めるために (顧客へ価値が届くまでのリードタイムを短くする)
  59. 59. マルチタスクやめる A A A A A A A A A A A A A A A B C B C B C B C B C B C B C B C B C B C B C B C B C B C B C A A A A A A A A A A A A A A A B B B B B B B B B B B B B B B C C C C C C C C C C C C C C C 月 火 水 木 金 月 火 水 木 金 月 火 水 木 金 月 火 水 木 金 月 火 水 木 金 月 火 水 木 金 リリースまでのリードタイム 1w リリースまでのリードタイム 2w リリースまでのリードタイム 3w リリースまでのリードタイム 3w リリースまでのリードタイム 3w リリースまでのリードタイム 3w たくさんのことを同時に調整しようとするから 仕様の調整の「会議」やら「定例」やらがうまれる
  60. 60. A A A A A A A A A A A A A A A B C B C B C B C B C B C B C B C B C B C B C B C B C B C B C A A A A A A A A A A A A A A A B B B B B B B B B B B B B B B C C C C C C C C C C C C C C C 月 火 水 木 金 月 火 水 木 金 月 火 水 木 金 月 火 水 木 金 月 火 水 木 金 月 火 水 木 金 リリースまでのリードタイム 1w リリースまでのリードタイム 2w リリースまでのリードタイム 3w リリースまでのリードタイム 3w リリースまでのリードタイム 3w リリースまでのリードタイム 3w たくさんのことを同時に調整しようとするから 仕様の調整の「会議」やら「定例」やらがうまれる Git Flow ・Release Branchがマルチタスクをうんでいる? ・フロー効率あげるのに、可能なら一個流しにしたい ↓ Github Flow 現在移行に向け奮闘中 ・CD ・デプロイパイプライン ・E2E Test整備 ・Feature Flag マルチタスクやめる (例)
  61. 61. スクラム導入におけるビジネス側への説明内容抜粋 やりたいことが永久に湧いてくると思うので、得られるビジネス価値によって 優先順位付けするメカニズムが必要 ・プロダクトバックログ運用開始 ・状況の変化に柔軟に対応するための仕組み(トレードオフ、2週間開発)  ・プランニング、スプリント エンジニアチームの成果・やっていることを可視化 ・全体の定例で毎週予定されているリリースプランを少し未来分まで提示 色々なステークホルダーがエンジニアリーダーにタスクを投げてくる状況(テッ クリードがチケット差配屋さんになること)の脱却 ・ビジネス側と開発側のコミュニケーションチャネルを人ではなく、  プロダクトバックログ&プランニングという場に変更。 スプリントのエンジニア工数比率のポートフォリオの合意形成をしたい。 ・各種施策を実施するためのカイゼン枠を確保。
  62. 62. 現在のチームのスプリントのポートフォリオ 以下のタイムボックス管理 50% 機能追加 20% カイゼン(この枠で前述の各種カイゼン実施) 15% 既知バグ改修 15% 新規バグ改修 ※打ち合わせや雑務の稼働時間は全部SprintBacklogにつんである上で残りの時間を上記に分 配している カイゼンに20%おいているは大事。 (この20%の説明責任を果たし、ビジネス側に合意ををとるための勘所が本日のスライド。) エンジニアのカイゼンのモチベーションを奪ってはいけない。 エンジニアの改善のモチベーションは良い方向に持っていこうとする善のエネルギー。 それをしょうもない理由でへし折るとチーム全体がダークサイドへ堕ちてしまう。
  63. 63. まだ道半ば
  64. 64. We’re HIRING!! ともに越境し歩んでくれる 同士を募集しています

×