すくすくスクラム瀬戸内_要件定義の嘘_20100205

すくすくスクラム瀬戸内

2010年2月5日（金）

岡山国際交流センター

1すくすくスクラム瀬戸内

今村哲也ｕｎｌｉｍｉｔｅｄｗｏｒｋｓ代表認定スクラムマスター

twitter tetsuyai e-mail [email protected]

独立系ＳＩｅｒの子会社 ⇒ 独立ビジネス情報系のシステム開発官公庁、原子力発電所、空港

チームリーダー、プロジェクトリーダー


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


絵を、他のグループに見せないでください。


右隅に大きな丘があります。

丘の上を赤いトンボが飛んでいます。

赤いトンボの後ろを青いトンボが飛んでいます。

丘のふもとには３軒の家があります。

３軒の家には窓があります。

など


右隅に大きな丘があります。

丘の上を赤いトンボが飛んでいます。

赤いトンボの後ろを青いトンボが飛んでいます。

丘のふもとには３軒の家があります。

３軒の家には窓があります。

など

説明文を書く

すべてを文章にできましたか？

誤解のない文章にできましたか？

絵を描く

説明文が意図した通りの絵でしたか？

絵に想像や先入観が反映されていませんでしたか？



要件定義

設計構築試験運用


本当に？


１９９４年のスタンディッシュ・グループによる調査結果

プロジェクト失敗率８３．８％

（大企業に限定すると９１％にも！）

うち３１．１％は完成前に中止され、

残りの５２．７％は平均８９％の開発費超過に陥った。


13%

12%

12%

7%7%

49%

プロジェクトに問題が起きる原因

ユーザーからの情報が

不足している

要求や仕様が不完全で

ある

要求や仕様が変化する

経営幹部からの支援が

不足している

技術が不足している

その他


13%

12%

11%

10%9%

9%

36%

プロジェクトが中止される原因

要求が不完全である

ユーザーの関与が不足

している

リソースが不足してい

る

非現実的な期待をされ

る

経営幹部からの支援が

不足している

要求や仕様が変化する


2003年のスタンディッシュ・グループによる調査結果

プロジェクト失敗率６６％

少しは改善されているけれど、まだ過半数のプロジェクトは失敗している。


プロジェクト失敗率７５％

うち４６％はニーズを満たさなかったため、（仕様は満たしていたが）一度も使用されなかった。

残りの２０％はニーズを満たすように、大規模な改修が施された。


7%

13%

16%

19%

45%

要求した機能を実際に使っている度合い

いつも使う

よく使う

ときどき使う

ほとんど使わない

まったく使わない


プロジェクト失敗率８７％

スコープ管理が、

８２％で最大の失敗要因であり、２５％で全体に影響を及ぼした失敗要因である。


「詳細に要求を定義し、そのあと長い時間をかけて開発した後でそれを納品するというアプローチは、もはや不適切だということである。

ビジネス要求が高い確率で変わるということは、要求を文書化した後に大きな変更はほとんど加えられないという想定が基本的に間違っていること、そして、多くの時間や工数をかけて要求を最大限に定義してもだめだということを意味する。」


２００３年の日経コンピュータによる調査結果

プロジェクト失敗率７３．３％


27.7

7.6

10.6

13.1

13.9

18.7

19.1

19.1

21.9

35.9

その他

運用計画が利用実態に沿っていな…

ベンダーの選択に問題があった

システムの開発作業の質が悪かった

社内の開発体制に問題があった

システムの企画が十分ではなかった

エンドユーザーへの教育が不十分…

システムの設計が不正確だった

テストが不十分・移行作業に問題が…

要件定義が十分ではなかった

プロジェクトの品質問題の原因

プロジェクトの品質問題の原因


失敗、してますね ^^;;


しかも原因の第一位は「要件定義」！！


典型的なソフトウェアプロジェクトでは

２５％の要件は変化する


0

5

10

15

20

25

30

35

10 100 1000 10000

要求

変更

の割

合（

％）

プロジェクトの規模（ファンクションポイント）

ソフトウェアプロジェクトにおける変更の割合

ソフトウェアプロジェ

クトにおける変更の割

合


1998年のロバート・オースティン氏とリチャード・ノーラン氏による大規模ソフトウェア開発プロジェクトに関する調査結果

第1の誤った前提

大規模プロジェクトを計画通りに遂行することが可能であるというものである。


プロジェクト後半における仕様変更を避けることが可能であるというものである。


大規模なプロジェクトほど早期に仕様を凍結することが理に適っているというものである。


ソフトウェアシステムの新規開発において、システムの要件はユーザーがそのシステムを使用する時になるまで完全に明確化されることがない。

（ワッツ・ハンフリー氏、ＩＢＭ）


ワークショップではいかがでしたか？

現実には７０～９０％ものプロジェクトが失敗しています。

それらすべてが失敗原因の第一位に「要件定義」を挙げています。

複数の研究者が、要件定義は２５％以上も変化する、という調査結果を報告しています。


要件定義

設計構築試験運用


本当に？



ユーザー自身が、望んでいることを正確に把握していない。

ユーザーから開発者に、望んでいることや知っていることがうまく伝わらない。

要求の細部は開発してみなければ明らかにならない。

要求の細部は複雑すぎて理解しづらい。

開発途中の製品を見て、ユーザーの気が変わる。

環境からの働きかけによって、要求が変わったり増えたりする。


最初に要件定義が完成しない以上、すべてを計画し、計画通りにプロジェクトを進めることはできない。

計画の代わりに中心に据えるもの

お客様にとっての価値


7%

13%

16%

19%

45%

要求した機能を実際に使っている度合い

いつも使う

よく使う

ときどき使う

ほとんど使わない

まったく使わない


スペースシャトルのソフトウェアの心臓部

1977年～1980年

⇒ ウォーターフォール・モデルが理想的と信じられていた時代

⇒ 初期の反復型開発の成功例、31ヶ月で17回のイテレーション

「ウォーターフォール・モデルが適していなかったのは、シャトルのプログラムに対する要求が、ソフトウェアを開発している間もずっと進化し続けていたからである」



Technology

すくすくスクラム瀬戸内_要件定義の嘘_20100205