Agile

1. Agile Japan 2012 サテライト＜名古屋＞
2012/03/16 You&I

2.  H/N You&I(読み：ユーアンドアイ)
 出身 生まれも育ちも名古屋市
 年齢 30代前半
 本職 商学部出身の職業プログラマ
 言語 C++, C#, VisualBasic 6.0,
日本語COBOL
 日記 http://d.hatena.ne.jp/youandi/
 所属 名古屋アジャイル勉強会
プログラミング生放送 名古屋支部
わんくま同盟
2

3. 3

4. プロジェクトを核心まで
煮詰めて抽出した
共通理解(＝合意事項)を、
開発チームだけではなく、
より広範囲なプロジェクトの
利害関係者へ
手軽に伝える為のツール
4

5.  インセプションデッキは、ジョナサン・ラス
マセン氏の2010年9月発売の著書「The Agile
Samurai」において、「10の手強い質問」と
して紹介されています。
 日本においては「The Agile Samurai」の発売
後にブログ・SNS等で紹介される中、オーム
社より2011年7月に書籍「アジャイルサムラ
イ」として日本語翻訳版が発売されました。
5

6.  インセプションデッキは、プロジェクトの開
始前に実施するプラクティスです。プロジェ
クトのふりかえりの際にも利用可能です。
 プロジェクトを始めるにあたって・・・
 誰が関係するのか
 何を作るのか、どうやって作るのか
 いつまでに作るのか
 ・・・etc.
 関係者全員で話し合い、関係者全員で合意す
る為のプラクティスです。上から決められた
指示ではなく、自分達でやる事を決めます。
6

7. 7

8. 1. 利害関係者(ステークホルダー)を集める
2. 集まった人達で、PowerPoint文書の穴埋め
をするワークショップを行う
3. 作成したPowerPoint文書を見える所に貼り
出す
たったこれだけ。
インセプションデッキは手軽に行えます。
そして内容に変更があれば、逐次作成ワー
クショップを行い、内容を修正します。
常にプロジェクトの最新状態を示します。
8

9.  インセプションデッキはアイデア出しの場で
は有りません！プロジェクトの方向付けを行
う為の場です。
 関係者にちゃんと主旨を伝えた上で集まりま
しょう。
 必要な資料があるなら会議前に事前配布。議
論の叩き台となる情報を持っている側が用意
します。
 プロジェクトファシリテーションにある通り
会議は目的・目標を決め、短く簡潔に、そし
て意義のあるものにしましょう
9

10.  話し合いは、ホワイトボード、ペン、付箋紙、
模造紙(B紙)を使って行います。
 10の手強い質問は、必ずしも全てを行う必要
は有りません。必要な物だけ行えば良いです。
 10の手強い質問の詳細は、後ほど紹介します。
 1つのテーマにつき1～1.5時間話し合いを行っ
たら、スライドにまとめます。
 インセプションデッキのPowerPoint文書
 http://j.mp/inception-deck (英語版)
 http://j.mp/inception-deck-ja (日本語版)
 次のテーマに進み、スライドをまとめるのを
繰り返す。
10

11.  10の手強い質問についてまとめたスライドを
印刷して見える所に貼り出します。
 サーバーの共有フォルダ等にスライドの電子
ファイルを置いただけでは、共有したことに
はなりませんので注意！
 プロジェクトで大事な事を周囲に報告する事
も兼ねて、目に付く位置に貼り出します。
11

12. 12

13. 13
我々はなぜこ
こにいるの
か？
エレベーター
ピッチ
パッケージデ
ザイン
やらないこと
リスト
ご近所さんを
探せ

14. 何の為にこの場に集まったのかを明確にし、当
たり前の事かも知れないが、自分の認識と周
りとで認識が合っているのか確認する。
 ミッションの定義
 自分達の顧客は誰なのか
 プロジェクトの始まった理由はなんなのか
 プロジェクトの目的やゴールは何か
14

15. 我々はなぜここにいるのか
•[大事な理由(その１)]
•[大事な理由(その２)]
•[大事な理由(その３)]
[プロジェクトの根幹を成す、
最も大事な理由]
15

16. プロジェクトをTV CMのように30秒でアピール
するとしたら何を伝えるべきだろうか？
 ニーズの定義
 どんな顧客の要望に応えるのか
 プロジェクトの成果物名は何か
 プロジェクトの成果物はどのように分類され
るものなのか
 プロジェクトの成果物は何ができるのか
 プロジェクトの成果物の目玉は何か
16

17. エレベーターピッチ
 [潜在的な、ニーズを満たしたり・課題/問題を解決
したい] したい。
 [対象となる顧客] 向けの、
 [プロダクト名] というプロダクトは、
 [プロダクトの種別] です。
 これは [重要な利点、対価に見合う説得力のある理
由] ができ、
 [考え得る最も有力な代替手段] とは違って、
 [代替手段とは差別化される決定的な特徴] が備わっ
ている。
17

18. 雑誌の広告ページのように、１ページや１枚紙
でプロジェクトをアピールするとしたら、ど
のような内容になるか。
 ビジョンの定義
 プロジェクトの成果物名は何か
 プロジェクトの成果物の目玉は何か
 ユーザー視点で書く
18

19. パッケージデザイン
[プロダクトの名前]
[最高のキャッチコピー]
[ユーザーへのアピール(その１)]
[ユーザーへのアピール(その２)]
[ユーザーへのアピール(その３)]
[素敵な写真]
19

20. プロジェクトで実現したい事は明確になってい
る事が多い。やらなくても良い事を明確にす
る事で、やるべき事を明確にする。
 スコープの定義
 まずはやりたい事を洗い出す
 やる・やらない・あとで決めるに分類する
20

21. やらないことリスト
やる やらない
[作業] [作業]
あとで決める
[作業]
21

22. プロジェクト終盤での不意の横槍は対応が大変
です。早めに関係者を洗い出し、顔合わせを
しましょう。
 プロジェクトコミュニティの定義
 自分達が思っているよりも、プロジェクトの
関係者に含まれる範囲は広い。
 利害関係者(ステークホルダー)の洗い出し
 実際に顔合わせする
22

23. コアチーム
[顧客]
[開発チーム]
[マネージャ]
[品証部門]
利害関係者
[XXX部門]
[YYYグループ]
[ZZZチーム]
[営業部門]
[運用部門]
[安全管理者]
[セキュリティ専門家]
・
・
・
ご近所さんを探せ
23

24. 24
技術的な解決
案を描く
夜も眠れなく
なるような問
題は？
期間を見極め
る
トレードオフ
スライダー
何がどれだけ
必要か？

25. プロジェクトの成果物をどのように実現するか、
予め決めましょう。またどこに問題が起こり
そうかも当たりを付けましょう。
 アーキテクチャの定義
 利用技術の洗い出し
 リスクの洗い出し
 構成を決める
25

26. 端末
技術的な解決案
クラウド
データ
ベース
ブラ
ウザ
[通信プロトコル
をどうする？]
[クラウドサービ
スがダウンした
ら？]
やらない
•[端末の多機種対応]
あとで決める
•[利用クラウドサービス]
•[利用データベース]
26

27. プロジェクトを進める上で、これが起きたら目
的を達成できなくなるという、最悪のケース
は何でしょうか。予めそれを想定し、対処法
や回避法を考えましょう。
 リスクの洗い出し
 リスクに対する対処法/回避法の洗い出し
 リスクへの対応に価値があるかないかを見極
める
27

28. 夜も眠れなくなるような問題
28
リスク対応の価値あり リスク対応の価値なし
[夜も眠れなくなる問題１] [夜も眠れなくなる問題４]
[夜も眠れなくなる問題２] [夜も眠れなくなる問題５]
[夜も眠れなくなる問題３] [夜も眠れなくなる問題６]

29. いつ頃終わるかという情報はやはり必要です。
プロジェクトのスケジュールを大雑把に決め
ましょう。ここで決めた事は、コミットメン
ト(確約)では有りません。
 スケジュールの定義
 どんな作業があるか洗い出す
 いつまでに終わらせる必要があるか洗い出す
29

30. 期間を見極める
[一ヶ月] [二ヶ月] [半月]
[環境構築] [トレーニング]
[開発]
30

31. プロジェクトを進める上で、作業の順序づけを
決めましょう。このプロジェクトでは何が優
先されるかで、プロジェクトの方向性が決ま
ります。
 機能・予算・時間・品質のどれを優先するか
決める
 どんな作業があるか洗い出す
 優先度は一意なものとする。同一の優先度の
ものは存在してはならない。
31

32. トレードオフスライダー
優先度 タスク
Max Min [スコープ(機能)]
Max Min [予算]
Max Min [時間]
Max Min [品質]
Max Min
Max Min
Max Min
32

33. プロジェクトにおいて、予算・期間・人員がい
つどれだけ必要になるか、決めましょう。
 人・体制・予算・機材・場所・期間等何がど
れだけ必要になるかを定義
 人員体制について、ロール(役割) 別に誰に何
を期待するのか、何人必要になるのか洗い出
しましょう
 最終的な意志決定者が誰になるか決めましょ
う
33

34. 何がどれだけ必要か？(予算・期間・人)
[一ヶ月] [二ヶ月] [半月]
[環境構築] [トレーニング][開発] [リリース！]
[5人]、 [2ヶ月半]、[1,500万円]
34

35. 何がどれだけ必要か？(俺たちの"Aチーム")
人数 役割 強みや期待する事
[1] [顧客]
[フィードバックの為に、週1で
ミーティング対応する事]
[3] [開発者] [C++の開発経験がある事]
[1] [テスター] [テスト自動化の経験がある事]
[1] [アナリスト]
[顧客要求についてチームと連携
し、分析が行える事]
35

36. 36

37.  インセプションデッキは、関係者全員で話し
合い、関係者全員で合意する為のワーク
ショップ。
 開発チームだけでも実施可能です。やれる所から
実践しましょう。
 核心を突く質問(＝手強い質問)ができるかどうか
は、やはり実践経験によります。インセプション
デッキを行い、その実施結果からどんな質問をす
べきかが導出される筈です。
37

38.  10の手強い質問は、必ずしも全てを行う必要
は有りません。必要な物だけ行えば良いです。
 お試しセット
① やらないことリスト
② ご近所さんを探せ
③ トレードオフスライダー
38

39.  インセプションデッキは、常にプロジェクト
の最新状態を示します。
 内容に変更があれば、逐次ワークショップを開催
して内容を修正し、常に最新状態を保ちます。
 プロジェクトの方向性にズレを感じた時(チーム
の意識にズレがあったり、作業進捗の雲行きが怪
しくなったり)が、インセプションデッキの実施
タイミングです。
39