書き物の不思議

Agile開発では、極端に書き物[*1]を減らす流派がある。書いても意味のない文書は不要、ということ。もちろん、全く書き物をしないわけではなく、必要なものなら書くし、必要なら保存もする。
という話をすると、某大手SI業者の人達[*2]は「設計書がないと開発ができない」と口を揃えて言う。

自分はむしろ「なんで設計書があれば開発できるのか?」が不思議でたまらない。IPA情報処理推進機構のサイトなど[*3][*4]を見る限りでは、要求定義→外部設計→内部設計→プログラム設計→コードと落ちていくらしい。つまり、徐々に細部を固めていくということらしいのだけど、

この地図「だけ」から

という衛星写真に持っていくことはできないのと同様に、外部設計「だけ」からはより詳細な設計を導くことはできない。

地図から衛星写真並の詳細な地形図を描くためには、「どこに木がある」「この建物の屋根はこんな色と形」のような詳細情報が必要。でも、これは「地球」という完成品があるから不可能ではない。

開発途上のソフトウェアの場合は完成品がない。なので設計書に書かれていない詳細な情報は...担当者がその知識範囲内で決めていくことになる。まあ、これではあまりにも怖いのでレビューにかけることになるわけだけど、レビューする人達は全知全能の神ではない[*5]から、やっぱり抜けや間違いが残ることになる。[*6] 上流での抜けや間違いというツケが、プロジェクト後半でどういう形でハネかえってくるかは、皆さんご存知のとおり。

設計書があれば、たしかに開発はできるかもしれない。でも、そこから出てくるモノは実はお客さんが欲しいモノとは別なもので、なおかつたくさんの不具合を含んだ代物である可能性が高い。まあ、その不具合を潰して出荷するから、高い金をお客さんから徴収できるんだけどね。

*1:なぜわざわざカタカナでドキュメントと記述するのか??

*2:ここはツッコむところではない

*3:その1

*4:その2

*5:むしろ、どーしようもないくらいしょーもない連中で、本質的ではないツッコミばっかりしてくるから、本質的ではないところに凝った資料を用意することに情熱を費してしまうという状況が多い??

*6:悪魔は細部に宿る、にはこういう理由があるわけ