トップダウン設計を三回で成熟させる

機能・データ・責務で、仮設の設計を運用できる構造へ育てる

Copyright © 2026 LWP 山中 一弘

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

記事要約

トップダウン設計は、一度上から分解すれば完成するものではない。

実務で設計を進めると、最初は画面や操作手順に沿って機能を分ける。これは自然で、説明もしやすい。しかし、そのまま実装すると、同じデータを読む処理、同じ検証、同じ集計、同じ保存処理が複数の関数に散らばりやすい。

そこで二回目の設計では、データを軸にして構造を組み直す。どの表を読むのか、どの項目を検証するのか、どの単位で保存するのかを見直し、データ操作を共通化する。

それでも設計はまだ終わらない。データ操作を整理しても、「なぜこの処理の組み合わせが必要なのか」という意味が見えにくいことがある。三回目の設計では、業務上の責務を軸にして、意味を持つ処理のまとまりを取り出す。ここで、単なる関数の集まりが、説明でき、再利用でき、変更に耐える構造へ変わる。

この記事では、トップダウン設計を「機能」「データ」「責務」の三回で成熟させる考え方を整理する。Excel VBAや業務マクロのように、画面、ワークシート、テーブル、手続き型コードが近い距離で混ざりやすい環境を念頭に、実務で使える設計の進め方としてまとめる。

本記事の対象とゴール

想定読者

本記事で得られること

1. トップダウン設計が一回で終わらない理由を説明できる。

2. 初回設計を、失敗ではなく仮設構造として扱える。

3. 機能軸、データ軸、責務軸の違いを理解できる。

4. UI、Logic、Storeの三層構造を、最初から押しつけるものではなく、設計が成熟した結果として捉えられる。

5. Excel VBAのような実務コードで、重複を見つけ、共通化し、業務ロジックへ育てる手順を持てる。

本記事で扱わないこと

先に結論

トップダウン設計は、機能を分けるだけでは完成しない。

最初の設計では、要求、画面、操作手順をもとに機能を分ける。この段階は必要である。いきなり抽象的な責務から入るより、何をしたいのかを見える形にできる。

しかし、機能軸だけで実装を進めると、同じデータ処理が複数の関数に散る。そこで二回目に、データ構造を軸にして処理を整理する。読み込み、検証、変換、保存といったデータ操作を共通化する。

さらに、データ操作の共通化だけでは、業務上の意味が見えない。三回目に、責務を軸にして、意味を持つ処理連鎖を取り出す。ここで、UI、Logic、Storeの層が自然に見えてくる。

つまり、三回設計するとは、同じことをやり直すことではない。視点を変えて構造を成熟させることである。

1. 設計は情報整理から始まる

1.1 道具より前に整理がある

Excelで表を作る。VBAでマクロを書く。フォルダを作る。ファイル名を決める。

これらは別々の作業に見えるが、根にある問題は同じである。情報に名前をつけ、置き場所を決め、関係を整理し、変化に耐える形にする作業である。

情報が整理されていない状態では、どれだけ便利な道具を使っても混乱する。ファイル名がばらばらなら検索できない。列名が曖昧なら計算の意味が分からない。シート構成に役割がなければ、どこを直せばよいか分からない。

プログラム設計も同じである。関数名、引数名、シート名、テーブル名、フォルダ名は、単なるラベルではない。設計の考え方を外へ出したものである。

1.2 名前づけは構造の出発点である

良い名前は、対象の役割を示す。悪い名前は、作った人の作業順や気分だけを残す。

たとえば、`処理1`、`処理2`、`データ作成` という名前では、何を入力し、何を判断し、何を出力するのかが分からない。一方で、`売上明細を読み込む`、`月次集計を作成する`、`請求対象を判定する` という名前なら、処理の責務が見える。

ただし、最初から完璧な名前を付けることは難しい。作り始めの段階では、まだ責務が見えていないからである。

ここに、トップダウン設計を三回行う理由がある。

最初は機能名でよい。次にデータ名が見えてくる。最後に責務名が見えてくる。名前の成熟は、設計の成熟とほぼ同じである。

2. なぜトップダウン設計は一回で終わらないのか

2.1 最初に見えているものは操作である

利用者の要求を聞くと、最初に見えるのは操作である。

月次集計を出したい。明細を取り込みたい。エラー行を確認したい。帳票を出力したい。別ファイルへ転記したい。

この段階では、要求は画面やボタンの単位で語られやすい。したがって、初回のトップダウン設計も、自然に機能単位になる。

これは悪いことではない。むしろ、最初の設計としては正しい。利用者の言葉に近く、何を作るのかを共有しやすいからである。

2.2 機能分割だけでは構造が安定しない

問題は、その機能分割を完成形だと思ってしまうことである。

機能ごとに関数を作ると、各関数はそれぞれ必要なデータを読み、必要な検証をし、必要な変換をし、必要な保存をする。すると、似た処理があちこちに現れる。

たとえば、月次集計にも明細出力にも、同じ売上明細の読み込みが必要になる。請求書作成にもエラー確認にも、同じ顧客コードの検証が必要になる。帳票出力にも転記ファイル作成にも、同じ日付範囲の判定が必要になる。

機能から見ると別々の処理でも、データから見ると同じ処理である。この視点のずれが、初回設計の脆さになる。

2.3 初回設計は仮設構造である

初回設計は、捨てるべきものではない。初回設計があるから、要求が見える。操作が見える。必要な入出力が見える。

ただし、初回設計は完成形ではなく仮設構造である。

仮設構造とは、最初に作る足場のようなものである。そこから実装の見通しを立て、重複を発見し、データ構造を見つけ、責務を抽出するために使う。

初回設計で重要なのは、早く作ることではなく、次の設計で見直せる形にしておくことである。

3. 第1回：機能軸で初期設計を作る

3.1 要求とUIから処理を分ける

第1回の設計では、要求、画面、操作手順をもとに処理を分ける。

Excel VBAであれば、ボタン、メニュー、シート操作、出力帳票などが入口になりやすい。利用者に説明するには、この単位が分かりやすい。

たとえば、売上処理のマクロなら、最初は次のように分ける。

Private Sub Btn月次集計_Click()

    ' 売上明細を読み込む

    ' 対象月で絞り込む

    ' 金額を集計する

    ' 集計表へ出力する

End Sub

Private Sub Btn請求書作成_Click()

    ' 売上明細を読み込む

    ' 顧客ごとにまとめる

    ' 請求対象を判定する

    ' 請求書シートへ出力する

End Sub

Private Sub Btnエラー確認_Click()

    ' 売上明細を読み込む

    ' 必須項目を検証する

    ' エラー一覧へ出力する

End Sub

この設計は、最初の説明としては分かりやすい。ボタンと処理が対応しているため、利用者にも開発者にも伝えやすい。

3.2 速いが、重複しやすい

機能軸の設計は、手が動きやすい。とりあえずボタンごとに処理を書けば、動くものが作れる。

しかし、実装が進むと同じ処理が増える。

この段階で、重複を単なるコピーとして放置すると、後から修正が難しくなる。

日付の判定ルールが変わったとき、月次集計だけ直して請求書作成を直し忘れる。顧客コードの形式が変わったとき、エラー確認だけ旧仕様のまま残る。こうした不整合は、機能軸だけで設計したコードに起こりやすい。

3.3 第1回の成果は「動く見取り図」である

第1回の設計で得るべきものは、完成コードではない。

得るべきものは、動く見取り図である。

どんな入口があるのか。どんなデータを使うのか。どんな出力が必要か。どの処理が似ているか。どの処理が同じデータを触っているか。

これらを見つけるために、第1回の機能設計がある。

4. 第2回：データ軸で構造を組み直す

4.1 関数を貫く共通データを見る

第2回の設計では、機能ではなくデータを見る。

売上明細、顧客マスタ、商品マスタ、請求条件、出力帳票、エラー一覧。これらのデータが、どの機能で使われているかを確認する。

すると、機能ごとに別々に見えていた処理の中に、共通のデータ操作があることに気づく。

これらは、ボタンの責務ではない。データを扱う責務である。

4.2 CRUD、変換、制約で分ける

データ軸で整理するときは、操作の種類を見るとよい。

まず、CRUDで考える。読む、作る、更新する、削除する。Excel VBAでは、削除よりも「クリアする」「書き戻す」「出力する」という表現になることも多い。

次に、変換を見る。シートのセル範囲を配列へ変換する。文字列の日付を日付型として解釈する。顧客コードを桁数固定の表現へそろえる。集計結果を帳票用の二次元配列へ変換する。

さらに、制約を見る。必須列があること。金額が数値であること。日付が対象期間内であること。顧客コードがマスタに存在すること。これらは、データの信頼性を支える条件である。

この三つで見ると、散らばっていた処理をまとめやすくなる。

4.3 Store層を作る

データ軸の整理では、Store層を作ると見通しがよくなる。

Store層は、Excelのシート、テーブル、ファイル、配列、辞書など、データの入出力に近い処理を担当する層である。ここでは、業務上の最終判断まではしない。まずはデータを安定して読み書きできる形にする。

たとえば、次のような関数へ分ける。

Public Function SalesStore_LoadRows(ByVal ws As Worksheet) As Variant

    ' 売上明細シートから明細行を読み込む

    ' 戻り値は二次元配列、または行オブジェクトの配列とする

End Function

Public Function SalesStore_ValidateColumns(ByVal rows As Variant) As Boolean

    ' 必須列が存在するかを確認する

End Function

Public Sub SalesStore_WriteReport(ByVal ws As Worksheet, ByVal reportRows As Variant)

    ' 帳票用に整形済みのデータをシートへ出力する

End Sub

この段階では、まだ業務ロジックを全部きれいに分けようとしなくてよい。

大事なのは、データの読み書きを各ボタン処理から外へ出すことである。これだけでも、重複はかなり減る。

4.4 扇構造で機能とデータをつなぐ

機能軸のままでは、ボタンごとにデータ処理が散らばる。データ軸で整理すると、複数の機能が同じStore関数を使うようになる。

これを上から見ると、扇のような構造になる。

月次集計、請求書作成、エラー確認という複数の機能が、下位にある共通のデータ操作へ向かって集まる。そして、そのデータ操作を通じて、同じ売上明細や顧客マスタへアクセスする。

この扇構造は、設計が一段成熟した状態である。

まだ完全ではないが、少なくとも「同じデータを同じ方法で扱う」構造ができる。これにより、列追加、形式変更、シート名変更などの影響範囲を狭くできる。

4.5 データ軸だけでは意味が不足する

ただし、データ軸で整理しても、まだ問題は残る。

読み込み、検証、変換、出力の関数はきれいに並んでいる。しかし、それらをどう組み合わせると、どの業務処理になるのかが見えにくい。

たとえば、次のような処理連鎖があるとする。

1. 売上明細を読み込む

2. 顧客コードを正規化する

3. 対象月で絞り込む

4. 請求対象外を除外する

5. 顧客別に集計する

6. 請求書用の形式へ変換する

これは単なるデータ操作の並びではない。「月次請求データを作る」という業務上の意味を持っている。

この意味を取り出すのが、三回目の設計である。

5. 第3回：責務軸で意味を抽出する

5.1 業務ロジックは意味を持つ処理連鎖である

業務ロジックとは、単に計算式が書かれている場所ではない。

業務上の意味を持った処理連鎖である。

請求対象を判定する。月次売上を確定する。異常明細を分類する。出力対象を決める。これらは、データ操作を組み合わせた結果として現れるが、データ操作そのものではない。

責務軸の設計では、この意味を持つまとまりに名前を付ける。

Public Function SalesLogic_BuildMonthlyReport(ByVal salesRows As Variant, ByVal targetMonth As Date) As Variant

    ' 対象月の売上を抽出する

    ' 顧客別に集計する

    ' 月次レポート用の行へ変換する

End Function

Public Function BillingLogic_BuildInvoiceRows(ByVal salesRows As Variant, ByVal customerRows As Variant) As Variant

    ' 請求対象を判定する

    ' 顧客別に請求行を組み立てる

    ' 出力用の並びに整える

End Function

Public Function SalesLogic_FindInvalidRows(ByVal salesRows As Variant) As Variant

    ' 業務ルールに照らして異常明細を抽出する

End Function

ここで重要なのは、関数名が「データをどう触るか」ではなく「業務上何を作るか」を表している点である。

5.2 類似処理を意味でまとめる

責務軸で見ると、同じような処理連鎖が複数の場所にあることに気づく。

たとえば、月次集計でも請求書作成でも、対象月で売上明細を絞り込む。エラー確認でも請求書作成でも、顧客コードの正当性を確認する。帳票出力でも転記ファイル作成でも、出力用の行配列を作る。

データ軸では、これらを小さな操作として共通化できる。責務軸では、さらに一段上げて「請求対象を作る」「月次集計対象を作る」「異常明細を分類する」といった意味でまとめる。

この段階で、設計は単なる部品集から業務構造へ変わる。

5.3 Logic層はUIとStoreの間に立つ

責務軸で抽出された処理は、Logic層に置く。

Logic層は、画面操作に依存しない。ワークシートのセル番地にもできるだけ依存しない。入力されたデータをもとに、業務上の判断、計算、分類、変換を行う。

実行入口は、次のように薄くできる。

Public Sub RunMonthlyReport()

    On Error GoTo ErrHandler

    Dim salesRows As Variant

    salesRows = SalesStore_LoadRows(ThisWorkbook.Worksheets("売上明細"))

    Dim reportRows As Variant

    reportRows = SalesLogic_BuildMonthlyReport(salesRows, DateSerial(2025, 5, 1))

    SalesStore_WriteReport ThisWorkbook.Worksheets("月次集計"), reportRows

    Exit Sub

ErrHandler:

    MsgBox "月次集計を作成できませんでした。" & vbCrLf & Err.Description, vbExclamation

End Sub

この例では、UIまたは実行入口は、読み込み、業務処理、出力を呼び出すだけである。月次集計の意味は `SalesLogic_BuildMonthlyReport` に集約され、シートの読み書きは `SalesStore_...` に分かれている。

これが、三回目の設計で得たい構造である。

5.4 責務が分かれると影響範囲が見える

責務軸で設計すると、変更時の影響範囲が見える。

シート名が変わったなら、Store層を見る。対象月の判定ルールが変わったなら、Logic層を見る。ボタンの配置やメッセージを変えるなら、UI層を見る。

どこを直せばよいか分かるということは、どこを直さなくてよいかも分かるということである。

実務では、この差が大きい。修正範囲が見えないコードは、毎回全体を疑う必要がある。修正範囲が見えるコードは、変更に対して落ち着いて作業できる。

6. 三層構造は最初に押しつけるものではない

6.1 UI、Logic、Storeは成熟の結果である

設計の教科書では、UI層、業務ロジック層、データ層を分けると説明されることが多い。

これは正しい。しかし、実務では最初からきれいに分けるのが難しい。

最初の段階では、何がUI固有で、何が業務判断で、何がデータ操作なのかがまだ見えていない。利用者の言葉は操作単位で出てくる。データの共通性は、実装を少し進めないと見えない。業務上の責務は、重複や処理連鎖を見ないと名前を付けにくい。

したがって、三層構造は最初に押しつけるものではなく、設計を三回見直した結果として現れるものだと考えるほうが実務的である。

6.2 各層の役割

三層を分けるなら、役割は次のように考える。

UI層は、利用者との接点である。ボタン、メニュー、入力フォーム、メッセージ、確認ダイアログなどを扱う。利用者から値を受け取り、処理結果を見せる。

Logic層は、業務上の意味を扱う。判定、計算、集計、分類、エラーの意味づけ、処理順序の組み立てを担当する。

Store層は、データの読み書きを扱う。Excelシート、テーブル、CSV、フォルダ、ファイル、配列、辞書などとの接点を担当する。

この三層が分かれると、コードの読み方が変わる。

UI層を読めば、利用者操作の流れが分かる。Logic層を読めば、業務ルールが分かる。Store層を読めば、データの持ち方と入出力が分かる。

6.3 三層化の目的は分類そのものではない

三層に分ける目的は、きれいな分類表を作ることではない。

目的は、変更に耐えることである。

同じデータ処理を一か所へ寄せる。業務判断をUIから切り離す。シート構成の変更が業務ロジックへ波及しないようにする。メッセージ変更で集計処理を壊さないようにする。

このために三層化する。

層を増やしたのに、変更時にどこを直すべきか分からないなら、その分類はまだ責務になっていない。

7. Excel VBAで三回設計を使う

7.1 ボタン処理を入口にしたままにしない

Excel VBAでは、ボタンのクリックイベントやシートイベントに処理を書き始めることが多い。

これは入口としては自然である。しかし、クリックイベントの中に読み込み、検証、集計、出力、エラー処理を全部入れると、すぐに保守しにくくなる。

最初はそれでもよい。第1回の設計では、操作の流れを確認するために、入口へ処理を並べてもよい。

ただし、そのまま完成にしない。第2回でデータ操作を外へ出し、第3回で業務ロジックを外へ出す。

7.2 関数名を変えながら設計を成熟させる

三回設計では、関数名も変わる。

最初は、`Btn月次集計_Click` の中に処理がある。次に、`LoadSalesRows`、`WriteMonthlyReport` のようなデータ操作名が出てくる。最後に、`BuildMonthlyReport`、`BuildInvoiceRows`、`FindInvalidRows` のような業務責務名が出てくる。

この名前の変化を嫌がる必要はない。

むしろ、名前が変わるのは、設計の視点が変わった証拠である。

ただし、名前づけには一貫性が必要である。読み込みは `Load`、書き込みは `Write`、作成は `Build`、判定は `Is` や `Can`、抽出は `Find` や `Filter` など、プロジェクト内で語彙をそろえる。

語彙がそろうと、関数一覧を見ただけで役割が分かる。

7.3 配列や辞書は層の境界を明確にする

Excel VBAでは、シートを直接触る処理が増えやすい。どの関数でも `Range` を読み、どの関数でもセルへ書く形になると、Store層が全体へ広がってしまう。

これを防ぐには、シートから読み込んだ後の表現を決める。

二次元配列で渡すのか。辞書で渡すのか。行ごとの構造体に近い形で渡すのか。プロジェクトの規模に応じて選べばよい。

重要なのは、Logic層がセル番地を知らなくてもよい状態にすることである。

Public Function SalesLogic_CalcTotalAmount(ByVal salesRows As Variant) As Currency

    Dim total As Currency

    Dim i As Long

    For i = LBound(salesRows, 1) To UBound(salesRows, 1)

        total = total + CCur(salesRows(i, 5))

    Next

    SalesLogic_CalcTotalAmount = total

End Function

この例は単純だが、考え方は重要である。Logic層は、どのワークシートの何行目から読んだかを知らない。必要な形に整えられたデータを受け取り、業務計算だけを行う。

7.4 共通化しすぎない

三回設計は、何でも共通関数にするための考え方ではない。

一度しか出てこない処理を無理に抽象化すると、かえって読みにくくなる。似ているようで意味が違う処理を一つにまとめると、引数が増え、条件分岐が増え、結局分かりにくい共通関数になる。

共通化する対象は、同じ責務を持つものに限る。

同じデータ操作ならStore層でまとめる。同じ業務判断ならLogic層でまとめる。同じ表示処理ならUI層でまとめる。

似ているコードをまとめるのではなく、同じ意味を持つ処理をまとめる。この違いが重要である。

8. 三回設計の実務手順

8.1 まず機能一覧を作る

最初に、利用者の要求から機能一覧を作る。

ここでは、まだきれいな層分けを求めない。操作の言葉でよい。

この段階で大事なのは、要求を落とさないことである。

8.2 次にデータ一覧を作る

機能一覧ができたら、各機能が触るデータを並べる。

そして、どの機能がどのデータを読むのか、書くのか、変換するのかを確認する。

ここで重複が見える。同じデータを複数の機能が触っているなら、Store層へ切り出す候補である。

8.3 最後に責務一覧を作る

データ操作が見えたら、業務上の責務を探す。

ここでは、処理手順ではなく意味を見る。

たとえば、「売上明細を対象月で絞り、顧客別にまとめ、請求対象を判定する」という連鎖は、「請求データを作成する」という責務かもしれない。

この名前を付けることで、Logic層が見えてくる。

8.4 三つの問いで見直す

日常の設計では、次の三つの問いを使うとよい。

1. これは機能なのか、データ操作なのか、業務責務なのか。

2. この処理は、どのデータ構造に依存しているのか。

3. この単位に名前を付けるなら、操作名になるのか、データ名になるのか、責務名になるのか。

この問いを繰り返すだけで、設計の見え方は変わる。

9. 情報整理としての三回設計

9.1 ファイル、フォルダ、シートにも同じ考え方が使える

三回設計は、プログラムだけの話ではない。

ファイル整理にも、フォルダ構成にも、Excelシート設計にも使える。

最初は用途で分ける。次にデータの種類で分ける。最後に責務やライフサイクルで分ける。

たとえば、フォルダを「集計」「出力」「確認」のような作業機能で分けることがある。これは初回設計としては分かりやすい。しかし、データの種類や更新タイミングが混ざると、後で探しにくくなる。

そこで、入力、作業、出力、履歴、参照資料といったデータの性質で見直す。さらに、正式版、作業中、旧版、証跡といった責務で見直す。

これは、機能軸、データ軸、責務軸の考え方そのものである。

9.2 履歴とバージョンも設計である

情報は時間とともに変わる。

設計書も、Excelブックも、マクロも、一度作って終わりではない。修正され、比較され、旧版が参照され、次の版へ引き継がれる。

したがって、履歴とバージョンも設計の一部である。

ファイル名に日付を入れるのか、版番号を入れるのか、正式版と作業版をどう区別するのか。これは単なる事務処理ではなく、情報の変化に耐えるための構造設計である。

プログラム設計でも同じである。関数名、層、責務、変更履歴が整理されていると、後から見た人が設計の意図を追える。

9.3 構造は共有資産になる

設計が成熟すると、個人の頭の中にあった判断が外へ出る。

どの層に何を書くか。どの名前を使うか。どのデータ操作を共通化するか。どの責務をLogic層へ置くか。

これらがそろうと、設計は共有資産になる。

個人だけが分かるコードではなく、チームで読み、直し、引き継げるコードになる。Excel VBAのような小さな業務マクロでも、この差は大きい。

10. まとめ

トップダウン設計は、一回で完成させるものではない。

第1回では、要求、画面、操作手順をもとに機能を分ける。これは、何を作るかを見える形にするために必要である。

第2回では、データを軸にして構造を組み直す。読み込み、検証、変換、保存を整理し、複数の機能から使える形にする。

第3回では、責務を軸にして意味を抽出する。業務上の判断、計算、分類、作成をLogic層へまとめ、UIやStoreから切り離す。

この三回は、同じ設計をやり直す作業ではない。機能、データ、責務という異なる視点で、設計を成熟させる作業である。

最初から完璧な三層構造を作ろうとしなくてよい。まず機能を見える形にする。次にデータの重複を見つける。最後に業務上の意味を取り出す。

その順序を持てば、Excel VBAの業務マクロでも、設計は場当たり的な手続きの集まりから、説明でき、直せて、引き継げる構造へ変わる。

出典メモ

この記事は、LWP内部資料「トップダウン設計はなぜ3回繰り返すのか」1版および2版を主な素材とし、「情報の整理学」目次に含まれる情報整理、名前づけ、構造化、履歴設計の観点を補助素材として再構成したものです。

2版の内容を主軸に、1版で示された機能、データ、責務による設計進化の骨格を確認し、読者向けの記事として章立て、説明、Excel VBAでの模式例を補いました。

同名の音声素材は、本文から自動作成された派生物であるため、本文生成の一次ソースとしては扱っていません。