オブジェクト指向型のプログラム言語を使うと、オブジェクト指向のプログラミングが自然にできて、開発効率がアップする、というのは幻想で、オブジェクト指向的な考え方というか、ノウハウを利用することによってでしか、開発効率はアップしないとか、極論を書いてみるテスト。
研究的なプログラミングとか、ライトウェイトなプログラミングをしている場合は別として、いわゆる業務で使うアプリケーションのようなもの全般、いわゆる SIer が請け負うアプリケーションに関して云えば、オブジェクト指向一辺倒で行くのはプロジェクトの成功率的に云えば、危険である。プロジェクトの成功率というのは、以前書いた（と思うけど）、プロジェクトが赤字にならないことであって、その他の個々人のスキルとか将来性とか、更に云えば会社の将来性とかいうのとは別ので、目の前のプロジェクトを如何に完遂するのか？というのが焦点になる。
良いとか、悪いとかは別として、それが「プロジェクトの成功」と定義するワケ。
で、このプロジェクトの成功に関してどのようなプログラミング的な知識が適用／寄与できるかというと、一般的に言えば、オブジェクト指向であったり、プロトタイピングであったり、アジャイルであったり、諸々の手法であったりするわけだが、失敗する可能性を低くしたいのであれば（ローリスク、ローリターンという意味で）、既存の成功パターンに少しだけ他の成功パターンを加えるほうがいい。
全面的に変える必要がある場合は、
- この予算では、アプリケーションが完成できない、という見込み。
- このメンバでは、アプリケーションを完成させられない、という見込み。
- この期間では、アプリケーションを完成させらんれない、という見込み。
といった、局所的な最適化あるいは改善策では、到底達成さできない場合に入れ替えが必要になる。
さて、改善の積み重ね、あるいは地道な努力、という程度（という言い方も悪いかもしれないが）で済む話であるならば、全面的なオブジェクト指向の手法の取り入れは止めておいたほうがベター…というか、SIer にとっては、リスキーなパターンを取るよりも、安全策を取るほうが良いのだ。
が、何をすれば安全であるのかというと、２つのパターンがあって、
- 従来の設計書、プログラミング手法、試験手法を続ける。
- オブジェクト指向の手法を少しだけ取り入れて、設計、プログラミング、試験の手法を変えていく。
というものがある。「従来の」と書くと、旧態依然という感じがして最新技術を追う業界（これは疑問なのだけど）にとっては、ちょっと…と二の足を踏むかもしれないのだが、建築業界のようにゼネコンを目指すのであれば、より実績のある技術に負うところが多い、と言い換えてもよい。従来の技術であっても、10 年以上続けているのであれば（場合によっては、20 年以上前でもよい）それは、それで実行時に効率化されているであろうし、変えなくてもよい、と言い切れる。
が、従来通りの手法で作っていると、やはり間に合わなくなってくる部分があり…というか、最近の開発の傾向として、
- 昔よりも、不具合に関して、厳しくなくなっている。
- 昔よりも、運用時のバージョンアップが可能になっている。
という点を汲み入れると、
- ある程度、強固でなくても良い部分がある。
- ある程度、後に切り替えられる部分がある。
という結論になる。
建前上は、「完成品」が求められるものの、一般的な受託開発のソフトウェアは自動車や航空機ほど完成度を求められていない。となれば、求められてないところは、求められてないなりの「経済性」で開発をする、ということが暗に求めらているのである、と言い切る。
そこで、アプリケーションの中では、強固であることが必須な部分と、さほど強固でなくてよい部分があることがわかる。これをどのように分けるかは、いくつかの手法があるのだが、
- 強固な部分 → ライブラリ化（オブジェクト指向）
- 緩い部分 → 一般的な手続き的手法で、プログラミング
という分け方をする。よく「共通化」とか「共通基盤」とか言われるのが、ライブラリ化にあたり、このあたりは昔からベテランが対応することになっている。また、ベテランがプログラミングする故に品質がよく、落ちにくいという頑健さが求められる。
で、逆に言えば、この強固ではない部分
- GUI 部品を使った画面のプログラミング
- 共通ライブラリを使ったプログラミング
- コピー＆ペーストを繰り返すプログラミング
のようなところは、一般的なスキル（設計から試験も、ほどよくという「経済性」を保つ）で開発を行うという方法がある。
このあたり、MVC パターンと絡むところがあるのだが、設計から試験まで、2 つの視点を使いプロジェクトの「経済性」を保ちつつ、成功率を高めるという手法になる。
