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.

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

14,832 views

Published on

DevLOVE200 Bridge の登壇資料です。
https://devlove.doorkeeper.jp/events/60269
デブサミの以下の資料の焼き直しです。
https://www.slideshare.net/i2key/devsumib

Published in: Engineering

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

  1. 1. 新規事業が対峙 する現実から エンジニアリン グを俯瞰する リクルートテクノロジーズ 黒田 樹 @i2key DevLOVE200 Bridge
  2. 2. 文脈により事情は大きく変わると思うので、 正解はないと思います。 考え方の取っ掛かりにしていただければ。 ※注意 想定読者 ・ビジネスに対峙するエンジニアリーダー的な人 ・ビジネスに価値貢献するとか、価値を作るといいつつ、 それ以上具体的に言語化できない人 ・よかれと思う改善提案がビジネス側の理解を得られず悶々 としている人 ・各種方法論(リーンスタートアップ、スクラム、etc)の説明 はしません。実践者対象です。 ・ニッチ向け。
  3. 3. 越境の契機 見えてきた勘所 現場に還る
  4. 4. 越境の契機 見えてきた勘所 現場に還る
  5. 5. エンジニアリングビジネス PBL リリー ス プランニ ング 振り返り MTG レビュー デイリー MTG Sprint/2weeks 開発タスク/Day 僕の考えた最強 の機能リスト
  6. 6. エンジニアリングビジネス PBL リリー ス プランニ ング 振り返り MTG レビュー デイリー MTG Sprint/2weeks 開発タスク/Day 【あるある】 ・プロダクトオーナーが施策のコスト責任を終えていない ・各施策単位で効果測定が出来ていない(やりっぱなし ・各施策単位での費用対効果の説明責任を果たせない 僕の考えた最強 の機能リスト PBLの質、超重要。 (やる必然性・エビデンスの有無) どんなに開発チームがスペシャルでも、チームに  をインプットすると 結局、価値をうまない  がチームからアウトプットされる ボトルネックが 開発→ビジネスへ遷移
  7. 7. エンジニアリングビジネス PBL リリー ス プランニ ング 振り返り MTG レビュー デイリー MTG Sprint/2weeks 開発タスク/Day 計測 構築 学習 デー タ アイ デア ビジネス 仮説リスト 全部、思い込みだと前提におく 思い込みにより発生する各種ムダを 省くためにリーンにやる http://www.slideshare.net/i2key/45-developers-summit-2015-devsumi-devsumib http://www.slideshare.net/i2key/devsumi-natsumic7 ※(元)僕の考えた 最強の機能リスト
  8. 8. 従来の プロダクトバックログ 仮説検証型の プロダクトバックログ ・仮説A検証用モック作成 ・仮説B検証用ダミーボタン実装 ・検証済み○○機能本実装 ・検証済み○○機能本実装 ・リファラル向上改善 ・登録ファネル改善 ・計測基盤実装 ・コホートに対するプッシュ実装 ・○○機能実装 ・○○機能実装 ・○○機能実装 ・○○機能実装 ・○○機能実装 ・○○機能実装 ・○○機能実装 ・○○機能実装 ・○○機能実装 ・○○機能実装 ・○○機能実装 わざわざ開発せずに インタビューやエンジニアリング以外で検証できそう 根拠無し 根拠無し 根拠無し 事前検証 (エビデンス収集) 実証後の実装
  9. 9. 国内x企業内新規事業→海外xスタートアップ 出資先海外スタートアップ の日本市場グロース支援 www.slideshare.net/i2key/bp-leanstartup/42
  10. 10. NINTENDOの国から やってきた男として やってみせる デブサミ2011【18-B-1】 プログラマが知るべき、たったひとつの大事なことがら @t_wada 氏(現、弊社技術顧問氏)の原体験 https://www.slideshare.net/t_wada/the-only- one-big-thing-every-programmer-should-know
  11. 11. エンジニアリング ビジネス PBL リリー ス プランニ ング 振り返り MTG レビュー デイリー MTG Sprint/2weeks 開発タスク/Day 計測 構築 学習 デー タ アイ デア ビジネス 仮説リスト セールス / マーケ プランニ ング 実行 学習 役割の視野を広げる 売上、KPIを上げるためになんでもやる
  12. 12. http://www.slideshare.net/i2key/leanstartup-devlove-leanstartup http://l-orem.com/lean-startup-18-anti-patterns/ 多くの新規事業の現場から 見えてきたアンチパターン集 エンジニアなのに・・・ 膨大な量のビジネス企画のシャワーを浴びる RECRUIT VENTURES、リクルートグループ各社での布教活動(いっ ぱい)/各種審査員/新規事業アイデアの壁打ちメンター(大量)/etc
  13. 13. 1. キャンバス依存パターン 2. そもそもFounder/Market Fit、Founder/Product Fitして いないパターン 3. MVPでシンプルにやらなきゃだめだよ!だって、ネットの 記事にそうかいてあるしパターン 4. 石橋叩きすぎパターン 5. シングルタスクパターン 6. 誰そのペルソナ、本当にいるのパターン 7. その人お金払わないよねパターン 8. 何か言っているようで何も言っていないパターン 9. キャバクラでの我々パターン 16. 性能競争パターン 17. 解決策ありきパターン 18. ○○がそれやったらどーすんのパターン
  14. 14. 経験した各フェーズの立ち回り から、時間軸の視野を広げる
  15. 15. 越境の契機 見えてきた勘所 現場に還る
  16. 16. この視界から エンジニアリングを見てみる これ
  17. 17. 見えてきた勘所 ビジネスモデルから エンジニアリングを見る
  18. 18. ビジネスモデル ↓ エンジニアリングの座組
  19. 19. とっかかりポイント どこで売上が発生しているか ・エンジニアの書いたコード上で売上がたつ ・エンジニアの書いたコード上で売上がたたない
  20. 20. コード上で売上がたつ場合
  21. 21. 検索条件 入力画面 検索結果 一覧画面 詳細画面 予約画面 口コミ SEO SEM ETC サービス トップ 画面 if(isBooked){ } 口コミ SEO SEM ETC 成果課金型 広告枠検索サービス ¥0 利用者 クライアント マッチング サービス CVR改善 = 売上直結 エンジニアの書いたコード上で売上がたつ例 CPA改善 = 売上直結 流入数
  22. 22. 検索条件 入力画面 検索結果 一覧画面 詳細画面 予約画面 口コミ SEO SEM ETC サービス トップ 画面 if(isBooked){ } 口コミ SEO SEM ETC 成果課金型 広告枠検索サービス ¥0 利用者 クライアント マッチング サービス CVR改善 = 売上直結 エンジニアの書いたコード上で売上がたつ例 水漏れ補修 水漏れ補修 水漏れ補修 水漏れ補修 CPA改善 = 売上直結 流入数 エンジニアによるプロダクト改善が売上目標に直接寄与 = エンジニアが成長のエンジン(になりやすい) = エンジニアのビジネス貢献が可視化しやすい = 数値目標を持ったプロダクトチームが  じゃんじゃん改善サイクルを回すとよいパターン = アジャイルとか超導入しやすい座組(結果が売上で出る) = 内製化はじめるとかもここらへんが成果を出しやすい (憧れのエンジニア文化がある会社はこのモデル多め)
  23. 23. Acquisition 獲得 Retention 継続 Churn 解約 Referral 紹介 Activation 活性化 Revenue 収益 AARRRモデル
  24. 24. Acquisition(獲得) Retention(継続) Churn(解約) Referral(紹介) Activation(活性化) Revenue(収益) AARRRモデル マーケ 営業 プロダクト
  25. 25. 検索条件 入力画面 検索結果 一覧画面 詳細画面 予約画面 口コミ SEO SEM ETC サービス トップ 画面 if(isBooked){ } 口コミ SEO SEM ETC 成果課金型 広告枠検索サービス ¥0 利用者 クライアント マッチング サービス CVR改善 = 売上直結 エンジニアの書いたコード上で売上がたつ例 水漏れ補修 水漏れ補修 水漏れ補修 水漏れ補修 CPA改善 = 売上直結 流入数 パワーバランスこうなりがち(逆もあるがほぼイコール) 売上(CVR)・QCD ≧ 流入数・CV数       (プロダクト)     (マーケ) 売上 CVR・QCD 流入数 CV数 マーケ プロダクト
  26. 26. コード上で売上がたたない場合
  27. 27. 検索条件 入力画面 検索結果 一覧画面 詳細画面 予約画面 口コミ SEO SEM ETC サービス トップ 画面 if(isBooked){ } 口コミ SEO SEM ETC 純広告枠 (営業商品)検索サービス ¥0 利用者 クライアント マッチング サービス CVR改善 = 次回発注への信頼獲得 = 売上直結ではない 営業 エンジニアの書いたコード上で売上がたたない例 CV数 流入数
  28. 28. 検索条件 入力画面 検索結果 一覧画面 詳細画面 予約画面 口コミ SEO SEM ETC サービス トップ 画面 if(isBooked){ } 口コミ SEO SEM ETC 純広告枠 (営業商品)検索サービス ¥0 利用者 クライアント マッチング サービス CVR改善 = 次回発注への信頼獲得 = 売上直結ではない 営業 エンジニアの書いたコード上で売上がたたない例 CV数 流入数 売上 CVR・QCD 流入数 CV数 マーケ プロダクト 営業 パワーバランスこうなりがち 売上 > 流入数・CV数 > CVR・QCD (営業)     (マーケ)       (プロダクト)
  29. 29. Acquisition(獲得) Retention(継続) Churn(解約) Referral(紹介) Activation(活性化) Revenue(収益) AARRRモデル マーケ 営業 プロダクト 営業
  30. 30. 検索条件 入力画面 検索結果 一覧画面 詳細画面 予約画面 口コミ SEO SEM ETC サービス トップ 画面 if(isBooked){ } 口コミ SEO SEM ETC 純広告枠 (営業商品)検索サービス ¥0 利用者 クライアント マッチング サービス CVR改善 = 次回発注への信頼獲得 = 売上直結ではない 営業 エンジニアの書いたコード上で売上がたたない例 CV数 流入数 売上 CVR・QCD 流入数 CV数 マーケ プロダクト 営業 営業が売上に直接的に寄与 = 営業が成長エンジン( 売上○○円/人 予測可能) エンジニアは顧客単価を上げるための商品開発で寄与 & 安定運用(QCD) & 改善(CVR向上) 顧客単価UP貢献 ・イケイケアルゴリズム ・競合を凌駕する技術優位
  31. 31. 検索条件 入力画面 検索結果 一覧画面 詳細画面 予約画面 口コミ SEO SEM ETC サービス トップ 画面 if(isBooked){ } 口コミ SEO SEM ETC 純広告枠 (営業商品)検索サービス ¥0 利用者 クライアント マッチング サービス CVR改善 = 次回発注への信頼獲得 = 売上直結ではない 営業 エンジニアの書いたコード上で売上がたたない例 CV数 流入数 売上 CVR・QCD 流入数 CV数 マーケ プロダクト 営業 顧客単価UP貢献 営業が売上に直接的に寄与 = 営業が成長エンジン( 売上○○円/人 予測可能) エンジニアは顧客単価を上げるための商品開発で寄与 & 安定運用(QCD) & 改善(CVR向上) ビジネス貢献が 可視化しにくい場合
  32. 32. 検索条件 入力画面 検索結果 一覧画面 詳細画面 予約画面 口コミ SEO SEM ETC サービス トップ 画面 if(isBooked){ } 口コミ SEO SEM ETC 純広告枠 (営業商品)検索サービス ¥0 利用者 クライアント マッチング サービス CVR改善 = 次回発注への信頼獲得 = 売上直結ではない 営業 エンジニアの書いたコード上で売上がたたない例 エンジニアのビジネス貢献が可視化しにくい場合 = トラブルだけが目立つようになる = できて当たり前(減点主義)のパラダイム = エンジニアはコスト削減や生産性向上のようなビジネス指標 から程遠い目標設定になる = QCDSの制約の雁字搦めになるので、エンジニア側は壁を作 りディフェンシブになりだす = 本来、俊敏に開発したい目的に反して、組織がスローダウン していく
  33. 33. 放置していると組織としての慣性は、 ビジネス部門と開発部門 の社内受発注な関係に向かいやすい
  34. 34. ・エンジニアの書いたコード上で売上がたつ  →攻めのエンジニアリング要素強め   →でも、その中にも守りの要素はある。 ・エンジニアの書いたコード上で売上がたたない  →守りのエンジニアリング要素強め   →でも、その中にも攻めの要素はある。 ひとつの塊として扱うのではなく 適材適所で攻め/守りの目的に合わせた エンジニアリングが必要
  35. 35. 見えてきた勘所 ビジネス戦略、 プロダクト戦略から エンジニアリングを見る
  36. 36. ビジネス戦略 プロダクト戦略 ↓ エンジニアリング戦略 6 のぼり方・戦略
  37. 37. エンジニアがビジネス貢献すると思ってやっていることが、 実はそこまで重要ではない場合もある。 一般的に正しいとされている方法論を実施したときに、 いずれかのハレーションが生まれるような場合、 前提の置き方を間違っていることが多い。 (間違った原理主義に陥っている可能性)
  38. 38. アジャイルにやりたい(はずだ)。 本当にそうだろうか?
  39. 39. リリースサイクルを高速化したい(はずだ)。 本当にそうだろうか?
  40. 40. 仮説検証型にしたい(はずだ)。 本当にそうだろうか?
  41. 41. 仮説検証型にしたい(はずだ)。 本当にそうだろうか? 目的意識は持っているものの、 目的をエンジニアが決めつけていて、 ビジネスと目的がすりあっていない可能性
  42. 42. ビジネス「側」はエンジニアのことを理解してくれない とかいうのではなく、 まずは、膝を突き合わせて語りお互いを理解すること。 ビジネス戦略を正しく捉えた上での 戦略に合わせた開発手法なり技術選定なりが必要 本当の目的にあわせて開発のやりかたを決める。 まずは目的を問う。
  43. 43. 我々が忠誠を誓うのは、開発手法ではない。 目的である。 目的を問い、目的からはじめる。 そこからズレると現場が不幸になる。
  44. 44. https://www.slideshare.net/papanda/ss-72221454 時を越えた越境への道 @papanda 氏 ここで世界線が交差する
  45. 45. https://www.youtube.com/watch?v=-WTZ2frEiZU https://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 目的に対するIT戦略の一般論
  46. 46. 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が共存していきましょうという話
  47. 47. BusinessCapabilityCentric https://martinfowler.com/bliki/BusinessCapabilityCentric.html Agile IT Organization Design: For Digital Transformation and Continuous Delivery Bi modal IT戦略は、SoEかSoRかの二極化の議論になりがち なので、そうではなく実際のビジネスケーパビリティによって チームを組んでそれぞれで適した開発(手法・技術)をしましょ う。そのほうがチームを長期間存続させることができます。と いう話。広義なマイクロサービスの組織論サイドにも近い。
  48. 48. 方法論や考え方は、真理に対して、 それぞれ別の角度から光を当てているため、 1つの方法論に固執すると視野が狭まり、 本質を見失い、 過度な原理主義に陥る恐れがある。
  49. 49. 真理 バイモーダル戦略 BusinessCapabilityCenrticIT SoRとSoEの 二極化で整理できる わけないだろ 特定の位置から光をあてると 影の部分に対してヤジがとんでくる だから、 SoRとSoEは グラデーションだ っていってんだろ
  50. 50. 真理 バイモーダル戦略 BusinessCapabilityCenrticIT ビジネス能力だけで 開発手法決まるわけ ないだろ!!! 特定の位置から光をあてると 影の部分に対してヤジがとんでくる
  51. 51. 影になる部分を補うように、それぞれの方向から光を当ててみる 真理 バイモーダル戦略 BusinessCapabilityCenrticIT
  52. 52. Business Capability Centric IT SoE SoR 入稿業務予約業務 課金業務 分析業務 UI/UX UI/UX UI/UX 予約登録API 検索API 入稿API 決済API システム間 連携処理 参照API 参照API カスタマー 社内担当者 カスタマー 社内担当者 アプリ UI/UX ブックマーク 予約機能 検索機能 カスタマー 俊敏 アジャイル 仮説検証 売上・KPI 安定 計画駆動 仕様通り ROI・QCD 利用者 Business Capability 俊敏なKPI改善 俊敏なKPI改善 トラブル0件 トラブル0件 使いやすさ 正確な集計目的 BiModalIT UI/UX 参照API 検索API 集計処理
  53. 53. Business Capability Centric IT SoE SoR 入稿業務予約業務 課金業務 分析業務 UI/UX UI/UX UI/UX UI/UX 予約登録API 検索API 入稿API 決済API システム間 連携処理 参照API 参照API 集計処理 カスタマー 社内担当者 カスタマー 社内担当者 アプリ UI/UX ブックマーク 予約機能 検索機能 カスタマー 俊敏 アジャイル 仮説検証 売上・KPI 安定 計画駆動 仕様通り ROI・QCD 利用者 Business Capability 俊敏なKPI改善 俊敏なKPI改善 トラブル0件 トラブル0件 使いやすさ 正確な集計目的 BiModalIT アジャイル アジャイル アジャイル ウォーター フォール ウォーター フォール ウォーター フォール 参照API 検索API
  54. 54. Business Capability Centric IT SoE SoR 入稿業務予約業務 課金業務 分析業務 UI/UX UI/UX UI/UX UI/UX 予約登録API 検索API 入稿API 決済API システム間 連携処理 参照API 参照API 参照API 検索API 集計処理 カスタマー 社内担当者 カスタマー 社内担当者 アプリ UI/UX ブックマーク 予約機能 検索機能 カスタマー 俊敏 アジャイル 仮説検証 売上・KPI 安定 計画駆動 仕様通り ROI・QCD 利用者 Business Capability 俊敏なKPI改善 俊敏なKPI改善 トラブル0件 トラブル0件 使いやすさ 正確な集計目的 BiModalIT アジャイル アジャイル アジャイル ウォーター フォール ウォーター フォール ウォーター フォール 重要な プロジェクト 型案件 Objective-C ↓ Swiftへ フルリライト 新機能の 実装前に 仮説検証 価格設定 のための 仮説検証 学び最大化 学び最大化
  55. 55. Business Capability Centric IT SoE SoR 入稿業務予約業務 課金業務 分析業務 UI/UX UI/UX UI/UX UI/UX 予約登録API 検索API 入稿API 決済API システム間 連携処理 参照API 参照API 参照API 検索API 集計処理 カスタマー 社内担当者 カスタマー 社内担当者 アプリ UI/UX ブックマーク 予約機能 検索機能 カスタマー 俊敏 アジャイル 仮説検証 売上・KPI 安定 計画駆動 仕様通り ROI・QCD 利用者 Business Capability 俊敏なKPI改善 俊敏なKPI改善 トラブル0件 トラブル0件 使いやすさ 正確な集計目的 BiModalIT アジャイル アジャイル アジャイル ウォーター フォール ウォーター フォール ウォーター フォール 重要な プロジェクト 型案件 Objective-C ↓ Swiftへ フルリライト 新機能の 実装前に 仮説検証 価格設定 のための 仮説検証 アジャイル アジャイル ウォーター フォール ウォーター フォール 学び最大化 学び最大化
  56. 56. Business Capability Centric IT SoE SoR 入稿業務予約業務 課金業務 分析業務 UI/UX UI/UX UI/UX UI/UX 予約登録API 検索API 入稿API 決済API システム間 連携処理 参照API 参照API 参照API 検索API 集計処理 カスタマー 社内担当者 カスタマー 社内担当者 アプリ UI/UX ブックマーク 予約機能 検索機能 カスタマー 俊敏 アジャイル 仮説検証 売上・KPI 安定 計画駆動 仕様通り ROI・QCD 利用者 Business Capability 俊敏なKPI改善 俊敏なKPI改善 トラブル0件 トラブル0件 使いやすさ 正確な集計目的 BiModalIT アジャイル アジャイル アジャイル ウォーター フォール ウォーター フォール ウォーター フォール 重要な プロジェクト 型案件 Objective-C ↓ Swiftへ フルリライト 新機能の 実装前に 仮説検証 価格設定 のための 仮説検証 アジャイル アジャイル ウォーター フォール ウォーター フォール 戦略・各種優先度に応じて SoEチームと SoRチームに分けるか、 優先度をつけて1チームでやるか チームの能力、戦略、財務、 各種文脈に応じて判断する。
  57. 57. 見えてきた勘所 ビジネスフェーズから エンジニアリングを見る
  58. 58. ビジネスフェーズ ↓ 求められる プロダクト品質
  59. 59. 充足 不充足 満足 不満足 顧客の満足感 物理的な充足度 魅力品質 当たり前品質 アーリーアダプターには ここ弱めにするか。とか マネタイズ検証時には 必要だね。とか Minimum Sellable Product 性能品質 魅力品質 性能品質 当たり前品質 不充足でも不満には思わないが、 充足されれば満足 <例> ハイレゾ音源(あれば良いが、なくても 不満ではない)、曲面液晶など 不充足だと不満、充足されると満足 <例> バッテリーの持ち(稼働時間が長ければ 満足、短いと不満)、重量など 不充足だと不満、充足されて当たり前 <例> 通話音声(音が良くて当たり前、聞き 取りづらいと不満) 狩野モデル一般論
  60. 60. 深い課題を抱えた顧客がいるか その課題の解決策は妥当か 顧客発見 顧客実証 顧客開拓 組織構築 [ニーズ検証] [売って検証] [リーチ検証] [本格拡大] 独自な価値提供を出来ているか 顧客は本当に買ってくれるか コスト構造に無理がないか 独自な価値提供を出来ているか 最適な売り方の検証 最適な価格設定の検証 独自な価値提供を出来ているか Problem Solution Fit Product Market Fit Scaling Retention CAC < LTV 最大LTVセグメントの比率 課題解決可能 な最小限 売り方最適化 / 売上最大化売る ビジネス フェーズ 狩野 モデル 魅力的品質 最低限の性能品質 魅力的品質 当たり前品質 アップセル・クロスセルに 向けた性能品質 魅力的品質 当たり前品質 指標値例 検証アク ション 検証 ポイント MVP 目標 MVP作って壊す MVP 品質 最低限の 売れる状態 セグメントに応じて売れる状態 検証が既存ユーザに影響与えない
  61. 61. 充足 不充足 満足 不満足 顧客の満足感 物理的な充足度 魅力品質 当たり前品質 アーリーアダプターには ここ弱めにするか。とか マネタイズ検証時には 必要だね。とか Minimum Sellable Product 性能品質 魅力品質 性能品質 当たり前品質 不充足でも不満には思わないが、 充足されれば満足 <例> ハイレゾ音源(あれば良いが、なくても 不満ではない)、曲面液晶など 不充足だと不満、充足されると満足 <例> バッテリーの持ち(稼働時間が長ければ 満足、短いと不満)、重量など 不充足だと不満、充足されて当たり前 <例> 通話音声(音が良くて当たり前、聞き 取りづらいと不満) 狩野モデル
  62. 62. 充足 不充足 満足 不満足 顧客の満足感 物理的な充足度 魅力品質 当たり前品質 アーリーアダプターには ここ弱めにするか。とか マネタイズ検証時には 必要だね。とか Minimum Sellable Product 性能品質 魅力品質 性能品質 当たり前品質 不充足でも不満には思わないが、 充足されれば満足 <例> ハイレゾ音源(あれば良いが、なくても 不満ではない)、曲面液晶など 不充足だと不満、充足されると満足 <例> バッテリーの持ち(稼働時間が長ければ 満足、短いと不満)、重量など 不充足だと不満、充足されて当たり前 <例> 通話音声(音が良くて当たり前、聞き 取りづらいと不満) 狩野モデル
  63. 63. 充足 不充足 満足 不満足 顧客の満足感 物理的な充足度 魅力品質 当たり前品質 アーリーアダプターには ここ弱めにするか。とか マネタイズ検証時には 必要だね。とか Minimum Sellable Product 性能品質 魅力品質 性能品質 当たり前品質 不充足でも不満には思わないが、 充足されれば満足 <例> ハイレゾ音源(あれば良いが、なくても 不満ではない)、曲面液晶など 不充足だと不満、充足されると満足 <例> バッテリーの持ち(稼働時間が長ければ 満足、短いと不満)、重量など 不充足だと不満、充足されて当たり前 <例> 通話音声(音が良くて当たり前、聞き 取りづらいと不満) 狩野モデル
  64. 64. ビジネスフェーズ ↓ 求められる エンジニア像
  65. 65. ビジネスフェーズからエンジニア像を俯瞰してみる (ユニークなValuePropositionが技術ではない場合の例) Problem / Solu,on Fit Product / Market Fit Scaling 100% %me Scale MySQL MVP iOS iOS KPI 検証用のMVPを 高速に実装 ビジネス文脈を意識した 品質担保&成長貢献 セグメントに応じた 性能向上 顧客発見 顧客実証 顧客開拓
  66. 66. 検証を設計する (実証条件/実証方法/etc) 効果を計測する KPI(数値目標)を設定する リリースする ユーザがコンバージョンする 仮説をたてる 仕様にする 設計する ユーザーに届く ユーザーが使う ユーザーが気づく KPI(数値目標)達成 指標:ベロシティ/デプロイ回数/性能値/品質/コスト/etc エンジニアのコミットと目標 データから学ぶ (仮説を修正する   打ち手を変える) エンジニアが直接結果を コントロール出来る範囲 (コードのみに対峙してる) エンジニアが直接結果を コントロール出来ない範囲 (ユーザーの判断という不確実性が介在) テストする 実装する 指標:MAU/継続率/○○率/売上/etc
  67. 67. 検証を設計する (実証条件/実証方法/etc) 効果を計測する KPI(数値目標)を設定する リリースする ユーザがコンバージョンする 仮説をたてる 仕様にする 設計する ユーザーに届く ユーザーが使う ユーザーが気づく KPI(数値目標)達成 指標:ベロシティ/デプロイ回数/性能値/品質/コスト/etc エンジニアのコミットと目標 データから学ぶ (仮説を修正する   打ち手を変える) エンジニアが直接結果を コントロール出来る範囲 (コードのみに対峙してる) エンジニアが直接結果を コントロール出来ない範囲 (ユーザーの判断という不確実性が介在) テストする 実装する 指標:MAU/継続率/○○率/売上/etc マルチロールに しみ出す
  68. 68. 検証を設計する (実証条件/実証方法/etc) 効果を計測する KPI(数値目標)を設定する リリースする ユーザがコンバージョンする 仮説をたてる 仕様にする 設計する ユーザーに届く ユーザーが使う ユーザーが気づく KPI(数値目標)達成 指標:ベロシティ/デプロイ回数/性能値/品質/コスト/etc エンジニアのコミットと目標 データから学ぶ (仮説を修正する   打ち手を変える) エンジニアが直接結果を コントロール出来る範囲 (コードのみに対峙してる) エンジニアが直接結果を コントロール出来ない範囲 (ユーザーの判断という不確実性が介在) テストする 実装する 指標:MAU/継続率/○○率/売上/etc それぞれのプロ
  69. 69. 見えてきた勘所 ビジネス仮説検証プロセス から エンジニアリングを見る
  70. 70. 仮説検証プロセス ↓ エンジニアリングによる 仮説検証基盤構築
  71. 71. 仮説検証基盤要件 方法 既存のユーザへの影響 を最小化 ユーザーを任意の属性 でセグメントする機能 管理コンソールの実装 (Firebase …etc) 既存のユーザへの影響 を最小化 ユーザーセグメントに 対して機能の出し分け を可能にする 事業フェーズが進めば進むほど、 既にたくさん使われているプロダ クトで仮説検証をすることになる ため必要最低限の影響範囲で仮説 検証をする Feature Flag、A/Bテス ト、Private Beta Test、 Dark Launch、etc (Leanplum, Firebase, Optimizely, etc) 検証結果が濁らないこ と 仮説や施策単位に各種 数値を計測出来る機能 (例)CV数が目標の場合、マーケの 頑張りなのか、プロダクト改善に よるCVR向上なのか切り分けがで きない コホート分析 (Localytics, Google Analytics, Firebase …etc) 検証方法の改善が出来 ること 検証ポイントまでユー ザが漏れずに到達でき ていること UI上の問題で検証ポイントまでユ ーザが到達していないのに、検証 失敗とする事案がある ファネル分析 (Localytics, Google Analytics, etc) : : : DevOps系プラクティス見れば基本ソレ
  72. 72. 見えてきた勘所 予算計画のリズムから エンジニアリングを見る
  73. 73. 1年 1年 1年 予算のリズム ↓ 開発のリズム(ほんとに?????) 答え持っていないのでここは 誰かご教授願いたいです (課題提起プレゼン) 次年度予算計画 次年度予算計画 次年度予算計画
  74. 74. Bimodal IT Mode1 Mode2 別名 System of Record(SoR) System of Engagement(SoE) 適正 基幹系・勘定系、 ミッションクリティカルな機能・システム (決済システム、顧客管理等) 正解が無い中、柔軟に変化をしながら走り続 ける必要がある機能・サービス (スマホアプリ、ウェブサービスのフロント) 目的 信頼性、安定性 定めた仕様に従って安定性や品質を担保し ながら開発していく必要がある 俊敏性、速度 フィードバックに基づいて速やかに改善を加 え、頻繁にリリースする 価値・評価 費用対効果、コスト 売上、ブランド、UX アプローチ ウォーターフォール、V-model、重量IID アジャイル、リーン、カンバン、軽量IID 調達 エンタープライズサプライヤー、 長期的な取引 小さい、新しいベンダー、短期間の取引 メンバ適正 従来のプロセス、プロジェクトが得意 新しくて不確実なプロジェクトが得意 組織/文化 開発部門・計画型 ビジネス&開発混在・探索型 サイクルタイム 数ヶ月 数日、数週間 本当は、俊敏性や速度を持ってやりたいのに、 結果的に重厚長大な計画駆動型になってしまう場合もある 年次予算計画の圧 本当は、こうしたいのに
  75. 75. エンタープライズの場合、年次の予算計画があり、 ベースとなるサイクルタイムは年になる。 1年先の未来の状況を事前に予想して計画しないとならない。 そして、それを1年後まで大幅に変更することはない。 計画の実行に固執すると「発見」による変更がきかなくなる 1年 1年 1年 新規事業なのに年次計画駆動になるバイアス 予算:目的のために確保する資金の合計(活動に費やせる金額の上限) 戦略:実際にやることを定義するもの 予算は戦略をどのように実現するべきか計画するのもではない 顧客に価値を届けるこのと成否を予測したり評価したりするのもではない。 課題:年次プロセス以外で資金調達する方法がない
  76. 76. 課題:年次プロセス以外で資金調達する方法がない →「発見」による軌道修正が不可能 →より多くの予算を確保するために多大な労力をかけて最高のビジネスプ ランを計画(予想w)しないとならない 解決策事例1:新規事業組織部門としてバジェットは年次固定 で持ちつつ、それを部門内で資金調達型で各新規事業へ配分し ていく。各事業にステージ(調達額上限)を設定。同時に撤退の ルールも決め予算の「選択と集中」を行う。 http://www.slideshare.net/i2key/bp-leanstartup#94
  77. 77. 解決策事例2:活動基準会計を行う。前述の新規事業単位での 資金調達よりも、細かい現場での機能追加レベルでの資金調達 法。仮説検証の学びに対するコストの説明責任を設ける。仮説 検証、ひとつひとつに対して何を学ぶのか、検証するために何 が必要なのか、どのように計測するのか、いくらかかるのかを 設計する。優先付をして学びに対するムダの無い投資をする。 http://www.slideshare.net/i2key/45-developers-summit-2015-devsumi-devsumib#141
  78. 78. 行動様式 現場で得られた数々の経験から 汎化し自分なりの 勘所(原理原則)を導き出し、 またそれを経験や疑似体験に 照らし合わせ補正していく
  79. 79. 脳内整理 Version 1.0
  80. 80. 脳内整理 Version 2.0
  81. 81. 脳内整理 Version 3.0
  82. 82. 顧客発見 【ニーズ検証】 顧客実証 【売って検証】 組織構築 【本格拡大】 Problem/Solution Fit Product/Market Fit Scaling Retention CAC < LTV 売上 課題解決可能 な最小限 売り方最適化 / 売上最大化売る 品質 モデル 魅力的品質 最低限の性能品質 魅力的品質 当たり前品質 アップセル/クロスセルに向けた性能品質 魅力的品質 当たり前品質 指標値例 検証アク ション 検証 ポイント MVP 目標 MVP作って壊す MVP 品質 最低限の 売れる状態 セグメントに応じて売れる状態 検証が既存ユーザに影響与えない 独自な価値提供を出来ているか 深い課題を抱えた顧客がいるか その課題の解決策は妥当か 開発 モデル例 独自な価値提供を出来ているか 顧客は本当に買ってくれるか コスト構造に無理がないか 顧客開拓 【リーチ検証】 独自な価値提供を出来ているか 最適な売り方の検証 最適な価格設定の検証 導入期 成長期 成熟期 【SoE】Agile【SoE】カウボーイ 【SoE】Agile 【SoR】WaterFall 利益 独自な価値提供を出来ているか CPA最適化 マーケットシェア 分析/検証 インフラ 要件 CVR最大化等のUI/UX仮説検証 価格設定/商品検討のための仮説検証 クロスセルのためのエンタープライズ個別対応開発 仮説検証済み機能によるマーケット刈り取り開発 納期必達型の商品開発 負債解消ビックリライト(ObjC->Swift化) ビジネス仮説検証の高速化文化祭前夜感と全能感を味わ う時期 & ALL高品質 競合との性能競争(消耗戦) キードライバー値 最大化 利益最大化 ビジネス フェーズ ■既存のユーザへの影響を最小化 ユーザーを任意の属性でセグメントする機能 ユーザーセグメントに対して機能の出し分けを可能にする 事業フェーズが進めば進むほど、既にたくさん使われているプロダクトで仮説 検証をすることになるため必要最低限の影響範囲で仮説検証をする ■検証結果が濁らないこと 仮説や施策単位に各種数値を計測出来る機能 (例)CV数が目標の場合、マーケの頑張りなのか、プロダクト改善によるCVR向上なのか切り分けができない ■検証方法の改善が出来ること(ファネル分析) 検証ポイントまでユーザが漏れずに到達できていること UI上の問題で検証ポイントまでユーザが到達していないのに、結果指標 のみを見て検証失敗とする誤判断することがある ■利用開始日別ユーザ単位の分析(コホート分析) 日々の流入イベント毎にユーザーの継続率を分離して計測 ユーザーインタビュー時に使い始めてもらった人の継続率を図る。特定 の日だけアドを少額流して、アドを当てたセグメントの継続率を見る等 リリース日単位の追加機能別のユーザーの継続率を分離して計測 どの機能追加が継続率にヒットしたかを確認する等 Feature Flag、A/Bテスト、Private Beta Test、Dark Launch、etc (Leanplum, Firebase, Optimizely, LaunchDarkly , etc)、独自インフラ手段 Localytics, Google Analytics, Firebase …etc
  83. 83. 顧客発見 【ニーズ検証】 顧客実証 【売って検証】 組織構築 【本格拡大】 Problem/Solution Fit Product/Market Fit Scaling Retention CAC < LTV 売上 課題解決可能 な最小限 売り方最適化 / 売上最大化売る 品質 モデル 魅力的品質 最低限の性能品質 魅力的品質 当たり前品質 アップセル/クロスセルに向けた性能品質 魅力的品質 当たり前品質 指標値例 検証アク ション 検証 ポイント MVP 目標 MVP作って壊す MVP 品質 最低限の 売れる状態 セグメントに応じて売れる状態 検証が既存ユーザに影響与えない 独自な価値提供を出来ているか 深い課題を抱えた顧客がいるか その課題の解決策は妥当か 開発 モデル例 独自な価値提供を出来ているか 顧客は本当に買ってくれるか コスト構造に無理がないか 顧客開拓 【リーチ検証】 独自な価値提供を出来ているか 最適な売り方の検証 最適な価格設定の検証 導入期 成長期 成熟期 【SoE】Agile【SoE】カウボーイ 【SoE】Agile 【SoR】WaterFall 利益 独自な価値提供を出来ているか CPA最適化 マーケットシェア 分析/検証 インフラ 要件 CVR最大化等のUI/UX仮説検証 価格設定/商品検討のための仮説検証 クロスセルのためのエンタープライズ個別対応開発 仮説検証済み機能によるマーケット刈り取り開発 納期必達型の商品開発 負債解消ビックリライト(ObjC->Swift化) ビジネス仮説検証の高速化文化祭前夜感と全能感を味わ う時期 & ALL高品質 競合との性能競争(消耗戦) キードライバー値 最大化 利益最大化 ビジネス フェーズ ■既存のユーザへの影響を最小化 ユーザーを任意の属性でセグメントする機能 ユーザーセグメントに対して機能の出し分けを可能にする 事業フェーズが進めば進むほど、既にたくさん使われているプロダクトで仮説 検証をすることになるため必要最低限の影響範囲で仮説検証をする ■検証結果が濁らないこと 仮説や施策単位に各種数値を計測出来る機能 (例)CV数が目標の場合、マーケの頑張りなのか、プロダクト改善によるCVR向上なのか切り分けができない ■検証方法の改善が出来ること(ファネル分析) 検証ポイントまでユーザが漏れずに到達できていること UI上の問題で検証ポイントまでユーザが到達していないのに、結果指標 のみを見て検証失敗とする誤判断することがある ■利用開始日別ユーザ単位の分析(コホート分析) 日々の流入イベント毎にユーザーの継続率を分離して計測 ユーザーインタビュー時に使い始めてもらった人の継続率を図る。特定 の日だけアドを少額流して、アドを当てたセグメントの継続率を見る等 リリース日単位の追加機能別のユーザーの継続率を分離して計測 どの機能追加が継続率にヒットしたかを確認する等 Feature Flag、A/Bテスト、Private Beta Test、Dark Launch、etc (Leanplum, Firebase, Optimizely, LaunchDarkly , etc)、独自インフラ手段 Localytics, Google Analytics, Firebase …etc これは原理原則のとある特定のビジネス文脈における 1インスタンス。 その雛形は自分の中にアップデートし続ける。 ※すべての文脈に対応しようとすると文章化できない
  84. 84. リーンスタートアップ 制約理論 デザインシンキング 顧客開発 トヨタ生産方式 アジャイル スクラム XP リーンソフトウェア開発 真理 バイモーダル戦略 BusinessCapabilityCenrticIT モダンアジャイル TDD Flow Efficiency KANBAN ペアプログラミング ゆとりの法則
  85. 85. 越境の契機 見えてきた勘所 現場に還る
  86. 86. フロー効率性とリソース効率性のパラダイムを 効果的に使い分けて現場を推進すること SoEでもSoRでもそれは変わらない。 http://i2key.hateblo.jp/entry/2017/05/15/082655
  87. 87. リソース効率性とフロー効率性 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 A機能、B機能、C機能の実装それぞれ15人日かかる場合
  88. 88. リソース効率性とフロー効率性 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 A機能、B機能、C機能の実装それぞれ15人日かかる場合 リソース効率が良い (例)稼働率100% フロー効率が良い (例)機能リリースまでのリードタイムの短さ
  89. 89. リソース効率 フロー効率 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
  90. 90. リソース効率性 フロー効率性 1つのリソースを稼働率が 100%になるまで分配する フローユニットが享受できる リソースを最大化する This is Lean https://www.amazon.co.jp/dp/919803930X/ 例:マルチタスク 例:ペアプログラミング This is Leanの P21 The Efficiency Matrix
  91. 91. わたし あなた 彼 「ゆとりの法則」より 各従業員の机に一時置き場がなければ、組織の 全従業員が常に100%忙しいということはありえない。
  92. 92. わたし あなた 彼 書類受け 書類受け 書類受け 全員の机に一時置き場(書類受け)を用意すると、 全員が常に忙しくなるような仕事の流れを作ることができる
  93. 93. わたし あなた 彼 書類受け 書類受け 書類受け 稼働率100% 稼働率100% 稼働率100% 待ちタスク いっぱい 待ちタスク いっぱい 待ちタスク いっぱい リードタイムが 生まれる リードタイムが 生まれる リードタイムが 生まれる リソースの効率性は高まるが、副作用として仕事が組織の中で 処理されるのにかかる時間が長くなる(組織の速度低下)
  94. 94. 待ち行列理論 ・100%の利用率の高速道路は、駐車場といっしょ ・CPU100%利用率のパソコンは? ・稼働率100%のチームは? スループットを最大化ではなくチームに最適化する ・処理中のもの量の最小化 ・処理中のもののサイズを最小化 チームへの負荷を調整 ・たくさんのこと同時にしない ・タスク管理ではなく、チームのペースを管理する 仕事の許容量を制限する ・スコープボックスではなくタイムボックス ・プッシュ型ではなくプル型でやる フロー効率を高めるために (顧客へ価値が届くまでのリードタイムを短くする)
  95. 95. 事例:学びの回数の最大化
  96. 96. 提案 サービス ¥0 クライアント 企業従業員 クライアント BtoB 従業員向け SaaS型 サービス 営業 time (月) : : : 受注率 継続率 継続率 BtoBのSaaSモデル
  97. 97. Acquisition(獲得) Retention(継続) Churn(解約) Referral(紹介) Activation(活性化) Revenue(収益) マーケ 営業 プロダクト
  98. 98. xxx画面 xxx画面 xxx画面 CV画面 サービス トップ 画面 if(isConverted){ } 営業
  99. 99. 最適な売り方、 最適な価格設定の 検証フェーズ
  100. 100. ・営業が獲得と初回売上立てるモデル   ↓ ・月額課金における継続率は  プロダクトで担保しつつ、  最適な価格設定の検証を走らせる   ↓ ・仮説検証の学びの回数最大化   ↓ ・仮説検証の速度の最大化  (本番デプロイ回数/日)   ※リリースまでのリードタイム最小化 最適な売り方、 最適な価格設定の 検証フェーズ
  101. 101. ・フェーズ的に売り物を使って  仮説検証していく   ↓ ・MVPは当たり前品質、性能品質必要  (競合同等の機能品質がないと買ってもらえない   →検証したい価格設定の検証ができない)   ↓ ・仮説検証の質を最大化   ↓ ・プロダクト品質 ・既存ユーザに仮説検証で  迷惑をかけない仕組み ・濁らない計測 最適な売り方、 最適な価格設定の 検証フェーズ
  102. 102. 仮説検証トライ回数最大化 仮説検証トライ品質最大化 (デプロイ回数/日) http://i2key.hateblo.jp/entry/2016/12/07/153146
  103. 103. 仮説検証トライ回数最大化 仮説検証トライ品質最大化 (デプロイ回数/日) プロセス品質向上 = 手戻り防止 = フロー効率あげる リードタイム削減 =フロー効率あげる プロセスタイムの削減 =フロー効率あげる 仮説品質向上 = 手戻り防止 = フロー効率あげる 計測品質向上 = 手戻り防止 = フロー効率あげる 実装品質向上 = 手戻り防止 = フロー効率あげる http://i2key.hateblo.jp/entry/2016/12/07/153146
  104. 104. 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 ・マルチタスクやめる ・ペアプログラミング ・モブプログラミング ・カンバン&WIP制限 ・デザインスプリント ・同期するようなタスクを減らす    :
  105. 105. 事例:特定の部分では仮説検証を 回しつつ、プロジェクト型の案件 も行う両立型
  106. 106. 顧客発見 【ニーズ検証】 顧客実証 【売って検証】 組織構築 【本格拡大】 Problem/Solution Fit Product/Market Fit Scaling Retention CAC < LTV 売上 課題解決可能 な最小限 売り方最適化 / 売上最大化売る 品質 モデル 魅力的品質 最低限の性能品質 魅力的品質 当たり前品質 アップセル/クロスセルに向けた性能品質 魅力的品質 当たり前品質 指標値例 検証アク ション 検証 ポイント MVP 目標 MVP作って壊す MVP 品質 最低限の 売れる状態 セグメントに応じて売れる状態 検証が既存ユーザに影響与えない 独自な価値提供を出来ているか 深い課題を抱えた顧客がいるか その課題の解決策は妥当か 開発 モデル例 独自な価値提供を出来ているか 顧客は本当に買ってくれるか コスト構造に無理がないか 顧客開拓 【リーチ検証】 独自な価値提供を出来ているか 最適な売り方の検証 最適な価格設定の検証 導入期 成長期 成熟期 【SoE】Agile【SoE】カウボーイ 【SoE】Agile 【SoR】WaterFall 利益 独自な価値提供を出来ているか CPA最適化 マーケットシェア 分析/検証 インフラ 要件 CVR最大化等のUI/UX仮説検証 価格設定/商品検討のための仮説検証 クロスセルのためのエンタープライズ個別対応開発 仮説検証済み機能によるマーケット刈り取り開発 納期必達型の商品開発 負債解消ビックリライト(ObjC->Swift化) ビジネス仮説検証の高速化文化祭前夜感と全能感を味わ う時期 & ALL高品質 競合との性能競争(消耗戦) キードライバー値 最大化 利益最大化 ビジネス フェーズ ■既存のユーザへの影響を最小化 ユーザーを任意の属性でセグメントする機能 ユーザーセグメントに対して機能の出し分けを可能にする 事業フェーズが進めば進むほど、既にたくさん使われているプロダクトで仮説 検証をすることになるため必要最低限の影響範囲で仮説検証をする ■検証結果が濁らないこと 仮説や施策単位に各種数値を計測出来る機能 (例)CV数が目標の場合、マーケの頑張りなのか、プロダクト改善によるCVR向上なのか切り分けができない ■検証方法の改善が出来ること(ファネル分析) 検証ポイントまでユーザが漏れずに到達できていること UI上の問題で検証ポイントまでユーザが到達していないのに、結果指標 のみを見て検証失敗とする誤判断することがある ■利用開始日別ユーザ単位の分析(コホート分析) 日々の流入イベント毎にユーザーの継続率を分離して計測 ユーザーインタビュー時に使い始めてもらった人の継続率を図る。特定 の日だけアドを少額流して、アドを当てたセグメントの継続率を見る等 リリース日単位の追加機能別のユーザーの継続率を分離して計測 どの機能追加が継続率にヒットしたかを確認する等 Feature Flag、A/Bテスト、Private Beta Test、Dark Launch、etc (Leanplum, Firebase, Optimizely, LaunchDarkly , etc)、独自インフラ手段 Localytics, Google Analytics, Firebase …etc
  107. 107. Business Capability Centric IT SoE SoR 入稿業務予約業務 課金業務 分析業務 UI/UX UI/UX UI/UX UI/UX 予約登録API 検索API 入稿API 決済API システム間 連携処理 参照API 参照API 参照API 検索API 集計処理 カスタマー 社内担当者 カスタマー 社内担当者 アプリ UI/UX ブックマーク 予約機能 検索機能 カスタマー 俊敏 アジャイル 仮説検証 売上・KPI 安定 計画駆動 仕様通り ROI・QCD 利用者 Business Capability 俊敏なKPI改善 俊敏なKPI改善 トラブル0件 トラブル0件 使いやすさ 正確な集計目的 BiModalIT アジャイル アジャイル アジャイル ウォーター フォール ウォーター フォール ウォーター フォール 重要な プロジェクト 型案件 Objective-C ↓ Swiftへ フルリライト 新機能の 実装前に 仮説検証 価格設定 のための 仮説検証 アジャイル アジャイル ウォーター フォール ウォーター フォール 学び最大化 学び最大化 重要な プロジェクト 型案件
  108. 108. マーケ組織 商品企画組織 営業組織 分析組織 プロダクト開発組織 プロダクトオーナー プロジェクト(WF) スクラム1 スクラム2 ガーディアン アーキテクト プロダクトオーナー プロキシー プロダクトオーナー プロキシー プロジェクトリーダー スクラムマスター ○○○○○ XXXXXX △△△△△ ○○○○○ プロダクトオーナー プロキシー ○○○○○ XXXXXX △△△△△ ○○○○○ ○○○○○ XXXXXX △△△△△ ○○○○○ エンジニア エンジニア エンジニア :エンジニア x N人 UI/UXデザイナー スクラムマスター エンジニア エンジニア エンジニア : SoR SoE SoE アプリフロントチーム
  109. 109. Business Capability Centric IT SoE SoR 入稿業務予約業務 課金業務 分析業務 UI/UX UI/UX UI/UX UI/UX 予約登録API 検索API 入稿API 決済API システム間 連携処理 参照API 参照API 参照API 検索API 集計処理 カスタマー 社内担当者 カスタマー 社内担当者 アプリ UI/UX ブックマーク 予約機能 検索機能 カスタマー 俊敏 アジャイル 仮説検証 売上・KPI 安定 計画駆動 仕様通り ROI・QCD 利用者 Business Capability 俊敏なKPI改善 俊敏なKPI改善 トラブル0件 トラブル0件 使いやすさ 正確な集計目的 BiModalIT アジャイル アジャイル アジャイル ウォーター フォール ウォーター フォール ウォーター フォール 重要な プロジェクト 型案件 Objective-C ↓ Swiftへ フルリライト 新機能の 実装前に 仮説検証 価格設定 のための 仮説検証 アジャイル アジャイル ウォーター フォール ウォーター フォール 学び最大化 学び最大化 重要な プロジェクト 型案件
  110. 110. マーケ組織 商品企画組織 営業組織 分析組織 プロダクト開発組織 プロダクトオーナー プロジェクト(WF) スクラム1 スクラム2 ガーディアン アーキテクト プロダクトオーナー プロキシー プロダクトオーナー プロキシー プロジェクトリーダー スクラムマスター ○○○○○ XXXXXX △△△△△ ○○○○○ プロダクトオーナー プロキシー ○○○○○ XXXXXX △△△△△ ○○○○○ ○○○○○ XXXXXX △△△△△ ○○○○○ エンジニア エンジニア エンジニア :エンジニア x N人 UI/UXデザイナー スクラムマスター エンジニア エンジニア エンジニア : SoR SoE SoE アプリフロントチーム
  111. 111. マーケ組織 商品企画組織 営業組織 分析組織 プロダクト開発組織 プロダクトオーナー プロジェクト(WF) スクラム1 スクラム2 ガーディアン アーキテクト プロダクトオーナー プロキシー プロダクトオーナー プロキシー プロジェクトリーダー スクラムマスター ○○○○○ XXXXXX △△△△△ ○○○○○ プロダクトオーナー プロキシー ○○○○○ XXXXXX △△△△△ ○○○○○ ○○○○○ XXXXXX △△△△△ ○○○○○ エンジニア エンジニア エンジニア :エンジニア x N人 UI/UXデザイナー スクラムマスター エンジニア エンジニア エンジニア : SoR SoE SoE リソース効率 & フロー効率 例:CCPM アプリフロントチーム
  112. 112. Business Capability Centric IT SoE SoR 入稿業務予約業務 課金業務 分析業務 UI/UX UI/UX UI/UX UI/UX 予約登録API 検索API 入稿API 決済API システム間 連携処理 参照API 参照API 参照API 検索API 集計処理 カスタマー 社内担当者 カスタマー 社内担当者 アプリ UI/UX ブックマーク 予約機能 検索機能 カスタマー 俊敏 アジャイル 仮説検証 売上・KPI 安定 計画駆動 仕様通り ROI・QCD 利用者 Business Capability 俊敏なKPI改善 俊敏なKPI改善 トラブル0件 トラブル0件 使いやすさ 正確な集計目的 BiModalIT アジャイル アジャイル アジャイル ウォーター フォール ウォーター フォール ウォーター フォール 重要な プロジェクト 型案件 Objective-C ↓ Swiftへ フルリライト 新機能の 実装前に 仮説検証 価格設定 のための 仮説検証 アジャイル アジャイル ウォーター フォール ウォーター フォール 学び最大化 学び最大化 重要な プロジェクト 型案件
  113. 113. マーケ組織 商品企画組織 営業組織 分析組織 プロダクト開発組織 プロダクトオーナー プロジェクト(WF) スクラム1 スクラム2 ガーディアン アーキテクト プロダクトオーナー プロキシー プロダクトオーナー プロキシー プロジェクトリーダー スクラムマスター ○○○○○ XXXXXX △△△△△ ○○○○○ プロダクトオーナー プロキシー ○○○○○ XXXXXX △△△△△ ○○○○○ ○○○○○ XXXXXX △△△△△ ○○○○○ エンジニア エンジニア エンジニア :エンジニア x N人 UI/UXデザイナー スクラムマスター エンジニア エンジニア エンジニア : SoR SoE SoE アプリフロントチーム
  114. 114. マーケ組織 商品企画組織 営業組織 分析組織 プロダクト開発組織 プロダクトオーナー プロジェクト(WF) スクラム1 スクラム2 ガーディアン アーキテクト プロダクトオーナー プロキシー プロダクトオーナー プロキシー プロジェクトリーダー スクラムマスター ○○○○○ XXXXXX △△△△△ ○○○○○ プロダクトオーナー プロキシー ○○○○○ XXXXXX △△△△△ ○○○○○ ○○○○○ XXXXXX △△△△△ ○○○○○ エンジニア エンジニア エンジニア :エンジニア x N人 UI/UXデザイナー スクラムマスター エンジニア エンジニア エンジニア : SoR SoE SoE フロー効率 例:一個流し アプリフロントチーム
  115. 115. まとめ
  116. 116. ビジネスのことを考えて提案しているのに 受け入れられない場合、 前提の置き方を間違っていることが多い。 (間違った原理主義に陥っている可能性)
  117. 117. アジャイルにやりたい(はずだ)。 本当にそうだろうか?
  118. 118. リリースサイクルを高速化したい(はずだ)。 本当にそうだろうか?
  119. 119. 仮説検証型にしたい(はずだ)。 本当にそうだろうか?
  120. 120. 我々が忠誠を誓うのは、開発手法ではない。 目的である。 目的を問い、目的からはじめる。

×