構造化設計からオブジェクト指向設計へ

～三回設計法に学ぶ責務分離の思想とその進化～

Copyright © 2025 LWP 山中 一弘 本資料は、出典を明記いただければ、商用・非商用を問わず、ご自由に複製・改変・再配布していただけます。なお、著作権表示は改変せず、そのまま記載してご利用くださいますようお願いいたします。

要約

本稿は、VBAなどの構造化言語における「トップダウン三回設計法（機能→データ→責務）」という現場的設計の知見を起点に、オブジェクト指向設計（OOP）、Clean Architecture、ドメイン駆動設計（DDD）、そしてデザインパターンなどが、これらの視点交代をいかに定型化し、初期設計から取り込んでいるかを体系的に論じるものである。

三回設計法では、まず操作手順に基づく処理が分割され、次に再利用性と意味に基づいて構造が整理され、最後に業務的な責務の意味をもとに再構成が行われる。OOPではこのプロセスがあらかじめ分離・設計されており、ユースケース駆動設計、クラスと関係の構造化、パターン適用、責務の層分離といった方法論がこの視点を初期から支える。特にDDDでは、「意味」に根ざした設計語彙と構造分離を通じて、設計行為を業務知の表現として昇華させる。

本稿では、構造化設計者の視点からOOPの思想と実践を橋渡しし、設計の繰り返しがどのように思想と手法へと成熟するのかを照射する。

1. はじめに：設計はなぜ繰り返され、そして成熟するのか

1.1 設計の繰り返しは学習と意味付けのプロセスである

設計は一度で完成するものではない。むしろ、最初の設計は不完全であることを前提とし、その後の試行錯誤を通じて構造が成熟していく。これは単なる修正の繰り返しではなく、対象に対する理解の深化と、それに応じた構造の再定義という意味づけの連続的プロセスである。

設計とは、与えられた要件に対し、どのような構造でそれを支えるかを決定する行為である。しかし現実の業務要件は、断片的で、あいまいで、ときに矛盾すら含んでいる。そうした条件下で、設計者は手探りで処理を分解し、構造を仮定し、徐々に責任の所在を定義していく。この一連のプロセスが、設計の「繰り返し」として観察される。

したがって、設計が繰り返されるのは、失敗を避けるための保険ではない。それは設計者自身が業務を理解し、意味を再構成するための、不可避な学習プロセスなのである。

1.2 三回設計法とは──処理・構造・意味の三視点

本稿が主軸とする「三回設計法」は、VBAや構造化言語を用いた業務設計において実務的に発見された設計の進化モデルである。この方法論では、設計が三つの視点を経て成熟していくことが観察されている。

第一回目の設計では、操作手順や画面設計に基づき、処理が機能単位で分割される。ここでは業務フローがそのまま構造に反映されるため、分かりやすいが再利用性や整合性には乏しい。

第二回目では、共通処理やデータ構造が抽出され、機能をまたいだ再利用や構造的整合性を意識した設計が導入される。ここで「構造としての設計」が初めて明示的に意識されるようになる。

そして第三回目では、各処理や構造が果たすべき「意味」すなわち業務上の責任と位置づけに着目し、構造が再配置される。ここでは、単なる技術的な都合ではなく、意味をもった構造が構築され、設計が業務知の表現へと昇華していく。

この三回の設計は、単にフェーズを分けたというよりも、設計者の視点の交代と成長を反映したプロセスである。

1.3 本稿の目的：構造的視座の進化としてのOOP再定式化

本稿の目的は、上記の三回設計法を起点とし、これがどのようにオブジェクト指向設計（OOP）やそれ以後の設計思想と結びつくかを構造的に再定式化することである。三回設計法が現場で発見された視点交代の記述であるのに対し、OOPはこれらの視点をあらかじめ設計の原理に組み込んだ体系的な手法である。

たとえば、OOPにおける「関心の分離」や「責務駆動設計」は、三回設計法の第三段階を初期から組み込んだものである。さらに、Clean ArchitectureやDDD（ドメイン駆動設計）は、構造と意味の融合を一貫した方法論として提示する。

本稿では、構造化設計の現場知と、OOP以降の設計理論とを対応づけることで、設計とは何か、どのように成熟していくかを再考する。そして読者が、自身の設計行為をより深く理解し、実務に適用するための構造的な視座を獲得することを目指す。

2. 三回設計法の構造と意図

2.1 第1回：機能の分割──画面・操作・処理単位での構造化

第一回目の設計では、設計者は業務要件をもとに、操作手順や画面遷移といった表面的な動作を中心に処理を分割する。これは主にユーザーの操作単位や、業務フローに沿った「できること」の分解であり、いわゆる「機能軸」による構造化である。

この段階では、たとえば「受注入力」「在庫確認」「納品書出力」といった機能ごとに、それぞれの処理がコードとして独立に実装される。各機能には固有の画面とロジックが存在し、それぞれが閉じた処理単位として構成されることが多い。結果として、コードは業務の操作順に対応しやすく、可視性にも優れる。

しかし、この設計は再利用性に乏しく、類似処理の重複や、仕様変更時の修正漏れを招きやすい。たとえば「商品名の入力チェック」や「金額の再計算」など、複数機能にまたがる共通処理が個別に記述されるため、変更が全体に波及する。

この機能単位の構造化は、業務の「操作」や「行為」に忠実な構造を実現する反面、共通性や意味構造に対する配慮を欠いている。つまり、初期の設計は「やるべきこと」のリストをコードに写し取ったにすぎない。

2.2 第2回：データの集約──再利用可能な構造への抽象化

第二回目の設計では、重複した処理や共通パターンが顕在化し、それらを再利用可能な形で抽象化する動きが始まる。ここでは「データ構造」が設計の中心となり、処理の枠組みが整理されていく。

設計者は、同一のデータに対して複数の機能が類似の操作を繰り返していることに気づく。たとえば「商品マスタの検索」「売上伝票の金額集計」「在庫の更新」といった処理が、それぞれ異なる機能内で個別に実装されていた場合、それらを「商品」「売上」「在庫」というデータ単位で共通化するという発想が生まれる。

ここで重要となるのは、処理をデータにひもづけて再構成するという視点である。データ構造を中心に、関連する操作を集約し、再利用性の高い関数やモジュールへと分離していくことで、コードの重複を削減し、構造的整合性を向上させることができる。

この段階で、初めて「構造としての設計」が意識されるようになる。コードは機能単位ではなく、データ単位で整理され、横断的な共通処理が抽出される。ここにおいて設計は「対象の把握」から「構造の整理」へと進化する。

2.3 第3回：責務の再配置──意味を軸とした構造の再構成

第三回目の設計では、抽出された構造や再利用可能な部品群が、どのような「意味」や「責任」に基づいて存在するのかが問われる段階に入る。単に共通だからまとめるのではなく、それが「誰の責務であるのか」「どこに属するべきか」といった意味的再配置が行われる。

たとえば、データの集計処理を一箇所にまとめただけでは、再利用の効率は向上しても、変更や拡張の際にモジュール間の責任が不明確となり、保守性を損なう可能性がある。ここで設計者は、機能と構造の背後にある「業務的責任」や「変更の主体」を軸に、再配置を行う必要がある。

この責務再配置の設計では、構造の一貫性よりも「意味の一貫性」が重視される。すなわち、「誰が何を知っているべきか」「どこで何を決定するべきか」といった責務の境界が、構造を規定する基準となる。

この段階での設計は、しばしば業務モデルそのものと深く関わる。構造が意味と整合することで、設計は業務知のモデルとして成立し、単なるコード構成ではなく、表現行為としての価値を獲得する。

2.4 なぜこの三視点は順番に現れるのか──知識の獲得順としての設計

三回設計法における視点の遷移は、単なる設計フェーズの変化ではない。それは、設計者が対象に対してどのような知識を獲得していくかという、理解の段階的深化を反映している。

最初の設計では、与えられた要件や目の前の業務フローに基づき、「何をすればよいか」が主な関心事であり、処理単位で設計が進む。次に、複数の処理を通じて共通のデータや構造が見えてきたとき、設計者は「どのように再利用できるか」という視点を持つようになる。そして最後に、それぞれの処理や構造が果たすべき意味を理解し、「なぜそのような配置であるべきか」「誰が責任を持つべきか」という問いに到達する。

この順序性は、設計者の経験、業務理解、技術的成熟と深く関係している。したがって、三回設計法は単なる設計手法ではなく、設計者の認知発達プロセスでもある。その意味で、この方法論はOOPやDDDといった後発の設計体系と親和性が高く、接続可能な理論的基盤を提供している。

3. オブジェクト指向における並行的構造設計

3.1 関心の分離と責務ベース設計

オブジェクト指向設計（OOP）の本質は、「関心の分離（Separation of Concerns）」にある。これは、1つの構造やコードが複数の異なる目的を同時に担わないようにするという原則であり、結果としてシステムを分割可能にし、理解しやすく、変更に強くする。

この原則の具体的な表現が「責務ベース設計（Responsibility-Driven Design）」である。オブジェクト指向では、すべてのクラスやモジュールに対して「その構造は何に責任を持つべきか」を問う。これにより、構造の配置や分離は、技術的な都合ではなく意味的な必然性によって決定される。

たとえば、ある業務システムにおいて「受注情報を管理するクラス」があるとき、それがUIの表示も、データの保存も、在庫の引当も同時に行っていたとすれば、それは関心の混在である。OOPではそれぞれの関心──表示、保存、業務判断──を別のクラスに分け、各構造を単一の責務に基づいて設計する。

この責務中心の視点は、構造化設計における「第3回設計」の責務再配置と対応しているが、OOPではこの視点を初期設計段階から組み込むことが可能である。すなわち、視点の「獲得」ではなく「前提」として設計に取り入れる点が大きな違いである。

3.2 ユースケース駆動設計とBoundary/Control/Entityモデル

オブジェクト指向において、業務ロジックの構造化は「ユースケース駆動設計（Use Case Driven Design）」という形で定式化される。これは、ユーザー視点から見た具体的な操作要求（ユースケース）を起点に、必要な処理構造を明確化する設計手法である。

この設計を支えるのが「Boundary/Control/Entity（BCE）」モデルである。Boundaryは外部とのインターフェース（画面やAPI）、Controlは処理の調整とフローの管理、Entityはドメインの中核データ構造とルールを表す。BCEは、それぞれが異なる責務を持ち、異なる変化に対して独立に対応することができる。

たとえば、受注処理のユースケースにおいて、ユーザー入力を受け取るフォームがBoundary、注文の整合性チェックや在庫引当を司る制御ロジックがControl、注文内容や在庫といったビジネスデータを保持するクラスがEntityに相当する。これらはそれぞれ分離されつつ、協調してユースケースを実現する。

BCEモデルは、構造を意味に応じて役割分担させるという意味で、責務の視点を設計初期から並行的に適用する強力なパターンである。構造化設計では後から責務を見出して再配置するが、OOPでは最初から責務を軸に構造が組み立てられる。

3.3 クラス図と関連の設計：構造と意味の融合

クラス図は、オブジェクト指向における最も基本的かつ強力な可視化手段である。ただし、単に属性と操作を並べた記述ではなく、「構造と意味の融合」として設計すべきである。

クラス図における関連（association）は、オブジェクト間の意味的関係を示す。たとえば「顧客は複数の注文を持つ」「注文は一つの商品に対応する」といった関連は、データ構造であると同時に、ドメインモデルにおける意味的構造である。関連の多重度や方向性は、単なる技術的制約ではなく、業務の理解と直結している。

このように、クラスとその関連を設計する際には、処理を構造に埋め込むのではなく、「構造に意味を載せる」ことが求められる。OOPにおいて設計とは、意味のある構造を作る行為であり、それによってシステム全体が可読性と拡張性を獲得する。

構造化設計でもデータ構造は存在するが、それはあくまで処理の補助的な存在であった。OOPでは、構造そのものが意味の担い手となり、設計の中心に位置づけられる。この違いは、設計における思考順序を反映しており、構造→意味の順ではなく、意味→構造という方向に転換されている。

3.4 層分離・インターフェース分離・疎結合の原理と意義

OOPにおける設計のもう一つの柱は、「層分離（Layered Architecture）」である。これは、UI・業務ロジック・データアクセスといった異なる関心を持つ処理を、明確に層として分離し、それぞれの層が定義されたインターフェースを通じて通信するという設計原則である。

この層分離によって、UIの変更が業務ロジックに波及せず、データベースの構造変更もロジック層に影響を与えにくくなる。つまり、構造が疎結合となり、各層が独立して進化可能な状態を実現する。

このとき、重要なのが「インターフェース分離（Interface Segregation）」の原則である。これは、モジュールが必要とする最小限の契約（インターフェース）のみを依存対象とすることで、過剰な結合を避けるという設計思想である。これにより、構造の自由度が保たれ、部分的な改変が全体を破壊しにくくなる。

また、「疎結合（Loose Coupling）」という性質は、再利用性と保守性の観点から極めて重要である。構造化設計では、関数の呼び出しや共有変数によって、コード間の依存関係が複雑に絡みがちであった。OOPでは、依存関係をインターフェース越しに設計することで、構造を抽象的かつ意味的に定義できる。

こうした設計原理は、構造の見通しと変化への強さを支えるものであり、構造化設計で経験的に繰り返されていた設計上の苦労を、あらかじめ理論的に解消する試みである。

4. 責務の構造化と設計思想の進化

4.1 Clean Architectureにおける層分離と依存逆転

Clean Architectureは、ソフトウェア設計における「変化に強い構造」を実現するための包括的アーキテクチャ指針であり、Robert C. Martin（通称 Uncle Bob）によって提唱された。その中核にあるのが、「関心ごとの層分離」と「依存関係の方向を逆転させる」という2つの原則である。

Clean Architectureでは、システムを複数の層（エンティティ層、ユースケース層、インターフェースアダプタ層、フレームワーク層）に分離する。それぞれの層は独立した責務を持ち、内側の層ほどビジネスに密着した「意味のある構造」として設計される。一方、外側の層はUIやDBといった技術的な実装であり、変更可能性が高い。

ここで重要なのは「依存逆転（Dependency Inversion）」の原則である。通常の実装では、ビジネスロジックがUIやDBに依存しがちだが、Clean Architectureではこれを逆転させ、UIやDBがビジネスロジックの抽象に依存するように設計する。すなわち、「重要なもの（業務の意味）」が「取替え可能なもの（技術の詳細）」に依存しない構造を作る。

このアーキテクチャは、設計の初期段階から責務の分離と再利用可能性を視野に入れるため、構造化設計で繰り返し発見されていた責務の再配置を、体系的に初期設計に取り込むことができる点で、大きな思想的進化を示している。

4.2 DDDによる意味単位の責務分離

ドメイン駆動設計（Domain-Driven Design, DDD）は、複雑な業務システムの設計において、技術よりも「意味」に着目した責務分離を徹底する設計方法論である。DDDの最大の特徴は、業務の概念そのものを構造に反映させるという点にある。

DDDでは、ドメインモデルを構成する基本単位として、Entity、Value Object、Aggregateという分類が導入される。Entityは同一性を持つ業務対象（例：注文、顧客）であり、Value Objectは値としての性質を持つ構造（例：金額、住所）である。Aggregateは、整合性を保つべきEntityとValue Objectの集合であり、一貫性の境界を表す。

この構造は、意味のまとまりに基づいて設計された責務の配置であり、構造化設計では設計の後半でようやく到達する「意味のまとまり」を、最初から設計単位として導入している。

さらに、DDDではドメイン知識の複雑な振る舞いを扱うために、Domain ServiceとApplication Serviceという二つのサービス概念を導入する。Domain Serviceはビジネスルールを表現する構造であり、Application Serviceはユースケースを調整し、ドメインオブジェクトを協調させる役割を担う。

これにより、振る舞いも意味に応じて責務が分離され、構造に一貫した意図が宿る。構造化設計において、処理がデータに紐づけられるようになった第二回設計とは異なり、DDDでは意味単位で処理と構造の対応関係が厳密に整理される。

DDDにおけるもう一つの重要な要素が「ユビキタス言語（Ubiquitous Language）」である。これは、開発者と業務担当者が共通して使用する言葉を、モデルやコード、ドキュメントに一貫して反映させるという設計思想である。

このアプローチにより、構造は単なる技術的な実装ではなく、業務の意味構造そのものとして機能する。すなわち、コードは説明の媒体であり、業務知識の形式知化として機能する。この点において、DDDは「構造の意味化」に最も深く踏み込んだ設計思想である。

4.3 デザインパターンによる構造と責任の定型化

設計パターン（Design Patterns）は、ソフトウェア設計において繰り返し現れる問題に対する「定型的な解法」を提供する枠組みである。中でもGoF（Gang of Four）パターンは、23の基本的な設計パターンを提示し、OOPにおける構造と責任の整理に広く用いられている。

GoFパターンは、役割に応じて以下の3つに分類される。

• 生成パターン（Creational）：オブジェクトの生成過程を責務として分離する（例：Factory Method、Builder）

• 構造パターン（Structural）：オブジェクトの組み合わせ方に関する構造的な責任を定型化する（例：Adapter、Composite、Decorator）

• 振る舞いパターン（Behavioral）：オブジェクト間の責任のやりとりや処理の流れに関する設計（例：Strategy、Observer、Command）

これらのパターンは、単にコードの再利用を目的とするのではなく、責任の分担と構造の明確化を目的としている点で、三回設計法の第三段階における「意味の整理」と対応している。

DDDでは、こうしたGoFパターンをよりドメイン志向に適用する「戦術的DDDパターン」が提唱されている。たとえば、Repositoryは永続化とドメインロジックの責務を分離する構造であり、Specificationはビジネスルールの再利用と表現力を高めるパターンである。

これらの戦術的パターンは、DDDにおける意味の構造化を技術的に支える実装技法であり、パターンの適用が単なる技術選択ではなく、「意味を宿す構造の定型化」として機能することを示している。

5. 三回設計法とオブジェクト指向の構造的対比と昇華

5.1 三回設計法は「視点の交代」、OOPは「視点の並行設計」

三回設計法の本質は、「設計者の視点が段階的に変化すること」にある。すなわち、機能→構造→責務という順で、設計者の理解が深まり、それに伴って構造が再構成されていく。この視点の変化は、経験と反省によって促され、現場での学習を通じて進行する。

一方、オブジェクト指向設計（OOP）は、これらの視点を設計初期から同時に扱うことを前提としている。すなわち、「どのような機能が必要か（ユースケース）」「どのような構造で保持するか（クラスと関連）」「誰がどの責務を負うか（役割分担）」といった視点を、並列に検討し、構造として統合していく。

この違いは、設計における思考の順序と方法論に表れる。三回設計法では、構造が処理の実装から自発的に導かれるのに対し、OOPでは、構造と責務を先に定義し、そのうえで処理を配置する。言い換えれば、三回設計法が「発見的設計」であるのに対し、OOPは「構想的設計」である。

この視点の並行設計は、設計者にとって高い抽象能力とモデル化スキルを要求するが、同時に再利用性と変更耐性の高い構造をもたらす。OOPは、三回設計法の持つ視点交代の流れを、手続きではなく前提条件に転化した体系である。

5.2 設計構造対応マッピング：三回設計法 vs OOP設計技法

三回設計法とOOPの設計技法を比較すると、以下のような対応関係が見えてくる。

• 第1回設計（機能分割）⇔ ユースケース駆動設計（Use Case Driven Design）

• 第2回設計（構造抽出）⇔ クラス設計とドメインモデル化

• 第3回設計（責務再配置）⇔ 責務ベース設計、Clean Architecture、DDDの構造

この対応関係は、設計の観点が時間とともに獲得される過程と、それを設計初期からモデルに組み込む体系との差異を示している。OOPでは、これらの観点が設計技法として明示されており、設計者は視点を意識的に使い分けながら、より高次の構造を形成できる。

たとえば、OOPにおけるBoundary/Control/Entityモデルは、三回設計法のそれぞれの視点に対応した構造を初期設計において同時に保持する。また、DDDでは意味に基づいた責務単位で構造を整理することが標準化されており、第三回設計にあたる再配置を、設計工程の冒頭から組み込むことが可能である。

このように、OOPの設計技法は、三回設計法の実践知を理論と構造に再編成したものであり、両者の間には明確な構造的写像が存在する。

5.3 設計行為の変化：反復的発見から初期分離への進化

構造化設計における三回設計法は、現場での反復的な発見と再構成によって成り立っていた。設計者は、問題に直面し、修正を繰り返す中で、処理の抽象化や責務の分離といった知見を獲得していく。

しかし、OOPでは、これらの知見を形式知化し、設計の初期段階から導入することが可能である。すなわち、責務ベースで構造を定義し、依存関係を意図的に設計することで、後からの再構成ではなく、前もっての分離によって複雑性を制御することができる。

この進化は、単に設計手法の違いにとどまらず、「設計行為」そのものの意味を変化させる。発見による設計は「後追いの思考」であり、構想による設計は「先回りの思考」である。OOPとは、設計を偶然性の産物から、意図された構造化行為へと昇華させる運動である。

5.4 視点の獲得と設計文化の成熟

視点の交代を経て視点の並行設計へと至るこの流れは、単なる技術的進歩ではない。それは「設計文化」の成熟である。OOPやDDDといった手法は、過去の失敗や試行錯誤の蓄積を背景に、設計をより明示的で、より構造的で、より意味的なものへと変質させた。

設計とは、構造によって意味を表現する行為である。この構造はコードそのものではなく、設計者の意図、文脈、責任、変化耐性といった多層的な意味の体系であり、適切な視点を獲得しなければ見通すことはできない。

三回設計法は、その視点を一歩ずつ獲得するための実務的プロセスであり、OOPはその視点をあらかじめ備えた構造的言語である。両者は対立ではなく、補完関係にあり、経験知と形式知、現場と理論を橋渡しする設計の知的基盤となる。

6. おわりに：意味を宿す構造としての設計

6.1 「責務」とは意味の境界である

設計において最も重要な問いは、「この構造は何のために、誰の責任で存在するのか」である。機能やデータといった設計要素の配置は、必ず何らかの責務──意味をもった役割──によって正当化される必要がある。責務とは、知識や判断、操作の単なる分担ではなく、「構造の意味を規定する境界線」である。

構造化設計においては、責務はしばしば後から発見されるものであり、コードの重複や設計の揺らぎを経て、経験的に調整されていくものであった。一方、オブジェクト指向では、設計の最初から責務が中心に据えられ、構造はそれに従って分割・配置される。責務によって意味が分離され、意味によって構造が秩序づけられる。この関係こそが、設計における思考の基軸となる。

6.2 オブジェクト指向は「業務をそのまま設計にする」革命である

オブジェクト指向（OOP）の革命性は、それが「業務を分解せず、そのままの構造で取り込める」ことにある。これは単なる抽象化やカプセル化の技術的側面ではなく、設計という行為におけるモデリングの質的転換である。

構造化設計では、業務の全体像を機能とデータに分割し、それらを組み合わせ直すことでようやく「業務の意味」を再現するという、翻訳と再構成を要した。設計者は個々の機能を記述しながら、背後にある業務構造を想起し、頭の中で統合する必要があった。これは高度な職人技であり、設計の品質は設計者の経験に強く依存していた。

しかし、OOPでは、アクター、オブジェクト、ユースケースといった設計要素が、業務の構造と直接的に対応している。顧客・商品・注文といったドメインオブジェクトがそのままクラスやエンティティとなり、顧客の行動がそのままユースケースになる。設計は翻訳作業ではなく、「業務の構造をそのまま写し取る行為」として遂行される。

これは、設計の再現性と説明可能性を飛躍的に向上させた。設計者の暗黙知を排し、業務の構造をコードとして共有可能なかたちで定着させる仕組みを提供した。これにより、チーム内の認識共有、変更への対応、他者による保守・拡張が容易になり、設計行為そのものの生産性が飛躍的に向上したのである。

6.3 革命的な生産性向上の構造的理由

OOPがもたらした生産性の革命は、単にコードの行数が減った、再利用性が高まったという量的な側面だけではない。以下のような構造的な知の仕組みとしての効果が、本質である。

• 意味の一貫性：業務構造がそのままクラス・関連・責務としてコードに現れるため、構造が意味を保ったまま継続的に成長できる。

• 分担の容易さ：責務に基づいた設計は、チームメンバー間での明確な分担と、変更時の影響局所化を可能にする。

• 視点の並列化：処理・構造・責務といった複数の視点を同時に設計できるため、設計の繰り返しが減り、初期から質の高い構造を作ることができる。

• 業務と設計の対応関係：設計レビューや保守の現場において、業務モデルとコード構造が一体化しているため、設計の意図や背景が把握しやすい。

これらの特性により、OOPは単なる技術選択ではなく、業務知をコードへと形式知化するための知的基盤として、従来の設計文化を根底から変革した。

6.4 構造化設計の経験をOOPに活かす翻訳知

構造化設計の経験は、OOPにおける設計判断の源泉となる。三回設計法が示すように、設計者は初めに処理を分け、次に構造を抽出し、最後に意味のまとまりとして責務を再配置する。この過程で得られる視点と判断基準は、OOPにおいても本質的に活用される。

たとえば、OOPでは初期から責務分離を前提に設計されるが、どのようにクラスを定義し、どこにメソッドを配置し、どの粒度で分離するかといった判断は、構造化設計で繰り返された構造化の経験を抜きにしては行えない。

OOPは、三回設計法で暗黙に蓄積された知見を、明示的な構造と方法論に転写したものであり、職人芸を「再現可能な知」へと変換するための技術でもある。構造化設計を経て得られた知識は、OOPを真に有効に使いこなすための土壌なのである。

6.5 設計とは説明可能な構造を生み出す知的活動である

最終的に、設計の価値はそれが「説明可能かどうか」によって決まる。なぜその構造なのか、なぜその責任配置なのか、なぜその名前・関連・流れなのか。これらを明確に語れることが、設計の本質的な品質を決定する。

OOPはこの要求に高いレベルで応える体系である。構造が意味と責任を伴い、コードそのものが業務知の表現媒体となる。設計とは、知識を構造に変換する行為であり、OOPはそのための記述言語、構造のための思想体系である。

OOPが革命的であったのは、設計行為を個人の経験から共同の知へ、曖昧な直感から説明可能な構造へと移行させた点にある。構造はもはや単なる技術的配置ではなく、「意味を宿す構造体」として、知識の運搬装置となった。

7. 付録：構造設計の比較と実務への応用

7.1 三回設計法とOOP/DDDの視点対応表（横断マッピング）

本稿で論じた三回設計法は、機能→構造→意味という三つの視点の獲得を通じて設計が成熟するプロセスである。一方、OOPやDDDでは、この三視点が初期設計から併存し、並行的に扱われる。以下は、各設計視点とそれに対応するOOP/DDDの構造要素とのマッピングを示す。

7.2 設計レイヤと技法の比較図（構造化 vs OOP vs DDD）

設計を実務に適用するためには、各アーキテクチャにおけるレイヤ構造の違いを理解し、それぞれが何を目的としているのかを明示する必要がある。以下に、構造化設計・OOP・DDDにおける典型的な設計レイヤの比較を示す。

7.3 実務でOOPに移行するための転換ポイントと段階

構造化設計を中心に業務システムを構築してきた組織にとって、OOPへの移行は単なる技術選定ではなく、設計文化そのものの転換である。以下に、移行にあたっての代表的な段階と転換点を示す。

7.4 本稿の用語対応一覧と設計翻訳表

本稿において使用した主要概念について、構造化設計／OOP／DDDでの用語の違いと意味の対応を一覧表として整理する。