前回との接続とこの講義の役割
前回のN-04では、部品と部品をつなぐAPI設計と、利用している側を壊さない互換性を学びました。今回は視点を部品の内側へ移し、1つの部品の中で責任をどう分けるかを扱います。設計の6決定事項でいえば、②責任にあたる論点です。J-07で一度見た3層の分離図を、ここで正式な設計原則として整理していきます。
このスライドのポイント
- 前回N-04: API設計と、利用側を壊さない互換性（部品と部品の「つなぎ目」の設計）
- 今回: 視点を部品の内側へ移し、1つの部品の中で責任をどう分けるか
- 設計の6決定事項でいえば「②責任」を深掘りする回
- J-07で一度見た3層の分離図を、正式な設計原則として整理する
責任分離とレイヤーの定義
責任分離とは、1つの部品に1つの責任だけを持たせ、変更の影響範囲を限定する設計原則です。レイヤーとは、責任ごとに分けた層のことを指します。Webアプリは大きく3つの層に分けられます。画面の表示と操作を担うUI層、業務のルールや判断を担う業務ロジック層、データの保存と取り出しを担うデータアクセス層です。これはJ-07で見た3層の分離図の正式版であり、目的は美しさではなく変更コストの限定にあります。
このスライドのポイント
- 責任分離＝1つの部品に1つの責任だけを持たせ、変更の影響範囲を限定する設計原則
- レイヤー＝責任ごとに分けた「層」
- Webアプリの代表的な3層:
なぜ責任分離が必要か
責任分離を知らないと、AIが生成しがちな「1つの関数に画面もルールも保存も全部入り」のコードの問題を指摘できません。たとえば経費精算アプリで税率が変わったとき、税率の計算があちこちの画面に散らばっていれば、変更のたびに全画面を触ることになります。1箇所の修正が思わぬ画面を壊し、確認の手間も膨らみます。責任が分かれていれば、変更は該当する層の中だけで済みます。これは、バイブコーディングで構造が崩れていくのを防ぐ、中期的に効く歯止めになります。
このスライドのポイント
- 分離を知らないと、AIが生成しがちな「画面もルールも保存も全部入り」の関数の問題を指摘できない
- 経費精算アプリの例: 税率の計算が各画面に散らばると、税率変更のたびに全画面を触ることになる
- 1箇所の修正が別の画面を壊し、確認の手間も膨らむ
- 責任が分かれていれば、変更は該当する層の中だけで済む
- バイブコーディングで構造が崩れるのを防ぐ、中期的な歯止め
構造——3層と変更波及の比較
全体像を3つの層の重なりで見てみましょう。上からUI層、業務ロジック層、データアクセス層と並び、上の層は下の層へ依頼を渡し、下の層はその結果を返します。ここで税率変更というシナリオを、分離ありと分離なしで比べます。分離ありの場合、変更は業務ロジック層の税率計算1箇所で完結します。分離なしの場合、税率計算が画面や保存処理に埋め込まれているため、全ファイルを探し回ることになります。この波及範囲の差こそが、責任分離の効果です。
このスライドのポイント
- 3層は上から下へ「依頼」を渡し、下から上へ「結果」を返す
- 税率変更というシナリオで、分離あり／なしの波及範囲を比較
具体例——承認ルールの変更
もう1つ、承認ルールが変わった場合を具体的に追います。経費精算アプリで「5万円以上は部長承認が必要」というルールが「3万円以上」に変わったとします。責任が分離されていれば、直すのはJ-07で見た承認判定の関数、たとえばneedsApprovalという1つの関数だけです。画面もデータの保存処理も触る必要がありません。これは、E-07の関数化、H-10の部品化、そしてJ-07の層の分離と積み上げてきた、関係する処理をまとめて1箇所に置くという思想の完成形です。まとめておいたからこそ、変更が1箇所で済むわけです。
このスライドのポイント
- 経費精算アプリで「5万円以上は部長承認」が「3万円以上」に変わったと想定
- 分離されていれば、直すのはJ-07で見た承認判定の関数（例: needsApproval）1つだけ
- 画面もデータの保存処理も触る必要がない
- E-07の関数化 → H-10の部品化 → J-07の層の分離、と積んだ「まとめて1箇所」思想の完成形
技術サンプルカード——3層と変更波及の対比図
スライドのサンプルは、3つの層と変更の波及を対比した図です。種別は図解、目的は、同じ税率変更が分離ありと分離なしでどこまで波及するかを一目で確かめることです。左の分離ありでは、UI層・業務ロジック層・データアクセス層が縦に並び、税率変更は業務ロジック層の中だけにとどまります。右の分離なしでは、1つの関数に画面と計算と保存が混ざり、変更が全体へ広がります。読み方の要点は、矢印が依頼と結果の往復であること、そして変更の印が片方では1層に、もう片方では全体に付くことです。
混同しやすい概念——ファイル分割と責任分離
混同しやすいのは、ファイルを分けることと責任を分けることの違いです。ファイルを物理的に複数に分割しても、それだけでは責任分離にはなりません。たとえば別ファイルにした画面コードが、そのままデータベースの保存処理を抱えていれば、責任は混ざったままです。責任分離の基準は、置き場所ではなく、変更する理由です。変更理由が違う処理は別の層へ、同じ理由の処理は1箇所へ。ファイルが分かれていても責任が混ざっていれば、変更コストは下がりません。
このスライドのポイント
- 「ファイルを分ける（物理的分割）」と「責任を分ける（変更理由で分割）」は別物
- ファイルを複数に分けても、画面コードが保存処理を抱えていれば責任は混ざったまま
- 分離の基準は置き場所ではなく「変更する理由」
- ファイルが分かれていても責任が混ざっていれば、変更コストは下がらない
バイブコーディングでの確認点
AIのコードをレビューするときは、この関数の変更理由は何種類ありますか、と聞いてみてください。理由が2種類以上あれば、それは分離の候補です。これは、I-02で学んだ、部品を1行で説明できるかというテストの発展形です。1行で言い切れず「画面を出して、税率も計算して、保存もして」と接続詞が続くなら、責任が混ざっているサインです。分離の判断は人間が持ち、具体的な直し方はAIに出させる、という分担で進めましょう。
このスライドのポイント
- AIのコードレビューで「この関数の変更理由は何種類ありますか」を聞く
- 変更理由が2種類以上あれば、分離の候補
- I-02で学んだ「部品を1行で説明できるか」テストの発展形
- 「画面を出して、税率も計算して、保存もして」と接続詞が続くなら、責任が混ざっているサイン
- 分離の判断は人間、具体的な直し方はAIに出させる
まとめと次回
最後に一問一答です。責任分離の目的は何でしょうか。（間）答えは、変更の影響範囲を限定することです。見た目の美しさのためではなく、変更コストを限定するための原則でした。30秒でまとめます。1つの部品に1つの責任を持たせ、UI層・業務ロジック層・データアクセス層に分ければ、変更は該当する層の中で完結します。次回のN-06では、この分離の良し悪しを測る2つの指標、結合度と凝集度へ進みます。関連資料は「リファクタリング指示文50」と「SaaS機能パーツ100」です。
このスライドのポイント
- 一問一答: 責任分離の目的は？ → 変更の影響範囲を限定すること
- 30秒まとめ: 1部品に1責任、UI・業務ロジック・データアクセスの3層に分ければ、変更は該当層で完結する
- 次回N-06: 分離の良し悪しを測る2指標「結合度と凝集度」へ
- 関連資料: 「リファクタリング指示文50」「SaaS機能パーツ100」
