リーンスタートアップとスマートなエンジニアリングの葛藤 2017/06改訂版 #bpstudy #agilejapan #postudy

リーンスタートアップとスマートな
エンジニアリングの葛藤
2017/06 改訂版
グロースエクスパートナーズ株式会社
関満徳

撮影可録音可
Copyright© Growth xPartners, Inc. All rights reserved. 1

今日お話したいこと
• 「リーンスタートアップ」と「スマートなエン
ジニアリング」の間に生じるズレや葛藤
• 企画サイドや開発サイドがこの悩みに対しどの
ように動くべきか

アジェンダ
• 今、起きていること
• ズレや葛藤について考える
• どう動くとよさそうか
• まとめ

アジェンダ
• まとめ

• 「作る」から「使い続ける」へ
• モノとコトの実現プロセス
今、起きていること

参考資料(1/1)
– モノ消費ではなくコト消費の時代へ
» http://www.nikkeibp.co.jp/article/matome/20140220/384639/
– Naoya Ito - System of Record と System of Engagement
» https://speakerdeck.com/player/3be8af3598db45c6b16dc19a98c
cecd6?slide=4#
– 赤間信幸 - 拝啓『変わらない開発現場』を嘆く皆様へ
～変わっていくエンタープライズ系業務システム開発とマイ
クロソフトエンタープライズサービスの取り組み～
» https://blogs.msdn.microsoft.com/nakama/2017/05/25/devmod
ernization/
– 小野和俊 - わたしのバイモーダル戦略
» http://blog.livedoor.jp/lalha/archives/50524676.html
– 十返文子 - プロジェクトマネジメント再入門
～PjMは何であって何でないのか～
» https://www.slideshare.net/togaeri/pjm-72819087/12
Copyright© POStudy ～アジャイル・プロダクトマネジメント研究会～. All rights reserved. 6

「作る」から「使い続ける」へ
• モノからコトへのパラダイムシフト
–幅広い業界で市場は成熟し、すでに必要なモノは
ほとんど手に入った
–人々の関心はモノの所有欲を満たすことから、
経験、思い出、人間関係、サービスなどの
目に見えない価値であるコトに移行してきている
Copyright© POStudy ～アジャイル・プロダクトマネジメント研究会～. All rights reserved. 8モノ消費ではなくコト消費の時代へ http://www.nikkeibp.co.jp/article/matome/20140220/384639/

–モノを作る
–作ったモノを使い続けてコトを得る

–一度作ったモノは、作ったらおしまい
–目に見えない価値であるコトは変わっていくので、
追随していく必要がある

–一度作ったモノは、成長しない
–一度作ったモノは、リリース後も成長し続ける
リリース1回目
↓
リリースn回目
↓
成
長
度
時間
成長しない
成長し続ける

–一度作ってリリースしたら、改修されない
–リリース後も改修し続ける
リリース1回目
↓
リリースn回目
↓
成
長
度
改修されない
改修し続ける
時間

–モノの提供＝数年間に一度のリリースの時代
–コトの提供＝数ヶ月/数週間/数日に1回、または
1日数回のリリースの時代へ
時間
時間
リ
リ
ー
ス
リ
リ
ー
ス

–単一リリースのためのアーキテクチャ
単一リリース
アーキテクチャ
–複数リリース毎に改善するアーキテクチャ
複数リリース
改善するアーキテクチャ
…

–単一プロジェクトのためのプロダクトマネジメント
単一プロジェクト
プロダクトマネジメント
–複数プロジェクトに跨がるプロダクトマネジメント
複数プロジェクト
プロダクトマネジメント
…

• マネジメント領域における役割
プロダクト
マネジメント
（PdM）
Do the right thing:
正しいことをする
プロダクト・マネージャー
プロダクト・オーナー
リーダー
プロジェクト
マネジメント
（PjM）
Do things right:
正しく実行する
プロジェクト・マネジャー
マネジャー
十返文子 - プロジェクトマネジメント再入門～PjMは何であって何でないのか～ https://www.slideshare.net/togaeri/pjm-72819087/14

• マネジメント領域におけるマネジメント対象
プロジェクトマネジメントプロダクトマネジメント
スコープ
マネジメント
コスト
マネジメント
コミュニ
ケーション
マネジメント
統合
マネジメント
ステーク
ホルダー
マネジメント
リスク
マネジメント
調達
マネジメント
資源
マネジメント
タイム
マネジメント
品質
マネジメント
What
How How
much
When
HowHow How
Why
How
WhoWhere
プロダクト
マネジメント
顧客（市場）
マネジメント
What Who
Who
ほぼ一緒？
やや重なる？
＝分析・戦略…
十返文子 - プロジェクトマネジメント再入門～PjMは何であって何でないのか～ https://www.slideshare.net/togaeri/pjm-72819087/12

• SoR (System of Record)
–情報を正しく「記録」するためのシステム
–想起するもの･･･バックエンド、予約、在庫、カー
ド決済、ポイント処理、管理画面
• SoE (System of Engagement)
–ユーザーや取引先との「絆」を作るためのシステム
–想起するもの･･･ UI、デザイン、アプリ、スマート
フォン、ダイレクトマーケティング、CRM
Copyright© POStudy ～アジャイル・プロダクトマネジメント研究会～. All rights reserved. 18Naoya Ito - System of Record と System of Engagement https://speakerdeck.com/player/3be8af3598db45c6b16dc19a98ccecd6?slide=4#

SoR 型システム（モード1） SoE 型システム（モード2）
用語 • System of Record • System of Engagement
定義
• 事実を記録することに主眼を置いたシステ
ム・サービス
• お客様との関係（絆）を強化するための
システム・サービス
主役 • データ • 利用者
システム領域
• バックエンド
• 認証、在庫管理、決済、個人情報保護
• フロントエンド、スマートフォンアプリ
• UI、CRM、ダイレクトメール
開発手法
• 比較的ウォーターフォール寄り
• 開発前に要件を明確に定義
• 品質の確保を優先
• 比較的アジャイル、リーン寄り
• トライ&エラーで正しい問題・論点を
探り当てる
• 迅速なリリースを優先
性向 / 適合
• 安定性重視
• 予測可能業務
• リスクを抑えて安全運転
• 要件を事前に明確化
• ユーザーインタフェース品質、開発速度重視
• 探索型業務
• スピード重視で運転
• トライ&エラー、プロトタイピング
マネジメント
• トップダウン寄り
• 「正しい仕様」に基づいたプロジェクト管理
• 経営や開発部門が主導することが多い
• ボトムアップ寄り
• 「正しい仕様」は存在しない
• マーケティング、デザインが主導することも
ケイパ
ビリティ
• 要件定義力、調整力、プロジェクトマネジメ
ント
• SIのみなさんが得意そう
• ユーザー視点、デザイン思考、アナリティク
ス
• Web系が得意そうケイパビリティ
Naoya Ito - System of Record と System of Engagement https://speakerdeck.com/player/3be8af3598db45c6b16dc19a98ccecd6?slide=4#
赤間信幸 - 拝啓『変わらない開発現場』を嘆く皆様へ～変わっていくエンタープライズ系業務システム開発とマイクロソフトエンタープライズサービスの取り組み～ https://blogs.msdn.microsoft.com/nakama/2017/05/25/devmodernization/

• バイモーダルで実現する企業IT
モード1
方向
転換
馬力
モード2
小野和俊 - わたしのバイモーダル戦略 http://blog.livedoor.jp/lalha/archives/50524676.html

モノとコトの実現プロセス
• 日本的プロダクトオーナーの現状
スクラム
マスター
開発チーム
開発
日本的プロダクトオーナー
経営層
情シス
営業
広報ｺｰﾙｾﾝﾀｰ
現場
作業者管理
部門
法務
財務
顧客
意思決定
促進
現場調整
Dev/Ops
視点
ビジネス
視点
意思決定者
現場
日本的プロダクトオーナーの苦労のポイ
ント
日本的プロダクトオーナーは、スクラ
ムで定義されるプロダクトオーナーより、
より多く、複数の視点の結節点で調整力
を求められる場面が多い。
プロダクトオーナーの現状
プロダクトオーナーは、様々な部
署から任命されることが多く、実
は必要なスキルや経験と案件が
マッチしていないことも多い。

なぜ
やるべきか
土台
づくり
使い続け
させる作って
仮説検証
作る計画を
立てて
作る計画を
まわす
作らずに
仮説検証
作る
WHY
HOW
アイ
ディア
モノ
コト
データ計測
する
学習
する
構築
する
アイ
ディア
モノ
コト
データ
計測
する
学習
する
構築
する
WHAT

なぜ
やるべきか
土台
づくり
使い続け
させる作って
仮説検証
作る計画を
立てて
作る計画を
まわす
作らずに
仮説検証
作る
WHY
HOW
アイ
ディア
モノ
コト
データ計測
する
学習
する
構築
する
アイ
ディア
モノ
コト
データ
計測
する
学習
する
構築
する
WHAT
リーン
スクラム
アーキ
テクチャ
本番運用

プロダクト
Log
仮説スプリント
計画
ふりかえり
スプリント
スプリント
バックログ
デイリー
スクラム
プロダクト
バックログ
評価用
成果物
仮説検討
価値検討仕様検討
オポチュニティ
バックログ
価値評価
リーン
キャンバス
.....
:::::
:::::
:::::
:::::
:::::
:::::
.....
:::::
:::::
:::::
:::::
:::::
:::::
.....
:::::
:::::
:::::
:::::
:::::
:::::
ペルソナ
カスタマー
ジャーニーマップ
インセプション
デッキ
サービス
ブループリント
設計
アーキテクチャビジョン
& デザイン設計
テクニカル
ソリューション技術
検討
スプリント
レビュー
ToDo Ready In Progress Done Feedback
かんばん
価値計測出荷
プロダクト
利用

プロダクト
Log
計画
ふりかえり
スプリント
スプリント
バックログ
デイリー
スクラム
プロダクト
バックログ
評価用
成果物
仮説検討
バックログ
価値評価
リーン
キャンバス
.....
:::::
:::::
:::::
:::::
:::::
:::::
.....
:::::
:::::
:::::
:::::
:::::
:::::
.....
:::::
:::::
:::::
:::::
:::::
:::::
ペルソナ
カスタマー
デッキ
サービス
設計
テクニカル
検討
スプリント
レビュー
かんばん
価値計測出荷
プロダクト
利用
リーン
スクラム
アーキ
テクチャ
本番運用

なぜ
やるべきか
土台
づくり
使い続け
させる作って
仮説検証
作る計画を
立てて
作る計画を
まわす
作らずに
仮説検証
作る
WHY
HOW
アイ
ディア
モノ
コト
データ計測
する
学習
する
構築
する
アイ
ディア
モノ
コト
データ
計測
する
学習
する
構築
する
WHAT
思い込みにより発生
する各種ムダを省く
ためにリーンにやる
ムダなモノを省き
必要なモノを素早く
作り続ける
エンジニアリング
モノを支え
るアーキ
テクチャ
ムダなく本番運用を
まわし続ける

なぜ
やるべきか
土台
づくり
使い続け
させる作って
仮説検証
作る計画を
立てて
作る計画を
まわす
作らずに
仮説検証
作る
WHY
HOW
アイ
ディア
モノ
コト
データ計測
する
学習
する
構築
する
アイ
ディア
モノ
コト
データ
計測
する
学習
する
構築
する
WHAT
やりたいコト
用意しなければなら
ないモノ
用意しな
ければなら
ないモノ
対応しなければ
ならないコト

なぜ
やるべきか
土台
づくり
使い続け
させる作って
仮説検証
作る計画を
立てて
作る計画を
まわす
作らずに
仮説検証
作る
WHY
HOW
アイ
ディア
モノ
コト
データ計測
する
学習
する
構築
する
アイ
ディア
モノ
コト
データ
計測
する
学習
する
構築
する
WHAT
やりたいコト
ないモノ
用意しな
ければなら
ないモノ
葛藤
葛藤
ならないコト

アジェンダ
• まとめ

• アーキテクチャから見た葛藤
• リーンから見た葛藤
ズレや葛藤について考える

アーキテクチャ設計から見た葛藤
なぜ
やるべきか
土台
づくり
使い続け
させる作って
仮説検証
作る計画を
立てて
作る計画を
まわす
作らずに
仮説検証
作る
WHY
HOW
アイ
ディア
モノ
コト
データ計測
する
学習
する
構築
する
アイ
ディア
モノ
コト
データ
計測
する
学習
する
構築
する
WHAT
やりたいコト
ないモノ
用意しな
ければなら
ないモノ
葛藤
ならないコト

なぜ
やるべきか
土台
づくり
使い続け
させる作って
仮説検証
作る計画を
立てて
作る計画を
まわす
作らずに
仮説検証
作る
WHY
HOW
アイ
ディア
モノ
コト
データ計測
する
学習
する
構築
する
アイ
ディア
モノ
コト
データ
計測
する
学習
する
構築
する
WHAT
やりたいコト
ないモノ
用意しな
ければなら
ないモノ
葛藤
アーキテクチャ設計の
ジレンマ
ならないコト

• アーキテクチャ設計とは
–システムの構造と振る舞いを定義すること
» 構造システムの分け方と組み方
» 振る舞い稼働しているシステムが利用できる状態で
外部に対して行うこと
IT
サービス
機能
非機能
静的構造
動的構造
構造のパターン振る舞い

• 構造と振る舞いの関係
» 静的構造時間軸にとらわれない要素の配置と関係性
» 動的構造時間軸の中で現れる要素の配置と関係性
» 機能インプットに対するアウトプット
» 非機能振る舞いの質
IT
サービス
機能
非機能
静的構造
動的構造
構造のパターン振る舞い

• 構造と振る舞いの関係
振る舞いの
初期要求
システム開発の流れ
振る舞い
振る舞い
システムの設計
システムの実装
システムのテスト
アーキテクチャの
設計構造構造構造定義定義
参照
参照
定義
実現
確認
利用
評価

• アーキテクチャ設計のジレンマ
–本来はシステムを作り始める前にアーキテクチャを
定義すべき
–その時点で得られる要求が正しいかわからない
振る舞いの
初期要求
システム開発の流れ
振る舞い
振る舞い
システムの設計
システムの実装
アーキテクチャの
設計構造構造構造定義定義
参照
参照
定義
実現
利用

• アーキテクチャ設計のジレンマ
–要求が定まらなければ構造が決まらない
–要求を定めるためには作らなければならない
–作るためには構造が決まっていないといけない
振る舞いの
初期要求
構造振る舞い
構造が決まって
いないと作れない
振る舞いを見ないと
要求がわからない
要求が曖昧では
決定できない

リーンから見た葛藤
なぜ
やるべきか
土台
づくり
使い続け
させる作って
仮説検証
作る計画を
立てて
作る計画を
まわす
作らずに
仮説検証
作る
WHY
HOW
アイ
ディア
モノ
コト
データ計測
する
学習
する
構築
する
アイ
ディア
モノ
コト
データ
計測
する
学習
する
構築
する
WHAT
やりたいコト
ないモノ
用意しな
ければなら
ないモノ
葛藤
ならないコト

なぜ
やるべきか
土台
づくり
使い続け
させる作って
仮説検証
作る計画を
立てて
作る計画を
まわす
作らずに
仮説検証
作る
WHY
HOW
アイ
ディア
モノ
コト
データ計測
する
学習
する
構築
する
アイ
ディア
モノ
コト
データ
計測
する
学習
する
構築
する
WHAT
やりたいコト
ないモノ
用意しな
ければなら
ないモノ
やりたいコトのサイクルと
用意するサイクルの
タイミングがあわない
用意するサイクルに
乗らないタスクは
どうすればいいのか
葛藤
ならないコト

アジェンダ
• まとめ

• アーキテクチャ設計でできること
• リーンでできること
• 改善活動でできること
どう動くとよさそうか

なぜ
やるべきか
土台
づくり
使い続け
させる作って
仮説検証
作る計画を
立てて
作る計画を
まわす
作らずに
仮説検証
作る
WHY
HOW
アイ
ディア
モノ
コト
データ計測
する
学習
する
構築
する
アイ
ディア
モノ
コト
データ
計測
する
学習
する
構築
する
WHAT
やりたいコト
ないモノ
用意しな
ければなら
ないモノ
葛藤
アーキテクチャ設計の
ジレンマ
ならないコト

アーキテクチャ設計でできること
• ジレンマに対するアーキテクチャ戦略
–戦略1 変化に対応出来る構造の導入
–戦略2 構造パターン追加への対応
–戦略3 犠牲的な構造パターンの導入

• 戦略1 変化に対応出来る構造の導入
–要求の変化を可能な限り予測
–変化に対応出来る構造にしておく
構造
機能A 機能B 機能C
構造
機能A
変化を予測し、
変化に対応出来る作りにする
変化に合わせて
機能を追加していく

構造
構造
機能A
変化を予測し、
変化に対応出来る作りにする
メリットデメリット
【戦略1】
変化に対応出来る
構造の導入
変化に効率的に
対応出来る
変化が発生しない
と保守的に大きな
影響が出る

• 戦略2 構造パターン追加への対応
–構造パターンの追加に対応できるようにしておく
構造1
構造1
機能A
機能に適した構造を用意するが、
構造の拡張性を残す
構造2

構造1
構造1
機能A
機能に適した構造を用意するが、
構造の拡張性を残す
構造2
【戦略2】
構造パターン追加
への対応
変化が発生した
時点で適切な構造
を導入できる
使われなくなった
構造パターンが
技術的負債となる

• 戦略3 犠牲的な構造パターンの導入
–意図的に簡易的な構造パターンを導入
–本当に必要になったタイミングで作り直すことを
前提
構造2
構造1
機能A
機能に適した構造を用意し、
最小限な機能にしていく
変化に合わせて機能と
構造を追加していく
機能A
構造1

構造2
構造1
機能A
機能に適した構造を用意し、
最小限な機能にしていく
変化に合わせて機能と
構造を追加していく
機能A
構造1
【戦略3】
犠牲的な構造
パターンの導入
もっと効率的に
実装できる
早く限界が来て
しまうと作り直す
無駄が出る

• 戦略のメリットとデメリットまとめ
【戦略1】
変化に対応出来る
構造の導入
変化に効率的に
対応出来る
変化が発生しない
と保守的に大きな
影響が出る
【戦略2】
構造パターン追加
への対応
変化が発生した
時点で適切な構造
を導入できる
使われなくなった
構造パターンが
技術的負債となる
【戦略3】
犠牲的な構造
パターンの導入
もっと効率的に
実装できる
早く限界が来て
しまうと作り直す
無駄が出る

なぜ
やるべきか
土台
づくり
使い続け
させる作って
仮説検証
作る計画を
立てて
作る計画を
まわす
作らずに
仮説検証
作る
WHY
HOW
アイ
ディア
モノ
コト
データ計測
する
学習
する
構築
する
アイ
ディア
モノ
コト
データ
計測
する
学習
する
構築
する
WHAT
やりたいコト
ないモノ
用意しな
ければなら
ないモノ
やりたいコトのサイクルと
用意するサイクルの
タイミングがあわない
用意するサイクルに
乗らないタスクは
どうすればいいのか
葛藤
ならないコト

リーンでできること
• 管理するものを分類する
• リズムを合わせて見通しを共有する

管理するものを分類する
なぜ
やるべきか
土台
づくり
使い続け
させる作って
仮説検証
作る計画を
立てて
作る計画を
まわす
作らずに
仮説検証
作る
WHY
HOW
アイ
ディア
モノ
コト
データ計測
する
学習
する
構築
する
アイ
ディア
モノ
コト
データ
計測
する
学習
する
構築
する
WHAT
リーン
スクラム
アーキ
テクチャ
本番運用

なぜ
やるべきか
土台
づくり
使い続け
させる作って
仮説検証
作る計画を
立てて
作る計画を
まわす
作らずに
仮説検証
作る
WHY
HOW
アイ
ディア
モノ
コト
データ計測
する
学習
する
構築
する
アイ
ディア
モノ
コト
データ
計測
する
学習
する
構築
する
WHATリーン
スクラム
アーキ
テクチャ
本番運用
スプリント
バックログ
プロダクト
バックログ
バックログ
かんばん
• アイディア出し中
• 問題が本当にあるか確認中
• プロトタイプによる検証中
で、開発着手前のものは、
「オポテュニティバックログ」
で管理
現在、開発チームが
着手中のタスクは
「スプリントバックログ」
で管理
開発計画のサイクルに
入らないタスクは
「かんばん」
で管理
今後開発予定のものは、
「プロダクトバックログ」
で管理

プロダクト
Log
計画
ふりかえり
スプリント
スプリント
バックログ
デイリー
スクラム
プロダクト
バックログ
評価用
成果物
仮説検討
バックログ
価値評価
リーン
キャンバス
.....
:::::
:::::
:::::
:::::
:::::
:::::
.....
:::::
:::::
:::::
:::::
:::::
:::::
.....
:::::
:::::
:::::
:::::
:::::
:::::
ペルソナ
カスタマー
デッキ
サービス
設計
テクニカル
検討
スプリント
レビュー
かんばん
価値計測出荷
プロダクト
利用
リーン
スクラム
アーキ
テクチャ
本番運用
で管理
で管理
で管理
スプリント
バックログ
プロダクト
バックログ
バックログ
かんばん開発計画のサイクルに
入らないタスクは
「かんばん」
で管理

リズムを合わせて見通しを共有する
なぜ
やるべきか
土台
づくり
使い続け
させる作って
仮説検証
作る計画を
立てて
作る計画を
まわす
作らずに
仮説検証
作る
WHY
HOW
アイ
ディア
モノ
コト
データ計測
する
学習
する
構築
する
アイ
ディア
モノ
コト
データ
計測
する
学習
する
構築
する
WHAT
リーン
スクラム
アーキ
テクチャ
本番運用

• 1週間の仕事量
使い続け
させる
作る計画を
立てて
作る計画を
まわす
作る
スクラム
～スプリントバックログ～
本番運用
～かんばん～
月火水木金計
午前 ○ ○ ○ ○ ○
午後1 ○ ○ ○ ○ ○
午後2 ○ ○ ○ ○ ○
1人 3 3 3 3 3 15
5人 15 15 15 15 15 75

• スプリントバックログとかんばんの比率を計画
1スプリント
=2週間
スプリント
X
スプリント
X+1
スプリント
X+2
スプリント
X+3
スプリント
X+4
スプリント
バックログ
100 60 80 100 85
かんばん 50 90 70 50 65
合計
75×2週間=
150 150 150 150 150
本番リリース後は、
障害対応や調査依頼が増えるので
かんばんの割合を増やす
本番リリースがない時は
スプリントバックログの
割合を増やす

• スプリントバックログとかんばんの比率を計画
–数スプリント先／数ヶ月後までの期間
–その結果、企画チームから見れば、
「いつまでに要件を伝えれば、リリースしたい時期
にリリース可能なのかがわかる」
スプリント
X
スプリント
X+1
スプリント
X+2
スプリント
X+3
スプリント
X+4
スプリント
X+5
スプリント
X+6
スプリント
X+7
スプリント
バックログ
100 35 80 100 85 55 80 40
かんばん 50 85 70 50 65 80 70 95
合計 150 120 150 150 150 135 150 135
祝日や予定休・突発休の分だけ
合計ポイントを減らして計画
プロダクトロードマップに
あわせてリリースしたい時期
リリースしたい時期に間に合わせる為に
開発をはじめる時期を、逆算して計画
少なくともこの時期までに企画側内で承認
を取り、Goを出せば良いことがわかる
リリース前の非機能要件等の確認結果への
対応工数を、かんばん側にあらかじめ計画
リリース後の対応工数を
かんばん側に計画

なぜ
やるべきか
土台
づくり
使い続け
させる作って
仮説検証
作る計画を
立てて
作る計画を
まわす
作らずに
仮説検証
作る
WHY
HOW
アイ
ディア
モノ
コト
データ計測
する
学習
する
構築
する
アイ
ディア
モノ
コト
データ
計測
する
学習
する
構築
する
WHATリーン
スクラム
アーキ
テクチャ
本番運用
スプリント
バックログ
プロダクト
バックログ
バックログ
かんばん
で管理
で管理
開発計画のサイクル
に入らないタスクは
「かんばん」
で管理
で管理
次のスプリント計画前までに、
• バックログ見直し
• ユーザーストーリー見直し
• ストーリーテスト作成
• ストーリーポイント見直し
• 価値・リスク観点での優先順位見直し
を実施しておく

プロダクト
Log
計画
ふりかえり
スプリント
スプリント
バックログ
デイリー
スクラム
プロダクト
バックログ
評価用
成果物
仮説検討
バックログ
価値評価
リーン
キャンバス
.....
:::::
:::::
:::::
:::::
:::::
:::::
.....
:::::
:::::
:::::
:::::
:::::
:::::
.....
:::::
:::::
:::::
:::::
:::::
:::::
ペルソナ
カスタマー
デッキ
サービス
設計
テクニカル
検討
スプリント
レビュー
かんばん
価値計測出荷
プロダクト
利用
リーン
スクラム
アーキ
テクチャ
本番運用
で管理
で管理
で管理
スプリント
バックログ
プロダクト
バックログ
バックログ
かんばん開発計画のサイクル
に入らないタスクは
「かんばん」
で管理
次のスプリント計画前までに、
• バックログ見直し
• ユーザーストーリー見直し
• ストーリーテスト作成
• ストーリーポイント見直し
• 価値・リスク観点での優先順位見直し
を実施しておく

改善活動でできること
• ふりかえりを共有する

ふりかえりの進め方
1. ふりかえりの全体説明（6分）
2. 個人ふりかえり（6分）
3. 個人ふりかえりのチーム内共有（6分）
4. チーム別ふりかえり（30分）
5. チーム別ふりかえり結果の共有（15分）
6. ふりかえりのふりかえり（8分）

用意するもの
No. 道具名数必須備考
1 個人ふりかえり（A3）人数分必須
2 サインペン（黒）人数分必須裏写りしにくいペンならなおよい
3 付箋人数分必須
4 模造紙チーム数分必須ホワイトボードでも可
5 養生テープ 2個必須
6 タイマー 1個必須スマフォアプリでも可
7 カメラ 1個必須スマフォアプリでも可
8
9
10
11
12
13

ふりかえりとは

ふりかえりの目的
• もっとうまくできるようにする
–定期的に検査して、ちょっとずつ良くする
• 強制的に仕事を停止する
–強制的に立ち止まって、本当にこのままでいいのか
考える余裕を持つ
–定期的な予定として組み込む

ふりかえりの大前提
• 心理的安全性の確保
–「あなた vs わたし」 → 「問題 vs わたしたち」
–安全でないと、失敗を認めたり、問題を明らかに
したり、新しいことに挑戦しにくくなる
–高い心理的安全性を持つチームは、それぞれが
同じくらいの持ち時間で話す傾向がある
–心理的安全性の確保のため、無記名で実施

ふりかえりのコツ
• 意見ではなく、事実を
–例）品質が悪い
–例）情報共有が不足している
–意見だけをもとにしてアクションを決めると、
本質的な問題が解決しない
–解決策の欠如を問題として語るのは、
場の安全性、チームの信頼の欠如を示すシグナル

個人ふりかえり

個人ふりかえりのステップ
1. 企画チームと開発チームが半分ずつ混合した
グループA・グループBに分かれて着席いただ
いた後、個人でふりかえりをします
2. チーム内で、個人ふりかえり結果を
共有します
グループA グループB
スクリーン

個人ふりかえり
スプリントを通し
て、今回私が改善
できたこと
スプリント中に、
今回私が改善でき
なかったこと
スプリントゴール
を達成するために、
私がやったこと
今回のスプリント
を通して、私が学
んだこと
今回のスプリント
中に、私が感じた
こと
次のスプリントで、
私が改善したいと
考えていること

個人ふりかえりのチーム内共有
グループA・グループBに分かれて着席いただ
いた後、個人でふりかえりをします
2. チーム内で、個人ふりかえり結果を
共有します
スクリーン

チーム別ふりかえり

チーム別ふりかえりのステップ
グループA・グループBに分かれて、最初は別
々にふりかえりを実施します
–それぞれのグループにファシリテーターがつきます
2. チーム別ふりかえり結果を共有します
スクリーン

Keep
続けたいこと、
よいこと
Try
改善策、
工夫したいこと
Action
次のスプリントで
行動すること
Problem
不満点、
問題点
(1)続けたいこと、
よいこと
(2)不満点、問題点
(3)Problemに
効きそうな改善策
(4)Keepを
強化する改善策
(6)次のスプリントで
行動することを合意し、
具体化する

チーム別ふりかえり
Keep
続けたいこと、
よいこと
Try
改善策、
工夫したいこと
Action
次のスプリントで
行動すること
Problem
不満点、
問題点

グループA・グループBに分かれて、最初は別
々にふりかえりを実施します
–それぞれのグループにファシリテーターがつきます
2. チーム別ふりかえり結果を共有します
スクリーン

ふりかえりのふりかえり

ふりかえりのふりかえり
＜個人ワークショップ＞
• A3用紙を2枚用意します
• 以下をそれぞれ1枚ずつ書き出してください
–今日、気づいたこと
–次回のふりかえりで改善したいこと
＜A3用紙＞
■次回、改善すること
xxxxxx
＜A3用紙＞
■今日、気づいたこと
xxxxxx

アジェンダ
• まとめ

まとめ

なぜ
やるべきか
土台
づくり
使い続け
させる作って
仮説検証
作る計画を
立てて
作る計画を
まわす
作らずに
仮説検証
作る
WHY
HOW
アイ
ディア
モノ
コト
データ計測
する
学習
する
構築
する
アイ
ディア
モノ
コト
データ
計測
する
学習
する
構築
する
WHAT
やりたいコト
ないモノ
用意しな
ければなら
ないモノ
葛藤
葛藤

–アーキテクチャ戦略を立てる
–管理するものを分類する
–リズムを合わせる
–ふりかえりを共有する

お知らせ
• アーキテクチャについてもう少し
全体感が知りたいなら
–Cloud First Architecture 設計ガイド
» 第1章クラウドファーストの意味
» 第2章クラウド技術の構成
» 第3章クラウドファーストに至るまでの歴史
» 第4章エンタープライズとクラウドファースト
» 第5章アーキテクチャー設計ガイド
» 第6章クラウドファーストにおけるエンジニア
» https://www.amazon.co.jp/dp/4822237818

一緒に働く仲間を募集中です
http://gxp.co.jp/recruit/career.html

ご清聴ありがとうございました！
コンタクト先 URL
Blog http://fullvirtue.com/
Twitter https://twitter.com/fullvirtue
Facebook https://www.facebook.com/fullvirtue
Email fullvirtue@gmail.com
資料公開場所 http://slideshare.net/fullvirtue/
これまで登壇してきた資料はこちらで公開しています！
是非ご覧ください！
関満徳せきみつのり
グロースエクスパートナーズ株式会社 ITアーキテクト
Microsoft MVP for Visual Studio and Development Technologies
ITサービス開発のコンサルティング、開発、運用を一貫
して手掛けながら、「顧客価値の創造」と「持続可能な
仕組み創り」をテーマとしたアジャイル・プロダクトマ
ネジメントのワークショップデザインを数多く実施。全
国各地でファシリテーターとしても活躍。

リーンスタートアップとスマートなエンジニアリングの葛藤 2017/06改訂版 #bpstudy #agilejapan #postudy

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to リーンスタートアップとスマートなエンジニアリングの葛藤 2017/06改訂版 #bpstudy #agilejapan #postudy

Similar to リーンスタートアップとスマートなエンジニアリングの葛藤 2017/06改訂版 #bpstudy #agilejapan #postudy (20)

More from 満徳関

More from 満徳関 (20)