工程の考え方を変える

設計でしかわからないのであれば先にやる。
あらかじめやったほうがいいものは先にやる。
作るために最適の工程を考える。

原則はこう。

・作りたいものはどういうものかを考える（要求定義とか要件定義）

・作ったものがいいのかどうかを評価する（総合試験とかリリーステストとか）

で、間に入るのは、システムを作るってこと。

デザイン（設計）、構築、試験、
これの繰り返し。

これで十分では？

おおよそ、アジャイル開発を現実的なＳＩビジネスに適応しようとすると、ほぼこうなる。

これをショートレンジで手早くやるなら、アジャイル的。
長めに設定して、ある程度の成果を確実に出していくなら、
・・・・なんだろうな、アジャイル的な要素を入れた、本当のウォーターフォールだろうか。

工程ごとに区切り、そのたびに契約していくって考え方より、
一回、実装の確からしさを受けて、見積もりしなおし、都度、契約しなおすほうが、より現実的。

ってこと。

あ、実装のスコープは、段階を経てすこしづつ収束していくってことでどうだろうか。

なんでか、一気に作りたがるのがＳＩの性か。

それはね、次回の日記に・・・