AIは最高級言語になれるのか? -「動いている挙動が正義」から始める設計論- ④

※本記事は、筆者の考えをもとに、生成AI(ChatGPT)と対話しながら構成・文章化したものです

オブジェクト指向は「実装」で誤解された設計思想


はじめに ― この章は寄り道であり、原点でもある

この章は、少し寄り道の話になる。
新しい言語の話でも、AIの機能紹介でもない。

それでも、この寄り道を書かずにはいられなかった。

なぜなら私は長い間、
「オブジェクト指向が分からなかった自分」
というわだかまりを抱え続けてきたからだ。

そして今振り返ると、それは理解力の問題ではなく、
設計思想が“評価不能な条件”で実装されていた
という話だったのだと、ようやく言葉にできるようになった。


なぜオブジェクト指向は理想的に見えたのか

オブジェクト指向について調べると、
よくこんな説明に出会う。

ベテランプログラマーでなくても
普通のプログラマーが協調して開発できる思想

これは、とても魅力的に見えた。

属人化を避け、
人海戦術でも破綻しにくく、
大規模開発に向く。

まさに「設計思想」と呼ぶにふさわしい理想だった。


だが、現場では扱えなかった

私が参加したのは組み込み系のプロジェクトだった。
そこで直面した現実は、教科書とはまるで違っていた。

  • 仕様書は長年メンテされていない
  • テストは自動化されておらず、単体検証も弱い
  • 「動いているコード」だけが真実
  • そして何より
    分かっている人が、もういなかった

この状態でオブジェクト指向を導入するというのは、
想像以上に難しかった。


実は、地獄はオブジェクト指向以前に始まっていた

今だから冷静に言えるが、
当時のプロジェクトでは次のことが同時に行われていた。

  • ハード変更に伴う大規模リファクタリング
  • 複数機種に分かれていた機能の統合
  • 値(状態)の構造体化
  • オブジェクト指向化の試行
  • バージョン管理システムの変更
  • バグチケット管理システムの導入

つまり、

コードの構造、仕様、状態表現、設計思想、
開発プロセスそのものを一気に入れ替えていた

しかも私は外注として参加しており、
設計や進め方を止める権限はなかった。

今思えば、
どんな設計思想であっても評価できる条件ではなかった


それでも唯一の救いはあった

救いは一つだけあった。

総合テストが存在していたことだ。

細かい仕様は曖昧でも、
「最終的に何ができていれば正しいか」だけは
挙動として定義されていた。

だから私はそこで初めて、

正しさとは、
理屈ではなく
最終的に動いている挙動なのだ

という感覚を、身体で理解した。


一番わからなかったのが「オブジェクト化」だった

そして多分、一番勉強したのもオブジェクト指向だった。

私はそのプロジェクトで結局、

  • クラスや継承、多態性を使わず
  • 「機能(責務)の分離」だけに落とし込むしか出来なかったからだ

それは現実的で、安全で、
プロジェクトを壊さない選択だった。

だが同時に、

「本当は、もっとちゃんと理解して使いたかった」

という未練も残った。

オブジェクト指向の「思想」と「実装」は別物だった

ここで一度、言葉を正確に分けておきたい。

オブジェクト指向が本来解決しようとしていたのは、
クラスを書くことでも、継承を使うことでもない。

本来の目的は、次の一点に集約される。

変更を、局所に閉じ込めること

  • 変更の影響範囲を限定する
  • 分業しても壊れにくくする
  • 全体を理解していなくても手を入れられるようにする

これは「設計思想」であり、
特定の構文や言語機能に依存しない考え方だ。

しかし実装の現場では、
オブジェクト指向は次のように理解されていった。

  • クラスを作ること
  • 継承関係を設計すること
  • 抽象クラスを用意すること
  • デザインパターンを適用すること

これらは本来 手段 にすぎない。
だがいつの間にか、目的の代わりになってしまった。

その結果、

「なぜそのクラスが存在するのか」
「何の変更から守りたいのか」

が説明されないまま、
形だけのオブジェクト指向が増えていった。

私はオブジェクト指向が分からなかったのではない。
オブジェクト指向が、
“実装の作法”としてしか語られなかった

ことに戸惑っていただけだったのだ。


だが今なら分かる

今なら、はっきり言える。

私はオブジェクト指向に敗北したのではない。
オブジェクト指向を、
成立しない条件で実装しようとしていただけだ。

オブジェクト指向が本当に力を発揮するには、

  • 仕様が共有されている
  • 境界が明確である
  • 間違いがすぐ検出できる(テストがある)

これらが前提になる。

当時は、その前提がなかった。


「理解できなくても正しく作れる思想」を探し始めた理由

この経験から、私はこう考えるようになった。

もし設計思想が
「分かっている人がいること」を前提にしているなら、
それは現実の開発では弱すぎるのではないか。

理解できなくても、
誤解しても、
それでも破綻しない仕組み。

人を信頼しすぎない設計思想こそが、
本当に強いのではないか。


そして、今いる場所

今、私は GitHub を使い、
仕様をテストに寄せ、
「挙動」を証拠として残す開発をしている。

当時は存在しなかった道具もある。
だが何より違うのは、

正しさを、人ではなく仕組みに委ねようとしていること

だ。


おわりに ― この章の位置づけ

この章は、
オブジェクト指向を否定するためのものではない。

むしろ逆だ。

オブジェクト指向は間違っていなかった。
ただ「実装」の段階で誤解されてきただけだ。

そしてこの違和感こそが、
私が「最高級言語」を探し始めた原点だった。


コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です