わたしが知らないスゴ本は、きっとあなたが読んでいる: ウォーターフォールはこう使え（まとめ）
この連載を始めたのは、Waterfall 2006を見たから。ついカッとなって書いてしまった。今は反省している。この連載は体系的じゃないし、blog よりむしろ出版物の形で問うべき。何よりも、今週の睡眠時間を大幅に犠牲にしてきたので、眠くてたまらん。 …というわけで、ここでは総括＋補足して締める。 ウォーターフォール・モデルとは、プロジェクト構造化モデルと言い換えられる。その特徴として、以下のことが挙げられる。（その1） プロジェクトを構造化し、段階を踏んで要素成果物を構築する 次に、必要な要素成果物を適切なタイミングで持ち寄り、組み上げる 要素成果物を構築する工程はスパイラル・モデルを適用できる。しかし、組み上げる工程は逐次的であることが求められる プロジェクトを構造化することにより、プロジェクトを「見える化」できる。全体と部分、出来てるところと空白のところが分かる。未確定事項がオープン
わたしが知らないスゴ本は、きっとあなたが読んでいる: ウォーターフォールはこう使え（その5）
ウォーターフォールの怨嗟の的になっているのは「ドキュメント」だろう。使うかどうかも分からぬような大量のドキュメントを書かされる。しかも顧客の一言で大幅に書き直しを命ぜられる。さもありなん。だが、ここでは、ウォーターフォール・モデルにおけるドキュメントの必要性を強調する。 ドキュメント＝契約書 なぜドキュメント化が嫌われるのか? SEの立場から言うと、ちゃんと検討していないまま、「とりあえず」ドキュメント化をさせられるから（結果、後から手直しが多発する）だろう。PGの立場からすると、理解してコードに落とすだけの内容を、なぜ語弊の出る日本語に書き直さなければならないか、疑問に思うだろう。 本当の問題はSE/PGがドキュメントを書いていること。あるいは、片手間にドキュメントを書いていることをなんとかすべき。本来なら専門部隊を準備するか、リソースを明示的に割り当て、執筆期間を設ける必要がある。 こ
わたしが知らないスゴ本は、きっとあなたが読んでいる: ウォーターフォールはこう使え（その4）
決めるべき2つの日どり 二つ目の戦略。それは「日どり」だ。「あいまいな仕様」が"今は"決まってないことを顧客自身の口から言ってもらった後は、何月何日までに仕様凍結するかプロジェクト全体のスケジュールの中で顧客と決める。「仕様の再確認」ができていない以上、そいつができる日はいつなのかを決める。 こいつを最初に決める。ここを過ぎると挽回が不可能とうい点「ポイント・オブ・ノーリターン」を"今"決める。ここまでギッチリ動機づけしておけば、仕様凍結の最大の脅威「先送り」を回避できる。 あるいは、こっちの方がもっと重要なのだが、「仕様凍結を先送りしている事実」を共有できる。極端な話、仕様が凍結されていないのが問題なのではない。仕様が凍結されていないことが公になっていないまま、先へ進んでいるほうが深刻なり。 表向きは仕様は固まっているはずなので、顧客からは口頭や電話だけで「指示」がくる。当然、仕様書は書
わたしが知らないスゴ本は、きっとあなたが読んでいる: ウォーターフォールはこう使え（その3）
ちょっと思い出して欲しい。次の弾丸が飛んでくるのはいつだろうか? 「すでに決まったはずではないか」 「そう読み取れるではないか」 「いまさら言われても困る」 よい子のみんなはもちろん分かってる。納品が間近に迫ってきたときだね。品質がアレなのか、そもそもマトモにできていないことが明らかになったか、トリガーは様々だけど、たいていはプロジェクトも終盤になってそんな弾丸が飛んでくる。 これは「仕様のあいまい性」を先送りしてきたツケだ。実はこの弾丸、プロジェクトを通じて3度発射する機会があるという。 1回目：顧客との契約時、仕様の確認をするとき 2回目：ベンダーと請負会社の契約直前に、請負会社から仕様の確認を求められ、顧客に問い合わせるとき 3回目：火ダルマになっていることが知れ渡り、顧客が乗り込んできて「こんなのを作れなんて言ってない」と言い放つとき .…にもかかわらず、3回目がほとんどだろ。この
わたしが知らないスゴ本は、きっとあなたが読んでいる: ウォーターフォールはこう使え（その2）
ウォーターフォール・モデルとは一言で説明するなら、「プロジェクトの構造化」だ。逐次実行や先手管理、進捗の予実管理なんざ、特徴的だが本質ではない。それらはキチンと構造化された後に実現できる。プロジェクトの構造化をしないまま先手管理しようとするからおかしくなる。 プロジェクトの構造化はこうやる ウォーターフォールは逐次的な開発技法であり、ウォーターフォール全体として「分析>設計>製造>試験」とはならない。顧客受けしやすいようそんな絵を書くこともあるが、実質は異なる。 「すべきこと」単位に分解して、「すべきこと」同士の順序性を決めた後、「すべきこと」同士では逐次的な関係を守らせるようにすることが本当。 「すべきこと」の分け方は「分析」「設計」「製造」「試験」ではない。これらは分断するものではない。「なんちゃってウォーターフォール」をダメにしているのは、工程（＝フェーズ）ごとにチームを割り、それぞ
わたしが知らないスゴ本は、きっとあなたが読んでいる: ウォーターフォールはこう使え（その1）
ウォーターフォール・モデル悪玉論が幅を利かせている。一方でスパイラル・モデルやアジャイル・モデルがもてはやされている、銀の弾丸のごとく。 曰く、 この無駄な成果物を作らされているのはウォーターフォールだから あいまいな仕様と理不尽な要求に振り回されているのはウォーターフォールだから スケジュール後半になって追い立てられるのはウォーターフォールだから いつまでたっても品質が向上しないのはウォーターフォールだから 赤字プロジェクトが垂れ流されているのはウォーターフォールだから このプロジェクトがデスマってるのはウォーターフォールだから 偉大な（?）グルの尻馬に乗って叩く。まるでウォーターフォールという軛がボクの創造性と可能性をことごとくダメにしていると言わんばかりに。何かに責任転嫁して考えを止めるのは楽だけど、その「何か」が真の原因で無い限り、解決にはならない。 仕事ができないのは道具が悪いと
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
