毒か薬か、どちらかになる（OOと開発効率について）

OOを使った方が効率的なのか、使わない方が効率的なのか。
これはRoRの話題と同じなんですよね。
適性とマッチしない場合、効率は劇的に低下してしまいます。

OOの適性は、これから開発するシステムの規模や取り扱う業務や機能の複雑さ、提供方法から運用工程、更にはあるかどうか分からない（が、殆どの場合ある）派生開発の時の保守性までを考慮しないと、何とも言えません。
また、大規模＝OOという事ではなく、あまりに巨大であれば並列稼動を意識してメンバーの最も低いスキルに合わせた方がかえって効率的、という事態もありえます。

このへんはOOというと必ず語られるデザインパターンも同じで、使う＝効率化かというと必ずしもそうではなかったりします。このへんの見極めを誤ると、冗長な実装や無駄に複雑な構成となりかえってひどい目にあったりします。

また、OOの適性にマッチした開発対象だったとしても、設計工程で内部仕様をある程度形作ってしまうOODを使うと、はたから見てとても非効率的に見えるかも知れません。
昔ながらの「おおざっぱにサブシステム分けして、画面のデザインを決めて、イベントごとの最低限の仕様を決めたらもう詳細設計、実装、試験」という開発プロセスと違い、やれプロトタイプだやれスパイラルだと一向にステータスが進んでいかない（または、戻る）からです。
こういう点も、OOの是非についての議論を生む要因の一つなんでしょう。

個人的には、OOは「毒か薬か、どちらかになる」んだと思います。

OOのメリットとデメリットを踏まえた上で、メリットの方が大きくなるような場合で、かつプロジェクトのメンバーもそれらを理解しているのであれば、OOはとても良い薬となるでしょう。そのプロジェクトは、実装か試験か分かりませんが、システムがリリースされるまでにそのメリットを享受することになると思います。

反面、使うべきではない局面でOOを使用した場合、特にOOを理解している人がいなかったりして、OOのメリットを適切に享受できない場合、構成や試験仕様が無意味に複雑化したり、実装で同じようなコードを何度も何度も書いたりと、プロジェクトに余計なコストを強い続けることになりそうです。

ひがさんがRoRについて危惧されているまんまのことが、既にOOにもあったんですね。