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

1. 新規事業が対峙する現実からエンジニアリングを俯瞰するリクルートテクノロジーズ黒田　樹 @i2key DevLOVE200 Bridge

2. 文脈により事情は大きく変わると思うので、正解はないと思います。考え方の取っ掛かりにしていただければ。 ※注意想定読者・ビジネスに対峙するエンジニアリーダー的な人・ビジネスに価値貢献するとか、価値を作るといいつつ、それ以上具体的に言語化できない人・よかれと思う改善提案がビジネス側の理解を得られず悶々としている人・各種方法論(リーンスタートアップ、スクラム、etc)の説明はしません。実践者対象です。・ニッチ向け。

3. 越境の契機見えてきた勘所現場に還る

5. エンジニアリングビジネス PBL リリースプランニング振り返り MTG レビューデイリー MTG Sprint/2weeks 開発タスク/Day 僕の考えた最強の機能リスト

6. エンジニアリングビジネス PBL リリースプランニング振り返り MTG レビューデイリー MTG Sprint/2weeks 開発タスク/Day 【あるある】・プロダクトオーナーが施策のコスト責任を終えていない・各施策単位で効果測定が出来ていない（やりっぱなし・各施策単位での費用対効果の説明責任を果たせない僕の考えた最強の機能リスト PBLの質、超重要。（やる必然性・エビデンスの有無）どんなに開発チームがスペシャルでも、チームに　　をインプットすると結局、価値をうまない　　がチームからアウトプットされるボトルネックが開発→ビジネスへ遷移

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. 従来のプロダクトバックログ仮説検証型のプロダクトバックログ・仮説A検証用モック作成・仮説B検証用ダミーボタン実装・検証済み○○機能本実装・検証済み○○機能本実装・リファラル向上改善・登録ファネル改善・計測基盤実装・コホートに対するプッシュ実装・○○機能実装・○○機能実装・○○機能実装・○○機能実装・○○機能実装・○○機能実装・○○機能実装・○○機能実装・○○機能実装・○○機能実装・○○機能実装わざわざ開発せずにインタビューやエンジニアリング以外で検証できそう根拠無し根拠無し根拠無し事前検証 (エビデンス収集) 実証後の実装

9. 国内x企業内新規事業→海外xスタートアップ出資先海外スタートアップの日本市場グロース支援 www.slideshare.net/i2key/bp-leanstartup/42

10. NINTENDOの国からやってきた男としてやってみせるデブサミ2011【18-B-1】プログラマが知るべき、たったひとつの大事なことがら @t_wada 氏（現、弊社技術顧問氏）の原体験 https://www.slideshare.net/t_wada/the-only- one-big-thing-every-programmer-should-know

11. エンジニアリングビジネス PBL リリースプランニング振り返り MTG レビューデイリー MTG Sprint/2weeks 開発タスク/Day 計測構築学習データアイデアビジネス仮説リストセールス / マーケプランニング実行学習役割の視野を広げる売上、KPIを上げるためになんでもやる

12. http://www.slideshare.net/i2key/leanstartup-devlove-leanstartup http://l-orem.com/lean-startup-18-anti-patterns/ 多くの新規事業の現場から見えてきたアンチパターン集エンジニアなのに・・・膨大な量のビジネス企画のシャワーを浴びる RECRUIT VENTURES、リクルートグループ各社での布教活動（いっぱい）/各種審査員/新規事業アイデアの壁打ちメンター（大量）/etc

13. 1. キャンバス依存パターン 2. そもそもFounder/Market Fit、Founder/Product Fitしていないパターン 3. MVPでシンプルにやらなきゃだめだよ！だって、ネットの記事にそうかいてあるしパターン 4. 石橋叩きすぎパターン 5. シングルタスクパターン 6. 誰そのペルソナ、本当にいるのパターン 7. その人お金払わないよねパターン 8. 何か言っているようで何も言っていないパターン 9. キャバクラでの我々パターン 16. 性能競争パターン 17. 解決策ありきパターン 18. ○○がそれやったらどーすんのパターン

14. 経験した各フェーズの立ち回りから、時間軸の視野を広げる

16. この視界からエンジニアリングを見てみるこれ

17. 見えてきた勘所ビジネスモデルからエンジニアリングを見る

18. ビジネスモデル ↓ エンジニアリングの座組

19. とっかかりポイントどこで売上が発生しているか・エンジニアの書いたコード上で売上がたつ・エンジニアの書いたコード上で売上がたたない

20. コード上で売上がたつ場合

21. 検索条件入力画面検索結果一覧画面詳細画面予約画面口コミ SEO SEM ETC サービストップ画面 if(isBooked){ } 口コミ SEO SEM ETC 成果課金型広告枠検索サービス ¥0 利用者クライアントマッチングサービス CVR改善＝売上直結エンジニアの書いたコード上で売上がたつ例 CPA改善＝売上直結流入数

22. 検索条件入力画面検索結果一覧画面詳細画面予約画面口コミ SEO SEM ETC サービストップ画面 if(isBooked){ } 口コミ SEO SEM ETC 成果課金型広告枠検索サービス ¥0 利用者クライアントマッチングサービス CVR改善＝売上直結エンジニアの書いたコード上で売上がたつ例水漏れ補修水漏れ補修水漏れ補修水漏れ補修 CPA改善＝売上直結流入数エンジニアによるプロダクト改善が売上目標に直接寄与 = エンジニアが成長のエンジン（になりやすい） = エンジニアのビジネス貢献が可視化しやすい = 数値目標を持ったプロダクトチームが　じゃんじゃん改善サイクルを回すとよいパターン = アジャイルとか超導入しやすい座組（結果が売上で出る） = 内製化はじめるとかもここらへんが成果を出しやすい (憧れのエンジニア文化がある会社はこのモデル多め)

23. Acquisition 獲得 Retention 継続 Churn 解約 Referral 紹介 Activation 活性化 Revenue 収益 AARRRモデル

24. Acquisition(獲得) Retention(継続) Churn(解約) Referral(紹介) Activation(活性化) Revenue(収益) AARRRモデルマーケ営業プロダクト

25. 検索条件入力画面検索結果一覧画面詳細画面予約画面口コミ SEO SEM ETC サービストップ画面 if(isBooked){ } 口コミ SEO SEM ETC 成果課金型広告枠検索サービス ¥0 利用者クライアントマッチングサービス CVR改善＝売上直結エンジニアの書いたコード上で売上がたつ例水漏れ補修水漏れ補修水漏れ補修水漏れ補修 CPA改善＝売上直結流入数パワーバランスこうなりがち（逆もあるがほぼイコール）売上(CVR)・QCD ≧ 流入数・CV数　　　　　　(プロダクト)　　　　　(マーケ) 売上 CVR・QCD 流入数 CV数マーケプロダクト

26. コード上で売上がたたない場合

27. 検索条件入力画面検索結果一覧画面詳細画面予約画面口コミ SEO SEM ETC サービストップ画面 if(isBooked){ } 口コミ SEO SEM ETC 純広告枠（営業商品）検索サービス ¥0 利用者クライアントマッチングサービス CVR改善＝次回発注への信頼獲得 = 売上直結ではない営業エンジニアの書いたコード上で売上がたたない例 CV数流入数

28. 検索条件入力画面検索結果一覧画面詳細画面予約画面口コミ SEO SEM ETC サービストップ画面 if(isBooked){ } 口コミ SEO SEM ETC 純広告枠（営業商品）検索サービス ¥0 利用者クライアントマッチングサービス CVR改善＝次回発注への信頼獲得 = 売上直結ではない営業エンジニアの書いたコード上で売上がたたない例 CV数流入数売上 CVR・QCD 流入数 CV数マーケプロダクト営業パワーバランスこうなりがち売上 > 流入数・CV数 > CVR・QCD (営業)　　　　　(マーケ)　　　　　　　(プロダクト)

29. Acquisition(獲得) Retention(継続) Churn(解約) Referral(紹介) Activation(活性化) Revenue(収益) AARRRモデルマーケ営業プロダクト営業

30. 検索条件入力画面検索結果一覧画面詳細画面予約画面口コミ SEO SEM ETC サービストップ画面 if(isBooked){ } 口コミ SEO SEM ETC 純広告枠（営業商品）検索サービス ¥0 利用者クライアントマッチングサービス CVR改善＝次回発注への信頼獲得 = 売上直結ではない営業エンジニアの書いたコード上で売上がたたない例 CV数流入数売上 CVR・QCD 流入数 CV数マーケプロダクト営業営業が売上に直接的に寄与 = 営業が成長エンジン（売上○○円/人予測可能）エンジニアは顧客単価を上げるための商品開発で寄与＆安定運用（QCD）＆改善（CVR向上）顧客単価UP貢献・イケイケアルゴリズム・競合を凌駕する技術優位

31. 検索条件入力画面検索結果一覧画面詳細画面予約画面口コミ SEO SEM ETC サービストップ画面 if(isBooked){ } 口コミ SEO SEM ETC 純広告枠（営業商品）検索サービス ¥0 利用者クライアントマッチングサービス CVR改善＝次回発注への信頼獲得 = 売上直結ではない営業エンジニアの書いたコード上で売上がたたない例 CV数流入数売上 CVR・QCD 流入数 CV数マーケプロダクト営業顧客単価UP貢献営業が売上に直接的に寄与 = 営業が成長エンジン（売上○○円/人予測可能）エンジニアは顧客単価を上げるための商品開発で寄与＆安定運用（QCD）＆改善（CVR向上）ビジネス貢献が可視化しにくい場合

32. 検索条件入力画面検索結果一覧画面詳細画面予約画面口コミ SEO SEM ETC サービストップ画面 if(isBooked){ } 口コミ SEO SEM ETC 純広告枠（営業商品）検索サービス ¥0 利用者クライアントマッチングサービス CVR改善＝次回発注への信頼獲得 = 売上直結ではない営業エンジニアの書いたコード上で売上がたたない例エンジニアのビジネス貢献が可視化しにくい場合 = トラブルだけが目立つようになる = できて当たり前（減点主義）のパラダイム = エンジニアはコスト削減や生産性向上のようなビジネス指標から程遠い目標設定になる = QCDSの制約の雁字搦めになるので、エンジニア側は壁を作りディフェンシブになりだす = 本来、俊敏に開発したい目的に反して、組織がスローダウンしていく

33. 放置していると組織としての慣性は、ビジネス部門と開発部門の社内受発注な関係に向かいやすい

34. ・エンジニアの書いたコード上で売上がたつ　→攻めのエンジニアリング要素強め　　→でも、その中にも守りの要素はある。・エンジニアの書いたコード上で売上がたたない　→守りのエンジニアリング要素強め　　→でも、その中にも攻めの要素はある。ひとつの塊として扱うのではなく適材適所で攻め/守りの目的に合わせたエンジニアリングが必要

35. 見えてきた勘所ビジネス戦略、プロダクト戦略からエンジニアリングを見る

36. ビジネス戦略プロダクト戦略 ↓ エンジニアリング戦略 6 のぼり方・戦略

37. エンジニアがビジネス貢献すると思ってやっていることが、実はそこまで重要ではない場合もある。一般的に正しいとされている方法論を実施したときに、いずれかのハレーションが生まれるような場合、前提の置き方を間違っていることが多い。（間違った原理主義に陥っている可能性）

38. アジャイルにやりたい（はずだ）。本当にそうだろうか？

39. リリースサイクルを高速化したい（はずだ）。本当にそうだろうか？

40. 仮説検証型にしたい（はずだ）。本当にそうだろうか？

41. 仮説検証型にしたい（はずだ）。本当にそうだろうか？目的意識は持っているものの、目的をエンジニアが決めつけていて、ビジネスと目的がすりあっていない可能性

42. ビジネス「側」はエンジニアのことを理解してくれないとかいうのではなく、まずは、膝を突き合わせて語りお互いを理解すること。ビジネス戦略を正しく捉えた上での戦略に合わせた開発手法なり技術選定なりが必要本当の目的にあわせて開発のやりかたを決める。まずは目的を問う。

43. 我々が忠誠を誓うのは、開発手法ではない。目的である。目的を問い、目的からはじめる。そこからズレると現場が不幸になる。

44. https://www.slideshare.net/papanda/ss-72221454 時を越えた越境への道　@papanda 氏ここで世界線が交差する

45. https://www.youtube.com/watch?v=-WTZ2frEiZU https://www.youtube.com/watch?v=QKgBsEISAbM https://www.youtube.com/watch?v=DVVQGdcYY88 Geoﬀrey 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. Bi-modal IT Bimodal IT Mode1 Mode2 別名 System of Record(SoR) System of Engagement(SoE) 適正基幹系・勘定系、ミッションクリティカルな機能・システム (決済システム、顧客管理等) 正解が無い中、柔軟に変化をしながら走り続ける必要がある機能・サービス (スマホアプリ、ウェブサービスのフロント) 目的信頼性、安定性定めた仕様に従って安定性や品質を担保しながら開発していく必要がある俊敏性、速度フィードバックに基づいて速やかに改善を加え、頻繁にリリースする価値・評価費用対効果、コスト売上、ブランド、UX アプローチウォーターフォール、V-model、重量IID アジャイル、リーン、カンバン、軽量IID 調達エンタープライズサプライヤー、長期的な取引小さい、新しいベンダー、短期間の取引メンバ適正従来のプロセス、プロジェクトが得意新しくて不確実なプロジェクトが得意組織/文化開発部門・計画型ビジネス＆開発混在・探索型サイクルタイム数ヶ月数日、数週間 Geoﬀrey Moore “SOEs operating on top of and in touch with SORs” 企業内のIT戦略として適材適所で SoRとSoEが共存していきましょうという話

47. BusinessCapabilityCentric https://martinfowler.com/bliki/BusinessCapabilityCentric.html Agile IT Organization Design: For Digital Transformation and Continuous Delivery Bi modal IT戦略は、SoEかSoRかの二極化の議論になりがちなので、そうではなく実際のビジネスケーパビリティによってチームを組んでそれぞれで適した開発（手法・技術）をしましょう。そのほうがチームを長期間存続させることができます。という話。広義なマイクロサービスの組織論サイドにも近い。

48. 方法論や考え方は、真理に対して、それぞれ別の角度から光を当てているため、 1つの方法論に固執すると視野が狭まり、本質を見失い、過度な原理主義に陥る恐れがある。

49. 真理バイモーダル戦略 BusinessCapabilityCenrticIT SoRとSoEの二極化で整理できるわけないだろ特定の位置から光をあてると影の部分に対してヤジがとんでくるだから、 SoRとSoEはグラデーションだっていってんだろ

50. 真理バイモーダル戦略 BusinessCapabilityCenrticIT ビジネス能力だけで開発手法決まるわけないだろ！！！特定の位置から光をあてると影の部分に対してヤジがとんでくる

51. 影になる部分を補うように、それぞれの方向から光を当ててみる真理バイモーダル戦略 BusinessCapabilityCenrticIT

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. 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. 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. 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. 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. 見えてきた勘所ビジネスフェーズからエンジニアリングを見る

58. ビジネスフェーズ ↓ 求められるプロダクト品質

59. 充足不充足満足不満足顧客の満足感物理的な充足度魅力品質当たり前品質アーリーアダプターにはここ弱めにするか。とかマネタイズ検証時には必要だね。とか Minimum Sellable Product 性能品質魅力品質性能品質当たり前品質不充足でも不満には思わないが、充足されれば満足 <例> ハイレゾ音源（あれば良いが、なくても不満ではない）、曲面液晶など不充足だと不満、充足されると満足 <例> バッテリーの持ち（稼働時間が長ければ満足、短いと不満）、重量など不充足だと不満、充足されて当たり前 <例> 通話音声（音が良くて当たり前、聞き取りづらいと不満）狩野モデル一般論

60. 深い課題を抱えた顧客がいるかその課題の解決策は妥当か顧客発見顧客実証顧客開拓組織構築 [ニーズ検証] [売って検証] [リーチ検証] [本格拡大] 独自な価値提供を出来ているか顧客は本当に買ってくれるかコスト構造に無理がないか独自な価値提供を出来ているか最適な売り方の検証最適な価格設定の検証独自な価値提供を出来ているか Problem Solution Fit Product Market Fit Scaling Retention CAC < LTV 最大LTVセグメントの比率課題解決可能な最小限売り方最適化 / 売上最大化売るビジネスフェーズ狩野モデル魅力的品質最低限の性能品質魅力的品質当たり前品質アップセル・クロスセルに向けた性能品質魅力的品質当たり前品質指標値例検証アクション検証ポイント MVP 目標 MVP作って壊す MVP 品質最低限の売れる状態セグメントに応じて売れる状態検証が既存ユーザに影響与えない

61. 充足不充足満足不満足顧客の満足感物理的な充足度魅力品質当たり前品質アーリーアダプターにはここ弱めにするか。とかマネタイズ検証時には必要だね。とか Minimum Sellable Product 性能品質魅力品質性能品質当たり前品質不充足でも不満には思わないが、充足されれば満足 <例> ハイレゾ音源（あれば良いが、なくても不満ではない）、曲面液晶など不充足だと不満、充足されると満足 <例> バッテリーの持ち（稼働時間が長ければ満足、短いと不満）、重量など不充足だと不満、充足されて当たり前 <例> 通話音声（音が良くて当たり前、聞き取りづらいと不満）狩野モデル

64. ビジネスフェーズ ↓ 求められるエンジニア像

65. ビジネスフェーズからエンジニア像を俯瞰してみる（ユニークなValuePropositionが技術ではない場合の例） Problem / Solu,on Fit Product / Market Fit Scaling 100% %me Scale MySQL MVP iOS iOS KPI 検証用のMVPを高速に実装ビジネス文脈を意識した品質担保＆成長貢献セグメントに応じた性能向上顧客発見顧客実証顧客開拓

66. 検証を設計する（実証条件/実証方法/etc）効果を計測する KPI（数値目標）を設定するリリースするユーザがコンバージョンする仮説をたてる仕様にする設計するユーザーに届くユーザーが使うユーザーが気づく KPI（数値目標）達成指標：ベロシティ/デプロイ回数/性能値/品質/コスト/etc エンジニアのコミットと目標データから学ぶ（仮説を修正する　　打ち手を変える）エンジニアが直接結果をコントロール出来る範囲（コードのみに対峙してる）エンジニアが直接結果をコントロール出来ない範囲（ユーザーの判断という不確実性が介在）テストする実装する指標：MAU/継続率/○○率/売上/etc

67. 検証を設計する（実証条件/実証方法/etc）効果を計測する KPI（数値目標）を設定するリリースするユーザがコンバージョンする仮説をたてる仕様にする設計するユーザーに届くユーザーが使うユーザーが気づく KPI（数値目標）達成指標：ベロシティ/デプロイ回数/性能値/品質/コスト/etc エンジニアのコミットと目標データから学ぶ（仮説を修正する　　打ち手を変える）エンジニアが直接結果をコントロール出来る範囲（コードのみに対峙してる）エンジニアが直接結果をコントロール出来ない範囲（ユーザーの判断という不確実性が介在）テストする実装する指標：MAU/継続率/○○率/売上/etc マルチロールにしみ出す

68. 検証を設計する（実証条件/実証方法/etc）効果を計測する KPI（数値目標）を設定するリリースするユーザがコンバージョンする仮説をたてる仕様にする設計するユーザーに届くユーザーが使うユーザーが気づく KPI（数値目標）達成指標：ベロシティ/デプロイ回数/性能値/品質/コスト/etc エンジニアのコミットと目標データから学ぶ（仮説を修正する　　打ち手を変える）エンジニアが直接結果をコントロール出来る範囲（コードのみに対峙してる）エンジニアが直接結果をコントロール出来ない範囲（ユーザーの判断という不確実性が介在）テストする実装する指標：MAU/継続率/○○率/売上/etc それぞれのプロ

69. 見えてきた勘所ビジネス仮説検証プロセスからエンジニアリングを見る

70. 仮説検証プロセス ↓ エンジニアリングによる仮説検証基盤構築

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. 見えてきた勘所予算計画のリズムからエンジニアリングを見る

73. 1年 1年 1年予算のリズム ↓ 開発のリズム（ほんとに？？？？？）答え持っていないのでここは誰かご教授願いたいです（課題提起プレゼン）次年度予算計画次年度予算計画次年度予算計画

74. Bimodal IT Mode1 Mode2 別名 System of Record(SoR) System of Engagement(SoE) 適正基幹系・勘定系、ミッションクリティカルな機能・システム (決済システム、顧客管理等) 正解が無い中、柔軟に変化をしながら走り続ける必要がある機能・サービス (スマホアプリ、ウェブサービスのフロント) 目的信頼性、安定性定めた仕様に従って安定性や品質を担保しながら開発していく必要がある俊敏性、速度フィードバックに基づいて速やかに改善を加え、頻繁にリリースする価値・評価費用対効果、コスト売上、ブランド、UX アプローチウォーターフォール、V-model、重量IID アジャイル、リーン、カンバン、軽量IID 調達エンタープライズサプライヤー、長期的な取引小さい、新しいベンダー、短期間の取引メンバ適正従来のプロセス、プロジェクトが得意新しくて不確実なプロジェクトが得意組織/文化開発部門・計画型ビジネス＆開発混在・探索型サイクルタイム数ヶ月数日、数週間本当は、俊敏性や速度を持ってやりたいのに、結果的に重厚長大な計画駆動型になってしまう場合もある年次予算計画の圧本当は、こうしたいのに

75. エンタープライズの場合、年次の予算計画があり、ベースとなるサイクルタイムは年になる。 1年先の未来の状況を事前に予想して計画しないとならない。そして、それを1年後まで大幅に変更することはない。計画の実行に固執すると「発見」による変更がきかなくなる 1年 1年 1年新規事業なのに年次計画駆動になるバイアス予算：目的のために確保する資金の合計（活動に費やせる金額の上限）戦略：実際にやることを定義するもの予算は戦略をどのように実現するべきか計画するのもではない顧客に価値を届けるこのと成否を予測したり評価したりするのもではない。課題：年次プロセス以外で資金調達する方法がない

76. 課題：年次プロセス以外で資金調達する方法がない →「発見」による軌道修正が不可能 →より多くの予算を確保するために多大な労力をかけて最高のビジネスプランを計画（予想ｗ）しないとならない解決策事例1：新規事業組織部門としてバジェットは年次固定で持ちつつ、それを部門内で資金調達型で各新規事業へ配分していく。各事業にステージ(調達額上限)を設定。同時に撤退のルールも決め予算の「選択と集中」を行う。 http://www.slideshare.net/i2key/bp-leanstartup#94

77. 解決策事例2：活動基準会計を行う。前述の新規事業単位での資金調達よりも、細かい現場での機能追加レベルでの資金調達法。仮説検証の学びに対するコストの説明責任を設ける。仮説検証、ひとつひとつに対して何を学ぶのか、検証するために何が必要なのか、どのように計測するのか、いくらかかるのかを設計する。優先付をして学びに対するムダの無い投資をする。 http://www.slideshare.net/i2key/45-developers-summit-2015-devsumi-devsumib#141

78. 行動様式現場で得られた数々の経験から汎化し自分なりの勘所(原理原則)を導き出し、またそれを経験や疑似体験に照らし合わせ補正していく

79. 脳内整理 Version 1.0

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. 顧客発見【ニーズ検証】顧客実証【売って検証】組織構築【本格拡大】 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. リーンスタートアップ制約理論デザインシンキング顧客開発トヨタ生産方式アジャイルスクラム XP リーンソフトウェア開発真理バイモーダル戦略 BusinessCapabilityCenrticIT モダンアジャイル TDD Flow Eﬃciency KANBAN ペアプログラミングゆとりの法則

86. フロー効率性とリソース効率性のパラダイムを効果的に使い分けて現場を推進すること SoEでもSoRでもそれは変わらない。 http://i2key.hateblo.jp/entry/2017/05/15/082655

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. リソース効率性とフロー効率性 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. リソース効率フロー効率 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. リソース効率性フロー効率性 1つのリソースを稼働率が 100%になるまで分配するフローユニットが享受できるリソースを最大化する This is Lean https://www.amazon.co.jp/dp/919803930X/ 例：マルチタスク例：ペアプログラミング This is Leanの P21 The Eﬃciency Matrix

91. わたしあなた彼「ゆとりの法則」より各従業員の机に一時置き場がなければ、組織の全従業員が常に100％忙しいということはありえない。

92. わたしあなた彼書類受け書類受け書類受け全員の机に一時置き場（書類受け）を用意すると、全員が常に忙しくなるような仕事の流れを作ることができる

93. わたしあなた彼書類受け書類受け書類受け稼働率100% 稼働率100% 稼働率100% 待ちタスクいっぱい待ちタスクいっぱい待ちタスクいっぱいリードタイムが生まれるリードタイムが生まれるリードタイムが生まれるリソースの効率性は高まるが、副作用として仕事が組織の中で処理されるのにかかる時間が長くなる（組織の速度低下）

94. 待ち行列理論・100%の利用率の高速道路は、駐車場といっしょ・CPU100%利用率のパソコンは？・稼働率100%のチームは？スループットを最大化ではなくチームに最適化する・処理中のもの量の最小化・処理中のもののサイズを最小化チームへの負荷を調整・たくさんのこと同時にしない・タスク管理ではなく、チームのペースを管理する仕事の許容量を制限する・スコープボックスではなくタイムボックス・プッシュ型ではなくプル型でやるフロー効率を高めるために（顧客へ価値が届くまでのリードタイムを短くする）

95. 事例：学びの回数の最大化

96. 提案サービス ¥0 クライアント企業従業員クライアント BtoB 従業員向け SaaS型サービス営業 time (月) ：：：受注率継続率継続率 BtoBのSaaSモデル

97. Acquisition(獲得) Retention(継続) Churn(解約) Referral(紹介) Activation(活性化) Revenue(収益) マーケ営業プロダクト

98. xxx画面 xxx画面 xxx画面 CV画面サービストップ画面 if(isConverted){ } 営業

99. 最適な売り方、最適な価格設定の検証フェーズ

100. ・営業が獲得と初回売上立てるモデル　　↓ ・月額課金における継続率は　プロダクトで担保しつつ、　最適な価格設定の検証を走らせる　　↓ ・仮説検証の学びの回数最大化　　↓ ・仮説検証の速度の最大化　（本番デプロイ回数/日）　　※リリースまでのリードタイム最小化最適な売り方、最適な価格設定の検証フェーズ

101. ・フェーズ的に売り物を使って　仮説検証していく　　↓ ・MVPは当たり前品質、性能品質必要　（競合同等の機能品質がないと買ってもらえない　　→検証したい価格設定の検証ができない）　　↓ ・仮説検証の質を最大化　　↓ ・プロダクト品質・既存ユーザに仮説検証で　迷惑をかけない仕組み・濁らない計測最適な売り方、最適な価格設定の検証フェーズ

102. 仮説検証トライ回数最大化仮説検証トライ品質最大化（デプロイ回数/日） http://i2key.hateblo.jp/entry/2016/12/07/153146

103. 仮説検証トライ回数最大化仮説検証トライ品質最大化（デプロイ回数/日）プロセス品質向上 = 手戻り防止 = フロー効率あげるリードタイム削減 =フロー効率あげるプロセスタイムの削減＝フロー効率あげる仮説品質向上 = 手戻り防止 = フロー効率あげる計測品質向上 = 手戻り防止 = フロー効率あげる実装品質向上 = 手戻り防止 = フロー効率あげる http://i2key.hateblo.jp/entry/2016/12/07/153146

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. 事例：特定の部分では仮説検証を回しつつ、プロジェクト型の案件も行う両立型

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. 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. マーケ組織商品企画組織営業組織分析組織プロダクト開発組織プロダクトオーナープロジェクト(WF) スクラム1 スクラム2 ガーディアンアーキテクトプロダクトオーナープロキシープロダクトオーナープロキシープロジェクトリーダースクラムマスター ○○○○○ XXXXXX △△△△△ ○○○○○ プロダクトオーナープロキシー ○○○○○ XXXXXX △△△△△ ○○○○○ ○○○○○ XXXXXX △△△△△ ○○○○○ エンジニアエンジニアエンジニア：エンジニア x N人 UI/UXデザイナースクラムマスターエンジニアエンジニアエンジニア： SoR SoE SoE アプリフロントチーム

111. マーケ組織商品企画組織営業組織分析組織プロダクト開発組織プロダクトオーナープロジェクト(WF) スクラム1 スクラム2 ガーディアンアーキテクトプロダクトオーナープロキシープロダクトオーナープロキシープロジェクトリーダースクラムマスター ○○○○○ XXXXXX △△△△△ ○○○○○ プロダクトオーナープロキシー ○○○○○ XXXXXX △△△△△ ○○○○○ ○○○○○ XXXXXX △△△△△ ○○○○○ エンジニアエンジニアエンジニア：エンジニア x N人 UI/UXデザイナースクラムマスターエンジニアエンジニアエンジニア： SoR SoE SoE リソース効率＆フロー効率例：CCPM アプリフロントチーム

114. マーケ組織商品企画組織営業組織分析組織プロダクト開発組織プロダクトオーナープロジェクト(WF) スクラム1 スクラム2 ガーディアンアーキテクトプロダクトオーナープロキシープロダクトオーナープロキシープロジェクトリーダースクラムマスター ○○○○○ XXXXXX △△△△△ ○○○○○ プロダクトオーナープロキシー ○○○○○ XXXXXX △△△△△ ○○○○○ ○○○○○ XXXXXX △△△△△ ○○○○○ エンジニアエンジニアエンジニア：エンジニア x N人 UI/UXデザイナースクラムマスターエンジニアエンジニアエンジニア： SoR SoE SoE フロー効率例：一個流しアプリフロントチーム

115. まとめ

116. ビジネスのことを考えて提案しているのに受け入れられない場合、前提の置き方を間違っていることが多い。（間違った原理主義に陥っている可能性）

117. アジャイルにやりたい（はずだ）。本当にそうだろうか？

118. リリースサイクルを高速化したい（はずだ）。本当にそうだろうか？

119. 仮説検証型にしたい（はずだ）。本当にそうだろうか？

120. 我々が忠誠を誓うのは、開発手法ではない。目的である。目的を問い、目的からはじめる。

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

Itsuki Kuroda

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