エンジニアが成長のエンジンになる日 #devsumi #natsumiC7

エンジニアが成長のエンジンになる日Recruit Holdings R&D Division Business Development Office Kuroda Itsuki @i2key

SPEED for Enterprise

黒田　樹　(@i2key) <= Follow me :-) 前職ではSIerで官公庁系大規模システムのアーキテクト。 Java屋。数多くのデスマを経験。昨年度までは、全世界でシリーズ累計1300万DLのアプリcameranシリーズの開発全体責任者（開発、採用、組織構築、プロセスetc）でした。また、社内外でリーンスタートアップやアジャイルの登壇とかをたまにしています。現在は、今までの経験やノウハウを使い海外のマイナー出資先スタートアップの日本展開支援をしています。

http://99designs.jp

支援先スタートアップ

サービス大ヒット ↓ 増員 ↓ カオス ↓

ギスギス ↓ 鎮火 ↓

やっぱダメ ↓

いいか？リーンにヤレhttp://www.slideshare.net/i2key/45-developers-summit-2015-devsumi-devsumib

総合1位／ベストバリュー賞（満足度1位）／公募賞

ありがとうございました！

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

サービス大ヒット ↓ 増員 ↓ カオス ↓

ギスギス ↓ 鎮火 ↓

やっぱダメ ↓

いいか？リーンにヤレhttp://www.slideshare.net/i2key/45-developers-summit-2015-devsumi-devsumib

総合1位／ベストバリュー賞（満足度1位）／公募賞

ありがとうございました！この取り組みの裏側ビジネススケール期

エンジニアの役割成長に直接的に寄与

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

ビジネスにおけるスピードを生み出す開発

「ビジネスにおけるスピードを生み出す開発」とは不確実性の高い事業ドメインやフェーズにおいて、大きく失敗するリスクを最小化するために、ビジネスアイデアを複数の小さな仮説に分解し、それら一つ一つ検証し実証していくという価値観のもと、この仮説検証の速度をエンジニアリングで最大化すること。そのために、必要なインフラ基盤があり、エンジニア自ら推進することが出来る仕組みがあり、その活動の成果が適正に評価されること。


エンジニアが感じるサービス開発現場のモヤモヤ

プロダクトバックログに起票されるタスクが本当に開発すべきことなのか。やるべき理由はあるのか。

その機能をリリースしたあとの成果は機能毎にわかるのか。結果から学びを得ているのか。

やっていることはサービスの成長に直結しているのか。

そのモヤモヤは実は正しいことが多い

大抵思い込みで盛大に

スベる

出会い系サイトを作る ↓

うまく行かない ↓

動画共有機能は良く使われている ↓

動画共有サイトにピボット

位置情報チェックインアプリを作る ↓


写真共有機能は良く使われている ↓

写真共有サイトにピボット

オンラインゲームを作る ↓


写真共有機能は良く使われている ↓

写真管理共有サービスにピボット

世の中の成功してるサービスの60%以上が、最初のビジネスアイデアを捨てている。市場にだして、初めて分かること多すぎwwwwwwwww

5

なぜ？彼らは死なないですんだのか

5

失敗から学びを得ている

ビジネスアイデア全てを仮説と捉えて、それらを小さく分割して検証すること

効率よく失敗して、効率よく学ぶ考え方

無駄を徹底的に省くこと・思い込みを排除し全てを仮説と捉える・コストに対する学びを最大化する・失敗による損失を最小化する　= 不確実性(リスク)を最小化するプロセス　≠ 成功を保証するプロセス

そのために、効率的(例:小さく/短く/安く)に仮説を検証して学びを得る（ことが多い）

例）写真加工アプリにフィルタ購入機能を作ろう！！やりたいことの実装工数は3人月くらいかかりそうです。

あなたがこのプロダクトのオーナーならどうしますか？

①フィルタ購入機能を3人月かけて実装する　（一切購入されないリスクそのまま） ②フィルタ購入するボタン（ダミー）を用意して、全体のユーザーの10%に表示して確認し、本当に購入ボタンが押された回数を測定してから開発着手の判断をする。工数は2人日。（本当に購入されるのかのみを検証）②のほうが無駄の無い判断してるぽい

例えばこんな感じ

100円で購入

100円で購入

現在開発中です！近日リリース予定です！

＜ポップアップ＞

ユーザー全体の10%にだけ表示されるボタン

今みたいなのをMVPと言ったりしますMinimum Viable Product（検証可能な最小限の製品）。仮説を検証するために必要な最小限の何か。・プロダクト・インタビュースクリプト・説明スライド・ペーパープロトタイピング　and so on…

仮説が検証できれば別に完璧な製品である必要はない

仮説立てる->MVPをつくる->測る->学ぶ

MVP

ビジネスアイデアを仮説として捉えて検証するためのプロセス。仮説検証のためのMVPを Buildしてそれを元にMeasureし、その結果得られたデータから Learnする。

つくる

測る

学ぶ

仮説たてる

保有リスク量

時間引用: http://www.slideshare.net/clevergirl/ux-jackson-2013-oneday-lean-startup-workshop

ウォーターフォール型プロセス

あれ？流行らない。よし、機能追加だ！もっと豪華な

フィルターを売るぞ！

まだまだ機能が足らんぞおおお！マーケットプレイスにすべきだ！！！！

フィルター購入機能をつくるぞ！

3人月

http://www.slideshare.net/clevergirl/ux-jackson-2013-oneday-lean-startup-workshop

時間

仮説検証モデルによるプロセス保有リスク量

2人日

Learn

Build

Build

MeasureMeasure

時間

仮説検証モデルによるプロセス保有リスク量

2人日

全体の10%のみに出すダミー購入ボタン作る

計測した結果、全然クリックされていない

需要ないんだね、あぶなかった・・・（リスクがゼロになる）

①仮説

②何を学ぶのか

③必要なデータは？

④どうやって計測する？

⑤必要なものは？

⑥どう構築するか？

良質な仮説検証を回すには、BMLループをゴールから遡り設計をするのがキモ

Product Backlog ＜開発タスク＞

10個ひらめいた！

Product Owner

10個のエンジニアタスク

従来のタスクあるある

シャワー浴びながら・・トイレに入りながら・・ktkr!!!!

いやいやいや・・・

フィルタを売って売上をあげる！フィルタ購入機能実装

Lean Canvas ＜ビジネス仮説＞

仮説検証 MVPの設計

Product Backlog ＜MVP構築タスク＞

10個の仮説 3個のMVP構築（エンジニアタスク）

10個のMVP設計

7個のGetOutOfBuilding （プロダクトオーナータスク）

※別に開発しなくても仮説検証できる

仮説検証型タスク

エンジニアリング必要

エンジニアリング不要

フィルタが本当に購入されるのか

ダミー x 10%のユーザで

検証検証用フィルタ購入ダミーボタン実装

従来の Product Backlog

仮説検証型の Product Backlog

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

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

検証用フィルタ購入ダミーボタン実装

フィルタ購入機能実装


10

分析計測

リリースA/Bテスト

10データ収集

仮説検証単位（MVP）毎に効果を検証する

検証Aの実装をセグメントAにリリース結果数値をウォッチ

検証Bの実装をセグメントBにリリース結果数値をウォッチ

検証Cの実装をセグメントCにリリース結果数値をウォッチ

やったことの単位に結果を見ること

全部同時にリリースした場合、合計値でユーザー数などを見ていても何が寄与したのかが見えない。

Sprint Backlog

検証Aの実装

検証Bの実装

検証Cの実装

10

検証Bを行っているユーザー

検証Cを行っているユーザー

検証Aを行っているユーザー

このように縦に合計値で見ないほうがよい場合があるこの場合検証Aの効果の影響なのに合計値のみで見ていると判断を謝る

混ぜるな危険

・セグメント毎に対して別々の機能をリリース出来る　セグメントを自由に作成できる　　(例：5%のユーザ集合、○○をした人、1ヶ月使ってない人） Feature Toggle, Feature Flipping

・セグメント毎にデータの計測が出来ること　　コホート分析

・同じセグメントに対して複数のパターンの検証が出来る　　A/Bテスト

仮説検証を効果的に行うためのインフラ要件

※今回説明省略します

※今回説明省略します

プランニング

　　↓ コーディング

　　↓ テスト・コードレビュー

　　↓ ステージングリリース

　　↓ 本番リリース　　↓ 何故かわからないけどサービス全体の利用率が上昇している（学びがないから再現性がない）

開発環境

ステージング環境本番環境

仮説検証を意識しない開発フロー

仮説検証を意識した開発フロー

開発環境

本番環境

プランニング　　↓ コーディング　　↓ テスト・コードレビュー　　↓ 検証単位で非公開で本番リリース　　↓ 検証単位で開示範囲を制限（チームメンバーだけ）　　↓ 検証単位で開示範囲を制限（社員だけ）　　↓ 検証単位で全ユーザーのN%に開示検証単位で特定ユーザセグメントに開示　　↓ 検証単位にコホートで効果分析　　↓ 検証単位の改善（A/Bテスト実施）

　　↓

仮説検証を意識した開発フロー

開発環境

本番環境

プランニング　　↓ コーディング　　↓ テスト・コードレビュー　　↓ 検証単位で非公開で本番リリース　　↓ 検証単位で開示範囲を制限（チームメンバーだけ）　　↓ 検証単位で開示範囲を制限（社員だけ）　　↓ 検証単位で全ユーザーのN%に開示検証単位で特定ユーザセグメントに開示　　↓ 検証単位にコホートで効果分析　　↓ 検証単位の改善（A/Bテスト実施）

　　↓

LEAN STARTUPが語られるときにエンジニアリングサイドについて何故か触れられることが少ない・・

小さく失敗して効率よく学ぶインフラ (一部の方には当たり前かもですが・・）

Java

http://www.ff4j.orgFeature Flipping for Java

https://github.com/togglz/togglzTogglz

https://github.com/tacitknowledge/flip

https://github.com/akomtur/fitchyFitchy

Flip

Python

Ruby

GutterDjango-lean

Chanko

Flipper

https://github.com/disqus/gutter

https://bitbucket.org/akoha/django-lean/wiki/Home

https://www.djangopackages.com/grids/g/feature-flip/その他Django関連

https://cookpad.github.io/chanko/

https://github.com/jnunemaker/flipper

https://github.com/FetLife/rolloutRollout

Permission : ROLE_ADMINPermission : ROLE_USER

Feature Flipping for Java


開発チーム PO Engineer Engineer Engineer Designer

プロダクトチーム PO Engineer Engineer Designer

グロースチーム Engineer Engineer Designer

カメラ機能チームプロダクト担当 PO Engineer Designer

SNS機能チームプロダクト担当 PO Engineer Designer

ユーザ管理チームプロダクト担当 PO Engineer Designer

グロース担当 Engineer Designer



機能追加開発もやるしグロースのための改善もやるけどどうしても改善の優先度が下がりがち

・・・

成長率を上げるために目標別に専門チームに分離・新規機能追加をやるプロダクトチーム・数値目標を元に既存機能の改善するグロースチームコードベースが大きくなりすぎ改善サイクルとリリースサイクルの不協和音

上記に追加して、サービス単位でチーム分割（アーキテクチャも分割）

開発チーム PO Engineer Designer

サービス開発全般

エンジニア体制の推移例（あくまで例）

立ち上げ (P/S Fit目指す)

ユーザー定着してきた (P/M Fit目指す)

グロース頑張る (Scale目指す)











・・・









ガンガンいこうぜ！！！！











・・・









機能追加をやりつつ、既存機能のグロース・改善もやる同じプロダクトバックログで管理 Sprintのタスクウェイトを

新規機能30%、既存改善30%のように定義しているものの・・・











・・・









既存の成長を維持しつつ、新規にもスケールさせるという目標を持ち始め、明確に目標とチームをリンクさせ分離しはじめる

(コードベースが重厚長大化の兆し付き）











・・・









エンジニア体制が大きくなり、一度のリリースで大量のソースコードがリリース。

CIの時間は増大し、ソース間の依存性は高まり、ひとたびテストで落ちると・・・。

リリース頻度＝仮説検証トライ回数と考えると、 BMLループのスループット低下。

そのため、リリースをシンプルに、依存性を最小化。

リソースと権限とコミットを同じ場所におくために、リリース単位(サービス単位)=ビジネスKPI=仮説検証単位(大

仮設)=チーム単位をリンクさせる。 ※この最終的に出来上がった何かが、

結果的にマイクロサービスアーキテクチャ？？(自信ないw)














・・・





グロース改善

機能開発

機能開発

機能開発

機能開発

グロース改善

グロース改善















・・・





グロース改善

機能開発

機能開発

機能開発

機能開発

グロース改善

グロース改善



機能開発グロース改善グロースチーム Engineer Engineer Designer

仕様の検討 ↓ 設計 ↓ 実装 ↓ テスト ↓ リリース

仮説構築 ↓ 検証の設計 ↓ MVPの構築 ↓ 検証 ↓ データ取得 ↓ 結果から学ぶ

各チームのエンジニアのフォーカス

MVP実装品質 MVPリリース頻度デプロイ回数/日

数値目標継続率離脱率コンバージョン率：

要件/仕様は決まっている結果を出せば自由

目標

制約


15

検証を設計する（実証条件/実証方法/etc）

効果を計測する

KPI（数値目標）を設定する

リリースする

ユーザがコンバージョンする

仮説をたてる

仕様にする

設計する

ユーザーに届く

ユーザーが使う

ユーザーが気づく

KPI（数値目標）達成

指標：ベロシティ/デプロイ回数/性能値/品質/コスト/etc

エンジニアのコミットと目標

データから学ぶ（仮説を修正する　　打ち手を変える）

エンジニアが直接結果をコントロール出来る範囲（コードのみに対峙してる）

エンジニアが直接結果をコントロール出来ない範囲

（ユーザーの判断という不確実性が介在）テストする

実装する

指標：MAU/継続率/○○率/売上/etc

15




リリースする


仮説をたてる

仕様にする

設計する











実装する

スペシャリスト（深い専門性）深める

ビジネスへ染み出すエンジニア広げる

どの円にフォーカスしてコミットするかはエンジニアの生き方・価値観そのもの

強制をするものではない

cameranでの事例




リリースする


仮説をたてる

仕様にする

設計する











実装する


@kasajei

@kusudart

継続率コミット

MAUコミットその代わり、勝手にやらしてもらうよ




リリースする


仮説をたてる

仕様にする

設計する










実装する

コミット：継続率○○%UPファンはアーティストの投稿を必ずチェックするのではないか？今はそれに気付いていないだけでは

ラルクアンシェルのHydeの投稿を彼の投稿を「like」したことあるセグメントに通知してあげることで、リテンションするか計測する

Hydeの投稿タイミングで過去にlikeしたセグメントに対して、プッシュ通知する機能を実装

ユーザーの継続率があがる

仮説は正しかった、他のセグメントにもスケールできるか検証する

SQLで作ったセグメントに対して、指定したトリガで自動でプッシュするようにする

継続率：○○%達成cameranでの事例

指標：MAU/継続率/○○率/売上/etc

VAMPSにいいね！したけど1ヶ月来訪していないユーザへ VAMPS投稿タイミングで通知

TERUにいいね！したけど1ヶ月来訪していないユーザへ TERU投稿タイミングで通知




リリースする


仮説をたてる

仕様にする

設計する





指標：デプロイ回数/性能値/品質/コスト/etc






実装する

継続率：○○%ファンはアーティストの投稿を必ずチェックするのではないか？今はそれに気付いていないだけでは

ラルクアンシェルのHydeの投稿を彼の投稿を「like」したことあるセグメントに通知してあげることで、リテンションするか計測する

Hydeの投稿タイミングで過去にlikeしたセグメントに対して、プッシュ通知する機能を実装

ユーザーの継続率があがる

仮説は正しかった、他のセグメントにもスケールできるか検証する

SQLで作ったセグメントに対して、指定したトリガで自動でプッシュするようにする

継続率：○○%達成

エンジニアがKPIにコミットし、自分の責任の範囲内で

勝手にサービスをHackし成果を出す

目標達成




リリースする


仮説をたてる

仕様にする

設計する











実装する


@kasajei

@kusudart






リリースする


仮説をたてる

仕様にする

設計する











実装する


@kasajei

@kusudart



成長のエンジン


Hackers will be Engines of

Growth!!

ご静聴ありがとうございました

Engineering

エンジニアが成長のエンジンになる日 #devsumi #natsumiC7