受託開発、請負契約、エンタープライズシステムにおけるアジャイル開発の目的と実践。「見積と計画編」- アジャイルジャパン2014 -

1. エンタープライズでも
できるアジャイル開発
上田 善行 河村 博文
2014年6月27日
シーアイアンドティー・パシフィック株式会社
Agile Japan 2014
D Sharon Pruitt

2. 昨年に続き、できるシリーズ
www.slideshare.net/yoshiyukiueda にアクセス

3. ● 受託開発におけるアジャイル開発の見積と計画技法
○ 誰でもできる
○ コンセプトの提案ではなく当社が実践している
○ 請負契約に対応
○ 受託開発以外でも参考になる
本セッションの概要

4. ● 上田 善行 ASPACビジネスディレクター
○ ueda@ciandt.com / @yoshiyukiueda
● 河村 博文 ASPACプログラムマネージャ
○ kawamura@ciandt.com / @hirobumiK
● シーアイアンドティーについて
○ アジャイル専門のグローバルITサービス
○ 日本を含む5カ国で事業展開
○ 1995年設立、従業員1700名
○ www.ciandt.com
自己紹介

6. アジャイル

7. エンター
プライズ
向け
スタート
アップ
向け
正解は一つじゃない

8. エンタープライズ

9. ● 全体の見積ができないはず
● 範囲が明確でないはず
● スケジュールが明確でないはず
● 請負契約ではできないはず
● 受託開発には向かないはず
アジャイル開発を採用しない理由

10. ● 開発前に要件が明確にできない
● プロジェクト途中でも仕様を変更したい
● 開発リスクを下げたい
● ユーザー（利用部門）の満足度をあげたい
● 必要かどうかわからない機能を開発したくない
アジャイル開発を採用したい理由

11. イメージの世界
ウォーターフォール
計画で
精密
アジャイル
偶発的で
粗雑

12. ウォーターフォールの幻想

13. ● ブレない見積
● 計画性と柔軟性の両立
● WFよりも高い予測可能性、生産性、品質
● 開発リスクの低減
● 予算内で最高のROI
あるべきエンタープライズアジャイル

14. とりあえず始める？

15. ● スプリントが期間内に終わらない
● ベロシティが安定しない
● 品質があがらない
● モノが良くない
● チーム内の空気が重い
とりあえずアジャイルの問題

16. これらの問題は
開発前に発生している

17. 誰でもできる
完全な
見積と計画

18. 計測が

19. 測る

20. ● プロダクトバックログを用意する
● ストーリーを記入する（粒度や完成度は問わない）
● プラニングポーカーで各規模を推定する（開発陣）
● 全体規模を算出する
● しかし。。。
要求の規模を測る

21. ● 規模のルールを策定する
○ 人間が見積る為、選択肢は少なく
○ 工数ではなく規模（複雑性）で見積る
○ 一定以上の規模は分解する
○ 開発するチームが見積る
○ 事前情報（予算等）は与えない
○ 最初に最も小さい規模を特定
○ お客様とレビューする
○ 客観的な評価軸をもつ
要求の規模を測る前に

22. 全体規模（ストーリー*規模）
この時点でわかるもの

23. 計る

24. ● プロダクトバックログから任意のストーリーを抽出
● バックログに占める各規模の分布割合を意識する
● 抽出するストーリー数は全体数の10∼20%まで
● 抽出したストーリーに対して工数（時間）で見積る
● しかし。。。
規模あたりの時間を計る

25. ● 確率の式を策定する
○ CI&Tでは、PERTを利用
「PERT法」は、楽観的、悲観的、
中庸の３種の見積もり時間を割り
当て、β分布という確率分布を用
いて重ねあわせることにより、
全体のスケジュールに必要な時間
を確率的に表現することが出来る。
見積工数がはずれる確率を織り込む

26. 開発生産性
営業日（製造／規模）
この時点でわかるもの

27. 量る

28. ● 開発時間の前提は過去の平均で決める
○ 製造、テスト、バグ修正、非製造時間を割合で
● チームの種別と各人数を決める
○ CI&Tでは、チームを２種類に分けている
■ POチーム：PM、SM、アーキテクト
■ バーニングチーム：開発者（テスター含む）
■ バーニングチームのみがバーンダウンする
開発時間の前提とチームを定義する

29. 開発時間の前提とチームの定義例

30. 開発生産性
営業日（開発者／規模）
この時点でわかるもの

31. 図る

32. ● スプリントの日数を定義する
○ インセプション、開発、リリーススプリント
○ 開発スプリントの日数は各回とも必ず共通
● 生産性がすでに算出できている為、この時点で必要
スプリント数が判明する
● ベロシティを確定させる為に、効率性を定義する
（ベロシティに対してかける効率性）
○ 例：初回スプリントは、85％の効率性
スプリントを定義する

33. スプリントと効率性の定義例

34. ベロシティ
（規模／スプリント）
必要スプリント数
この時点でわかるもの

35. 各要求のビジネス価値を定義する
● 各要求（ストーリー）の価値評価を実施
○ 価値の高い順にスプリント計画に入れる

36. そうして完成する
全体の計画

37. アジャイル開発計画
● プロジェクトの全体計画
○ 全体の見積（工数）
○ 各要求の開発優先順位
○ 各要求別の見積
○ 各要求の価値と見積の比較

38. 計測、分析、改善は続く
● 生産性
● 予測可能性
● 品質
● アーキテクチャ
● 人（KPML & PDP）

39. まとめ

40. 規模のルール
要求の
収集
（開発）
要求の
規模
特定
任意の
ストーリー
抽出
任意の
ストーリー
工数算出
確率を
反映した
生産性算出
チーム
体制の
定義
工程毎の
開発時間
割り出し
スプリント
日数の
定義
ベロシティ
効率性の
適用
スプリント
数の算出
日程への
落とし込み
外部マイル
ストーン
との調整
全体計画と
コスト策定
要求価値と
開発の優先
順位決定
スプリント0
スタート
確率のルール 開発工程のルール
見積と計画のプロセス
ビジネスゴールの共有

41. アジャイル開発の役割

42. ● 全体の見積ができる
● 範囲が明確にできる
● スケジュールが明確にできる
● 請負契約でもできる
● 受託開発にも向く
アジャイル開発でも

43. ● 開発前に要件が明確でなくても計画できる
● プロジェクト途中でも仕様の変更ができる
● 開発リスクが下がる
● ユーザー（利用部門）の満足度があがる
● 必要かどうかわからない機能は開発させない
アジャイル開発だから

44. 1時間では語り尽くせない
エンタープライズでもできる
アジャイル開発。
開発管理編、アーキテクチャ編など
またの機会にお話させて頂きます！
ご意見・ご質問は ueda@ciandt.com まで

45. ありがとうございました。