機能と存在の分離【迷走編】：オブジェクト指向の隠された2つの側面

※ この記事はnote.comの自作コンテンツの転載です。

機能と存在の分離【迷走編】：オブジェクト指向の隠された2つの側面

システム開発の現場で繰り返される「議論の迷走」。その根本原因は、私たちが「機能（Doing）」と「存在（Being）」という全く異なる2つの側面を、無自覚に混同していることにあります。

本連載では、この2つを明確に分離することで、堅牢なドメインモデルと柔軟なインターフェースを両立させる開発のあり方を考えていきます。第1回「迷走編」、第2回「構築編」、第3回「生命編」を通じて、システムに「実在感」を宿らせるための道筋を、読んでいただいたみなさんがイメージできれば、うれしく思います。

1. はじめに：開発現場の議論が噛み合わない理由

システム開発の現場で、機能追加や仕様変更の議論がいつまでも終わらず、空転してしまうことはありませんか？

「この画面にこのボタンが必要だ」という話が、いつの間にかデータベースのテーブル構造の議論に飛び火し、結局どちらも決まらない。こうした混乱の正体は、私たちがオブジェクト指向という言葉で「2つの異なる側面」を同時に語ってしまっていることにあります。

この2つを峻別しない限り、議論の迷走を止めることはできません。

2. オブジェクト指向の2つの側面

私は、オブジェクト指向を以下の2つの領域に分けて考えるべきだと考えています。

1. オントロジー（存在：Being）の側面

   「その世界には何があり、それぞれがどう関連しているか」という世界の記述。

2. インターフェース（機能：Doing）の側面

   「その世界を外側からどう操作し、どう覗き込むか」という振る舞いの抽象化。

【注釈】本連載における「機能」の定義
本連載では、「機能（Doing）」を 「利用者の目的達成（ユースケース）」 と定義し、内部的な「責務」や「処理」とは区別します。
これは、別記事『「機能」という言葉の物語』で触れた "Feature"（ユーザーへの提供価値） に相当するものです。
「機能」はあくまで外部との接点（インターフェース）であり、システム内部の構造（オントロジー）を「機能」単位で分割してはならない、という立場をとります。

イメージしやすい例：『Cities: Skylines』

この2つの違いは、都市開発シミュレーションゲーム『Cities: Skylines』で考えると非常に分かりやすくなります。

• オントロジー（Being）＝「シミュレーションの物理法則」
  ゲームの中では、プレイヤーが見ていようがいまいが、電気は電線を伝わり、市民は家と職場を往復し、車が道路を走り、交通量が増えれば渋滞が発生します。これは「世界がどうあるか」というルールそのものであり、画面の都合で勝手に曲げられてはいけない部分です。

• インターフェース（Doing）＝「プレイヤーのための操作パネル」
  一方で、プレイヤーが道路を敷いたり、幸福度グラフを見たりするのは「機能」です。これは、巨大なシミュレーション世界に干渉するための「窓」や「レバー」に過ぎません。

世の中の多くの議論では、この「世界の理（ことわり）」と「ユーザーへの見せ方」がごちゃ混ぜになっています。だからこそ、画面（機能）を変えようとするたびに、世界のルール（存在）が揺らいでしまうのです。

3. 「存在（Being）」を定義する：ドメイン分析の真髄

ここでいう「存在（Being）」を定義する作業は、一般に 「ドメイン分析」 と呼ばれます。

ドメイン分析において、最も重要な鉄則があります。それは、 「分析モデルの中にメソッド（操作）を入れない」 ということです。

なぜなら、メソッドとは「何かをすること（Doing）」であり、それは外部の都合によって決まるものだからです。

• 例： 銀行の世界において「口座がある」「入出金には必ず相手がいる」という関係性は、世界が成立するための不変のルール、つまり「存在」です。

• 一方で「残高をCSVで出力する」という手続きは、誰かがそうしたいという「機能」に過ぎません。

ドメイン分析とは、こうした「誰が何をしたいか」というノイズを一時的に排し、純粋に 「その世界は何によって構成され、何が不変のルールなのか」 という配線図を描き出す作業なのです。

【コラム】状態遷移と不変条件

Being（存在）の記述には、単なるデータの形だけでなく、 『状態がどのように遷移してよいか』という世界の規約（不変条件）』 も含まれます。

実装コード上では、これらはバリデーションなどの「メソッド」として記述されることが多いため、「やはりドメインモデルにもメソッドは必要ではないか？」と混同されがちです。しかし、これらは「世界を操作する機能（Doing）」ではなく、「世界の整合性を保つための不変条件（Being）」をロジックで表現したものです。操作（ユースケース）とは明確に区別する必要があります。

※このテーマについては、別の記事で詳しく解説します。

Cities: Skylinesに学ぶ「リアリティ」の所在

シミュレーションゲームのリアリティは、オントロジーの側に宿っています。どんなに凝ったユーザーインターフェースを備えていても、背後にある「世界の理」に納得性がなければ、嘘っぽくて熱中できないでしょう。

システムも同様です。画面がいかにリッチでも、背後のドメインモデル（存在）の挙動に整合性がなければ、ユーザーは無意識に「頼りなさ」を感じ取ります。システムに「実在感」を宿らせるのは、実は地味で目に見えないオントロジーの側なのです。

4. 結論：分けないと、開発は「迷走」する

「存在」を確立しないまま「機能」の議論を優先させてしまうと、システムは一貫性のない機能の「つぎはぎ」になってしまいます。

その結果、開発チームは「何が正しい仕様か」の拠り所を失い、迷走を始めます。機能（Doing）は、安定した存在（Being）の上にしか正しく構築できません。

次回の記事では、この「存在」の上に、どのように「機能の窓」を開けていくのか、その具体的な構成についてお話しします。