1. すくすくスクラム瀬戸内
2010年2月5日（金）
岡山国際交流センター
すくすくスクラム瀬戸内 1

2.  今村哲也
 ｕｎｌｉｍｉｔｅｄ ｗｏｒｋｓ 代表
 認定スクラムマスター
 twitter tetsuyai
 e-mail mail@tetsuyai.com
 独立系ＳＩｅｒの子会社 ⇒ 独立
 ビジネス情報系のシステム開発
 官公庁、原子力発電所、空港
 チームリーダー、プロジェクトリーダー
すくすくスクラム瀬戸内 2

3. すくすくスクラム瀬戸内 3

4. 絵を、他のグループに見せないでください。
すくすくスクラム瀬戸内 4

5.  右隅に大きな丘がありま
す。
 丘の上を赤いトンボが飛
んでいます。
 赤いトンボの後ろを青い
トンボが飛んでいます。
 丘のふもとには３軒の家
があります。
 ３軒の家には窓がありま
す。
など
すくすくスクラム瀬戸内 5

6.  右隅に大きな丘があり
ます。
 丘の上を赤いトンボが
飛んでいます。
 赤いトンボの後ろを青
いトンボが飛んでいま
す。
 丘のふもとには３軒の
家があります。
 ３軒の家には窓があり
ます。
など
すくすくスクラム瀬戸内 6

7. 説明文を書く
 すべてを文章にできましたか？
 誤解のない文章にできましたか？
絵を描く
 説明文が意図した通りの絵でしたか？
 絵に想像や先入観が反映されていませんでしたか？
すくすくスクラム瀬戸内 7

8. すくすくスクラム瀬戸内 8

9. 要件
設計 構築 試験 運用
定義
すくすくスクラム瀬戸内 9

10. 本当に？
すくすくスクラム瀬戸内 10

11. １９９４年のスタンディッシュ・グループによる調査結果
プロジェクト失敗率 ８３．８％
（大企業に限定すると９１％にも！）
うち３１．１％は完成前に中止され、
残りの５２．７％は平均８９％の開発費超過に陥った。
すくすくスクラム瀬戸内 11

12. プロジェクトに問題が起きる原因
ユーザーからの情報が
不足している
13%
要求や仕様が不完全で
ある
12% 要求や仕様が変化する
49%
経営幹部からの支援が
12% 不足している
技術が不足している
7%
7% その他
すくすくスクラム瀬戸内 12

13. プロジェクトが中止される原因
要求が不完全である
13%
ユーザーの関与が不足
している
36%
12% リソースが不足してい
る
非現実的な期待をされ
11% る
経営幹部からの支援が
9% 10% 不足している
9% 要求や仕様が変化する
すくすくスクラム瀬戸内 13

14. 2003年のスタンディッシュ・グループによる調査結果
プロジェクト失敗率 ６６％
少しは改善されているけれど、
まだ過半数のプロジェクトは失敗している。
すくすくスクラム瀬戸内 14

15. プロジェクト失敗率 ７５％
うち４６％はニーズを満たさなかったため、
（仕様は満たしていたが）一度も使用されなかった。
残りの２０％はニーズを満たすように、
大規模な改修が施された。
すくすくスクラム瀬戸内 15

16. 要求した機能を実際に使っている度合い
7%
13%
いつも使う
45% よく使う
ときどき使う
16% ほとんど使わない
まったく使わない
19%
すくすくスクラム瀬戸内 16

17. プロジェクト失敗率 ８７％
スコープ管理が、
８２％で最大の失敗要因であり、
２５％で全体に影響を及ぼした失敗要因である。
すくすくスクラム瀬戸内 17

18. 「詳細に要求を定義し、そのあと長い時間をか
けて開発した後でそれを納品するというアプ
ローチは、もはや不適切だということであ
る。
ビジネス要求が高い確率で変わるということ
は、要求を文書化した後に大きな変更はほと
んど加えられないという想定が基本的に間
違っていること、そして、多くの時間や工数
をかけて要求を最大限に定義してもだめだと
いうことを意味する。」
すくすくスクラム瀬戸内 18

19. ２００３年の日経コンピュータによる調査結果
プロジェクト失敗率 ７３．３％
すくすくスクラム瀬戸内 19

20. プロジェクトの品質問題の原因
プロジェクトの品質問題の原因
要件定義が十分ではなかった 35.9
テストが不十分・移行作業に問題が… 21.9
システムの設計が不正確だった 19.1
エンドユーザーへの教育が不十分… 19.1
システムの企画が十分ではなかった 18.7
社内の開発体制に問題があった 13.9
システムの開発作業の質が悪かった 13.1
ベンダーの選択に問題があった 10.6
運用計画が利用実態に沿っていな… 7.6
その他 27.7
すくすくスクラム瀬戸内 20

21. 失敗、してますね ^^;;
すくすくスクラム瀬戸内 21

22. しかも原因の第一位は
「要件定義」！！
すくすくスクラム瀬戸内 22

23. 典型的なソフトウェアプロジェクトでは
２５％の要件は変化する
すくすくスクラム瀬戸内 23

24. ソフトウェアプロジェクトにおける変更の割合
35
要求変更の割合（％）
30
25
20
15 ソフトウェアプロジェ
クトにおける変更の割
10
合
5
0
10 100 1000 10000
プロジェクトの規模（ファンクションポイント）
すくすくスクラム瀬戸内 24

25. 1998年のロバート・オースティン氏とリチャード・ノーラン氏による
大規模ソフトウェア開発プロジェクトに関する調査結果
第1の誤った前提
大規模プロジェクトを計画通りに遂行することが可能であるというも
のである。
第2の誤った前提
プロジェクト後半における仕様変更を避けることが可能であるという
ものである。
第3の誤った前提
大規模なプロジェクトほど早期に仕様を凍結することが理に適ってい
るというものである。
すくすくスクラム瀬戸内 25

26. ソフトウェアシステムの新規開発において、システム
の要件はユーザーがそのシステムを使用する時になる
まで完全に明確化されることがない。
（ワッツ・ハンフリー氏、ＩＢＭ）
すくすくスクラム瀬戸内 26

27.  ワークショップではいかがでしたか？
 現実には７０～９０％ものプロジェクトが失敗して
います。
 それらすべてが失敗原因の第一位に「要件定義」を
挙げています。
 複数の研究者が、要件定義は２５％以上も変化
する、という調査結果を報告しています。
すくすくスクラム瀬戸内 27

28. 要件
設計 構築 試験 運用
定義
すくすくスクラム瀬戸内 28

29. 本当に？
すくすくスクラム瀬戸内 29

30. すくすくスクラム瀬戸内 30

31.  ユーザー自身が、望んでいることを正確に把握して
いない。
 ユーザーから開発者に、望んでいることや知ってい
ることがうまく伝わらない。
 要求の細部は開発してみなければ明らかにならな
い。
 要求の細部は複雑すぎて理解しづらい。
 開発途中の製品を見て、ユーザーの気が変わる。
 環境からの働きかけによって、要求が変わったり増
えたりする。
すくすくスクラム瀬戸内 31

32. 最初に要件定義が完成しない以上、すべてを計画し、
計画通りにプロジェクトを進めることはできない。
計画の代わりに中心に据えるもの
お客様にとっての価値
すくすくスクラム瀬戸内 32

33. 要求した機能を実際に使っている度合い
7%
13%
いつも使う
45% よく使う
ときどき使う
16% ほとんど使わない
まったく使わない
19%
すくすくスクラム瀬戸内 33

34. スペースシャトルのソフトウェアの心臓部
1977年～1980年
⇒ ウォーターフォール・モデルが理想的と信じられていた時代
⇒ 初期の反復型開発の成功例、31ヶ月で17回のイテレーション
「ウォーターフォール・モデルが適していなかったの
は、シャトルのプログラムに対する要求が、ソフト
ウェアを開発している間もずっと進化し続けていた
からである」
すくすくスクラム瀬戸内 34

35. すくすくスクラム瀬戸内 35