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

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

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

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

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

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

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

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