SlideShare a Scribd company logo
1 of 65
Download to read offline
新規事業が対峙
する現実から
エンジニアリン
グを俯瞰する
RECRUIT TECHNOLOGIES
IT Management Division
Development 2 , DevOps0G
Kuroda Itsuki @i2key
本スライドの主語:大企業内の新規事業
文脈により事情は大きく変わると思うので、
正解はないと思います。
考え方の取っ掛かりにしていただければ。
※注意
想定読者
・ビジネスに対峙するエンジニアリーダー的な人
・ビジネスに価値貢献するとか、価値を作るといいつつ、
それ以上具体的に言語化できない人
・よかれと思う改善提案がビジネス側の理解を得られず悶々
としている人
越境の足跡
見えてきた勘所
現場に還る
越境の足跡
見えてきた勘所
現場に還る
エンジニアリングビジネス
PBL
リリー
ス
プランニ
ング
振り返り
MTG
レビュー
デイリー
MTG
Sprint/2weeks 開発タスク/Day
エンジニアチーム全員の稼働を簡単にムダに出来るポジションだからこそ、プロダクトオー
ナー・プロダクトマネージャ採用基準は厳しい(あるべき)
僕の考えた最強
の機能リスト
PBLの質、超重要。
(やる必然性・エビデンスの有無)
施策に対するコスト責任をおえている、もしくは、他の施策と濁り無く施策効果を単体で計測できる
環境がないと実施内容が大きくてキラキラするバイアスが発生することがある。
実際の数値で施策の結果を評価できないため賑やかなものを作りたくなる。(各種構造上の問題)
どんなに開発チームがスペシャルでも、チームに  をインプットすると
結局、価値をうまない  がチームからアウトプットされる
エンジニアリングビジネス
PBL
リリー
ス
プランニ
ング
振り返り
MTG
レビュー
デイリー
MTG
Sprint/2weeks 開発タスク/Day
計測
構築
学習
デー
タ
アイ
デア
ビジネス
仮説リスト
全部、思い込みだと前提におく
思い込みにより発生する各種ムダを
省くためにリーンにやる
http://www.slideshare.net/i2key/45-developers-summit-2015-devsumi-devsumib
http://www.slideshare.net/i2key/devsumi-natsumic7
※(元)僕の考えた
最強の機能リスト
従来の
プロダクトバックログ
仮説検証型の
プロダクトバックログ
・仮説A検証用モック作成
・仮説B検証用ダミーボタン実装
・検証済み○○機能本実装
・検証済み○○機能本実装
・リファラル向上改善
・登録ファネル改善
・計測基盤実装
・コホートに対するプッシュ実装
・○○機能実装
・○○機能実装
・○○機能実装
・○○機能実装
・○○機能実装
・○○機能実装
・○○機能実装
・○○機能実装
・○○機能実装
・○○機能実装
・○○機能実装
わざわざ開発せずに
インタビューやエンジニアリング以外で検証できそう
根拠無し
根拠無し
根拠無し
事前検証
(エビデンス収集)
実証後の実装
国内x企業内新規事業→海外xスタートアップ
出資先海外スタートアップ
の日本市場グロース支援
www.slideshare.net/i2key/bp-leanstartup/42
リクルートジョブズリクルート住まい
カンパニー
リクルート住まい
カンパニー
RECRUIT
VENTURESTechLab PAAK
RECRUIT
VENTURES
RECRUIT VENTURES
RECRUIT VENTURES
(全拠点生放送)
http://www.slideshare.net/i2key/leanstartup-devlove-leanstartup
http://l-orem.com/lean-startup-18-anti-patterns/
多くの新規事業の現場から
見えてきたアンチパターン集
エンジニアなのに・・・
膨大な量のビジネス企画のシャワーを浴びる
RECRUIT VENTURES、リクルートグループ各社での布教活動(いっ
ぱい)/各種審査員/新規事業アイデアの壁打ちメンター(大量)/etc
エンジニアリング
ビジネス
PBL
リリー
ス
プランニ
ング
振り返り
MTG
レビュー
デイリー
MTG
Sprint/2weeks 開発タスク/Day
計測
構築
学習
デー
タ
アイ
デア
ビジネス
仮説リスト
セールス / マーケ
プランニ
ング
実行
学習
役割の視野を広げる
時間軸の視野を広げる
越境の足跡
見えてきた勘所
現場に還る
この視界から
エンジニアリングを見てみる
これ
見えてきた勘所
ビジネスモデルから
エンジニアリングを見る
ビジネスモデル
↓
エンジニアリングの座組
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
成果課金型
広告枠検索サービス
¥0
利用者 クライアント
マッチング
サービス
CVR改善 = 売上直結
エンジニアの書いたコード上で売上がたつ例
水漏れ補修 水漏れ補修 水漏れ補修 水漏れ補修
CPA改善 = 売上直結
流入数
エンジニアによるプロダクト改善が売上目標に直接寄与
= エンジニアが成長のエンジン(になりやすい)
= エンジニアのビジネス貢献が可視化しやすい
= 数値目標を持ったプロダクトチームが
 じゃんじゃん改善サイクルを回すとよいパターン
= アジャイルとか超導入しやすい座組(結果が売上で出る)
(憧れのエンジニア文化がある会社はこのモデル多め)
エンジニアリングへのビジネス期待
安定性 or 俊敏性 どちらなのか
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”
検索条件
入力画面
検索結果
一覧画面
詳細画面 予約画面
口コミ
SEO
SEM
ETC
サービス
トップ
画面
if(isBooked){
}
口コミ
SEO
SEM
ETC
純広告枠
(営業商品)検索サービス
¥0
利用者 クライアント
マッチング
サービス
CVR改善 = 次回発注への信頼獲得 = 売上直結ではない
営業
エンジニアの書いたコード上で売上がたたない例
CV数
流入数
検索条件
入力画面
検索結果
一覧画面
詳細画面 予約画面
口コミ
SEO
SEM
ETC
サービス
トップ
画面
if(isBooked){
}
口コミ
SEO
SEM
ETC
純広告枠
(営業商品)検索サービス
¥0
利用者 クライアント
マッチング
サービス
CVR改善 = 次回発注への信頼獲得 = 売上直結ではない
営業
エンジニアの書いたコード上で売上がたたない例
CV数
流入数
売上
CVR・QCD
流入数
CV数
マーケ
プロダクト
営業
パワーバランスこうなりがち
売上 > 流入数・CV数 > CVR・QCD
(営業)     (マーケ)       (プロダクト)
検索条件
入力画面
検索結果
一覧画面
詳細画面 予約画面
口コミ
SEO
SEM
ETC
サービス
トップ
画面
if(isBooked){
}
口コミ
SEO
SEM
ETC
純広告枠
(営業商品)検索サービス
¥0
利用者 クライアント
マッチング
サービス
CVR改善 = 次回発注への信頼獲得 = 売上直結ではない
営業
エンジニアの書いたコード上で売上がたたない例
CV数
流入数
売上
CVR・QCD
流入数
CV数
マーケ
プロダクト
営業
パワーバランスこうなりがち
売上 > 流入数・CV数 > CVR・QCD
(営業)     (マーケ)       (プロダクト)
CTO及びそれに準ずる人がいれば
その人が説明責任を持ち均衡を保ってくれるはずだが・・・
大企業内新規事業だとそうもいかず・・・
検索条件
入力画面
検索結果
一覧画面
詳細画面 予約画面
口コミ
SEO
SEM
ETC
サービス
トップ
画面
if(isBooked){
}
口コミ
SEO
SEM
ETC
純広告枠
(営業商品)検索サービス
¥0
利用者 クライアント
マッチング
サービス
CVR改善 = 次回発注への信頼獲得 = 売上直結ではない
営業
エンジニアの書いたコード上で売上がたたない例
CV数
流入数
売上
CVR・QCD
流入数
CV数
マーケ
プロダクト
営業
営業が売上に直接的に寄与
= 営業が成長エンジン( 売上○○円/人 予測可能)
エンジニアは顧客単価を上げるための商品開発で寄与
& 改善・安定運用(CVR向上・QCD)
顧客単価UP貢献
12
検索条件
入力画面
検索結果
一覧画面
詳細画面 予約画面
口コミ
SEO
SEM
ETC
サービス
トップ
画面
if(isBooked){
}
口コミ
SEO
SEM
ETC
純広告枠
(営業商品)検索サービス
¥0
利用者 クライアント
マッチング
サービス
CVR改善 = 次回発注への信頼獲得 = 売上直結ではない
営業
エンジニアの書いたコード上で売上がたたない例
CV数
流入数
売上
CVR・QCD
流入数
CV数
マーケ
プロダクト
営業
営業が売上に直接的に寄与
= 営業が成長エンジン( 売上○○円/人 予測可能)
エンジニアは顧客単価を上げるための商品開発で寄与
& 改善・安定運用(CVR向上・QCD)
顧客単価UP貢献
ビジネス貢献を説明できず(理解されず)に
ここだけに極端にフォーカスがあたると・・・・ 12
検索条件
入力画面
検索結果
一覧画面
詳細画面 予約画面
口コミ
SEO
SEM
ETC
サービス
トップ
画面
if(isBooked){
}
口コミ
SEO
SEM
ETC
純広告枠
(営業商品)検索サービス
¥0
利用者 クライアント
マッチング
サービス
CVR改善 = 次回発注への信頼獲得 = 売上直結ではない
営業
エンジニアの書いたコード上で売上がたたない例
エンジニアのビジネス貢献が可視化しにくい
= トラブルだけが目立つようになる
= できて当たり前(減点主義)のパラダイム
= エンジニアはコスト削減や生産性向上のようなビジネス指標
から程遠い目標設定になる
= QCDSの制約の雁字搦めになるので、エンジニア側は壁を作
りディフェンシブになりだす
= 本来、俊敏に仮説検証回したい目的に反して、組織がスロー
ダウンしていく
12
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”
エンジニアのビジネス貢献を正しく説明できないと
本来の目的に反してコスト効率のパラダイムに引力が働くことがある
(ビジネスー開発間の信頼関係・理解等他にも要因あるが)
ビジネス貢献を
抜きにした
過剰な
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,on	Fit Product	/	Market	Fit 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)
次年度予算計画 次年度予算計画 次年度予算計画
Bimodal IT Mode1 Mode2
別名 System of Record(SoR) System of Engagement(SoE)
適正
基幹系・勘定系、
ミッションクリティカルな機能・システム
(決済システム、顧客管理等)
正解が無い中、柔軟に変化をしながら走り続
ける必要がある機能・サービス
(スマホアプリ、ウェブサービスのフロント)
目的
信頼性、安定性
定めた仕様に従って安定性や品質を担保し
ながら開発していく必要がある
俊敏性、速度
フィードバックに基づいて速やかに改善を加
え、頻繁にリリースする
価値・評価 費用対効果、コスト 売上、ブランド、UX
アプローチ ウォーターフォール、V-model、重量IID アジャイル、リーン、カンバン、軽量IID
調達
エンタープライズサプライヤー、
長期的な取引
小さい、新しいベンダー、短期間の取引
メンバ適正 従来のプロセス、プロジェクトが得意 新しくて不確実なプロジェクトが得意
組織/文化 開発部門・計画型 ビジネス&開発混在・探索型
サイクルタイム 数ヶ月 数日、数週間
本当は、俊敏性や速度を持ってやりたいのに、
結果的に重厚長大な計画駆動型になってしまう場合もある
年次予算計画の圧
本当は、こうしたいのに
エンタープライズの場合、年次の予算計画があり、
ベースとなるサイクルタイムは年になる。
1年先の未来の状況を事前に予想して計画しないとならない。
そして、それを1年後まで大幅に変更することはない。
計画の実行に固執すると「発見」による変更がきかなくなる
1年 1年 1年
新規事業なのに年次計画駆動になるバイアス
予算:目的のために確保する資金の合計(活動に費やせる金額の上限)
戦略:実際にやることを定義するもの
予算は戦略をどのように実現するべきか計画するのもではない
顧客に価値を届けるこのと成否を予測したり評価したりするのもではない。
課題:年次プロセス以外で資金調達する方法がない
課題:年次プロセス以外で資金調達する方法がない
→「発見」による軌道修正が不可能
→より多くの予算を確保するために多大な労力をかけて最高のビジネスプ
ランを計画(予想w)しないとならない
事例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
リリースまでのリードタイム 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
リリースまでのリードタイム 2w
リリースまでのリードタイム 3w
リリースまでのリードタイム 3w
リリースまでのリードタイム 3w
リリースまでのリードタイム 3w
たくさんのことを同時に調整しようとするから
仕様の調整の「会議」やら「定例」やらがうまれる
Git Flow
・Release Branchがマルチタスクをうんでいる?
・フロー効率あげるのに、可能なら一個流しにしたい
↓
Github Flow
現在移行に向け奮闘中
・CD
・デプロイパイプライン
・E2E Test整備
・Feature Flag
マルチタスクやめる
(例)
スクラム導入におけるビジネス側への説明内容抜粋
やりたいことが永久に湧いてくると思うので、得られるビジネス価値によって
優先順位付けするメカニズムが必要
・プロダクトバックログ運用開始
・状況の変化に柔軟に対応するための仕組み(トレードオフ、2週間開発)
 ・プランニング、スプリント
エンジニアチームの成果・やっていることを可視化
・全体の定例で毎週予定されているリリースプランを少し未来分まで提示
色々なステークホルダーがエンジニアリーダーにタスクを投げてくる状況(テッ
クリードがチケット差配屋さんになること)の脱却
・ビジネス側と開発側のコミュニケーションチャネルを人ではなく、
 プロダクトバックログ&プランニングという場に変更。
スプリントのエンジニア工数比率のポートフォリオの合意形成をしたい。
・各種施策を実施するためのカイゼン枠を確保。
現在のチームのスプリントのポートフォリオ
以下のタイムボックス管理
50% 機能追加
20% カイゼン(この枠で前述の各種カイゼン実施)
15% 既知バグ改修
15% 新規バグ改修
※打ち合わせや雑務の稼働時間は全部SprintBacklogにつんである上で残りの時間を上記に分
配している
カイゼンに20%おいているは大事。
(この20%の説明責任を果たし、ビジネス側に合意ををとるための勘所が本日のスライド。)
エンジニアのカイゼンのモチベーションを奪ってはいけない。
エンジニアの改善のモチベーションは良い方向に持っていこうとする善のエネルギー。
それをしょうもない理由でへし折るとチーム全体がダークサイドへ堕ちてしまう。
まだ道半ば
We’re HIRING!!
ともに越境し歩んでくれる
同士を募集しています

More Related Content

What's hot

フロー効率性とリソース効率性について #xpjug
フロー効率性とリソース効率性について #xpjugフロー効率性とリソース効率性について #xpjug
フロー効率性とリソース効率性について #xpjugItsuki Kuroda
 
LEANSTARTUPアンチパターン #devlove #leanstartup
LEANSTARTUPアンチパターン #devlove #leanstartupLEANSTARTUPアンチパターン #devlove #leanstartup
LEANSTARTUPアンチパターン #devlove #leanstartupItsuki Kuroda
 
Head First Inception Deck
Head First Inception DeckHead First Inception Deck
Head First Inception DeckNaoto Nishimura
 
組織にテストを書く文化を根付かせる戦略と戦術
組織にテストを書く文化を根付かせる戦略と戦術組織にテストを書く文化を根付かせる戦略と戦術
組織にテストを書く文化を根付かせる戦略と戦術Takuto Wada
 
ログの書き方がチームの生産性を爆上げする話
ログの書き方がチームの生産性を爆上げする話ログの書き方がチームの生産性を爆上げする話
ログの書き方がチームの生産性を爆上げする話Tsuyoshi Ushio
 
ユーザーインタビューするときは、どうやらゾンビのおでましさ
ユーザーインタビューするときは、どうやらゾンビのおでましさユーザーインタビューするときは、どうやらゾンビのおでましさ
ユーザーインタビューするときは、どうやらゾンビのおでましさYoshiki Hayama
 
あなたの手元の本よりいい方法がある! UXデザインのプロはこうやってユーザーのインサイトを確実に見つける
あなたの手元の本よりいい方法がある! UXデザインのプロはこうやってユーザーのインサイトを確実に見つけるあなたの手元の本よりいい方法がある! UXデザインのプロはこうやってユーザーのインサイトを確実に見つける
あなたの手元の本よりいい方法がある! UXデザインのプロはこうやってユーザーのインサイトを確実に見つけるYoshiki Hayama
 
リーンスタートアップにおける良い仮説、悪い仮説
リーンスタートアップにおける良い仮説、悪い仮説リーンスタートアップにおける良い仮説、悪い仮説
リーンスタートアップにおける良い仮説、悪い仮説Takaaki Umada
 
心理的安全性を 0から80ぐらいに上げた話
心理的安全性を 0から80ぐらいに上げた話心理的安全性を 0から80ぐらいに上げた話
心理的安全性を 0から80ぐらいに上げた話Yusuke Hisatsu
 
5分でわかる良いスライドのつくりかた
5分でわかる良いスライドのつくりかた5分でわかる良いスライドのつくりかた
5分でわかる良いスライドのつくりかたKoki Kaku
 
Leanstartupをリーンにヤル #リーンスタートアップ
Leanstartupをリーンにヤル #リーンスタートアップLeanstartupをリーンにヤル #リーンスタートアップ
Leanstartupをリーンにヤル #リーンスタートアップItsuki Kuroda
 
大企業アジャイルの勘所(ver1.1) #アジャイルマネジメントセミナー
大企業アジャイルの勘所(ver1.1) #アジャイルマネジメントセミナー大企業アジャイルの勘所(ver1.1) #アジャイルマネジメントセミナー
大企業アジャイルの勘所(ver1.1) #アジャイルマネジメントセミナーItsuki Kuroda
 
4つの戦犯から考えるサービスづくりの失敗
4つの戦犯から考えるサービスづくりの失敗4つの戦犯から考えるサービスづくりの失敗
4つの戦犯から考えるサービスづくりの失敗toshihiro ichitani
 
Kanban Vs Scrum日本語版
Kanban Vs Scrum日本語版Kanban Vs Scrum日本語版
Kanban Vs Scrum日本語版Hiroki Kondo
 
LEAN STARTUP OVERVIEW
LEAN STARTUP OVERVIEWLEAN STARTUP OVERVIEW
LEAN STARTUP OVERVIEWItsuki Kuroda
 
フロー効率性とリソース効率性、再入門 #devlove #devkan
フロー効率性とリソース効率性、再入門 #devlove #devkanフロー効率性とリソース効率性、再入門 #devlove #devkan
フロー効率性とリソース効率性、再入門 #devlove #devkanItsuki Kuroda
 
人生で大事なことは XP白本と参考文献に教わった
人生で大事なことは XP白本と参考文献に教わった 人生で大事なことは XP白本と参考文献に教わった
人生で大事なことは XP白本と参考文献に教わった Takeshi Kakeda
 
スクラムパタン入門
スクラムパタン入門スクラムパタン入門
スクラムパタン入門Kiro Harada
 
解説!30分で分かるLEAN ANALYTICS
解説!30分で分かるLEAN ANALYTICS解説!30分で分かるLEAN ANALYTICS
解説!30分で分かるLEAN ANALYTICSしくみ製作所
 

What's hot (20)

フロー効率性とリソース効率性について #xpjug
フロー効率性とリソース効率性について #xpjugフロー効率性とリソース効率性について #xpjug
フロー効率性とリソース効率性について #xpjug
 
LEANSTARTUPアンチパターン #devlove #leanstartup
LEANSTARTUPアンチパターン #devlove #leanstartupLEANSTARTUPアンチパターン #devlove #leanstartup
LEANSTARTUPアンチパターン #devlove #leanstartup
 
Head First Inception Deck
Head First Inception DeckHead First Inception Deck
Head First Inception Deck
 
組織にテストを書く文化を根付かせる戦略と戦術
組織にテストを書く文化を根付かせる戦略と戦術組織にテストを書く文化を根付かせる戦略と戦術
組織にテストを書く文化を根付かせる戦略と戦術
 
ログの書き方がチームの生産性を爆上げする話
ログの書き方がチームの生産性を爆上げする話ログの書き方がチームの生産性を爆上げする話
ログの書き方がチームの生産性を爆上げする話
 
ユーザーインタビューするときは、どうやらゾンビのおでましさ
ユーザーインタビューするときは、どうやらゾンビのおでましさユーザーインタビューするときは、どうやらゾンビのおでましさ
ユーザーインタビューするときは、どうやらゾンビのおでましさ
 
あなたの手元の本よりいい方法がある! UXデザインのプロはこうやってユーザーのインサイトを確実に見つける
あなたの手元の本よりいい方法がある! UXデザインのプロはこうやってユーザーのインサイトを確実に見つけるあなたの手元の本よりいい方法がある! UXデザインのプロはこうやってユーザーのインサイトを確実に見つける
あなたの手元の本よりいい方法がある! UXデザインのプロはこうやってユーザーのインサイトを確実に見つける
 
リーンスタートアップにおける良い仮説、悪い仮説
リーンスタートアップにおける良い仮説、悪い仮説リーンスタートアップにおける良い仮説、悪い仮説
リーンスタートアップにおける良い仮説、悪い仮説
 
心理的安全性を 0から80ぐらいに上げた話
心理的安全性を 0から80ぐらいに上げた話心理的安全性を 0から80ぐらいに上げた話
心理的安全性を 0から80ぐらいに上げた話
 
5分でわかる良いスライドのつくりかた
5分でわかる良いスライドのつくりかた5分でわかる良いスライドのつくりかた
5分でわかる良いスライドのつくりかた
 
Leanstartupをリーンにヤル #リーンスタートアップ
Leanstartupをリーンにヤル #リーンスタートアップLeanstartupをリーンにヤル #リーンスタートアップ
Leanstartupをリーンにヤル #リーンスタートアップ
 
大企業アジャイルの勘所(ver1.1) #アジャイルマネジメントセミナー
大企業アジャイルの勘所(ver1.1) #アジャイルマネジメントセミナー大企業アジャイルの勘所(ver1.1) #アジャイルマネジメントセミナー
大企業アジャイルの勘所(ver1.1) #アジャイルマネジメントセミナー
 
4つの戦犯から考えるサービスづくりの失敗
4つの戦犯から考えるサービスづくりの失敗4つの戦犯から考えるサービスづくりの失敗
4つの戦犯から考えるサービスづくりの失敗
 
Kanban Vs Scrum日本語版
Kanban Vs Scrum日本語版Kanban Vs Scrum日本語版
Kanban Vs Scrum日本語版
 
LEAN STARTUP OVERVIEW
LEAN STARTUP OVERVIEWLEAN STARTUP OVERVIEW
LEAN STARTUP OVERVIEW
 
フロー効率性とリソース効率性、再入門 #devlove #devkan
フロー効率性とリソース効率性、再入門 #devlove #devkanフロー効率性とリソース効率性、再入門 #devlove #devkan
フロー効率性とリソース効率性、再入門 #devlove #devkan
 
人生で大事なことは XP白本と参考文献に教わった
人生で大事なことは XP白本と参考文献に教わった 人生で大事なことは XP白本と参考文献に教わった
人生で大事なことは XP白本と参考文献に教わった
 
スクラムパタン入門
スクラムパタン入門スクラムパタン入門
スクラムパタン入門
 
しょぼいプレゼンをパワポのせいにするな! by @jessedee
しょぼいプレゼンをパワポのせいにするな! by @jessedeeしょぼいプレゼンをパワポのせいにするな! by @jessedee
しょぼいプレゼンをパワポのせいにするな! by @jessedee
 
解説!30分で分かるLEAN ANALYTICS
解説!30分で分かるLEAN ANALYTICS解説!30分で分かるLEAN ANALYTICS
解説!30分で分かるLEAN ANALYTICS
 

Viewers also liked

CDNのトラフィックエンジニアリング:CDNの現状とSDNの可能性
CDNのトラフィックエンジニアリング:CDNの現状とSDNの可能性CDNのトラフィックエンジニアリング:CDNの現状とSDNの可能性
CDNのトラフィックエンジニアリング:CDNの現状とSDNの可能性J-Stream Inc.
 
TectonicはKubernetesの構築・管理基盤である -概要の章-/-構築の章-
TectonicはKubernetesの構築・管理基盤である -概要の章-/-構築の章-TectonicはKubernetesの構築・管理基盤である -概要の章-/-構築の章-
TectonicはKubernetesの構築・管理基盤である -概要の章-/-構築の章-Masahito Zembutsu
 
cacooアイコンの話
cacooアイコンの話cacooアイコンの話
cacooアイコンの話晋也 古渡
 
20171110 サーバーワークス流Cacoo使いこなし術
20171110 サーバーワークス流Cacoo使いこなし術20171110 サーバーワークス流Cacoo使いこなし術
20171110 サーバーワークス流Cacoo使いこなし術陽一 佐竹
 
DDD x CQRS 更新系と参照系で異なるORMを併用して上手くいった話
DDD x CQRS   更新系と参照系で異なるORMを併用して上手くいった話DDD x CQRS   更新系と参照系で異なるORMを併用して上手くいった話
DDD x CQRS 更新系と参照系で異なるORMを併用して上手くいった話Koichiro Matsuoka
 
脱・初心者!Googleアナリティクス活用テクニック
脱・初心者!Googleアナリティクス活用テクニック脱・初心者!Googleアナリティクス活用テクニック
脱・初心者!Googleアナリティクス活用テクニックNanae Hibino
 
[社内勉強会]ELBとALBと数万スパイク負荷テスト
[社内勉強会]ELBとALBと数万スパイク負荷テスト[社内勉強会]ELBとALBと数万スパイク負荷テスト
[社内勉強会]ELBとALBと数万スパイク負荷テストTakahiro Moteki
 
Scaling A Customer Team - Michael Redbord
Scaling A Customer Team - Michael RedbordScaling A Customer Team - Michael Redbord
Scaling A Customer Team - Michael RedbordSupport Driven
 
CDNのトレンド2017 セキュリティCDNとマルチCDN
CDNのトレンド2017 セキュリティCDNとマルチCDNCDNのトレンド2017 セキュリティCDNとマルチCDN
CDNのトレンド2017 セキュリティCDNとマルチCDNJ-Stream Inc.
 
Lean Analytics at Lean Startup Update!! 2015
Lean Analytics at Lean Startup Update!! 2015Lean Analytics at Lean Startup Update!! 2015
Lean Analytics at Lean Startup Update!! 2015Masanori Kado
 
サイボウズ式コミュニティとの関わり方
サイボウズ式コミュニティとの関わり方サイボウズ式コミュニティとの関わり方
サイボウズ式コミュニティとの関わり方Masataka Isa
 
20161124 cmc kickoff
20161124 cmc kickoff20161124 cmc kickoff
20161124 cmc kickoffHideki Ojima
 
20170902 ことば探しから始める情報設計ワークショップ
20170902 ことば探しから始める情報設計ワークショップ20170902 ことば探しから始める情報設計ワークショップ
20170902 ことば探しから始める情報設計ワークショップchachaki chachaki
 
20170623 cmc vol5_opening
20170623 cmc vol5_opening20170623 cmc vol5_opening
20170623 cmc vol5_openingHideki Ojima
 
【Zeal】azure + power biで始めるbigdata分析の第一歩 20171115版 公開用
【Zeal】azure + power biで始めるbigdata分析の第一歩 20171115版 公開用【Zeal】azure + power biで始めるbigdata分析の第一歩 20171115版 公開用
【Zeal】azure + power biで始めるbigdata分析の第一歩 20171115版 公開用yuuki takizawa
 
全自動Zabbix ver2
全自動Zabbix ver2全自動Zabbix ver2
全自動Zabbix ver2真乙 九龍
 
ZabbixでDockerも監視
ZabbixでDockerも監視 ZabbixでDockerも監視
ZabbixでDockerも監視 Atsushi Tanaka
 
Zabbix jp勉強会 Hadoop-HBaseの監視_20120512
Zabbix jp勉強会 Hadoop-HBaseの監視_20120512Zabbix jp勉強会 Hadoop-HBaseの監視_20120512
Zabbix jp勉強会 Hadoop-HBaseの監視_20120512Seiichiro Ishida
 

Viewers also liked (20)

CDNのトラフィックエンジニアリング:CDNの現状とSDNの可能性
CDNのトラフィックエンジニアリング:CDNの現状とSDNの可能性CDNのトラフィックエンジニアリング:CDNの現状とSDNの可能性
CDNのトラフィックエンジニアリング:CDNの現状とSDNの可能性
 
TectonicはKubernetesの構築・管理基盤である -概要の章-/-構築の章-
TectonicはKubernetesの構築・管理基盤である -概要の章-/-構築の章-TectonicはKubernetesの構築・管理基盤である -概要の章-/-構築の章-
TectonicはKubernetesの構築・管理基盤である -概要の章-/-構築の章-
 
cacooアイコンの話
cacooアイコンの話cacooアイコンの話
cacooアイコンの話
 
20171110 サーバーワークス流Cacoo使いこなし術
20171110 サーバーワークス流Cacoo使いこなし術20171110 サーバーワークス流Cacoo使いこなし術
20171110 サーバーワークス流Cacoo使いこなし術
 
DDD x CQRS 更新系と参照系で異なるORMを併用して上手くいった話
DDD x CQRS   更新系と参照系で異なるORMを併用して上手くいった話DDD x CQRS   更新系と参照系で異なるORMを併用して上手くいった話
DDD x CQRS 更新系と参照系で異なるORMを併用して上手くいった話
 
脱・初心者!Googleアナリティクス活用テクニック
脱・初心者!Googleアナリティクス活用テクニック脱・初心者!Googleアナリティクス活用テクニック
脱・初心者!Googleアナリティクス活用テクニック
 
[社内勉強会]ELBとALBと数万スパイク負荷テスト
[社内勉強会]ELBとALBと数万スパイク負荷テスト[社内勉強会]ELBとALBと数万スパイク負荷テスト
[社内勉強会]ELBとALBと数万スパイク負荷テスト
 
Scaling A Customer Team - Michael Redbord
Scaling A Customer Team - Michael RedbordScaling A Customer Team - Michael Redbord
Scaling A Customer Team - Michael Redbord
 
CDNのトレンド2017 セキュリティCDNとマルチCDN
CDNのトレンド2017 セキュリティCDNとマルチCDNCDNのトレンド2017 セキュリティCDNとマルチCDN
CDNのトレンド2017 セキュリティCDNとマルチCDN
 
Lean Analytics at Lean Startup Update!! 2015
Lean Analytics at Lean Startup Update!! 2015Lean Analytics at Lean Startup Update!! 2015
Lean Analytics at Lean Startup Update!! 2015
 
サイボウズ式コミュニティとの関わり方
サイボウズ式コミュニティとの関わり方サイボウズ式コミュニティとの関わり方
サイボウズ式コミュニティとの関わり方
 
20161124 cmc kickoff
20161124 cmc kickoff20161124 cmc kickoff
20161124 cmc kickoff
 
20170902 ことば探しから始める情報設計ワークショップ
20170902 ことば探しから始める情報設計ワークショップ20170902 ことば探しから始める情報設計ワークショップ
20170902 ことば探しから始める情報設計ワークショップ
 
20170623 cmc vol5_opening
20170623 cmc vol5_opening20170623 cmc vol5_opening
20170623 cmc vol5_opening
 
【Zeal】azure + power biで始めるbigdata分析の第一歩 20171115版 公開用
【Zeal】azure + power biで始めるbigdata分析の第一歩 20171115版 公開用【Zeal】azure + power biで始めるbigdata分析の第一歩 20171115版 公開用
【Zeal】azure + power biで始めるbigdata分析の第一歩 20171115版 公開用
 
全自動Zabbix ver2
全自動Zabbix ver2全自動Zabbix ver2
全自動Zabbix ver2
 
全自動Zabbix
全自動Zabbix全自動Zabbix
全自動Zabbix
 
Zabbix概論
Zabbix概論Zabbix概論
Zabbix概論
 
ZabbixでDockerも監視
ZabbixでDockerも監視 ZabbixでDockerも監視
ZabbixでDockerも監視
 
Zabbix jp勉強会 Hadoop-HBaseの監視_20120512
Zabbix jp勉強会 Hadoop-HBaseの監視_20120512Zabbix jp勉強会 Hadoop-HBaseの監視_20120512
Zabbix jp勉強会 Hadoop-HBaseの監視_20120512
 

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

using astah for openthology modeling
using astah for openthology modelingusing astah for openthology modeling
using astah for openthology modelingKenji Hiranabe
 
20130928 dev opsday_tokyo
20130928 dev opsday_tokyo20130928 dev opsday_tokyo
20130928 dev opsday_tokyoOsamu Takazoe
 
Introduction of KOTATSU-MODEL in Requirement Development
Introduction of KOTATSU-MODEL in Requirement DevelopmentIntroduction of KOTATSU-MODEL in Requirement Development
Introduction of KOTATSU-MODEL in Requirement DevelopmentKent Ishizawa
 
これからの開発環境の話をしよう - 開発現場力を高める環境づくり #ost2013
これからの開発環境の話をしよう - 開発現場力を高める環境づくり #ost2013これからの開発環境の話をしよう - 開発現場力を高める環境づくり #ost2013
これからの開発環境の話をしよう - 開発現場力を高める環境づくり #ost2013智治 長沢
 
Tcアドバイザリー業務の7ケース
Tcアドバイザリー業務の7ケースTcアドバイザリー業務の7ケース
Tcアドバイザリー業務の7ケースsinrock
 
アドバイザリー業務:7つのケース(事例)
アドバイザリー業務:7つのケース(事例)アドバイザリー業務:7つのケース(事例)
アドバイザリー業務:7つのケース(事例)sinrock
 
最新事例にみるサービスデザインという新潮流(I・CON2014)
最新事例にみるサービスデザインという新潮流(I・CON2014)最新事例にみるサービスデザインという新潮流(I・CON2014)
最新事例にみるサービスデザインという新潮流(I・CON2014)IMJ Corporation
 
Vantan shinsuke miyaki_upload
Vantan shinsuke miyaki_uploadVantan shinsuke miyaki_upload
Vantan shinsuke miyaki_uploadShinsuke Miyaki
 
SFA運用の秘訣と定着化のコツセミナー資料
SFA運用の秘訣と定着化のコツセミナー資料SFA運用の秘訣と定着化のコツセミナー資料
SFA運用の秘訣と定着化のコツセミナー資料NetyearGroup
 
広告効果測定&解析ツールを使って広告Roiを最大化する運用方法
広告効果測定&解析ツールを使って広告Roiを最大化する運用方法広告効果測定&解析ツールを使って広告Roiを最大化する運用方法
広告効果測定&解析ツールを使って広告Roiを最大化する運用方法Ryoma Hosokawa
 
財務分析勉強会挨拶
財務分析勉強会挨拶財務分析勉強会挨拶
財務分析勉強会挨拶oranie Narut
 
お客様とコードの間
お客様とコードの間お客様とコードの間
お客様とコードの間Moriyuki Hirata
 
アジャイルツアー大阪
アジャイルツアー大阪アジャイルツアー大阪
アジャイルツアー大阪Tsuyoshi Ushio
 
夏サミ 2013 基調講演 長沢パート資料 #natsumiS1
夏サミ 2013 基調講演 長沢パート資料 #natsumiS1夏サミ 2013 基調講演 長沢パート資料 #natsumiS1
夏サミ 2013 基調講演 長沢パート資料 #natsumiS1智治 長沢
 
Ci&T Anti-Software Factory Pattern
Ci&T Anti-Software Factory PatternCi&T Anti-Software Factory Pattern
Ci&T Anti-Software Factory PatternYoshiyuki Ueda
 

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

using astah for openthology modeling
using astah for openthology modelingusing astah for openthology modeling
using astah for openthology modeling
 
20130928 dev opsday_tokyo
20130928 dev opsday_tokyo20130928 dev opsday_tokyo
20130928 dev opsday_tokyo
 
Introduction of KOTATSU-MODEL in Requirement Development
Introduction of KOTATSU-MODEL in Requirement DevelopmentIntroduction of KOTATSU-MODEL in Requirement Development
Introduction of KOTATSU-MODEL in Requirement Development
 
Application System導入価値を取り戻す“測る化”とは
Application System導入価値を取り戻す“測る化”とはApplication System導入価値を取り戻す“測る化”とは
Application System導入価値を取り戻す“測る化”とは
 
Meta Service Design
Meta Service DesignMeta Service Design
Meta Service Design
 
これからの開発環境の話をしよう - 開発現場力を高める環境づくり #ost2013
これからの開発環境の話をしよう - 開発現場力を高める環境づくり #ost2013これからの開発環境の話をしよう - 開発現場力を高める環境づくり #ost2013
これからの開発環境の話をしよう - 開発現場力を高める環境づくり #ost2013
 
Tcアドバイザリー業務の7ケース
Tcアドバイザリー業務の7ケースTcアドバイザリー業務の7ケース
Tcアドバイザリー業務の7ケース
 
アドバイザリー業務:7つのケース(事例)
アドバイザリー業務:7つのケース(事例)アドバイザリー業務:7つのケース(事例)
アドバイザリー業務:7つのケース(事例)
 
最新事例にみるサービスデザインという新潮流(I・CON2014)
最新事例にみるサービスデザインという新潮流(I・CON2014)最新事例にみるサービスデザインという新潮流(I・CON2014)
最新事例にみるサービスデザインという新潮流(I・CON2014)
 
Vantan shinsuke miyaki_upload
Vantan shinsuke miyaki_uploadVantan shinsuke miyaki_upload
Vantan shinsuke miyaki_upload
 
SFA運用の秘訣と定着化のコツセミナー資料
SFA運用の秘訣と定着化のコツセミナー資料SFA運用の秘訣と定着化のコツセミナー資料
SFA運用の秘訣と定着化のコツセミナー資料
 
事業開発メソッド
事業開発メソッド 事業開発メソッド
事業開発メソッド
 
広告効果測定&解析ツールを使って広告Roiを最大化する運用方法
広告効果測定&解析ツールを使って広告Roiを最大化する運用方法広告効果測定&解析ツールを使って広告Roiを最大化する運用方法
広告効果測定&解析ツールを使って広告Roiを最大化する運用方法
 
関西バランス・スコアカード研究会 資料
関西バランス・スコアカード研究会 資料関西バランス・スコアカード研究会 資料
関西バランス・スコアカード研究会 資料
 
財務分析勉強会挨拶
財務分析勉強会挨拶財務分析勉強会挨拶
財務分析勉強会挨拶
 
お客様とコードの間
お客様とコードの間お客様とコードの間
お客様とコードの間
 
アジャイルツアー大阪
アジャイルツアー大阪アジャイルツアー大阪
アジャイルツアー大阪
 
夏サミ 2013 基調講演 長沢パート資料 #natsumiS1
夏サミ 2013 基調講演 長沢パート資料 #natsumiS1夏サミ 2013 基調講演 長沢パート資料 #natsumiS1
夏サミ 2013 基調講演 長沢パート資料 #natsumiS1
 
Ci&T Anti-Software Factory Pattern
Ci&T Anti-Software Factory PatternCi&T Anti-Software Factory Pattern
Ci&T Anti-Software Factory Pattern
 
Tech stars
Tech starsTech stars
Tech stars
 

More from Itsuki Kuroda

カネとAgile #RSGT2018
カネとAgile #RSGT2018カネとAgile #RSGT2018
カネとAgile #RSGT2018Itsuki Kuroda
 
日経BPリーン式創業塾 #leanstartup #リーンスタートアップ
日経BPリーン式創業塾 #leanstartup #リーンスタートアップ日経BPリーン式創業塾 #leanstartup #リーンスタートアップ
日経BPリーン式創業塾 #leanstartup #リーンスタートアップItsuki Kuroda
 
エンジニアが成長のエンジンになる日 #devsumi #natsumiC7
エンジニアが成長のエンジンになる日 #devsumi  #natsumiC7エンジニアが成長のエンジンになる日 #devsumi  #natsumiC7
エンジニアが成長のエンジンになる日 #devsumi #natsumiC7Itsuki Kuroda
 
LEANSTARTUPの現場 #leanstartup
LEANSTARTUPの現場 #leanstartupLEANSTARTUPの現場 #leanstartup
LEANSTARTUPの現場 #leanstartupItsuki Kuroda
 
リーンスタートアップ概論
リーンスタートアップ概論リーンスタートアップ概論
リーンスタートアップ概論Itsuki Kuroda
 
社内スタートアップによる組織の成長に伴い発生する痛みとその解決策について(Rebuild) #devlove
社内スタートアップによる組織の成長に伴い発生する痛みとその解決策について(Rebuild) #devlove 社内スタートアップによる組織の成長に伴い発生する痛みとその解決策について(Rebuild) #devlove
社内スタートアップによる組織の成長に伴い発生する痛みとその解決策について(Rebuild) #devlove Itsuki 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
 
社内スタートアップによる組織の成長に伴い発生する痛みとその解決策(スクラム&リーンスタートアップ導入)について #devlove #devlove創
社内スタートアップによる組織の成長に伴い発生する痛みとその解決策(スクラム&リーンスタートアップ導入)について #devlove #devlove創社内スタートアップによる組織の成長に伴い発生する痛みとその解決策(スクラム&リーンスタートアップ導入)について #devlove #devlove創
社内スタートアップによる組織の成長に伴い発生する痛みとその解決策(スクラム&リーンスタートアップ導入)について #devlove #devlove創Itsuki 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
 
Play勉強会資料(MTLブログ用)
Play勉強会資料(MTLブログ用)Play勉強会資料(MTLブログ用)
Play勉強会資料(MTLブログ用)Itsuki Kuroda
 
女子中高生とTwitter4J #twtr_hack
女子中高生とTwitter4J #twtr_hack女子中高生とTwitter4J #twtr_hack
女子中高生とTwitter4J #twtr_hackItsuki Kuroda
 
学生向けAndroid勉強会(入門編)
学生向けAndroid勉強会(入門編)学生向けAndroid勉強会(入門編)
学生向けAndroid勉強会(入門編)Itsuki Kuroda
 
Nfcハッカソン発表資料
Nfcハッカソン発表資料Nfcハッカソン発表資料
Nfcハッカソン発表資料Itsuki Kuroda
 

More from Itsuki Kuroda (13)

カネとAgile #RSGT2018
カネとAgile #RSGT2018カネとAgile #RSGT2018
カネとAgile #RSGT2018
 
日経BPリーン式創業塾 #leanstartup #リーンスタートアップ
日経BPリーン式創業塾 #leanstartup #リーンスタートアップ日経BPリーン式創業塾 #leanstartup #リーンスタートアップ
日経BPリーン式創業塾 #leanstartup #リーンスタートアップ
 
エンジニアが成長のエンジンになる日 #devsumi #natsumiC7
エンジニアが成長のエンジンになる日 #devsumi  #natsumiC7エンジニアが成長のエンジンになる日 #devsumi  #natsumiC7
エンジニアが成長のエンジンになる日 #devsumi #natsumiC7
 
LEANSTARTUPの現場 #leanstartup
LEANSTARTUPの現場 #leanstartupLEANSTARTUPの現場 #leanstartup
LEANSTARTUPの現場 #leanstartup
 
リーンスタートアップ概論
リーンスタートアップ概論リーンスタートアップ概論
リーンスタートアップ概論
 
社内スタートアップによる組織の成長に伴い発生する痛みとその解決策について(Rebuild) #devlove
社内スタートアップによる組織の成長に伴い発生する痛みとその解決策について(Rebuild) #devlove 社内スタートアップによる組織の成長に伴い発生する痛みとその解決策について(Rebuild) #devlove
社内スタートアップによる組織の成長に伴い発生する痛みとその解決策について(Rebuild) #devlove
 
Let's design MVP #devlove #leanstartup
Let's design MVP #devlove #leanstartupLet's design MVP #devlove #leanstartup
Let's design MVP #devlove #leanstartup
 
社内スタートアップによる組織の成長に伴い発生する痛みとその解決策(スクラム&リーンスタートアップ導入)について #devlove #devlove創
社内スタートアップによる組織の成長に伴い発生する痛みとその解決策(スクラム&リーンスタートアップ導入)について #devlove #devlove創社内スタートアップによる組織の成長に伴い発生する痛みとその解決策(スクラム&リーンスタートアップ導入)について #devlove #devlove創
社内スタートアップによる組織の成長に伴い発生する痛みとその解決策(スクラム&リーンスタートアップ導入)について #devlove #devlove創
 
Social.framework&Account.framework #twtr_hack
Social.framework&Account.framework #twtr_hackSocial.framework&Account.framework #twtr_hack
Social.framework&Account.framework #twtr_hack
 
Play勉強会資料(MTLブログ用)
Play勉強会資料(MTLブログ用)Play勉強会資料(MTLブログ用)
Play勉強会資料(MTLブログ用)
 
女子中高生とTwitter4J #twtr_hack
女子中高生とTwitter4J #twtr_hack女子中高生とTwitter4J #twtr_hack
女子中高生とTwitter4J #twtr_hack
 
学生向けAndroid勉強会(入門編)
学生向けAndroid勉強会(入門編)学生向けAndroid勉強会(入門編)
学生向けAndroid勉強会(入門編)
 
Nfcハッカソン発表資料
Nfcハッカソン発表資料Nfcハッカソン発表資料
Nfcハッカソン発表資料
 

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