実装から独立した設計？(その2)
http://watanabek.cocolog-nifty.com/blog/2005/08/post_040b.html
なぜなら、作成されたものがほんとうに「実装独立」であるかどうかを検証する方法がないからだ。
検証する必要はない．真の意味で「実装独立な設計」などはまずあり得ない．よって検証するまでもなく，常に「実装独立でない」と判定しておけばほぼ１００％あたる．ほとんどサハラ砂漠の天気予報．「明日は晴れです」と予報を出しておけばほとんど１００％当たる．当たって当然なので自慢にもならない．
だいたい、実装までを担当することがすでに決まっているのであれば、ベンダーはプログラミングやテストのしやすさだけを主眼にした設計文書だけを残そうとするだろう。
だいたい実装まで担当することが既に決まっていないのであれば，設計者はプログラミングやテストのし易さを度外視した設計文書を作ろうとするだろう．実装で苦労するのも，設計ミスによるシステム構築失敗の責任をとらされるのも赤の他人だからだ．*1
しかもこれは顧客にとっても災難だ．プログラミング困難でテスト不可能な設計とは失敗作とほぼ同義．そのような設計は実装も不可能ならばテストもできない．実装段階でコストが一桁増えたり，実現不可能で振り出しに戻ったり，それが原因で納期遅れまで発生する*2．またデバッグはおろか，基本動作の確認さえも満足にできないので実運用に入ってからもシステムトラブルが頻発する*3．これが果たして顧客の望んでいるまともな設計と言えるだろうか？
ベンダーにとっては当座の案件のシステムを稼動させることが最重要で、将来の実装技術の変化にともなうシステム刷新のしやすさなんて二の次三の次だからだ。
それが良いことだとは思わない*4．
しかし「設計者」にとってはそれ以前の段階で，将来のシステム更新はおろか，当座のシステムを稼働させることさえ眼中にない．目的はいかに多くの設計書を書き，そしてどれだけの利益が得られるかだろう．実装さえも担当しない「設計者」がいれば，当然そうなる．
*1:そもそもテスト容易性を無視した設計など，既にまともとは言えない．http://capsctrl.que.jp/kdmsnr/wiki/bliki/?Detestable
実装もテストも度外視した設計書などまさに絵に描いた餅．そんなもの食ったら腹壊すぞ．
*3:たとえば，テストすべきパス／項目が千通りあり，これに対し5千個のテストをするのと，テストすべきパスが百万通りあり，これに対して1万個のテストをするのと，どちらがまともだろうか．ましてテストすべきパスが，時には一億にも一兆にもできるのがソフトウエアである．何も考えずに作れば一兆通りになる組み合わせを，いかにして一万通りに押さえるかというのが，ソフトウエア設計の最大の課題の一つだ．逆に普通に作れば一兆通りになる組み合わせを、1千兆通りにも，時にはそれ以上にもするのが無能な設計者のもたらす損害の一つだ．
*4:こうなる理由の一つは契約にもある．長期のサポート料金込みの契約ならば保守性や，柔軟性の高い設計／実装も考慮するだろう．しかし保守も将来のシステム変更も他社が，時にはライバル会社が行うというのであれば，一体だれが支払われる料金以上の仕事をしようとするだろうか？しかもこの問題はベンダー内部においてすら存在する．新規開発と保守で担当者が異なる場合に，新規開発担当者が保守性に対してどれだけ努力するだろうか？技術力が高く，且つ良心的な人ならば努力してくれるかもしれないが，それはあまりにも悲しい，非現実的な希望だ．
