木を見る西洋人と森を見る東洋人：オブジェクト指向設計に潜む「認知」と「哲学」の境界線

​1. はじめに

​エンジニアとして設計業務に従事していると、「オブジェクト指向」という概念が驚くほどスムーズに腹落ちする時と、逆に「なぜこんなに回りくどい捉え方をするのか」と違和感を覚える瞬間に遭遇します。
​この違和感の正体を探るヒントが、認知心理学者リチャード・ニスベット氏の著書『木を見る西洋人、森を見る東洋人』(ISBN 978-4478910184)にあります。本作では、西洋と東洋における「世界の捉え方」の根本的な違いが論じられています。
​本稿では、オブジェクト指向分析設計開発を単なる技術論としてではなく、人文学・哲学の文脈から再定義し、私たちがモデリングの際に行っている「思考の正体」を解き明かします。

​2. なぜオブジェクト指向分析設計開発は西洋でしか生まれなかったのか

​結論から言えば、オブジェクト指向分析設計開発という思想は西洋の歴史的・文化的背景が影響している可能性があります。
​現に、『オブジェクト指向方法論の世界：比較と解説』(ISBN 49313356184)(P.129)という書籍にはOMT、OOSA、OOSE、boochをはじめとする設計手法が登場しますが、それらの系譜をたどっていくと、調べた範囲ではあるが、すべてが西洋で生まれ、東洋からは生まれていないことがわかります。

手法	国
OMT	アメリカ
booch	アメリカ
OOSE	スウェーデン
Eiffel/OOSC	フランス
Coad Yourdon	アメリカ
CRCカード	アメリカ
Fusion	アメリカ
Shlaer Mellor	アメリカ
Martin Odell(=Ptech)	イギリス/アメリカ
MERODE	ベルギー
OORASS/OOram	ノルウェー
HOOD	イギリス
GOOD	アメリカ
OOSD(=Colbert)	アメリカ
SOMA	スイス
OSMOSYS	スイス／イギリス？
Texel	アメリカ・イギリス
OBA	チェコ？
MOSES	イギリス？
ROOM	カナダ
SDM	ドイツ
RCM	イギリス
Wirfs-Brock	アメリカ

※オブジェクト指向手法の歴史を俯瞰するには、「手法の星雲図」が非常に参考になります。年代だけでなく、各手法の関係性や発展の流れを一枚で把握できる優れた可視化です。『オブジェクト指向方法論の世界：比較と解説』(ISBN 49313356184)(P.129)

その根拠は、前述の『木を見る西洋人、森を見る東洋人』(P.159)に記された認知プロセスの差にあります。
​「分類」の西洋、「関係」の東洋
​書籍では子供に「牛・鶏・草」を見せ、「丸で牛とどちらか一つを囲むならどちらか？」と質問する実験が紹介されています。

地域	解答	意味	解説
西洋的な回答	鶏	歩くよ、 寝るよ、 食べるよ	共通の動作に着目し、カテゴリー(クラス)で分類します
東洋的な回答	草	牛は草を食べるから	対象間の関係性(メッセージング)に着目します

​また、上空で向きを変える風船について、

地域	解答	解説
西洋的な回答	彼(風船)がそっちに行きたかった	対象に意思や文脈を投影します
東洋的な回答	上空で風が変わった	対象間の関係性(メッセージング)に着目します

周囲が不機嫌な中で一人だけ笑顔の人物に対しても、

地域	解答	解説
西洋的な回答	本人が笑っているから幸せだ	個体の表現のみを評価します
東洋的な回答	幸せそうだけど、何か様子がおかしい	全体の場(コンテキスト)から判断します

コロナ禍に起きたマスク問題もこの延長線に見える

地域	解答	解説
西洋的	マスクを嫌がる	・病人に見える ・弱く見える
東洋的	マスクをする	周りに迷惑をかけない

マスクが効かないという論争もあるが、それはさておき、行動で違いがわかる

コロナ禍の行政対応もそのまま延長線に見える

地域	対応	解説
西洋的	web申請一択	・コストを下げる ・申請方法はある
東洋的	・web申請 ・紙申請	皆ができる

​対象を周囲から切り離し、それ自体を「独立した実体」として分析し、内部に属性を閉じ込める――。このカプセル化や責務の分離という思想は、西洋哲学との類似性が見られるように思います

​3. クラス図の抽出とアリストテレス哲学

​UMLのクラス図を作成する際、私たちは無意識に「目の前の具体的な対象」から「共通する本質」を抜き出す作業を行います。このプロセスは、古代ギリシャの哲学者アリストテレスが提唱した 「形相(エイドス)」 の概念と驚くほど酷似しています。
​実体と形相の類似性
​アリストテレスは、個別の物体には、そのものをそのものたらしめている「形相(本質・設計図)」が宿っていると考えました。
​アリストテレスの視点： 目の前にある「個別の机」は、その背後にある「机という形相(型)」を具現化したものである。
​オブジェクト指向の視点： メモリ上の「個別のインスタンス」は、設計時に定義した「クラス(型)」を具体化したものである。
​属性や操作を定義する行為は、アリストテレスが『カテゴリー論』で試みた分類学の現代版といえます。私たちはモデリングを通じて、図らずも数千年前の哲学者と同じ視座で世界を解体しているのです。

アリストテレスのカテゴリー論(十範疇)

範疇	内容
実体	モノそのもの
量	数・大きさ
性質	色・能力
関係	親子・大小
場所	どこにあるか
時間	いつか
状態	姿勢・配置
所有	持っているもの
能動	作用する
受動	作用される

Coad手法のクラス抽出法

Coad	意味
有形物	現実のモノ
役割	人やシステムの役目
事象	イベント
相互作用	通信・関係
場所	ロケーション
組織	集合・構造
仕様	ルール・定義

​4. 進化と多様性：OOPにおける「振る舞い」の再定義

​西洋的な分類(継承)に基づいた開発が、実際の生物(オブジェクト)の多様性にどう対応するかを具体例で見てみましょう。
​「動物」という基底クラスから「人」「牛」「鳥」を派生させ、共通メソッドを定義します。
​「食べる」メソッドのオーバーライド

対象	動作
人	一般的な咀嚼・消化処理を書きます
牛	進化の過程で胃を4つ持ちました。4つの胃を直列に通過させ、微生物の力を借りて分解し、再び口に戻して噛み直す(反芻)という特殊な多段階消化プロセスを実装します
​鳥(鳩・カモ)	軽量化のため歯がありません。小石を飲み込み、砂嚢(さのう)という器官の中で小石を利用して咀嚼する選択を取りました
ゴキブリ	胃(前胃)にキチン質という歯のような構造。咀嚼と消化を胃で同時に行う

​「排泄」メソッドの多態性(ポリモーフィズム)
​環境や制約によって、内部実装(ロジック)は劇的に変化します。

対象	動作
​哺乳類	アンモニアを尿素に変え、液体として排泄します
鳥類	飛行のために極限まで軽量化を図りました。 水分を保持して重くなるのを防ぐため、 尿と糞と一緒に排泄します。

「繁殖」メソッドの特殊解

対象	動作
​一般	やることをやる
カマキリ	条件によって繁殖中にオス捕食が起こることがある
シャケ	川で外部繁殖、その後、ほぼ全個体が死亡
クマノミ	環境でオス⇄メス変化、その群れにいる一番大きな個体がメスになる(こわい。。。)
チョークバス	両性具有で交代(数十秒単位で)で繁殖する
カタツムリ	成長の過程で右巻き、左巻きが発生し、右巻きと左巻きがあうと、位置があわない
シオマネキ	繁殖アピールで片側のはさみが巨大化
ジャイアントパンダ	・繁殖力が低い ・繁殖期が短い

クマノミの生態は長年議論になっていた「場」はオブジェクトか？という問いに一つの回答を出したと思います。

​「寝る」メソッドの特殊解

対象	動作
​人間や牛や鳥	「静止して寝る」という共通処理を親クラスから継承できます
マグロ	泳ぐことでエラに酸素を送り込む「衝突強制換気」という呼吸法をとるため、静止すると窒息します。そのため、以下のいずれかの仮説に基づいた特殊な振る舞いを記述する必要があります

マグロの睡眠の仮説

仮説	動作
半球睡眠説	片方の脳を休ませながら、もう片方の脳で泳ぎ続ける(非同期並列処理のような振る舞い)
落下・遊泳説	水面まで泳ぎ上がり、重力を利用して沈降しながら一時的に脳を休ませる(バッチ処理的な間欠動作)
群れや流れに乗る休息説	自分で推進しなくてもよい状態、海流に乗って省エネ移動、エネルギー消費を下げる
脳の「局所休息」に近い状態説	脳全体がオフになる「人間型睡眠」とは違い、活動パターンの低下としての“睡眠様状態

​
このように、共通するインターフェースを保ちつつ、生存戦略上、特殊化が必要な部分だけを変更する。これこそがOOPの醍醐味です。そして生物は、知らずに勝手に最適化していたのです。

※マグロの睡眠仮説への補足

この話を調べていると、面白い人物に行き当たりました。
その人物の名前は、ヤコブ・ツィペロヴィチ(Yakov Tsiperovich)です。
ロシア語圏では「眠らない男」として紹介されてきた人物です。
研究機関で調べた際、
研究者は「起きているように見えるが、脳波にはアルファ波が出ている」、
または、「数秒〜数分単位で脳の一部が睡眠状態（微小睡眠）に入っている」と
観察したとされています。
ただし、ピアレビュー(査読)が行われていないため、都市伝説になっています。
つまり、外見上は覚醒していても、脳が休息に近い状態になっている可能性があるということです。
これは、マグロについても「眠っているか」ではなく、
泳ぎながら休息という機能を実現しているのではないかと考えるきっかけになります。

※じゃんけんの例は「新・標準プログラマーズライブラリ C++ クラスと継承 完全制覇」の巻末をご覧ください

5. UML前夜の群雄割拠：90年代「オブジェクト指向4大手法」のメタモデルとプロセスを徹底解剖する

私たちが普段当たり前のように使っているUML(Unified Modeling Language)。しかし、1990年代前半のオブジェクト指向界隈は、各々の思想を掲げた方法論(メソドロジー)が乱立する、まさに「大航海時代」でした。

今回、UML誕生直前の貴重な比較資料(オブジェクト指向システム開発)をベースに、当時の4大手法(Shlaer&Mellor / OMT / Coad&Yourdon / Booch)の思想、用語、基盤、そして開発プロセスの違いを徹底解析しました。

コード(実装)の制約に縛られがちな現代だからこそ、彼らが「現実世界をどう切り取ろうとしたか」という狂気的なまでのモデリング思想は、ドメイン駆動設計(DDD)やクリーンアーキテクチャに通じる強烈な気づきを与えてくれます。

5.1. 用法・メタモデルの相違：各手法は何にフォーカスしたか

同じ「オブジェクト指向」であっても、手法によって使用する用語(メタモデル)には明確な差異がありました。これは手法ごとの「システムの捉え方の重心」を表しています。

図：各手法の用語(用法)の相違

概念	Shlaer& Mellor	OMT	Coad& Yourdon	Booch
クラス	オブジェクト	クラス	クラス	クラス
属性	属性	属性	属性	フィールド
メソッド	プロセス・モデル	操作 (Operation)	サービス (Service)	操作 (Operation)
メッセージ	イベント	事象 (Event)	メッセージ接続	メッセージ
インスタンス	インスタンス	インスタンス	オブジェクト	オブジェクト
階層	上位型-下位型	スーパークラス-サブクラス	Gen-Spec	上位クラス-下位クラス
全体-部分	関連付けオブジェクト	集約	Whole-Part	using関係
継承	関連付けオブジェクト	スーパークラス/サブクラス	Gen-Spec	上位クラス/下位クラス

比較から読み取れる各アプローチの傾向

• Shlaer & Mellor（データモデリング志向）:
  クラスという抽象概念よりも「現実世界のオブジェクト(実体)」を重んじる傾向があります。「継承」や「全体-部分」といった構造も、リレーショナルデータモデルのように「関連付けオブジェクト」という均質な関係性で表現しようとする特徴があります。
• Booch(豊かなモデル表現・設計志向):
  「フィールド」や「using関係」といった、プログラミング言語(特にC++やAda)の実装やメモリ配置を意識しやすい用語が見られます。単なる設計特化というわけではなく、システムを精緻に表現するための極めて豊かな語彙を持っていた手法です。

5.2. 仕様化プロセスの違い：オブジェクトを見つけた「次の一手」

オブジェクトを検出した後にどのような手順でモデリングを進めるか(仕様化プロセス)にも、各手法の個性が見られます。

図：3大手法の仕様化プロセス

手法	第一歩(構造の定義)	次のステップの傾向
Shlaer & Mellor	1. オブジェクト検出 2. [属性]の定義	まずオブジェクトの中身(属性)を定義し、オブジェクト仕様書を固めてから階層や関連を定義していく、堅牢なボトムアップ的アプローチ。
OMT	1. オブジェクト検出 2. [関連]の定義	オブジェクトを見つけたら、まず名詞同士の「つながり(関連)」を優先して結び、全体のコンテキストを定義するアプローチ。
Coad & Yourdon	1. オブジェクト検出 2. [構造]の定義	発見後、即座にGen-Spec(継承)やWhole-Part(集約)といった構造に落とし込む。オブジェクト指向言語とのマッピングが直感的なアプローチ。

5.3. ドキュメント体系と各手法の「特徴と課題」

システムを「構造(静的)」「関連(動的)」「メソッド(機能)」の3つの視点からどう文書化するか。当時の比較表から、それぞれの強みと課題が浮き彫りになります。

図：4大手法の特徴と課題(要約)

手法	強い特徴と評価された点	当時の主な課題
Shlaer & Mellor	オブジェクトの関係表現が豊富。ドキュメント体系(情報構造図など)が非常にしっかりしている。	メソッド表現が弱く、オブジェクト指向設計(OOD)への繋がりが明確になりにくい。
OMT	動的モデル(Statechartの採用など)の構築手順が確立しており、分析〜設計の統合性が高い。	手法の習得コストが高く、分析フェーズの充実に比べると設計フェーズの記述が相対的に弱い。
Coad & Yourdon	言語ベースの意味モデルであり、OODへの繋がりがスムーズ。プロセスが軽量で自由度が高い。	動的モデルの表現がシンプルであるため、複雑なシステムの仕様化においては具体性に欠ける面がある。
Booch	主要な言語をカバーし、設計・実装に必要なほとんどの図(クラス図、タイミング図など)を描ける表現力。	仕様化(分析)のプロセスが明確に規定されておらず、分析フェーズのサポートが薄い傾向がある。

※注釈：OMTの動的モデルが高く評価された背景には、デヴィッド・ハレルが提唱した「Statechart(状態遷移図)」をいち早く取り入れた事実が大きく寄与しています。

5.4. 歴史的結末：UMLという「標準化」への道

これらの手法は、最終的に**UML(Unified Modeling Language)**という一つの規格へと収束していきます。

しかし、これは「優れたものが自然に残った(進化論)」という単純なストーリーではありません。1990年代後半、オブジェクト指向技術の普及に伴い、ツールベンダーや開発現場から「表記法(モデリング言語)の統一」を求める強い産業的・市場的要経が高まりました。

その結果、OMG(Object Management Group)による標準化プロセスのもと、主要な手法の提唱者たち(スリーアミーゴスと呼ばれるジェームズ・ランボー、グラディ・ブーチ、イヴァー・ヤコブソン)がRational社に結集します。

• OMT手法 からは「オブジェクト図」や「Statechart」といった統合的なビューを。
• Booch手法 からは、設計フェーズに耐えうる表現力豊かな「クラス図」などの記法を。
• (本記事には未登場ですが)OOSE手法 からは「ユースケース」の概念を。

UMLは、各手法が持っていた「強い特徴」を産業的な合意のもとで統合し、標準言語として策定されたという歴史的背景を持っています。

5.5. まとめ

「オブジェクト指向分析・設計」とは、決して単一の正解があるわけではなく、「分析(現実世界をどう捉えるか)」「設計(構造をどう整理するか)」「実装(言語にどう落とし込むか)」のどこに比重を置くかによって姿を変えるアプローチ群です。

当時の手法が抱えていた「現実世界の複雑な関連をどう表現するか」「動的な振る舞いをどう可視化するか」という悩みは、現代のドメイン駆動設計(DDD)やクリーンアーキテクチャの実践においても、依然として私たちエンジニアに問いかけてくる本質的なテーマだと言えるでしょう。

6. 「木」に固執するリスクと「森」の視点

​しかし、西洋的な「木を見る(個を見る)」視点だけでは、優れたシステムは構築できません。ここで重要になるのが、東洋的な「森を見る(関係性を見る)」視点です。
​エンジニアがしばしば陥る罠に、クラス単体の設計(木)に完璧を求めるあまり、システム全体の「相互作用(森)」を見失うというものがあります。
​木を見る設計： クラス図は美しいが、各オブジェクトがどう連携してビジネスロジックを実現するかが見えていない。
​森を見る設計： シーケンス図を重視し、オブジェクト間のメッセージングの流れを最適化する。
​優れたオブジェクト指向設計とは、西洋的な「厳格な個の定義」を行いながら、同時に東洋的な「コンテキスト(文脈)と場の把握」を両立させることにあるのではないでしょうか。

​7. 結び：二つの視点を行き来する

​オブジェクト指向設計は、西洋哲学の「実体論」という強力な武器をソフトウェアの世界に持ち込みました。
​しかし、真に柔軟で堅牢なシステムを作るためには、西洋的な「分析」によって切り分けられたパーツを、東洋的な「統合」の視点でもう一度繋ぎ合わせる必要があります。マグロが酸素を取り込むために独自の睡眠をとるように、あるいは鳥が飛ぶために排泄の仕組みを特化させたように、オブジェクトもまた、置かれた環境(コンテキスト)との関係性の中でその振る舞いを決定します。
「木」を定義し、「森」を描く。
この二つの認知モードを自覚的にスイッチすることこそが、アーキテクトに求められる真のメタ認知スキルであると私は考えます。

8. なぜ、今、記事を書いたのか？Anthropic Mythosへの期待

OOPを正確に理解する為には3年(ただし、実践者に従えば3ヶ月)が必要とします。『UMLによるオブジェクト指向モデリング セルフレビューノート』(ISBN 4886487440)(P.155)に記載されたとおりです。その間いろいろなところで論争が巻き起こっており、その流れに乗りたくなかった、心の疲弊を防いだのです。時代は変わりました、現在のAIでもある程度の精度で評価できるようになりました。私はAIに鋭い問いを繰り返しました、そして、この文章を作成することができました。状況は落ち着いたと考え記事を書いてみました。そして、Anthropic Mythosです。Anthropic Mythosは検証型AIです、彼がどのような構造なのかを解析してもらうのがいまから楽しみです。

9. 私が本当に欲しかったもの

オブジェクト指向を学び始めてから、私は本位田さん、山城さんがまとめられたオブジェクト指向方法論の著書、アンディさん、五十嵐さんがまとめられたオブジェクト指向方法論の著書を見る機会がありました。

その比較表から感じたのは、「どの方法論も完璧ではない」ということです。それぞれに長所と短所があり、得意とする対象も異なっていました。

一方で、当時主流だった手続型開発にも、システムの大規模化や複雑化に対応する限界が見え始めていました。だからこそ、多くの研究者が新しい方法論を提案し続けていたのだと思います。

私は自然に、「では、どうすればもっと良い方法論になるのだろう」と考えるようになりました。

しかし、そのような議論をしようとしても、現実にはなかなかできませんでした。

• 「この手法が標準だから」
• 「○○先生が提唱した方法だから」
• 「昔からこうしているから」

という空気があり、さらに専門家やコミュニティの門を叩いても、十分な議論ができる機会はほとんどありませんでした。

私が知りたかったのは、「どの方法論が正しいか」ではありません。

「別の方法論の長所を取り入れれば、もっと良くできないのか。」
「入手できない方法論はどんな長所があるのか。」
「分析設計の妥当性の指標は何か？」

そうした議論です。

最近、1980年代から1990年代初頭のオブジェクト指向方法論を調べ直してみると、当時はCoad&Yourden法、booch法、OMT法、Shlaer Mellor法、OOSE法、など、多くの方法論が提案されていました。また、分析(OOA)、設計(OOD)、プログラミング(OOP)だけでなく、見積り、品質評価、要求工学など、さまざまな方向から研究が行われていました。

オブジェクト指向は最初から完成されたものではなく、多くの研究者が議論し、試行錯誤しながら発展させてきた技術だったのです。

そして、ようやく気付いたことがあります。

私が求めていたのは「答え」ではありませんでした。

一緒に考え、反証し、改善案を検討できる相手だったのです。

現在は生成AIの登場によって、その環境が大きく変わりました。

ChatGPT、Gemini、Grok、Claudeなど、それぞれ異なる視点を持つAIと対話し、自分の仮説を検証したり、反証を求めたり、文献を整理したりできます。

もちろん、最終的な判断は人間が行う必要がありますし、AIの回答も鵜呑みにはできません。しかし、「この考え方に穴はないか」「別の視点はないか」と何度でも議論できる環境が、個人にも手に入るようになりました。

振り返ると、私が本当に欲しかったのは「最適な方法論」ではなく、「方法論をより良くするために自由に議論できる環境」だったのだと思います。DDDの理解も進めようと思います。

10. オブジェクト指向方法論の使い分け

10.1. はじめに

オブジェクト指向分析・設計には、多くの方法論が存在します。
代表的なものとして、

• Booch法
• OMT法(Object Modeling Technique)
• OOSE法(Object-Oriented Software Engineering)
• Coad/Yourdon法
• Shlaer–Mellor法
• MERODE法

などがあります。
これらは競合するものではありません。
それぞれが得意とする問題領域が異なります。
重要なのは、「どの方法論を採用するか」ではなく、
現在直面している問題を解決するために、どの考え方を利用するか
です。

---

10.2. 要件が不明確な場合

システムを作る前に、利用者が何を求めているのか不明な場合があります。
この状態でクラス図を作成すると、開発者の想像によるモデルになりやすくなります。
この場合は、要求分析を重視します。

適した考え方

• OOSE法
• ICONIX Process(開発プロセス)

代表的な手法：

• ユースケース図
• シナリオ分析

利用者がシステムをどのように利用するのかを整理し、システム境界を決定します。

---

10.3. 問題領域の構造を明確化したい場合

対象領域に存在するオブジェクト、その属性、サービス、関係を整理する場合は、オブジェクトモデルを中心に考えます。

適した考え方

• OMT法
• Coad/Yourdon法

利用するもの：

• クラス図
• オブジェクト図

ここでは、

• 何が存在するか
• どのような関連があるか
• どのオブジェクトがどの役割やサービスを担当するか

を明確にします。
OMT法では、

• Object Model
• Dynamic Model
• Functional Model

の3つの視点から問題領域を分析します。

---

10.4. オブジェクトの責務や協調を設計したい場合

クラスが存在しても、それだけではシステムは動きません。
オブジェクト同士がどのように協調するかを確認する必要があります。

適した考え方

• Booch法

利用するもの：

• シーケンス図
• コミュニケーション図(旧コラボレーション図)

Booch法は、オブジェクト指向設計において、クラスやオブジェクトの構造、オブジェクト間の協調、設計の詳細化を重視します。
「どのオブジェクトがどの責務を担当するべきか」
を検討するのに適しています。

---

10.5. 問題領域を厳密に分析したい場合

問題領域の概念を深く分析し、安定したモデルを作成したい場合があります。

適した考え方

• Shlaer–Mellor法

特徴：

• 情報モデル
• 状態モデル
• プロセスモデル

問題領域を情報モデル・状態モデル・プロセスモデルとして整理し、それらを統合してモデル化する方法論です。
デザインパターンそのものはオブジェクトではないが、発明オブジェクトを設計するための知識・型として捉えられます

---

10.6. イベント中心でモデル化したい場合

イベントやオブジェクトのライフサイクルからモデル化したい場合があります。

適した考え方

• MERODE法

特徴：
イベントを中心として、

・オブジェクトモデル
・ライフサイクルモデル
・プロセスモデル

を構築し、オブジェクト間の関係、状態変化、イベントによる振る舞いを統合して分析します。
補足：
問題領域を中心にモデル化するという考え方は、DDD(Domain-Driven Design)にも通じる部分があります。

---

10.7. オブジェクト指向を学ぶための方法論

オブジェクト指向分析・設計を学ぶ場合、実際の開発方法だけでなく、オブジェクトをどのように発見するかを学ぶための方法もあります。

適した考え方

• CRCカード法
• Coad/Yourdon法

特徴：
CRCカード法は、クラス(Class)、責務(Responsibility)、協調(Collaborator)をカードに記述し、オブジェクト同士の協調を考える方法です。
オブジェクトの責務と協調を実際に考えながら、オブジェクト指向の基本的な考え方を学ぶことができます。

Coad/Yourdon法では、要求文などから名詞句・動詞句を抽出し、それらを手掛かりとしてクラス候補やサービス候補を発見します。
名詞句は、分析の過程でクラス、属性、属性値、不要な情報などに分類されます。また、動詞句については、動作主体、動作対象、間接目的語などを整理し、クラス候補やサービス候補を検討します。
さらに、クラス候補を抽出する際には、装置、組織体、場所、記録すべき事象、役割、操作手続き、他のシステムなどの観点も利用します。
ここで重要なのは、名詞句をそのままクラスにするわけではないことです。
名詞句や動詞句は、あくまでクラスやサービスを発見するための手掛かりです。
そのため、Coad/Yourdon法は、
「要求文から、どのようにオブジェクトを発見するのか」
を学ぶ方法としても利用できます。

補足：Coad/Yourdon法はオブジェクトの発見方法を学ぶ上で有用ですが、大規模開発では、モデルの分割やチーム間の整合性など別の課題が生じるため、単独で開発全体を支える方法としては限界があります。
補足：CRCカード法は、オブジェクトの責務や協調を体験的に学ぶ教育に適しています。一方、大規模開発の設計やデザインパターンの体系的な説明には向いていません。

---

10.8. 実際の設計では組み合わせる

実際の開発では、一つの方法論だけを使用することは少なくなっています。
例えば、
要求整理：

OOSE
 ↓
ユースケース

概念整理：

OMT
 ↓
オブジェクトモデル・動的モデル・機能モデル

責務確認：

Booch
 ↓
オブジェクト設計・相互作用モデル

問題領域分析：

Shlaer–Mellor
MERODE
 ↓
問題領域の理解・モデル化

というように、それぞれの強みを利用します。

---

10.9. まとめ

オブジェクト指向方法論は、どれが最も優れているかを競うものではありません。
重要なのは、
「現在、何が分かっていないのか」
を判断することです。

• 利用者要求が不明なら OOSE法
• 構造を整理したいなら OMT法
• オブジェクト間の責務や協調を検討するなら Booch法
• 問題領域を厳密にモデル化するなら Shlaer–Mellor法
• イベント中心でオブジェクトモデルを分析するなら MERODE法

というように、問題に合わせて方法論を選択することが、効果的なオブジェクト指向分析につながります。

補足：
OMTでは、分析・設計したモデルを、当時広く利用されていた非オブジェクト指向言語へ実装するための考え方も示されています。
これは、オブジェクト指向分析と実装環境を分離して考えるという、当時の実用的な設計思想を反映しています。

11. クラスを発明してはいけない？――値・制御・管理・不確定クラスをめぐる方法論

オブジェクト指向では、「何をクラスにするか」が重要である。

しかし、ここには一つの危険がある。

クラスを作ることそのものが、設計になってしまうことだ。

「これは名詞だからクラスにしよう」

「これはデータだからクラスにしよう」

「処理が多いからControllerにしよう」

「いろいろ管理するからManagerにしよう」

こうしてクラスを増やしていくと、いつの間にか「現実をモデル化している」のか、「クラスを増やしている」のか分からなくなる。

ここでは、その中でも特に注意したい4種類を取り上げる。

• 値クラス
• 制御クラス
• 管理クラス
• 不確定クラス

ただし、これは「この名前のクラスを絶対に作ってはいけない」という意味ではない。

重要なのは、

«そのクラスを作ることによって、何が明確になったのか説明できるか»

である。

---

11.1. 値クラス――ただのデータ入れになっていないか

値クラスとは、複数の値をまとめて保持するためだけのクラスである。

例えば、

UserData
Parameter
Information
Configuration

などである。

これは一見するとオブジェクト指向らしい。

しかし、

Data
  ↓
Controller
  ↓
Manager

となった瞬間、問題が見えてくる。

データを持っているだけのクラスと、それを操作するクラスが完全に分離されているなら、実際には手続き型プログラムをクラスという箱に入れただけかもしれない。

したがって、古典的なオブジェクト指向設計では、「データだけを持つクラス」に対する警戒が存在する。

しかし、ここには現代的な例外がある。

AI開発では値クラスが重要になる

AI・機械学習では、

入力データ
特徴量
学習パラメータ
推論結果
バッチ
テンソル
データセット

など、大量のデータを一定の構造で受け渡すこと自体が重要になる。

このため、

値を構造化することそのものが設計上の意味を持つ場合、値クラスは有効である。

したがって、

「値クラスは禁止」

ではなく、

「意味のないデータ入れクラスを、オブジェクト指向であるかのように扱うことを警戒する」

とする方が正確である。

※ DTOは、JavaのWeb開発でGUIとモデルの間をデータとして橋渡しするために生じた、実装上の都合として扱う。
モデル、DTO、画面で同じデータを受け渡すことに意味があるのか、という議論はここでは問題にしない。
重要なのは、DTOをドメインモデルの「発見されたクラス」と同列に扱わないことである。
DTOはデータ交換のための構造であり、ドメインモデルとは役割が異なる。
したがって、本稿のオブジェクト発見の議論ではDTOを対象外とする。

---

11.2. 制御クラス――実は方法論によって扱いが違う

"Controller" や "Control" は、オブジェクト指向では非常に微妙な存在である。

なぜなら、

「処理を担当するオブジェクト」

とも、

「手続き型プログラムをクラスに押し込んだもの」

とも解釈できるからである。

ところが、ここで注意すべき方法論がある。

JacobsonのOOSE法や、そこから発展したEntity–Boundary–Controlの考え方では、Controlは正式なモデル要素である。

つまり、

Boundary
   ↓
Control
   ↓
Entity

という構造そのものが設計方法の一部になっている。

したがって、

「制御クラスはオブジェクト指向ではない」

と一刀両断することはできない。

ここではむしろ、

制御クラスを認める方法論と、責務を実体側へ移すことを重視する方法論が存在する

と理解する必要がある。

これは方法論比較の重要なポイントになる。

※ユースケース図でのユーザ目線を意識した設計思想が強いように思う

---

11.3. 管理クラス――「Manager」という名前に逃げない

一方で、"Manager" はかなり危険な名前である。

UserManager
DataManager
SystemManager
ObjectManager

と名付ければ、何でもクラスにできてしまう。

しかし、

UserManager
├─ ユーザー登録
├─ ユーザー削除
├─ ログイン
├─ 権限管理
├─ メール送信
├─ データベース操作
└─ ログ保存

となったら、それは「管理」という言葉で責務の曖昧さを隠しているだけである。

Riel系のオブジェクト指向設計ヒューリスティックでも、"Manager"、"System"、"Subsystem" のような名前を持つクラスや、責務が集中した巨大クラスには強い警戒が置かれている。

つまり、

Managerという名前を付ければ責務が成立するわけではない。

「何を管理するのか」ではなく、

「なぜこのオブジェクト自身が、その責務を持つのか」

まで説明できなければならない。

---

11.4. 不確定クラス――「何なのか分からないもの」をクラスにする

そして、最も厄介なのがこの問題である。

ここでいう「不確定」とは、単なる "Object" や "Thing" のことではない。

例えば、

• 幽霊
• 時間
• 文字

のような概念である。

これらは確かに人間の世界に存在する概念だ。

しかし、

「それは何なのか？」

と問うと、途端に問題が発生する。

例えば「時間」をクラスにすると、

時間
├─ 物理学的時間
├─ 歴史的時間
├─ 心理的時間
├─ 社会的時間
└─ 哲学的時間

となり得る。

「文字」なら、

文字
├─ 言語学
├─ Unicode
├─ 書体
├─ 表記体系
└─ 文字史

となる。

「幽霊」なら、

幽霊
├─ 民俗学
├─ 宗教学
├─ 歴史学
├─ 心理学
└─ 物語

となる。

ここで恐ろしいのは、クラスを作ったことで問題が解決するどころか、そのクラスを説明するための新しいクラスが必要になることである。

そして最終的には、

幽霊
 ↓
歴史
 ↓
歴史学
 ↓
学問
 ↓
人間
 ↓
社会
 ↓
世界

という具合に、モデルが世界そのものを説明し始める。

これが、ここでいう「不確定クラス」である。

---

11.5. ところがShlaer–Mellor法には「発明オブジェクト」がある

ここで、この禁止論を簡単に破壊する存在が登場する。

Shlaer–Mellor法の「発明オブジェクト(invented object)」である。

これは非常に重要である。

なぜなら、

「現実世界に存在するものだけをオブジェクトにする」

というルールを採用した場合、モデル上必要な概念を扱えなくなるからである。

そこでShlaer–Mellor法では、問題領域に物理的に存在するものだけではなく、モデルを成立させるために分析者が導入するオブジェクトを認める。

これによって、

「それは現実に存在するのか？」

という反論が通らなくなる。

例えば「時間」をモデル化したとして、

「時間という物体が現実に存在するのか？」

と問われても、

「物体として存在する必要はない。モデル上必要だから導入した」

と回答できてしまう。

これが発明オブジェクトの強さである。

※ただし、採用するにはかなりの説明が求められる

---

11.6. ここで「不確定クラス」「〇〇制御」「〇〇管理」の禁止が難しくなる

つまり、

現実に存在しない
        ↓
だからクラスにしてはいけない

という単純な禁止規則では、Shlaer–Mellor法には対抗できない。

むしろ、

現実には存在しない
        ↓
しかしモデル上必要
        ↓
だから発明する

という考え方が成立するからである。

ここで問題は一段深くなる。

「モデル上必要」とは何なのか？

である。

---

11.7. オブジェクト指向方法論は「世界を写す」のか、「モデルを作る」のか

ここに方法論の思想の違いが現れる。

現実世界をモデル化することを重視するなら、

「それは現実世界の何なのか？」

が重要になる。

しかし、モデルの内部で必要な概念を構築することを重視するなら、

「それはモデルの中で何の役割を持つのか？」

が重要になる。

Shlaer–Mellor法の発明オブジェクトは、後者を強く押し進める。

すると、

オブジェクトとは現実世界のコピーなのか、それともモデルの中で意味を持つ存在なのか？

という、オブジェクト指向そのものの問題に到達する。

---

11.8. AI時代には、この問題がさらに大きくなる

現在はAIに、

「このシステムをオブジェクト指向で設計してください」

と頼めば、簡単に大量のクラスが生成される。

User
UserManager
UserController
UserData
Time
Event
Entity
Information
Object

コードは動くかもしれない。

しかし、

なぜそのクラスが存在するのか？

という問いには答えられないかもしれない。

さらにShlaer–Mellor法の発明オブジェクトまで認めれば、

「必要だから発明しました」

という説明まで可能になる。

だからこそ、AI時代のオブジェクト指向では、単に

「クラスがあるか」

を見るのでは不十分である。

見るべきなのは、

そのクラスによって、モデルの何が明確になったのか。

である。

---

11.9. 「禁止」の意味を変える

ここまで考えると、4種類のクラスを単純に禁止することはできない。

値クラスはAI開発で有用である。

制御クラスはOOSE法やEBCで正式に認められている。

管理クラスは方法論によって強く警戒される。

そして不確定クラスには、Shlaer–Mellor法の発明オブジェクトという強力な対抗概念がある。

したがって、ここで禁止すべきなのはクラスの種類ではない。

禁止すべきなのは、

「クラスを作ったことを、設計したことと勘違いすること」

である。

クラスを作る。

なぜ作ったのか説明する。

そのクラスが担う責務を説明する。

他のクラスではなく、そのクラスでなければならない理由を説明する。

そして、必要ならば、

「このクラスを削除したら、モデルの何が失われるのか？」

と問う。

この問いに答えられないクラスは、たとえコードが動いていても、設計上の存在理由が弱い。

---

11.10. まとめ

オブジェクト指向の難しさは、

「何をクラスにするか」

ではない。

本当に難しいのは、

「何をクラスにしないか」

である。

そしてShlaer–Mellor法の発明オブジェクトは、この問題をさらに難しくする。

現実に存在しないものまでモデルに導入できるからだ。

だから最終的な判断基準は、

現実に存在するか。

でもなく、

名詞として存在するか。

でもなく、

発明できるか。

でもない。

「そのクラスを導入することによって、モデルの何が明確になるのか。」

この一点を問い続ける必要がある。

AIがクラスをいくらでも生成できる時代になった今、この問いは以前よりも重要になっている。

12. デザインパターンはいろいろな問題をあらわにした

オブジェクト指向では、クラスにデータと振る舞いをまとめることが基本になる。

しかし、実際にシステムを設計していくと、それだけではうまく表現できない問題が現れてくる。

そこで登場したのが、デザインパターンである。

デザインパターンは、オブジェクト指向の便利な使い方を整理したものともいえる。

しかし、別の見方もできる。

それは、オブジェクト指向で設計を行う中で繰り返し現れた問題を、パターンとして名前付けすることで、その問題そのものを明らかにしたものだという見方である。

Adapterは「継承か移譲か」をあらわにした

例えば、Adapterパターンである。

Adapterでは、既存のクラスを別のインターフェースから利用できるようにする。

ここで興味深いのは、同じ目的を実現するために、継承と移譲という異なる設計方法が存在することである。

継承によって既存クラスの機能を利用することもできるし、別のオブジェクトを保持して、そのオブジェクトへ処理を移譲することもできる。

つまりAdapterは、

「継承か、移譲か」

という設計上の選択を表面化させたパターンとも見ることができる。

「継承よりコンポジション」という考え方によって、移譲が好まれる場面は増えた。

しかし、それは「継承という仕組みが存在しなかった」という話ではない。

むしろ、同じ問題に対して、

継承で解決するのか、移譲で解決するのか

という選択肢が存在することを、Adapterという具体的なパターンが分かりやすく示している。

Factory Methodは「クラスと動作」の関係をあらわにした

もう一つ、Factory Methodを見ると、さらに興味深いことが分かる。

Factory Methodでは、オブジェクトを生成するという「動作」をメソッドとしてクラスに持たせる。

つまり、クラスは単純に「もの」を表現するだけのものではない。

一つのクラスが、自身の状態を変更する動作を持ちながら、同時にオブジェクトの生成方法を表すFactory Methodを持つこともできる。

ここでは、

• 「もの＝クラス」
• 「動作＝別クラス」

という単純な対応にはなっていない。

もちろん、生成処理をFactoryクラスなどの別クラスへ分離することもできる。

しかし、Factory Methodという設計が存在すること自体が、ある動作を必ず別クラスへ分離しなければならないわけではないことを示している。

デザインパターンを見ていくと、オブジェクト指向における「クラス」「オブジェクト」「動作」「責務」の関係が、決して単純なものではないことが見えてくる。

RUPで考えると、さらに見方が変わる

ここで重要になるのが、RUP(Rational Unified Process)のような開発プロセスにおけるモデルの段階である。

ここでは、RUPそのものの厳密な定義としてではなく、私自身が理解しやすいように、モデルの詳細化を段階として整理してみる。

最初から実装と同じ細かさのクラス図を描くのではなく、分析・設計を進めながら、モデルを徐々に具体化していく。

例えば、次のように整理できる。

層	モデルの役割	対応するパターン
1層目	要求・ユースケース	分析パターン
2層目	業務・ドメインの構造	ビジネスパターン
3層目	システム全体の構造	アーキテクチャパターン
4層目	実装に近い詳細設計	デザインパターン

この4層という区分そのものが重要なのではない。

重要なのは、モデルには粒度があるということである。

2層目や3層目では、一つの「もの」として扱っているものが、詳細設計では複数のクラスに分割されることがある。

例えば分析段階では、

「注文」

という一つのものとして考えていたものが、詳細設計では、

• Order
• OrderFactory
• Adapter
• Repository

など、複数のクラスとして具体化されることがある。

だからといって、分析段階で「Order」という一つのクラスとして考えていたことが間違いだった、とはならない。

モデルの粒度が違うからである。

これは、クラス分離について議論するときに非常に重要な点だと思う。

2層目や3層目のモデルに対して、4層目で初めて必要になるようなデザインパターンの細かなクラス構造を要求すれば、当然、モデルは過剰に細分化される。

逆に、詳細設計の段階であれば、Adapterにおける継承と移譲の選択や、Factory Methodによる生成処理などを具体的に記述する意味が出てくる。

つまり、

「クラスをどこまで分離するべきか」

という問いには、

「どの段階のモデルについて言っているのか」

という問いもセットで必要になる。

デザインパターンは、オブジェクト指向の完成された設計規則というより、実際の設計で繰り返し発生する問題と、その問題に対する典型的な解決方法を名前付けしたものとして見ることができる。

そして、その細かな構造が最も意味を持つのは、実装に近い詳細設計の段階である。

そう考えると、分析段階の「もの」と、詳細設計でデザインパターンを適用したクラス構造を、同じ粒度で比較することには注意が必要になる。

ここで注意したいのは、分析モデルで発見した「もの」と、最終的な実装コードにおけるクラスが、一対一に対応するわけではないということである。

---

現実世界をモデル化するということ

オブジェクト指向について語るとき、「現実世界のものをクラスとして表現する」という説明がよく登場する。

しかし、ここには一つ注意が必要だ。

現実世界を観察して得られるものは、単なる「分類」だけではない。

生物を観察すれば、そこには個体があり、器官があり、状態があり、他の個体との関係があり、そして、その関係の中で営みが行われている。

発見オブジェクト

このことを考える上で、Shlaer–Mellor法は興味深い。

先ほどのモデルの詳細化について述べたように、分析や設計は、最初から完成された構造を決め打ちすることではない。

対象領域を観察し、そこに存在するものや関係を発見しながら、モデルを具体化していく活動でもある。

例えば、カマキリを観察する。

最初は「カマキリ」という一つの生物として見ていたものが、詳しく観察すると、脳、身体、口、消化器官、獲物など、さまざまな対象が見えてくる。

つまり、観察の解像度を上げることで、新しい「もの」が発見される。

私は、こうしたものをShlaer–Mellor法でいう発見オブジェクトとして捉えている。

重要なのは、発見されたオブジェクトが、最初から完成されたモデルとして存在しているわけではないことである。

観察する。

仮説を立てる。

さらに観察する。

すると、それまで一つのものとして扱っていた対象の内部に、別のオブジェクトや関係が見えてくる。

これは、学問におけるモデルの発展にも似ている。

自然を観察していくと、最初のモデルでは説明できなかった現象が現れ、その現象を説明するためにモデルそのものが変化していく。

オブジェクト指向の分析モデルも、これに似ている。

「最初に正しいクラスを全部決める」のではない。

観察することで、モデルが変化していくのである。

しかし、生命には「もの」だけではない

ここで、もう一つ重要なものが見えてくる。

生命を観察すると、そこには「もの」だけではなく、営みがある。

例えば、クマノミの群れを考えてみる。

クマノミは、単純に「オス」と「メス」という個体を並べただけでは、その生態を十分に説明できない。

群れの中には役割があり、その役割を担う個体が存在する。

そして、群れの状態が変化すると、個体の役割も変化する。

メスがいなくなると、群れの中の個体の関係が変化し、それに応じて最大のオスがメスへ性転換する。

ここで重要なのは、

個体の属性だけではなく、群れという関係の中で、個体の状態や役割が変化していく

ということである。

これは、「Animal → Mammal → Dog」のような分類とは異なる。

分類ではなく、関係と変化と営みである。

生命の営みとデザインパターン

このように生命を観察していくと、ソフトウェアのデザインパターンと似た構造が見えてくる。

例えば、一つのオブジェクトや個体の状態が変化し、その変化によって周囲のオブジェクトや個体の行動が変化するとする。

これをソフトウェアとして表現すれば、

        群れ
         │
    状態・役割の変化
         │
    ┌────┴────┐
    ↓         ↓
  個体A      個体B
    │         │
  行動       行動

という構造になる。

このような「一つのオブジェクトの状態変化を他のオブジェクトへ伝え、それぞれが反応する」という構造は、Observerパターンによって表現できる。

また、複数のオブジェクトの間に調整役となるオブジェクトを置き、相互作用を仲介させるのであれば、Mediatorパターンとして表現することもできる。

もちろん、クマノミの生態がそのままObserverやMediatorパターンだと言っているのではない。

そうではなく、

生命の営みを観察すると、オブジェクト同士の協調、状態変化、役割分担、情報の伝達といった、ソフトウェア設計でも繰り返し現れる構造が見えてくる

ということである。

そしてデザインパターンは、そのような構造をソフトウェアの中で扱うための一つの抽象化なのである。

「現実世界をクラスにする」の先へ

ここまで考えると、「現実世界のものをクラスにする」という説明だけでは、オブジェクト指向の一面しか説明していないことが分かる。

現実世界には、

• 発見される「もの」がある
• もの同士の「関係」がある
• ものには「状態」がある
• 状態が変化する
• 他のものと協調して「営み」が行われる
• 観察が進めば、モデルそのものも変化する

という構造がある。

Shlaer–Mellor的な分析は、観察を通して「何が存在するのか」を発見する。

そしてデザインパターンは、発見されたオブジェクトが、どのように協調し、どのように営みを実現するのかを、繰り返し現れる構造として扱う。

だから、

現実世界をモデル化する
↓
現実世界の分類を、そのままクラス階層にする

と考える必要はない。

むしろ、

観察する
↓
発見オブジェクトが現れる
↓
関係や状態や営みが見えてくる
↓
モデルが変化する
↓
繰り返し現れる構造を抽象化する
↓
デザインパターンとして実装する or クラスを壊して、クラスを発明する

という流れで考えたほうが、オブジェクト指向の「モデル化」と「設計」は自然につながるのではないだろうか。

現実世界の分類をコードに写すことが、オブジェクト指向のすべてではない。

観察によって世界の構造を発見し、その構造の中で行われている営みをモデル化し、必要に応じて抽象化していく。

その過程そのものに、オブジェクト指向の面白さがある。

---

---

ある一つの注目点：昔話

昔話は認知モデルの化石なのか？

最近、「東洋人は森を見て、西洋人は木を見る」という認知の違いについて考えていました。
しかし、「東洋」「西洋」という言葉だけでは少し曖昧です。
そこで、各地域で語り継がれてきた昔話を観測してみることにしました。
ここでの目的は文化の優劣を論じることではありません。
昔話には、その社会が子供たちに伝えたかった価値観が残っているのではないか。
その仮説を観測してみます。

観測方法

今回は以下の二点に注目しました。

• 主人公はどのような人物か
• 最後に何が守られるのか

観測結果

文化圏	主人公	最後に守られるもの
日本	普通の人	共同体
中国	賢者・修行者・官僚	秩序
ヨーロッパ	王子・英雄	個人の成功
アフリカ	動物・共同体の一員	生存知識
アメリカ	開拓者・挑戦者	挑戦と開拓

日本

桃太郎、浦島太郎、鶴の恩返しなどでは、特別な英雄よりも普通の人が主人公になることが多く見られます。

そして最後に守られるものは個人の成功よりも、

• 村
• 家族
• 約束
• 恩

といった共同体の安定です。ただし、日本はその他の外国と違い、外国の昔話も積極的に読まれているという疑問も同時に存在します。

中国

西遊記や白蛇伝などを見ると、

• 修行
• 知恵
• 秩序

が重要な役割を果たします。

個人の勝利というより、
社会や世界の秩序が回復されることが結末になりやすいように見えます。

ヨーロッパ

シンデレラやジャックと豆の木などでは、

• 試練
• 冒険
• 成長

が中心になります。

最後には主人公自身の成功が描かれます。
共同体よりも個人の物語として読むことができます。

アフリカ

アナンシの物語などでは動物が頻繁に登場します。

重要なのは強さではなく、

• 知恵
• 工夫
• 生き残る方法

です。

物語は共同体の中で生きるための知識を伝える役割を持っていたのかもしれません。

アメリカ

アメリカの民話には、

• ポール・バニヤン
• ペコス・ビル
• ジョニー・アップルシード

などがいます。
彼らは王子ではありません。
開拓者です。
物語の中心にあるのは、

• 新しい土地を切り開く
• 困難へ挑戦する
• 自力で道を作る

という価値観です。

本当に東洋と西洋なのか？

ここで一つ疑問があります。

私は日本人ですが、

• ジャックと豆の木
• シンデレラ
• アラジン
• 西遊記

を知っています。

つまり現代人は一つの文化だけで育っているわけではありません。

むしろ複数の文化圏の認知モデルを同時に学習しているとも考えられます。

まとめ

昔話を観測していて思ったのは、

昔話は娯楽であると同時に、その社会が子供たちへ伝えたかった価値観の保存装置なのではないか、ということです。

もしそうであれば、

昔話は単なる物語ではありません。

その文化の認知モデルが化石として残ったものなのかもしれません。

もちろんこれは一つの仮説です。

しかし、昔話を並べてみると、文化ごとに主人公や結末の傾向が異なって見えるのは興味深い観測結果でした。

もう一つの注目点：ゲームでも見える東洋・西洋の違い ― 主人公・関係性・選択肢の観測フレーム ―

本記事は文化論の断定を目的としません。
また「東洋と西洋はこう違う」という単純化を結論とするものでもありません。

ここでやるのはあくまで一つの試みです。

ゲームという共通フォーマットを通して、
東洋・西洋で“強く出やすい設計思想の違い”を観測できるか？

という問いです。

評価ではなく観測として整理します。

観測フレーム

以下の6軸でゲームを見ます。

項目	意味
主人公	プレイヤーは誰として扱われるか
仲間	関係性が中心か
敵	明確な敵か、構造的問題か
守るもの	何が動機になるか
自由度	選択肢の広さ
結末	収束型か分岐型か

Atari・初期アーケード

Asteroids
Missile Command

項目	観測
主人公	ほぼ存在しない、つまりプレイヤー
仲間	なし
敵	明確(物体・弾)
守るもの	生存・スコア
自由度	低い
結末	スコア更新

観測

この段階では「物語」というより、
行動そのものをゲーム化している
段階に見えます。

日本RPG系の観測

Dragon Quest
Final Fantasy IV
Mother

項目	観測
主人公	固定人物
仲間	非常に重要
敵	明確
守るもの	世界・日常
自由度	低〜中
結末	収束型(物語完結)

観測

共通して目立つのは
仲間(関係性)の比重が非常に大きい
という点です。
戦闘や目的よりも、「誰と旅をするか」が設計の中心にあります。

欧米RPG系の観測

Ultima IV
Wizardry
Fallout
Baldur's Gate

項目	観測
主人公	プレイヤー主体・作成型
仲間	補助〜重要
敵	明確よりも構造的・複雑
守るもの	生存・倫理・自己
自由度	高い
結末	分岐型(選択依存)

観測

特徴的なのは
プレイヤーの選択そのものが中心にある
という点です。
「誰と仲間になるか」よりも
「どう行動するか」の比重が大きい傾向があります。

任天堂系(設計思想として別軸)

The Legend of Zelda: Breath of the Wild
Animal Crossing: New Horizons

項目	観測
主人公	固定 or プレイヤー
仲間	軽〜中
敵	ある場合とない場合が極端
守るもの	世界 / コミュニティ / 体験
自由度	極めて高い
結末	非固定(プレイ継続型)

観測

ここでは物語よりも
遊びそのものの設計
が中心にあるように見えます。

比較まとめ

観測を横に並べると次のようになります。

軸	東洋RPG的傾向	西洋RPG的傾向
主人公	固定人物	プレイヤー主体
中心要素	関係性(仲間)	選択(意思決定)
敵	明確	構造的・曖昧
自由度	中程度	高い
体験	物語収束型	分岐・自己生成型

仮説(断定ではない)

この観測から言えるのは次のような仮説です。

東洋系のゲームは「関係性の設計」に比重が寄りやすい
西洋系のゲームは「選択と結果の設計」に比重が寄りやすい

ただしこれは傾向であり、例外は多く存在します。

重要な例外

例外はむしろ本質を示します。

The Legend of Zelda → 日本だが高自由度
Wizardry → 欧米だが仲間重視
Minecraft → 国分類不能
Grand Theft Auto V → 物語と自由度の混合

おわりに

本記事は結論を出すものではなく、

ゲームという共通フォーマットを使った観測の試み

です。

重要なのは分類ではなく、

何を増やそうとしているか
何を中心に設計しているか
何をプレイヤーに体験させているか

という視点です。

東洋・西洋という二分法ではなく、
「設計思想の違いとして何が見えてくるか」を今後も観測していくことで、より精度の高いモデルが作れる可能性があります。

観察者として

私は長い間、オブジェクト指向やUMLを観察してきた。
今は
「なぜ人によって理解が違うのか」
を観察している。
同じ本を読んでも解釈は異なる。
同じ技術を学んでも重視する点は異なる。
ある人はコードを見る。
ある人は設計を見る。
ある人は組織を見る。
ある人は顧客を見る。
それぞれが見ているものは違う。
そして、その違いは必ずしも誤りではない。
経験した成功や失敗によって、見える景色が変わるからである。
私は以前、それを教義化と呼んでいた。
しかし最近は少し違うのではないかと思い始めている。
人は教義を守っているのではなく、
その教義の奥にある何かを守っているのではないか。
成功体験かもしれない。
組織の安定かもしれない。
責任の所在かもしれない。
あるいは調和かもしれない。
ここで私は別の問いにたどり着いた。
知恵とは何だろうか。
知識なら本に書ける。
技術なら学習できる。
しかし知恵は少し違う。
同じ知識を持ちながら、異なる判断をする人がいる。
その差はどこから生まれるのだろう。
私はもう答えを急がないことにした。
歴史を見れば、人間の認識が変わるには長い時間がかかる。
世代が変わることもある。
環境が変わることもある。
そして本人が変わることもある。
今の私は、何かを証明する人ではなく、観察する人でありたい。
観測し、考え、議論できる場を増やしたい。

発見

・DDDはシステムよりの考え方

・テーブルマナーや離席の東洋と西洋

地域	マナー
西洋、低額	先に支払い？？？
西洋、高額	後払い、離席時にハの字を作る
日本	利便性重視？
日本＋離席	私物があるかどうか？ 時間がどのくらい経過？

・あいさつで東洋と西洋と犬と猫

動物	あいさつ
犬	けつの匂いをかぐと急にだまる？ (すべてを理解する？)
西洋	簡素、疎通確認？？？
東洋	状態の通知、状態や連絡？？？
猫	視覚と鼻の突き合わせ？？？

・昆虫を食べる植物と普通の植物と海の植物

植物	特徴
昆虫を食べる植物	土の栄養が足りないため捕食？？？ 関節は筋肉がつかず使い捨て？
普通の植物	光合成、土から水分
海の植物	？？？一部のサンゴに足がある？？？

今の問

・動物の食事の頻度
・猫の目
・トカゲ
・タコ
・オジキソウ
・ラフレシア
でChatGPTと議論をしています

​執筆協力：Gemini, ChatGPT

---

もし歴史認識に誤りがある部分があれば、出典を示していただけると修正検討します。

---

この仮説はいずれ崩れるだろう。

それでいい。

仮説が崩れたこと自体は、問題ではない。
むしろ、そこから新たな問いが生まれたのなら、それは前進である。

多くの問いが、多くの学問を押し上げてきた。
最初の説明が永遠に正しかったからではない。
説明が崩れ、その先に新しい問いが生まれたからだ。

だから、私の仮説を「正しい」「間違っている」と決めつけるだけで終わらないでほしい。

もし間違っているというのなら、
その先に何があるのかを問うてほしい。

仮説を壊すことよりも、
壊したあとに何も問わないことのほうが、私は問題だと思う。

上に続く階段への問いを、探してほしい。

---

松ごっつで全部の自分の意見に「違うか〜」あれがりそうですね〜

---

？？？もしかして自分でも管理できなきなってる？？？

---

参考文献

リチャード・E・ニスベット『木を見る西洋人、森を見る東洋人』

オブジェクト指向方法論の世界：比較と解説

ジョン・ラカメラほか『オブジェクト指向開発の落とし穴』

アリストテレス『カテゴリー論』

オブジェクト指向システム開発

オブジェクト指向入門 第2版 原則・コンセプト

オブジェクト指向入門 第2版 方法論・実践

UMLによるオブジェクト指向モデリング セルフレビューノート

［復刻版］オブジェクト指向ソフトウェア工学OOSE ――Use Caseによるアプローチ――

憂鬱なプログラマのためのオブジェクト指向開発講座

シュレイアー・メラー法によるオブジェクト・モデリング

UML2.0仕様書 2.1対応

Java言語で学ぶデザインパターン入門

増補改訂版 Java言語で学ぶデザインパターン入門 マルチスレッド編

オブジェクト指向方法論OMT モデル化と設計

オブジェクト指向プログラミング入門 第2版 新装版

新・標準プログラマーズライブラリ C++ クラスと継承 完全制覇