チェックはどこで行うか？

～チェック処理の責任配置と三回設計法に基づく設計進化～

要約

本稿では、関数分割において頻出する「チェック処理（たとえばレコード件数0件時の処理）」を、呼び出し側に持たせるか、呼ばれる側に持たせるかという設計上の問題を扱う。前半ではこの問いに対して、純粋関数主義・防御的プログラミング・責務分離の各観点から整理し、チェックは単なる制御文ではなく、「責任の所在を明示する構造要素」であることを示す。

後半ではこの議論を、著者が提唱する「トップダウン設計三回説」の視点──機能・データ・責務という三軸に基づいた段階的設計手法──に適用することで、設計の成熟過程に応じてチェックの配置戦略がどのように進化するかを具体的に検討する。チェック処理もまた、構造化と意味付けを通じて責務として再構成されるべき対象であるという視座を提供する。

第1章　はじめに──関数分割とチェック処理の責任問題

1.1 レコード0件チェックという設計上の分岐点

関数を分割する際、純粋な処理ロジックを抽出することは比較的容易である。一方、入力の妥当性をどこで確認するかという問題は、設計判断としてしばしば難問となる。その代表例が、「レコード件数が0件の場合に処理を実行すべきかどうか」という判断である。

たとえば、ある関数がレコードを正規化・整形する役割を持っているとする。このとき、与えられるデータが空であった場合にどこで対応するかは、実装者の方針によって異なる。呼び出し側が0件を検出して処理を中断する実装もあれば、呼ばれる関数自身が「件数が0件であれば即時終了」などの処理を含む設計もある。

この判断の違いは、表面的にはスタイルや慣習の違いに見えるかもしれないが、実際には「どの関数が何を前提にし、何を責任として担っているか」という設計上の責務の割り当てに関わる深い問題である。つまり、チェック処理の所在は、コードの動作以前に、設計の構造をどう理解し、どう語るかという視点を反映しているのである。

1.2 チェック処理の責任構造としての意味づけ

呼び出し側で件数チェックを行う設計は、処理関数を「前提条件が満たされていれば正しく動作する純粋関数」として保つことができる。これは関数型プログラミングにおける思想とも整合しており、再利用性やテストのしやすさといった観点で非常に優れている。

一方、呼ばれる関数の内部にチェック処理を組み込む方式は、いわゆる防御的プログラミングに相当する。実行時の安定性を担保し、予期しない入力にも対応できる堅牢性を実現するが、関数の内部に複数の責務が混在するという構造的欠点を持つ。

また、第三の選択肢として、チェック処理を独立した「ガード関数」や「前提保証関数」として切り出す設計も存在する。この方式では、チェックは明示的な責任としてコードに表現され、設計の可読性と保守性が向上する。

以上のように、チェック処理は単なる実装上の技巧ではなく、設計構造における責任の所在を問うものである。本稿では、こうした問題を一般的な原則として整理した上で、著者が提唱する「トップダウン設計三回説」の各段階においてチェックの意味と配置がどのように変化するかを構造的に論じていく。設計とは、構造に責任を埋め込む行為であり、チェックはそのもっとも端的なしるしである。

第2章　チェック処理はどこに持たせるべきか──3つの原則

チェック処理の配置を考える際、設計者はしばしば複数の対立する原則の間で判断を迫られる。本章では、関数分割におけるチェック処理の責任の所在を明確化するために、代表的な三つの設計原則──純粋関数主義、防御的プログラミング、責務分離設計──を比較し、それぞれの特徴と前提を明らかにする。

2.1 純粋関数主義：呼び出し側に持たせる

純粋関数主義の立場では、関数は「副作用を持たず、同じ入力に対して常に同じ出力を返すもの」として定義される。この原則に従うならば、入力データの件数チェックのような「前提条件の確認」は、呼び出し側が責任を持つべき処理である。関数内部では前提が満たされていることを仮定し、その上で最小限の変換処理のみを行う。こうすることで、関数の再利用性、テスト容易性、予測可能性が飛躍的に向上する。

たとえば「NormalizeRecords」という関数が「1件以上のレコードが存在すること」を前提としているならば、それを保証するのは関数の外部であるべきである。処理のロジックに集中し、関数の目的と入力条件を明示的に契約として記述する。この設計方針は、構造の透明性を重視する設計者にとって極めて有効である。

2.2 防御的プログラミング：呼ばれる側に持たせる

防御的プログラミングは、関数やモジュールが入力の正当性を自ら検証し、問題がある場合は自律的に対応することを原則とする設計思想である。この方式では、呼び出し元が前提条件を満たしていない場合でも、関数が想定外の入力に対して破綻せず、適切に対処するよう設計される。たとえば、入力が0件なら即時に空の出力を返す、もしくは処理をスキップするなどのロジックを関数内部に組み込む。

このアプローチは、運用環境における堅牢性を高める効果がある。特に、複数の呼び出し元が存在し、入力の妥当性を一貫して保証できない場合に有効である。ただし、関数内部に制御ロジックが増加するため、処理本来の意図が不明瞭になる危険もある。さらに、関数ごとに異なる防御方針が取られると、設計全体としての一貫性が損なわれる可能性がある。

2.3 責務分離設計：チェックを明示的に切り出す

純粋関数主義と防御的プログラミングのいずれにも課題がある場合、第三の選択肢として「責務分離設計」が提案される。この方式では、チェック処理を機能関数にもデータ処理関数にも組み込まず、独立した「ガード関数」や「前提保証関数」として明示的に設計する。これにより、チェックは構造上の責務として明示化され、関数設計の意図が明確に保たれる。

たとえば「EnsureRecordsExist(rs)」のような関数を用意し、すべての呼び出し元がこの関数を通じて件数の有無を確認することで、構造の一貫性と再利用性を両立できる。こうしたチェック関数群は、プロジェクト内の設計ガイドラインとして整備されることが望ましい。

この設計方針の利点は、チェック処理を「処理の一部」ではなく、「意味ある前提」としてコード構造に組み込める点にある。チェックは単なる補助処理ではなく、構造化された責務の一種であるという視点が、設計の成熟度を高める。

2.4 原則の比較と選択基準（可読性・再利用性・保守性）

これら三つの設計原則は、いずれも一長一短がある。純粋関数主義は構造的に洗練されているが、入力保証が呼び出し側の責任となるため、複数の箇所に同一のチェックが散在する恐れがある。防御的プログラミングは堅牢性に優れるが、関数内部の責務が肥大化しやすく、構造の透明性が損なわれる。一方で、責務分離設計は構造的整合性を確保できるが、設計コストや習慣化の負担が発生する。

選択基準としては、次の三点が挙げられる。

第一に「可読性」。関数の責務が明確であるか、意図が他者に伝わるかどうか。
第二に「再利用性」。同じ処理や同じチェックが他の関数でも必要になるか。
第三に「保守性」。処理の変更や前提条件の追加に対応できる柔軟性があるか。

これらを総合的に勘案し、プロジェクトの規模、関数の性質、開発体制に応じて、最適な方針を選定すべきである。設計は原則の適用ではなく、状況に応じた構造的判断の積み重ねである。

第3章　責任としてのチェック──設計判断フレームワーク

チェック処理をどこに配置するかという設計判断は、最終的には「そのチェックは誰の責任か」という問いに帰着する。本章では、チェック処理を責任構造の観点から分類・整理し、層別構造や意味の構造に基づいて、設計判断を体系化するためのフレームワークを提示する。

3.1 入力妥当性チェックの分類（技術的 vs 業務的）

まず最初に考えるべきは、そのチェックが技術的妥当性を保証するものか、業務的前提を保証するものかという分類である。

技術的チェックとは、Nullの存在、有効なデータ型、I/Oの成功可否、オブジェクトの存在確認など、プログラムとして動作可能であることを保証する最低限の条件である。これらは通常、Store層やFramework層で行われ、破損や異常を早期に検出するためのものである。

一方、業務的チェックとは、件数が1件以上あること、特定のフラグが立っていること、特定のフィールドが埋まっていることなど、ビジネスルールとして処理を実行するに足る条件が整っているかを判断するものである。これはアプリケーションロジックの一部であり、単なるI/O検査ではない。

この分類により、同じ「チェック処理」であっても、設計上の責任と配置先は根本的に異なることが明らかになる。

3.2 層別構造との対応（UI／Logic／Store）

三層構造（UI／Logic／Store）の視点を導入すると、チェック処理の責任配置はより明確になる。

UI層では、主に形式的・入力的チェックが行われる。未入力の警告、選択肢の未指定、フォーカス制御など、ユーザー操作の正当性を確認する責務を担う。

Logic層では、業務的妥当性の確認が行われる。対象データが意味的に有効であるか、処理前提が満たされているかなど、業務責任を引き受ける判断が求められる。

Store層では、データ存在や技術的健全性の検証を行う。接続失敗、空データ、整合性エラーなど、システム的障害に備えるチェックが該当する。

このように、チェック処理は単に「早めに書く」ものではなく、どの層の責任として実装されるべきかを意識する必要がある。

3.3 チェックを責務として捉える視点

チェック処理を「構文」や「補助処理」として軽視すると、設計構造は容易に破綻する。むしろ、チェックこそが構造を意味づけるための責務であるという視点が重要である。

たとえば「EnsureRecordsExist(rs)」のような関数は、「この処理の前提として、対象となるレコードが存在するべきである」という業務的責任の明文化である。この責任が明示されていることで、関数呼び出しの文脈が明快になり、構造的な整合性も担保される。

責務とは、処理単位の外部との契約であり、前提と保証によって構成される。チェック処理はそのうちの「前提」の部分を明示するものであり、処理の文法ではなく処理の立場を明らかにする構造的要素である。

3.4 処理の意味を構造に織り込む

責任を明確化するためには、処理を構文ではなく「意味のあるまとまり」として構造に織り込む必要がある。たとえば、「集計を行う処理」は単に数値を加算するのではなく、「有効な明細が存在していること」を前提とする。これを構造に取り込むには、処理の冒頭に前提チェックを明示的に配置し、その責任が処理構造の一部であることを可視化することが求められる。

このような視点から再構成された関数は、単に「動く」コードではなく、「意味を持って説明できる」コードとなる。チェック処理は、その意味構造を支える柱の一つであり、設計における第一級の構成要素として扱われるべきである。

第4章　設計三回手法におけるチェック処理の進化

設計が進化するにつれて、処理やデータの構造だけでなく、チェック処理の位置づけもまた変化する。本章では、著者が提唱する「トップダウン設計三回説」の三段階──機能軸・データ軸・責務軸──において、チェック処理がどのように現れ、どのように再配置されるべきかを考察する。チェックとは単なる実装上の補助処理ではなく、設計の成熟に伴って再構成されるべき構造的責任である。

4.1 第1回設計（機能軸）：UI操作内に埋め込まれたチェック

初期設計では、ユーザー操作や画面単位で関数が分割されるため、チェック処理はしばしばUIイベント関数の中に局所的に埋め込まれる。たとえば「検索ボタンを押したときにレコードが0件ならメッセージを出して中断する」といった処理は、機能関数の中に直接記述されることが多い。

この段階では、チェックは「処理の流れを止める条件分岐」として認識されており、構造的責任として整理されていない。設計者は業務の流れに沿って自然に処理を並べていくため、チェックもその中に溶け込む。結果として、同一の前提条件チェックが複数のUI操作に重複して記述されるという構造的問題が生じる。

この重複は設計上の問題であると同時に、将来的な仕様変更への脆弱性を意味する。処理の妥当性はその機能固有の責任ではなく、むしろ共通する業務制約に基づくものであるにもかかわらず、その抽象化が行われていないのである。

4.2 第2回設計（データ軸）：データ変形関数への混入

第二回目の設計では、同一のデータ構造を扱う処理が関数として共通化され、構造の再利用性が向上する。その過程で、レコード変形やフィルタリングといった処理が、専用の変換関数やAPIとして切り出されるようになる。この段階では、機能関数からチェック処理が分離され、代わりに変形関数の内部にチェックが組み込まれるようになる。

たとえば「NormalizeRecords」という関数の内部で、「もし0件ならば処理をスキップする」といったロジックが追加されるケースがこれに該当する。この構造は、一見すると再利用性と堅牢性を両立しているように見えるが、実際には「変形処理」という純粋な責務と、「入力妥当性確認」という別種の責務が混在している。

この混入は、一見保守的だが構造的に曖昧な設計である。データ処理関数が、本来持つべき純粋な「変換責務」から逸脱し、前提条件の評価という「判断責務」を内包してしまっている。これにより、関数の意味はあいまいになり、再利用時の前提共有も困難になる。

4.3 第3回設計（責務軸）：業務的責務としてのチェック再配置

第三回目の設計では、各関数や処理群が業務的意味によって再構成され、「何のために」「誰の立場で」行う処理なのかが構造に織り込まれる。この段階では、チェック処理もまた意味を持つ責務として明示的に抽出され、専用の責務単位として再配置される。

たとえば「EnsureValidRecords」や「GuardIfNoData」といった関数は、単に0件を検出するのではなく、「この責務において対象データが存在することを業務的に保証する」という意味を持つ。UI操作でもデータ変形でもない、「処理を開始するための意味的前提」を引き受ける関数として構造に組み込まれる。

この構造では、関数の冒頭に「保証ステップ」として責務的チェック関数を明示的に記述し、その呼び出しが責任の所在を語る構造的要素となる。こうしてチェック処理は「副次的な補助」ではなく、「責任構造の一部」として再定義される。

4.4 チェックは誰の責任か？という問いへの構造的答え

設計が成熟するとは、チェック処理の有無を問うことではなく、「このチェックは誰の責任か？」という問いに構造的に答えられるようになることである。初期段階では局所的で散在していたチェックは、データ構造に紛れ込むことで一時的な整理を得るが、最終的には意味の単位として構造に再統合されることによって初めて設計的に完成する。

このように、チェック処理の進化は、単なる処理の再配置ではなく、責任の明示と構造の言語化という観点において設計思想の成熟を象徴するものである。構造化された設計とは、処理だけでなく前提条件もまた責務として可視化された状態を指すのである。

第5章　応用例とテンプレート化の可能性

これまでの章で検討してきたように、チェック処理は単なる条件分岐ではなく、構造化された設計責任の一部である。その責任を明示し、関数構造の中で再利用可能な形式に落とし込むためには、チェック処理自体をテンプレート化・明文化し、設計上の再利用単位として捉える必要がある。本章では、VBAを例にとり、ガード関数の設計例、「Ensure系」関数のパターン化、ガイドラインへの統合可能性、さらにはチェックを業務ルールとして明示的に設計する方針について論じる。

5.1 VBAにおけるガード関数の構造設計例

VBAにおける関数設計では、関数冒頭に前提条件の確認を記述するのが一般的である。この際、件数チェックや入力確認などの処理がそのまま If ... Then Exit Function という形で埋め込まれがちである。しかし、このような実装は構造的責任を曖昧にし、再利用性を損なう。

そこで導入されるのが、ガード関数である。たとえば以下のような関数がその代表例となる。

Function EnsureRecordsExist(a_rs)

    If a_rs.EOF And a_rs.BOF Then

        Err.Raise 513, , "レコードが存在しません。"

    End If

End Function

この関数を業務関数の冒頭に配置することで、「この関数は対象レコードが存在することを前提とする」ことが構造的に明示される。さらに、テストやロギングの統一も容易になり、設計の説明可能性が大きく向上する。

5.2 「Ensure系」関数群の責務明示と再利用

上記のようなガード関数は、業務処理の前提条件を「Ensure系」として関数群で整備することで、再利用と構造的説明の両立を図ることができる。以下はその分類例である。

関数名前提責務の内容

EnsureNotEmpty 文字列またはコレクションの非空確認

EnsureRangeIsValid 範囲指定が妥当かの検証

EnsureUserConfirmed ユーザー操作による確定確認

EnsureRecordsExist Recordsetの存在確認

このように関数名に「Ensure」を冠することで、設計上の意図を名前で伝えることができる。これらはライブラリ化することでプロジェクト全体に横展開でき、保守・レビュー・教育においても構造を読み解くための手がかりとなる。

5.3 設計ガイドラインへの展開可能性

チェック処理をガード関数として分離・明示する設計方針は、コード記述ルールとして体系化し、チームやプロジェクト単位での設計ガイドラインへと昇華させることができる。たとえば以下のような方針を明文化することで、設計の属人化を防ぐことができる。

各関数は、処理の前提条件を冒頭で明示的にチェックすること
複数の関数で共有される前提は「Ensure系」として独立関数化すること
ガード関数の命名は「Ensure + 内容」とし、責務の可読性を確保すること
処理の中断（Exit）ではなく、責務の逸脱は例外（Err.Raise）で表現すること

このようなガイドラインは、設計教育やレビュー時の共通言語として機能し、設計の再現性と整合性を支える基盤となる。

5.4 チェックを「業務ルールの一部」として設計する

チェック処理の真価は、単なる入力検査ではなく、業務ルールの反映として位置づけられることにある。たとえば「対象月に売上が存在しない場合は集計を行わない」「承認フラグが立っていないものは出力しない」といった判断は、業務プロセスの本質的な一部である。

これらを単なるIf文として書くのではなく、「EnsureXxxx」や「IsXxxxReady」といった名前で責務化することで、コードは業務の構造を語るドキュメントとなる。設計者はコードの背後にある意味を明示し、読者はそれを構造として読み解く。こうした設計は、業務知識と実装の橋渡しとして機能し、長期的な保守と組織的知識共有の基盤を提供する。

第6章　まとめ──チェックは構造における責任のしるしである

これまで検討してきたように、チェック処理とは単なる技術的制御ではなく、設計構造における責任の明示そのものである。構造を組み立てるという行為は、何を前提とし、何を保証し、何に責任を持つかを選び取る営みであり、チェック処理はその前提責任を最も端的に示す機能である。

6.1 チェックを単なる条件分岐と捉えない

設計の初期段階では、チェックは処理をスキップするための条件分岐、もしくは例外を回避するための予防措置として導入される。しかし、そのような実装はコードの動作を保証しても、構造の意味を保証するわけではない。

チェックを「if ～ then ～」という構文レベルの記述にとどめてしまうと、それが何を意味しているのか、誰の責任として行われているのかが不明瞭になる。これでは設計の読み手が意図を汲み取ることが難しくなり、保守や拡張の際に誤解を招く要因となる。

むしろ、チェックは「この処理は、ある条件を前提にして初めて成立する」という責任の境界を可視化する記号である。設計とは、本質的に責任の区画整理であり、チェックはその境界を引く線である。

6.2 設計の成熟に応じて責務も構造も進化する

トップダウン設計三回説の視点から見れば、チェック処理の構造的扱いは、設計の成熟に伴って次のように進化する。

第1回設計では、チェックはUI操作の中に埋め込まれ、個別に処理される。

第2回設計では、チェックはデータ変形関数の内部に移され、共通化の中に吸収される。

第3回設計では、チェックは明示的な責務として抽出され、関数構造の一部として再配置される。

この進化は、単なる再配置ではなく、「意味による構造再定義」の過程である。チェック処理もまた、他の関数やデータ構造と同様に、視点の交代によって意味づけが変化し、再設計される対象であるという点に本質がある。

6.3 三回設計法におけるチェック処理の再定義

三回設計法において、チェック処理は次のように再定義される。

チェックは技術的制御ではなく、設計的責務の明示である。
チェックは構造の中に意味を織り込む手段であり、関数やモジュールの前提を語る要素である。
チェックは**「誰が責任を持つか」という問いに構造的に答えるための文法である**。

この定義に基づくならば、チェック処理はもはや副次的な存在ではない。むしろ、構造の正しさ・一貫性・説明可能性を支える柱の一つである。チェックは、構造における責任のしるしであり、設計の成熟度を映す鏡でもある。