補足

前回への補足です。
というか、反省と改訂。

OOの適性は、これから開発するシステムの規模や取り扱う業務や機能の複雑さ、提供方法から運用工程、更には（ｒｙ

ここで取り上げたOOはもっぱらOODを指しています。でも「現場でのOO」を強調したいので、あえてOO率を高めてみました。しばらくこの方針を続けてみようかな、と思います。

昔ながらの「おおざっぱにサブシステム分けして、画面のデザインを決めて、イベントごとの最低限の仕様を決めたらもう詳細設計、実装、試験」という開発プロセスと違い、やれプロトタイプだやれスパイラルだと一向にステータスが進んでいかない（または、戻る）からです。

ただ、開発プロセスを混ぜ込んでしまったのには反省です。スパイラルもプロトタイプも、OOには直接関係ありませんでした。既存の開発方法（と一般的に呼ばれているもの）との差分を考えた場合、OOの弱点となるのはいくつかあることを超いい加減に書いてしまいました。

反省ついでにちょっと仕切り直しまて、OOにのみスコープを絞ってみます。