ビッグピクチャー

Dreaming in CodeのJoelによる書評から。
http://local.joelonsoftware.com/mediawiki/index.php/%E3%83%93%E3%83%83%E3%82%B0%E3%83%94%E3%82%AF%E3%83%81%E3%83%A3%E3%83%BC

これの具合の悪い副作用の1つは、心がものごとをどれほどはっきり理解しているかについて過大評価しがちだということだ。心はいつでも「ビッグピクチャー」を持っているつもりでいる。たとえそうでないときであっても。
このことはソフトウェア開発においてはとりわけ危険な罠となる。やりたいことの大まかなアイデアが頭の中にできると、それはまったく明快で何かをデザインする必要があるとさえ思われない。すぐに飛び込んでビジョンの実装に取りかかれると感じる。
たとえばあなたのビジョンは古いDOSのスケジュール管理ソフトの再構築だったとしよう。それは大変結構なのだけど、ぜんぜんお勧めできない。それは簡単なことのように見える。それがどう機能するかは明らかなように思える。あなたは何かをデザインしようとさえしない･･･そして一団のプログラマを雇って、コードをバリバリ書き始める。
ここであなたは2つの間違いを犯している。
第一に、心の自信過剰のトリックに引っかかっている。「ああ、これのやり方ならよくわかっている! まったく分かり切ったことだ。仕様を詰める必要もない。ただコードを書きゃいいんだ」
第二に、デザインする前にプログラマを雇ってしまっている。それがまずいのは、ソフトウェアをデザインしようとするのより難しい唯一のことは、チームでソフトウェアをデザインすることだからだ。

去年は、仕様を見える形でアウトプットしないプロジェクトの失敗を見た。
とりあえずアウトプットをするように働きかけてみたが、プロジェクトが燃えている最中からではもはや無理だったようだ。再スケジュールはできたのだけど、それによってできた時間がアウトプットに使われることがなかった。
フォローアップもやってみたが、まだ定着してきた兆しは見えない。
まさに、上の引用のままって感じ。
少しづつでも変わるといいな。