はじめに
オブジェクト指向やポリモーフィズムを学ぶと、必ずと言っていいほど次のようなメリットが語られます。
「呼び出し側はインターフェースだけ知っていればいい。中身（実装）をいちいち気にする必要がない」
しかし、実際の開発現場で機能追加や不具合修正を行っていると、こう思いませんか？
「いや、結局めっちゃ中身気にするじゃん。ていうか、中身を見ないと怖くて修正できないんだけど？」
この「教科書通りの理想」と「現場のリアル」の間にある強烈な違和感。
「自分の技術力が低くて、本当のオブジェクト指向を体現できていないだけなのだろうか？」と悩んだ末にたどり着いた、ひとつの答えを書き残しておきます。
「中身を見ない」が成立しない現実
一般的なWebアプリケーションなどでは、以下のようなレイヤー構造（多層アーキテクチャ）を取ることが多いと思います。
- UI層（UI・コントローラー）
- Application層（ユースケース）
- Domain層（ビジネスロジック）
- Infrastructure層（DBや外部APIとの通信）
ここで「新しい機能を追加する」「新しいデータ項目を画面に出す」というタスクが発生したとします。多くの場合、1人の担当者がUI層からInfrastructure層まで、すべてを縦断して修正します。
この「縦断的な修正」を行う際、オブジェクト指向の「中身を隠蔽する」という性質は、恩恵どころか解析の邪魔になることがあります。
抽象化がもたらす「脳内ジャンプ」のコスト
ポリモーフィズムを駆使して抽象化されたコードは、見た目は非常にスッキリします。しかし、バグの調査や仕様変更のためにコードを読むとき、私たちは「実際に今動いている具象クラスはどれか？」を突き止める必要があります。
-
draw()を呼んでいるが、今画面に表示されない原因はどこか？ - インターフェースの定義へ飛ぶ。
- そのインターフェースを実装している具象クラスを検索する。
- 該当するクラスの実装（中身）をやっと確認する。
このように、抽象化のレイヤーを挟むことで**「コードを読む時の脳内ジャンプ（コンテキストスイッチ）」**が増大します。中身を見ないと挙動が保証できない現場において、このジャンプは単なる認知負荷でしかありません。
オブジェクト指向が「本来の力」を発揮する条件
では、ポリモーフィズムやオブジェクト指向は現場では無用の長物なのでしょうか？
そんなことはありません。ただ、それが真価を発揮するには**「前提となる開発体制」**が必要なのだと思います。
1. レイヤーごとに担当者が分かれている場合
もし、フロントエンド（UI）担当と、バックエンド（Infrastructure/Domain）担当が明確に分かれている大規模チームであれば、インターフェースは「担当者間の契約」として機能します。
「そっちの中身（SQLのチューニング等）はそっちでやって。こっちはこのメソッドを呼ぶだけにするから」という状況なら、「中身を見なくていい」は真実になります。
2. ライブラリやフレームワークを提供する場合
自分たちが「使う側」ではなく「提供する側」であれば、利用者に中身（複雑な内部状態の管理など）を見せないためのカプセル化やポリモーフィズムは必須になります。
しかし、**「自社サービスの保守運用」で「数人のチーム（あるいは1人）」が「全レイヤーを触る」という状況では、オブジェクト指向はオーバースペック（過剰設計）**になりがちなのです。
「不連続な変更」に弱いアーキテクチャ
オブジェクト指向が得意なのは、「同じインターフェースのまま、種類を増やす」という水平方向の拡張です（例：決済方法に『PayPay』を追加するなど）。
しかし、実際の業務システムで多いのは「仕様そのものが変わる」「全く新しいフローが追加される」といった、全レイヤーを貫通する不連続な変更です。
こうなると、せっかく作った抽象化の型自体を壊して作り直す必要があり、結局は全ファイルの中身を精査することになります。
おわりに：中を見るのは「技術不足」ではない
「中身がわからないと不安だ」「毎回中身をチェックしてしまう」というのは、決して技術力が低いからではありません。
それは、システムエンジニアとして**「予期せぬ副作用を起こさないか」「既存の泥臭い仕様を壊さないか」を正確に把握しようとする、極めて誠実で正しい本能**です。
オブジェクト指向の「中身を隠す」という教えは、巨大なシステムや大規模なチームを統治するための手法のひとつに過ぎません。
少人数で全層を開発・保守する現場においては、無理にポリモーフィズムを使ってコードを分散させるより、「どこで何をしているか、中身が一目でわかる」ベタ書き（具象クラスへの直接依存やシンプルな分岐）の方が、はるかにメンテナンス性が高いことも多々あります。
「ここは絶対に隠蔽しないと複雑さが爆発する」という局所にだけオブジェクト指向の恩恵を取り入れ、それ以外は堂々と「中身を見て直す」こと。それこそが、現場に即した現実的なアーキテクチャ設計なのではないでしょうか。
ポエムでした。