第7回　オブジェクト指向は「正しい」のか？──科学技術としての考察

筆者よりプログラミングやソフトウェアエンジニアリングにずっと詳しい読者に対して、身の程知らずのそしりを免れないタイトルだが、この連載の開始にあたって「多角的な視点から」というのを強調したと思う。ひとつの考え方として捉えていただければ幸いだ。

オブジェクト指向の「波」

現役エンジニアの読者諸氏にしてみたら素人同然の私だが、これでもエンジニアとしてプログラミングや回路設計などでメシを食っていた時代もある。初めてのプログラムというものに接したのは本と雑誌で読んだBASICだった。実際に自分でプログラミングをしたのはアセンブラ（というかマシン語）が最初だ。SDK-85とかTK-80の時代だったので、BASICなんて「ASR-33」といったテレタイプ端末がないと使えなかったからだ。

就職してからは、ロジック回路などをやりながらFORTRAN、BASIC、C言語あたりを使っていた。COBOLの経験もあるが、オブジェクト指向言語との遭遇は、プロフィールにあるアスキーに転職したときだ。編集部に見慣れない端末（ワークステーションだった）が置いてあり、それがテクトロニクス製のSmallTalkマシンだと聞かされた。先輩編集者がSmallTalkの本を作るので、編集部で購入したそうだ。

そのときは、オブジェクト指向という概念は理解できなかったが、OS、もしくはハードウェアでガベージコレクションをしてやらないとまともに動かない処理系という印象が強く残っている。その後、Objective-CやC++などオブジェクト指向の「波」がやってくる。Eiffelなんて言語もあった。プログラミングの書籍でも、オブジェクト指向を解説しようとする本がやたらと出版された。私も「Little Small Talk」なんてPC向けの処理系の本の編集をやらせてもらったことがある。

初期のころは、クラス、メソッド、オブジェクト、継承などの概念を説明する本が流行ったと思う。「⁠リンゴ」「⁠みかん」などを集めたものが「くだものクラス」だ、動作（処理）と属性（変数）を単位として考えるプログラミング、などといったやつだ。なぜそれがうれしいかというと、モジュール化が進み、抽象度も高くなり、コードの再利用ができ、バグが減り、効率が上がり、ひいては「ソフトウェアクライシス」に対応できるからだとされた。

時代は「オブジェクト指向ありき」へ

その後、これらの意見の正しさを証明するかのように、プログラミングの手法が変わっていった。C++やVC++が普及し、Javaのブームがきた。解説書も、説教くさい「オブジェクト指向とは？」、といったスタイルの解説書から、プログラムっていうのはこういうものだというオブジェクト指向ありきの解説が主流となる。なまじ、手続き指向の知識を前提にオブジェクト指向を教えるより、プログラムはライブラリをインクルードしてメソッドを呼び出して、と教えるパターンだ。オブジェクト指向の抽象化やコードの再利用によって効率を上げようというのは、裏を返せば適切なスキルがなくてもプログラミングできるようにするという側面もある。最低限のアルゴリズムさえ理解できれば、言語仕様その他の細部を気にしないで済ませることができるからだ。

これを加速させたのはIDEだろう。できのよいIDEは、あたかもアプリケーションソフトを操作するようにプログラムを作り上げていく。「⁠ユーザ」はコーディングのスキルや知識がなくても、マウス操作ができれば「プログラマ」になれるわけだ。これはあまりに表層的な捉え方だという反論はあるだろう。どんな優秀なツールを使おうとも、本質的なアルゴリズムやロジックを理解できない人間にはまともなプログラミングはできないはずだ。それは全面的に正しい。しかし、その反面、正論や理屈はともかくスキルのない人間にコードを書かせる実態があるのも事実だ。

オブジェクト指向やその開発環境は、本来の抽象化や再利用の効果をもたらすとともに、プログラマのハードルも下げてくれた。これは、文系の学生にもプログラミングの楽しみを広げ、その人の能力を広げるという良い方向に働いてくれたが、同時にビジネス的側面からコストダウンと生産力アップのためにプログラマの頭数を集める方便とされる流れを止めることはできなかった。なぜなら、それが科学技術のあるべき姿（の一部）だからだ。

車輪は何度も発明するな。Perlの開発者で有名なラリー・ウォールが好んで使った言葉だ。科学技術のいいところは、一度発明されたもの開発されたものはだれでも簡単に使うことができ、その恩恵に授かることができることだ。同じ苦労をしないでその結果が得られるということは、過去に積み上げたものはブラックボックスとして細部を知らずとも同じように利用できるということだ。あたかもOOPのクラスライブラリのごとく。OOPによってプログラマになるための鍛錬や訓練が軽減されるなら、それを否定する合理的理由はない（東洋哲学ではそうではないのだが⁠）⁠。

かくして人類はOOPを手に入れた。これによりバグから解放されプログラマはより高度な問題に取り組むことができる……はずだった。もちろん現実はそれほど甘くはない。科学技術が人間を雑事や危険から解放し、より「人間らしい」世界を約束してれるという幻想は、歴史上でなんども打ち砕かれている。なにより、生き物というものは楽ができるなら、とことん楽をしようとする。楽した分、より生産性の高い活動をしようなんていう人間はごく少数といわざるを得ない。まあ、それほど話を大げさにしなくとも、パソコンやOAが騒がれたころにも同様な宣伝はあった。このシステムを導入すれば計算ミスや書類の山から解放されますよ。といった類のやつだ。かのFSFのフリーソフトウェア宣言にも、プログラムがフリーになれば人間はより創造的な活動に邁進できるという趣旨の文章があるくらいだ。

問われるのは「人間側の適応」

ここでやっと冒頭の疑問（仮説）にたどりつくのだが、オブジェクト指向はプログラマをむしろ退化させていないだろうか。あるいはその危険性はないのだろうか。メモリマップやデバイスのタイミングチャートを読めないプログラマは正しいのだろうか。見た目は高度なグラフィック演算やシミュレーション、複雑なプロトコル処理やデバイスを簡単に使いこなしているが、本当にそうだろうか。プログラミングの現場では、「⁠へたに人間がコーディングするからバグが出るんだ。」ということさえ言われる。先ほどの車輪の発明の比喩の発展系だが、「⁠自分でコードを書くな。動いてるものを使え。」という言い方もある。もちろん限定的な文脈でのことだが、このような本末転倒ともいえなくもない状況は、我々が目指した道なのだろうか、と思うことがある。

もう少し即物的な話にすれば、エンジニアやプログラマがバグや生産性の悪さに苦しみながらも、それが特殊技能であった時代は、給料や待遇でのメリットがあった。しかし、バグや生産性の問題を解決しようとした結果、プログラムをだれでもできるレベルに引き下げてしまい、自らの地位と経済的価値を下げる結果になっていないだろうか。理系離れやかつての花形職業を3K労働の代名詞のようにしてしまったのは、ほかならぬ我々自身だったのかもしれない。

確かにOOPやすべてのテクノロジーは人間の表面的能力を増幅させるが、その本質部分を変化させることはできない。結局、OOPもバグをなくしてはいないし、ソフトウェアクライシスを救ってもいない。これがOOPの問題なのか適用方法に問題があるのかは不明だが、もし、OOPでプログラマがダメになったり価値が下がるとしたら、それはむしろ本人（人間）の問題というべきだろう。とすると、せいぜいいえることは、OOPでプログラマという属性全体の価値や存在意義が下がるとしたら、そういう資質の人間を大量にプログラマにしたからに他ならない。OOPで楽をできるからといって、無条件に対象を広げるのではなく事前の教育やスキルが重要である。ということくらいだろう。

技術とは、その使い方や適用のしかたによって結果が変わるだけだ。成果に対して評価は可能だが、その評価だって絶対的なものではない。時代とともに変わるものだ。しかもその基準が、評価対象の技術の存在によって影響を受けることさえある。アジャイルやエクストリーム開発あたりがいい例だろう。前回のコラムでも述べたが、科学技術そのものに正しいとか間違いという概念はなじまない。使わなくなった器官や能力が「退化」していくのも、正常な「進化」の過程であるはずだ。その進化が、環境の変化にどう対応できるかで、その「種」が生き延びるのか滅びるのかが決まる。たぶんそれだけのことなのだろう。