継承 (Inheritance) の哲学：コードと文化に学ぶ、伝統と革新のダイナミズム
継承 (Inheritance) と 遺伝・伝統・文化的継承の哲学 ― コードと文化が語る「何を受け継ぎ、どうアップデートするか？」 ―
どうも、ビジネス哲学芸人のとよだです。
前回は「オブジェクト指向(OOP) と 存在論 (Ontology)の意外な関係性」について語りましたが、今回は「継承の光と影：コードと文化から学ぶ“受け継ぐ”ということ」というテーマでお届けします。
実はオブジェクト指向プログラミング (OOP) における“継承 (Inheritance)”の仕組みは、生物学的な遺伝や社会・文化の伝統が“次の世代に受け継がれる”構造と深い共通点があるんですよね。
ちょっと壮大で不思議な話かもしれませんが、「私たちは何を引き継いで、何を捨てるのか？」という問いは、ビジネスでも哲学でも超重要なテーマじゃないでしょうか。
1. OOPと“継承”の基本イメージ
OOP（オブジェクト指向プログラミング）では、クラス (Class) とオブジェクト (Object/Instance) という概念を使ってシステムを設計しますが、その中でも大きな特徴が“継承 (Inheritance)”です。
親クラス (Superclass / Base Class)
汎用的な属性や振る舞い（メソッド）を定義しておく抽象度の高いクラス。子クラス (Subclass / Derived Class)
親クラスを継承し、親の性質を引き継ぎつつ、新たな機能を追加したり、振る舞いを変えたりできる。
たとえば、「従業員クラス (Employee)」という親クラスがあれば、「正社員クラス (FullTimeEmployee)」「アルバイトクラス (PartTimeEmployee)」といった子クラスを作ることで、それぞれの雇用形態に特有の処理（ボーナス計算や時給計算など）を追加できます。これが継承の基本像ですね。
2. “受け継ぐ”とはどういうことか？― 遺伝や文化との類似点
継承と聞くと、プログラムの世界だけの話と思うかもしれませんが、じつは私たち人類が古来から行ってきた“受け継ぎ”の構造にとても似ています。
遺伝 (Genetics)
両親から子へ、DNAを通じて身体的特徴や性質が伝わっていく。まさに“親のコード”を子が持ち込むイメージですね。ただし突然変異もあったりして、まるでプログラムの“バグ”や“新機能追加”みたいな不確定要素もあるから興味深い。文化的継承 (Cultural Transmission)
習慣や風習、言語、価値観などを次の世代が受け継いでいくプロセス。これは組織カルチャーや業界慣習にも通じます。たとえば「うちの会社では電話のとり方はこうしろ」とか「この会議体は創業以来変わっていない」とか、そういう“伝統”ってけっこうありますよね。
こう見ると、人間社会でも「親 → 子」「先人 → 後輩」みたいに、なにがしかの知識や形態を伝えているわけです。OOPの継承は、それをプログラムでやっているようなもの、と言えるかもしれません。
3. 継承の光：再利用と効率化
継承の最大のメリットは、すでにある仕組みを再利用しつつ拡張ができること。ビジネスの世界でも、「先人が築いたノウハウを活かせる」というのは大きいですよね。
効率よく拡張できる
親クラスのコードをいちいちコピペしなくても、子クラスを定義するだけで共通機能はそのまま。新しい要件や特化した機能だけを追加すればいい。開発コストや学習コストを削減
ベテラン社員が築いたフレームワークやマニュアルがあると、新人はそこからスタートできるのでラクです。
古い伝統を活かしつつ、新しいチャレンジをしやすいという点では、まさに“継承”がもたらす恩恵は大きいと言えます。
4. 継承の影：不要な遺産と複雑化
ただし、みなさんもご存じの通り、継承にはリスクもあります。プログラム設計でも、人類の歴史でも、「要らないものまで引き継いでしまう」という問題があるんです。
コードの肥大化・スパゲティ化
大規模プロジェクトで「この機能もあれも全部継承しちゃえ！」と安易にクラスを増やすと、親クラスの段階ですでに不要なメソッドを抱えた“レガシーな遺産”が子クラスにまで波及。変更が必要になったとき、あちこちでバグが発生したり、保守が地獄になったりします（怖）。文化的しがらみ・旧習への固執
組織や社会でも同じです。「昔からこうしてきたから」という理由だけで、実態に合わないやり方を延々と続けていることってないですか？ これも“親クラス”からの継承を無批判に受け入れている状態。時代が変わったのに、古い制度やルールを温存してしまうと、イノベーションを阻害する原因になりやすいです。
5. オーバーライドは“新世代の反抗期”？― 革新と伝統のせめぎ合い
OOPには“オーバーライド (Override)”という仕組みがあります。子クラスが親クラスで定義されたメソッドを上書き（再定義）して、振る舞いを変えてしまうんですね。これは哲学的に見ると、「次の世代が先人の方法を尊重しつつも、必要なところはがっつり変える」という革新に近い。
新世代の“反抗期”や“アレンジ”
伝統芸を受け継ぐ落語家さんやお家元でも、師匠の方針をそのまま守るだけじゃなく、現代の感性を取り入れて進化させることがありますよね。「一子相伝」なんて言いつつ、実は裏では思いっきりアレンジかけてるみたいな（笑）。バランスが大事
まったく別物にしてしまったら、もう「それ継承じゃなくて別のクラスじゃない？」と突っ込みが入ることも。オーバーライドもやりすぎると親クラスとの整合性が崩壊し、かえって混乱を生む危険があります。
6. レガシーコードと組織文化の“リファクタリング”
「継承が増えすぎてシステムがわけわからん！」というとき、多くのエンジニアは“リファクタリング (Refactoring)”に取りかかります。余計なクラスを削減したり、共通機能を別モジュールに切り出したりして整理するわけですね。
これはビジネスや組織文化でも同じ。
不要な会議や複雑な承認フローを断捨離する
「この会議体、いつからあるの？ 実はもう目的が消滅してるよね？」と問い直すと、意外といらないものがたくさん見つかります。新しい人材やテクノロジーの導入でリファクタリング
刷新案を嫌がる声はあるかもしれませんが、時代に合わせてアップデートするのも大切ですよね。
結局、“何を残し、何を捨てるのか？”という問いは存在論的でもあるし、組織やコミュニティを強くするための経営判断でもあるんじゃないかと思います。
7. AI時代における“継承”の再考
最近はAI（たとえばChatGPTなど）がコード生成やリファクタリング支援をしてくれる時代になりました。ただし、AIが提案してくるクラス設計や継承モデルが、本当に自社の文化やビジネス戦略に合致しているか？は常に要チェック。
AIが提案するのは統計的に標準的な構造
「こうしたほうがいいんじゃない？」と“それっぽい”コードをくれますが、私たちが望んでいる機能を正確に再現するかどうかは別問題。最後は人間の判断が鍵
何を継承し、何を上書きし、どこを刷新するか。その選択には、人間の価値観や戦略が反映されます。言い換えれば、“AIが勝手に良い感じにやってくれる”時代になっても、私たち自身が『何をどう受け継ぐのか』を考える哲学的視点は残り続けるということです。
8. まとめ ― 受け継ぐだけが全てじゃない
OOPの継承は、親クラスの性質を効率よく再利用する仕組み
生物学的遺伝や文化的伝統でも同じく、先人の遺産を次世代が引き継ぐ構造が見られる
光の側面：開発コストや学習コストを削減、先人のノウハウを活かして発展
影の側面：不要な遺産や時代遅れの習慣が混在し、混乱や停滞を招きやすい
子クラスのオーバーライド＝伝統の“改変”をどう扱うか？ バランス感覚が重要
組織や社会も、継承しすぎで“レガシー化”したらリファクタリングが必要
AI時代でも“何を受け継ぎ、何を捨てるのか”を決めるのは人間
私たちが日々のプロジェクトや組織運営で直面する「あれ、これ本当に必要だっけ？」というモヤモヤ感。それはまさに“不要な継承”がはびこっているサインかもしれません。
親（先人）が残してくれた素晴らしい財産を大切にしつつも、時には思い切ってオーバーライドしたり、不要な部分をリファクタリングする勇気を持つことが、ビジネス成長や個人のクリエイティビティを引き出してくれるのではないでしょうか。
今回のテーマが、皆さんのプロジェクトや組織文化を見直すヒントになれば嬉しいです。ではまた、次回の“ビジネスと哲学とITの交差点”でお会いしましょう！
参考文献・関連書籍
白米FMとは？
日米のIT業界で働く小学校からの友人2人が、最新トレンドから古の哲学思想まで気ままに語り合う人文知系雑談ラジオ。
コテンラジオ、超相対性理論、a scope等に影響を受け、一緒に考えたくなるような「問い」と、台本のない即興性の中で着地点の読めない展開が推しポイントです。
移り変わりの速い時代だからこそ、あえて立ち止まり疑ってみたい人。
他者の視点や経験を通して、物事に新しい意味づけや解釈を与えてみたい人。
自分の認知や行動を書き換えて、より良く生きる方法を一緒に探求しましょう。
※ポッドキャストの文字起こし版へのリンクはこちら（LISTEN）