うそのアジャイル、まことのアジャイル
～アジャイル開発はこうして形骸化する～
2016/1/22 12002-2016 Eiwa System Management, Inc.
株式会社永和システムマネジメント
コンサルティングセンター
センター長 天野勝
http://www.esm.co.jp/service/consulting/

 2001年に「アジャイルソフトウェア開発宣言」がされ
てから、15年が経ちました。
 「アジャイル」という考え方は、ソフトウェア開発の枠
を飛び越え、ビジネス領域へと拡張されており、多く
の支持を得ることができています。
 しかしその一方で、アジャイル開発に取り組み、失
敗をしている例も増えてきています。
 このような事例から、皆さんがアジャイル開発とど
のように付き合うべきかを考えるきっかけになれば
と考えております。
22002-2016 Eiwa System Management, Inc.2016/1/22
セミナーの概要

アジャイル開発とは？
2016/1/22 32002-2016 Eiwa System Management, Inc.

42002-2016 Eiwa System Management, Inc.2016/1/22
アジャイルソフトウェア開発宣言
http://agilemanifesto.org/iso/ja/principles.html
「アジャイル開発宣言」と同時に、
各手法の共通項を原則としてまと
めた。
当時、軽量級と呼ばれていたソフトウェア開
発手法の提唱者により、各手法の共通点を
まとめて、「アジャイル開発宣言」とした。
http://agilemanifesto.org/iso/ja/

52002-2016 Eiwa System Management, Inc.2016/1/22
動くソフトウェアを、反復・漸進的に作る
優先順位の高い要求から少しずつ作り上げていく
分析
設計
実装
テスト
時
間
時
間
要求(スコープ) 要求(スコープ)
ウォータフォール アジャイル
計画
Beck 2000Royce 1970
各工程を
並行で実施
各工程を
1回ずつ順に実施
1～4週間
イテレーション
動く
ソフトウェア

62002-2016 Eiwa System Management, Inc.2016/1/22
多重のPDCAサイクル
イテレーション毎に動くソフトウェアを開発する
Plan
・イテレーション計画会
Do
・朝会
・開発
Done
Keep Try
Problem
KPT
DoneToDo Doing Done
ﾀｽｸﾎﾞｰﾄﾞ 動く
ソフトウェア
ﾊﾞｰﾝﾀﾞｳﾝﾁｬｰﾄ
動作させて
確認するので
ごまかせない
Plan
・インセプションデッキ
・リリース計画会
プロダクト
バックログ
要求
要求
要求
要求
要求
要求
要求
CheckAct
・ふりかえり会
・レビュー会
PDCA

 プロジェクトを始めるにあたり、プロジェクトの関係
者で合意すべきことを話し合うセッション、および、
そのための質問
72002-2016 Eiwa System Management, Inc.2016/1/22
インセプションデッキ
出典： 『アジャイルサムライ』サポートページ https://github.com/agile-samurai-ja/support
我われはなぜここにいるのか
• 大事な理由その1
• 大事な理由その2
• 大事な理由その3
<このプロジェクトの根幹に
関わる理由を1つ、ここに書く>
エレベーターピッチ
• [潜在的なニーズを満たしたり、
潜在的な課題を解決したり] したい
• [対象顧客] 向けの、
• [プロダクト名] というプロダクトは、
• [プロダクトのカテゴリー] です。
• これは [重要な利点、対価に見合う説得力のある理
由] ができ、
• [代替手段の最右翼] とは違って、
• [差別化の決定的な特徴] が備わっている。
パッケージデザイン
(プロダクトの名前)
(素敵な写真)
(最高のキャッチコピー)
(ユーザーへのアピールその1)
(ユーザーへのアピールその2)
(ユーザーへのアピールその3)
やらないことリスト
やる やらない
あとで决める
プロジェクトコミュニティは...
コアチーム
(○○グループ)
(他のチーム)
(ほげほげ部門)
関係者全員を！
...思っているよりもずっと大きい！
技術的な解決策の概要
←リスクがある箇所
←今回は対象外
採用する技術:
* <プログラミング言語>
* <ライブラリ>
* <ツール>
* <その他の要素技術>
夜も眠れなくなるような問題は何だろう?
• もし起きたらこわーいこと、その1
• もし起きたらこわーいこと、その2
• もし起きたらこわーいこと、その3
俺たちの“Aチーム”
人数 役割 強みや期待すること
1 アナリスト 必要な分だけ必要なときに分析するスタイルで働ける。
テストも喜んで手伝える。
素早い繰り返し型の開発スタイルで働ける。
2 開発者 C#、MVC.NET、jQuery、SQL
ユニットテスト、リファクタリング、TDD、
継続的インテグレーション
0.5 マネージャ 顧客と直接顔を合わせてのコミュニケーションを担当する。
状況報告、スコープ調整、予算管理、レポートラインへの報告
期間を見極める
リリース!
構築 受入テスト トレーニング
~3ヶ月
あくまで推測であって、確約するものではありません。
1週間 1週間
トレードオフ・スライダー
典型的なフォース
機能をぜんぶ揃える(スコープ)
予算内に収める(予算)
期日を死守する(時間)
高い品質、少ない欠陥(品質)
MAX MIN
MAX MIN
MAX MIN
MAX MIN
上記以外で重要なこと
簡単に使える
考えさせない！
詳細な証跡(なんでもログを取る)
(などなど)
MAX MIN
MAX MIN
MAX MIN
MAX MIN
初回のリリースに必要なもの
3名、3.5ヶ月、$250K
リリース!
構築 受入テスト トレーニング
~3ヶ月 1週間 1週間
<プロジェクトの名前>
<スポンサーの名前>

アジャイルチーム
82002-2016 Eiwa System Management, Inc.2016/1/22
アジャイル開発の主な登場人物
3つの役割でチームを運営する
プロダクト
オーナー
(顧客)
プロセスが円滑に進
むようにする人達 支援者
開発者
要求
成果物
支援
市場
ニーズ
サービス 要求をもとに開発を
する人達
スクラムでは
・支援者⇒スクラムマスター
ビジネスの責任者と
して、成果物の価値
を最大化する人(達)
ユーザー 役割は目印で、
実際の肩書とは
異なることもある

92002-2016 Eiwa System Management, Inc.2016/1/22
アジャイルソフトウェア開発宣言
http://agilemanifesto.org/iso/ja/
当時、軽量級と呼ばれて
いたソフトウェア開発手法
の提唱者により、各手法
の共通点をまとめて、「ア
ジャイル開発宣言」とした。
（2001年2月）

102002-2016 Eiwa System Management, Inc.2016/1/22
アジャイル界隈の歴史
•Lean/Agile
•Agile/UX
•大規模
•組織改革
XP
2000
Agile
2001
スクラム
FDD, Crystal,
DSDM, ASD
2010
リーンソフトウェア開発
Evo
Patterns
TPS
Deming Lean
2015
Kanban
Lean Startup
Enterprise Agile
・SAFe
・DAD
KAIZEN
Scrum

112002-2016 Eiwa System Management, Inc.2016/1/22
アジャイルソフトウェア開発の適用範囲
ソフトウェアの開発手法
ソ
フ
ト
ウ
ェ
ア
層
シ
ス
テ
ム
層
IT 業
務
層
事
業
層
事業要件
業務要件定義
システム要件定義
システム方式設計
ソフト方式設計
ソフトウェア要件定義
事業評価
(業務)運用テスト
システムテスト
システム方式結合
プログラミング
ソフトウェア結合
ソフトウェアテスト
参考：IPA「共通フレーム2007 第2版」

122002-2016 Eiwa System Management, Inc.2016/1/22
アジャイル開発に分類される手法は多数
各提唱者の成功事例や視点によってバリエーションがある
APM
©アジャイルプロセス協議会
アジャイルプロジェクトマネジメントWG
RUP
WF
軽量
UP
ASD
スクラム
FDD
DSDM
XP
人の関わり方
（アクティブ）
人の関わり方
（パッシブ）
プロダクト重視
マネジメント重視
リーン
AM
アジャイル開発に
分類される手法

132002-2016 Eiwa System Management, Inc.2016/1/22
代表的なアジャイル開発手法
各手法は提唱者の関心事で情報をまとめたものにすぎない
XP
Extreme
Programming
Kent Beckらが提唱している手法。
「変化ヲ抱擁セヨ」をスローガンとして、ソフトウェア開
発技術の複数のベストプラクティスを極端に実施する
ことで、開発サイクルを素早く回す。
開発者視点
・原理/原則
・開発プラクティス
・管理プラクティス
スクラム
Scrum
Ken Schwaber、Jeff Sutherlandらが提唱している手法。
ソフトウェア開発のマネジメント面にフォーカスをあて、
チームを自律的に動かすための場作りの仕掛け（フ
レームワーク）を提供している。
管理者視点
・原理/原則
・管理プラクティス
リーン
Lean Software
Development
Mary Poppendiekらが提唱している手法（考え方）。
トヨタ生産方式をお手本として、ソフトウェア開発を成
功させるための原則集。この原則をもとに、具体的な
プラクティスを生み出す。第一原則は「ムダの排除」。
経営者視点
・原理/原則

142002-2016 Eiwa System Management, Inc.2016/1/22
様々なプラクティス
http://guide.agilealliance.org/subway.html
Niko-niko

152002-2016 Eiwa System Management, Inc.2016/1/22
チームムードの見える化：ニコニコカレンダー
http://www.geocities.jp/nikonikocalendar/index_ja.html

162002-2016 Eiwa System Management, Inc.2016/1/22
バグの見える化：バグレゴ
協力：チェンジビジョン

テーマ：作業を効率的に行なうために
172002-2016 Eiwa System Management, Inc.2016/1/22
KPT(けぷと)ふりかえり
Keep、Problem、Tryの観点でふりかえる
Keep Try
Problem
(1‘)試してみてうまくいったこと／続けること
(2) 不満点、問題点
(4)Problemに効きそうな改善策
(3)Keepを強化する改善策
(1)続けること、良いこと
開始前に深呼吸する
机の上を片付ける
●焦ったら、深呼吸する
●迷ったら、アラームを挙げる
●....
●作業場所が狭い
●迷うことが多い
●....
●机の上を片付ける
●立って行なう
●荷物はイスの上に置く
●事前に何をするか、確認
する
●開始前に深呼吸する
(6)試すことを選択、
合意する
(5)工夫したいこと
●指のストレッチをする
●....
参考：『これだけ！KPT』

リスクコントロール
2016/1/22 182002-2016 Eiwa System Management, Inc.

 プロジェクトを始めるにあたり、プロジェクトの関係
者で合意すべきことを話し合うセッション、および、
そのための質問
192002-2016 Eiwa System Management, Inc.2016/1/22
インセプションデッキ
出典： 『アジャイルサムライ』サポートページ https://github.com/agile-samurai-ja/support
我われはなぜここにいるのか
• 大事な理由その1
• 大事な理由その2
• 大事な理由その3
<このプロジェクトの根幹に
関わる理由を1つ、ここに書く>
エレベーターピッチ
• [潜在的なニーズを満たしたり、
潜在的な課題を解決したり] したい
• [対象顧客] 向けの、
• [プロダクト名] というプロダクトは、
• [プロダクトのカテゴリー] です。
• これは [重要な利点、対価に見合う説得力のある理
由] ができ、
• [代替手段の最右翼] とは違って、
• [差別化の決定的な特徴] が備わっている。
パッケージデザイン
(プロダクトの名前)
(素敵な写真)
(最高のキャッチコピー)
(ユーザーへのアピールその1)
(ユーザーへのアピールその2)
(ユーザーへのアピールその3)
やらないことリスト
やる やらない
あとで决める
プロジェクトコミュニティは...
コアチーム
(○○グループ)
(他のチーム)
(ほげほげ部門)
関係者全員を！
...思っているよりもずっと大きい！
技術的な解決策の概要
←リスクがある箇所
←今回は対象外
採用する技術:
* <プログラミング言語>
* <ライブラリ>
* <ツール>
* <その他の要素技術>
夜も眠れなくなるような問題は何だろう?
• もし起きたらこわーいこと、その1
• もし起きたらこわーいこと、その2
• もし起きたらこわーいこと、その3
俺たちの“Aチーム”
人数 役割 強みや期待すること
1 アナリスト 必要な分だけ必要なときに分析するスタイルで働ける。
テストも喜んで手伝える。
素早い繰り返し型の開発スタイルで働ける。
2 開発者 C#、MVC.NET、jQuery、SQL
ユニットテスト、リファクタリング、TDD、
継続的インテグレーション
0.5 マネージャ 顧客と直接顔を合わせてのコミュニケーションを担当する。
状況報告、スコープ調整、予算管理、レポートラインへの報告
期間を見極める
リリース!
構築 受入テスト トレーニング
~3ヶ月
あくまで推測であって、確約するものではありません。
1週間 1週間
トレードオフ・スライダー
典型的なフォース
機能をぜんぶ揃える(スコープ)
予算内に収める(予算)
期日を死守する(時間)
高い品質、少ない欠陥(品質)
MAX MIN
MAX MIN
MAX MIN
MAX MIN
上記以外で重要なこと
簡単に使える
考えさせない！
詳細な証跡(なんでもログを取る)
(などなど)
MAX MIN
MAX MIN
MAX MIN
MAX MIN
初回のリリースに必要なもの
3名、3.5ヶ月、$250K
リリース!
構築 受入テスト トレーニング
~3ヶ月 1週間 1週間
<プロジェクトの名前>
<スポンサーの名前>
夜も眠れなくなるような問題は何だろう?
• もし起きたらこわーいこと、その1
• もし起きたらこわーいこと、その2
• もし起きたらこわーいこと、その3
未来の問題＝リスク

202002-2016 Eiwa System Management, Inc.2016/1/22
XPが想定しているリスク
Zensow「プロダクトオーナーシップジェネレーション」研修資料より抜粋

212002-2016 Eiwa System Management, Inc.2016/1/22
リスクコントロール
トータルのコストが低減するようにリスクを管理下におく
リスク
事前対策 事後対策
インパクトを軽減
発生頻度を低減
素早く安価に対処
仕組み作り

Step1 リスクを見つける(イベント、インパクト)
Step2 リスクを発生させる要因を見つける(ドライバー)
Step3 リスクの対応策を考える
Step4 リスク対応策の実行計画を作る
リスク対応策を実行する際のリスクも考慮する
Step5 リスク対応策を実行する
222002-2016 Eiwa System Management, Inc.2016/1/22
リスクコントロールのステップ

232002-2016 Eiwa System Management, Inc.2016/1/22
リスクの構造
リスク対策はリスクの構造をもとに考える
影響
(インパクト)
事象
(イベント)
要因
(ドライバー)
要因
要因
要因
要因
リスク事象を発生させる要
因は複数存在する
事象が発生することによっ
て影響が出ることが問題
事象 要因
事象 要因
リスク事象は、他のリ
スクの要因になる

242002-2016 Eiwa System Management, Inc.2016/1/22
リスク対応策の検討
狙いを定めて、対応策を検討する
影響
(インパクト)
事象
(イベント)
要因
(ドライバー)
要因
要因
要因
要因
影響を抑える
対応策
要因の発生確率を
抑える対応策
リスク事象を発生させる要
因をなくせば、リスクは問
題にならない
リスク事象が発生しても、
影響がなければ、リスクは
問題にならない

252002-2016 Eiwa System Management, Inc.2016/1/22
リスク対応策の例
可能性の高い要因をつぶす
子供と
映画行けない
信頼を失う
明日
帰れない
飛行機
飛ばない
寝坊して
遅刻する
チケットを
なくす
雪が降る
しまった場所を
忘れる別の日に
約束する
目立つところに
しまう
あきらめる
飛行機
乗れない
目覚ましを
設定する
便を
変更する

262002-2016 Eiwa System Management, Inc.2016/1/22
リスク対応策の例
影響の大きな要因に対して、対応策を検討する
納期に
間に合わない
作業が
遅れる
作業を
やり直す
作業が
難しく
時間がかかる
かかる工数が
わからない
要件が
変更になる
納期を延ばす
交渉をする 有識者に
見積ってもらう
二人で
作業する
作業の着手が
遅れる
作業の途中で
割込みが入る
ユーザー内で
要件の合意が
とれていない
合意の会議に
参加する
少し着手して
工数を見積る
割込みを
断る
バッファ込みで
計画する

アジャイル開発の典型的な失敗
2016/1/22 272002-2016 Eiwa System Management, Inc.

 ケース1-1：上から降ってくる計画
 初期の計画が立案されてから、プロダクトオーナーが参画する。
 ケース1-2：見切り発車
 プロジェクトのリスクをあまり洗い出さずにプロジェクトを開始してしまう。
 ケース1-3：スキル不足チーム
 プロジェクト実施中にスキルが獲得できることを前提として、スキルがマッチしないメン
バーで体制を組む。
 ケース1-4：超短期間開発
 1～2か月ほどの開発プロジェクトに、アジャイル開発(インクリメンタル開発)を適用する。
282002-2016 Eiwa System Management, Inc.2016/1/22
ケース1：プロジェクト計画時の失敗

 ケース2-1：間に合わせ仕事
 イテレーション内に無理矢理に完了させる。
 しかし、ソフトウエアの内部品質が悪く、後続のイテレーションで機能追加/修正に想
定以上の手間がかかり遅延を引き起こし、さらに内部/外部の品質が悪化する。
 ケース2-2：変更されない初期要求
 プロジェクトの計画時に列挙した要求を変更することなく、プロジェクトを終える。
 ケース2-3：揮発する情報
 機能追加の際に、どのように手を付ければよいか見当がつかずに、機能を追加する
までの分析に時間がかかってしまう。
 ケース2-4：暇な開発チーム
 プロダクトオーナーがイテレーション計画の際に、具体化された要求を持ってこれな
かったため、開発チームがすることが無くなってしまい、暇を持て余してしまう。
 ケース2-5：権限のないプロダクトオーナー
 要求の優先順位を変えるのにも、プロダクトオーナーがステークホルダーにお伺いを
立てる。
 ケース2-6：リリースされないソフトウェア
 イテレーション毎にプロダクトオーナーに受け入れられてはいるが、ソフトウェアは真
のユーザーに使われていない。
292002-2016 Eiwa System Management, Inc.2016/1/22
ケース2：プロジェクト実行時の失敗

おわりに
2016/1/22 302002-2016 Eiwa System Management, Inc.

 アジャイル開発に分類される手法はあるが、アジャ
イル開発という手法は存在しない
 ある特定のリスクの回避策として、様々な開発手法、
プラクティスが存在している
 アジャイル開発はいまでも進化している
 そのうち言葉は消えるはず
 アジャイル開発に分類されている手法や、プラク
ティスは現場の知恵と工夫の成果に過ぎない
312002-2016 Eiwa System Management, Inc.2016/1/22
まとめ

現職 オブジェクト指向、アジャイル開発、開発現場の活性化をテーマに、
ファシリテーションを活用したコンサルティング、セミナーに従事
経歴 1995年 電機メーカの情報システム部門
2002年10月より現職
社外活動 けぷた倶楽部 エバンジェリスト
オブラブ 実行委員
アジャイルプロセス協議会 運営委員
日本XPユーザグループ 運営委員
日本ソフトウェアテストシンポジウム 実行委員
プロジェクトファシリテータ協会 副理事
ETロボコン審査委員
著書 『これだけ！KPT』
『eXtreme Programmingテスト技法』
『正しく学ぶソフトウエア設計』
訳書 『リーン開発の本質』
『アジャイルソフトウェア開発スクラム』
322002-2016 Eiwa System Management, Inc.2016/1/22
自己紹介
天野 勝(あまの まさる)
永和システムマネジメント
コンサルティングセンター
センター長

 株式会社 永和システムマネジメント(http://www.esm.co.jp)
 本社：福井県福井市
 1980年創業、2002年東京事務所開設
 金融、医療、オブジェクト指向
を使ったシステム開発
 コミュニティ活動や、
書籍の執筆・翻訳に積極的
332002-2016 Eiwa System Management, Inc.2016/1/22
会社紹介
福井県福井市

 本資料に関するお問い合わせは下記までお願いし
ます。
sales@esm.co.jp
twitter @esmsec
株式会社永和システムマネジメント
コンサルティングセンター
http://sec.tky.esm.co.jp/
342002-2016 Eiwa System Management, Inc.2016/1/22
お問い合わせ