変わりつつあるソフトウェア開発の価値観 - 3

シームレスであることから時間軸を見渡すことへ

はじめに

多くの技術者が、「オブジェクト指向は難解である」と感じています。 オブジェクト指向という考え方は、簡単に言ってしまえば「システム開発を楽にする」ために生まれてきたはずです。 にも関わらず、難解だと感じてしまうというのは、どういうわけなのでしょうか？ 多くの人に尋ねてみると、「オブジェクト指向を採用するとどんなメリットがあるのか、今ひとつピンと来ない」という答えが返ってくるのです。 メリットがピンと来ない手法を無理矢理使って開発したとしても、いいものができるはずはありません。 これでは、本来手段とするはずの「オブジェクト指向」が目的となってしまっているのです。

なぜ「オブジェクト指向のメリット」がピンと来ないのでしょうか？ 筆者は、オブジェクト指向のメリットそのものが時代とともにシフトしてきているという点に原因があるのではないかと感じています。

オブジェクト指向の黎明期

このパラダイムの根幹をなす「オブジェクト」という概念の源流は、1960年代に作り出されたシミュレーション用プログラミング言語であるSimula I、Simula 67にまで遡ることができます。 この後、1970年代にはSimulaのオブジェクトを発展させる形で、Smalltalkというプログラミング言語が研究され、1980年のSmalltalk-80公開とともに、オブジェクト指向パラダイムの歴史が本格的に幕を開けることになったのです。

その当時に言われていたオブジェクト指向のメリットは、「現実世界をそのままの形でクラスにできる。 このため、実装が簡単になる上、属人性を排除できる」というものでした。 また、「差分プログラミング」と称して、「よく似た既存のクラスがあれば、それを継承し、違う部分だけを実装すれば再利用できる」という宣伝文句もそこかしこで見かけました。 さらに、こういった「現実世界をそのままの形でクラスに（モデル化）できる」というメリットに着目し、当初はプログラミング用として考え出されたパラダイムを上流工程に適用した、「オブジェクト指向設計手法」や「オブジェクト指向分析手法」が生み出されました。 これらによって開発工程をシームレスにつなぐことができ、システムの開発効率や品質を大幅に改善できると言われていたのです。

「シームレスな開発」というメリットは正しく機能したのか？

現実世界をそのまま写像できるという考え方は、オブジェクト指向というパラダイムが、シミュレーション用言語であるSimulaに触発されて生み出されたことと無関係ではありません。 しかし、現実世界を「そのまま」コンピュータ上に実装することなどできない相談なのです。 例えば、銀行の勘定系システムを開発するのに、素粒子クラスを作成し、それらを組み合わせることで電子や陽子、そして原子や分子を生成し、さらにそれらを組み合わせて顧客オブジェクトや元帳オブジェクトを作るような極端なことはしないはずです。 この時点で、「現実世界の抽象化」という作業が発生することになるのですが、この「抽象化」がくせ者となるのです。

現実世界のものごとにはさまざまな性質、特徴が存在しています。 そして、抽象化とはそういったものの一面だけを抜き出し、残りの面をすべて排除してしまう行為なのです（このことは「捨象」と呼ばれています）。 つまり、現実世界のものごとに10個の側面があった場合、抽象化によって9個の側面が捨てられてしまうわけです。 一度捨ててしまったものは、二度と戻ってはきません。 しかも、10個ある側面のうちの1つが必ず正解である保証もありません。 システムの内容によりけりで、側面によって一長一短があり、また、その評価基準も一定していないのです。 これでは、属人性の排除など無理な相談です。 また、さまざまなシステム間でクラスを再利用しようとした場合、すべてのシステムのことを考えた上で正しく抽象化しておかなければならないのです。 このため、「現実世界をそのままの形でクラスにできる」というメリットは、簡単なシミュレーション以外では正しく機能せず、「実装できない設計書」が世の中に溢れることになったのです。

オブジェクト指向パラダイム − そのメリットの転換期

1990年代にオブジェクト指向パラダイムの転換期が静かに訪れました。 そのきっかけをたどると、Smalltalkコミュニティに到達します。 彼らは「システムというものは完成しない」という重要な事実を常識として体得していたのです。 実際、ほとんどのシステムは本番稼働後も保守開発が続けられます。 つまり、システムというものは、捨てられる時が来るまでずっと変化し続けるのです。 これにはさまざまな理由があります。 本番稼働までこぎ着けたものの、その後で要求の間違いが判明することもあるでしょう。 予算の都合上、あきらめていた機能を別途追加することもあります。 また、正しくシステムを作成できたとしても、本番稼働後にシステムを取り巻く業務環境が変わり、それにシステムを追随させる必要が出てくることもあります。 さらに、最近では「開発しながら仕様を確定させるアプローチ」も増えてきています。 この場合、開発期間中にシステムの仕様が変わっていくことになるのです。

変化する部分と変化しない部分を分けて考えるという発想

要求の追加や変更が発生するたびに、システム全体を見直して影響する部分を探し出したり、テストの時点で既存機能に悪影響が発生していないことを確認しなければならない場合、莫大な保守コストがかかることになります。 こういったことは、何としてでも避けるべきでしょう。 つまり、将来変更が起こりそうな部分や、開発時点で詳細が見えていない部分を何らかの形で封印し、それらの詳細を意識することなしに使用できるようにしておけば、システム変更が発生しても影響範囲を局所化することができるのです。 このような戦略を採用した場合、追加要求が発生しても、新規クラスを作成し、そのクラスをシステムにプラグインするだけで、既存部分を丸ごと手つかずのまま残しておける、すなわち「再利用」できるようになるわけです。

こういった「システムの変化を特定部分に封じ込めることで、そこ以外の既存部分を再利用する」というメリットがクローズアップされるようになってきたのです。 この転換期の旗手となったのが、『オブジェクト指向における再利用のためのデザインパターン』という書籍（通称GoF本）です。 このタイトル中に含まれている「再利用」という言葉は、「汎用性のある部品を作り、他システムから使用できるようにする」ことではなく、「変化を封じ込め、開発済みの既存部分を手つかずのまま残す（＝自システム内で再利用する）」ということを意味しているのです。 つまり、要求中にある流動的要素を洗い出し、要求の変化する場所を特定した後、それらをオブジェクト指向の仕組みを用いて封じ込めることによって、変化に強いシステムを作成しようというわけです。 「時とともに変化する部分を見極める」という「時間軸を見渡した設計」により、システムの保守コストを大きく引き下げることが可能になるのです。

現在の状況

現在（2005年）のところ、オブジェクト指向のメリットをネット上で検索したり、識者に尋ねてみると、おおむね上記いずれかの答えが得られるはずです。 では、どちらのメリットを重視するべきなのでしょうか？

筆者の意見では前者（現実世界をそのままの形でモデル化する）には「それなり」のメリットこそあるものの、当初喧伝されていたほどの属人性排除効果や再利用性は期待できないと実感しています。 また、「現実世界をそのままの形で」という宣伝文句を真に受け、実装のことを考えない設計書が世の中に溢れかえったという事実を考えると、このメリットは害悪の方が大きかったのではないかとすら思えます。 このため、今後は後者（要求の共通部分と可変部分を見極め、可変部分を封印する）のメリットに比重を置いて開発を行っていくことが主流になるべきだと考えています。

いずれのメリットを重視するかはともかく、オブジェクト指向を学ぶ際には、こういった時代とともに移り変わりつつあるメリットが存在しているということを頭に入れておくと、オブジェクト指向にまつわるさまざまな「謎」が氷解するはずです。