構造化言語におけるOOP的設計再考

～OOP的視座と三回設計法の融合による現場知の体系化～

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

要約

構造化言語（VBAなど）において設計の品質を高めるためには、処理の順序やデータ構造だけでなく、意味や責務をも見通した構造的設計が求められる。従来、構造化設計では「トップダウン三回設計法（処理→構造→責務）」によって、試行錯誤的に設計の成熟が図られてきた。一方、オブジェクト指向設計（OOP）やドメイン駆動設計（DDD）では、これらの視点交代をあらかじめ設計原理に組み込むことで、高度な再利用性と意味一貫性をもった構造を初期から獲得できる。

本稿では、OOP設計がもたらす「業務構造の視覚化」と、三回設計法がもたらす「実装的現場知」との接続を試みる。OOPの設計書をそのまま構造化言語で実装することはできないが、それを翻訳するプロセスは、三回設計法を再演する形と見なすことができる。また、OOPの分析技法を取り入れた三回設計法は、より意味に根ざした処理設計へと進化しうる。

このように、設計思想を単一にせず、OOPと三回設計法を意識的に往還させることで、構造化言語でも高度な意味構造を備えた設計が可能となる。記事では、複数設計手法の融合が実務に与える影響とその軽減策を検討しながら、最終的に現実的かつ再現可能な「構造的設計文化」へと昇華させる道筋を描く。

第1章　はじめに──設計を繰り返すとはどういうことか

1.1 本稿の問題意識と構造化言語の制約

構造化言語、特にVBAのような言語環境において、設計の品質を高めようとする試みは常に困難を伴う。オブジェクト指向言語のような構造抽象化の支援機構が存在しないため、プログラマは処理の順序や変数の配置といった「表面的な構造」にとどまりがちである。その結果、局所最適な手続き設計は行えても、全体構造の再利用性や意味的整合性には限界がある。

構造化言語の設計課題は、単なる機能不足ではなく、設計という行為の視座を持ちづらいという点にある。手続きが即ちプログラム全体を表すという思想に立つ限り、意味や責任の配置はコードの流れの中に埋没してしまう。このような環境下でいかに構造的思考を保ち、かつ実装可能な形で再現するかが、本稿の中心的な問題意識である。

1.2 設計行為とは「視点の変化と意味の獲得」である

設計とは、単にコードの外形を整える作業ではない。それは視点を変えながら「なぜこの処理が必要なのか」「この構造は何を意味しているのか」を問い直す行為である。視点の変化とは、機能単位の視野からデータ構造へ、さらに責務や利用者の期待といった文脈的意味へと進展するものである。

この視点の変化を一度で完了させることは困難であり、多くの現場では段階的に、すなわち設計を繰り返すことで意味の解像度を上げていく。このプロセスにおいて、構造化言語では三回設計法という反復手法が有効に機能する。処理→構造→責務という設計のフェーズを明確に意識することで、視点を強制的に切り替える枠組みを与えることができる。

1.3 OOPと三回設計法が交差する地点

オブジェクト指向設計（OOP）においては、視点の変化が設計原理としてあらかじめ組み込まれている。ユースケース記述から始まり、クラス図、責務分離、依存の制御といった一連の設計作業は、構造を意味の単位として再構成する試みである。そこには、意味と構造の一致、すなわち「ドメインの表現としての構造化」が志向されている。

一方で、構造化言語における三回設計法は、OOPのような構文的支援なしに、この視点変化を段階的に獲得しようとする現場知の体系である。処理の流れから構造を抽出し、さらに責務の再配置を通じて意味の統一性を目指すという流れは、OOPの設計過程と本質的に交差している。

本稿では、OOPの設計技法を単なる外部参照とするのではなく、構造化言語の現場において再演・翻訳する枠組みとして捉える。これにより、両者の設計思想を往還させながら、新たな構造的設計の地平を切り拓くことを目指す。

第2章　OOP設計の本質──意味を構造化するという思想

2.1 OOP設計書は「業務モデル」である

OOPにおける設計書は、単なるコードの前段階ではなく、業務の意味構造を明示するモデルとして機能する。ユースケース図は業務の流れを抽象化し、クラス図は対象となる実体や概念を形式化する。さらに、クラス間の関係性や責務の分担は、現実世界の役割や権限の再構成にほかならない。すなわち、OOP設計とは業務そのものを構造的に読み解き、ソフトウェアとして再記述する知的作業である。

OOP設計が有効に機能するのは、対象となる業務が暗黙のうちに含んでいる意味関係を明確に言語化できるからである。設計書は仕様書ではなく、意味を記述するための構造化表現である。構造化言語がコードを「処理」として記述するのに対し、OOP設計書はコード以前に「意味」と「責任」を分離・定義することで、後工程の実装に高い指針性を与える。

2.2 クラス図・ユースケース・責務設計の意味

クラス図は、構造的観点から業務の対象物（エンティティ）を明示化する。顧客、注文、商品といった概念は、それぞれが保持すべき情報とふるまいを明確にされ、相互に関係づけられる。これにより、業務の「見えない構造」が可視化され、設計の出発点として機能する。

ユースケース図は、利用者の視点から業務フローを切り出す。ここでは、「誰が、何を、なぜ、どのように」という業務の本質が抽出され、システムの提供価値を把握する土台となる。ユースケースとクラス図が連携することで、「どの責任が、どの構造に属するか」という設計の骨格が明らかになる。

責務設計は、これらの図に基づいてクラス単位に機能を割り当てる作業である。「この処理はどの役割の責任か」「情報の管理主体は誰か」といった設問を通じて、業務上の責任をコードレベルの構造に変換する。この過程において、OOPは単なる構文ではなく、業務を再解釈するための思考道具として機能する。

2.3 OOPが提供する「意味のまとまり」

OOPが最大の価値を発揮するのは、「意味をひとまとまりとして構造に落とし込める」という点である。手続き型設計においては、意味や意図がコードの流れの中に散在しがちであるが、OOPでは意味を包含する構造単位（クラス、オブジェクト）として定義できる。たとえば、商品クラスには商品の属性と価格計算のふるまいが集約され、利用者はその内部実装に立ち入ることなく意味単位として活用できる。

このような「意味のまとまり」は、再利用性、拡張性、保守性において極めて有効である。OOPでは、変更の波及範囲を最小化するために、意味ごとに構造を分離する原則が徹底される。その結果、変更が生じた際にも、意味的整合性を保ったまま部分的な修正が可能となる。

構造化言語では、こうした「意味のまとまり」を構文的にサポートする仕組みが存在しない。しかし、OOP設計を事前に行い、その意味構造を保持したまま構造化言語で実装することで、部分的にOOPの利点を取り込むことが可能となる。これは、意味を設計段階で確定し、処理として展開するという翻訳的アプローチであり、三回設計法と親和性の高い思考様式である。

第3章　構造化言語における三回設計法の実践知

3.1 処理ベースの初期設計の限界

構造化言語における初期設計は、しばしば「処理の順番」をベースに進められる。業務フローや手順書に従い、必要な操作をそのままコードに変換することで、短時間で機能するプログラムが完成する。しかしこのアプローチでは、意味のある構造や責任の境界が曖昧なまま実装されるため、後の保守や改修の段階で複雑化を招きやすい。

処理ベースの設計では、似たようなコードが複数箇所に散在し、変更があった場合にどこを修正すべきか判断が難しくなる。また、業務全体の構造や目的を見失いやすく、手続きの集合がそのままシステムの姿になってしまう。このような初期設計は、実装速度を優先する現場では重宝されるが、設計品質や再利用性といった中長期的な観点では大きな限界を抱えている。

3.2 データ構造と意味構造の分離

三回設計法の第二段階では、処理に埋め込まれていた情報要素を「構造」として再構成する。具体的には、複数の手続きにまたがって利用される変数や、同様の構造をもつデータ群を抽出し、それらをテーブルや配列、ユーザー定義型などの形式で統合する。この段階で重要なのは、単なる物理的整理にとどまらず、それぞれのデータがもつ意味的役割を明確化することである。

たとえば「売上」という概念がコードの中で何度も出現する場合、それを1つの構造体やワークシート表として再構成することで、「売上」に関する意味が一箇所に集約される。こうすることで、変更や追加の際に処理全体を見直す必要がなくなり、意味構造に基づいたモジュール化が可能となる。

データ構造を明確にすると、業務上の「実体」とプログラム上の「処理」が切り離される。この分離は、設計における視点の変化を促進し、処理の見通しを飛躍的に高める要因となる。構造化言語でも、明示的なオブジェクト機構をもたずとも、こうした再構成によって「擬似的な意味モデル」を構築することができる。

3.3 責務再配置による設計の成熟

三回設計法の第三段階では、機能やデータに対して付与された処理責任を見直し、それをより意味的に妥当な単位へと再配置する。この段階では、既に動作するコードをただ整理するのではなく、「この処理はどこに属するべきか」「誰の責任として管理するべきか」といった視点で、構造の再評価が行われる。

たとえば、入力チェック処理が複数箇所に散らばっている場合、それらを共通の関数に統合するだけでなく、その関数がどの層（UI層、業務層、データ層）に属するかを再検討する。処理が持つ意味と、その配置先との整合性が設計の成熟度を決定づける。

責務の再配置は、構造の抽象度を一段引き上げ、設計を「単なる動作」から「意味の体系」へと昇華させるプロセスである。ここでの設計判断は、単なる技術的合理性ではなく、利用者や保守者の理解可能性、将来的な拡張性といった観点を含んで行われる。

この段階を経ることで、構造化言語においても「意味のまとまり」としての構造が形成される。三回設計法はそのための枠組みであり、OOPのような設計支援を欠く現場において、実装と意味の往復を促す知的装置として機能する。

第4章　OOP設計は三回設計の「前処理」となりうるか

4.1 OOP→構造化言語翻訳における再構成性

OOP設計で得られたクラス図やユースケース記述は、それ自体が構造的意味をもった情報資源である。これを構造化言語へと翻訳する際には、OOPの語彙や責任の分離構造を手続きベースに再構成する必要がある。たとえば、OOPにおける「顧客」クラスは、構造化言語においてはワークシートや配列、プロシージャ群に分割して表現される。これは直訳ではなく、翻訳過程での再構成を含む設計行為である。

この再構成性が意味をもつのは、OOP設計が設計者にとっての「抽象的モデル」として働き、構造化言語への実装を試みる過程で視点の変化が自然に誘発されるからである。すなわち、OOPの設計書は、構造化言語における三回設計法の第一段階および第二段階を省略または支援する「設計の前処理」として機能し得る。

4.2 構造視点の獲得と設計手順の簡素化

OOP設計を先に行うことで、構造化言語で設計を始めた場合に比べて、より高次の視点から初期設計に着手できるようになる。たとえば、通常であれば処理→構造→責務の順に段階的に設計を洗練させる必要があるが、OOP設計の出発点を利用すれば、はじめから「責任のまとまり」として構造を意識できる。

このような構造視点の先取りは、設計の試行錯誤を大幅に削減し、設計手順の簡素化をもたらす。とくにプロジェクト初期の混沌とした要件整理において、OOP的アプローチは思考の整理道具として極めて有効である。視覚的な構造図や責任分離の整理表があることで、構造化言語への実装時にも混乱が少なく、機能単位・責任単位のコード配置が自然に導かれる。

4.3 OOP設計を使うことで何が「省略」されるのか

OOP設計を前提とした構造化言語の実装では、本来三回設計法において繰り返し実施されるはずだった「視点の交代」や「構造の再発見」が、設計書の段階ですでにある程度達成されている。これにより、初期処理設計の検討範囲が限定され、設計のやり直しや再配置の作業が減少する。

省略されるのは作業量だけではない。視点の転換という認知的負荷、構造の意味解釈という解釈的負荷が軽減される点が大きい。あらかじめ意味のまとまりを得ているOOP設計を参照することで、構造化言語での実装者は処理の流れやデータの配置に集中できる。つまり、設計に伴う認知コストを前段階で吸収し、実装段階の生産性と一貫性を向上させることができる。

ただしこの省略は「設計をしなくてよくなる」ことを意味しない。むしろ設計が先に済んでいること、すなわち「設計を翻訳する」という認識に立脚しなければ、OOP設計の意図が構造化言語において崩壊する危険性がある。その意味で、OOP設計は三回設計法の省略ではなく、「繰り返し設計を支援する装置」として位置づけるべきである。

第5章　二重設計の現場的課題と心理的抵抗

5.1 なぜ「同じことを二度やる」と感じるのか

OOP設計を先に行い、その後に構造化言語で実装を行うというプロセスは、しばしば「同じことを二度やっているように感じる」という心理的抵抗を生む。特に実装者がOOP設計を十分に読み解けない場合、設計書の意図を再解釈して手続きベースのコードに置き換える行為は、単なる変換作業に見えてしまい、創造性のない作業と受け取られる。

この感覚は、OOP設計と構造化言語実装との間に共通する語彙や構造が存在しないことに起因する。クラスや責務といった概念が、構造化言語では明示的な構文として存在しないため、設計と実装が同じ内容を別の文法で繰り返しているように見える。設計と実装の「表層」が一致していないがゆえに、「また同じ内容を作り直している」という誤解が生じる。

5.2 設計ドキュメントと実装構造の分裂

OOP設計書と構造化言語の実装コードとの間には、しばしば構造的な乖離が生じる。設計ドキュメントでは明快に分離されていた責務や構造が、実装段階で統合されたり、断片化されたりすることで、設計とコードの対応関係が曖昧になる。これが「設計ドキュメントは実装に使えない」「実装が設計と乖離している」といった批判を生む温床となる。

この分裂は、単に翻訳作業の粗さによるものではない。構造化言語にはOOP的な責任分離を維持する構文的手段が存在しないため、設計構造をそのまま実装に写像することが困難なのである。さらに現場では、設計意図よりも納期や実装速度が優先されるため、設計書の修正や再解釈が後回しにされ、両者の乖離が時間とともに拡大していく。

5.3 メンテナンス・レビュー・運用負荷の現実

OOP設計に基づく構造化言語の実装は、初期開発フェーズでは有効に機能する一方で、運用段階に入ると新たな負荷を生む可能性がある。設計書と実装コードの対応が不明確である場合、レビューやバグ修正の際に「どの設計意図に基づく実装か」を確認するコストが増加する。特にメンテナンス担当者が設計書を参照せずに修正を加えると、意図を無視した改変が構造全体の劣化を招く。

また、レビュー時には「設計通りに実装されているか」を確認するために、両者を照合する作業が発生するが、この作業自体が煩雑で、レビュー効率を著しく下げることがある。設計と実装のあいだに構造的一貫性が保証されていない限り、設計の有無がかえって運用上の負荷になるという逆説が生じる。

このような負荷は、設計と実装の往還を自然な流れとして組み込んでいない開発文化に特有のものである。設計は使い捨ての資料ではなく、構造的思考を継続的に支える「思考のインフラ」であるという意識を持たない限り、二重設計は常に無駄な作業として認識され続けるだろう。

第6章　軽量化のための設計運用スタイルと判断軸

6.1 四つの設計スタイル（OOP主導／構造化主導／並列融合／脳内翻訳）

設計の品質を保ちながら、現場での運用負荷を最小化するには、設計スタイルの選択が重要である。本稿では、OOP設計と構造化言語の実装を組み合わせる際の実践的スタイルとして、次の4類型を提示する。

第一に「OOP主導型」は、OOPで設計書をきっちり作成し、それを翻訳する形で構造化言語へ実装するスタイルである。設計と実装の明確な分離、設計資産の再利用可能性などが利点であるが、翻訳の手間とドキュメント維持の負荷が高い。

第二に「構造化主導型」は、最初から構造化言語での実装を前提とし、必要に応じて設計図的なスケッチを補助的に用いるスタイルである。設計がコードに密接に結びつくため、運用は軽快だが、構造的な一貫性や責務の明確化には限界がある。

第三に「並列融合型」は、OOP設計と構造化実装を同時並行で進め、相互に補完しながら進行するスタイルである。柔軟かつバランスが取れている反面、設計と実装を切り分けて考えられない設計者には高度な判断を要求する。

最後に「脳内翻訳型」は、設計書を明示的に書かず、設計者の頭の中にOOP的なモデルを保持したまま、直接構造化言語で実装するスタイルである。ドキュメントレスで最も軽量だが、設計者に大きく依存し、知識の継承やレビューが困難となる。

6.2 プロジェクト規模・設計者レベル・共有範囲による選択戦略

どの設計スタイルを選ぶかは、プロジェクトの規模、設計者のスキル、関係者間の設計共有範囲といった複数の要因によって決定される。たとえば小規模で単独設計者による開発であれば、脳内翻訳型や構造化主導型が現実的である。一方、中～大規模プロジェクトやチーム開発では、並列融合型あるいはOOP主導型を選択する方が構造の一貫性と知識の共有に有利である。

設計者のスキルによっても選択肢は変化する。OOPに習熟した設計者であれば、設計書を介さずにモデルを頭の中で保持し、効率的に手続き型コードへ落とし込むことができる。しかし、初学者やチーム間での合意形成が必要な場合は、明示的な設計ドキュメントの存在が不可欠となる。

また、プロジェクトのライフサイクルのどの段階にあるかも考慮すべきである。初期構築段階ではOOP的なモデル設計が有効であり、保守段階では構造化的な軽量化が有利である。これらの要素を総合的に勘案し、現実的な設計運用方針を定めることが必要である。

6.3 最小負荷で最大構造を得る実務ガイド

現場で設計と実装の両立を図るには、「最小の労力で最大の構造的利益を得る」ための実務指針が求められる。まず第一に、OOP設計書を作成する場合には、すべてのクラスやユースケースを網羅しようとせず、「構造上重要な部分だけ」に限定して記述することが有効である。部分的な設計でも、骨格さえ共有できれば全体の構造的整合性は保たれる。

第二に、設計ドキュメントは「使い捨て」ではなく、「実装補助」として段階的に更新・簡素化しながら運用することが重要である。初期は詳細な設計書を用意し、開発が進むにつれて要点を抽出し、最終的にはテンプレート化することで、設計の再利用性と軽量性を両立できる。

第三に、実装コードそのものを「構造の記述媒体」として活用する方針がある。たとえば、関数の命名規則や、モジュールごとの責任分離、コメントによる構造意図の明示などにより、ドキュメントに頼らずとも設計の意味を読み取れる構造を目指す。

これらの工夫を通じて、設計の本質を失わずに、負荷を最小限に抑えることが可能になる。軽量で意味のある設計を実現することが、構造化言語における設計文化の実務的ゴールとなる。

第7章　OOP設計から再構成する三回設計法の応用例

7.1 クラス図→手続き構造へのマッピング

OOPにおけるクラス図は、対象業務の構造と責任の関係を視覚的に表現するものである。構造化言語への実装にあたっては、このクラス図を「手続きベースの構造」に変換する必要がある。変換の基本原則は、各クラスを責務単位に分解し、それぞれを関数・モジュール・テーブルとして再配置することである。

たとえば「商品」クラスがあれば、属性情報はワークシート上の行・列に、操作メソッドは「価格計算」や「在庫更新」などのサブルーチンとして対応づける。このとき重要なのは、OOPの構造を機械的に再現するのではなく、構造化言語の実装文脈に合わせて意味を再編集することである。クラス図を「意味構造のカタログ」として参照しながら、再配置可能な部品として捉え直す設計的視点が求められる。

7.2 責務分離されたOOP設計の再配置技法

OOP設計では、責務（責任と役割）はクラスに内包され、原則として単一責任を保つよう設計される。構造化言語では、これらの責務をコード構造に対応づける必要があるが、オブジェクト機構が存在しないため、別の単位に「割り当て直す」必要がある。

たとえば、責務ごとにモジュールを分ける、もしくは「機能名_処理内容」という命名で関数を分類・整理することで、擬似的に責任の分離を実現することができる。また、同じ責務に属する複数の関数を1つのシート上の表形式で管理し、構造的にリンクさせることで、責務の再現性と保守性を両立させることが可能である。

このように、OOPの責務構造を構造化言語の文法・道具に合わせて再配置するには、「意味→構造→処理」という再演の視座が必要となる。再配置の際には、責務単位での処理依存関係の明示や、呼び出し元の明確化といった工夫も併せて行うことで、設計の透明性と実行効率の両立を図ることができる。

7.3 OOPの語彙を使った三回設計テンプレート

OOP設計を構造化言語で実装する際に効果的なのが、「OOPの語彙」を用いた三回設計法のテンプレート化である。たとえば、「エンティティ」「サービス」「ユースケース」といったOOPの概念を、構造化言語の関数群・処理構造・データ構造に翻訳し、それぞれに定型パターンを設けることで、設計・実装の一貫性を確保することができる。

具体的には、エンティティは表（ワークシート）またはユーザー定義型として定義し、その属性操作は「Update_〇〇」「Validate_〇〇」といった命名規則で関数化する。サービスは、複数のエンティティにまたがる処理を集約した業務関数群とし、ユースケースは画面操作単位または処理フロー単位での手続きとして実装する。こうした構造的枠組みをテンプレートとして設計段階から準備しておけば、実装者は翻訳に悩まず、設計の意図に忠実なコードを効率的に作成できる。

このテンプレートは、あくまで三回設計法の補助的枠組みとして機能するものであるが、OOPの概念を適切に抽出・変換する訓練にもなるため、設計教育の素材としても有効である。構造化言語においてOOPの力を借りるには、表現手段ではなく「語彙と思考形式」を導入することが最も現実的であり、テンプレート化はその最適な入り口である。

第8章　設計思想の融合がもたらす構造的思考の成熟

8.1 思考の再演としての翻訳設計

OOP設計を構造化言語に翻訳するという行為は、単なる文法変換ではなく、「設計思考そのものの再演」である。クラス図やユースケースをもとに手続きベースの構造を再構築する過程では、設計者がもう一度、意味と責務と構造の関係を咀嚼し直すことになる。この再演によって、設計はより実装現場の文脈に根ざした具体性を帯び、意味の齟齬や責任の曖昧さを洗い出すことができる。

この再演的設計を繰り返すことは、設計者にとって思考の筋力を鍛える行為であり、結果として「構造的に考える力」の涵養につながる。構造を模倣するだけでなく、構造を自ら組み立て直す経験こそが、実践的設計者を育てる土壌となる。翻訳設計は、設計思想と実装技術の断絶を乗り越える知的訓練であり、まさに設計の本質を再学習する場である。

8.2 設計文化とは何を繰り返し、何を捨てるかの選択である

設計文化とは、設計に関わるすべての行為の中から、「何を形式化して残し、何を都度捨てるのか」という判断の蓄積である。全てを文書化しようとすれば設計は硬直化し、すべてを頭の中に収めようとすれば属人化する。その中間にある「繰り返す価値のある構造」だけを残し、それ以外を都度捨てる。この取捨選択の洗練が、文化としての設計を成熟させる。

OOP設計がもたらす「モデルとしての構造性」と、構造化言語が要求する「実装としての合理性」は、ときに衝突し、ときに補完し合う。その衝突や補完の経験が積み重なることによって、「このチームではこう設計する」という固有の文化が形成される。設計文化は抽象的な理念ではなく、日々の選択の中で鍛えられていく実践の技術である。

8.3 OOPと構造化言語の間を往還するということ

本稿を通じて一貫して主張してきたのは、OOPと構造化言語を対立的に捉えるのではなく、相互に行き来する「往還的な思考」が可能であるという点である。OOPの抽象性は、構造化言語の具体性によって検証され、構造化言語の制約は、OOPの思想によって補われる。この往還を繰り返すことで、設計は一段と柔軟かつ堅牢なものとなる。

設計者がOOPと構造化言語の両方に精通している必要はない。しかし、両者の視点の違いと、それぞれが補完し合える関係性を理解していることが、設計の質を高める上で重要である。往還とは翻訳であり、再構成であり、比較の中で本質を浮き彫りにする方法論である。

この思考の往還こそが、構造的設計の成熟を導く鍵であり、実装に閉じず、思想に留まらず、日々の実務とつながる生きた設計を可能にする。OOPと構造化言語は、別々の世界ではなく、設計という思考空間の中で相互に呼応するパートナーなのである。

設計スタイル選択マトリクス

A.1 OOP設計→三回設計の翻訳対応表

A.2 設計スタイル選択マトリクス

A.3 VBA向け責務設計テンプレート