MisaNeco Works ブログ

2026-10-20・仕事術 / プログラミング

オブジェクト指向をわかりやすく｜プログラミングをしない人の仕事にも効く考え方とたとえ

「オブジェクト指向」という言葉を聞いたことはありますか。プログラミングの本には、かならずと言っていいほど出てきます。でも、説明を読むと「クラス」「継承」「カプセル化」など、むずかしい言葉が並びます。

じつは、オブジェクト指向はプログラムだけの話ではありません。仕事の分け方、書類のひな形、チームの頼み方など、ふだんの仕事にもそのまま使える考え方です。

この記事では、オブジェクト指向を、プログラミングをしない人にもわかるように説明します。それぞれの考え方に「日常のたとえ」と「ごく短いコード例」を付けました。コードは読み飛ばしても大丈夫です。たとえだけで意味がわかるように書いています。

会社員の方、個人事業主の方、副業を始めたい方、プログラミングを学び始めた方に向けた内容です。

1. オブジェクト指向とは何か

ひとことで言うと、「モノ」を中心に考える方法です。

ここでいう「モノ」（オブジェクト）は、次の2つをセットで持っています。

たとえば「請求書」というモノを考えてみます。

オブジェクト指向では、このデータとふるまいを1つにまとめてあつかいます。

反対の考え方と比べると、違いがわかりやすくなります。

どちらが正しい、という話ではありません。手順を順に書くほうがわかりやすい仕事もあります。ただ、関わる人やモノが増えて複雑になるほど、「モノごとに分けて、役目を決める」考え方が役に立ちます。

Pythonの公式チュートリアルでも、クラス（後で説明します）は「データと機能を組み合わせる方法」と説明されています。「情報」と「できること」をまとめる、という点がいちばん大事なところです。

2. クラスとインスタンス：設計図と実物

日常のたとえ

クラスとインスタンスは、設計図と、そこから作った実物の関係です。

型は1つでも、たい焼きはいくつも焼けます。同じ型から焼いても、中身があんこかクリームかは1つずつ違います。

請求書も同じです。ひな形（クラス）には「宛先」「金額」という欄があるだけです。実際の1枚（インスタンス）では、そこに「山田商店」「55,000円」などの値が入ります。

コード例

class Invoice:
    def __init__(self, client, amount):
        self.client = client
        self.amount = amount
    def summary(self):
        return f"{self.client}様 {self.amount:,}円"
a = Invoice("山田商店", 55000)
b = Invoice("佐藤工務店", 120000)
print(a.summary())
print(b.summary())

実行すると、次のように表示されます。

山田商店様 55,000円
佐藤工務店様 120,000円

読み方はかんたんです。

ひな形は1つ。でも、実物は何枚でも作れます。これがクラスとインスタンスです。

3. カプセル化：中身を隠して、窓口だけ見せる

日常のたとえ

自動販売機を思い浮かべてください。私たちは、お金を入れてボタンを押すだけです。中の冷却装置や、在庫の並び方は知らなくても、飲み物は買えます。

このように、中のしくみを隠して、使う人には決まった窓口だけを見せることをカプセル化と呼びます。

お店の在庫も同じです。倉庫の在庫数を、だれでも自由に書きかえられたら困ります。「出庫したいときは、在庫係に出庫票を出す」と窓口を決めておけば、在庫係がきちんと確かめてから数を減らせます。

コード例

class Stock:
    def __init__(self, count):
        self._count = count  # 中身。外から直接さわらない約束
    def take(self, n):       # 窓口
        if n > self._count:
            return "在庫が足りません"
        self._count -= n
        return f"残り{self._count}個"
s = Stock(5)
print(s.take(3), s.take(9))

実行結果：

残り2個 在庫が足りません

在庫数（_count）を直接いじるのではなく、take（出す）という窓口を通して減らします。窓口の中で「足りるかどうか」を確かめるので、在庫がマイナスになりません。

ひとつ注意があります。 Pythonには、外から絶対にさわれない「完全に隠れた変数」はありません。公式チュートリアルでも、名前の先頭にアンダースコア（_）を付けたものは「外から使わない約束」として扱う、という慣習が説明されています。つまり、カプセル化は「鍵をかける」というより、「ここは窓口から頼んでね」というルールを決めることに近いのです。

4. 継承：共通の部分を引き継ぐ

日常のたとえ

チェーン店を考えてみます。

駅前店のマニュアルを、ゼロから全部書く必要はありません。「全店共通のルールに従う。ただし開店時間は7時」と書けば足ります。

このように、共通の部分を親から引き継ぎ、違うところだけ書きかえるのが継承です。親にあたるものを「親クラス」、引き継ぐ側を「子クラス」と呼びます。

コード例

class Shop:
    def open_time(self):
        return "10時開店"
    def rule(self):
        return "レジ締めは閉店後30分以内"
class StationShop(Shop):
    def open_time(self):
        return "7時開店"
s = StationShop()
print(s.open_time(), "/", s.rule())

実行結果：

7時開店 / レジ締めは閉店後30分以内

StationShop(Shop) は「駅前店は、お店（Shop）の共通ルールを引き継ぐ」という意味です。開店時間だけ書きかえ、レジ締めのルールは書いていません。それでも、親のルールがそのまま使えています。

5. ポリモーフィズム：同じ指示で、相手ごとに違う動き

日常のたとえ

ポリモーフィズムは「多態性（たたいせい）」とも訳されます。むずかしそうな名前ですが、中身は身近です。

月末に、上司が全部署へ「月末処理をお願いします」と声をかけたとします。

指示は1つ。でも、受け取った相手によって、やることが違います。 上司は、各部署の細かい作業を知らなくてもかまいません。「月末処理」という同じ言葉で頼めば、それぞれが自分の仕事をしてくれます。

コード例

class Accounting:
    def month_end(self): return "経理：帳簿を締める"
class Sales:
    def month_end(self): return "営業：売上の見込みを報告する"
class Warehouse:
    def month_end(self): return "倉庫：棚卸しをする"
for team in [Accounting(), Sales(), Warehouse()]:
    print(team.month_end())

実行結果：

経理：帳簿を締める
営業：売上の見込みを報告する
倉庫：棚卸しをする

最後の2行がポイントです。「全部署に month_end（月末処理）を頼む」としか書いていません。それでも、部署ごとに違う作業が返ってきます。新しく「総務」という部署が増えても、総務に month_end を用意すれば、頼む側の書き方は変えずにすみます。

6. 責任の分担と疎結合：頼み方だけ決めて、やり方は任せる

日常のたとえ

「疎結合（そけつごう）」は、部品どうしのつながりがゆるい状態のことです。反対に、つながりが強すぎる状態は「密結合」と呼ばれます。

たとえば、取引先へのお知らせを考えます。

後者なら、メールで送るかチャットで送るかは、担当に任せられます。連絡手段が変わっても、頼む側は何も変えなくてすみます。

オブジェクト指向では、それぞれのモノに「自分の役目」を持たせ、ほかのモノとは決めた窓口だけでやりとりするようにします。これを「責任の分担」と言います。

コード例

class EmailNotice:
    def send(self, text): print("メールで送信:", text)
class ChatNotice:
    def send(self, text): print("チャットで送信:", text)
def remind(notice):  # 頼む側は「send」という窓口しか知らない
    notice.send("明日は請求書の締め日です")
remind(EmailNotice())
remind(ChatNotice())

実行結果：

メールで送信: 明日は請求書の締め日です
チャットで送信: 明日は請求書の締め日です

remind（お知らせする）は、相手がメールかチャットかを知りません。知っているのは「send（送る）と頼めば届けてくれる」ということだけです。これが、頼み方だけ決めて、やり方は任せる、という形です。

ここまでの5つを表にまとめます。

考え方 ひとことで 日常のたとえ
クラスとインスタンス 設計図と実物 たい焼きの型と、焼けたたい焼き
カプセル化 中身を隠して窓口だけ見せる 自動販売機のボタン
継承 共通部分を引き継ぎ、違いだけ書く チェーン店の共通ルール＋店ごとの違い
ポリモーフィズム 同じ指示で、相手ごとに違う動き 「月末処理お願い」で各部署が別の作業
責任の分担・疎結合 頼み方だけ決めて、やり方は任せる 「届けて」と頼み、手段は担当に任せる

7. 少しだけ歴史

オブジェクト指向の考え方は、1960年代のノルウェーで生まれました。

オスロ大学の紹介ページによると、オーレ＝ヨハン・ダールとクリステン・ニガードが、ノルウェー計算センター（Norsk Regnesentral）で、シミュレーション用のプログラミング言語 Simula I（1961〜1965年） と Simula 67（1965〜1968年） を作りました。この中で、クラス、サブクラス、継承、実行中にオブジェクトを作ることなど、今のオブジェクト指向につながる考え方が初めて形になったと紹介されています。

2人は、2001年のACMチューリング賞（コンピューター科学で最も権威のある賞の1つ）を受けています。受賞理由は「Simula I と Simula 67 の設計を通じた、オブジェクト指向プログラミングの誕生に欠かせないアイデア」です。

「オブジェクト指向プログラミング」という言葉そのものは、アメリカの計算機科学者アラン・ケイが使い始めたとされます。ケイ本人が2003年7月23日に送ったメールでは、ユタ大学にいた1966年11月以降に、Simulaなどに影響を受けてプログラムのしくみを考え、「たぶん1967年に、何をしているのかと聞かれて『オブジェクト指向プログラミングだ』と答えた」と書いています。

同じメールで、ケイは当初の考えを次のように説明しています。

I thought of objects being like biological cells and/or individual computers on a network, only able to communicate with messages

（オブジェクトは、生き物の細胞や、ネットワーク上の1台1台のコンピューターのようなもので、メッセージでしかやりとりできないものだと考えた）

細胞は、中のしくみを外に見せず、信号のやりとりだけでほかの細胞と協力します。これは、この記事で説明した「カプセル化」や「疎結合」とよく似たイメージです。

ケイは、ゼロックス社のパロアルト研究所（Xerox PARC）で、プログラミング言語 Smalltalk（スモールトーク） を開発したチームを率いました。ケイ自身の論文「The Early History of Smalltalk」では、最初の本格的なSmalltalkは1972年ごろのSmalltalk-72で、一般向けに公開されたのはSmalltalk-80（1983年に公式公開）とされています。ケイは2003年のACMチューリング賞を受けています。

ちなみに、同じメールでケイは「Simulaの継承のしかたは好きではなかったので、よくわかるまで継承は組み込みの機能から外した」とも書いています。オブジェクト指向の生みの親の1人でさえ、継承には慎重だったのです。この点は、後の「やりすぎの注意」ともつながります。

8. エンジニア以外の仕事で役立つ場面

ここからが本題です。オブジェクト指向の考え方は、プログラムを書かない仕事でも使えます。以下はすべて「たとえば〜の場合」という仮の例です。

8-1. 業務マニュアル・役割分担（カプセル化）

たとえば、経費精算のやり方が人によってバラバラな職場を考えます。「経理の田中さんに直接LINEする人」「共有フォルダに置く人」「紙で渡す人」がいると、経理の担当は大変です。

そこで、窓口を1つに決めます。

申請する人は、フォームの使い方だけ知っていれば十分です。経理は、中のやり方を変えても、申請する人に影響を出さずにすみます。これがカプセル化の考え方です。

8-2. テンプレート書類（クラスとインスタンス）

見積書・請求書・議事録などのひな形は、そのままクラスです。

ひな形をきちんと作っておくと、だれが作っても同じ項目がそろいます。「欄を足したい」ときは、ひな形を1か所直せば、次からの書類すべてに反映されます。

8-3. チェックリスト・店舗の共通ルール（継承）

たとえば、3店舗あるお店の開店チェックリストです。

項目 全店共通（親） A店（子） B店（子）
レジのつり銭確認 あり 引き継ぐ 引き継ぐ
店内の清掃 あり 引き継ぐ 引き継ぐ
開店時間 10時 7時に変更 引き継ぐ
駐車場の確認 なし なし 追加する

全店共通のリストを1つ持ち、店ごとには違うところだけ書きます。共通ルールが変わったときは、親の1か所を直せば全店にいきわたります。店ごとに全部を書き写していると、1店だけ直し忘れる、ということが起きやすくなります。

8-4. 「月末処理をお願い」で各部署が動く（ポリモーフィズム）

5章の例のとおりです。仕事の頼み方で言えば、指示する側は「何をしてほしいか」だけを言い、「どうやるか」は各担当に任せるということです。

たとえば、次のような頼み方がこれにあたります。

全員に同じ言葉で頼めるので、指示がシンプルになります。新しい部署やメンバーが増えても、「その人の報告のしかた」を決めるだけですみます。

8-5. Excelの表の設計（1行＝1つのモノ）

Excelやスプレッドシートの表も、オブジェクト指向と相性がよいです。コツは、1行を「1つのモノ」、列を「そのモノが持つ情報（属性）」にすることです。

顧客ID 会社名 担当者 電話 最終連絡日
C001 山田商店 山田 03-0000-0000 2026-10-01
C002 佐藤工務店 佐藤 06-0000-0000 2026-09-15

（表の中身は説明のための架空の例です）

よくある失敗は、1行に2つのモノを混ぜることです。たとえば「顧客」と「その顧客の注文」を同じ行に入れると、注文が増えるたびに列が右へ伸びていきます。こういうときは、「顧客」の表と「注文」の表に分けて、注文の表に顧客IDの列を持たせます。モノが違えば表を分ける。これだけで、集計や並べかえがぐっと楽になります。

8-6. チーム運営・引き継ぎ

仕事を引き継ぐとき、「この仕事は何を持っていて、何ができるのか」を書くと、もれが減ります。

たとえば「請求業務」を引き継ぐ場合、次のように書き出せます。

これは、1つの仕事を「オブジェクト」として説明しているのと同じです。後任の人は、まず窓口と役目をつかめば、中の細かい手順は少しずつ覚えればよくなります。

8-7. 外注の頼み方

外注先に仕事を頼むときも、疎結合の考え方が使えます。

やり方まで細かく決めすぎると、外注先の得意な方法が使えません。反対に、納品の形を決めておかないと、受け取ったあとに手直しが必要になります。「入口と出口は決める。中は任せる」が、ちょうどよいバランスです。

8-8. 家事の分担

家の中でも同じです。

「洗濯物はかごに入れる」というルールだけ守れば、ほかの家族は洗濯の手順を知らなくても困りません。担当が変わっても、かごのルールが同じなら、家の中は混乱しません。

9. やりすぎの注意

便利な考え方ですが、使いすぎると逆に複雑になります。

細かく分けすぎない

窓口や担当を細かく分けすぎると、「この件はだれに頼めばいいの？」が増えます。たとえば、5人のチームで役割を15個に分けても、1人が3役を持つだけで、かえって混乱します。 分ける目安は「その分け方で、頼み方がシンプルになるか」です。シンプルにならないなら、まとめたままでかまいません。

継承を深くしすぎない

「全社共通 → 地域共通 → 県共通 → 市共通 → 店舗」のように、親子の段を重ねすぎると、「このルールはどこで決まったのか」をさかのぼるのが大変になります。 7章で紹介したとおり、アラン・ケイも継承には慎重でした。段は浅く、2〜3段くらいまでにとどめると、見通しがよくなります。共通にしたいものが少しだけなら、親子にせず、「共通の部品（チェックリストの一部など）を、必要なところで使う」という方法もあります。

最初から完ぺきな設計を目指さない

使いながら「ここは分けたほうがいい」「ここはまとめていい」とわかることも多いです。最初はざっくり分けて、困ったところから直していくほうが、結果的にうまくいきます。

10. よくある誤解

誤解 実際は
オブジェクト指向はプログラマーだけのもの 仕事の分け方・書類・表の作り方にも使える考え方
継承をたくさん使うほど上級者 継承は便利だが、深くしすぎると読みにくい。使いどころを選ぶ
カプセル化は「情報を隠して秘密にする」こと 目的は秘密ではなく、「窓口を決めて、まちがった使い方を防ぐ」こと
オブジェクト指向なら必ずよいものができる 道具の1つ。手順を順に書くほうがわかりやすい場面もある
「オブジェクト」は物理的なモノだけ 「請求業務」「予約」「注文」のような、形のないものもオブジェクトにできる

11. まとめ

12. 今日からできる練習

最後に、プログラミングをしなくてもできる練習を3つ紹介します。

練習1：身の回りの仕事を「モノ・持っている情報・できること」に分ける

紙かメモアプリに、「モノ｜持っている情報｜できること」の3つを書き出します。

自分の仕事から、モノを3つ選んで書いてみてください。書いてみると、「この情報はどのモノが持つべきか」がはっきりします。

練習2：窓口を1つ決める

「いつもバラバラの方法で頼まれる仕事」を1つ選びます。その仕事の受付方法を、フォーム・決まったメールアドレス・決まったチャットのどれか1つにしてみましょう。これがカプセル化の第一歩です。

練習3：共通ルールと違いを分けて書く

似た作業が複数あるとき（店舗ごと、取引先ごと、季節ごとなど）、「全部に共通すること」と「それぞれの違い」を分けて書き出します。共通部分を1か所にまとめるだけで、直し忘れが減ります。

プログラミングを学ぶ予定がある方は、この練習で作った表を、そのままクラスの設計に使えます。「モノ」がクラス、「持っている情報」がデータ、「できること」がメソッド（ふるまい）です。

参考にした資料

※この記事はAIを活用して作成しています。コード例は Python 3 で実行し、記事中の出力と一致することを確認しています。

新しい無料ツールや記事を、LINEでお知らせします
「ツール」「お金」「スマホ」と送ると、合うツールの案内が自動で届きます。

LINEで友だち追加Eternal Philosophy 公式LINE（EQUA・MisaNeco Works を運営）
関連記事コンフォートゾーンとは？意味・言葉の由来と、無理のない広げ方をやさしく解説