Download as PDF, PPTX
![深い課題を抱えた顧客がいるかその課題の解決策は妥当か顧客発見 顧客実証 顧客開拓 組織構築[ニーズ検証] [売って検証] [リーチ検証] [本格拡大]独自な価値提供を出来ているか顧客は本当に買ってくれるかコスト構造に無理がないか独自な価値提供を出来ているか最適な売り方の検証最適な価格設定の検証独自な価値提供を出来ているかProblemSolutionFitProductMarketFitScalingRetention CAC < LTV 最大LTVセグメントの比率課題解決可能な最小限売り方最適化 / 売上最大化売るビジネスフェーズ狩野モデル魅力的品質 最低限の性能品質魅力的品質当たり前品質アップセルに向けた性能品質魅力的品質当たり前品質指標値例検証アクション検証ポイントMVP目標MVP作って壊すMVP品質最低限の売れる状態セグメントに応じて売れる状態検証が既存ユーザに影響与えない](/image.pl?url=https%3a%2f%2fimage.slidesharecdn.com%2fdeveloperssummit2017-170215170508%2f75%2fdevsumiB-devsumi-35-2048.jpg&f=jpg&w=240)
Uploaded byItsuki Kuroda
PDF, PPTX56,345 views
新規事業が対峙する現実からエンジニアリングを俯瞰する #devsumiB #devsumi
Developers summit 2017の 【16-B-7】セッションのスライドです。
Recommended
More Related Content
What's hot
Viewers also liked
![[社内勉強会]ELBとALBと数万スパイク負荷テスト](/image.pl?url=https%3a%2f%2fcdn.slidesharecdn.com%2fss_thumbnails%2felbalb-160822022623-thumbnail.jpg%3fwidth%3d640%26amp%3bheight%3d640%26amp%3bfit%3dbounds&f=jpg&w=240)
Similar to 新規事業が対峙する現実からエンジニアリングを俯瞰する #devsumiB #devsumi
More from Itsuki Kuroda
新規事業が対峙する現実からエンジニアリングを俯瞰する #devsumiB #devsumi
- 1.新規事業が対峙する現実からエンジニアリングを俯瞰するRECRUIT TECHNOLOGIESIT ManagementDivisionDevelopment 2 , DevOps0GKuroda Itsuki @i2key
- 2.
- 3.
- 4.
- 5.
- 6.
- 7.
- 8.
- 9.リクルートジョブズリクルート住まいカンパニーリクルート住まいカンパニーRECRUITVENTURESTechLab PAAKRECRUITVENTURESRECRUIT VENTURESRECRUITVENTURES（全拠点生放送）http://www.slideshare.net/i2key/leanstartup-devlove-leanstartuphttp://l-orem.com/lean-startup-18-anti-patterns/多くの新規事業の現場から見えてきたアンチパターン集エンジニアなのに・・・膨大な量のビジネス企画のシャワーを浴びるRECRUIT VENTURES、リクルートグループ各社での布教活動（いっぱい）/各種審査員/新規事業アイデアの壁打ちメンター（大量）/etc
- 10.
- 11.
- 12.
- 13.
- 14.
- 15.
- 16.https://www.youtube.com/watch?v=-WTZ2frEiZUhttps://www.youtube.com/watch?v=QKgBsEISAbM https://www.youtube.com/watch?v=DVVQGdcYY88Geoffrey MooreKeynote: The Future of Enterprise IT (part 1,2,3)http://www.gartner.com/it-glossary/bimodal/System of EngagementBimodal IT BusinessCapabilityCentrichttps://martinfowler.com/bliki/BusinessCapabilityCentric.html一般論
- 17.Bi-modal ITBimodal ITMode1 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.
- 19.検索条件入力画面検索結果一覧画面詳細画面 予約画面口コミSEOSEMETCサービストップ画面if(isBooked){}口コミSEOSEMETC成果課金型広告枠検索サービス¥0利用者 クライアントマッチングサービスCVR改善＝ 売上直結エンジニアの書いたコード上で売上がたつ例CPA改善 ＝ 売上直結流入数
- 20.検索条件入力画面検索結果一覧画面詳細画面 予約画面口コミSEOSEMETCサービストップ画面if(isBooked){}口コミSEOSEMETC成果課金型広告枠検索サービス¥0利用者 クライアントマッチングサービスCVR改善＝ 売上直結エンジニアの書いたコード上で売上がたつ例水漏れ補修 水漏れ補修 水漏れ補修 水漏れ補修CPA改善 ＝ 売上直結流入数エンジニアによるプロダクト改善が売上目標に直接寄与= エンジニアが成長のエンジン（になりやすい）= エンジニアのビジネス貢献が可視化しやすい= 数値目標を持ったプロダクトチームが じゃんじゃん改善サイクルを回すとよいパターン= アジャイルとか超導入しやすい座組（結果が売上で出る）(憧れのエンジニア文化がある会社はこのモデル多め)
- 21.エンジニアリングへのビジネス期待安定性 or 俊敏性 どちらなのかBimodalIT 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.検索条件入力画面検索結果一覧画面詳細画面 予約画面口コミSEOSEMETCサービストップ画面if(isBooked){}口コミSEOSEMETC純広告枠（営業商品）検索サービス¥0利用者 クライアントマッチングサービスCVR改善＝ 次回発注への信頼獲得 = 売上直結ではない営業エンジニアの書いたコード上で売上がたたない例CV数流入数
- 23.検索条件入力画面検索結果一覧画面詳細画面 予約画面口コミSEOSEMETCサービストップ画面if(isBooked){}口コミSEOSEMETC純広告枠（営業商品）検索サービス¥0利用者 クライアントマッチングサービスCVR改善＝ 次回発注への信頼獲得 = 売上直結ではない営業エンジニアの書いたコード上で売上がたたない例CV数流入数売上CVR・QCD流入数CV数マーケプロダクト営業パワーバランスこうなりがち売上 > 流入数・CV数 > CVR・QCD(営業) (マーケ) (プロダクト)
- 24.検索条件入力画面検索結果一覧画面詳細画面 予約画面口コミSEOSEMETCサービストップ画面if(isBooked){}口コミSEOSEMETC純広告枠（営業商品）検索サービス¥0利用者 クライアントマッチングサービスCVR改善＝ 次回発注への信頼獲得 = 売上直結ではない営業エンジニアの書いたコード上で売上がたたない例CV数流入数売上CVR・QCD流入数CV数マーケプロダクト営業パワーバランスこうなりがち売上 > 流入数・CV数 > CVR・QCD(営業) (マーケ) (プロダクト)CTO及びそれに準ずる人がいればその人が説明責任を持ち均衡を保ってくれるはずだが・・・大企業内新規事業だとそうもいかず・・・
- 25.検索条件入力画面検索結果一覧画面詳細画面 予約画面口コミSEOSEMETCサービストップ画面if(isBooked){}口コミSEOSEMETC純広告枠（営業商品）検索サービス¥0利用者 クライアントマッチングサービスCVR改善＝ 次回発注への信頼獲得 = 売上直結ではない営業エンジニアの書いたコード上で売上がたたない例CV数流入数売上CVR・QCD流入数CV数マーケプロダクト営業営業が売上に直接的に寄与= 営業が成長エンジン（ 売上○○円/人 予測可能）エンジニアは顧客単価を上げるための商品開発で寄与＆ 改善・安定運用（CVR向上・QCD）顧客単価UP貢献12
- 26.検索条件入力画面検索結果一覧画面詳細画面 予約画面口コミSEOSEMETCサービストップ画面if(isBooked){}口コミSEOSEMETC純広告枠（営業商品）検索サービス¥0利用者 クライアントマッチングサービスCVR改善＝ 次回発注への信頼獲得 = 売上直結ではない営業エンジニアの書いたコード上で売上がたたない例CV数流入数売上CVR・QCD流入数CV数マーケプロダクト営業営業が売上に直接的に寄与= 営業が成長エンジン（ 売上○○円/人 予測可能）エンジニアは顧客単価を上げるための商品開発で寄与＆ 改善・安定運用（CVR向上・QCD）顧客単価UP貢献ビジネス貢献を説明できず(理解されず)にここだけに極端にフォーカスがあたると・・・・ 12
- 27.検索条件入力画面検索結果一覧画面詳細画面 予約画面口コミSEOSEMETCサービストップ画面if(isBooked){}口コミSEOSEMETC純広告枠（営業商品）検索サービス¥0利用者 クライアントマッチングサービスCVR改善＝ 次回発注への信頼獲得 = 売上直結ではない営業エンジニアの書いたコード上で売上がたたない例エンジニアのビジネス貢献が可視化しにくい= トラブルだけが目立つようになる= できて当たり前（減点主義）のパラダイム= エンジニアはコスト削減や生産性向上のようなビジネス指標から程遠い目標設定になる= QCDSの制約の雁字搦めになるので、エンジニア側は壁を作りディフェンシブになりだす= 本来、俊敏に仮説検証回したい目的に反して、組織がスローダウンしていく12
- 28.Bimodal IT Mode1Mode2別名 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.
- 30.
- 31.
- 32.
- 33.
- 34.
- 35.深い課題を抱えた顧客がいるかその課題の解決策は妥当か顧客発見 顧客実証 顧客開拓組織構築[ニーズ検証] [売って検証] [リーチ検証] [本格拡大]独自な価値提供を出来ているか顧客は本当に買ってくれるかコスト構造に無理がないか独自な価値提供を出来ているか最適な売り方の検証最適な価格設定の検証独自な価値提供を出来ているかProblemSolutionFitProductMarketFitScalingRetention CAC < LTV 最大LTVセグメントの比率課題解決可能な最小限売り方最適化 / 売上最大化売るビジネスフェーズ狩野モデル魅力的品質 最低限の性能品質魅力的品質当たり前品質アップセルに向けた性能品質魅力的品質当たり前品質指標値例検証アクション検証ポイントMVP目標MVP作って壊すMVP品質最低限の売れる状態セグメントに応じて売れる状態検証が既存ユーザに影響与えない
- 36.ビジネスフェーズからエンジニア像を俯瞰してみる（ユニークなValuePropositionが技術ではない場合の例）Problem/Solu,onFit Product/MarketFit Scaling100%%meScaleMySQLMVP iOS iOS KPI 検証用のMVPを高速に実装ビジネス文脈を意識した品質担保＆成長貢献セグメントに応じた性能向上顧客発見 顧客実証 顧客開拓
- 37.
- 38.
- 39.仮説検証基盤要件 方法既存のユーザへの影響を最小化ユーザーを任意の属性でセグメントする機能管理コンソールの実装既存のユーザへの影響を最小化ユーザーセグメントに対して機能の出し分けを可能にする事業フェーズが進めば進むほど、既にたくさん使われているプロダクトで仮説検証をすることになるため必要最低限の影響範囲で仮説検証をするFeature Flag、A/Bテスト、PrivateBetaTest、Dark Launch、etc検証結果が濁らないこと仮説や施策単位に各種数値を計測出来る機能(例)CV数が目標の場合、マーケの頑張りなのか、プロダクト改善によるCVR向上なのか切り分けができないコホート分析検証方法の改善が出来ること検証ポイントまでユーザが漏れずに到達できていることUI上の問題で検証ポイントまでユーザが到達していないのに、検証失敗とする事案があるファネル分析： ： ：DevOps系プラクティス見れば基本ソレ
- 40.
- 41.
- 42.Bimodal IT Mode1Mode2別名 System of Record(SoR) System of Engagement(SoE)適正基幹系・勘定系、ミッションクリティカルな機能・システム(決済システム、顧客管理等)正解が無い中、柔軟に変化をしながら走り続ける必要がある機能・サービス(スマホアプリ、ウェブサービスのフロント)目的信頼性、安定性定めた仕様に従って安定性や品質を担保しながら開発していく必要がある俊敏性、速度フィードバックに基づいて速やかに改善を加え、頻繁にリリースする価値・評価 費用対効果、コスト 売上、ブランド、UXアプローチ ウォーターフォール、V-model、重量IID アジャイル、リーン、カンバン、軽量IID調達エンタープライズサプライヤー、長期的な取引小さい、新しいベンダー、短期間の取引メンバ適正 従来のプロセス、プロジェクトが得意 新しくて不確実なプロジェクトが得意組織/文化 開発部門・計画型 ビジネス＆開発混在・探索型サイクルタイム 数ヶ月 数日、数週間本当は、俊敏性や速度を持ってやりたいのに、結果的に重厚長大な計画駆動型になってしまう場合もある年次予算計画の圧本当は、こうしたいのに
- 43.
- 44.
- 45.
- 46.
- 47.
- 49.
- 50.xxx画面 xxx画面 xxx画面CV画面サービストップ画面if(isConverted){}○○改善 = 受注率向上□□改善 = 継続率向上 のキードライバが見えていないコード上なのかリアルなのか？?
- 51.
- 52.
- 53.
- 54.
- 55.仮説検証トライ回数最大化 仮説検証トライ品質最大化（デプロイ回数/日）プロセス品質向上= 手戻り防止=フロー効率あげるリードタイム削減=フロー効率あげるプロセスタイムの削減＝フロー効率あげる仮説品質向上= 手戻り防止= フロー効率あげる計測品質向上= 手戻り防止= フロー効率あげる実装品質向上= 手戻り防止= フロー効率あげるhttp://i2key.hateblo.jp/entry/2016/12/07/153146
- 56.リソース効率フロー効率This is LeanTheEfficiency Matrix①② ③④Efficient islands効率的な島々Wasteland荒廃した地Efficient ocean効率的な海The perfect stateHighHighLowLowhttps://www.amazon.co.jp/dp/919803930X/①あなたはここにいると思っている②実際には多分ここ③まずはフロー効率化からはじめて④その後にリソース効率化をしていく例）稼働率100%のチーム 機能がリリースされるまでのリードタイム長い例）稼働率は100%ではないチーム 機能がリリースされるまでのリードタイム短いVariationリソース効率（例）稼働率100%フロー効率（例）機能リリースまでのリードタイムの短さ
- 57.リソース効率フロー効率This is LeanTheEfficiency Matrix①② ③④Efficient islands効率的な島々Wasteland荒廃した地Efficient ocean効率的な海The perfect stateHighHighLowLowhttps://www.amazon.co.jp/dp/919803930X/①あなたはここにいると思っている②実際には多分ここ③まずはフロー効率化からはじめて④その後にリソース効率化をしていく例）稼働率100%のチーム 機能がリリースされるまでのリードタイム長い例）稼働率は100%ではないチーム 機能がリリースされるまでのリードタイム短いVariation
- 58.バックエンドエンジニアフロントエンジニアプロダクトオーナー顧客Feedback承認レビュー仕様確認API開発 API開発Front開発デプロイ待ち 待ちフロー効率をあげていく学ぶ（顧客のフィードバックを得る）までのリードタイムエンジニア(フロント＆バックエンド）フロントエンジニアプロダクトオーナー顧客Feedback承認条件API開発Front開発 デプロイ 待ち待ち待ち※先に提示された条件をパスすればリリース承認というルールにする等※フルスタック（）な振る舞いをすることで引き継ぎによるムダが減る※ここにきて手戻りが発生することも学ぶ(顧客のフィードバックを得る)までのリードタイム
- 59.
- 60.マルチタスクやめるA A AA A A A A A A A A A A ABCBCBCBCBCBCBCBCBCBCBCBCBCBCBCA A A A AA A A A AA A A A AB B B B BB B B B BB B B B BC C C C CC C C C CC C C C C月 火 水 木 金 月 火 水 木 金 月 火 水 木 金月 火 水 木 金 月 火 水 木 金 月 火 水 木 金リリースまでのリードタイム 1wリリースまでのリードタイム 2wリリースまでのリードタイム 3wリリースまでのリードタイム 3wリリースまでのリードタイム 3wリリースまでのリードタイム 3wたくさんのことを同時に調整しようとするから仕様の調整の「会議」やら「定例」やらがうまれる
- 61.A A AA A A A A A A A A A A ABCBCBCBCBCBCBCBCBCBCBCBCBCBCBCA A A A AA A A A AA A A A AB B B B BB B B B BB B B B BC C C C CC C C C CC C C C C月 火 水 木 金 月 火 水 木 金 月 火 水 木 金月 火 水 木 金 月 火 水 木 金 月 火 水 木 金リリースまでのリードタイム 1wリリースまでのリードタイム 2wリリースまでのリードタイム 3wリリースまでのリードタイム 3wリリースまでのリードタイム 3wリリースまでのリードタイム 3wたくさんのことを同時に調整しようとするから仕様の調整の「会議」やら「定例」やらがうまれるGit Flow・Release Branchがマルチタスクをうんでいる？・フロー効率あげるのに、可能なら一個流しにしたい↓Github Flow現在移行に向け奮闘中・CD・デプロイパイプライン・E2E Test整備・Feature Flagマルチタスクやめる（例）
- 62.
- 63.現在のチームのスプリントのポートフォリオ以下のタイムボックス管理50% 機能追加20% カイゼン（この枠で前述の各種カイゼン実施）15%既知バグ改修15% 新規バグ改修※打ち合わせや雑務の稼働時間は全部SprintBacklogにつんである上で残りの時間を上記に分配しているカイゼンに20％おいているは大事。（この20％の説明責任を果たし、ビジネス側に合意ををとるための勘所が本日のスライド。）エンジニアのカイゼンのモチベーションを奪ってはいけない。エンジニアの改善のモチベーションは良い方向に持っていこうとする善のエネルギー。それをしょうもない理由でへし折るとチーム全体がダークサイドへ堕ちてしまう。
- 64.
- 65.