SlideShare a Scribd company logo
1 of 69
Download to read offline
エンジニアが
成長のエンジン
になる日
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
総合1位/ベストバリュー賞(満足度1位)/公募賞
ありがとうございました!この取り組みの裏側
ビジネススケール期
エンジニアの役割
成長に直接的に寄与
ビジネスにおける
スピードを生み出す開発
「ビジネスにおけるスピードを生み出す開発」とは
不確実性の高い事業ドメインやフェーズにおいて、
大きく失敗するリスクを最小化するために、ビジネス
アイデアを複数の小さな仮説に分解し、それら一つ一
つ検証し実証していくという価値観のもと、この
仮説検証の速度をエンジニアリングで最大化
すること。そのために、必要なインフラ基盤があ
り、エンジニア自ら推進することが出来る仕組み
があり、その活動の成果が適正に評価されること。
「ビジネスにおけるスピードを生み出す開発」とは
不確実性の高い事業ドメインやフェーズにおいて、
大きく失敗するリスクを最小化するために、ビジネス
アイデアを複数の小さな仮説に分解し、それら一つ一
つ検証し実証していくという価値観のもと、この
仮説検証の速度をエンジニアリングで最大化
すること。そのために、必要なインフラ基盤があ
り、エンジニア自ら推進することが出来る仕組み
があり、その活動の成果が適正に評価されること。
エンジニアが感じる
サービス開発現場のモヤモヤ
プロダクトバックログに起票されるタスクが本当に開発す
べきことなのか。やるべき理由はあるのか。
その機能をリリースしたあとの成果は機能毎にわかるのか。
結果から学びを得ているのか。
やっていることはサービスの成長に直結しているのか。
そのモヤモヤは実は正しいことが多い
大抵思い込みで盛大に
スベる
出会い系サイトを作る
↓
うまく行かない
↓
動画共有機能は良く使われている
↓
動画共有サイトにピボット
位置情報チェックインアプリを作る
↓
うまく行かない
↓
写真共有機能は良く使われている
↓
写真共有サイトにピボット
オンラインゲームを作る
↓
うまく行かない
↓
写真共有機能は良く使われている
↓
写真管理共有サービスにピボット
世の中の成功してるサービス
の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人月
時間
仮説検証モデルによるプロセス
保有リスク量
2人日
Learn
Build
Build
Measure
Measure
時間
仮説検証モデルによるプロセス
保有リスク量
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.org
Feature Flipping for Java
https://github.com/togglz/togglz
Togglz
https://github.com/tacitknowledge/flip
https://github.com/akomtur/fitchy
Fitchy
Flip
Python
Ruby
Gutter
Django-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/rollout
Rollout
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
グロース担当
Engineer
Designer
グロース担当
Engineer
Designer
機能追加開発もやるし
グロースのための改善もやるけど
どうしても改善の優先度が下がりがち
・・・
成長率を上げるために目標別に専門チームに分離
・新規機能追加をやるプロダクトチーム
・数値目標を元に既存機能の改善するグロースチーム
コードベースが大きくなりすぎ
改善サイクルとリリースサイクルの不協和音
上記に追加して、
サービス単位でチーム分割
(アーキテクチャも分割)
開発チーム
PO
Engineer
Designer
サービス開発全般
エンジニア体制の推移例(あくまで例)
立ち上げ
(P/S Fit目指す)
ユーザー定着してきた
(P/M Fit目指す)
グロース頑張る
(Scale目指す)
開発チーム
PO
Engineer
Engineer
Engineer
Designer
プロダクトチーム
PO
Engineer
Engineer
Designer
グロースチーム
Engineer
Engineer
Designer
カメラ機能チーム
プロダクト担当
PO
Engineer
Designer
SNS機能チーム
プロダクト担当
PO
Engineer
Designer
ユーザ管理チーム
プロダクト担当
PO
Engineer
Designer
グロース担当
Engineer
Designer
グロース担当
Engineer
Designer
グロース担当
Engineer
Designer
機能追加開発もやるし
グロースのための改善もやるけど
どうしても改善の優先度が下がりがち
・・・
成長率を上げるために目標別に専門チームに分離
・新規機能追加をやるプロダクトチーム
・数値目標を元に既存機能の改善するグロースチーム
コードベースが大きくなりすぎ
改善サイクルとリリースサイクルの不協和音
上記に追加して、
サービス単位でチーム分割
(アーキテクチャも分割)
開発チーム
PO
Engineer
Designer
サービス開発全般
エンジニア体制の推移例(あくまで例)
立ち上げ
(P/S Fit目指す)
ユーザー定着してきた
(P/M Fit目指す)
グロース頑張る
(Scale目指す)
ガンガンいこうぜ!!!!
開発チーム
PO
Engineer
Engineer
Engineer
Designer
プロダクトチーム
PO
Engineer
Engineer
Designer
グロースチーム
Engineer
Engineer
Designer
カメラ機能チーム
プロダクト担当
PO
Engineer
Designer
SNS機能チーム
プロダクト担当
PO
Engineer
Designer
ユーザ管理チーム
プロダクト担当
PO
Engineer
Designer
グロース担当
Engineer
Designer
グロース担当
Engineer
Designer
グロース担当
Engineer
Designer
機能追加開発もやるし
グロースのための改善もやるけど
どうしても改善の優先度が下がりがち
・・・
成長率を上げるために目標別に専門チームに分離
・新規機能追加をやるプロダクトチーム
・数値目標を元に既存機能の改善するグロースチーム
コードベースが大きくなりすぎ
改善サイクルとリリースサイクルの不協和音
上記に追加して、
サービス単位でチーム分割
(アーキテクチャも分割)
開発チーム
PO
Engineer
Designer
サービス開発全般
エンジニア体制の推移例(あくまで例)
立ち上げ
(P/S Fit目指す)
ユーザー定着してきた
(P/M Fit目指す)
グロース頑張る
(Scale目指す)
機能追加をやりつつ、
既存機能のグロース・改善もやる
同じプロダクトバックログで管理
Sprintのタスクウェイトを
新規機能30%、既存改善30%のように
定義しているものの・・・
開発チーム
PO
Engineer
Engineer
Engineer
Designer
プロダクトチーム
PO
Engineer
Engineer
Designer
グロースチーム
Engineer
Engineer
Designer
カメラ機能チーム
プロダクト担当
PO
Engineer
Designer
SNS機能チーム
プロダクト担当
PO
Engineer
Designer
ユーザ管理チーム
プロダクト担当
PO
Engineer
Designer
グロース担当
Engineer
Designer
グロース担当
Engineer
Designer
グロース担当
Engineer
Designer
機能追加開発もやるし
グロースのための改善もやるけど
どうしても改善の優先度が下がりがち
・・・
成長率を上げるために目標別に専門チームに分離
・新規機能追加をやるプロダクトチーム
・数値目標を元に既存機能の改善するグロースチーム
コードベースが大きくなりすぎ
改善サイクルとリリースサイクルの不協和音
上記に追加して、
サービス単位でチーム分割
(アーキテクチャも分割)
開発チーム
PO
Engineer
Designer
サービス開発全般
エンジニア体制の推移例(あくまで例)
立ち上げ
(P/S Fit目指す)
ユーザー定着してきた
(P/M Fit目指す)
グロース頑張る
(Scale目指す)
既存の成長を維持しつつ、
新規にもスケールさせるという
目標を持ち始め、明確に目標と
チームをリンクさせ分離しはじめる
(コードベースが重厚長大化の兆し付き)
開発チーム
PO
Engineer
Engineer
Engineer
Designer
プロダクトチーム
PO
Engineer
Engineer
Designer
グロースチーム
Engineer
Engineer
Designer
カメラ機能チーム
プロダクト担当
PO
Engineer
Designer
SNS機能チーム
プロダクト担当
PO
Engineer
Designer
ユーザ管理チーム
プロダクト担当
PO
Engineer
Designer
グロース担当
Engineer
Designer
グロース担当
Engineer
Designer
グロース担当
Engineer
Designer
機能追加開発もやるし
グロースのための改善もやるけど
どうしても改善の優先度が下がりがち
・・・
成長率を上げるために目標別に専門チームに分離
・新規機能追加をやるプロダクトチーム
・数値目標を元に既存機能の改善するグロースチーム
コードベースが大きくなりすぎ
改善サイクルとリリースサイクルの不協和音
上記に追加して、
サービス単位でチーム分割
(アーキテクチャも分割)
開発チーム
PO
Engineer
Designer
サービス開発全般
エンジニア体制の推移例(あくまで例)
立ち上げ
(P/S Fit目指す)
ユーザー定着してきた
(P/M Fit目指す)
グロース頑張る
(Scale目指す)
エンジニア体制が大きくなり、
一度のリリースで大量のソースコードがリリース。
CIの時間は増大し、ソース間の依存性は高まり、ひとたび
テストで落ちると・・・。
リリース頻度=仮説検証トライ回数と考えると、
BMLループのスループット低下。
そのため、リリースをシンプルに、依存性を最小化。
リソースと権限とコミットを同じ場所におくために、
リリース単位(サービス単位)=ビジネスKPI=仮説検証単位(大
仮設)=チーム単位をリンクさせる。
※この最終的に出来上がった何かが、
結果的にマイクロサービスアーキテクチャ??(自信ないw)
機能追加開発もやるし
グロースのための改善もやるけど
どうしても改善の優先度が下がりがち
成長率を上げるために目標別に専門チームに分離
・新規機能追加をやるプロダクトチーム
・数値目標を元に既存機能の改善するグロースチーム
コードベースが大きくなりすぎ
改善サイクルとリリースサイクルの不協和音
上記に追加して、
サービス単位でチーム分割
(アーキテクチャも分割)
サービス開発全般
開発チーム
PO
Engineer
Engineer
Engineer
Designer
プロダクトチーム
PO
Engineer
Engineer
Designer
グロースチーム
Engineer
Engineer
Designer
カメラ機能チーム
プロダクト担当
PO
Engineer
Designer
SNS機能チーム
プロダクト担当
PO
Engineer
Designer
ユーザ管理チーム
プロダクト担当
PO
Engineer
Designer
グロース担当
Engineer
Designer
グロース担当
Engineer
Designer
グロース担当
Engineer
Designer
・・・
開発チーム
PO
Engineer
Designer
立ち上げ
(P/S Fit目指す)
ユーザー定着してきた
(P/M Fit目指す)
グロース頑張る
(Scale目指す)
グロース改善
機能開発
機能開発
機能開発
機能開発
グロース改善
グロース改善
エンジニア体制の推移例(あくまで例)
機能追加開発もやるし
グロースのための改善もやるけど
どうしても改善の優先度が下がりがち
成長率を上げるために目標別に専門チームに分離
・新規機能追加をやるプロダクトチーム
・数値目標を元に既存機能の改善するグロースチーム
コードベースが大きくなりすぎ
改善サイクルとリリースサイクルの不協和音
上記に追加して、
サービス単位でチーム分割
(アーキテクチャも分割)
サービス開発全般
開発チーム
PO
Engineer
Engineer
Engineer
Designer
プロダクトチーム
PO
Engineer
Engineer
Designer
グロースチーム
Engineer
Engineer
Designer
カメラ機能チーム
プロダクト担当
PO
Engineer
Designer
SNS機能チーム
プロダクト担当
PO
Engineer
Designer
ユーザ管理チーム
プロダクト担当
PO
Engineer
Designer
グロース担当
Engineer
Designer
グロース担当
Engineer
Designer
グロース担当
Engineer
Designer
・・・
開発チーム
PO
Engineer
Designer
立ち上げ
(P/S Fit目指す)
ユーザー定着してきた
(P/M Fit目指す)
グロース頑張る
(Scale目指す)
グロース改善
機能開発
機能開発
機能開発
機能開発
グロース改善
グロース改善
エンジニア体制の推移例(あくまで例)
プロダクトチーム
PO
Engineer
Engineer
Designer
機能開発 グロース改善
グロースチーム
Engineer
Engineer
Designer
仕様の検討
↓
設計
↓
実装
↓
テスト
↓
リリース
仮説構築
↓
検証の設計
↓
MVPの構築
↓
検証
↓
データ取得
↓
結果から学ぶ
各チームのエンジニアのフォーカス
MVP実装品質
MVPリリース頻度
デプロイ回数/日
数値目標
継続率
離脱率
コンバージョン率
:
要件/仕様は決まっている 結果を出せば自由
目標
制約
「ビジネスにおけるスピードを生み出す開発」とは
不確実性の高い事業ドメインやフェーズにおいて、
大きく失敗するリスクを最小化するために、ビジネス
アイデアを複数の小さな仮説に分解し、それら一つ一
つ検証し実証していくという価値観のもと、この
仮説検証の速度をエンジニアリングで最大化
すること。そのために、必要なインフラ基盤があ
り、エンジニア自ら推進することが出来る仕組み
があり、その活動の成果が適正に評価されること。
15
検証を設計する
(実証条件/実証方法/etc)
効果を計測する
KPI(数値目標)を設定する
リリースする
ユーザがコンバージョンする
仮説をたてる
仕様にする
設計する
ユーザーに届く
ユーザーが使う
ユーザーが気づく
KPI(数値目標)達成
指標:ベロシティ/デプロイ回数/性能値/品質/コスト/etc
エンジニアのコミットと目標
データから学ぶ
(仮説を修正する
  打ち手を変える)
エンジニアが直接結果を
コントロール出来る範囲
(コードのみに対峙してる)
エンジニアが直接結果を
コントロール出来ない範囲
(ユーザーの判断という不確実性が介在)
テストする
実装する
指標:MAU/継続率/○○率/売上/etc
15
検証を設計する
(実証条件/実証方法/etc)
効果を計測する
KPI(数値目標)を設定する
リリースする
ユーザがコンバージョンする
仮説をたてる
仕様にする
設計する
ユーザーに届く
ユーザーが使う
ユーザーが気づく
KPI(数値目標)達成
指標:ベロシティ/デプロイ回数/性能値/品質/コスト/etc
エンジニアのコミットと目標
データから学ぶ
(仮説を修正する
  打ち手を変える)
エンジニアが直接結果を
コントロール出来る範囲
(コードのみに対峙してる)
エンジニアが直接結果を
コントロール出来ない範囲
(ユーザーの判断という不確実性が介在)
テストする
実装する
スペシャリスト
(深い専門性)
深める
ビジネスへ染み出す
エンジニア
広げる
どの円にフォーカスしてコミットするかは
エンジニアの生き方・価値観そのもの
強制をするものではない
cameranでの事例
検証を設計する
(実証条件/実証方法/etc)
効果を計測する
KPI(数値目標)を設定する
リリースする
ユーザがコンバージョンする
仮説をたてる
仕様にする
設計する
ユーザーに届く
ユーザーが使う
ユーザーが気づく
KPI(数値目標)達成
指標:ベロシティ/デプロイ回数/性能値/品質/コスト/etc
エンジニアのコミットと目標
データから学ぶ
(仮説を修正する
  打ち手を変える)
エンジニアが直接結果を
コントロール出来る範囲
(コードのみに対峙してる)
エンジニアが直接結果を
コントロール出来ない範囲
(ユーザーの判断という不確実性が介在)
テストする
実装する
ビジネスへ染み出す
エンジニア
広げる
@kasajei
@kusudart
継続率コミット
MAUコミット
その代わり、
勝手にやらしてもらうよ
検証を設計する
(実証条件/実証方法/etc)
効果を計測する
KPI(数値目標)を設定する
リリースする
ユーザがコンバージョンする
仮説をたてる
仕様にする
設計する
ユーザーに届く
ユーザーが使う
ユーザーが気づく
KPI(数値目標)達成
指標:ベロシティ/デプロイ回数/性能値/品質/コスト/etc
データから学ぶ
(仮説を修正する
  打ち手を変える)
エンジニアが直接結果を
コントロール出来る範囲
(コードのみに対峙してる)
エンジニアが直接結果を
コントロール出来ない範囲
(ユーザーの判断という不確実性が介在)
テストする
実装する
コミット:継続率○○%UP
ファンはアーティストの投稿を必ず
チェックするのではないか?
今はそれに気付いていないだけでは
ラルクアンシェルのHydeの投稿を
彼の投稿を「like」したことあるセ
グメントに通知してあげることで、
リテンションするか計測する
Hydeの投稿タイミングで
過去にlikeしたセグメントに対し
て、プッシュ通知する機能を実装
ユーザーの継続率があがる
仮説は正しかった、他のセ
グメントにもスケールでき
るか検証する
SQLで作ったセグメントに対して、
指定したトリガで自動でプッシュす
るようにする
継続率:○○%達成
cameranでの事例
指標:MAU/継続率/○○率/売上/etc
VAMPSにいいね!したけど1ヶ月来訪していないユーザへ
VAMPS投稿タイミングで通知
TERUにいいね!したけど1ヶ月来訪していないユーザへ
TERU投稿タイミングで通知
検証を設計する
(実証条件/実証方法/etc)
効果を計測する
KPI(数値目標)を設定する
リリースする
ユーザがコンバージョンする
仮説をたてる
仕様にする
設計する
ユーザーに届く
ユーザーが使う
ユーザーが気づく
KPI(数値目標)達成
指標:デプロイ回数/性能値/品質/コスト/etc
エンジニアのコミットと目標
データから学ぶ
(仮説を修正する
  打ち手を変える)
エンジニアが直接結果を
コントロール出来る範囲
(コードのみに対峙してる)
エンジニアが直接結果を
コントロール出来ない範囲
(ユーザーの判断という不確実性が介在)
テストする
実装する
継続率:○○%
ファンはアーティストの投稿を必ず
チェックするのではないか?
今はそれに気付いていないだけでは
ラルクアンシェルのHydeの投稿を
彼の投稿を「like」したことあるセ
グメントに通知してあげることで、
リテンションするか計測する
Hydeの投稿タイミングで
過去にlikeしたセグメントに対し
て、プッシュ通知する機能を実装
ユーザーの継続率があがる
仮説は正しかった、他のセ
グメントにもスケールでき
るか検証する
SQLで作ったセグメントに対して、
指定したトリガで自動でプッシュす
るようにする
継続率:○○%達成
エンジニアがKPIにコミットし、
自分の責任の範囲内で
勝手にサービスをHackし成果を出す
目標達成
検証を設計する
(実証条件/実証方法/etc)
効果を計測する
KPI(数値目標)を設定する
リリースする
ユーザがコンバージョンする
仮説をたてる
仕様にする
設計する
ユーザーに届く
ユーザーが使う
ユーザーが気づく
KPI(数値目標)達成
指標:ベロシティ/デプロイ回数/性能値/品質/コスト/etc
エンジニアのコミットと目標
データから学ぶ
(仮説を修正する
  打ち手を変える)
エンジニアが直接結果を
コントロール出来る範囲
(コードのみに対峙してる)
エンジニアが直接結果を
コントロール出来ない範囲
(ユーザーの判断という不確実性が介在)
テストする
実装する
ビジネスへ染み出す
エンジニア
広げる
@kasajei
@kusudart
継続率コミット
MAUコミット
その代わり、
勝手にやらしてもらうよ
検証を設計する
(実証条件/実証方法/etc)
効果を計測する
KPI(数値目標)を設定する
リリースする
ユーザがコンバージョンする
仮説をたてる
仕様にする
設計する
ユーザーに届く
ユーザーが使う
ユーザーが気づく
KPI(数値目標)達成
指標:ベロシティ/デプロイ回数/性能値/品質/コスト/etc
エンジニアのコミットと目標
データから学ぶ
(仮説を修正する
  打ち手を変える)
エンジニアが直接結果を
コントロール出来る範囲
(コードのみに対峙してる)
エンジニアが直接結果を
コントロール出来ない範囲
(ユーザーの判断という不確実性が介在)
テストする
実装する
ビジネスへ染み出す
エンジニア
広げる
@kasajei
@kusudart
継続率コミット
MAUコミット
その代わり、
勝手にやらしてもらうよ
成長のエンジン
「ビジネスにおけるスピードを生み出す開発」とは
不確実性の高い事業ドメインやフェーズにおいて、
大きく失敗するリスクを最小化するために、ビジネス
アイデアを複数の小さな仮説に分解し、それら一つ一
つ検証し実証していくという価値観のもと、この
仮説検証の速度をエンジニアリングで最大化
すること。そのために、必要なインフラ基盤があ
り、エンジニア自ら推進することが出来る仕組み
があり、その活動の成果が適正に評価されること。
Hackers
will be
Engines
of
Growth!!
ご静聴ありがとうございました

More Related Content

What's hot

リーン開発の本質 公開用
リーン開発の本質 公開用リーン開発の本質 公開用
リーン開発の本質 公開用ESM SEC
 
心理的安全性を 0から80ぐらいに上げた話
心理的安全性を 0から80ぐらいに上げた話心理的安全性を 0から80ぐらいに上げた話
心理的安全性を 0から80ぐらいに上げた話Yusuke Hisatsu
 
LEANSTARTUPアンチパターン #devlove #leanstartup
LEANSTARTUPアンチパターン #devlove #leanstartupLEANSTARTUPアンチパターン #devlove #leanstartup
LEANSTARTUPアンチパターン #devlove #leanstartupItsuki Kuroda
 
リーンスタートアップと顧客開発とアジャイル開発を一気通貫するッ #devlove #devkan
リーンスタートアップと顧客開発とアジャイル開発を一気通貫するッ #devlove #devkanリーンスタートアップと顧客開発とアジャイル開発を一気通貫するッ #devlove #devkan
リーンスタートアップと顧客開発とアジャイル開発を一気通貫するッ #devlove #devkanItsuki Kuroda
 
エンジニアの個人ブランディングと技術組織
エンジニアの個人ブランディングと技術組織エンジニアの個人ブランディングと技術組織
エンジニアの個人ブランディングと技術組織Takafumi ONAKA
 
Product ManagerとProduct Ownerの役割の違いについて
Product ManagerとProduct Ownerの役割の違いについてProduct ManagerとProduct Ownerの役割の違いについて
Product ManagerとProduct Ownerの役割の違いについてNoritaka Shinohara
 
オーバーエンジニアリングって何? #devsumi #devsumiA
オーバーエンジニアリングって何? #devsumi #devsumiAオーバーエンジニアリングって何? #devsumi #devsumiA
オーバーエンジニアリングって何? #devsumi #devsumiAOre Product
 
結果的に組織がAgileな状態であること #agile #scrum #leanstartup
結果的に組織がAgileな状態であること #agile #scrum #leanstartup結果的に組織がAgileな状態であること #agile #scrum #leanstartup
結果的に組織がAgileな状態であること #agile #scrum #leanstartupItsuki Kuroda
 
フロー効率性とリソース効率性、再入門 #devlove #devkan
フロー効率性とリソース効率性、再入門 #devlove #devkanフロー効率性とリソース効率性、再入門 #devlove #devkan
フロー効率性とリソース効率性、再入門 #devlove #devkanItsuki Kuroda
 
開発速度が速い #とは(LayerX社内資料)
開発速度が速い #とは(LayerX社内資料)開発速度が速い #とは(LayerX社内資料)
開発速度が速い #とは(LayerX社内資料)mosa siru
 
経営のアジリティを支えるDevOpsと組織
経営のアジリティを支えるDevOpsと組織経営のアジリティを支えるDevOpsと組織
経営のアジリティを支えるDevOpsと組織Recruit Technologies
 
人は1ヶ月でエンジニアになれるのか
人は1ヶ月でエンジニアになれるのか人は1ヶ月でエンジニアになれるのか
人は1ヶ月でエンジニアになれるのかYamaura Kiyoto
 
Leanstartupをリーンにヤル #リーンスタートアップ
Leanstartupをリーンにヤル #リーンスタートアップLeanstartupをリーンにヤル #リーンスタートアップ
Leanstartupをリーンにヤル #リーンスタートアップItsuki Kuroda
 
データプロダクト開発を成功に導くには
データプロダクト開発を成功に導くにはデータプロダクト開発を成功に導くには
データプロダクト開発を成功に導くにはRecruit Lifestyle Co., Ltd.
 
サービスブループリントによるシステム設計手法の紹介 - XP祭り2022
サービスブループリントによるシステム設計手法の紹介 - XP祭り2022サービスブループリントによるシステム設計手法の紹介 - XP祭り2022
サービスブループリントによるシステム設計手法の紹介 - XP祭り2022Yusuke Suzuki
 
ゼロからはじめるプロダクトマネージャー生活
ゼロからはじめるプロダクトマネージャー生活ゼロからはじめるプロダクトマネージャー生活
ゼロからはじめるプロダクトマネージャー生活Takaaki Umada
 
「のどが渇いた」というユーザーに何を出す? ユーザーの「欲しい」に惑わされない、本当のインサイトを見つけるUXデザイン・UXリサーチ
「のどが渇いた」というユーザーに何を出す? ユーザーの「欲しい」に惑わされない、本当のインサイトを見つけるUXデザイン・UXリサーチ「のどが渇いた」というユーザーに何を出す? ユーザーの「欲しい」に惑わされない、本当のインサイトを見つけるUXデザイン・UXリサーチ
「のどが渇いた」というユーザーに何を出す? ユーザーの「欲しい」に惑わされない、本当のインサイトを見つけるUXデザイン・UXリサーチYoshiki Hayama
 
図解で学ぶ「Lean UX」
図解で学ぶ「Lean UX」図解で学ぶ「Lean UX」
図解で学ぶ「Lean UX」Katsuhito Okada
 
5分で出来る!イケてるconfluenceページ
5分で出来る!イケてるconfluenceページ5分で出来る!イケてるconfluenceページ
5分で出来る!イケてるconfluenceページCLARA ONLINE, Inc.
 

What's hot (20)

リーン開発の本質 公開用
リーン開発の本質 公開用リーン開発の本質 公開用
リーン開発の本質 公開用
 
心理的安全性を 0から80ぐらいに上げた話
心理的安全性を 0から80ぐらいに上げた話心理的安全性を 0から80ぐらいに上げた話
心理的安全性を 0から80ぐらいに上げた話
 
LEANSTARTUPアンチパターン #devlove #leanstartup
LEANSTARTUPアンチパターン #devlove #leanstartupLEANSTARTUPアンチパターン #devlove #leanstartup
LEANSTARTUPアンチパターン #devlove #leanstartup
 
リーンスタートアップと顧客開発とアジャイル開発を一気通貫するッ #devlove #devkan
リーンスタートアップと顧客開発とアジャイル開発を一気通貫するッ #devlove #devkanリーンスタートアップと顧客開発とアジャイル開発を一気通貫するッ #devlove #devkan
リーンスタートアップと顧客開発とアジャイル開発を一気通貫するッ #devlove #devkan
 
エンジニアの個人ブランディングと技術組織
エンジニアの個人ブランディングと技術組織エンジニアの個人ブランディングと技術組織
エンジニアの個人ブランディングと技術組織
 
Product ManagerとProduct Ownerの役割の違いについて
Product ManagerとProduct Ownerの役割の違いについてProduct ManagerとProduct Ownerの役割の違いについて
Product ManagerとProduct Ownerの役割の違いについて
 
オーバーエンジニアリングって何? #devsumi #devsumiA
オーバーエンジニアリングって何? #devsumi #devsumiAオーバーエンジニアリングって何? #devsumi #devsumiA
オーバーエンジニアリングって何? #devsumi #devsumiA
 
結果的に組織がAgileな状態であること #agile #scrum #leanstartup
結果的に組織がAgileな状態であること #agile #scrum #leanstartup結果的に組織がAgileな状態であること #agile #scrum #leanstartup
結果的に組織がAgileな状態であること #agile #scrum #leanstartup
 
フロー効率性とリソース効率性、再入門 #devlove #devkan
フロー効率性とリソース効率性、再入門 #devlove #devkanフロー効率性とリソース効率性、再入門 #devlove #devkan
フロー効率性とリソース効率性、再入門 #devlove #devkan
 
開発速度が速い #とは(LayerX社内資料)
開発速度が速い #とは(LayerX社内資料)開発速度が速い #とは(LayerX社内資料)
開発速度が速い #とは(LayerX社内資料)
 
経営のアジリティを支えるDevOpsと組織
経営のアジリティを支えるDevOpsと組織経営のアジリティを支えるDevOpsと組織
経営のアジリティを支えるDevOpsと組織
 
人は1ヶ月でエンジニアになれるのか
人は1ヶ月でエンジニアになれるのか人は1ヶ月でエンジニアになれるのか
人は1ヶ月でエンジニアになれるのか
 
Leanstartupをリーンにヤル #リーンスタートアップ
Leanstartupをリーンにヤル #リーンスタートアップLeanstartupをリーンにヤル #リーンスタートアップ
Leanstartupをリーンにヤル #リーンスタートアップ
 
データプロダクト開発を成功に導くには
データプロダクト開発を成功に導くにはデータプロダクト開発を成功に導くには
データプロダクト開発を成功に導くには
 
サービスブループリントによるシステム設計手法の紹介 - XP祭り2022
サービスブループリントによるシステム設計手法の紹介 - XP祭り2022サービスブループリントによるシステム設計手法の紹介 - XP祭り2022
サービスブループリントによるシステム設計手法の紹介 - XP祭り2022
 
ゼロからはじめるプロダクトマネージャー生活
ゼロからはじめるプロダクトマネージャー生活ゼロからはじめるプロダクトマネージャー生活
ゼロからはじめるプロダクトマネージャー生活
 
「のどが渇いた」というユーザーに何を出す? ユーザーの「欲しい」に惑わされない、本当のインサイトを見つけるUXデザイン・UXリサーチ
「のどが渇いた」というユーザーに何を出す? ユーザーの「欲しい」に惑わされない、本当のインサイトを見つけるUXデザイン・UXリサーチ「のどが渇いた」というユーザーに何を出す? ユーザーの「欲しい」に惑わされない、本当のインサイトを見つけるUXデザイン・UXリサーチ
「のどが渇いた」というユーザーに何を出す? ユーザーの「欲しい」に惑わされない、本当のインサイトを見つけるUXデザイン・UXリサーチ
 
WayOfNoTrouble.pptx
WayOfNoTrouble.pptxWayOfNoTrouble.pptx
WayOfNoTrouble.pptx
 
図解で学ぶ「Lean UX」
図解で学ぶ「Lean UX」図解で学ぶ「Lean UX」
図解で学ぶ「Lean UX」
 
5分で出来る!イケてるconfluenceページ
5分で出来る!イケてるconfluenceページ5分で出来る!イケてるconfluenceページ
5分で出来る!イケてるconfluenceページ
 

Viewers also liked

日経BPリーン式創業塾 #leanstartup #リーンスタートアップ
日経BPリーン式創業塾 #leanstartup #リーンスタートアップ日経BPリーン式創業塾 #leanstartup #リーンスタートアップ
日経BPリーン式創業塾 #leanstartup #リーンスタートアップItsuki Kuroda
 
リーンスタートアップ概論
リーンスタートアップ概論リーンスタートアップ概論
リーンスタートアップ概論Itsuki Kuroda
 
社内スタートアップによる組織の成長に伴い発生する痛みとその解決策について(Rebuild) #devlove
社内スタートアップによる組織の成長に伴い発生する痛みとその解決策について(Rebuild) #devlove 社内スタートアップによる組織の成長に伴い発生する痛みとその解決策について(Rebuild) #devlove
社内スタートアップによる組織の成長に伴い発生する痛みとその解決策について(Rebuild) #devlove Itsuki Kuroda
 
[Developers Summit 2017] MicrosoftのAI開発機能/サービス
[Developers Summit 2017] MicrosoftのAI開発機能/サービス[Developers Summit 2017] MicrosoftのAI開発機能/サービス
[Developers Summit 2017] MicrosoftのAI開発機能/サービスNaoki (Neo) SATO
 
社内スタートアップによる組織の成長に伴い発生する痛みとその解決策(スクラム&リーンスタートアップ導入)について #devlove #devlove創
社内スタートアップによる組織の成長に伴い発生する痛みとその解決策(スクラム&リーンスタートアップ導入)について #devlove #devlove創社内スタートアップによる組織の成長に伴い発生する痛みとその解決策(スクラム&リーンスタートアップ導入)について #devlove #devlove創
社内スタートアップによる組織の成長に伴い発生する痛みとその解決策(スクラム&リーンスタートアップ導入)について #devlove #devlove創Itsuki Kuroda
 
Nfcハッカソン発表資料
Nfcハッカソン発表資料Nfcハッカソン発表資料
Nfcハッカソン発表資料Itsuki Kuroda
 
女子中高生とTwitter4J #twtr_hack
女子中高生とTwitter4J #twtr_hack女子中高生とTwitter4J #twtr_hack
女子中高生とTwitter4J #twtr_hackItsuki Kuroda
 
Social.framework&Account.framework #twtr_hack
Social.framework&Account.framework #twtr_hackSocial.framework&Account.framework #twtr_hack
Social.framework&Account.framework #twtr_hackItsuki Kuroda
 
First step of UX Monitoring 〜UXモニタリングこと始め〜
First step of UX Monitoring 〜UXモニタリングこと始め〜First step of UX Monitoring 〜UXモニタリングこと始め〜
First step of UX Monitoring 〜UXモニタリングこと始め〜Taro Yoshioka
 
ソフトハウスの品質保証のウソホント
ソフトハウスの品質保証のウソホントソフトハウスの品質保証のウソホント
ソフトハウスの品質保証のウソホントYasuharu Nishi
 
テスト駆動開発入門
テスト駆動開発入門テスト駆動開発入門
テスト駆動開発入門Shuji Watanabe
 
AARRRで始めるグロースハック
AARRRで始めるグロースハックAARRRで始めるグロースハック
AARRRで始めるグロースハックpLucky
 
スタートアップにおける技術チームの作り方
スタートアップにおける技術チームの作り方スタートアップにおける技術チームの作り方
スタートアップにおける技術チームの作り方Yuji Otani
 
テスト駆動開発のはじめ方
テスト駆動開発のはじめ方テスト駆動開発のはじめ方
テスト駆動開発のはじめ方Shuji Watanabe
 
【Running Lean入門】リーンキャンバス作成ワークショップ(簡易版)
【Running Lean入門】リーンキャンバス作成ワークショップ(簡易版)【Running Lean入門】リーンキャンバス作成ワークショップ(簡易版)
【Running Lean入門】リーンキャンバス作成ワークショップ(簡易版)Masanori Kado
 
ソフトウェアの品質保証の基礎とこれから
ソフトウェアの品質保証の基礎とこれからソフトウェアの品質保証の基礎とこれから
ソフトウェアの品質保証の基礎とこれからYasuharu Nishi
 
Y Combinator 創業者 Paul Graham からのスタートアップへのアドバイス(スタートアップが迷った時に読む Paul Graham から...
Y Combinator 創業者 Paul Graham からのスタートアップへのアドバイス(スタートアップが迷った時に読む Paul Graham から...Y Combinator 創業者 Paul Graham からのスタートアップへのアドバイス(スタートアップが迷った時に読む Paul Graham から...
Y Combinator 創業者 Paul Graham からのスタートアップへのアドバイス(スタートアップが迷った時に読む Paul Graham から...Takaaki Umada
 
connpassの戦略決定〜チームで取り組んだ価値のデザイン
connpassの戦略決定〜チームで取り組んだ価値のデザイン  connpassの戦略決定〜チームで取り組んだ価値のデザイン
connpassの戦略決定〜チームで取り組んだ価値のデザイン Haruo Sato
 
「訴求ファースト」と「こだわり駆動開発」~教育、医療、もの書き市場で戦うプロダクトマネージャーの考え方~
「訴求ファースト」と「こだわり駆動開発」~教育、医療、もの書き市場で戦うプロダクトマネージャーの考え方~「訴求ファースト」と「こだわり駆動開発」~教育、医療、もの書き市場で戦うプロダクトマネージャーの考え方~
「訴求ファースト」と「こだわり駆動開発」~教育、医療、もの書き市場で戦うプロダクトマネージャーの考え方~JustSystems Corporation
 

Viewers also liked (20)

日経BPリーン式創業塾 #leanstartup #リーンスタートアップ
日経BPリーン式創業塾 #leanstartup #リーンスタートアップ日経BPリーン式創業塾 #leanstartup #リーンスタートアップ
日経BPリーン式創業塾 #leanstartup #リーンスタートアップ
 
リーンスタートアップ概論
リーンスタートアップ概論リーンスタートアップ概論
リーンスタートアップ概論
 
社内スタートアップによる組織の成長に伴い発生する痛みとその解決策について(Rebuild) #devlove
社内スタートアップによる組織の成長に伴い発生する痛みとその解決策について(Rebuild) #devlove 社内スタートアップによる組織の成長に伴い発生する痛みとその解決策について(Rebuild) #devlove
社内スタートアップによる組織の成長に伴い発生する痛みとその解決策について(Rebuild) #devlove
 
[Developers Summit 2017] MicrosoftのAI開発機能/サービス
[Developers Summit 2017] MicrosoftのAI開発機能/サービス[Developers Summit 2017] MicrosoftのAI開発機能/サービス
[Developers Summit 2017] MicrosoftのAI開発機能/サービス
 
社内スタートアップによる組織の成長に伴い発生する痛みとその解決策(スクラム&リーンスタートアップ導入)について #devlove #devlove創
社内スタートアップによる組織の成長に伴い発生する痛みとその解決策(スクラム&リーンスタートアップ導入)について #devlove #devlove創社内スタートアップによる組織の成長に伴い発生する痛みとその解決策(スクラム&リーンスタートアップ導入)について #devlove #devlove創
社内スタートアップによる組織の成長に伴い発生する痛みとその解決策(スクラム&リーンスタートアップ導入)について #devlove #devlove創
 
Nfcハッカソン発表資料
Nfcハッカソン発表資料Nfcハッカソン発表資料
Nfcハッカソン発表資料
 
女子中高生とTwitter4J #twtr_hack
女子中高生とTwitter4J #twtr_hack女子中高生とTwitter4J #twtr_hack
女子中高生とTwitter4J #twtr_hack
 
Social.framework&Account.framework #twtr_hack
Social.framework&Account.framework #twtr_hackSocial.framework&Account.framework #twtr_hack
Social.framework&Account.framework #twtr_hack
 
First step of UX Monitoring 〜UXモニタリングこと始め〜
First step of UX Monitoring 〜UXモニタリングこと始め〜First step of UX Monitoring 〜UXモニタリングこと始め〜
First step of UX Monitoring 〜UXモニタリングこと始め〜
 
ソフトハウスの品質保証のウソホント
ソフトハウスの品質保証のウソホントソフトハウスの品質保証のウソホント
ソフトハウスの品質保証のウソホント
 
テスト駆動開発入門
テスト駆動開発入門テスト駆動開発入門
テスト駆動開発入門
 
AARRRで始めるグロースハック
AARRRで始めるグロースハックAARRRで始めるグロースハック
AARRRで始めるグロースハック
 
スタートアップにおける技術チームの作り方
スタートアップにおける技術チームの作り方スタートアップにおける技術チームの作り方
スタートアップにおける技術チームの作り方
 
テスト駆動開発のはじめ方
テスト駆動開発のはじめ方テスト駆動開発のはじめ方
テスト駆動開発のはじめ方
 
【Running Lean入門】リーンキャンバス作成ワークショップ(簡易版)
【Running Lean入門】リーンキャンバス作成ワークショップ(簡易版)【Running Lean入門】リーンキャンバス作成ワークショップ(簡易版)
【Running Lean入門】リーンキャンバス作成ワークショップ(簡易版)
 
ソフトウェアの品質保証の基礎とこれから
ソフトウェアの品質保証の基礎とこれからソフトウェアの品質保証の基礎とこれから
ソフトウェアの品質保証の基礎とこれから
 
MVP CANVAS
MVP CANVASMVP CANVAS
MVP CANVAS
 
Y Combinator 創業者 Paul Graham からのスタートアップへのアドバイス(スタートアップが迷った時に読む Paul Graham から...
Y Combinator 創業者 Paul Graham からのスタートアップへのアドバイス(スタートアップが迷った時に読む Paul Graham から...Y Combinator 創業者 Paul Graham からのスタートアップへのアドバイス(スタートアップが迷った時に読む Paul Graham から...
Y Combinator 創業者 Paul Graham からのスタートアップへのアドバイス(スタートアップが迷った時に読む Paul Graham から...
 
connpassの戦略決定〜チームで取り組んだ価値のデザイン
connpassの戦略決定〜チームで取り組んだ価値のデザイン  connpassの戦略決定〜チームで取り組んだ価値のデザイン
connpassの戦略決定〜チームで取り組んだ価値のデザイン
 
「訴求ファースト」と「こだわり駆動開発」~教育、医療、もの書き市場で戦うプロダクトマネージャーの考え方~
「訴求ファースト」と「こだわり駆動開発」~教育、医療、もの書き市場で戦うプロダクトマネージャーの考え方~「訴求ファースト」と「こだわり駆動開発」~教育、医療、もの書き市場で戦うプロダクトマネージャーの考え方~
「訴求ファースト」と「こだわり駆動開発」~教育、医療、もの書き市場で戦うプロダクトマネージャーの考え方~
 

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

LEAN STARTUP OVERVIEW
LEAN STARTUP OVERVIEWLEAN STARTUP OVERVIEW
LEAN STARTUP OVERVIEWItsuki Kuroda
 
Twilio Meetup Tokyo 2015 Microsoft 講演資料「開発コミュニティでアイディアと仲間を見つけよう!ハッカソンから技術系スター...
Twilio Meetup Tokyo 2015 Microsoft 講演資料「開発コミュニティでアイディアと仲間を見つけよう!ハッカソンから技術系スター...Twilio Meetup Tokyo 2015 Microsoft 講演資料「開発コミュニティでアイディアと仲間を見つけよう!ハッカソンから技術系スター...
Twilio Meetup Tokyo 2015 Microsoft 講演資料「開発コミュニティでアイディアと仲間を見つけよう!ハッカソンから技術系スター...Shinichiro Isago
 
シラサギ紹介20170915
シラサギ紹介20170915シラサギ紹介20170915
シラサギ紹介20170915Naokazu Nohara
 
OSCnagoya2019(Shirasagi20190709)
OSCnagoya2019(Shirasagi20190709)OSCnagoya2019(Shirasagi20190709)
OSCnagoya2019(Shirasagi20190709)Naokazu Nohara
 
シラサギ紹介(OSC東京)
シラサギ紹介(OSC東京)シラサギ紹介(OSC東京)
シラサギ紹介(OSC東京)Naokazu Nohara
 
Shirasagi20190222(OSC TOKYO)
Shirasagi20190222(OSC TOKYO)Shirasagi20190222(OSC TOKYO)
Shirasagi20190222(OSC TOKYO)Naokazu Nohara
 
価値デザインと並行して進めるエンタープライズアジャイルの姿
価値デザインと並行して進めるエンタープライズアジャイルの姿価値デザインと並行して進めるエンタープライズアジャイルの姿
価値デザインと並行して進めるエンタープライズアジャイルの姿Hagimoto Junzo
 
シラサギ紹介OSC京都2017
シラサギ紹介OSC京都2017シラサギ紹介OSC京都2017
シラサギ紹介OSC京都2017Naokazu Nohara
 
探検隊長が語るSoftLayerデザインパターン
探検隊長が語るSoftLayerデザインパターン探検隊長が語るSoftLayerデザインパターン
探検隊長が語るSoftLayerデザインパターンMaho Takara
 
UDJ_Company Introduction_2024.nov.pdf
UDJ_Company Introduction_2024.nov.pdfUDJ_Company Introduction_2024.nov.pdf
UDJ_Company Introduction_2024.nov.pdfRikuHamaguchi
 
What is Enterprise Agile
What is Enterprise Agile What is Enterprise Agile
What is Enterprise Agile Kenji Hiranabe
 
夏サミ2013【A1】基礎からわかるDevOps
夏サミ2013【A1】基礎からわかるDevOps夏サミ2013【A1】基礎からわかるDevOps
夏サミ2013【A1】基礎からわかるDevOpsDevelopers Summit
 
Social Change 〜 ソフトウェア開発者が経営者になるまでと、これからの戦略
Social Change 〜 ソフトウェア開発者が経営者になるまでと、これからの戦略Social Change 〜 ソフトウェア開発者が経営者になるまでと、これからの戦略
Social Change 〜 ソフトウェア開発者が経営者になるまでと、これからの戦略Yoshihito Kuranuki
 
リアルタイムトレンド抽出飛び込み用
リアルタイムトレンド抽出飛び込み用リアルタイムトレンド抽出飛び込み用
リアルタイムトレンド抽出飛び込み用DMM.com
 
シラサギ紹介osc京都
シラサギ紹介osc京都シラサギ紹介osc京都
シラサギ紹介osc京都Naokazu Nohara
 
シラサギ紹介20170525
シラサギ紹介20170525シラサギ紹介20170525
シラサギ紹介20170525Naokazu Nohara
 

Similar to エンジニアが成長のエンジンになる日 #devsumi #natsumiC7 (20)

LEAN STARTUP OVERVIEW
LEAN STARTUP OVERVIEWLEAN STARTUP OVERVIEW
LEAN STARTUP OVERVIEW
 
Twilio Meetup Tokyo 2015 Microsoft 講演資料「開発コミュニティでアイディアと仲間を見つけよう!ハッカソンから技術系スター...
Twilio Meetup Tokyo 2015 Microsoft 講演資料「開発コミュニティでアイディアと仲間を見つけよう!ハッカソンから技術系スター...Twilio Meetup Tokyo 2015 Microsoft 講演資料「開発コミュニティでアイディアと仲間を見つけよう!ハッカソンから技術系スター...
Twilio Meetup Tokyo 2015 Microsoft 講演資料「開発コミュニティでアイディアと仲間を見つけよう!ハッカソンから技術系スター...
 
OSC KYOTO 2018
OSC KYOTO 2018OSC KYOTO 2018
OSC KYOTO 2018
 
シラサギ紹介20170915
シラサギ紹介20170915シラサギ紹介20170915
シラサギ紹介20170915
 
OSC長岡
OSC長岡OSC長岡
OSC長岡
 
Osc広島2017
Osc広島2017Osc広島2017
Osc広島2017
 
OSCnagoya2019(Shirasagi20190709)
OSCnagoya2019(Shirasagi20190709)OSCnagoya2019(Shirasagi20190709)
OSCnagoya2019(Shirasagi20190709)
 
シラサギ紹介(OSC東京)
シラサギ紹介(OSC東京)シラサギ紹介(OSC東京)
シラサギ紹介(OSC東京)
 
OSC Chiba 2017
OSC Chiba 2017OSC Chiba 2017
OSC Chiba 2017
 
Shirasagi20190222(OSC TOKYO)
Shirasagi20190222(OSC TOKYO)Shirasagi20190222(OSC TOKYO)
Shirasagi20190222(OSC TOKYO)
 
価値デザインと並行して進めるエンタープライズアジャイルの姿
価値デザインと並行して進めるエンタープライズアジャイルの姿価値デザインと並行して進めるエンタープライズアジャイルの姿
価値デザインと並行して進めるエンタープライズアジャイルの姿
 
シラサギ紹介OSC京都2017
シラサギ紹介OSC京都2017シラサギ紹介OSC京都2017
シラサギ紹介OSC京都2017
 
探検隊長が語るSoftLayerデザインパターン
探検隊長が語るSoftLayerデザインパターン探検隊長が語るSoftLayerデザインパターン
探検隊長が語るSoftLayerデザインパターン
 
UDJ_Company Introduction_2024.nov.pdf
UDJ_Company Introduction_2024.nov.pdfUDJ_Company Introduction_2024.nov.pdf
UDJ_Company Introduction_2024.nov.pdf
 
What is Enterprise Agile
What is Enterprise Agile What is Enterprise Agile
What is Enterprise Agile
 
夏サミ2013【A1】基礎からわかるDevOps
夏サミ2013【A1】基礎からわかるDevOps夏サミ2013【A1】基礎からわかるDevOps
夏サミ2013【A1】基礎からわかるDevOps
 
Social Change 〜 ソフトウェア開発者が経営者になるまでと、これからの戦略
Social Change 〜 ソフトウェア開発者が経営者になるまでと、これからの戦略Social Change 〜 ソフトウェア開発者が経営者になるまでと、これからの戦略
Social Change 〜 ソフトウェア開発者が経営者になるまでと、これからの戦略
 
リアルタイムトレンド抽出飛び込み用
リアルタイムトレンド抽出飛び込み用リアルタイムトレンド抽出飛び込み用
リアルタイムトレンド抽出飛び込み用
 
シラサギ紹介osc京都
シラサギ紹介osc京都シラサギ紹介osc京都
シラサギ紹介osc京都
 
シラサギ紹介20170525
シラサギ紹介20170525シラサギ紹介20170525
シラサギ紹介20170525
 

More from Itsuki Kuroda

大企業アジャイルの勘所(ver1.1) #アジャイルマネジメントセミナー
大企業アジャイルの勘所(ver1.1) #アジャイルマネジメントセミナー大企業アジャイルの勘所(ver1.1) #アジャイルマネジメントセミナー
大企業アジャイルの勘所(ver1.1) #アジャイルマネジメントセミナーItsuki Kuroda
 
カネとAgile(大企業新規事業編) #rsgt2021
カネとAgile(大企業新規事業編) #rsgt2021カネとAgile(大企業新規事業編) #rsgt2021
カネとAgile(大企業新規事業編) #rsgt2021Itsuki Kuroda
 
大規模レガシー環境に立ち向かう有機的な開発フォーメーション #devsumi #devsumic
大規模レガシー環境に立ち向かう有機的な開発フォーメーション #devsumi #devsumic大規模レガシー環境に立ち向かう有機的な開発フォーメーション #devsumi #devsumic
大規模レガシー環境に立ち向かう有機的な開発フォーメーション #devsumi #devsumicItsuki Kuroda
 
大企業アジャイルの勘所 #devlovex #devlovexd
大企業アジャイルの勘所 #devlovex #devlovexd大企業アジャイルの勘所 #devlovex #devlovexd
大企業アジャイルの勘所 #devlovex #devlovexdItsuki Kuroda
 
カネとAgile #RSGT2018
カネとAgile #RSGT2018カネとAgile #RSGT2018
カネとAgile #RSGT2018Itsuki Kuroda
 
フロー効率性とリソース効率性について #xpjug
フロー効率性とリソース効率性について #xpjugフロー効率性とリソース効率性について #xpjug
フロー効率性とリソース効率性について #xpjugItsuki Kuroda
 
事業が対峙する現実からエンジニアリングを俯瞰する #devlove
事業が対峙する現実からエンジニアリングを俯瞰する #devlove事業が対峙する現実からエンジニアリングを俯瞰する #devlove
事業が対峙する現実からエンジニアリングを俯瞰する #devloveItsuki Kuroda
 
Let's design MVP #devlove #leanstartup
Let's design MVP #devlove #leanstartupLet's design MVP #devlove #leanstartup
Let's design MVP #devlove #leanstartupItsuki Kuroda
 
Play勉強会資料(MTLブログ用)
Play勉強会資料(MTLブログ用)Play勉強会資料(MTLブログ用)
Play勉強会資料(MTLブログ用)Itsuki Kuroda
 
学生向けAndroid勉強会(入門編)
学生向けAndroid勉強会(入門編)学生向けAndroid勉強会(入門編)
学生向けAndroid勉強会(入門編)Itsuki Kuroda
 

More from Itsuki Kuroda (10)

大企業アジャイルの勘所(ver1.1) #アジャイルマネジメントセミナー
大企業アジャイルの勘所(ver1.1) #アジャイルマネジメントセミナー大企業アジャイルの勘所(ver1.1) #アジャイルマネジメントセミナー
大企業アジャイルの勘所(ver1.1) #アジャイルマネジメントセミナー
 
カネとAgile(大企業新規事業編) #rsgt2021
カネとAgile(大企業新規事業編) #rsgt2021カネとAgile(大企業新規事業編) #rsgt2021
カネとAgile(大企業新規事業編) #rsgt2021
 
大規模レガシー環境に立ち向かう有機的な開発フォーメーション #devsumi #devsumic
大規模レガシー環境に立ち向かう有機的な開発フォーメーション #devsumi #devsumic大規模レガシー環境に立ち向かう有機的な開発フォーメーション #devsumi #devsumic
大規模レガシー環境に立ち向かう有機的な開発フォーメーション #devsumi #devsumic
 
大企業アジャイルの勘所 #devlovex #devlovexd
大企業アジャイルの勘所 #devlovex #devlovexd大企業アジャイルの勘所 #devlovex #devlovexd
大企業アジャイルの勘所 #devlovex #devlovexd
 
カネとAgile #RSGT2018
カネとAgile #RSGT2018カネとAgile #RSGT2018
カネとAgile #RSGT2018
 
フロー効率性とリソース効率性について #xpjug
フロー効率性とリソース効率性について #xpjugフロー効率性とリソース効率性について #xpjug
フロー効率性とリソース効率性について #xpjug
 
事業が対峙する現実からエンジニアリングを俯瞰する #devlove
事業が対峙する現実からエンジニアリングを俯瞰する #devlove事業が対峙する現実からエンジニアリングを俯瞰する #devlove
事業が対峙する現実からエンジニアリングを俯瞰する #devlove
 
Let's design MVP #devlove #leanstartup
Let's design MVP #devlove #leanstartupLet's design MVP #devlove #leanstartup
Let's design MVP #devlove #leanstartup
 
Play勉強会資料(MTLブログ用)
Play勉強会資料(MTLブログ用)Play勉強会資料(MTLブログ用)
Play勉強会資料(MTLブログ用)
 
学生向けAndroid勉強会(入門編)
学生向けAndroid勉強会(入門編)学生向けAndroid勉強会(入門編)
学生向けAndroid勉強会(入門編)
 

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