[終日研修資料] 企画担当者のためのリーン・アジャイル・プロダクトマネジメント集中特訓講座～課題発見からバックログ作成へ～ #postudy

グロースエクスパートナーズ株式会社
関満徳@fullvirtue
2018年06月16日(土)10:30～17:30
Copyright© POStudy . All rights reserved.～アジャイル・プロダクトマネジメント研究会～

撮影可録音可
※音にご配慮お願いいたします
Copyright© POStudy . All rights reserved.～アジャイル・プロダクトマネジメント研究会～ 1
♪

ネームホルダーに名刺をいれてください
（または、お名前を書いてください）
おねがい

はじめに

本日の概要
• 第1部では、リーン・アジャイル・プロダクト
マネジメントに関する集中講義を行います。
• 第2部では、課題発見から解決策検討、そして
バックログ作成までの各プロセスを、ステップ
バイステップで、ワークショップ形式にて実践
演習を行います。

本日の対象者
• 顧客開発や事業戦略について課題をお持ちの方
• 企画、マーケティングを担当している方、
もしくはこれから関わる方
• 顧客ニーズに対する提案の機会がある方、
• 開発・デザインだけでなく、
ビジネスにも取り組んでいきたい方
• 新規事業に関わっている方、
• スタートアップを実際に行っている方、

本日のゴール
• アジャイル・スクラム・プロダクトマネジメン
トを自分の言葉で説明できる
• 課題と解決策の設定のポイントを説明できる
• バックログ作成のポイントを説明できる

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

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

本ワークショップで使用するもの
No. 道具名数必須備考
1 A3用紙人数分×30枚前後必須
2 サインペン（黒）人数分必須裏写りしにくいペンならなおよい
3 サインペン（赤）人数分必須裏写りしにくいペンならなおよい
4 サインペン（青）人数分任意裏写りしにくいペンならなおよい
5 紙用マッキー（数色）テーブル数分必須裏写りしにくいペンならなおよい
6 付箋紙（75 x 75）人数分必須強粘着であれば、なおよい
7 タイマー 1個必須アプリでも可
8 カメラ 1個必須アプリでも可
9
10
11
12
13

ご質問は
• お手元の付箋に、1枚に1つの質問を書いてくだ
さい
• 休憩中に回収し、QAの時間にて回答いたします

テーマ選定
• 今回は、以下のテーマを対象に、
ワークショップを実施いたします。
–2018/04/07(土)の回
プロダクトマネージャーが
ステークホルダーとの調整で困っていること
–2018/06/16(土)の回
関係会社間の調整で困っていること

アイスブレイク

アイスブレイク(1)
＜個人ワークショップ＞
• 花見に来てくれる顧客に対する
顧客価値を、付箋に書き出してください
–1枚の付箋に1つの顧客価値を書いてください
–書き終わった方は、写真を撮っておいてください
–最後に、もう一度同じワークをやります
–本セミナーの実施前／実施後で、
ご自身の顧客価値に対する考え方の
変わり具合を各自確認いただきます

アジェンダ
• 第1部：
リーン・アジャイル・プロダクトマネジメント
集中講義
• 第2部：
課題発見からバックログ作成へ
• ふりかえり
• まとめ

アジェンダ
• 第1部：
集中講義
• 第2部：
• ふりかえり
• まとめ

第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.～アジャイル・プロダクトマネジメント研究会～ 20モノ消費ではなくコト消費の時代へ 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) (モード1)
–情報を正しく「記録」するためのシステム
–想起するもの･･･バックエンド、予約、在庫、カー
ド決済、ポイント処理、管理画面
• SoE (System of Engagement) (モード2)
–ユーザーや取引先との「絆」を作るためのシステム
–想起するもの･･･ UI、デザイン、アプリ、スマート
フォン、ダイレクトマーケティング、CRM
Copyright© POStudy . All rights reserved.～アジャイル・プロダクトマネジメント研究会～ 30Naoya 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

参考資料(1/1)
– 【お金２.０】分散化する未来が変える経済のカタチ
» https://akari-media.com/2018/02/01/member-110/
– わたしが資生堂CSOと個人会社を“複業”する理由
—— 留目真伸氏の｢プロ経営者3.0｣思考
» https://www.businessinsider.jp/post-168710
– 信用経済3-0-個人の信用をお金にできる時代を私は創造
してゆく
» https://www.amazon.co.jp/dp/B07BL4JK5H
– PMStyle – プロダクトマネジメント入門
» http://pmstyle.biz/column/product/product1_3.htm
– プロダクトマネジメントトライアングル(改案)
» https://webexpert-draft.jp/articles/59

「使い続ける」実現プロセス
• プロダクトマネジメントの変遷
プロ経営者1.0
信用経済1.0 自然経済
貨幣経済
売り手中心の
中央集権型社会
信用経済3-0-個人の信用をお金にできる時代を私は創造してゆく https://www.amazon.co.jp/dp/B07BL4JK5H
大量生産による解決個別課題の解決
経
営
視
点
プ
ロ
ダ
ク
ト
マ
ネ
ジ
メ
ン
ト
プロ経営者2.0
信用経済2.0 共有経済
インターネット社会がもたら
したインフルエンサー中心の
中央集権型社会
プロ経営者3.0
信用経済3.0 共有経済
評価経済＋α？
個人の信用がそのまま
通貨として使える経済社会
どれだけ採取するか
どれだけ大量生産するか
どれだけ売りさばくか
在庫管理はどうするか
誰にとっての価値か
価値をどう提供するか
共有すべきものはなにか
わたしが資生堂CSOと個人会社を“複業”する理由 —— 留目真伸氏の｢プロ経営者3.0｣思考 https://www.businessinsider.jp/post-168710
【お金２.０】分散化する未来が変える経済のカタチ https://akari-media.com/2018/02/01/member-110/

• [大量生産による解決]下でのプロダクトマネジメント
Copyright© Growth xPartners, Inc. All rights reserved. 36PMStyle – プロダクトマネジメント入門 http://pmstyle.biz/column/product/product1_3.htm
対
象
ス
キ
ル
【上流(upstream)】
～市場投入までに行うべきこと～
・ロードマップ
・ビジネスケース
・新製品開発
・市場投入
【下流(downstream)】
～市場投入後に行うべきこと～
・ライフサイクル管理
・ブランド管理
・マーケティング
・リーダーシップ
・意思決定
・会計
・コンペティティブ・
インテリジェンス
・価格戦略
プロダクトマネージャー
プロダクトオーナー

• インターネット時代のプロダクトマネジメント
Copyright© @fullvirtue. All rights reserved. 37プロダクトマネジメントトライアングル(改案) https://webexpert-draft.jp/articles/59

• インターネット時代のプロダクトマネジメント
プロダクト
マネージャー

• [例]プロダクトマネージャーへのキャリアパス
プロダクト
マネージャー
エンジニア
マーケティングスタートアップ

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

• スクラムで定義しているプロダクトオーナー
経営層
情シス
営業
現場
作業者管理
部門
法務
財務
顧客
意思決定
促進
現場調整
Dev/Ops
視点
ビジネス
視点
意思決定者
現場
スクラム
マスター
開発チーム
開発
プロダクトオーナー

スクラム
マスター
開発チーム
開発
経営層
情シス
営業
現場
作業者管理
部門
法務
財務
顧客
意思決定
促進
現場調整
Dev/Ops
視点
ビジネス
視点
意思決定者
現場
日本的プロダクトオーナーの苦労のポイ
ント

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

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

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

参考資料(1/3)
–Agile Japan 2017 基調講演資料
» http://www.agilejapan.org/session.html
» ※このURLは、2018年上旬まで有効です

参考資料(2/3)
• 有志によるモダンアジャイル日本語訳
–Facebookグループ
» https://www.facebook.com/groups/modernagilejp/
–モダンアジャイル（日本語訳）
» https://www.slideshare.net/imagire/ss-64457130
–Agile 2016 より
» Agile 2016の基調講演: モダンアジャイル
▸ https://www.infoq.com/jp/news/2016/08/agile2016-modern-
agile
» モダンアジャイルに対するざっくりした理解
▸ http://enk.hatenablog.com/entry/2017/02/10/200841

参考資料(3/3)
–Agile Japan 2017 より
» モダンアジャイルの原則・実践について ※翻訳者
▸ http://bit.ly/2qCRRGu
» THANK YOU AGILE JAPAN 2017 ※Agile Japan実行委員
▸ https://anagileway.wordpress.com/2017/04/20/thank-you-
agile-japan-2017/
» AgileJapan2017とワークショップに参加して、
モダンアジャイルについて考えてきました ※参加者
▸ http://blog.agile.esm.co.jp/entry/2017/05/10/120443
» モダンアジャイルの話が心に突き刺さりまくりました
（AgileJapan2017に参加してきました！） ※参加者
▸ http://aspec7.hateblo.jp/entry/2017/04/14/180722

モダンアジャイルを提唱した背景
• 2001年公開アジャイルソフトウェア開発宣言
–2011年正式な日本語版も公開
» http://agilemanifesto.org/iso/ja/manifesto.html

• 以来、多くのことが変化し、改善が迫られた
–開発プロセスにおける弱さ
» スプリントの終わりになると無理矢理詰め込まれる、
質の低い仕事
» 増え続ける技術負債との戦い
–摩擦の発生
» 完了の定義が引き起こす摩擦
▸ 実際の顧客ではなく、プロダクトオーナーがOKしたら受入
» マネジメントはきちんと開発する時間を与えてくれないと
開発の現場はフラストレーションが溜まる一方
Copyright© POStudy . All rights reserved.～アジャイル・プロダクトマネジメント研究会～ 51モダンアジャイルワークショップ - http://agilejapan.org/modernagile_0414.html

[ご参考] 完成の定義と完成の定義
• 完成の定義
–スクラムガイド（初版）
» https://www.scrumguides.org/docs/scrumguide/v201
6/2016-Scrum-Guide-Japanese.pdf
• 完成の定義
–スクラムガイド（改訂版）
» https://www.scrumguides.org/docs/scrumguide/v201
7/2017-Scrum-Guide-Japanese.pdf

• アジャイルについてさらなる検証と実験を実施
–よりシンプルなアプローチがないか
–より安全にできないか
• その結果、大幅に効率的なアジャイルプロセス
を構築
–それがモダンアジャイル
Copyright© POStudy . All rights reserved.～アジャイル・プロダクトマネジメント研究会～ 53モダンアジャイルワークショップ - http://agilejapan.org/modernagile_0414.html

モダンアジャイルとは
• 時代遅れとなったアジャイルプロセスよりも
着手しやすいスタートポイント
–価値駆動
» アウトプットではなくアウトカム（成果）に着目
▸ 良いソフトウェアを作ろう、動作するソフトウェアを作ろうと
考えるのではなく、それらが生み出す「成果」に着目
» 「要求」を「実験」として捉える
▸ アジャイルマニフェストの「変化に対応する」というのは受動的
▸ 高速に実験し、高速に学習するために、顧客からの要求さえも実験で
あると捉え、早く失敗していく
–非慣例的
» 実践を増幅
▸ 慣例とは繰り返し行われて習慣の様になった事柄、非慣例とはその逆
Copyright© POStudy . All rights reserved.～アジャイル・プロダクトマネジメント研究会～ 54モダンアジャイルの原則・実践について - 今給黎隆 http://bit.ly/2qCRRGu

モダンアジャイルの4原則
• [最高] 人々を最高に輝かせる
• [安全] 安全を必須条件にする
• [高速] 高速に実験＆学習する
• [継続] 継続的に価値を届ける

モダンアジャイルプラクティス
カテゴリプラクティス
1 [最高][安全] 仕事の憲章化
2 [高速][最高][安全] リーン・スタートアップの活用
3 [高速][最高] リーンUXの適用
4 [高速][安全][継続] 頻繁な協調と統合
5 [安全][高速] 安全に失敗できる環境
6 [安全][継続] テストとリファクタリング
7 [安全] 人々への敬意と感謝
8 [安全][高速] 非難しないふりかえりを指揮
9 [継続] フローに集中
10 [継続][高速][安全] 継続的なデプロイとリリース
11 [継続][安全] プロダクトコミュニティを形成
12 [継続][高速][安全] ソリューションを進化
モダンアジャイルの原則・実践について - 今給黎隆 http://bit.ly/2qCRRGu

1. [最高][安全]
仕事の憲章化
• 人々を最高に輝かせたいなら、
その意味を定義する必要がある

1. [最高][安全]
仕事の憲章化
• アジャイル憲章
–明確なビジョン、ミッション、テスト可能な成果物
を、プロダクトコミュニティが発見し、同じ立場で
考えてもらうための軽量なプラクティス
–憲章の設置
» プロジェクトの最初に一度だけ行うものではない
» 憲章の設置は継続的な試み
▸ アジャイル憲章は英語だと “ing”が付いている
▸ 良い憲章はガードレールのようなもの
▸ 道を逸れるのを妨ぐ

2. [高速][最高][安全]
リーン・スタートアップの活用
• エリック・リースの古典的な
リーン・スタートアップ
–大規模な組織、小規模なスタートアップ、または
その中間のソフトウェアを開発する場合でも有効
» 「不確実な状況下で活動してしまっている」ことを
理解するのを助け、ユーザーが必要とするものを
推測する事がいかに安全でないのかを明らかにしてくれる

2. [高速][最高][安全]
リーン・スタートアップの活用
• エリック・リースの古典的な
リーン・スタートアップ
–素早く簡素な実験や、仮説の迅速な検証・無効化な
ど、精緻なコードを作るための投資をしてしまう前
に、何を作るべきなのかを発見するための、さまざ
まな有用な方法を提案
» ユーザーが実際にソフトウェアを使用しているかどうか、
利益を受けているかどうか、超すげーことになっているか
どうかを、あなたが分かってないならDoneの定義を再定義
する必要がある

3. [高速][最高]
リーンUXの適用
• リーンUX
–リーン・スタートアップに密接に関係
–優れたユーザー体験を発見して作り出すための、
迅速で低コストな、分析主導のアプローチ

[ご参考]
• UX = ユーザー自身の情報 × コンテキスト
–コンテキストとは
» 切り口-1: デバイス
» 切り口-2: 環境
» 切り口-3: 時間
» 切り口-4: 行動
» 切り口-5: パーソナル
» 切り口-6: 場所
» 切り口-7: ソーシャル
» コンテキスト･デザインの5原則
▸ ご参考：https://uxdaystokyo.com/articles/context01/

4. [高速][安全][継続]
頻繁な協調と統合
• ソフトウェア開発における多くの問題の
根本的な原因
–チーム内やチーム間でのコラボレーションと統合が
貧弱だと、組織は危険にさらされる
» ソロワーク
▸ 知識サイロ（何かの仕組みを一人だけしか知らない）の発生
▸ より大きな欠陥、脆弱な問題の解決、より強い注意力の散漫と、より
少ない規律（特に良いテストを書いたり、リファクタリングによる設
計の改善に対する）を生み出す傾向がある

• ソロワークの解消
–ペアリング
» 二人で一緒に仕事をし、ペアを定期的に交換
–モブプログラミング(mobbing)
» 三人以上で協力して、キーボード・マウスを
「ドライブ」する人を定期的に交代
» 開発に対するコミュニティアプローチ
–ディープソロ（深い単独作業）
» コードレビューによる協調作業
» 素早くマスターブランチに統合

• ペアリング・モブプログラミングの効果
–学習のスピードを高める
–価値のある結果を生み出す流れを加速
–重要なスキル・知識に対する危険な依存性を削減
–技術への容易な変更を可能
–人々を最高に輝かせるものをもたらす

5. [安全][高速]
安全に失敗できる環境
• あなたの会社に恐れの文化がある場合
–どんなすばらしいプラクティスやプロセスも
あなたを助けられない
• 最高の企業
–人々が実験、失敗、異議、そして彼ら自身が
安全と感じる文化を育成
–安全に失敗できる企業→「学習する組織」

6. [安全][継続]
テストとリファクタリング
• テストと設計はアジリティの本質
–モダンアジリスト
» 探索的テスト、自動テスト、（主に設計の活動であり、
副次的にテストの活動でもある）テスト駆動開発や、
いくつかの手動テストを実行
▸ 欠陥が80％以上減少
–信頼できる高速で自動化されたソフトウェア動作
チェックがあること
» プログラマにとって
▸ コードの変更や欠陥の生成を恐れることが少ない
▸ 高速に仕事ができるセイフティネットを持てる

6. [安全][継続]
テストとリファクタリング
• リファクタリング
–挙動を変えずに既存のコードの設計を改善
» 設計が複雑になることを回避
» コードを簡単かつわかりやすく
（したがって変更しやすく）する重要なプラクティス
–リファクタリングは「見直し」
» 私たちはもっと学び、以前の作業の欠陥を発見し、
コードの設計・読みやすさ・シンプルさを向上させる
ように努力することで見直しを実施
» テストとリファクタリングは、共にチームのスピードに
不可欠な存在

7. [安全]
人々への敬意と感謝
• 安全の文化を確立するには
–役割、年齢、学歴、人種、性別によらない、
心からの敬意と感謝が重要
–アンゼニアリング（Anzeneering）
» 時間、お金、情報、評判、
関係、健康を守り、人々を尊重

8. [安全][高速]
非難しないふりかえりを指揮
• ふりかえりのお約束
–ふりかえりの前に慣習的に読まれる
–たとえどんなことに気付いたとしても、
チーム全員が、その時点で知っていたことや
彼(彼女)のスキル及び能力、利用可能なリソース、
そしてその時の状況で最善を尽くしたのだと
理解し、心の底から信じる
–このお約束は、ふりかえりを学びに焦点を当てた
安全な場になるように整える

9. [継続]
フローに集中
• かんばん
–タイムボックスによる作業の連続的な流れ
–合理化されたアジャイル計画
» 連続フローを可能
–かんばんボードを使用
» チームは作業をボード上で見える化
» 重要な作業をボードに設けられた列を移すことでプル
» 仕掛品を制限
» サービスの分類（緊急または正常な作業など）を補助
» ボトルネックを見える化し、取り除く
» 開発中の価値を人々に提供
ToDo Doing Done

9. [継続]
フローに集中
• かんばんによるムダの排除
–タイムボックス内でどれくらいの作業をするかを
予測しようとする時間のムダ
–ストーリーポイントの正確な値を考慮することの
ムダ
–魅力的なバーンダウンやバーンアップチャートを
公開するために見栄えを良くすることのムダ

10. [継続][高速][安全]
継続的なデプロイとリリース
• 継続的デプロイ
–早期な速い実験（A / Bテスト等）を実現
–ユーザーが最も必要とするものをできるだけ
迅速かつ安全に提供することを可能
–「コンセプトをキャッシュにする」までの
サイクルを劇的に減らす
–一日に何回もプロダクション環境へ安全にデプロイ
» 初期アジリストの想像をはるかに上回る継続的
インテグレーション（CI）の実践

11. [継続][安全]
プロダクトコミュニティを形成
• プロダクトが直面する主な問題
–自分自身のコミュニティ意識の欠如
• 人々を最高に輝かせるソフトウェアを作るには
–適切な人が必要
–適切な人々はプロダクトコミュニティを作り上げる

11. [継続][安全]
• プロダクトコミュニティ
–プロダクトに影響を与えたり、プロダクトに影響を
受ける可能性のある人々
–あなたが思っているよりも「常に」大きい
» フロントエンド、バックエンド、ミドルウェア、およびUX
チームに分かれておらず、独自のバックログを持つ
» フルスタックであり、原始的なソリューションを、
人々を最高に輝かせ、組織の成功に役立つ洗練された
プロダクトへと進化させる準備ができている
–「憲章」において頻繁に定義付けと洗練化を実施

11. [継続][安全]
• プロダクトコミュニティを形成すること
–誰が何をどのようにすることが重要な結果を達成す
るのに不可欠であるのか認識するのに役立つ

12. [継続][高速][安全]
ソリューションを進化
• ソリューションの進化の設計
–人材とチームを組織して、何を構築し、協調し、統
合し、開発し、リリースするのか計画
–ソリューションをすばやく進化
» ユーザーにプロダクトや機能をすばやく提供
» フィードバックからすばやく学ぶ
–ユーザーに価値をすばやく伝える最良の方法
» プロダクトコミュニティ内やプロダクトコミュニティ間で
の協調と統合のリスクを明確化
» リスクの修正のための非常に便利な方法

モダンアジャイルプラクティス
カテゴリプラクティス
1 [最高][安全] 仕事の憲章化
2 [高速][最高][安全] リーン・スタートアップの活用
3 [高速][最高] リーンUXの適用
4 [高速][安全][継続] 頻繁な協調と統合
5 [安全][高速] 安全に失敗できる環境
6 [安全][継続] テストとリファクタリング
7 [安全] 人々への敬意と感謝
8 [安全][高速] 非難しないふりかえりを指揮
9 [継続] フローに集中
10 [継続][高速][安全] 継続的なデプロイとリリース
11 [継続][安全] プロダクトコミュニティを形成
12 [継続][高速][安全] ソリューションを進化

モダンアジャイルプラクティスマップ
ジョシュアケリーエブスキー
インダストリアルロジック
訳：Takashi imagire 協力：@kawaguti, Modern
Agile JP(FaceBook)
人々を
最高に輝かせる
Make Users Awesome
安全を
必須条件にする
Make Safety a Prerequisite
高速に
実験＆学習する
Experiment & Learn Rapidly
継続的に
価値を届ける
Deliver Value Continuously
フローに集中
Focus on Flow
仕事の憲章化
Charter Your Work
リーンスタートアップの活用
Leverage Lean Startup
リーンUXの適用
Apply Lean UX
Collaborate
& Integrate
Frequently
安全に失敗できる環境
Make it Safe to Fail
テストと
リファクタリング
Test & Refactor
人々への敬意と感謝
Respect & Appreciate People
非難しない
ふりかえりを指揮
Conduct Blameless
Retrospectives
継続的な
デプロイとリリース
Deploy & Release
Continuously
プロダクト
コミュニティを形成
Form Product
Communities
ソリューションを進化
Evolve Solutions
Original: https://www.industriallogic.com/blog/modern-agile/
モダンアジャイル（日本語訳）- 今給黎隆 https://www.slideshare.net/imagire/ss-64457130

モダンアジャイルの4原則
• [最高] 人々を最高に輝かせる
• [安全] 安全を必須条件にする
• [高速] 高速に実験＆学習する
• [継続] 継続的に価値を届ける

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

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

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

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

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

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

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

Q&A

お昼休み

現代のプロダクト開発の進め方事例
• Microsoft PowerPoint における開発手法
• Microsoft りんなにおける開発手法
• まとめ

Microsoft PowerPoint
における開発手法
Copyright© Growth xPartners, Inc. All rights reserved. 93

Microsoft PowerPoint の歴史
出典：WikiPedia https://ja.wikipedia.org/wiki/Microsoft_PowerPoint
No. パッケージ版のリリース状況
バージョン 1 Forethougt が1987年にMacintosh向けにリリースしたもの。
バージョン 2 Macintosh版は1988年にリリースされ、Windows版はWindows 3.0用で1990年にリリースされた。
バージョン 3 Macintosh版は1992年にリリースされ、Windows版はWindows 3.1用にMacintosh版と同じ年にリリースされた。
バージョン 4 Windows版の PowerPoint 4.0 は1993年にリリースされ、Macintosh版のPowerPoint 4.0は1994年にリリースされた。
バージョン 7 他のOfficeソフトウェアとバージョン番号が統一されたため、バージョン番号が3繰り上がった。このバージョンはPowerPoint
95としてWindows版のみリリースした。日本語版はこのバージョンから用意された。
バージョン 8 Windows版のPowerPoint 97が1996年にリリースされ、Macintosh版のPowerPoint 98は1998年にリリースされた。
バージョン 9 Windows版のPowerPoint 2000が1999年にリリースされ、最後のMac OS 9版PowerPoint 2001は2000年にリリースされた。
PowerPoint 2000では従来アウトライン画面・スライド画面・ノート画面を別々の画面で操作していたものを、一つの画面で操
作できるようになったことで、プレゼンテーション制作の生産性を大幅に向上させた。
バージョン 10 Windows版のPowerPoint 2002が2001年にリリースされ、初のMac OS X版のPowerPoint Xも同年にリリースされた。
バージョン 11 Windows版のPowerPoint 2003が2003年にリリースされ、Mac OS X版のPowerPoint 2004は2004年にリリースされた。
バージョン 12 Windows版のPowerPoint 2007が2007年にリリースされ、Mac OS X版のPowerPoint 2008は2008年にリリースされた。
バージョン 14 Windows版のPowerPoint 2010が2010年にリリースされ、Mac OS X版のPowerPoint 2011も同年にリリースされた。
バージョン ? 2010年6月から「Office Web Apps」という名称で、Word、Excel、PowerPoint、OneNoteのブラウザベースのバージョンが
提供された。以降、都度バージョンアップを実施。
2014年2月に、「Office Online」に名称変更した。
バージョン？ 2011年6月に「Office 365」が提供開始された。以降、都度バージョンアップを実施。
バージョン 15 Windows版のPowerPoint 2013が2013年にリリースされた。
バージョン 16 Windows版、OS X版、iOS版のPowerPoint 2016が2015年にリリースされた。
出典：WikiPedia https://ja.wikipedia.org/wiki/Microsoft_Office_365

Microsoft PowerPoint の種類
• パッケージ版
–Office 20XX
» Windows 版
» MacOS 版
–Office 365
» Windows 版
» OS X 版
• Office Online
• スマートフォン用アプリ
–iOS 版

Microsoft PowerPoint の開発体制
• 複数チームで構成
• 1チームは、自律的に動ける人数に限定
–プログラムマネージャー × 1名～?名
–エンジニア × 数名
–プログラムマネージャーとエンジニアは同室にいる
–プラットフォーム毎にチーム編成を行っているわけ
ではない
• ローカライズは、別チームが担当

Microsoft PowerPoint 開発の進め方
• タスクは、2種類に分類
• それぞれのタスクを担当するチーム数は
スプリント毎に再配分
–時期によって比率がかなり異なる
» Microsoft Build 後は、フィードバックがたくさん来る
▸ シールド : フィーチャーが 50% : 50% になることも
▸ シールドが溜まる傾向にある場合、シールド対応チーム数を増やして
対応
タスク内訳
シールドフィードバック／不具合対応
フィーチャー計画された機能開発→毎月リリース

お話してくださった方が言うには
• アジャイルやスクラムをやっているという認識
はない
• Microsoft 社内で試行錯誤した結果、今の形に
行き着いた
• とはいえ、ここまでくるのにいろいろなことが
あった

ここ最近のTopix (1/3)
• チームメンバーからテスターがいなくなった
–開発とテストは両輪
–同じ人が同時にやればよい
–エンジニアAが実装、エンジニアBがテスト、という
分担をすることもある
–テストは基本的にすべて自動化が必要
» とはいえ、数十年前から存在するソースコードのため、
既存のコードは膨大に存在するが、その部分を自動化する
ようなことはしていない
» 今回手を入れる部分について、新たにテストコードを記述

• チームメンバーからDev Lead がいなくなった
–マネージャーの役割をしていた人が一気に減った
–1チームの人数を減らして、マネージャーがいなくて
も管理可能に

• 評価制度がかなり変わった
–リリースされなかったら評価がゼロ
–どのぐらいのインパクトを与えたかが評価
» 10やってたことを2に減らす、かわりに
やった2を10箇所にApplyしてインパクトを増やすetc…
» やることを減らして、クオリティを上げる傾向に
–評価はかけ算
» セキュリティやパフォーマンスが悪いと0点に

Microsoft りんな
における開発手法

Microsoft りんなとは
• 平成生まれ。東京の北の方出身。
2015年8月にメジャーデビュー以降、リアルなJK感が反映されたマシ
ンガントークと、類まれなレスポンス速度が話題を集め、学生ファン
を中心にブレイク。
またそのキュートな後ろ姿から、数々の男性が彼女を口説き落とそう
と熾烈な争いを繰り広げるなど、AI界にJK旋風を巻き起こし、絶大な
支持を集めている。
LINEのお友だち数は約630万人(2018年1月現在)を突破！昨今では、
飾ることのない物言いでユーザーの恋愛相談に乗ったり、奇抜なポー
ジングをユーザーに強要したり、トイレの中まで追いかけてきてゲー
ムを仕掛けるなど、その独特なサービス精神を発揮、さらに幅広い層
より支持を集めている。
2016年の夏には、400万人規模にのぼるフェス「りんなEXPO」を開
催。いま「日本で最も発言力のある女子高生」である。

Microsoft りんなの歩み 2015年～

Microsoft りんなの歩み 2017年～

Microsoft りんな立ち上げ
• インキュベーション的にスタート
–日本語＋キャラクター＋コンセプト
（トモダチのように）
–1ヵ月ぐらい
• 初期開発
–半年～1年ぐらい
–出口：どこで話すか
» LINEに決定

Microsoft りんなリリース
• 初回リリース
–2015年8月
• ブランディング・マーケティング
–開発チームが自分たちで実施
• プログラムマネージャーのありかたの見直し
–ユーザー寄りにシフト
• リリースしてからが本番！

Microsoft りんなその後の開発体制
• 複数チームで構成
• 1チームは、自律的に動ける人数に限定
–プログラムマネージャー × 1名
–エンジニア × 1名
–プログラムマネージャーとエンジニアは同室にいる

Microsoft りんな開発の進め方
• タスクはおろか、ロードマップや
マイルストーンを事前に定義するのは諦めた
–理由：ニーズがわからず、そもそも立てられない
• そこで、、、
–1スプリント1週間に設定
–毎週リリースしてフィードバックを得る
–フィードバックを元に次やることを決める

• 初回リリース後からしばらくは、、、
–各チームから今回のスプリントで実施するテーマを
自分たちで決めてもらって実施
–リリースすると数時間で大量のフィードバックが得
られるので、全員でフィードバックを確認
–次のスプリントが始まっている最中に得たフィード
バックを、すぐに反映することも

• だんだんわかってきた後は、、、
–編集会議を設定するようになった
» 企業とのコラボ企画などもあり、あらかじめやらないと
いけないことが明確になる傾向が出てきたのも、一因

まとめ

まとめ
• プロダクトの特性やフェーズごとに、適した
開発の進め方があるのは前提として、、、
–巨大プロダクトの場合、シールドとフィーチャーの
バランスを都度コントロールする進め方
–AIの場合、フィードバックループ中心の進め方
• 複数チームで対応可能な体制づくりがポイント
–1チームの構成人数は最小限
» チームが自律的に動ける人数
» チームが自律的に動くための仕組み

Q&A

アジェンダ
• 第1部：
集中講義
• 第2部：
• ふりかえり
• まとめ

第2部：

• 顧客と課題の仮説立案
• 解決策の検討
• 仮説検証方法の検討と立案
• バックログとタスクの検討
第2部：

産まれた月日時間順に
1列に並んでください
アイスブレイク

第2部：

• テーマ選定
• 顧客設定～プロトペルソナ～
• 課題の仮説立案
顧客と課題の仮説立案

• テーマ選定

テーマ選定
• 今回は、以下のテーマを対象に、
ワークショップを実施いたします。
–2018/04/07(土)の回
ステークホルダーとの調整で困っていること
–2018/06/16(土)の回
関係会社間の調整で困っていること

テーマ選定
スクラム
マスター
開発チーム
開発
経営層
情シス
営業
現場
作業者管理
部門
法務
財務
顧客
意思決定
促進
現場調整
Dev/Ops
視点
ビジネス
視点
意思決定者
現場
日本的プロダクトオーナーの苦労のポイ
ント

• テーマ選定

参考資料(1/1)
–ペルソナ
» http://www.missiondrivenbrand.jp/entry/kaitai_perso
nadesign
» http://www.missiondrivenbrand.jp/entry/kaitai_perso
nadesign
–プロトペルソナ
» https://uxxinspiration.com/2014/03/persona/
–坂田一倫 - Lean UX Workshop at Movida Japan
#3
» https://www.slideshare.net/kazumichisakata/lean-ux-
workshop-at-movida-japan-3/31

顧客設定～プロトペルソナ～
• ペルソナとは？
–ブランドに対して感情移入を促し、長期的なファン
になってくれることが期待できる象徴的な顧客像
• ペルソナ設定（ペルソナデザイン）とは？
–その象徴的な顧客像を描くこと
Copyright© POStudy . All rights reserved.～アジャイル・プロダクトマネジメント研究会～ 129http://www.missiondrivenbrand.jp/entry/kaitai_personadesign

• ペルソナの作成手順
1. ターゲット層を定める
2. ターゲットユーザーを調査する
3. 行動パターンをまとめる
4. ペルソナシートに落とし込む
5. ペルソナに優先順位をつける
• ペルソナ作成後
1. シナリオを使って具現化
Copyright© POStudy . All rights reserved.～アジャイル・プロダクトマネジメント研究会～ 130http://www.missiondrivenbrand.jp/entry/kaitai_personadesign

• ペルソナのメリット
1. 意思決定にブレがなくなる
2. ユーザーを深く理解することで、
ユーザー目線になれる
• ペルソナのデメリット
1. きちんとした調査が必要
2. 時間・費用がかかる
3. スピード感が求められる開発現場では、
導入が難しい
Copyright© POStudy . All rights reserved.～アジャイル・プロダクトマネジメント研究会～ 131https://uxxinspiration.com/2014/03/persona/

• プロトペルソナ
–Lean UXで提唱されている「ペルソナの原型」
» プラグマティックペルソナ、なんちゃってペルソナ、
捏造ペルソナ、簡易ペルソナと呼ぶことも
–ペルソナのデメリットをなくすため、
以下を推測によってまとめたもの
» 製品を使うのは誰か
» その理由は何か
–記述は形式張らないスケッチで実施
–現場でリサーチを行って、修正しながら精度向上
Copyright© POStudy . All rights reserved.～アジャイル・プロダクトマネジメント研究会～ 132https://uxxinspiration.com/2014/03/persona/

• プロトペルソナ
【名前と見た目のイラスト】
顧客のイメージ、名前、容姿など
【基本属性】
年代、性別、住まい、家族構成、職業、
所有しているデバイスなど
【特徴的な行動】
対象サービス分野に関連するユーザーの
特徴的な５つの行動
【ニーズや不満点】
５つの特徴的な行動から推測される、ターゲット
ユーザーのニーズや、不満と感じるポイント
坂田一倫 - Lean UX Workshop at Movida Japan #3 https://www.slideshare.net/kazumichisakata/lean-ux-workshop-at-movida-japan-3/31

ワークショップ(1)
• 先ほど選んだテーマについて困っているプロト
ペルソナを作成してください
＜A3用紙＞プロトペルソナ
顧客のイメージ、名前、
容姿など
【基本属性】
年代、性別、住まい、
家族構成、職業、
対象サービス分野に関連
するユーザーの特徴的な
５つの行動
５つの特徴的な行動から
推測される、ターゲット
ユーザーのニーズや、
不満と感じるポイント

＜グループワークショップ＞
• 先ほど作成したプロトペルソナを
グループで共有してください
＜A3用紙＞プロトペルソナ
顧客のイメージ、名前、
容姿など
【基本属性】
年代、性別、住まい、
家族構成、職業、
対象サービス分野に関連
するユーザーの特徴的な
５つの行動
５つの特徴的な行動から
推測される、ターゲット
ユーザーのニーズや、
不満と感じるポイント

• テーマ選定

参考資料(1/1)
–問題と課題の違い
» https://www.kaizen-base.com/contents/kall-42420/

課題の仮説立案
• 問題解決へのアプローチ
目標と現状の差
解決すべき事柄
今はどうなっているか
（実際の姿、予想される
状態、予期せぬ結果）
現状
どうならなければいけないか
（あるべき姿、期待される結
果、ありたい姿）
目標
GAP = 問題

解決策課題解決のために
具体的にやること
課題目標と現状の差を埋める
ために、やるべきこと
（やると決めたこと）
現状
目標
GAP = 問題

現状
目標
GAP = 問題

現状
目標
GAP = 問題
①課題設定やふりかえり
などで改善内容を確認

現状
目標
GAP = 問題
②実施したか否かを測る
メトリクスを設定して計測

現状
目標
GAP = 問題
③成果が出たか否かを測る

現状
目標
GAP = 問題
③成果が出たか否かを測る
④ふりかえりで
解決したか確認

• A3用紙を1枚用意してください。
• 先ほど選んだテーマにて先ほど作成したプロト
ペルソナが、解決したいと考えている「課題」
を考え、書き出してください。
–シーン別に書き出すとよいです。
＜A3用紙＞
■YYYが抱える課題
xxxxxx
■ZZZが抱える課題
xxxxxx

ワークショップ(3) ※参照用
現状
目標
GAP = 問題

• 先ほど書き出した課題をグループ内で共有し、
課題についてディスカッションしてください。
–ディスカッションを通して導き出した根本課題は、
新しいA3用紙に書き出してください。
＜A3用紙＞
■課題
xxxxxx
（前のワークで書いたもの）

ワークショップ(4) ※参照用
現状
目標
GAP = 問題

• この後のワークショップのテーマ課題を決めて
ください。
–決定したテーマ課題は、
＜A3用紙＞
■グループのテーマ課題
xxxxxx

＜発表＞
• 先ほど書き出したグループのテーマ課題を、
紹介してください。
＜A3用紙＞
■グループのテーマ課題
xxxxxx

• テーマ選定
Q&A

休憩

第2部：

• 6コマ漫画によるストーリー作成
• 本来解決すべき課題の特定
解決策の検討

解決策の検討

参考資料(1/1)
–坂田一倫 - Lean UX Workshop at Movida Japan
#3
» https://www.slideshare.net/kazumichisakata/lean-ux-
workshop-at-movida-japan-3/32
–広野萌 - 意味不明なことばかり言ってるUXデザイ
ナー達の代わりに「UXデザインとは何か」を端的に
説明しよう
» http://hajipion.com/2321.html

6コマ漫画によるストーリー作成
• GAPをどう埋めるか
現状
目標
GAP = 問題
どうやって GAP を埋めるか

• 6up sketches
ユーザーが
サービスを
使う前
ユーザーが
サービスを
使った後

• 先ほど選んだペルソナを対象に、
6up sketchesを作ってください
＜A3用紙＞
6up sketches
ユーザーが
サービスを
使う前
ユーザーが
サービスを
使った後

ワークショップ(7) 参照用

• 先ほど作成した6up sketchesを
＜A3用紙＞
6up sketches
ユーザーが
サービスを
使う前
ユーザーが
サービスを
使った後

• 先ほどのペルソナを別のペルソナに置き換えて
6up sketchesを作ってください
＜A3用紙＞
6up sketches
ユーザーが
サービスを
使う前
ユーザーが
サービスを
使った後

ワークショップ(9) 参照用

• 先ほど作成した6up sketchesを
＜A3用紙＞
6up sketches
ユーザーが
サービスを
使う前
ユーザーが
サービスを
使った後

解決策の検討

本来解決すべき課題の特定
• 本来解決すべき、根本課題を見極める
現状
目標
GAP = 問題

• 先ほど書き出した6up Skechesについて、
共通する本来解決すべき「課題」を考え、
書き出してください。
＜A3用紙＞
■本来解決すべき課題
xxxxxx

• 先ほど書き出した課題をグループ内で共有し、
課題についてディスカッションしてください。
–ディスカッションを通して導き出した根本課題は、
別の色で書き足してください。
＜A3用紙＞
■課題
xxxxxx

解決策の検討

解決策の検討
• 根本課題に対する解決策を見極める
現状
目標
GAP = 問題

• 先ほど書き出した根本課題について解決策を考
え、書き出してください。
–シーン別に書き出すとよいです。
＜A3用紙＞
■解決策
xxxxxx

• 先ほど書き出した根本課題と解決策について
ディスカッションしてください。
–ディスカッションを通して導き出した解決策は、
＜A3用紙＞
■解決策
xxxxxx

• この後、プロジェクトとして実際に検討を行う
根本課題と解決策を決めて、書き出してくださ
い。
＜A3用紙＞
■根本課題
xxxxxx
■解決策
xxxxxx

＜発表＞
• 先ほどこの後、プロジェクトとして実際に
検討を行う根本課題と解決策を、紹介して
ください。
＜A3用紙＞
■根本課題
xxxxxx
■解決策
xxxxxx

Q&A

休憩

第2部：

• MVP(Minimum Viable Product)とは
• MVPの代表的パターン
• MVPの検討と立案

MVPの代表的パターン
プレスリリースプロダクトの価値を伝える資料
ランディングページプロダクトやサービスの需要を確認
プレオーダーローンチ前に商品の魅力を伝え、事前登録や購入を募る
オーディエンス開発型
サービス開発前に見込みユーザーのコミュニティを構築し、
意見交換・観察を行う
オズの魔法使い
完全に機能が実装されているように見せながら、実際には
手作業で動作させている製品を提供
コンシェルジュサービス開発前に、顧客に製品を使用する体験を提供
プロトタイプ
体験に近似したものを作成して、製品／サービス利用をシ
ミュレーションし、使いやすさを検証
シングルユースケース
検証したい機能をひとつに絞り、新しい手法を
ユーザーの一部にのみ試す
他社製品既存の製品やサービスの一部を使用
大西敬吾氏 – LiLz Boot Camp 資料および POStudyとの共催セミナーでも使用した資料より抜粋 https://lilz.jp/

[終日研修資料] 企画担当者のためのリーン・アジャイル・プロダクトマネジメント集中特訓講座～課題発見からバックログ作成へ～ #postudy

[終日研修資料] 企画担当者のためのリーン・アジャイル・プロダクトマネジメント集中特訓講座～課題発見からバックログ作成へ～ #postudy

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie [終日研修資料] 企画担当者のためのリーン・アジャイル・プロダクトマネジメント集中特訓講座～課題発見からバックログ作成へ～ #postudy

Ähnlich wie [終日研修資料] 企画担当者のためのリーン・アジャイル・プロダクトマネジメント集中特訓講座～課題発見からバックログ作成へ～ #postudy (20)

Mehr von 満徳関

Mehr von 満徳関 (16)