疑問2 オブジェクト指向技術は難しい？
筆者の考えはこうです。
「オブジェクト指向が難しいというのはぬれぎぬだ！」
確かにオブジェクト指向には，覚えることがたくさんあります。クラス，カプセル化，継承，ポリモーフィズム，クラスライブラリ，フレームワーク，デザイン・パターン…など，わかりづらい言葉ばかりです。また「ものごとを抽象化する考え方が重要」などとも言われます。こんなことを聞くと，日常のプログラミング作業で忙しい人は，ますます煙たく感じるかもしれません。
しかし，そんなに難しい技術なら，どうしてオブジェクト指向は消えてなくならないのでしょう？ この技術が登場してからすでに30年以上も経つそうですが（注10），消えてなくなるどころか，時間が経つにつれどんどん発展し普及してきています。それは疑問1で紹介した通りです。これは一体どういうことなのでしょう？
そ う，真犯人は別にいるのです。その犯人とは，「ソフトウエア開発」そのものだと筆者は確信しています（図2）。
（図2）
筆者もかれこれ15年以上，ソフトウエア開発の仕事をしてきました（年がバレますね）が，現在に至っても，つくづくこの仕事は難しいと感じます。そもそも作るものが直接目に見えるわけではありませんから，ユーザーの要求をきちんと理解するのは容易ではありません。しかもほとんどの場合，納期や予算はあらかじめ決まっています。さらに，進歩したとはいえコンピュータの能力は無限ではありませんから，パフォーマンスも気にしなければなりません。そんな状態ですから，バグの一つや二つは当たり前ですし，納期遅れや予算オーバーもしょっちゅうです。プロジェクトが途中でキャンセルされてしまうことさえ珍しくありません。それにもかかわらず，ユーザーの要求はどんどんエスカレートしています。システムはどんどん複雑でかつ大規模になりますが，納期は短く費用は安く…とあれもこれもが要求されます（注11）。
このような状況のなかでオブジェクト指向技術が消えるどころか普及しているのは，オブジェクト指向が「難しいソフトウエアを少しでも楽に開発するためのノウハウ集」だからです。オブジェクト指向技術の中には，部品化しやすいプログラム言語や，設計の定石集，それに再利用可能なソフトウエア部品などが含まれます。これらはどれも，過去の経験から得られた貴重なノウハウです。言わば「システム開発の虎の巻」と言ってもよいでしょう。たくさんの用語がはんらんしているのは，それだけ対象とする範囲が広いことの証拠でもあります。オブジェクト指向が難しい（と感じる）のは，それが対象とするソフトウエア開発自体が難しいことの表れなのです。「簡単にする」という志は高いものの，残念ながらまだ発展途上といったところでしょうか。
また，オブジェクト指向が抽象的というのも考えてみれば当たり前のことです。なぜならば，ソフトウエア自体が，目に見えない抽象物なのですから。
疑問3 オブジェクト指向は従来の開発とどう違う？
これはちょっと答えにくい質問です。「従来のやり方」をどう考えているかにもよりますが，あえて言うなら
「本質的な違いはない。開発の目標が増えただけ」 と筆者は考えています。
一般的によく言われるのは，以下のようなアプローチの違いです。
・従来は，システム全体の機能を徐々に分割していくトップダウン・アプローチだったが，オブジェクト指向では小さな部品を作りながら全体を組み上げていくボトムアップ・アプローチである
・従来の手法では「機能中心」だったが，オブジェクト指向では「もの（＝オブジェクト）中心」である
この説明は，当たっている点もありますが，筆者には今ひとつしっくりしません。なぜなら，従来のやり方でも共通サブルーチンを見つけるボトムアップの視点が必要でしたし，反対にオブジェクト指向でも，外部仕様をきちんと確認したり，全体をサブシステムに分割したりするトップダウンの視点は重要だからです。したがって，こうしたアプローチの違いでは両者の違いをうまく説明できません。
違いをあえて一言で言うならば，それが目指す目標ではないでしょうか。つまり従来の手法は，要求された機能を実現して「きちんと動くソフトウエアを作ること」が最大の目的でした。しかしオブジェクト指向開発では，さらに「保守性と再利用性を向上させること」という目標が追加されています。ここで重要なことは目標が「変わった」のではなく，「追加された」という点です。オブジェクト指向であっても従来からの優れた技術はそのまま生き残っており，消えてなくなったわけではありません。このため，CやCOBOLを使っていたときでも保守性や再利用性を向上させようと何らかの工夫してきた人にとっては，オブジェクト指向は受け入れやすいはずです。なぜならオブジェクト指向技術は，過去に同じような人たちが工夫してきたノウハウだからです。反対に保守や再利用性をあまり考えず，要求された機能通りに動けばよいと考えてきた人にとっては，オブジェクト指向は大きなギャップを感じることでしょう。「オブジェクト指向の習得には発想の転換が必要だ」などと言われることがありますが，転換すべき発想は案外こんなところにあるのかもしれません（図3）。
（図3）
疑問4 オブジェクト指向技術を採用すれば， 開発の生産性は向上する？
「もちろんイエス！」
でしょう。今や生産性を向上させるためには，オブジェクト指向は必要不可欠な技術です。反対に生産性を上げようと何らかの工夫をすると，自然とオブジェクト指向になるはずです。
しかし「じゃあ，一体どれくらい向上するのですか？」と聞かれると，根が真面目な筆者としては少々答えに詰まってしまいます。こういうときにあまり深く考えずに「5倍ぐらいですね！」などと胸を張って言える性格だったら，もっと気楽な人生を送れたかもしれません。
これまで筆者はシステム開発をするたびに，プログラムの規模と，それに要した費用や作業量などを調べてきました。
しかしそれでも，オブジェクト指向でどれくらい生産性が良くなるかはわからない，というのが正直なところです。
理由の一つは，オブジェクト指向技術があまりに多岐にわたっていることです。いったい何をどこまで採用したらオブジェクト指向をやったと言えるのか，実際のところよくわからないのです。また二つ目の理由としては，技術以外の要素が生産性に大きく影響することです。これは担当者のスキルや経験であったり，リーダーの管理能力だったりします。また個人のやる気やチームワークの良さなども無視できません。したがって残念ながら筆者には，オブジェクト指向でどれくらい生産性が良くなるのかはわかりません。それでも，もしオブジェクト指向技術を使わなかったら，開発生産性がかなり落ちたであろう，ということは断言できます。
生産性についてはもう一つ付け加えておくべき重要なことがあります。それは漫然と個々の技術を使っただけでは，けっして効果は出ない，ということです。先ほど生産性を上げるためにはオブジェクト指向は不可欠だと述べましたが，実はこの反対は必ずしも成り立ちません。つまりオブジェクト指向技術を見よう見まねで使っただけでは，生産性は上がらない，ということです。しょせんオブジェクト指向は道具（ツール）なのだ，と割り切るべきでしょう。使う人がその道具をどういう目的で，どういう場面で使うかによって，結果は大きく変わってしまうわけです。この点について，オブジェクト指向関連に詳しいソフトウエア・デザイナ兼ライターの，επιστημη（えぴすてーめー）氏による名言があります（注12）。
――オブジェクト指向を使えば生産性が上がると思ってるおかたが少なからずいらっしゃるようですが，それはとんでもないマチガイです。「オブジェクト指向を使えば生産性が上がる」のではありません。「オブジェクト指向を使って生産性を上げる」のです。
疑問5 オブジェクト指向技術を採用するとソフトウエアの実行性能（パフォーマンス）が悪くなるって本当？
これもなかなか微妙な質問です。あえて一言で言うならば，
「パフォーマンスは若干悪くなるが，ハードウエアが進歩した現在ではほとんど気にする必要がない」 といったところでしょうか。
オブジェクト指向は，主に保守や再利用をしやすくするための技術ですから，パフォーマンスの良しあしとは，直接関係がありません。しかし「二兎を追うものは一兎をも得ず」のたとえ通り，保守性や再利用性と，パフォーマンスの間にはある程度のトレードオフがあります。
具体的な例を挙げましょう。一般的に，オブジェクト指向言語で書かれたアプリケーションでは，実行時に必要なメモリーを確保したり，関数テーブルを介して関数を呼び出したり，といった動作が多くなります。したがって，そうでない場合に比べると，パフォーマンスはその分だけ悪くなります。しかし10年前，20年前ならいざ知らず，ハードウエアが進歩した現在では，この程度の問題はほとんど気にする必要はないでしょう。
ビジネス・アプリケーションならば，パフォーマンスの考慮として，次のことぐらいに気をつけておけば，一般的には十分と考えられます。
・データベースの構造やアクセス方法が適切か？
・スレッドやプロセス，データベースのコネクション，といったシステム資源の使い方は適切か？
・何万回，何十万回もループするようなロジックの中に無駄なコードが書かれていないか？
実際にパフォーマンス上の問題が起きた場合でも，上記に該当するような一部のコードを修正するだけで，全体のパフォーマンスは劇的に改善するものです。その他の部分についてのパフォーマンス改善は多くの場合，全体から見れば小さなものですから，それよりも保守性や再利用性の向上を優先させるべきでしょう。
さて，いろいろと述べてきましたが，ここでもう一度，冒頭の「オブジェクト指向って一体なんですか？」という質問について，考えてみましょう。筆者ならこう答えます。
「オブジェクト指向とは，品質が高く，理解が容易で，保守しやすいソフトウエアを開発するための技術やノウハウの総称である」
こう考えると，プログラム言語，分析/設計手法，プロジェクト管理手法，デザイン・パターン，クラスライブラリ，UML，CORBAなど多くの技術が「オブジェクト指向」という枠組みの中に入っていることの説明がつくのではないでしょうか。
オブジェクト指向は，最初はプログラミング言語からスタートしました。その後さまざまなアイデアや仕組みがつけ加えられてどんどん発展し，今日のような広がりを見せました。今後もしばらくは，オブジェクト指向を軸にソフトウエアの開発技術は発展していくでしょう。したがってソフトウエア開発をずっと続けていこうと考えている人にとっては，欠かすことのできない技術と言えるでしょう。
では，この技術をどうやって勉強すればよいでしょうか？ 「この連載を読み続けてください」というのは冗談として，まずはプログラミングをきちんと理解しておくことが重要です。実際にJavaなどを使ってコードを書き，デバッガを使って動かしながら，クラス，継承，ポリモーフィズムなどの仕組みを体感するのが一番手っ取り早い方法です。そのうえで，UML，デザイン・パターン，分析/設計手法と進んでいくのがおすすめのコースでしょう（図4）。実際，この連載もこの順序に沿って進めていく予定です。
（図4）
とはいえ，“形”から入ることも重要ですが，やっぱり最後は皆さんの“意志”です。それは，問題意識を持って，生産性や保守性，あるいは再利用性を向上させようとする意志であり，そのために工夫をすることだと思います。そういう人にとっては，オブジェクト指向が提供するさまざまなノウハウや仕組みがまさに宝の山となるでしょう。反対にそうした意識をあまりせずにソフトウエアを書いてきた人にとっては，オブジェクト指向は，わかりづらく使いづらいただのガラクタ箱に見えることでしょう（図5）。 ☆☆☆
（図5）
いかがだったでしょうか？ 次回は，オブジェクト指向にまつわる用語を整理する予定です。より具体的にオブジェクト指向の全体像がつかめると思います。
ご意見，ご要望のある方は，info@ulsystems.co.jpまで，ぜひメールをお送りください。
（注10）1967年に北欧で開発されたSimula（シミュラ）という言語がはじめてのオブジェクト指向言語だそうです。
（注11）こうしたユーザーには，パソコンや携帯電話を使って，少しでも便利な生活をしたいと考えている私たち（開発者）自身も含まれています。
（注12）「επιστημηのオブジェクト指向的日常」επιστημη（えぴすてーめー）著，翔泳社，の30ページより引用。