SlideShare a Scribd company logo
1 of 114
Download to read offline
大企業アジャ
イルの勘所
黒田 樹 @i2key
#DX時代のアジャイルマネジメントセミナー
これから話すこと
前提と制約を意識し
アウトカム最大化にフォーカスした
生産ラインを確立すること
= プログラムマネジメント的営み
課題感
課題感:「アジャイル」へのイメージ(大きな企業目線)
• 本に書いてあるようなスモールチームの状況を作ることが難しく、どうしても、現場と本
の世界の間に乖離が生まれる。(コンテキスト情報をなくして汎化するため仕方がない
が。)
• 制約のない理想のキレイな状態(制約が少ない世界の話)で語られがちであり、実際の現
場との乖離が激しすぎてどう登っていいのか困る初見殺し感とそれによる死に覚えゲー
感。
• 海外のほげほげ大企業でも出来てます。といわれても遠い世界の話にしか聞こえない。
• アウトカムにフォーカスしていない。ビジネス目的やKPIベースで語られずに、「価値」
あるソフトウェアみたいな表現の解像度で止まっていて、説明責任を果たせない。果たす
のが難しい。で、どういう構造でビジネスに寄与するの?が大切なのにプラクティスに終
始しがち。
• Be Agileという割には、Do Agileの話をよく見かける。本質が見えにくい。
本では制約や前提を整えてアジリティ高い状態に持っていく座組づくりについては触れられていない
制約や前提の存在しないコンテキスト 制約や前提のが大量に存在するコンテキスト
スモールチーム
アジャイルな状態
スモールチーム
アジャイルな状態
できない制約・前提
できない制約・前提
難しい制約・前提
難しい制約・前提
本に書いてある世界
制約の破壊の仕方
はあまり語られない
本では制約や前提を整えてアジリティ高い状態に持っていく座組づくりについては触れられていない
制約や前提の存在しないコンテキスト 制約や前提のが大量に存在するコンテキスト
スモールチーム
アジャイルな状態
スモールチーム
アジャイルな状態
できない制約・前提
できない制約・前提
難しい制約・前提
本に書いてある世界
制約の破壊の仕方
はあまり語られない
達人「場合による」
難しい制約・前提
Be Agile
本では制約や前提を整えてアジリティ高い状態に持っていく座組づくりについては触れられていない
制約や前提の存在しないコンテキスト 制約や前提のが大量に存在するコンテキスト
スモールチーム
アジャイルな状態
スモールチーム
アジャイルな状態
できない制約・前提
できない制約・前提
難しい制約・前提
本に書いてある世界
制約の破壊の仕方
はあまり語られない
難しい制約・前提
Be Agile
いやいや、こここそ大事でしょ
大企業&既存事業
大企業&新規事業
大企業&既存事業
ビジネス構造の理解
大企業における既存事業の場合
既存事業におけるビジネス構造の理解
全体的に10年くらい前に、紙→WEB化(DX?)している。
クライアント
様向け画面
アルバイト先を
探している人
アルバイトを
募集している企業
既存事業におけるビジネス構造の理解
クライアント
様向け画面
商品開発
サイト改善 サイト改善
求人情報に対するコンバージョンレートの向上
UI/UXの継続的改善(仮説検証型)
求人情報の出向枠の追加
掲載期間、掲載形式等の商品に関する開発
(営業広報あるため計画駆動、シッカリカッチリ)
既存事業におけるビジネス構造の理解
SoR
Bimodal IT Mode1 Mode2
正式名称 System of Record(SoR) System of Engagement(SoE)
適正
基幹系・勘定系、
ミッションクリティカルな機能・システム
(決済システム、顧客管理等)
正解が無い中、柔軟に変化をしながら走り続ける必要がある機
能・サービス
(スマホアプリ、ウェブサービスのフロント)
目的
信頼性、安定性
定めた仕様に従って安定性や品質を担保しながら開発して
いく必要がある
俊敏性、速度
フィードバックに基づいて速やかに改善を加え、頻繁にリリー
スする
価値・評価 費用対効果、コスト 売上、ブランド、UX
アプローチ ウォーターフォール、V-model、重量IID アジャイル、リーン、カンバン、軽量IID
調達
エンタープライズサプライヤー、
長期的な取引 小さい、新しいベンダー、短期間の取引
メンバ適正 従来のプロセス、プロジェクトが得意 新しくて不確実なプロジェクトが得意
組織/文化 開発部門・計画型 ビジネス&開発混在・探索型
サイクルタイム 数ヶ月 数日、数週間
SoE
計画型
シッカリカッチリ
探索型
速さ、柔軟さ
クライアント
様向け画面
商品開発
サイト改善 サイト改善
求人情報に対するコンバージョンレートの向上
UI/UXの継続的改善(仮説検証型)
求人情報の出向枠の追加
掲載期間、掲載形式等の商品に関する開発
(営業広報あるため計画駆動、シッカリカッチリ)
SoR
SoE SoE
タウンワーク
FromA Navi
はたらいく
とらばーゆ
入稿システム
応募管理
システム
タウンワーク
FromA Navi
はたらいく
とらばーゆ
入稿システム
応募管理
システム
商品開発
求人情報の出稿枠の追加
掲載期間、掲載形式等の商品に関する開発
(営業広報あるため計画駆動、シッカリカッチリ)
タウンワーク
FromA Navi
はたらいく
とらばーゆ
入稿システム
応募管理
システム
サイト改善
求人情報に対するコンバージョンレートの向上
UI/UXの継続的改善(仮説検証型)
エンジニアリングによる
事業価値の最大化
大企業における既存事業の場合
機能やUI/UXは事業価値(アクション数、etc)ではない。事業価値をうみだす装置である。
つまり、リリースするまでは何も価値をうみださない。使われることで事業価値に変換されていく。
そのため、リリース後に安定的に事業価値をうみだしつづけることが大事。
※リリース毎に確実に価値が積み上がるわけではないが、説明をシンプルにするために以下のように表現している。
Now
過去 未来
開発して未来に
積み上げる資産
事業価値
(KPI、etc)
過去に開発して
積み上げた資産
リリース
リリース
リリース
リリース予定
リリース予定
初期開発
エンハンス
エンハンス
エンハンス
エンハンス
時間
機能やUI/UXは事業価値(アクション数、etc)ではない。事業価値をうみだす装置である。
つまり、リリースするまでは何も価値をうみださない。使われることで事業価値に変換されていく。
そのため、リリース後に安定的に事業価値をうみだしつづけることが大事。
※リリース毎に確実に価値が積み上がるわけではないが、説明をシンプルにするために以下のように表現している。
Now
過去 未来
開発して未来に
積み上げる資産
事業価値
(KPI、etc)
過去に開発して
積み上げた資産
リリース
リリース
リリース
リリース予定
リリース予定
初期開発
エンハンス
エンハンス
エンハンス
エンハンス
時間
なので、グラフの面積を最大化することが事業貢献している状態をさす。
青い太線よりも赤い太線のほうが事業貢献度が高い。
Now
過去 未来
開発して未来に
積み上げる資産
事業価値
(KPI、etc)
過去に開発して
積み上げた資産
リリース
リリース
リリース
リリース予定
リリース予定
初期開発
エンハンス
エンハンス
エンハンス
エンハンス
この事業価値をうみだす装置の性能を上げるため(積分値を最大化)に出来ることは基本的には以下。
①価値が生まれるまでの時間を短くする。②生まれる価値を上げる。(開発)
③障害等で価値をうめなくなっている部分の最小化。④将来発生する③の防止。(安定稼働)
②効果を上げる
①速くする
③価値をうめな
くなっている部
分の最小化
④未来の価値毀損
の防止
③
④
時間
Now
過去 未来
開発して未来に
積み上げる資産
事業価値
(KPI、etc)
過去に開発して
積み上げた資産
リリース
リリース
リリース
リリース予定
初期開発
エンハンス①
エンハンス②
エンハンス③
エンハンス④
技術的負債とは何か。事業価値をうみだすまでのリードタイムという側面からみると以下の理解。
基本的に技術的負債は再び負債が埋め込まれたコードに来たとき(変更、調査、etc)に必要以上の工数、
言い換えるとリードタイムを悪化させるものである。例えば、以下のエンハンス①にてHoge.method()に
埋め込んでしまった技術的負債は、エンハンス③にてエンハンス期間を悪化させる作用がある。
リファクタリングはこれを除去する行為であり、リードタイム改善に寄与する場合もある。
時間
Hoge.method()
Hoge.method()
同じ規模感のエンハンスであったにしろ、
エンハンス③はより作業が発生してしまう
Now
過去 未来
開発して未来に
積み上げる資産
事業価値
(KPI、etc)
過去に開発して
積み上げた資産
リリース
リリース
リリース
リリース予定
初期開発
エンハンス①
エンハンス②
エンハンス④
技術的負債とは何か。新たに新商品を実装する場合に、各種サブシステム間におけるデータ連携のための
バッチを作ることが多い。しかしながら相互に依存するバッチ性能が悪いコードが事前に埋め込まれって
しまった場合、制限時間内(入稿から翌朝の掲載までの猶予時間)に処理が終わらせることが出来ず、
新商品を追加出来ない場合がある。結果として事業価値をこれ以上積み上げることが出来ない制約になる。
時間
リソース食い尽くすバッチが仕込まれる
エンハンス③
事業価値を積み上げられない
Now
過去 未来
開発して未来に
積み上げる資産
事業価値
(KPI、etc)
過去に開発して
積み上げた資産
リリース
リリース
リリース
リリース予定
初期開発
エンハンス
DevOpsとは何か。DevOpsは高品質を保ちつつ、システムに変更をコミットしてから、その変更が
本番システムに組み込まれるまでの時間を短縮することを目的とした一連の実践である。
CI/CD等の活用、監視による早期検知、インフラコード化、etc、フィードバックループを高速で回すことでの
コンセプトが事業価値になるまでのリードタイムの短縮に寄与する活動そのものである。
時間
エンハンス
エンハンス
エンハンス
①From concept To Cashのリードタイム削減
③障害の早期検知
③
Now
過去 未来
開発して未来に
積み上げる資産
事業価値
(KPI、etc)
過去に開発して
積み上げた資産
リリース
リリース
リリース
リリース予定
初期開発
アジャイルとは何か。事業価値の軸で見ると、小さく価値を積み上げていく開発思想。小さなロットの開発
を繰り返し一定のペースで行い、一定のペースでリリースしていくことでフィードバックループを高速に回す
ひとつの考え方。早期に失敗できるために、手戻りコストを最小化している。後述するフロー効率に特化して
いる。よくウォーターフォールと敵対関係で述べられることが多いが、本質的には、How Little OR How Much
どちらのやり方が事業スループットを上げられるかでしかないので、効率のよいようにやればよいと思う。
時間
エンハンス
エンハンス
リリース
リリース
リリース
リリース予定
リリース予定
リリース予定
エンハンス
エンハンス
エンハンス
エンハンス
エンハンス
エンハンス
エンハンス
Now
過去 未来
事業価値
(KPI、etc)
リリース
リリース
リリース予定
リリース予定
初期開発
エンハンス開発
エンハンス開発
時間
エンハンス開発
リリース
リリース
エンハンス開発
リリース予定
エンハンス開発
エンハンス開発
作らず検証
作らず検証
現実世界に照らし合わせると、大小様々な大きさの開発が存在する。並走することもあるし、シーケンシャル
に開発されることもある。作ってから市場に問う場合もあるし、作る前に市場に問う場合もある。
それはビジネス上の文脈に強く依存するため、一概にこうすれば良いというものは存在しない。
しかしながら、唯一あることは、これは事業なので、事業アウトカムを効率よく最大化することである。
ここでいう、帯部分の面積の積み上がりの最大化である。不確実な状況において大きくフルスイングして
リターンが無いという状況は最も非効率である。逆に不確実でないならフルスイングも選択肢に入る。
Now
過去 未来
事業価値
(KPI、etc)
リリース
リリース
リリース予定
リリース予定
初期開発
エンハンス開発
エンハンス開発
時間
エンハンス開発
リリース
リリース
エンハンス開発
リリース予定
エンハンス開発
エンハンス開発
作らず検証
作らず検証
営業がクライアントに売るような商品は一度
売ってしまうと切り戻し不可能なため、作る前
に商品のビジネスリスクを最小化するための検
証が行われる。具体的には、システム化せずエ
リア限定での販売実験をしてみる等。つまり開
発に入る段階においてビジネス上のリスク(不
確実性)はある程度潰されている状態になる。
また、システム上も入稿から効果系まで複数の
サブシステムを跨るため、開発規模も比較的大
きくなる。
Now
過去 未来
事業価値
(KPI、etc)
リリース
リリース
リリース予定
リリース予定
初期開発
エンハンス開発
エンハンス開発
時間
エンハンス開発
リリース
リリース
エンハンス開発
リリース予定
エンハンス開発
エンハンス開発
作らず検証
作らず検証
サイト上のコンバージョンレートの向上のよう
なUI/UX改善による○○率UP系開発は、開発前に
工数をかけて不確実性を下げる検証をするより
も、実際にユーザーに利用してもらいフィード
バックを得るほうが効率が良いため、小さくつ
くりABテストで学ぶ。開発に入る段階において
ビジネス上のリスク(不確実性)は潰されてい
ないため、切り戻す単位を最小化するために小
さく実装・実験する。結果的に小さい開発規模
の実験を大量に回すことになる。
フロー効率とリソース効率
Appendix
検索条件
入力画面
検索結果
一覧画面
詳細画面 予約画面
口コミ
SEO
SEM
ETC
サービス
トップ
画面
if(isBooked){
}
口コミ
SEO
SEM
ETC
掲載枠
検索
¥0
利用者 クライアント
広告
ビジネス
CVR改善 = 売上直結
例:CVR最大化に向けたUI/UX仮説検証
流入数
検索条件
入力画面
検索結果
一覧画面
詳細画面 予約画面
口コミ
SEO
SEM
ETC
サービス
トップ
画面
if(isBooked){
}
口コミ
SEO
SEM
ETC
掲載枠
検索
¥0
利用者 クライアント
CVR改善 = 売上直結
タウンワークにおけるUI/UX仮説検証
流入数
アウトカム
アウトカム
掲載料
1st week 2nd week 3rd week 4th week 5th week 6th week 7th week
1st week 2nd week 3rd week 4th week 5th week 6th week 7th week
CVR
CVR
±0 ±0 ±0 ±0 ±0 ±0 +3
±0 ±0 +1 +1 +1
+1 +1
±0 ±0 +1 +1
+1
±0 ±0
±0 ±0 +1
±0 ±0 ±0 ±0
売上
or
KPI
売上
or
KPI
release
A
B
C
0
0.75
1.5
2.25
3
1st week 2nd week 3rd week 4th week 5th week 6th week 7th week
0
0.75
1.5
2.25
3
1st week 2nd week 3rd week 4th week 5th week 6th week 7th week
複数のことをまとめて開発したときのビジネス上の実利
A
B
C
1つずつ開発してリリースしていくときのビジネス上の実利
複数のことをまとめて開発したときのビジネス上の実利
1つずつ開発してリリースしていくときのビジネス上の実利
1st week 2nd week 3rd week 4th week 5th week 6th week 7th week
1st week 2nd week 3rd week 4th week 5th week 6th week 7th week
CVR
CVR
±0 ±0 ±0 ±0 ±0 ±0 +3
±0 ±0 +1 +1 +1
+1 +1
±0 ±0 +1 +1
+1
±0 ±0
±0 ±0 +1
±0 ±0 ±0 ±0
売上
or
KPI
売上
or
KPI
release
A
B
C
0
0.75
1.5
2.25
3
1st week 2nd week 3rd week 4th week 5th week 6th week 7th week
0
0.75
1.5
2.25
3
1st week 2nd week 3rd week 4th week 5th week 6th week 7th week
A
B
C
学んでいない期間
稼いでいない期間
学んでいない期間
稼いでいない期間
オーバーヘッドで
若干合計稼働は増える
複数の実験を
同時にやると濁る
1つのリソースを稼働率が100%になるまで分配する
例
・マルチタスク
・大きなウォーターフォール型開発
A B C
Resource
流れる対象
30%
30% 40%
リソース稼働率:100%
(作業時間を絞り出す量を最大化)
1リソースに
フォーカスする
流れる対象 流れる対象
リソース効率性
A
Resource
流れる対象
流れる対象(タスク)が得られるリソースの時間を最大化する
流れる対象に
フォーカスする
Resource Resource
例
・ペアプログラミング/モブプログラミング
・クロスファンクショナルチーム
・システム障害発生時の動き
フロー効率性
リソース効率性とフロー効率性
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
C C C
C C C
C C C
月 火 水 木 金 月 火 水 木 金 月 火 水 木 金
月 火 水 木 金 月 火 水 木 金 月 火 水 木 金
リリースまでのリードタイム 1w
リリースまでのリードタイム 約2w
リリースまでのリードタイム 3w
リリースまでのリードタイム 3w
リリースまでのリードタイム 3w
A機能、B機能、C機能の実装それぞれ15人日かかる場合
A
A
A
B B
B B
B B
1st week 2nd week 3rd week 4th week 5th week 6th week 7th week
1st week 2nd week 3rd week 4th week 5th week 6th week 7th week
CVR
CVR
±0 ±0 ±0 ±0 ±0 ±0 +3
±0 ±0 +1 +1 +1
+1 +1
±0 ±0 +1 +1
+1
±0 ±0
±0 ±0 +1
±0 ±0 ±0 ±0
売上
or
KPI
売上
or
KPI
release
A
B
C
0
0.75
1.5
2.25
3
1st week 2nd week 3rd week 4th week 5th week 6th week 7th week
0
0.75
1.5
2.25
3
1st week 2nd week 3rd week 4th week 5th week 6th week 7th week
リソース効率を重視して開発した場合
A
B
C
フロー効率を重視して開発した場合
開発予算ポートフォリオから
自治権を実装する
(生産ラインの外形を作る)
大企業における既存事業の場合
クライアント
様向け画面
商品開発
サイト改善 サイト改善
求人情報に対するコンバージョンレートの向上
UI/UXの継続的改善(仮説検証型)
グロースハック
求人情報の出向枠の追加
掲載期間、掲載形式等の商品に関する開発
(営業広報あるため計画駆動、シッカリカッチリ)
SoR
SoE SoE
Now
過去 未来
事業価値
(KPI、etc)
リリース
リリース
リリース予定
リリース予定
初期開発
エンハンス開発
エンハンス開発
時間
エンハンス開発
リリース
リリース
エンハンス開発
リリース予定
エンハンス開発
エンハンス開発
作らず検証
作らず検証
現実世界に照らし合わせると、大小様々な大きさの開発が存在する。並走することもあるし、シーケンシャル
に開発されることもある。作ってから市場に問う場合もあるし、作る前に市場に問う場合もある。
それはビジネス上の文脈に強く依存するため、一概にこうすれば良いというものは存在しない。
しかしながら、唯一あることは、これは事業なので、事業アウトカムを効率よく最大化することである。
ここでいう、帯部分の面積の積み上がりの最大化である。不確実な状況において大きくフルスイングして
リターンが無いという状況は最も非効率である。逆に不確実でないならフルスイングも選択肢に入る。
Now
過去 未来
事業価値
(KPI、etc)
リリース
リリース
リリース予定
リリース予定
初期開発
エンハンス開発
エンハンス開発
時間
エンハンス開発
リリース
リリース
エンハンス開発
リリース予定
エンハンス開発
エンハンス開発
作らず検証
作らず検証
現実世界に照らし合わせると、大小様々な大きさの開発が存在する。並走することもあるし、シーケンシャル
に開発されることもある。作ってから市場に問う場合もあるし、作る前に市場に問う場合もある。
それはビジネス上の文脈に強く依存するため、一概にこうすれば良いというものは存在しない。
しかしながら、唯一あることは、これは事業なので、事業アウトカムを効率よく最大化することである。
ここでいう、帯部分の面積の積み上がりの最大化である。不確実な状況において大きくフルスイングして
リターンが無いという状況は最も非効率である。逆に不確実でないならフルスイングも選択肢に入る。
サイト改善
サイト改善
クルクル仮説検証
クルクル仮説検証
Now
過去 未来
事業価値
(KPI、etc)
リリース
リリース
リリース予定
リリース予定
初期開発
エンハンス開発
エンハンス開発
時間
エンハンス開発
リリース
リリース
エンハンス開発
リリース予定
エンハンス開発
エンハンス開発
作らず検証
作らず検証
現実世界に照らし合わせると、大小様々な大きさの開発が存在する。並走することもあるし、シーケンシャル
に開発されることもある。作ってから市場に問う場合もあるし、作る前に市場に問う場合もある。
それはビジネス上の文脈に強く依存するため、一概にこうすれば良いというものは存在しない。
しかしながら、唯一あることは、これは事業なので、事業アウトカムを効率よく最大化することである。
ここでいう、帯部分の面積の積み上がりの最大化である。不確実な状況において大きくフルスイングして
リターンが無いという状況は最も非効率である。逆に不確実でないならフルスイングも選択肢に入る。
商品開発
商品開発
シッカリかっちり
シッカリかっちり
マーケ組織 商品企画組織 営業組織 データ系組織
プロダクト開発組織
プロダクトオーナー
プロジェクト(WF) スクラム or カンバン スクラム or カンバン
アーキテクト
プロダクトオーナー
プロキシー
プロダクトオーナー
プロキシー
プロジェクトリーダー
スクラムマスター
○○○○○
XXXXXX
△△△△△
○○○○○
プロダクトオーナー
プロキシー
○○○○○
XXXXXX
△△△△△
○○○○○
○○○○○
XXXXXX
△△△△△
○○○○○
エンジニア
エンジニア
エンジニア
:
エンジニア x N人
UI/UXデザイナー
スクラムマスター
エンジニア
エンジニア
エンジニア
:
SoR SoE SoE
カンバン
○○○○○
XXXXXX
△△△△△
○○○○○
エンジニア
エンジニア
エンジニア
:
安定稼働、アーキ
(組織的ゆとり)
グロースハックチーム
商品開発チーム
障害対応/SRE
マーケ・プロモ
法令・要請
商品開発(掲載枠等)
グロースハック
(UI/UX改善)
4月 7月 10月 1月
予算
Time
投資ポートフォリオとエンジニアチーム構成の関係
年次の予算計画
1年分の活動予算
障害対応/SRE
マーケ・プロモ
法令・要請
商品開発(掲載枠等)
グロースハック
(UI/UX改善)
4月 7月 10月 1月
予算
Time
投資ポートフォリオとエンジニアチーム構成の関係
責務:コンバージョン率UP
予算ロック & 納期柔軟
責務:売上 + α
予算ロック & 納期コミット
責務:安定稼働 + アーキテクト
予算ロック & 納期柔軟
障害対応/SRE
マーケ・プロモ
法令・要請
商品開発(掲載枠等)
グロースハック
(UI/UX改善)
4月 7月 10月 1月
予算
Time
投資ポートフォリオとエンジニアチーム構成の関係
責務:コンバージョン率UP
予算ロック & 納期柔軟
責務:売上 + α
予算ロック & 納期コミット
責務:安定稼働 + アーキテクト
予算ロック & 納期柔軟
グロースハックチーム
商品開発チーム
安定稼働チーム
障害対応/SRE
マーケ・プロモ
法令・要請
商品開発(掲載枠等)
グロースハック
(UI/UX改善)
4月 7月 10月 1月
予算
Time
投資ポートフォリオとエンジニアチーム構成の関係
責務:コンバージョン率UP
予算ロック & 納期柔軟
責務:売上 + α
予算ロック & 納期コミット
責務:安定稼働 + アーキテクト
予算ロック & 納期柔軟
グロースハックチーム
商品開発チーム
安定稼働チーム
予算枠 目的&責任
チーム
予算:目的:責任:チームが1対1の状態
投資側からすれば目
的が達成できればよ
いのでHOWは自由。
あとは任せた!
→チームに自治権
→現場裁量で推進
→精神論ではなく構
造的アプローチによ
る自己組織化
障害対応/SRE
マーケ・プロモ
法令・要請
商品開発(掲載枠等)
グロースハック
(UI/UX改善)
4月 7月 10月 1月
予算
Time
投資ポートフォリオとエンジニアチーム構成の関係
責務:コンバージョン率UP
予算ロック & 納期柔軟
責務:売上 + α
予算ロック & 納期コミット
責務:安定稼働 + アーキテクト
予算ロック & 納期柔軟
グロースハックチーム
商品開発チーム
安定稼働チーム
予算枠 目的&責任
チーム アーキテクチャ
(余談)マイクロサービス
予算:目的:責任:チームが1対1の状態
障害対応/SRE
マーケ・プロモ
法令・要請
商品開発(掲載枠等)
グロースハック
(UI/UX改善)
4月 7月 10月 1月
予算
Time
投資ポートフォリオとエンジニアチーム構成の関係
責務:コンバージョン率UP
予算ロック & 納期柔軟
責務:売上 + α
予算ロック & 納期コミット
責務:安定稼働 + アーキテクト
予算ロック & 納期柔軟
グロースハックチーム
商品開発チーム
安定稼働チーム
予算枠 目的&責任
チーム
予算:目的:責任:チームが1対1の状態
予算枠 目的&責任
チーム
予算枠
目的&責任
チーム
障害対応/SRE
マーケ・プロモ
法令・要請
商品開発(掲載枠等)
グロースハック
(UI/UX改善)
4月 7月 10月 1月
予算
Time
投資ポートフォリオとエンジニアチーム構成の関係
予算枠
目的① チーム
例えば、予算枠とチームが目的単位でない場合
目的②
投資目的が混ざるの
で、優先順位付けにお
いて、一つ上位レイ
ヤーの意思決定お伺い
が発生するかもしれな
い。
→現場で決めれない
→現場に自治権がない
障害対応/SRE
マーケ・プロモ
法令・要請
商品開発(掲載枠等)
グロースハック
(UI/UX改善)
4月 7月 10月 1月
予算
Time
投資ポートフォリオとエンジニアチーム構成の関係
責務:コンバージョン率UP
予算ロック & 納期柔軟
責務:売上 + α
予算ロック & 納期コミット
責務:安定稼働 + アーキテクト
予算ロック & 納期柔軟
グロースハックチーム
商品開発チーム
安定稼働チーム
=>フロー効率重視
=>リソース効率重視
=>組織的「ゆとり」
障害対応/SRE
マーケ・プロモ
法令・要請
商品開発(掲載枠等)
グロースハック
(UI/UX改善)
4月 7月 10月 1月
予算
Time
投資ポートフォリオとエンジニアチーム構成の関係
責務:コンバージョン率UP
予算ロック & 納期柔軟
責務:売上 + α
予算ロック & 納期コミット
責務:安定稼働 + アーキテクト
予算ロック & 納期柔軟
グロースハックチーム
商品開発チーム
安定稼働チーム
=>フロー効率重視
=>リソース効率重視
=>組織的「ゆとり」
複数のことをまとめてV字
モデルでやる
(ウォーターフォール?)
一個ずつV字モデルでやる
(アジャイル?カンバン?
スクラム?それ系のやつ)
「ゆとり」を投資して効率
化で「ゆとり」をつくる
マーケ組織 商品企画組織 営業組織 データ系組織
プロダクト開発組織
プロダクトオーナー
プロジェクト(WF) スクラム or カンバン スクラム or カンバン
アーキテクト
プロダクトオーナー
プロキシー
プロダクトオーナー
プロキシー
プロジェクトリーダー
スクラムマスター
○○○○○
XXXXXX
△△△△△
○○○○○
プロダクトオーナー
プロキシー
○○○○○
XXXXXX
△△△△△
○○○○○
○○○○○
XXXXXX
△△△△△
○○○○○
エンジニア
エンジニア
エンジニア
:
エンジニア x N人
UI/UXデザイナー
スクラムマスター
エンジニア
エンジニア
エンジニア
:
リソース効率 フロー効率 フロー効率
カンバン
○○○○○
XXXXXX
△△△△△
○○○○○
エンジニア
エンジニア
エンジニア
:
安定稼働、アーキ
(組織的ゆとり)
グロースハックチーム
商品開発チーム
スモールチーム
アジャイルな状態
できない制約・前提
できない制約・前提
難しい制約・前提
難しい制約・前提
結果的に特定の数値に責任と権限を持ったスモールチームになる
ここからが本に書いてある世界
ここからアジャイルコーチ的な人の出番?
ここまで座組を整えないと、ただ現場でもがくだけになり非効率
根雪構造でビジネス
成果が積み上がる部分を
スコープとする
予算と目的と責任と権限
とチームを1:1にして、
チームに自治権を与える
SoEを対象とする
スモールチーム
アジャイルな状態
できない制約・前提
できない制約・前提
難しい制約・前提
難しい制約・前提
結果的に特定の数値に責任と権限を持ったスモールチームになる
ここからが本に書いてある世界
ここからアジャイルコーチ的な人の出番?
ここまで座組を整えないと、ただ現場でもがくだけになり非効率
根雪構造でビジネス
成果が積み上がる部分を
スコープとする
予算と目的と責任と権限
とチームを1:1にして、
チームに自治権を与える
SoEを対象とする
あとはアジリティ高めで
V字モデルをやるだけ
根雪構造に合わせた
事業価値の積み上がりを
エンジニアリングする
大企業における既存事業の場合
Now
過去 未来
開発して未来に
積み上げる資産
事業価値
(KPI、etc)
過去に開発して
積み上げた資産
リリース
リリース
リリース
リリース予定
リリース予定
初期開発
エンハンス
エンハンス
エンハンス
エンハンス
この事業価値をうみだす装置の性能を上げるため(積分値を最大化)に出来ることは基本的には以下。
①価値が生まれるまでの時間を短くする。②生まれる価値を上げる。(開発)
③障害等で価値をうめなくなっている部分の最小化。④将来発生する③の防止。(安定稼働)
②効果を上げる
①速くする
③価値をうめな
くなっている部
分の最小化
④未来の価値毀損
の防止
③
④
時間
赤線で囲んだ部分の面積を
最大化していきたい
Now
過去 未来
開発して未来に
積み上げる資産
事業価値
(KPI、etc)
過去に開発して
積み上げた資産
リリース
リリース
リリース
リリース予定
リリース予定
初期開発
エンハンス
エンハンス
エンハンス
この事業価値をうみだす装置の性能を上げるため(積分値を最大化)に出来ることは基本的には以下。
①価値が生まれるまでの時間を短くする。②生まれる価値を上げる。(開発)
③障害等で価値をうめなくなっている部分の最小化。④将来発生する③の防止。(安定稼働)
②効果を上げる
③価値をうめな
くなっている部
分の最小化
④未来の価値毀損
の防止
③
④
時間
①速くする
リリース予定リリース予定
複数の要件をまとめて
開発してたのを1個ずつ
開発してリリースしてみる
Now
過去 未来
開発して未来に
積み上げる資産
事業価値
(KPI、etc)
過去に開発して
積み上げた資産
リリース
リリース
リリース
リリース予定
リリース予定
初期開発
エンハンス
エンハンス
エンハンス
この事業価値をうみだす装置の性能を上げるため(積分値を最大化)に出来ることは基本的には以下。
①価値が生まれるまでの時間を短くする。②生まれる価値を上げる。(開発)
③障害等で価値をうめなくなっている部分の最小化。④将来発生する③の防止。(安定稼働)
②効果を上げる
③価値をうめな
くなっている部
分の最小化
④未来の価値毀損
の防止
③
④
時間
①速くする
リリース予定リリース予定
事業価値は根雪構造を
とるため事業価値の面積が
増える場合がある。
1st week 2nd week 3rd week 4th week 5th week 6th week 7th week
1st week 2nd week 3rd week 4th week 5th week 6th week 7th week
CVR
CVR
±0 ±0 ±0 ±0 ±0 ±0 +3
±0 ±0 +1 +1 +1
+1 +1
±0 ±0 +1 +1
+1
±0 ±0
±0 ±0 +1
±0 ±0 ±0 ±0
売上
or
KPI
売上
or
KPI
release
A
B
C
0
0.75
1.5
2.25
3
1st week 2nd week 3rd week 4th week 5th week 6th week 7th week
0
0.75
1.5
2.25
3
1st week 2nd week 3rd week 4th week 5th week 6th week 7th week
ビジネス価値とリソース効率性重視の開発スタイル
A
B
C
ビジネス価値とフロー効率性重視の開発スタイル
20
1st week 2nd week 3rd week 4th week 5th week 6th week 7th week
1st week 2nd week 3rd week 4th week 5th week 6th week 7th week
CVR
CVR
±0 ±0 ±0 ±0 ±0 ±0 +3
±0 ±0 +1 +1 +1
+1 +1
±0 ±0 +1 +1
+1
±0 ±0
±0 ±0 +1
±0 ±0 ±0 ±0
売上
or
KPI
売上
or
KPI
release
A
B
C
0
0.75
1.5
2.25
3
1st week 2nd week 3rd week 4th week 5th week 6th week 7th week
0
0.75
1.5
2.25
3
1st week 2nd week 3rd week 4th week 5th week 6th week 7th week
ビジネス価値とリソース効率性重視の開発スタイル
A
B
C
ビジネス価値とフロー効率性重視の開発スタイル
1個ずつV字モデル開発
複数まとめてV字モデル開発
20
1st week 2nd week 3rd week 4th week 5th week 6th week 7th week
1st week 2nd week 3rd week 4th week 5th week 6th week 7th week
CVR
CVR
±0 ±0 ±0 ±0 ±0 ±0 +3
±0 ±0 +1 +1 +1
+1 +1
±0 ±0 +1 +1
+1
±0 ±0
±0 ±0 +1
±0 ±0 ±0 ±0
売上
or
KPI
売上
or
KPI
release
A
B
C
0
0.75
1.5
2.25
3
1st week 2nd week 3rd week 4th week 5th week 6th week 7th week
0
0.75
1.5
2.25
3
1st week 2nd week 3rd week 4th week 5th week 6th week 7th week
ビジネス価値とリソース効率性重視の開発スタイル
A
B
C
ビジネス価値とフロー効率性重視の開発スタイル
リードタイム
リードタイム
20
1st week 2nd week 3rd week 4th week 5th week 6th week 7th week
CVR
±0 ±0 +1 +1 +1
+1 +1
±0 ±0 +1 +1
+1
±0 ±0
±0 ±0 +1
±0 ±0 ±0 ±0
売上
or
KPI
0
0.75
1.5
2.25
3
1st week 2nd week 3rd week 4th week 5th week 6th week 7th week
A
B
C
バックエンド
エンジニア
フロント
エンジニア
プロダクト
オーナー
顧客
+1
承認
レビュー
仕様確認
API開発 API開発
Front開発
デプロイ
待ち 待ち
待ち
テスト
テスト
ビジネス価値とフロー効率性重視の開発スタイル
20
1st week 2nd week 3rd week 4th week 5th week 6th week 7th week
CVR
±0 ±0 +1 +1 +1
+1 +1
±0 ±0 +1 +1
+1
±0 ±0
±0 ±0 +1
±0 ±0 ±0 ±0
売上
or
KPI
0
0.75
1.5
2.25
3
1st week 2nd week 3rd week 4th week 5th week 6th week 7th week
A
B
C
バックエンド
エンジニア
フロント
エンジニア
プロダクト
オーナー
顧客
+1
承認
レビュー
仕様確認
API開発 API開発
Front開発
デプロイ
待ち 待ち
待ち
テスト
テスト
ビジネス価値とフロー効率性重視の開発スタイル
リードタイム
リードタイム短縮
エンジニアリングによってLTを短縮したい 20
リードタイム
プロセスタイム(PT) ムダ
+
顧客への価値を作り出している時間 価値を作っていない時間
➡設計
➡コーディング
➡ビルド待ち
➡手戻り
➡承認待ち
20
Development
Planning Design Measure
Ph.1 Ph.2 Ready会 Sprint
Design AB Testing
工程別
滞留数
(在庫数)
工程別
スルー
プット 4個/2週 3個/2週 3個/2週 4個/2週 1個/2週 4個/2週
未着手案件の在庫推移を可視化し組織生産性の可視化
1案件あたりのリードタイムを最小化したい
20
Development
Planning Design Measure
Ph.1 Ph.2 Ready会 Sprint
Design AB Testing
工程別
滞留数
(在庫数)
工程別
スルー
プット 4個/2週 3個/2週 3個/2週 4個/2週 1個/2週 4個/2週
Ready状態の在庫を作る
スループット
在庫を出荷する
スループット
在
庫
量
推
移
Ready化数 リリース数
未着手案件の在庫推移を可視化し組織生産性の可視化
1案件あたりのリードタイムを最小化したい
Development
Planning Design Measure
Ph.1 Ph.2 Ready会 Sprint
Design AB Testing
工程別
滞留数
(在庫数)
工程別
スルー
プット 4個/2週 3個/2週 3個/2週 4個/2週 1個/2週 4個/2週
Ready状態の在庫を作る
スループット
在庫を出荷する
スループット
在
庫
量
推
移
① ②
③
① ②
リードタイム
③
③=①-②
 =在庫量
Ready化数 リリース数
累積フロー図
未着手案件の在庫推移を可視化し組織生産性の可視化
Development
Planning Design Measure
Ph.1 Ph.2 Ready会 Sprint
Design AB Testing
工程別
滞留数
(在庫数)
工程別
スルー
プット 4個/2週 3個/2週 3個/2週 4個/2週 1個/2週 4個/2週
Ready状態の在庫を作る
スループット
在庫を出荷する
スループット
在
庫
量
推
移
① ②
③
③
①
②
Ready化数 リリース数
Readyにした数とリリースした数 在庫数推移
未着手案件の在庫推移を可視化し組織生産性の可視化
大企業&新規事業
ビジネス構造の理解
大企業における新規事業の場合
参入市場 戦略 プロダクト要件 競争種別 開発スタイル 開発体制
新規市場 オーソドックスな
顧客開発
作るものがわからな
い
競争なし 探索型 柔軟さに特化した開
発体制
既存市場 競合と戦う
・フォロワー戦略
・同質化戦略
作るものが明確
当たり前品質の期待
値高い
競合で実証された機
能の実装
性能競争になる
ため、経営資源
の投下量勝負に
なる
(経営のコミッ
ト大事)
競合劣位解消の
ための機能開発
を計画的になり
やすい
高品質
高機能
計画駆動に特化した
開発体制で、いっき
に全部盛りを作った
ほうが効率が良い
既存市場 競合と戦わない
市場の再セグメント化
・ニッチ化(例:サカゼン)
・低コスト化(例:LCC)
からの顧客開発
作るものがうっすら
みえている
競争なし
競争あっても勝
者はいない
探索型 柔軟さに特化した開
発体制
クローン
市場
コピーキャット 作るものが明確 競争なし 機能を計画的に 計画駆動に特化した
開発体制
新規参入市場におけるビジネス不確実性と開発スタイル
参入市場 戦略 プロダクト要件 競争種別 開発スタイル 開発体制
新規市場 オーソドックスな
顧客開発
作るものがわからな
い
競争なし 探索型 柔軟さに特化した開
発体制
既存市場 競合と戦う
・フォロワー戦略
・同質化戦略
作るものが明確
当たり前品質の期待
値高い
競合で実証された機
能の実装
性能競争になる
ため、経営資源
の投下量勝負に
なる
(経営のコミッ
ト大事)
競合劣位解消の
ための機能開発
を計画的になり
やすい
高品質
高機能
計画駆動に特化した
開発体制で、いっき
に全部盛りを作った
ほうが効率が良い
既存市場 競合と戦わない
市場の再セグメント化
・ニッチ化(例:サカゼン)
・低コスト化(例:LCC)
からの顧客開発
作るものがうっすら
みえている
競争なし
競争あっても勝
者はいない
探索型 柔軟さに特化した開
発体制
クローン
市場
コピーキャット 作るものが明確 競争なし 機能を計画的に 計画駆動に特化した
開発体制で、いっき
に全部盛りを作った
ほうが効率が良い
大企業はこういうのが多い
新規参入市場におけるビジネス不確実性と開発スタイル
つぎにこれ(感覚)
世の中で一般的にスタートアップとされているやつ アジャイルといわれているやつ
アジャイルといわれているやつ
Complicated
Cynefin framework
Complex
Chaotic Clear
単純な領域
込み入った領域
複雑な領域
カオスな領域
理解→分類→反応
理解→分析→反応
探索→理解→反応
行動→理解→反応
Confused
Complicated
Complex
Chaotic
単純な領域
込み入った領域
複雑な領域
カオスな領域
理解→分類→反応
理解→分析→反応
探索→理解→反応
行動→理解→反応
不確実性が高く
リーンスタートアップや顧客
開発的アプローチがフィット
するであろう領域
不確実性:低
不確実性:高
Cynefin framework
Clear
Confused
Complicated
Cynefin framework + 新規事業の参入市場
Complex
Chaotic Clear
Confused
単純な領域
込み入った領域
複雑な領域
カオスな領域
理解→分類→反応
理解→分析→反応
探索→理解→反応
行動→理解→反応
新規市場
既存市場
• フォロアー戦略
• 同質化戦略
クローン市場
既存市場
• 再セグメント化
Complicated
Cynefin framework + 新規事業の参入市場
Complex
Chaotic Clear
Confused
単純な領域
込み入った領域
複雑な領域
カオスな領域
理解→分類→反応
理解→分析→反応
探索→理解→反応
行動→理解→反応
新規市場
既存市場
• フォロアー戦略
• 同質化戦略
クローン市場
既存市場
• 再セグメント化
←①大企業だと、
結構ある、
こっちの話
   ↑
②一般的な
新規事業ぽいやつ
Complicated
Cynefin framework + 新規事業の参入市場
Complex
Chaotic Clear
Confused
単純な領域
込み入った領域
複雑な領域
カオスな領域
理解→分類→反応
理解→分析→反応
探索→理解→反応
行動→理解→反応
新規市場
既存市場
• フォロアー戦略
• 同質化戦略
クローン市場
既存市場
• 再セグメント化
←①大企業だと、
結構ある、
こっちの話
   ↑
②一般的な
新規事業ぽいやつ
既存市場において同質化戦略で先行者が切り開いた市場を塗り替えに行くパターンは以下の開発スタイルに
なることが多い。すでに出来上がった市場であることから顧客に受け入れられるベースの要件が高い。
これは機能であったり品質であったり市場により様々ではある。そのため、後追いで市場参入するため、
先行者に一気に追いつく必要がある。同質化した際には、低価格化等の性能競争になる。
クローン市場に攻める際も、ほぼ同じ歩みになる。
Now
過去 未来
開発して未来に
積み上げる資産
事業価値
(KPI、etc)
過去に開発して
積み上げた資産
リリース
リリース
リリース予定
リリース予定
初期開発
エンハンス
エンハンス
エンハンス
時間
初期開発が大きめなプロジェクト開発
(市場先行者により機能要件が明確であるため)
市場が受け入れてくれる
当たり前レベルの価値
Problem/Solution
Fit
Product/Market
Fit Scaling
CAC < LTV 売上
指標値例
検証
ポイント
✓課題が本当に実在するか
✓課題を抱えた顧客がいるか
✓課題への解決策は妥当か
✓顧客は本当に買ってくれるか
✓コスト構造に無理がないか
売り物(プロダクト)を磨くフェーズ
✓最適な売り方の検証
✓最適な価格設定の検証
導入期 成長期 成熟期
✓マーケット
シェア
ビジネス
フェーズ
バケツの水漏れを塞ぐ バケツに水を流す バケツに流す水を増やす
売り方を磨くフェーズ
敷き詰め(営業&マーケ)
仮説検証で市場にFitさせていく
自社が市場開
拓者の場合
自社が後発参
入する場合
コピー作る
競合劣位解消
安定稼働
戦略上重要な機能追加
+
Retention
(Activation)
グロースハック
MVPでサクッと検証 売って検証
(いわゆるリーンスタートアップ)
Problem/Solution
Fit
Product/Market
Fit Scaling
CAC < LTV 売上
指標値例
検証
ポイント
✓課題が本当に実在するか
✓課題を抱えた顧客がいるか
✓課題への解決策は妥当か
✓顧客は本当に買ってくれるか
✓コスト構造に無理がないか
売り物(プロダクト)を磨くフェーズ
✓最適な売り方の検証
✓最適な価格設定の検証
導入期 成長期 成熟期
✓マーケット
シェア
ビジネス
フェーズ
バケツの水漏れを塞ぐ バケツに水を流す バケツに流す水を増やす
売り方を磨くフェーズ
敷き詰め(営業&マーケ)
仮説検証で市場にFitさせていく
自社が市場開
拓者の場合
自社が後発参
入する場合
コピー作る
競合劣位解消
安定稼働
戦略上重要な機能追加
+
Retention
(Activation)
グロースハック
MVPでサクッと検証 売って検証
(いわゆるリーンスタートアップ)
左から右にいくリードタイムを
可能な限り短縮したい
Problem/Solution
Fit
Product/Market
Fit Scaling
CAC < LTV 売上
指標値例
検証
ポイント
✓課題が本当に実在するか
✓課題を抱えた顧客がいるか
✓課題への解決策は妥当か
✓顧客は本当に買ってくれるか
✓コスト構造に無理がないか
売り物(プロダクト)を磨くフェーズ
✓最適な売り方の検証
✓最適な価格設定の検証
導入期 成長期 成熟期
✓マーケット
シェア
ビジネス
フェーズ
バケツの水漏れを塞ぐ バケツに水を流す バケツに流す水を増やす
売り方を磨くフェーズ
敷き詰め(営業&マーケ)
仮説検証で市場にFitさせていく
自社が市場開
拓者の場合
自社が後発参
入する場合
コピー作る
競合劣位解消
安定稼働
戦略上重要な機能追加
+
Retention
(Activation)
グロースハック
MVPでサクッと検証 売って検証
(いわゆるリーンスタートアップ)
文脈を無視して、
ここからリーンスタートアップ
始めたがる人が多い
MVPでサクッと検証 売って検証
(いわゆるリーンスタートアップ)
Problem/Solution
Fit
Product/Market
Fit Scaling
CAC < LTV 売上
指標値例
検証
ポイント
✓課題が本当に実在するか
✓課題を抱えた顧客がいるか
✓課題への解決策は妥当か
✓顧客は本当に買ってくれるか
✓コスト構造に無理がないか
売り物(プロダクト)を磨くフェーズ
✓最適な売り方の検証
✓最適な価格設定の検証
導入期 成長期 成熟期
✓マーケット
シェア
ビジネス
フェーズ
バケツの水漏れを塞ぐ バケツに水を流す バケツに流す水を増やす
売り方を磨くフェーズ
仮説検証で市場にFitさせていく
コピー作る
Retention
(Activation)
実際は、大企業では
これが結構、多い
自社が市場開
拓者の場合
自社が後発参
入する場合
敷き詰め(営業&マーケ)
競合劣位解消
安定稼働
戦略上重要な機能追加
+
グロースハック
MVPでサクッと検証 売って検証
(いわゆるリーンスタートアップ)
Problem/Solution
Fit
Product/Market
Fit Scaling
CAC < LTV 売上
指標値例
検証
ポイント
✓課題が本当に実在するか
✓課題を抱えた顧客がいるか
✓課題への解決策は妥当か
✓顧客は本当に買ってくれるか
✓コスト構造に無理がないか
売り物(プロダクト)を磨くフェーズ
✓最適な売り方の検証
✓最適な価格設定の検証
導入期 成長期 成熟期
✓マーケット
シェア
ビジネス
フェーズ
バケツの水漏れを塞ぐ バケツに水を流す バケツに流す水を増やす
売り方を磨くフェーズ
仮説検証で市場にFitさせていく
コピー作る
Retention
(Activation)
実際は、大企業では
これが結構、多い
自社が市場開
拓者の場合
自社が後発参
入する場合
敷き詰め(営業&マーケ)
競合劣位解消
安定稼働
戦略上重要な機能追加
+
グロースハック
カネを投下して、
いっきに開発しきる
(市場投入LT最短)
敷き詰め(営業&マーケ)
競合劣位解消
安定稼働
戦略上重要な機能追加
+
グロースハック
MVPでサクッと検証 売って検証
(いわゆるリーンスタートアップ)
Problem/Solution
Fit
Product/Market
Fit Scaling
CAC < LTV 売上
指標値例
検証
ポイント
✓課題が本当に実在するか
✓課題を抱えた顧客がいるか
✓課題への解決策は妥当か
✓顧客は本当に買ってくれるか
✓コスト構造に無理がないか
売り物(プロダクト)を磨くフェーズ
✓最適な売り方の検証
✓最適な価格設定の検証
導入期 成長期 成熟期
✓マーケット
シェア
ビジネス
フェーズ
バケツの水漏れを塞ぐ バケツに水を流す バケツに流す水を増やす
売り方を磨くフェーズ
仮説検証で市場にFitさせていく
コピー作る
Retention
(Activation)
既存プレイヤーがいるということは・・・・
・市場の当たり前品質レベルは高く・・
 性能要件も高く・・・・機能ももりもりであり・・・・
 それに後追いでコピーをつくるということは、
→大規模開発
開発マネジメント力
アーキテクト力
動員力勝負(ベトナムオフショア)
※コスト削減のためのオフショアではなく
 動員力によるリードタイム削減が目的
(来月50人必要といったら調達可能な世界)
多いとか、人月の神話ガーとか思った?
思考実験。その50人がペアワークしたら?
その50人がセットベースしたら?どう?
自社が市場開
拓者の場合
自社が後発参
入する場合
LT最短化したい
敷き詰め(営業&マーケ)
競合劣位解消
安定稼働
戦略上重要な機能追加
+
グロースハック
MVPでサクッと検証 売って検証
(いわゆるリーンスタートアップ)
Problem/Solution
Fit
Product/Market
Fit Scaling
CAC < LTV 売上
指標値例
検証
ポイント
✓課題が本当に実在するか
✓課題を抱えた顧客がいるか
✓課題への解決策は妥当か
✓顧客は本当に買ってくれるか
✓コスト構造に無理がないか
売り物(プロダクト)を磨くフェーズ
✓最適な売り方の検証
✓最適な価格設定の検証
導入期 成長期 成熟期
✓マーケット
シェア
ビジネス
フェーズ
バケツの水漏れを塞ぐ バケツに水を流す バケツに流す水を増やす
売り方を磨くフェーズ
仮説検証で市場にFitさせていく
コピー作る
Retention
(Activation)
既存プレイヤーがいるということは・・・・
・市場の当たり前品質レベルは高く・・
 性能要件も高く・・・・機能ももりもりであり・・・・
 それに後追いでコピーをつくるということは、
→大規模開発
開発マネジメント力
アーキテクト力
動員力勝負(ベトナムオフショア)
※コスト削減のためのオフショアではなく
 動員力によるリードタイム削減が目的
(来月50人必要といったら調達可能な世界)
多いとか、人月の神話ガーとか思った?
思考実験。その50人がペアワークしたら?
その50人がセットベースしたら?どう?
自社が市場開
拓者の場合
自社が後発参
入する場合
LT最短化したい
文脈を無視した「べき論」での「アジャ
イル?」ではビジネス上得たかった実利
に結果的に遠回りになることがある。
一気に作って追いついてから、アジャイ
ルするという選択肢を持っても良い。
スタートアップと同じ戦い方をしてたら
追いつけないし勝てない。
潤沢なリソースとすでにある顧客接点と
いう地の利を最大限に活かすこと。
不確実性
大
不確実性
中
不確実性
小
正しいものを探索する
(作る対象の不確実性)
正しいものを正しくつくる
(作り方の不確実性)
正しくつくる
正しいもの
原型
ポイントベース
・うまくいけば最短LT最小コストで走れる
・変更が入る度に手戻りが発生し、リードタイムが伸びる
・変更が入る度にコストがかかる
 例:年次法改正対応のような確定している要件
あ、違った
最初に決定
また違った
このカネのかけかたではなく(これは非効率)
不確実性
大
不確実性
中
不確実性
小
正しいものを探索する
(作る対象の不確実性)
正しいものを正しくつくる
(作り方の不確実性)
正しくつくる
正しいもの
原型
判
断
ポ
イ
ン
ト
判
断
セットベース
・情報がそろうまで決定をおくらせる
・複数案並走させることでコストかかる
・複数案走ることで手戻りを無くしリードタイムを最短にする
 例:リスクがあるアーキテクチャ候補の並走検討
こっち的カネのかけかた(アジャイルな哲学でカネを使う)
敷き詰め(営業&マーケ)
競合劣位解消
安定稼働
戦略上重要な機能追加
+
Problem/Solution
Fit
Product/Market
Fit Scaling
CAC < LTV 売上
指標値例
検証
ポイント
✓課題が本当に実在するか
✓課題を抱えた顧客がいるか
✓課題への解決策は妥当か
✓顧客は本当に買ってくれるか
✓コスト構造に無理がないか
売り物(プロダクト)を磨くフェーズ
✓最適な売り方の検証
✓最適な価格設定の検証
導入期 成長期 成熟期
✓マーケット
シェア
ビジネス
フェーズ
バケツの水漏れを塞ぐ バケツに水を流す バケツに流す水を増やす
売り方を磨くフェーズ
仮説検証で市場にFitさせていく
コピー作る
Retention
(Activation)
自社が市場開
拓者の場合
自社が後発参
入する場合
MVPでサクッと検証 売って検証
(いわゆるリーンスタートアップ)
グロースハック
仮説検証型
仮説検証型
一気につくって先行者に追いついたら
敷き詰め(営業&マーケ)
競合劣位解消
安定稼働
戦略上重要な機能追加
+
Problem/Solution
Fit
Product/Market
Fit Scaling
CAC < LTV 売上
指標値例
検証
ポイント
✓課題が本当に実在するか
✓課題を抱えた顧客がいるか
✓課題への解決策は妥当か
✓顧客は本当に買ってくれるか
✓コスト構造に無理がないか
売り物(プロダクト)を磨くフェーズ
✓最適な売り方の検証
✓最適な価格設定の検証
導入期 成長期 成熟期
✓マーケット
シェア
ビジネス
フェーズ
バケツの水漏れを塞ぐ バケツに水を流す バケツに流す水を増やす
売り方を磨くフェーズ
仮説検証で市場にFitさせていく
コピー作る
Retention
(Activation)
自社が市場開
拓者の場合
自社が後発参
入する場合
MVPでサクッと検証 売って検証
(いわゆるリーンスタートアップ)
グロースハック
仮説検証型
仮説検証型
一気につくって先行者に追いついたら
あとはアジリティ高めで
V字モデルをやるだけ
Complicated
Cynefin framework + 新規事業の参入市場
Complex
Chaotic Clear
Confused
単純な領域
込み入った領域
複雑な領域
カオスな領域
理解→分類→反応
理解→分析→反応
探索→理解→反応
行動→理解→反応
新規市場
既存市場
• フォロアー戦略
• 同質化戦略
クローン市場
既存市場
• 再セグメント化
←①大企業だと、
結構ある、
こっちの話
   ↑
②一般的な
新規事業ぽいやつ
Complicated
Cynefin framework + 新規事業の参入市場
Complex
Chaotic Clear
Confused
単純な領域
込み入った領域
複雑な領域
カオスな領域
理解→分類→反応
理解→分析→反応
探索→理解→反応
行動→理解→反応
新規市場
既存市場
• フォロアー戦略
• 同質化戦略
クローン市場
既存市場
• 再セグメント化
←①大企業だと、
結構ある、
こっちの話
   ↑
②一般的な
新規事業ぽいやつ
Now
過去 未来
開発して未来に
積み上げる資産
事業価値
(KPI、etc)
過去に開発して
積み上げた資産
リリース
リリース
リリース
リリース予定
初期開発
時間
エンハンス
エンハンス
リリース
リリース
リリース
リリース予定
リリース予定
リリース予定
エンハンス
エンハンス
エンハンス
エンハンス
エンハンス
エンハンス
エンハンス
新規市場や既存市場の再セグメント化戦略の場合は、基本的にはマーケットの不確実性に対峙することになる。
この場合求められる開発スタイルは不確実性のリスクを最小化していくスタイルである。言い換えるならば、
大きくフルスイングするのではなく、小さく失敗と学びを繰り返すやりかた。つまり、以下のように、ビジネス
仮説を可能な限り因数分解しひとつずつ仮説検証を回していく。
Now
過去 未来
開発して未来に
積み上げる資産
事業価値
(KPI、etc)
過去に開発して
積み上げた資産
リリース
リリース
リリース
リリース予定
初期開発
時間
エンハンス
エンハンス
リリース
リリース
リリース
リリース予定
リリース予定
リリース予定
エンハンス
エンハンス
エンハンス
エンハンス
エンハンス
エンハンス
エンハンス
新規市場や既存市場の再セグメント化戦略の場合は、基本的にはマーケットの不確実性に対峙することになる。
この場合求められる開発スタイルは不確実性のリスクを最小化していくスタイルである。言い換えるならば、
大きくフルスイングするのではなく、小さく失敗と学びを繰り返すやりかた。つまり、以下のように、ビジネス
仮説を可能な限り因数分解しひとつずつ仮説検証を回していく。
こうやればいいんだけど、
社内の力学により、難易度が跳ね上がることがある
(かもしれない)
Problem/Solution
Fit
Product/Market
Fit Scaling
CAC < LTV 売上
指標値例
検証
ポイント
✓課題が本当に実在するか
✓課題を抱えた顧客がいるか
✓課題への解決策は妥当か
✓顧客は本当に買ってくれるか
✓コスト構造に無理がないか
売り物(プロダクト)を磨くフェーズ
✓最適な売り方の検証
✓最適な価格設定の検証
導入期 成長期 成熟期
✓マーケット
シェア
ビジネス
フェーズ
バケツの水漏れを塞ぐ バケツに水を流す バケツに流す水を増やす
売り方を磨くフェーズ
敷き詰め(営業&マーケ)
仮説検証で市場にFitさせていく
自社が市場開
拓者の場合
自社が後発参
入する場合
コピー作る
競合劣位解消
安定稼働
戦略上重要な機能追加
+
Retention
(Activation)
グロースハック
MVPでサクッと検証 売って検証
(いわゆるリーンスタートアップ)
Problem/Solution
Fit
Product/Market
Fit Scaling
CAC < LTV 売上
指標値例
検証
ポイント
✓課題が本当に実在するか
✓課題を抱えた顧客がいるか
✓課題への解決策は妥当か
✓顧客は本当に買ってくれるか
✓コスト構造に無理がないか
売り物(プロダクト)を磨くフェーズ
✓最適な売り方の検証
✓最適な価格設定の検証
導入期 成長期 成熟期
✓マーケット
シェア
ビジネス
フェーズ
バケツの水漏れを塞ぐ バケツに水を流す バケツに流す水を増やす
売り方を磨くフェーズ
敷き詰め(営業&マーケ)
仮説検証で市場にFitさせていく
自社が市場開
拓者の場合
自社が後発参
入する場合
コピー作る
競合劣位解消
安定稼働
戦略上重要な機能追加
+
Retention
(Activation)
グロースハック
MVPでサクッと検証 売って検証
(いわゆるリーンスタートアップ)
社内新規事業のアーリーステージにおいて
過度な売上目標をチームに持たせたことで、
組織がアジリティを失っていく架空の話
Problem/Solution
Fit
Product/Market
Fit Scaling
Retention CAC < LTV 売上
課題解決可能
な最小限
売り方最適化 / 売上最大化
売る
アップセル/クロスセルに向けた性能品質
指標値例
検証アク
ション
検証
ポイント
MVP
目標
MVP作って検証
最低限売れる
当たり前品質
独自な価値提供を出来ているか
深い課題を抱えた顧客がいるか
その課題の解決策は妥当か
独自な価値提供を出来ているか
顧客は本当に買ってくれるか
コスト構造に無理がないか
売り物(プロダクト)を磨くフェーズ
独自な価値提供を出来ているか
最適な売り方の検証
最適な価格設定の検証
導入期 成長期 成熟期
利益
独自な価値提供を出来ているか
CPA最適化
マーケットシェア
キードライバー値
最大化
利益最大化
ビジネス
フェーズ
バケツの水漏れを塞ぐ バケツに水を流す バケツに流す水を増やす
売り方を磨くフェーズ
toC向け
新規サービス
Problem/Solution
Fit
Product/Market
Fit Scaling
CAC < LTV 売上
課題解決可能
な最小限
売り方最適化 / 売上最大化
売る
アップセル/クロスセルに向けた性能品質
指標値例
検証アク
ション
検証
ポイント
MVP
目標
MVP作って検証
最低限売れる
当たり前品質
独自な価値提供を出来ているか
深い課題を抱えた顧客がいるか
その課題の解決策は妥当か
独自な価値提供を出来ているか
顧客は本当に買ってくれるか
コスト構造に無理がないか
売り物(プロダクト)を磨くフェーズ
独自な価値提供を出来ているか
最適な売り方の検証
最適な価格設定の検証
導入期 成長期 成熟期
利益
独自な価値提供を出来ているか
CPA最適化
マーケットシェア
キードライバー値
最大化
利益最大化
ビジネス
フェーズ
バケツの水漏れを塞ぐ バケツに水を流す バケツに流す水を増やす
売り方を磨くフェーズ
カネ(売上目標)の圧
デカい売上はよ
Retention
toC向け
新規サービス
事業成長を加速させ
るために強めの売上
目標をもたせよう!
Problem/Solution
Fit
Product/Market
Fit Scaling
売上
CAC < LTV
課題解決可能
な最小限
売り方最適化 / 売上最大化
売る
アップセル/クロスセルに向けた性能品質
指標値例
検証アク
ション
検証
ポイント
MVP
目標
MVP作って検証
最低限売れる
当たり前品質
独自な価値提供を出来ているか
深い課題を抱えた顧客がいるか
その課題の解決策は妥当か
独自な価値提供を出来ているか
顧客は本当に買ってくれるか
コスト構造に無理がないか
売り物(プロダクト)を磨くフェーズ
独自な価値提供を出来ているか
最適な売り方の検証
最適な価格設定の検証
導入期 成長期 成熟期
利益
独自な価値提供を出来ているか
CPA最適化
マーケットシェア
キードライバー値
最大化
利益最大化
ビジネス
フェーズ
バケツの水漏れを塞ぐ バケツに水を流す バケツに流す水を増やす
売り方を磨くフェーズ
デカい売上はよ
Retention
顧客単価の高いtoB
サービスにしたくなる
toC向け
新規サービス
カネ(売上目標)の圧
Problem/Solution
Fit
Product/Market
Fit Scaling
売上
CAC < LTV
課題解決可能
な最小限
売り方最適化 / 売上最大化
売る
アップセル/クロスセルに向けた性能品質
指標値例
検証アク
ション
検証
ポイント
MVP
目標
MVP作って検証
最低限売れる
当たり前品質
独自な価値提供を出来ているか
深い課題を抱えた顧客がいるか
その課題の解決策は妥当か
独自な価値提供を出来ているか
顧客は本当に買ってくれるか
コスト構造に無理がないか
売り物(プロダクト)を磨くフェーズ
独自な価値提供を出来ているか
最適な売り方の検証
最適な価格設定の検証
導入期 成長期 成熟期
利益
独自な価値提供を出来ているか
CPA最適化
マーケットシェア
キードライバー値
最大化
利益最大化
ビジネス
フェーズ
バケツの水漏れを塞ぐ バケツに水を流す バケツに流す水を増やす
売り方を磨くフェーズ
デカい売上はよ
Retention
顧客単価の高いtoB
サービスにしたくなる
toC向け
新規サービス
実際は・・・
toC向けの実験レベル
のプロダクト品質
ただし、このまま
売っても、全く売れ
ない・・・
カネ(売上目標)の圧
Problem/Solution
Fit
Product/Market
Fit Scaling
売上
CAC < LTV
課題解決可能
な最小限
売り方最適化 / 売上最大化
売る
アップセル/クロスセルに向けた性能品質
指標値例
検証アク
ション
検証
ポイント
MVP
目標
MVP作って検証
最低限売れる
当たり前品質
独自な価値提供を出来ているか
深い課題を抱えた顧客がいるか
その課題の解決策は妥当か
独自な価値提供を出来ているか
顧客は本当に買ってくれるか
コスト構造に無理がないか
売り物(プロダクト)を磨くフェーズ
独自な価値提供を出来ているか
最適な売り方の検証
最適な価格設定の検証
導入期 成長期 成熟期
利益
独自な価値提供を出来ているか
CPA最適化
マーケットシェア
キードライバー値
最大化
利益最大化
ビジネス
フェーズ
バケツの水漏れを塞ぐ バケツに水を流す バケツに流す水を増やす
売り方を磨くフェーズ
デカい売上はよ
Retention
顧客単価の高いtoB
サービスにしたくなる
toC向け
新規サービス
実際は・・・
toC向けの実験レベル
のプロダクト品質
ただし、このまま
売っても、全く売れ
ない・・・
カネ(売上目標)の圧
プロダクトは今ココ 売上目標はココ
Problem/Solution
Fit
Product/Market
Fit Scaling
売上
CAC < LTV
課題解決可能
な最小限
売り方最適化 / 売上最大化
売る
アップセル/クロスセルに向けた性能品質
指標値例
検証アク
ション
検証
ポイント
MVP
目標
MVP作って検証
最低限売れる
当たり前品質
独自な価値提供を出来ているか
深い課題を抱えた顧客がいるか
その課題の解決策は妥当か
独自な価値提供を出来ているか
顧客は本当に買ってくれるか
コスト構造に無理がないか
売り物(プロダクト)を磨くフェーズ
独自な価値提供を出来ているか
最適な売り方の検証
最適な価格設定の検証
導入期 成長期 成熟期
利益
独自な価値提供を出来ているか
CPA最適化
マーケットシェア
キードライバー値
最大化
利益最大化
ビジネス
フェーズ
バケツの水漏れを塞ぐ バケツに水を流す バケツに流す水を増やす
売り方を磨くフェーズ
デカい売上はよ
Retention
顧客単価の高いtoB
サービスにしたくなる
toB向け機能が必要に
なる。要件も高品質高
性能になる。
toC向け
新規サービス
実際は・・・
toC向けの実験レベル
のプロダクト品質
カネ(売上目標)の圧
Problem/Solution
Fit
Product/Market
Fit Scaling
売上
CAC < LTV
課題解決可能
な最小限
売り方最適化 / 売上最大化
売る
アップセル/クロスセルに向けた性能品質
指標値例
検証アク
ション
検証
ポイント
MVP
目標
MVP作って検証
最低限売れる
当たり前品質
独自な価値提供を出来ているか
深い課題を抱えた顧客がいるか
その課題の解決策は妥当か
独自な価値提供を出来ているか
顧客は本当に買ってくれるか
コスト構造に無理がないか
売り物(プロダクト)を磨くフェーズ
独自な価値提供を出来ているか
最適な売り方の検証
最適な価格設定の検証
導入期 成長期 成熟期
利益
独自な価値提供を出来ているか
CPA最適化
マーケットシェア
キードライバー値
最大化
利益最大化
ビジネス
フェーズ
バケツの水漏れを塞ぐ バケツに水を流す バケツに流す水を増やす
売り方を磨くフェーズ
デカい売上はよ
Retention
顧客単価の高いtoB
サービスにしたくなる
toB向け機能が必要に
なる。要件も高品質高
性能になる。
toC向け
新規サービス
実際は・・・
toC向けの実験レベル
のプロダクト品質
売上計画から逆算した
計画駆動開発が始まる
(かもしれない)
カネ(売上目標)の圧
売れるために、
ちょっとこの機能を
増やしたいんだけど
計画どおり作らねばなら
ないので、変更は受け付
けません!
開発「側」は計画通り作り上げることが目標になり、柔軟な変更を弾き返すようになります。
プランニング「側」は目標に向けた計画を遂行したいがために、仕様を押し込みたくなるし、開発「側」はそれをディ
フェンスしたくなる。ギスギスしだす。
開発「側」は「仕様が決まってないので作れません」となる。更に開発「側」は計画を守るために、バッファを計画
上にたくさん盛り込みだす。つまりは、やれることをバッファ分だけ自ら減らしていく構造を作り上げる。そして、
基本的にバッファは使い切ってリリースを迎えることになる。結果的に自分たちのできる総量を、自ら低下させ成長
をスローダウンさせていくことになる。(パーキンソンの法則:バッファはあるだけ使い果たす)
(感じ悪いなあ・・)
(計画どおりやれって
いってんのお前だろ)
(計画達成するために、
バッファいっぱい積んで
おこう)
開発「側」 プランニング「側」
←目的がすり替わる()
カネ(売上目標)の圧
Problem/Solution
Fit
Product/Market
Fit Scaling
CAC < LTV 売上
課題解決可能
な最小限
売り方最適化 / 売上最大化
売る
アップセル/クロスセルに向けた性能品質
指標値例
検証アク
ション
検証
ポイント
MVP
目標
MVP作って検証
最低限売れる
当たり前品質
独自な価値提供を出来ているか
深い課題を抱えた顧客がいるか
その課題の解決策は妥当か
独自な価値提供を出来ているか
顧客は本当に買ってくれるか
コスト構造に無理がないか
売り物(プロダクト)を磨くフェーズ
独自な価値提供を出来ているか
最適な売り方の検証
最適な価格設定の検証
導入期 成長期 成熟期
利益
独自な価値提供を出来ているか
CPA最適化
マーケットシェア
キードライバー値
最大化
利益最大化
ビジネス
フェーズ
バケツの水漏れを塞ぐ バケツに水を流す バケツに流す水を増やす
売り方を磨くフェーズ
デカい売上はよ
Retention
toC向け
新規サービス
事業成長を加速させ
るために強めの売上
目標をもたせよう!
終わりの
はじまり
マネジメントはこういう力学を意識し、
コントロールする必要がある
スモールチーム
アジャイルな状態
できない制約・前提
できない制約・前提
難しい制約・前提
難しい制約・前提
結果的に特定の数値に責任と権限を持ったスモールチームになる
ここからが本に書いてある世界
ここからアジャイルコーチ的な人の出番?
ここまで座組を整えないと、ただ現場でもがくだけになり非効率
戦い方に合わせた
開発スタイルを選択する
売り物を磨くフェーズ
売り方を磨くフェーズ
に合わせた運営
参入市場を理解する
「べき論」に囚われない
まとめ
うまく行っている仕組み、取り組み、文化、制度にはそれが成立する前提があるが、意外にそこは共有され
ていないものである。
しかしながら、その前提こそが大切であり、その前提を作り上げている構造を理解して初めて本質的な座組
を作ることができるようになる。
色々な先進的な事例
・Joy incやモブプロで有名なハンター社の文化を成立させている前提条件はなんだろうか?
・Web系企業のエンジニア文化が重宝されるのはなぜだろうか?
ビジネスモデルは?成長のエンジンはエンジニア or 営業?上場していないから?
雇用形態が日本と違うから?終身雇用でも成立する?人事制度は?
表面の心地よい部分のみを見てしまい、憧れで終わってしまうのは思考停止。それが成立している前提条件
を自分の頭で構造として捉えることが大事。それをクリアしてるのであれば、やるだけ。
エンジニアなのであれば、構造として捉えることが得意であるはずで、
構造を把握できれば、コントロール出来るので、さあ、あとはやるだけだ。
前提を意識する
前提を意識する
例えば、前述のタウンワークのスループット最大化の取り組みは以下の条件だから成立してたので、そこらへんすっ
飛ばしてHOWのみフォーカスしコピーすると、○○プラクティスはクソみたいな感じになりがち。で、自分たちのミ
スによってその手法論は(笑)化していく。それにより、その組織内においての○○プラクティスという名前は死ぬ。
以下が前提と言われているやつ。もしくは、
「場合による」と回答されるときの「場合」。
✓事業のキードライバーが明確になっていること
✓キードライバーをグロースさせるための案件を継続的に用意
できること
✓案件のサイズにブレが少ないこと
✓目的に対して体制がロックされていること
✓ビジネス効果が根雪構造的に生まれるもの
この背後に隠れた条件を見抜く力が必要であり、
自分の頭で考える部分。
機能やUI/UXは事業価値(アクション数、etc)ではない。事業価値をうみだす装置である。
つまり、リリースするまでは何も価値をうみださない。使われることで事業価値に変換されていく。
そのため、リリース後に安定的に事業価値をうみだしつづけることが大事。
※リリース毎に確実に価値が積み上がるわけではないが、説明をシンプルにするために以下のように表現している。
Now
過去 未来
開発して未来に
積み上げる資産
事業価値
(KPI、etc)
過去に開発して
積み上げた資産
リリース
リリース
リリース
リリース予定
リリース予定
初期開発
エンハンス
エンハンス
エンハンス
エンハンス
時間
なので、グラフの面積を最大化することが事業貢献している状態をさす。
青い太線よりも赤い太線のほうが事業貢献度が高い。
アウトカムにフォーカスする
前提と制約を意識し
アウトカム最大化にフォーカスした
生産ラインを確立すること
まとめ
= プログラムマネジメント的営み

More Related Content

What's hot

フロー効率性とリソース効率性、再入門 #devlove #devkan
フロー効率性とリソース効率性、再入門 #devlove #devkanフロー効率性とリソース効率性、再入門 #devlove #devkan
フロー効率性とリソース効率性、再入門 #devlove #devkanItsuki Kuroda
 
カネとAgile(大企業新規事業編) #rsgt2021
カネとAgile(大企業新規事業編) #rsgt2021カネとAgile(大企業新規事業編) #rsgt2021
カネとAgile(大企業新規事業編) #rsgt2021Itsuki Kuroda
 
アジャイル開発におけるクラフトマンシップの重要性
アジャイル開発におけるクラフトマンシップの重要性アジャイル開発におけるクラフトマンシップの重要性
アジャイル開発におけるクラフトマンシップの重要性Shigeru Tatsuta
 
開発速度が速い #とは(LayerX社内資料)
開発速度が速い #とは(LayerX社内資料)開発速度が速い #とは(LayerX社内資料)
開発速度が速い #とは(LayerX社内資料)mosa siru
 
アジャイルメトリクス実践ガイド
アジャイルメトリクス実践ガイドアジャイルメトリクス実践ガイド
アジャイルメトリクス実践ガイドHiroyuki Ito
 
リーン開発の本質 公開用
リーン開発の本質 公開用リーン開発の本質 公開用
リーン開発の本質 公開用ESM SEC
 
社内スタートアップによる組織の成長に伴い発生する痛みとその解決策について45分拡大版 #devsumi #devsumiB
社内スタートアップによる組織の成長に伴い発生する痛みとその解決策について45分拡大版 #devsumi #devsumiB社内スタートアップによる組織の成長に伴い発生する痛みとその解決策について45分拡大版 #devsumi #devsumiB
社内スタートアップによる組織の成長に伴い発生する痛みとその解決策について45分拡大版 #devsumi #devsumiBItsuki Kuroda
 
45分間で「ユーザー中心のものづくり」ができるまで詰め込む
45分間で「ユーザー中心のものづくり」ができるまで詰め込む45分間で「ユーザー中心のものづくり」ができるまで詰め込む
45分間で「ユーザー中心のものづくり」ができるまで詰め込むYoshiki Hayama
 
アジャイル開発とメトリクス
アジャイル開発とメトリクスアジャイル開発とメトリクス
アジャイル開発とメトリクスRakuten Group, Inc.
 
LayerXのQAチームで目指したい動き方 (社内資料)
LayerXのQAチームで目指したい動き方 (社内資料)LayerXのQAチームで目指したい動き方 (社内資料)
LayerXのQAチームで目指したい動き方 (社内資料)mosa siru
 
価値探索 -仮説検証の実践-
価値探索 -仮説検証の実践-価値探索 -仮説検証の実践-
価値探索 -仮説検証の実践-toshihiro ichitani
 
エンジニアの個人ブランディングと技術組織
エンジニアの個人ブランディングと技術組織エンジニアの個人ブランディングと技術組織
エンジニアの個人ブランディングと技術組織Takafumi ONAKA
 
Leanstartupをリーンにヤル #リーンスタートアップ
Leanstartupをリーンにヤル #リーンスタートアップLeanstartupをリーンにヤル #リーンスタートアップ
Leanstartupをリーンにヤル #リーンスタートアップItsuki Kuroda
 
リーンスタートアップと顧客開発とアジャイル開発を一気通貫するッ #devlove #devkan
リーンスタートアップと顧客開発とアジャイル開発を一気通貫するッ #devlove #devkanリーンスタートアップと顧客開発とアジャイル開発を一気通貫するッ #devlove #devkan
リーンスタートアップと顧客開発とアジャイル開発を一気通貫するッ #devlove #devkanItsuki Kuroda
 
4つの戦犯から考えるサービスづくりの失敗
4つの戦犯から考えるサービスづくりの失敗4つの戦犯から考えるサービスづくりの失敗
4つの戦犯から考えるサービスづくりの失敗toshihiro ichitani
 
JaSST Tokyo 2022 アジャイルソフトウェア開発への統計的品質管理の応用
JaSST Tokyo 2022 アジャイルソフトウェア開発への統計的品質管理の応用JaSST Tokyo 2022 アジャイルソフトウェア開発への統計的品質管理の応用
JaSST Tokyo 2022 アジャイルソフトウェア開発への統計的品質管理の応用Akinori SAKATA
 
プロダクトオーナーが知るべき97のこと
プロダクトオーナーが知るべき97のことプロダクトオーナーが知るべき97のこと
プロダクトオーナーが知るべき97のことtoshihiro ichitani
 
どうする計画駆動型スクラム(スクラムフェス大阪2023 発表資料)
どうする計画駆動型スクラム(スクラムフェス大阪2023 発表資料)どうする計画駆動型スクラム(スクラムフェス大阪2023 発表資料)
どうする計画駆動型スクラム(スクラムフェス大阪2023 発表資料)NTT DATA Technology & Innovation
 
ゼロからはじめるプロダクトマネージャー生活
ゼロからはじめるプロダクトマネージャー生活ゼロからはじめるプロダクトマネージャー生活
ゼロからはじめるプロダクトマネージャー生活Takaaki Umada
 

What's hot (20)

Lean coffee
Lean coffeeLean coffee
Lean coffee
 
フロー効率性とリソース効率性、再入門 #devlove #devkan
フロー効率性とリソース効率性、再入門 #devlove #devkanフロー効率性とリソース効率性、再入門 #devlove #devkan
フロー効率性とリソース効率性、再入門 #devlove #devkan
 
カネとAgile(大企業新規事業編) #rsgt2021
カネとAgile(大企業新規事業編) #rsgt2021カネとAgile(大企業新規事業編) #rsgt2021
カネとAgile(大企業新規事業編) #rsgt2021
 
アジャイル開発におけるクラフトマンシップの重要性
アジャイル開発におけるクラフトマンシップの重要性アジャイル開発におけるクラフトマンシップの重要性
アジャイル開発におけるクラフトマンシップの重要性
 
開発速度が速い #とは(LayerX社内資料)
開発速度が速い #とは(LayerX社内資料)開発速度が速い #とは(LayerX社内資料)
開発速度が速い #とは(LayerX社内資料)
 
アジャイルメトリクス実践ガイド
アジャイルメトリクス実践ガイドアジャイルメトリクス実践ガイド
アジャイルメトリクス実践ガイド
 
リーン開発の本質 公開用
リーン開発の本質 公開用リーン開発の本質 公開用
リーン開発の本質 公開用
 
社内スタートアップによる組織の成長に伴い発生する痛みとその解決策について45分拡大版 #devsumi #devsumiB
社内スタートアップによる組織の成長に伴い発生する痛みとその解決策について45分拡大版 #devsumi #devsumiB社内スタートアップによる組織の成長に伴い発生する痛みとその解決策について45分拡大版 #devsumi #devsumiB
社内スタートアップによる組織の成長に伴い発生する痛みとその解決策について45分拡大版 #devsumi #devsumiB
 
45分間で「ユーザー中心のものづくり」ができるまで詰め込む
45分間で「ユーザー中心のものづくり」ができるまで詰め込む45分間で「ユーザー中心のものづくり」ができるまで詰め込む
45分間で「ユーザー中心のものづくり」ができるまで詰め込む
 
アジャイル開発とメトリクス
アジャイル開発とメトリクスアジャイル開発とメトリクス
アジャイル開発とメトリクス
 
LayerXのQAチームで目指したい動き方 (社内資料)
LayerXのQAチームで目指したい動き方 (社内資料)LayerXのQAチームで目指したい動き方 (社内資料)
LayerXのQAチームで目指したい動き方 (社内資料)
 
価値探索 -仮説検証の実践-
価値探索 -仮説検証の実践-価値探索 -仮説検証の実践-
価値探索 -仮説検証の実践-
 
エンジニアの個人ブランディングと技術組織
エンジニアの個人ブランディングと技術組織エンジニアの個人ブランディングと技術組織
エンジニアの個人ブランディングと技術組織
 
Leanstartupをリーンにヤル #リーンスタートアップ
Leanstartupをリーンにヤル #リーンスタートアップLeanstartupをリーンにヤル #リーンスタートアップ
Leanstartupをリーンにヤル #リーンスタートアップ
 
リーンスタートアップと顧客開発とアジャイル開発を一気通貫するッ #devlove #devkan
リーンスタートアップと顧客開発とアジャイル開発を一気通貫するッ #devlove #devkanリーンスタートアップと顧客開発とアジャイル開発を一気通貫するッ #devlove #devkan
リーンスタートアップと顧客開発とアジャイル開発を一気通貫するッ #devlove #devkan
 
4つの戦犯から考えるサービスづくりの失敗
4つの戦犯から考えるサービスづくりの失敗4つの戦犯から考えるサービスづくりの失敗
4つの戦犯から考えるサービスづくりの失敗
 
JaSST Tokyo 2022 アジャイルソフトウェア開発への統計的品質管理の応用
JaSST Tokyo 2022 アジャイルソフトウェア開発への統計的品質管理の応用JaSST Tokyo 2022 アジャイルソフトウェア開発への統計的品質管理の応用
JaSST Tokyo 2022 アジャイルソフトウェア開発への統計的品質管理の応用
 
プロダクトオーナーが知るべき97のこと
プロダクトオーナーが知るべき97のことプロダクトオーナーが知るべき97のこと
プロダクトオーナーが知るべき97のこと
 
どうする計画駆動型スクラム(スクラムフェス大阪2023 発表資料)
どうする計画駆動型スクラム(スクラムフェス大阪2023 発表資料)どうする計画駆動型スクラム(スクラムフェス大阪2023 発表資料)
どうする計画駆動型スクラム(スクラムフェス大阪2023 発表資料)
 
ゼロからはじめるプロダクトマネージャー生活
ゼロからはじめるプロダクトマネージャー生活ゼロからはじめるプロダクトマネージャー生活
ゼロからはじめるプロダクトマネージャー生活
 

Similar to 大企業アジャイルの勘所(ver1.1) #アジャイルマネジメントセミナー

ごった煮じゃNight!vol.1
ごった煮じゃNight!vol.1ごった煮じゃNight!vol.1
ごった煮じゃNight!vol.1Satoshi Furuichi
 
機械学習の課題設定講座
機械学習の課題設定講座機械学習の課題設定講座
機械学習の課題設定講座幹雄 小川
 
To cf e_06_中谷_職場の改革は教育のためのtocから
To cf e_06_中谷_職場の改革は教育のためのtocからTo cf e_06_中谷_職場の改革は教育のためのtocから
To cf e_06_中谷_職場の改革は教育のためのtocからTOC for Education, Japan Branch
 
失敗から学ぶ?、教科書には書いてあるけど、現場でしか学べないこと.pdf
失敗から学ぶ?、教科書には書いてあるけど、現場でしか学べないこと.pdf失敗から学ぶ?、教科書には書いてあるけど、現場でしか学べないこと.pdf
失敗から学ぶ?、教科書には書いてあるけど、現場でしか学べないこと.pdfRakuten Commerce Tech (Rakuten Group, Inc.)
 
三年後のエンジニアがもっているとお得な資質
三年後のエンジニアがもっているとお得な資質三年後のエンジニアがもっているとお得な資質
三年後のエンジニアがもっているとお得な資質Tsuyoshi Ushio
 
はじめてのアジャイル - Agile in a nutshell
はじめてのアジャイル - Agile in a nutshellはじめてのアジャイル - Agile in a nutshell
はじめてのアジャイル - Agile in a nutshellDai FUJIHARA
 
アジャイルマネジメントとマインドセット 〜ヒーローを待っていても世界は変わらない〜
アジャイルマネジメントとマインドセット 〜ヒーローを待っていても世界は変わらない〜アジャイルマネジメントとマインドセット 〜ヒーローを待っていても世界は変わらない〜
アジャイルマネジメントとマインドセット 〜ヒーローを待っていても世界は変わらない〜Dai FUJIHARA
 
ふつうの受託開発チームのつくりかた
ふつうの受託開発チームのつくりかたふつうの受託開発チームのつくりかた
ふつうの受託開発チームのつくりかたYoshitaka Kawashima
 
非開発者のためのアジャイル開発入門
非開発者のためのアジャイル開発入門非開発者のためのアジャイル開発入門
非開発者のためのアジャイル開発入門Kiro Harada
 
GCSアジャイル開発を使ったゲームの作り方
 GCSアジャイル開発を使ったゲームの作り方 GCSアジャイル開発を使ったゲームの作り方
GCSアジャイル開発を使ったゲームの作り方Hiroyuki Tanaka
 
アジャイル開発の現在・過去・未来~今を知り、源流を訪ね、先を見据える~
アジャイル開発の現在・過去・未来~今を知り、源流を訪ね、先を見据える~アジャイル開発の現在・過去・未来~今を知り、源流を訪ね、先を見据える~
アジャイル開発の現在・過去・未来~今を知り、源流を訪ね、先を見据える~Kenji Hiranabe
 
50代現役SEのつぶやき
50代現役SEのつぶやき50代現役SEのつぶやき
50代現役SEのつぶやきKenichi Yamada
 
アジャイルマネジメントとは?
アジャイルマネジメントとは?アジャイルマネジメントとは?
アジャイルマネジメントとは?Kiro Harada
 
Scrum-Fest-Sapporo-2021-Keynote-Our-Journey
Scrum-Fest-Sapporo-2021-Keynote-Our-JourneyScrum-Fest-Sapporo-2021-Keynote-Our-Journey
Scrum-Fest-Sapporo-2021-Keynote-Our-JourneyKenji Hiranabe
 
クラウド事業者に求めるビジネス要件
クラウド事業者に求めるビジネス要件クラウド事業者に求めるビジネス要件
クラウド事業者に求めるビジネス要件雄哉 吉田
 
2015-10-31 クラウドネイティヴ時代の運用を考える 〜 ドキュメント駆動運用へ
2015-10-31 クラウドネイティヴ時代の運用を考える  〜 ドキュメント駆動運用へ2015-10-31 クラウドネイティヴ時代の運用を考える  〜 ドキュメント駆動運用へ
2015-10-31 クラウドネイティヴ時代の運用を考える 〜 ドキュメント駆動運用へOperation Lab, LLC.
 
リーンスタートアップ入門
リーンスタートアップ入門リーンスタートアップ入門
リーンスタートアップ入門Yoshihito Kuranuki
 

Similar to 大企業アジャイルの勘所(ver1.1) #アジャイルマネジメントセミナー (20)

ごった煮じゃNight!vol.1
ごった煮じゃNight!vol.1ごった煮じゃNight!vol.1
ごった煮じゃNight!vol.1
 
A Lean UX Workshop
A Lean UX WorkshopA Lean UX Workshop
A Lean UX Workshop
 
機械学習の課題設定講座
機械学習の課題設定講座機械学習の課題設定講座
機械学習の課題設定講座
 
To cf e_06_中谷_職場の改革は教育のためのtocから
To cf e_06_中谷_職場の改革は教育のためのtocからTo cf e_06_中谷_職場の改革は教育のためのtocから
To cf e_06_中谷_職場の改革は教育のためのtocから
 
失敗から学ぶ?、教科書には書いてあるけど、現場でしか学べないこと.pdf
失敗から学ぶ?、教科書には書いてあるけど、現場でしか学べないこと.pdf失敗から学ぶ?、教科書には書いてあるけど、現場でしか学べないこと.pdf
失敗から学ぶ?、教科書には書いてあるけど、現場でしか学べないこと.pdf
 
三年後のエンジニアがもっているとお得な資質
三年後のエンジニアがもっているとお得な資質三年後のエンジニアがもっているとお得な資質
三年後のエンジニアがもっているとお得な資質
 
はじめてのアジャイル - Agile in a nutshell
はじめてのアジャイル - Agile in a nutshellはじめてのアジャイル - Agile in a nutshell
はじめてのアジャイル - Agile in a nutshell
 
はじめてのアジャイル
はじめてのアジャイルはじめてのアジャイル
はじめてのアジャイル
 
Agile Overview In Ono
Agile Overview In OnoAgile Overview In Ono
Agile Overview In Ono
 
アジャイルマネジメントとマインドセット 〜ヒーローを待っていても世界は変わらない〜
アジャイルマネジメントとマインドセット 〜ヒーローを待っていても世界は変わらない〜アジャイルマネジメントとマインドセット 〜ヒーローを待っていても世界は変わらない〜
アジャイルマネジメントとマインドセット 〜ヒーローを待っていても世界は変わらない〜
 
ふつうの受託開発チームのつくりかた
ふつうの受託開発チームのつくりかたふつうの受託開発チームのつくりかた
ふつうの受託開発チームのつくりかた
 
非開発者のためのアジャイル開発入門
非開発者のためのアジャイル開発入門非開発者のためのアジャイル開発入門
非開発者のためのアジャイル開発入門
 
GCSアジャイル開発を使ったゲームの作り方
 GCSアジャイル開発を使ったゲームの作り方 GCSアジャイル開発を使ったゲームの作り方
GCSアジャイル開発を使ったゲームの作り方
 
アジャイル開発の現在・過去・未来~今を知り、源流を訪ね、先を見据える~
アジャイル開発の現在・過去・未来~今を知り、源流を訪ね、先を見据える~アジャイル開発の現在・過去・未来~今を知り、源流を訪ね、先を見据える~
アジャイル開発の現在・過去・未来~今を知り、源流を訪ね、先を見据える~
 
50代現役SEのつぶやき
50代現役SEのつぶやき50代現役SEのつぶやき
50代現役SEのつぶやき
 
アジャイルマネジメントとは?
アジャイルマネジメントとは?アジャイルマネジメントとは?
アジャイルマネジメントとは?
 
Scrum-Fest-Sapporo-2021-Keynote-Our-Journey
Scrum-Fest-Sapporo-2021-Keynote-Our-JourneyScrum-Fest-Sapporo-2021-Keynote-Our-Journey
Scrum-Fest-Sapporo-2021-Keynote-Our-Journey
 
クラウド事業者に求めるビジネス要件
クラウド事業者に求めるビジネス要件クラウド事業者に求めるビジネス要件
クラウド事業者に求めるビジネス要件
 
2015-10-31 クラウドネイティヴ時代の運用を考える 〜 ドキュメント駆動運用へ
2015-10-31 クラウドネイティヴ時代の運用を考える  〜 ドキュメント駆動運用へ2015-10-31 クラウドネイティヴ時代の運用を考える  〜 ドキュメント駆動運用へ
2015-10-31 クラウドネイティヴ時代の運用を考える 〜 ドキュメント駆動運用へ
 
リーンスタートアップ入門
リーンスタートアップ入門リーンスタートアップ入門
リーンスタートアップ入門
 

More from Itsuki Kuroda

カネとAgile #RSGT2018
カネとAgile #RSGT2018カネとAgile #RSGT2018
カネとAgile #RSGT2018Itsuki Kuroda
 
LEANSTARTUPアンチパターン #devlove #leanstartup
LEANSTARTUPアンチパターン #devlove #leanstartupLEANSTARTUPアンチパターン #devlove #leanstartup
LEANSTARTUPアンチパターン #devlove #leanstartupItsuki Kuroda
 
日経BPリーン式創業塾 #leanstartup #リーンスタートアップ
日経BPリーン式創業塾 #leanstartup #リーンスタートアップ日経BPリーン式創業塾 #leanstartup #リーンスタートアップ
日経BPリーン式創業塾 #leanstartup #リーンスタートアップItsuki Kuroda
 
LEAN STARTUP OVERVIEW
LEAN STARTUP OVERVIEWLEAN STARTUP OVERVIEW
LEAN STARTUP OVERVIEWItsuki 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 (15)

カネとAgile #RSGT2018
カネとAgile #RSGT2018カネとAgile #RSGT2018
カネとAgile #RSGT2018
 
LEANSTARTUPアンチパターン #devlove #leanstartup
LEANSTARTUPアンチパターン #devlove #leanstartupLEANSTARTUPアンチパターン #devlove #leanstartup
LEANSTARTUPアンチパターン #devlove #leanstartup
 
日経BPリーン式創業塾 #leanstartup #リーンスタートアップ
日経BPリーン式創業塾 #leanstartup #リーンスタートアップ日経BPリーン式創業塾 #leanstartup #リーンスタートアップ
日経BPリーン式創業塾 #leanstartup #リーンスタートアップ
 
LEAN STARTUP OVERVIEW
LEAN STARTUP OVERVIEWLEAN STARTUP OVERVIEW
LEAN STARTUP OVERVIEW
 
エンジニアが成長のエンジンになる日 #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ハッカソン発表資料
 

大企業アジャイルの勘所(ver1.1) #アジャイルマネジメントセミナー