なぜオブジェクト指向方法論に代わる方法論が出ないのか

1990年代にオブジェクト指向分析・設計の方法論がめちゃ流行ったことがあります。 ただ、そのブームが終わって、後続となるような方法論が流行ることはありませんでした。

で、なぜなのか考えていたのですけど、オブジェクト指向方法論のウリは分析段階で出てきたオブジェクト(といいつつクラス)がコードにそのまま引き継がれるというものでした。ようするにオブジェクト指向方法論というのはコードのスケッチを書いて詳細化していくというものだったのです。
しかしながらこれは、スケッチとして書いた分析・設計が間違っていればコードも間違うわけで、強くウォーターフォールの性質をもつものでした。
結局のところスケッチの妥当性というのはコードを書かないと検証ができません。分析・設計段階で見出されたクラスが妥当かというのは、コード書かなければわからなかったのです。逆に、コードを書けば妥当かどうかわかります。であれば、最初からコードを書く方が楽です。

また、この考え方は、ソフトウェアを適用する環境は変わらないという暗黙の前提をもっていました。実際にはソフトウェアを開発して導入すると、導入した先の環境もかわります。そこでソフトウェアに求められる要求は変化します。
そうであれば、最初にソフトウェア導入前の環境を観察して分析設計を確定させてもあまり意味がなく、ソフトウェアを導入して変化した環境にあわせてソフトウェアも変化させる必要が出ます。
そこで1999年にエクストリームプログラミングの考え方がでて、アジャイルへとつながっていきます。

オブジェクト指向方法論のひとつであるヤコブソンのOOSEでは、ユースケース分析としてソフトウェアを適用する環境を観察するという過程をもっていました。
アジャイルの流れもあり、分析・設計する対象は作成するソフトウェアではなく、そのソフトウェアを適用する環境であるという考えが広まっていきます。そしてドメイン駆動設計として成熟することになります。

そういうこともあって、オブジェクト指向というときオブジェクト指向分析・設計のことが話題になることはなくなり、オブジェクト指向プログラミングの話だけが残っています。

かくして、分析・設計する対象はソフトウェアではなくソフトウェアの環境であり、工夫する対象はソフトウェアをどう作ってどう配備してどう運用するかというプロセスであり、コードに関してはあらかじめスケッチするのではなく方針や原則を決めプラクティスを実践する、ということに落ち着いたのではないかと思います。
つまり、DDD、アジャイル、継続的インテグレーション、SREという感じになったわけですね。これらは実装パラダイムには依存しないので、プログラマは自分たちに適した技術を採用できます。

Web世代が知らないエンタープライズシステム設計

エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)

はじめよう! 要件定義 ~ビギナーからベテランまで

Clean Agile 基本に立ち戻れ

SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム