思考を廻しておくために、ちょっと続きを
オブジェクト指向設計とプロジェクトの成功とは無関係なのか？ | Moonmile Solutions Blog
http://www.moonmile.net/blog/archives/2527
「○○設計」や「○○手法」を使う場合、因果関係は薄いよからスタートすると、「じゃあ、何を使えば成功率は高くなるのか？」ってな話になります。まぁ、直接的な利益追求の話でいえば、直近のプロジェクトが云々ということになり、では先行きの学習のほうは？ということなりますが、まぁ、直近のプロジェクトを優先してみるという仮定で。
明確な形になっているかどうかは別として、要求定義→設計→実装→試験な、感じでソフトウェア開発工程が流れていくのは確かなことで、これがサイクル的に極めて早いか（アジャイル的に）、遅いか（ウォーターフォール的に）の違いはあるものの、程よく分けておくと議論がしやすくなります。無勝手流の場合は別として。
その中で、設計をする会社・人と実装をする会社・人が別のことが多い訳で、Web系以外はなんとなくわかれているのですね、これが。この分け方の理由としては、
- 新人だから、設計できないので、実装から始める。
- 外注だから、お客と話せないので、実装からスタートする。
- 金銭上の関係で、実装となる。
- 業務理解に乏しいので、実装側となる。
というような「設計」はできないけど「実装」はできる、という現実があります。
そんな場合、設計も実装も混在した形でアジャイル式に設計そして実装をやると、混乱が生まれる、と言いますか先に書いた記事のようにマイナス要因が多くなるので却下します。
できることならば、「設計」から「実装」への向きが変わらないほうが、スムースでマイナス要因が少ないわけです。
となれば、一方向になるように設計をする（画面設計も含めて）をするのがベターな話で、思考錯誤的にオブジェクト指向設計に落とし込んだり、便利機能を盛り込んであれこれとライブラリ化したものを組み合わせてしまうよりも、そりゃあ、データベースの構造をきっちりと作りこんだ後に、CRUD に従ってデータベースアクセスをきっちりする画面、関数構造を作っていけば、おおむね一応方向になります…ってのが、私の考えです。
「おおむね」と言うのは、関数として CRUD を揃えることは可能なのですが、あれこれと便利画面を用意するとこのあたり破綻します。あれこれできる GUI 画面は一見お客に便利なように見えますが、その分、実装側に負担が大きくなるために、この「一方向」の流れが崩されてしまいます。一方向の流れが崩れると例外が発生するので、要件→設計→実装の流れに齟齬が生まれはじめ、混沌としたやり取りが発生します。そこから、不具合なり見落としがでてきて、工数に時間が掛かったり試験による品質が悪くなったりしてしまいます。
なので、先の記事のようにマイナス要因を排除するという方針に従うと、あれとして便利画面を「入れません」ってのがデータ指向による設計の基本です。決まりきった方法でしかアクセスしないという方針を、ユーザーが使う画面に押し付けるという流れですね。
いや、そりゃちょっと昨今のソフトウェアでそれはないでしょ、ってことになるので、全部をデータ指向で突き進む訳にもいかないのです。
ならば、部分的にオブジェクト指向を導入してもよいですね、ってのが最近の結論です。全体的にオブジェクト指向の設計を入れたほうが隠蔽化とか汎用性とかが良いのですが、汎用性についてはデータ指向も負けていないわけで、コーディングの手順（手続き）や画面操作は多くなるものの正確にできるという点では、プログラミング（あるいは設計時）の能力に依存しないのです（実行時のパフォーマンス云々はちょっと問題ありかもしれませんが）。
あくまで部分的に最適なものを適用する。勿論、部分的な適用であるから最適化には限界があります。すぐに、天井があって、コーディング速度や開発効率などの上限にぶつかります。このあたりが、直近のプロジェクトの利益率を最大化する、という仮定の上にある話で、この「直近の」を外さない限り、このあたりの話は堂々巡りになってしまうのかなと。逆に「直近の」を外した場合はどうなるかというと、単一プロジェクトから複数プロジェクトの話になるので、もう少し選択肢が広がります、ってな話です。
