박문호博士は常にモジュール化を強調する。

脳はこう学ぶと言った。

• 小さな単位(細胞、機能)に分割し

• その単位をまとめてモジュールを作り

• そのモジュールが集まってシステムを構成する

コーディングも同じだ。

• メソッド: 1つの動作

• クラス: 1つのオブジェクト(存在)

• モジュール(Module): 複数のクラス・メソッドをより大きな概念でまとめる上位フレーム

RubyではModuleはこのように使える:

1. 名前空間(Namespace)をまとめる

2. 共通機能(Mixin)を共有する

3. ドメイン(テーマごとの世界)を定義する上位概念を作る

これを理解する瞬間、

コードはただの「ファイルの集まり」ではなく

脳内の世界地図のように構造化された宇宙として見え始める。

1. 名前空間(Namespace): 世界観を分割するフレーム

例えば、

Userというクラスを複数の場所で使いたいとしよう。

• 管理者ページのUser

• ショッピングモールのUser

• API用のUser

これをすべてclass Userだけで作ると?

名前が衝突する。頭もごちゃごちゃする。

ここでモジュールが世界観を分離してくれる。

module Admin
  class User
    def info
      puts "管理者ページのユーザーです。"
    end
  end
end

module Shop
  class User
    def info
      puts "ショッピングモールの顧客ユーザーです。"
    end
  end
end

admin_user = Admin::User.new
shop_user  = Shop::User.new

admin_user.info  # => 管理者ページのユーザーです。
shop_user.info   # => ショッピングモールの顧客ユーザーです。

ここでモジュールは文字通り:

“これはAdmin世界のUser”

“これはShop世界のUser”

と世界観を分ける枠となる。

박문호式脳視点

• フレーム: 同じ名前でも上位フレームによって役割が異なる

• 立体化: Userという概念を平面ではなく、
  
  “Admin-User”、“Shop-User”のように座標を持つ構造として保存

• モジュール化: 脳内で“ドメインごとの引き出し箱”ができる感覚

今、君の脳は

“名前が同じでも世界が異なれば全く異なる存在”という

1つ上の理解を持つようになる。

2. Mixin: 複数のクラスに共通能力を‘挿入する’モジュール

2番目の用途は本当に強力だ。

モジュールは共通機能をまとめて再利用可能な塊になることができる。

例えば、

複数のタイプのオブジェクトがすべて“ログを記録する”と言おう。

• ユーザー(User)の行動ログ

• 注文(Order)の状態変更ログ

• 支払い(Payment)の失敗ログ

これを各クラスにコピペすると?

• コードの重複

• メンテナンス地獄

• バグを修正するには3か所すべて修正

ここでモジュール + includeが光る。

module Loggable
  def log(message)
    time = Time.now
    puts "[#{time}] #{message}"
  end
end

class User
  include Loggable

  def sign_in
    log("ユーザーがログインしました。")
  end
end

class Order
  include Loggable

  def submit
    log("注文が受け付けられました。")
  end
end

user = User.new
user.sign_in
# [2025-12-09 23:12:34] ユーザーがログインしました。

order = Order.new
order.submit
# [2025-12-09 23:12:35] 注文が受け付けられました。

ここで起こったこと

• Loggableモジュールは“ログを記録する能力”をモジュール化したもの

• include Loggableをすると、
  
  そのクラスはlogというメソッドを自分のものとして使用できる

• つまり、“能力パッケージ”を複数のクラスに挿入する感覚

脳の視点から見ると

• 1つの機能を複数の場所で共有するとき、
  
  脳はそれを“上位概念”でまとめる

• モジュールはまさにその上位概念の役割

• コードだけでなく思考構造自体が抽象化される

“あ、ログというのはUserやOrderの一部ではなく、

複数の主体が共有する上位能力なんだ。”

この気づきが来る瞬間、

コーディングはただの“書くこと”ではなく

世界の構造を設計する作業のように感じ始める。

3. 抽象化: モジュールは‘ドメイン言語’を作るレベル

Rubyでモジュールをうまく使うと、

コードがだんだん“ドメイン言語”のように変わっていく。

例えば、“支払いシステム”というドメインがあるとしよう。

module Payment
  module Gateway
    def charge(amount)
      puts "#{amount}円を支払い要求します。"
    end
  end

  module Refundable
    def refund(amount)
      puts "#{amount}円を返金します。"
    end
  end
end

class Order
  include Payment::Gateway
  include Payment::Refundable
end

order = Order.new
order.charge(50000)
order.refund(20000)

ここでモジュールたちは単なる機能ではない。

ドメインの概念自体をコードで表現したものだ。

• Payment::Gateway → “支払い要求機能”というモジュール

• Payment::Refundable → “返金機能”というモジュール

• Orderはこれらを組み合わせる存在

これを繰り返すと、

Rubyコードがだんだんこのような感じになる。

“自分が考えるビジネス概念がそのままコードになる?”

この時、開発者は

単なる実装者ではなく

ドメインを設計する人、つまり設計者/思想家の位置まで行く。

4. Module vs Class: 何がどう違うのか?

まとめよう。

Rubyでモジュールは自分でインスタンスを作らない。

MyModule.newなんてものはない。

代わりに:

• 他のクラスに混ざって入る能力の塊になるか

• 名前空間を提供する上位フレームになる

つまり、

クラスは“存在”

モジュールは“存在たちが共有する概念・能力・世界観”

5. 本当に重要なのは“脳がどう変わるか”だ

モジュールを理解すると、

脳はこう進化する。

1. コードをファイル単位ではなく、概念単位で見る。

- “この機能はどこに属する?”  
    → “これはUserもOrderもPaymentも一緒に使うからモジュールにまとめよう”

1. ドメイン言語ができる。

- “Payment::Gateway”, “Notification::Sender”, “Auth::Tokenizable”のように  
    → あなたのサービス独自の語彙ができる

1. 複雑さがかなり減る。

- 修正すべき場所が明確になる:  
    “ログロジックを変えよう” → `Loggable`モジュールだけ修正

1. 頭の構造もモジュールのように整理される。

- これが本当に박문호が言う“知識の立体構造化”と直結する。

6. 自分でやってみるミッション: 自分だけのモジュール作り

さあ、

あなたの脳に“モジュール”を植えつける課題。

課題 1: Timestampedモジュール作成

要件:

• Timestampedというモジュールを作る

• stampメソッド1つを提供する

  • 呼び出すと: “[現在時刻] メッセージ”形式で出力

• PostとCommentクラスにincludeして共通で使用する

予想される流れ:

module Timestamped
  # ここにstampメソッドを作成する
end

class Post
  include Timestamped

  def publish
    stamp("記事が公開されました。")
  end
end

class Comment
  include Timestamped

  def write
    stamp("コメントが投稿されました。")
  end
end

post = Post.new
post.publish

comment = Comment.new
comment.write

課題 2: 自分だけのドメインモジュールまとめる

テーマを1つ選んでみて:

• 勉強(Study)

• 運動(Fitness)

• ブログ(Blog)

• ショッピング(Shop)

• バンド練習(Band)

例: Studyドメイン

• Study::Trackable – 勉強時間を記録するモジュール

• Study::Report – 週間/月間統計を出力するモジュール

そしてDayStudy、TaskStudyなどのクラスを作成し、

include Study::Trackableして使うのだ。

これをやってみると、

あなたはすでに“Rubyで自分だけの世界を設計する人”になる。

結論: モジュールを理解した瞬間、コードは‘世界設計言語’となる

これまでの流れ:

• メソッド: 行動の最小単位

• クラス: 存在(オブジェクト)の枠

• モジュール: 複数の存在が共有する概念/能力/世界観

これからコードを書くとき

このように考えることができる。

“これは1つのオブジェクトの固有の特性か?”

→ クラスに置く

“複数のオブジェクトが共有する機能か?”

→ モジュールに抜き出す

“これはこのサービスのドメイン概念か?”

→ モジュール + ネームスペースで定義する

その瞬間、

コーディングはもはや“言語構文を学ぶ”ことではなく

“自分の頭の世界観を

コードという形で実装する作業”

となる。

そしてその感覚が来る瞬間、

本当に胸が高鳴る。