三回設計法と歴史的設計理論

～Yourdon・DeMarco・Jackson・DDDとの対応を通じて～

要約

本稿では、ソフトウェア設計における「三回のトップダウン設計」（機能・データ・責務の三段階）という実践的な設計論に対して、Yourdon、DeMarco、Jacksonといった歴史的設計理論がどのように対応しているかを考察する。第1回設計は処理・画面構成を起点とする機能分割であり、Yourdon/DeMarcoの構造化分析手法が強く影響している。第2回設計では、見えてきたデータ構造に基づき関数を再編成する段階で、Jacksonの構造順設計やParnasの情報隠蔽原則が有効である。第3回設計では、関数やモジュールの責務と意味を再定義する段階であり、ここにDomain-Driven Design（DDD）の視点を限定的に導入することで、設計の成熟と業務モデルへの対応が飛躍的に向上することが確認される。本稿は、三回設計法を構造化言語に適用する際の理論的背景と実務的意義を、古典理論と現代的手法の接点から明らかにするものである。

1.はじめに

1.1 三回設計法とは何か

ソフトウェア設計においては、初回の設計だけで完成された構造を得ることは稀である。特に業務アプリケーションや画面を伴うシステムにおいては、初期の構造はしばしば断片的な機能要件や操作イメージをもとに構築されるため、設計の全体像は見えにくい。こうした現実を踏まえ、「三回のトップダウン設計」という実践的アプローチを提案する。これは、機能設計→データ設計→責務設計の三段階を順に踏むことで、より深い構造的理解と整合性を得る手法である。第1回設計では主に画面や処理フローに基づいて構造が形作られ、第2回設計ではそこから抽出されたデータ構造によって関数の再配置が行われる。第3回設計では、各関数やモジュールの「存在意義」と「意味」に着目し、構造に論理的な説明力を与える段階である。

1.2 なぜ設計は繰り返されるのか

設計が一度で済まない最大の理由は、「最初の設計では見えていなかったことが、設計作業を通じて初めて可視化される」ためである。たとえば初回設計では、ユーザーが求める操作手順や画面レイアウトを中心に機能を配置するが、その背後にあるデータの構造や更新規則、さらには共通処理の抽出可能性などは、機能の集積を見て初めて明らかになる。したがって、設計は発見のプロセスであり、複数回に分けて行われることが合理的である。また、初回の設計で見落とされがちな整合性や責務の所在も、再設計の中で明確化されていく。設計の繰り返しは、単なる手戻りではなく、構造を成長させるための必然的プロセスである。

1.3 本稿の目的と視点

本稿の目的は、「三回設計法」という実践的設計手法に対し、歴史的に確立された設計理論との対応関係を明らかにすることで、その理論的裏付けと実務的意義を整理することにある。具体的には、YourdonやDeMarcoの構造化分析手法、Jacksonの構造順設計、Parnasの情報隠蔽原則、さらに現代のDomain-Driven Design（DDD）といった各種設計理論が、三回設計の各段階にどのように関係し、補完しうるかを考察する。また、これらの理論が構造化言語やVBAのような実装環境にも応用可能であることを示すことで、読者が設計技術を単なるコード上の技巧ではなく、普遍的な構造理解の技術として認識する手助けとしたい。

2.第1回設計と構造化分析の理論

2.1 処理・画面駆動による初期設計

第1回設計は、開発プロジェクトにおける最初の設計段階であり、ユーザーの操作や画面構成に着目して機能を定義するフェーズである。この段階では、業務フローや画面遷移、入力・出力項目に基づいて「何をする必要があるか」が中心的な関心となる。たとえば、売上入力、商品登録、集計出力といった具体的な処理単位が明示され、それらを構成する操作ステップが一連の処理フローとして記述される。設計者はこの段階で、ユーザーの視点に立った「使える設計」を目指すため、処理駆動型、あるいは画面駆動型の構造を自然と選択することになる。このような初期設計は、要件定義とプログラム設計の橋渡しとして有効であり、構造の出発点としての役割を担う。

2.2 DeMarcoのDFDと機能分割

この初期段階においては、DeMarcoによって提唱されたデータフロー図（DFD）が特に有効である。DFDは、システム内外のデータの流れと処理の関係を可視化する図式であり、処理単位（プロセス）、データストア、外部実体、データフローの4要素によって構成される。DFDを用いることで、各処理がどのようなデータを受け取り、どこへ渡しているかを明示できるため、システム全体のデータ流通を俯瞰できる設計が可能となる。特に中規模業務アプリケーションにおいては、画面＝処理単位＝DFDのプロセスとみなすことで、機能分割の骨格が自然に形成される。DFDの階層化を活用することで、詳細設計へと展開する足がかりも得られる。

2.3 YourdonのStructured Designと初期構造図

Yourdonは、DeMarcoと同様に構造化分析の先駆者であり、特にStructured Design（構造化設計）の手法を通じて、モジュール化と制御構造に焦点を当てた設計技法を確立した。Yourdonの設計手法では、モジュール間の制御関係や呼び出し階層を明確にし、処理の順序性と分担を構造図（Structure Chart）によって表現する。このアプローチは、初期設計の段階でよく用いられる「画面ごとの処理群」や「操作フローの階層化」を表現するのに適しており、プログラム構造との対応も取りやすい。構造図は、機能のまとまりと制御構造の視覚化を通じて、初期設計に一定の秩序と予測性を与える。

2.4 この段階の利点と限界

第1回設計は、利用者視点に即した設計が可能であり、初動の可視化、関係者間の合意形成、実装準備の迅速化という点で大きな利点をもつ。特にプロトタイピングとの親和性が高く、画面ベースで早期に試作品を提示しやすい点は実務的に有効である。しかし一方で、処理や画面を起点とした機能分割では、背後にあるデータ構造や更新規則が見落とされやすく、設計の整合性が保証されないという弱点もある。また、画面や処理単位に引きずられて冗長な処理が増殖しやすく、関数間の再利用性や保守性に乏しい構造になる危険性も高い。したがって、この段階の設計はあくまで「第一の構造」であり、後続のデータ設計や責務設計を前提とした仮構として位置づけるべきである。

3.第2回設計とデータ構造による再編

3.1 関数の背後に現れるデータ構造

第1回設計によって機能や画面単位で構築された構造は、一定の可視性と操作性を提供するが、その内部にはしばしば重複処理や整合性の欠如が潜在している。これを解消するために、第2回設計では、関数群の背後にあるデータ構造の分析を出発点とする。具体的には、各処理がどのようなデータ項目を参照・更新しているかを可視化し、共通するデータの存在を基盤として処理の再配置や統合を行う。ここで現れるのは、表面的な機能分割とは異なる、より深層の「構造的実体」である。データ項目の関係性、更新の順序、保持形式などの分析により、関数が従属するべき構造が明確になり、設計の再構成が可能となる。

3.2 Jackson Structured Programmingの適用可能性

この段階で特に有効なのが、Jackson Structured Programming（JSP）である。JSPは、データの論理構造を起点にして処理構造を導出する設計手法であり、データとプログラムの構造対応を重視する。たとえば、帳票データや階層的な明細情報を扱う場面では、データの入れ子構造や繰り返し構造に応じたループや条件分岐が自動的に設計される。VBAのような構造化言語では、ループ・条件・サブルーチンの明示的な記述により、JSPの思想を比較的忠実に表現できる。JSPは、初期の機能駆動設計では見えなかった「構造に基づく正当な処理順序」を導出する点で、第2回設計における構造整備の指針となる。

3.3 Parnasのモジュール設計原則との一致

Jacksonと並んで第2回設計に影響を与えるのが、Parnasのモジュール設計原則である。Parnasは、モジュールを「情報の隠蔽」と「変更の局所化」のための単位と定義した。すなわち、データ構造の内部表現を隠し、その操作を関数インターフェースに限定することで、全体構造の柔軟性と拡張性を担保する。この思想は、データ構造を基準に関数を再編する第2回設計に自然に適合する。たとえば、日付範囲のフィルタ処理、明細行の整形処理、外部マスタとの突合といった共通的なデータ操作は、データ型単位にまとめてモジュール化されるべきである。このモジュール化により、構造の整合性が確保され、変更の影響範囲が明確になる。

3.4 データによる処理統合と整合性の確保

第2回設計の本質は、機能の粒度や順序をいったん解体し、データ構造に適合した形で処理を再構成することである。この過程では、同一のデータ構造を参照する複数の関数を統合したり、同じ整合性制約を適用すべき処理を一体化したりする設計判断が求められる。たとえば、入力チェックと集計処理が同一データ構造に基づく場合、それらは一つのモジュールとしてまとめるべきである。このような統合によって、データの不整合や処理の重複といった設計上の弱点が解消され、構造としての一貫性が高まる。また、データを中心とした設計は、後の責務再定義やドメインモデリングに向けた基礎的な布石ともなる。データは処理の出発点であると同時に、構造を再編するための鍵である。

4.第3回設計と責務の意味づけ

4.1 関数の文脈と「なぜそこにあるのか」

第2回設計によってデータ構造を中心としたモジュール再編が完了すると、関数や処理の見かけ上の整理はある程度達成される。しかしこの時点では、関数が「何をしているか」は明確でも、「なぜその関数がその場所にあるのか」「どのような役割を果たすべきか」といった意味的な文脈は依然として曖昧である。第3回設計では、この「意味の問い直し」に着手する。たとえば、同一のデータを処理する関数群の中でも、計算を担う関数と制御を担う関数では、設計上の意味や責任が異なる。この段階では、処理の技術的配置ではなく、業務やモデルの観点から関数やモジュールの存在理由を定義し直すことが中心課題となる。設計者はここで初めて、構造に意味を与える責任に向き合うことになる。

4.2 共通処理の抽出と意味的再配置

第2回設計の段階で、データ構造に基づく処理の統合や整理はすでに達成されており、重複したコードや無秩序な処理の乱立といった問題は技術的には解消されている。しかし、そこに現れてくるのは、複数の機能にまたがって同様の業務処理が「意味的に」繰り返されているという構造である。たとえば、入力・承認・出力といった一連の業務単位が、異なる画面や関数に同様の流れで存在している場合、それぞれはデータ的には独立していても、業務上は同質な責務を果たしている。このような観点から、第3回設計では、機能単位に埋め込まれていた業務的意味を抽出し、それに基づいて処理を再配置する。ここで問われるのは、「この処理はどの業務単位に属するのか」「どの範囲で責任を担うべきか」という意味の整理である。業務のまとまりとして再構成された構造は、技術的な共通化よりも上位にある責務の分離を可能とし、設計に階層性と意味的整合をもたらす。

4.3 Clean Architectureとの親和性

このような責務中心の再設計は、Clean Architectureが提唱する「関心の分離」に非常に近い。Clean Architectureでは、エンティティ、ユースケース、インターフェースといった責務ごとの層を明示し、それぞれが独立した意図と制約を持つことを強調する。VBAのような構造化言語環境においては、物理的なレイヤー分離は難しいが、論理的な層構造としてClean Architectureの考え方を援用することは可能である。たとえば、ドメイン知識に基づいた処理と、UIに依存する処理とをサブルーチンレベルで明確に分離することで、コードの構造に意図を与えることができる。Clean Architectureは、責務に基づいた構造化再設計の目安として活用できる。

4.4 Domain-Driven Design（DDD）の限定的導入

第3回設計の段階で、業務の意味や文脈を反映させるうえで、DDDの一部概念を限定的に導入することが有効となる。特に、集約（Aggregate）や値オブジェクト（Value Object）といった概念は、構造を業務の単位で整理するための指針となる。VBAや構造化言語においては、オブジェクト指向の完全な実装は難しいが、関数命名やサブルーチン分割において業務単位の語彙や文脈を取り入れることで、実質的にドメイン駆動の設計を行うことが可能である。ただし、DDDの全体像をそのまま持ち込むと過剰な抽象化や技術的過負荷を招くため、文脈・エンティティ・責任という観点に限定して導入すべきである。DDDはあくまで業務理解を構造に反映する手段であり、目的ではない。設計の意味付けを支援する範囲での適用にとどめることで、設計と実装の整合性が保たれる。

5. 理論の統合的整理と実務応用

5.1 三回設計法に対応する理論の整理表

三回設計法は、それぞれの段階において対応する歴史的理論を持つ。第1回設計では、処理や画面構成を中心とする機能駆動型の設計であり、DeMarcoのDFDやYourdonの構造図が対応する。第2回設計では、データ構造を基盤として処理を再編することから、Jacksonの構造順設計（JSP）やParnasの情報隠蔽に基づくモジュール設計が中心となる。第3回設計では、責任と意味の再定義が焦点となるため、Clean ArchitectureやDDDの一部概念が補完的に適用される。これらの理論を単独で適用するのではなく、三回設計の各段階に応じて選択的に統合することによって、理論と実務の双方に整合した設計を実現できる。これにより、設計の妥当性が後からでも説明可能な、構造的かつ意味的に納得のいく成果物となる。

5.2 DDDを入れるべき範囲と入れすぎのリスク

DDDは非常に強力な設計理論であるが、全面的な導入は実装環境によっては過剰となる危険がある。特にVBAやローコード環境では、オブジェクト指向の構文的制約やフレームワークの不在により、完全なエンティティやリポジトリの設計が困難である。そこで有効なのは、DDDの「語彙統一」「責務による構造化」「ドメイン文脈の区分」といった概念を、関数設計や命名、処理単位の構造化に限定的に導入することである。たとえば、サブルーチン名に業務ドメインの語彙を反映させるだけでも、責務の分離とモデル理解は大きく前進する。一方、DDDを機械的に適用して「ユビキタス言語」や「境界づけられたコンテキスト」を無理に導入すると、かえって冗長性が生まれ、構造が複雑化する。必要なのは、手法としてのDDDではなく、設計思想としてのDDDの慎重な抽出である。

5.3 VBAやローコード環境への適用視点

VBAやローコード環境は、構造化やモジュール化が必ずしも強制されないため、設計者の技術的素養によって設計品質が大きく左右される。そのため、三回設計法のような構造的な思考プロセスは極めて有効である。第1回設計ではユーザーフォームやシート構成を処理単位として捉え、第2回設計では表構造やリストオブジェクトを起点にデータ整合性を意識した関数群を再編成する。第3回設計では、共通処理や業務モデルに基づいて関数を分類し直し、責任を明確化する。これにより、柔軟だが混沌としやすいローコード環境でも、論理的な構造を維持したまま拡張性のある設計が可能となる。技術的な制約の多い環境にこそ、設計思想の適用が必要とされる。

5.4 設計思想の普遍性と実装環境の差異

設計における理論は、その多くが抽象的で実装環境に依存しない普遍性を持っている。一方で、現場での実装環境は、構文、IDE、制約、運用体制などによって多様であり、理論の適用には翻訳と調整が求められる。たとえば、Parnasのモジュール設計原則は、JavaであれVBAであれ、情報の隠蔽と変更の局所化という価値を同様に提供するが、それをどう実装するかは環境に依存する。したがって、設計思想を単なる技法の集合として受け取るのではなく、抽象的な価値基準として把握し、それを現実の環境に応じて適切に地ならしする必要がある。本稿が示す三回設計法は、こうした設計思想と実装現場との橋渡しを意図しており、理論と実務を分断せず統合的に活用するための設計補助線となる。

6.おわりに

6.1 理論と実践をつなぐ視点の意義

本稿では、三回のトップダウン設計という実務的アプローチを軸に、Yourdon、DeMarco、Jackson、Parnas、そしてDDDなどの設計理論との対応関係を整理してきた。これらの理論は、いずれも一時代を築いたものであり、単独での適用には限界があるものの、三段階の設計プロセスに沿って位置づけ直すことで、実務的な文脈の中に有機的に統合することが可能となる。理論は抽象的で普遍性を持つがゆえに、そのままでは現場に適用しにくい。逆に実務は具体的で制約に富み、理論的な整合を欠いたまま進行しがちである。この断絶を埋める視点こそが、三回設計法の本質的な意義であり、理論と実践を一方向に押し付けるのではなく、相互に照らし合わせる設計態度が求められる。

6.2 「構造を繰り返し見る」ことの設計的価値

設計において本当に重要なのは、一度きりの設計で完成を目指すことではなく、同じ対象を複数の角度から見直し、構造の奥行きと整合性を発見していくプロセスである。初回設計では処理や画面構成のような表層的な視点が中心となるが、繰り返し設計する中で、データ構造や責務といったより深い層が明らかになっていく。この「構造を繰り返し見る」という姿勢は、設計を単なる図面づくりではなく、意味と意図を宿した知的営為として捉える上で不可欠である。複数回の設計は無駄ではなく、むしろ設計の成熟に必要なステップであり、そこで得られる構造理解は、保守性・拡張性・説明可能性といった設計品質の源泉となる。本稿が示した三回設計法は、その繰り返しの中にこそ、設計の本質的価値が宿ることを明らかにするものである。