時は80年代、仕様は変化することがわかった

このエントリは アジャイルCasual Advent Calendar 2014 の 4 日目のエントリです。
前回はwkubotaさんのレビューに関するエントリでした。

• 1日目が空いているのでとりあえず埋める
• 2日目にsuenamiさんがめっちゃいいこと書いてくれる
• あれに匹敵するものを書かねば！ということでKPIに関する超大作を作る
• まとまらないうちに3日目にwkubotaさんが書いてくれる
• まだまとまらないから別のネタ書こう <= イマココ

アジャイルソフトウェア要求の序章に書いてある事まとめ

• この前Amazonで買ってちまちま読み進めているけど、序章で気になった部分まとめてみる
• アジャイルとあまり関係ないけど、アジャイル前史みたいなものという理解でひとつ。

「仕様が変化する」という事実が人類に周知された過程

• 天動説と地動説のように、今まで前提とされていたことがひっくり返される事がある
  このケースにおいては、「仕様は最初の段階で全て出てくる、以降は固定である」という通説が「仕様は常に変化する」という事実に置き換えられた過程について書く

鉄の三角形

通称荒ぶる四天王(The Furious Four)として知られるQCDS(品質、コスト、納期、機能)のうち、「コスト、納期、機能」を示す言葉。
荒ぶる四天王は、言葉からするとまるで4つが同格のように思われるが、鉄の三角形では前後関係のあるものとされている。
鉄の三角形は「機能が定義できれば」「コストと納期は見積もれる」とする言葉である。
逆に言うと、要求される機能が変化すれば、コストと納期の見積もりは変化する。
顧客が契約締結から仕様を変更した場合、当初に約束された納期と見積の前提が崩れるので、納期遅れやコスト超過は必然である。
また発注サイドの「仕様は変更するが、納期と見積もりは死守」という要求に対し開発サイドは荒ぶる四天王の中で唯一自由になる品質を常に生け贄に捧げ続けることが、近年の炎上プロジェクトや使いづらいプロダクトの発生理由である、としている

相次ぐ炎上とウォーターフォールの改良

Royceが示したウォーターフォールモデルの通りに進めても炎上は不可避であるということは明らかになりつつあった。
参考資料：ウォーターフォールモデルの図
※注意： Royce当人はウォーターフォールモデルという言葉は使っていない。また、80年の論文の中で、自身が提起したウォーターフォールモデルは大規模プロジェクトには不向きであると述べている

当時のアプローチ

当時のアプローチとしては、 原因は仕様が巨大すぎることであり、
巨大すぎる仕様は頻繁な変更と、鉄の三角形に由来する納期とコストのぶれをもたらすことが問題なのだから、
仕様(Feature)を細かく分割する事でぶれを制御可能な範囲に収めようとした。

変化する仕様

現実には仕様は「発見」によって変化する、という考えが80年代以降の主流になっている。
そこでIncremental Development(反復型開発)という開発手法において、小さく区切る事で機能のぶれをおさえよう、そうすればコストと納期のぶれを小さい幅におさえられる、というアプローチがとられた。
ただしこれはウォーターフォール型を分割し、小型化しよう、というアプローチのように私には思われる。

「仕様は全てのフェーズで湧いてくる」ことが認められた

90年代、天下のIBMのRational事業部が推進するRational Unified Processにおいて、仕様は最初の調査段階で特に多く沸き出すものの、その沸き出しの波はあるが、終盤でも発生し得るものであると認められた。
また実装も初期の仕様を踏み固める段階からプロトタイピングや検証などにおいて発生し得るものであり、テストや品質担保作業は全フェーズにおいて行われるものであるとされた。

なにがいいたい？

私が経験したウォーターフォールモデルは必ず炎上する。
これは必然であり、統計によっても実証されており、理論化されている。
私が新人研修で習った大量のドキュメントは炎上を抑止する、大規模プロジェクトは大量のドキュメントと厳密な工程管理によってこそ成功させられる、というのは誤りであった。

それではみなさんご一緒に