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

新規事業が対峙する現実からエンジニアリングを俯瞰するRECRUIT TECHNOLOGIES IT Management Division Development 2 , DevOps0G Kuroda Itsuki @i2key

本スライドの主語：大企業内の新規事業

文脈により事情は大きく変わると思うので、正解はないと思います。

考え方の取っ掛かりにしていただければ。

※注意

想定読者・ビジネスに対峙するエンジニアリーダー的な人・ビジネスに価値貢献するとか、価値を作るといいつつ、それ以上具体的に言語化できない人・よかれと思う改善提案がビジネス側の理解を得られず悶々としている人

越境の足跡見えてきた勘所現場に還る


エンジニアリングビジネス

PBL

リリース

プランニング

振り返り MTG

レビュー

デイリー MTG

Sprint/2weeks 開発タスク/Day

エンジニアチーム全員の稼働を簡単にムダに出来るポジションだからこそ、プロダクトオーナー・プロダクトマネージャ採用基準は厳しい（あるべき）

僕の考えた最強の機能リスト

PBLの質、超重要。（やる必然性・エビデンスの有無）

施策に対するコスト責任をおえている、もしくは、他の施策と濁り無く施策効果を単体で計測できる環境がないと実施内容が大きくてキラキラするバイアスが発生することがある。実際の数値で施策の結果を評価できないため賑やかなものを作りたくなる。（各種構造上の問題）

どんなに開発チームがスペシャルでも、チームに　　をインプットすると結局、価値をうまない　　がチームからアウトプットされる


PBL

リリース

プランニング

振り返り MTG

レビュー

デイリー MTG


計測

構築

学習

データ

アイデア

ビジネス仮説リスト

全部、思い込みだと前提におく

思い込みにより発生する各種ムダを省くためにリーンにやる

http://www.slideshare.net/i2key/45-developers-summit-2015-devsumi-devsumibhttp://www.slideshare.net/i2key/devsumi-natsumic7

※(元)僕の考えた最強の機能リスト

従来のプロダクトバックログ

仮説検証型のプロダクトバックログ

・仮説A検証用モック作成・仮説B検証用ダミーボタン実装・検証済み○○機能本実装・検証済み○○機能本実装・リファラル向上改善・登録ファネル改善・計測基盤実装・コホートに対するプッシュ実装

・○○機能実装・○○機能実装・○○機能実装・○○機能実装・○○機能実装・○○機能実装・○○機能実装・○○機能実装・○○機能実装・○○機能実装・○○機能実装

わざわざ開発せずにインタビューやエンジニアリング以外で検証できそう

根拠無し

根拠無し

根拠無し

事前検証 (エビデンス収集)

実証後の実装

国内x企業内新規事業→海外xスタートアップ

出資先海外スタートアップの日本市場グロース支援

www.slideshare.net/i2key/bp-leanstartup/42

リクルートジョブズリクルート住まいカンパニー

リクルート住まいカンパニー

RECRUIT VENTURESTechLab PAAK

RECRUIT VENTURES

RECRUIT VENTURESRECRUIT VENTURES

（全拠点生放送）

http://www.slideshare.net/i2key/leanstartup-devlove-leanstartuphttp://l-orem.com/lean-startup-18-anti-patterns/

多くの新規事業の現場から見えてきたアンチパターン集

エンジニアなのに・・・膨大な量のビジネス企画のシャワーを浴びる RECRUIT VENTURES、リクルートグループ各社での布教活動（いっぱい）/各種審査員/新規事業アイデアの壁打ちメンター（大量）/etc


PBL

リリース

プランニング

振り返り MTG

レビュー

デイリー MTG


計測

構築

学習

データ

アイデア

ビジネス仮説リスト

セールス / マーケ

プランニング

実行

学習

役割の視野を広げる

時間軸の視野を広げる


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

これ

見えてきた勘所

ビジネスモデルからエンジニアリングを見る

ビジネスモデル ↓

エンジニアリングの座組

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

一般論

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が共存していきましょうという話

とっかかりポイント

どこで売上が発生しているか・エンジニアの書いたコード上で売上がたつ・エンジニアの書いたコード上で売上がたたない

検索条件入力画面

検索結果一覧画面詳細画面予約画面

口コミ

SEO

SEM

ETC

サービストップ画面

if(isBooked){

}

口コミ

SEO

SEM

ETC

成果課金型広告枠検索サービス

¥0利用者クライアント

マッチングサービス

CVR改善＝売上直結

エンジニアの書いたコード上で売上がたつ例

CPA改善＝売上直結

流入数



口コミ

SEO

SEM

ETC


if(isBooked){

}

口コミ

SEO

SEM

ETC

成果課金型広告枠検索サービス



CVR改善＝売上直結

エンジニアの書いたコード上で売上がたつ例

水漏れ補修水漏れ補修水漏れ補修水漏れ補修

CPA改善＝売上直結

流入数

エンジニアによるプロダクト改善が売上目標に直接寄与 = エンジニアが成長のエンジン（になりやすい） = エンジニアのビジネス貢献が可視化しやすい = 数値目標を持ったプロダクトチームが　じゃんじゃん改善サイクルを回すとよいパターン = アジャイルとか超導入しやすい座組（結果が売上で出る） (憧れのエンジニア文化がある会社はこのモデル多め)

エンジニアリングへのビジネス期待安定性 or 俊敏性　どちらなのか



















口コミ

SEO

SEM

ETC


if(isBooked){

}

口コミ

SEO

SEM

ETC

純広告枠（営業商品）検索サービス



CVR改善＝次回発注への信頼獲得 = 売上直結ではない

営業

エンジニアの書いたコード上で売上がたたない例

CV数流入数



口コミ

SEO

SEM

ETC


if(isBooked){

}

口コミ

SEO

SEM

ETC





営業


CV数流入数

売上

CVR・QCD

流入数 CV数

マーケプロダクト

営業

パワーバランスこうなりがち売上 > 流入数・CV数 > CVR・QCD (営業)　　　　　(マーケ)　　　　　　　(プロダクト)



口コミ

SEO

SEM

ETC


if(isBooked){

}

口コミ

SEO

SEM

ETC





営業


CV数流入数

売上

CVR・QCD

流入数 CV数


営業

パワーバランスこうなりがち売上 > 流入数・CV数 > CVR・QCD (営業)　　　　　(マーケ)　　　　　　　(プロダクト)

CTO及びそれに準ずる人がいればその人が説明責任を持ち均衡を保ってくれるはずだが・・・

大企業内新規事業だとそうもいかず・・・



口コミ

SEO

SEM

ETC


if(isBooked){

}

口コミ

SEO

SEM

ETC





営業


CV数流入数

売上

CVR・QCD

流入数 CV数


営業

営業が売上に直接的に寄与 = 営業が成長エンジン（売上○○円/人予測可能）エンジニアは顧客単価を上げるための商品開発で寄与＆改善・安定運用（CVR向上・QCD）

顧客単価UP貢献

12



口コミ

SEO

SEM

ETC


if(isBooked){

}

口コミ

SEO

SEM

ETC





営業


CV数流入数

売上

CVR・QCD

流入数 CV数


営業

営業が売上に直接的に寄与 = 営業が成長エンジン（売上○○円/人予測可能）エンジニアは顧客単価を上げるための商品開発で寄与＆改善・安定運用（CVR向上・QCD）

顧客単価UP貢献

ビジネス貢献を説明できず(理解されず)にここだけに極端にフォーカスがあたると・・・・ 12



口コミ

SEO

SEM

ETC


if(isBooked){

}

口コミ

SEO

SEM

ETC





営業


エンジニアのビジネス貢献が可視化しにくい = トラブルだけが目立つようになる = できて当たり前（減点主義）のパラダイム = エンジニアはコスト削減や生産性向上のようなビジネス指標から程遠い目標設定になる = QCDSの制約の雁字搦めになるので、エンジニア側は壁を作りディフェンシブになりだす = 本来、俊敏に仮説検証回したい目的に反して、組織がスローダウンしていく

12

















エンジニアのビジネス貢献を正しく説明できないと本来の目的に反してコスト効率のパラダイムに引力が働くことがある

(ビジネスー開発間の信頼関係・理解等他にも要因あるが）

ビジネス貢献を抜きにした

過剰な QCD評価

放置していると組織としての慣性は、ビジネス部門と開発部門

の社内受発注な関係に向かいやすい

じゃあ、どーすんのか

（本来は信頼関係があればよいが）ビジネス側・エンジニア側が共通の目標を持ち

それぞれの貢献を可視化できるようにする（or お互いの目標も持ちそれに貢献する）

※結果に対して自分のアクションで影響を与える

アジャイルやDevOpsで言われている同じ責任や目標を持ったクロスファンクショナルな

スモールチームと結局は同じこと。

OKRでも概念的なKPIツリーでもなんでも良いですが、そこで、ひとつのやりかたとしてアラインメントマップ

https://martinfowler.com/bliki/AlignmentMap.html

例）パフォーマンス(IT成果)が良くないのにカスタマー継続率(ビジネス成果) は好調。IT成果が実はビジネス成果に影響をあまり与えていない or 与えるレベルまでいっていないと予想できる。

https://martinfowler.com/bliki/AlignmentMap.html

振り返りとしてビジネス、ITそれぞれが別々に成果を評価しマージする。すべてのITの活動がビジネス成果に影響を与えるわけではないが、この結果から議論の機会になる


ビジネスフェーズからエンジニアリングを見る

ビジネスフェーズ ↓

求められるプロダクト品質エンジニア像

充足不充足

満足

不満足

顧客の満足感

物理的な充足度

魅力品質

当たり前品質アーリーアダプターにはここ弱めにするか。とかマネタイズ検証時には

必要だね。とか Minimum Sellable Product

性能品質

魅力品質

性能品質

当たり前品質

不充足でも不満には思わないが、充足されれば満足 <例> ハイレゾ音源（あれば良いが、なくても不満ではない）、曲面液晶など

不充足だと不満、充足されると満足 <例> バッテリーの持ち（稼働時間が長ければ満足、短いと不満）、重量など

不充足だと不満、充足されて当たり前 <例> 通話音声（音が良くて当たり前、聞き取りづらいと不満）

狩野モデル

深い課題を抱えた顧客がいるか

その課題の解決策は妥当か

顧客発見顧客実証顧客開拓組織構築[ニーズ検証] [売って検証] [リーチ検証] [本格拡大]独自な価値提供を出来ているか

顧客は本当に買ってくれるか

コスト構造に無理がないか

独自な価値提供を出来ているか

最適な売り方の検証

最適な価格設定の検証

独自な価値提供を出来ているか

Problem Solution

Fit

Product Market

Fit Scaling

Retention CAC < LTV 最大LTVセグメントの比率

課題解決可能な最小限

売り方最適化 / 売上最大化売る

ビジネスフェーズ

狩野モデル

魅力的品質最低限の性能品質魅力的品質

当たり前品質アップセルに向けた性能品質

魅力的品質当たり前品質

指標値例

検証アクション

検証ポイント

MVP 目標

MVP作って壊す

MVP 品質

最低限の売れる状態

セグメントに応じて売れる状態検証が既存ユーザに影響与えない

ビジネスフェーズからエンジニア像を俯瞰してみる（ユニークなValuePropositionが技術ではない場合の例）

Problem/Solu,onFit Product/MarketFit Scaling

100%

%me

Scale

MySQL

MVP

iOS

iOS

KPI

検証用のMVPを高速に実装

ビジネス文脈を意識した品質担保＆成長貢献

セグメントに応じた性能向上

顧客発見顧客実証顧客開拓


ビジネス仮説検証プロセスから

エンジニアリングを見る

仮説検証プロセス ↓

エンジニアリングによる仮説検証基盤構築

仮説検証基盤要件方法既存のユーザへの影響

を最小化ユーザーを任意の属性でセグメン

トする機能管理コンソールの実装

既存のユーザへの影響を最小化

ユーザーセグメントに対して機能の出し分けを可能にする

事業フェーズが進めば進むほど、既にたくさん使われているプロダクトで仮説検証をすることになるため必

要最低限の影響範囲で仮説検証をする

Feature Flag、A/Bテスト、Private Beta Test、Dark Launch、etc

検証結果が濁らないこと

仮説や施策単位に各種数値を計測出来る機能

(例)CV数が目標の場合、マーケの頑張りなのか、プロダクト改善によるCVR向上なのか切り分けができない

コホート分析

検証方法の改善が出来ること

検証ポイントまでユーザが漏れずに到達できていること

UI上の問題で検証ポイントまでユーザが到達していないのに、検証失敗とする事案がある

ファネル分析

：：：DevOps系プラクティス見れば基本ソレ


予算計画のリズムからエンジニアリングを見る

1年 1年 1年

予算のリズム ↓

開発のリズム（ほんとに？？？？？）

答え持っていないのでここは誰かご教授願いたいです

（課題提起プレゼンwwww）

次年度予算計画次年度予算計画次年度予算計画
















本当は、俊敏性や速度を持ってやりたいのに、結果的に重厚長大な計画駆動型になってしまう場合もある

年次予算計画の圧

本当は、こうしたいのに

エンタープライズの場合、年次の予算計画があり、ベースとなるサイクルタイムは年になる。

1年先の未来の状況を事前に予想して計画しないとならない。そして、それを1年後まで大幅に変更することはない。

計画の実行に固執すると「発見」による変更がきかなくなる1年 1年 1年

新規事業なのに年次計画駆動になるバイアス

予算：目的のために確保する資金の合計（活動に費やせる金額の上限）戦略：実際にやることを定義するもの予算は戦略をどのように実現するべきか計画するのもではない顧客に価値を届けるこのと成否を予測したり評価したりするのもではない。

課題：年次プロセス以外で資金調達する方法がない

課題：年次プロセス以外で資金調達する方法がない →「発見」による軌道修正が不可能 →より多くの予算を確保するために多大な労力をかけて最高のビジネスプランを計画（予想ｗ）しないとならない

事例1：新規事業組織部門としてバジェットは年次固定で持ちつつ、それを部門内で資金調達型で各新規事業へ配分していく。各事業にステージ(調達額上限)を設定。同時に撤退のルールも決め予算の「選択と集中」を行う。

http://www.slideshare.net/i2key/bp-leanstartup#94 19

事例2：前述の新規事業単位での資金調達よりも、細かい現場での機能追加レベルでの資金調達法。 MVP Canvasにより仮説検証の学びに対するコストの説明責任を設ける。（活動基準会計）バジェットの使い方を意味のないキラキラ機能追加ではなく、どのような学びがあるかをベースに議論する。

http://www.slideshare.net/i2key/45-developers-summit-2015-devsumi-devsumib#141 19

一般論脱予算経営 Beyond Budget Management

等いわれていますが、ここらへんの取り組みでうまくいっている事例等ありましたら、ご教授いただきたいです！！！！！誰か！

お願い!!!!

19


提案サービス

¥0クライアント企業従業員クライアント

BtoB 従業員向け SaaS型サービス

営業

time (月)

：：：

受注率

継続率

継続率

BtoBのSaaSモデル

xxx画面 xxx画面 xxx画面 CV画面サービストップ画面

if(isConverted){

}

○○改善 = 受注率向上 □□改善 = 継続率向上　

のキードライバが見えていないコード上なのかリアルなのか？ ?

最適な売り方、最適な価格設定の

検証フェーズ

・営業が売上立てるモデル　　↓ ・商品開発において受注率・継続率の　キードライバーとして見えるものが無い　　↓ ・キードライバーを発見する　仮説検証のトライ回数最大化　　↓ ・仮説検証の速度の最大化　（本番デプロイ回数/日）　　※リリースまでのリードタイム最小化


検証フェーズ

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


検証フェーズ

仮説検証トライ回数最大化仮説検証トライ品質最大化（デプロイ回数/日）

http://i2key.hateblo.jp/entry/2016/12/07/153146

仮説検証トライ回数最大化仮説検証トライ品質最大化（デプロイ回数/日）

プロセス品質向上 = 手戻り防止 = フロー効率あげる

リードタイム削減 =フロー効率あげる

プロセスタイムの削減＝フロー効率あげる

仮説品質向上 = 手戻り防止 = フロー効率あげる計測品質向上 = 手戻り防止 = フロー効率あげる

実装品質向上 = 手戻り防止 = フロー効率あげる

http://i2key.hateblo.jp/entry/2016/12/07/153146

リソース効率

フロー効率

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%

フロー効率（例）機能リリースまでのリードタイムの短さ

リソース効率

フロー効率

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

バックエンドエンジニア

フロントエンジニア

プロダクトオーナー

顧客Feedback

承認レビュー

仕様確認

API開発 API開発

Front開発

デプロイ待ち待ち

フロー効率をあげていく学ぶ（顧客のフィードバックを得る）までのリードタイム

エンジニア (フロント＆バックエンド）

フロントエンジニア

プロダクトオーナー

顧客 Feedback

承認条件

API開発 Front開発デプロイ待ち待ち

待ち

※先に提示された条件をパスすればリリース承認というルールにする等

※フルスタック（）な振る舞いをすることで引き継ぎによる

ムダが減る

※ここにきて手戻りが発生することも

学ぶ(顧客のフィードバックを得る)までのリードタイム

待ち行列理論・100%の利用率の高速道路は、駐車場といっしょ・100%利用率のサーバは？・稼働率100%のチームは？

スループットを最大化ではなくチームに最適化する・処理中のもの量の最小化・処理中のもののサイズを最小化

チームへの負荷を調整・たくさんのこと同時にしない・タスク管理ではなく、チームのペースを管理する

仕事の許容量を制限する・スコープボックスではなくタイムボックス・プッシュ型ではなくプル型でやる

フロー効率を高めるために（顧客へ価値が届くまでのリードタイムを短くする）

マルチタスクやめる

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


たくさんのことを同時に調整しようとするから仕様の調整の「会議」やら「定例」やらがうまれる

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



リリースまでのリードタイム 3wリリースまでのリードタイム 3w


たくさんのことを同時に調整しようとするから仕様の調整の「会議」やら「定例」やらがうまれる

Git Flow ・Release Branchがマルチタスクをうんでいる？・フロー効率あげるのに、可能なら一個流しにしたい

↓ Github Flow

現在移行に向け奮闘中・CD ・デプロイパイプライン・E2E Test整備・Feature Flag

マルチタスクやめる

（例）

スクラム導入におけるビジネス側への説明内容抜粋やりたいことが永久に湧いてくると思うので、得られるビジネス価値によって優先順位付けするメカニズムが必要・プロダクトバックログ運用開始・状況の変化に柔軟に対応するための仕組み（トレードオフ、2週間開発）　・プランニング、スプリント

エンジニアチームの成果・やっていることを可視化・全体の定例で毎週予定されているリリースプランを少し未来分まで提示

色々なステークホルダーがエンジニアリーダーにタスクを投げてくる状況（テックリードがチケット差配屋さんになること）の脱却・ビジネス側と開発側のコミュニケーションチャネルを人ではなく、　プロダクトバックログ＆プランニングという場に変更。

スプリントのエンジニア工数比率のポートフォリオの合意形成をしたい。・各種施策を実施するためのカイゼン枠を確保。

現在のチームのスプリントのポートフォリオ

以下のタイムボックス管理 50% 機能追加 20% カイゼン（この枠で前述の各種カイゼン実施） 15% 既知バグ改修 15% 新規バグ改修 ※打ち合わせや雑務の稼働時間は全部SprintBacklogにつんである上で残りの時間を上記に分配している

カイゼンに20％おいているは大事。（この20％の説明責任を果たし、ビジネス側に合意ををとるための勘所が本日のスライド。）エンジニアのカイゼンのモチベーションを奪ってはいけない。エンジニアの改善のモチベーションは良い方向に持っていこうとする善のエネルギー。それをしょうもない理由でへし折るとチーム全体がダークサイドへ堕ちてしまう。

まだ道半ば

We’re HIRING!!

ともに越境し歩んでくれる同士を募集しています

Engineering

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