実装から独立した設計?

http://watanabek.cocolog-nifty.com/blog/2005/08/post_d453.html

「実装独立であるかどうか」で「設計」を前後に区分して実践した場合、「前半の成果物」にもとづいて、任意の実装環境で「後半の成果物」を作成できるはずである。

そうすると,前半分には何も残らない.
設計のほぼ100%を占める後半の成果物で後半の成果物を作成することになる.おや?*1

「前半の成果物」が示す内容を、COBOLでもCでも.NETでもJavaでも実装できるということになる。

ここで実装を知らない「設計者」の限界が露呈する.言語が変われば設計方法もコーディングスタイルも一変する.「理論上実装できる」というのは嘘ではないが,それが「実現するのがおよそ現実的ではない」と同義であることが少なくない.*2

まあ、原理的にはそうなのだが、「前半」において実装環境がおおまかにも決まっていないことがまずあり得ないため、

まあ原理的にはそうなのだが,「前半」においておおまかにしか決まっていなかった実装環境が,後半においてガラリと変化することもある*3.もっと怖いことに実運用が始まってから問題が発覚したり,ビジネスの環境が激変したりして実装環境を変更しなければならなくなることもある.*4
それに対処するための実装から可能な限り切り離された柔軟な設計/実装というのは,昔からのソフトウエア開発のテーマの一つだ.*5だがそれをもたらすのは上流行程でもモデリングでもない.


捕捉しておくが,私は何も業務プロセスの分析や改革までも否定するつもりはない.それはそれで価値のあるものだ.だがそれは情報システムの開発ではないし,実装と独立した設計というものでもない.

*1:再利用性や実装からの独立性を,『上流行程』でなんとかしようとする試みが常に失敗する原因はこのあたりにある.いいかげん上流行程に対する幻想は捨てて欲しいものだ.

*2:というより,これは「実装独立」という単語からイメージされるものではないなあ.設計者にとって「環境」とは開発言語のことなのか?

*3:「こともある」どころか,人によってはそれくらい日常茶飯事かもしれない.

*4:さらには機能追加を含む保守行程においては,実装を無視しては何も始まらない.実装を無視できるのは既存システムを破壊して一から創り直す時くらいだが,保守や『実装独立』の観点からはこれはあまり好ましい選択ではない.時としてこれは設計者の敗北を意味する.
そもそも「実装独立の設計」の価値とは一体なんだろうか?「実装独立」は無料ではない.それを実現するには相当なコスト増が見込まれる.しかもそれがメリットをもたらす可能性があるのは,現システムがどうしようもない失敗作で,それを完全に廃棄して一から作り直す時だけだ.最初から失敗作を作る予定の元に失敗に対する多額の保険金(だけ)を積み立てておくことが,はたして健全なシステム構築と言えるだろうか?

*5:月並みなセリフなのであまり言いたくはないが,現時点におけるその究極の成果の一つがJavaというわけだ.もちろんこれは『上流行程』の産物ではない.