💡 独学者が語る！PHP 独自 MVC から学んだ「真の責務の分離」とは

導入：MVC とは「設計思想」である

私が長年 Web サイトを運用してきた中で、最初に手探りで取り入れた設計パターンが MVC (Model-View-Controller) でした。このパターンのおかげで、当時のスパゲッティコードから脱却し、システムに一定の秩序をもたらすことができました。

しかし、私が自作した PHP 独自 MVC は、サイトが成長するにつれて致命的な保守性の問題に直面しました。この経験を通じて痛感したのは、**「MVC は単なる三層のフォルダ構造ではない。真の責務の分離とは、データとロジック、表示の境界を厳格に守ることである」**という原則です。

本記事では、私が独自 MVC の運用で直面した**「偽りの分離」の課題と、モダンな Next.js (React)/Django への移行を通じて学んだ「真の責務の分離」**の教訓を解説します。

第1章：独自 MVC で陥った「偽りの責務分離」の罠

1. Controller の肥大化（Fat Controller）問題

独学者が自作 MVC で最も陥りやすい罠が、Controller の肥大化 (Fat Controller) です。私の旧システムも例に漏れず、Controller が以下のような複数の責務を抱え込んでいました。

データ取得: Model を呼び出すだけでなく、複雑なデータ集計クエリを Controller 内で直接生成してしまう。
業務ロジック: ユーザーの入力検証、条件分岐、外部 API との連携処理など、様々な業務ロジックを Controller に記述。
View への依存: データを View に渡す前に、Controller 側で View の表示形式に合わせた加工処理をしてしまう。

これにより、Controller はすぐに数百行のコードの塊となり、一つの処理を変更するだけで、予期せぬ別の機能が壊れるという「恐怖のコード」と化しました。

2. Model の持つべきでない「画面ロジック」

Controller が肥大化する裏側で、Model もまた不適切な責務を負っていました。

HTML 生成コードの混入: Model の中でデータ加工処理を行った際、その結果を HTML のタグで装飾して View に返してしまう（例：<div> や <br> を Model 内部で生成）。
外部サービスとの密結合: Model が特定の外部 API のデータ形式に強く依存してしまい、API 側の仕様変更で Model 全体の修正が必要になっていました。

真の Model は、**「データとビジネスロジックに集中すること」**が責務ですが、私の初期の MVC は、その境界線が曖昧でした。

3. View の「多すぎるロジック」

PHP で書かれた View ファイルでは、データを表示するだけでなく、if や foreach などの制御構造を複雑に入れ子にしていました。

問題: View でロジックを書きすぎると、View は単なるテンプレートではなくなり、テストが困難な「表示ロジックとデザインが混在した塊」になってしまいます。

第2章：モダン Full-Stack が実現する「真の責務の分離」

Next.js (React)/Django への移行は、単に言語が変わっただけでなく、フレームワークによる厳格な規約が、真の責務分離を強制してくれました。

1. Controller の消滅と View/Business Logic の分離

モダンな構成では、Controller の役割は、API サーバー（Django）と UI レイヤー（Next.js）に分離・吸収されました。

Django (API サーバー):
- DRF ViewSets: Controller のリクエスト受付とルーティングの責務を担います。しかし、内部の業務ロジックは全て Model/Service 層に分離されています。
- Model/Service 層: ここが**「真のビジネスロジック」**を担う場所です。複雑なデータ集計やビジネスルールは、Controller から完全に切り離された Python クラスとして記述され、テスト容易性が確保されました。
Next.js (UI レイヤー):
- Server Components: Controller が行っていたデータ取得の呼び出しと、View（React Component）へのデータ受け渡しを担います。

2. Model は「データそのもの」に集中する

Django ORM の Model は、データベースとの連携とデータ検証に集中し、View や Controller の都合に影響されなくなりました。

Serializer の活用: データと JSON の変換は DRF Serializer が担当し、Model が HTML 形式や API 形式を意識する必要が一切なくなりました。
PostgreSQL の活用: 複雑なデータ集計は、Model の持つ ORM の能力を最大限に引き出す形で実現され、Model の責務は「堅牢なデータ層」として確立されました。

3. View は「表示」に集中する (React Component)

Next.js の React Component は、View の責務を極めて厳格に守ります。

ロジックの排除: Tailwind CSS を用いてスタイルが Component 内部に閉じ込められ（View の責務の範囲内）、API から渡されたデータを加工・整形せずに表示することに集中できます。
Hooks の活用: 状態管理や副作用といったロジックは、カスタム Hooks に分離され、View のレンダリングコードをシンプルに保つことができます。

まとめ：設計原則こそが独学者の羅針盤

1. 真の責務の分離がもたらす効果

「真の責務の分離」を実現したことで、プロジェクト全体に以下の効果がもたらされました。

バグの発生源の特定容易性: 問題が API 層にあるのか、ビジネスロジック層にあるのか、UI 層にあるのかが明確になり、デバッグ時間が大幅に削減されました。
再利用性の向上: Django の Service 層で記述したビジネスロジックは、Web API だけでなく、将来的にコマンドラインツールやモバイル API としても容易に再利用できるようになりました。
保守性の向上: 開発者が修正を加えるべきファイルを迷うことがなくなり、コード変更による意図しない影響（バグ）の範囲を限定できるようになりました。

2. 独学者が身につけた「設計思想」

独学で Web 開発を始めた頃は、フレームワークの機能や言語の文法を覚えることに必死でした。しかし、この大規模な移行プロジェクトを通じて、**「技術は変わっても、設計原則は不変である」**という最も重要な教訓を学びました。

MVC の真の力は、コードを分割することではなく、未来の保守と拡張を見据えて、コードの役割（責務）を厳密に定義し、守り抜く設計思想にあります。この設計思想こそが、私がチーム開発で貢献できる最大の強みです。

今後も、この設計原則を羅針盤として、堅牢で拡張性の高いシステム開発を追求していきます。

投稿者プロフィール

bicstation

AIアシスタントとの協業が、この奮闘記を可能にした
実は、今回一連の記事を執筆し、そして開発を進める上で、強力な「相棒」の存在がありました。それが、私のような開発者をサポートしてくれるAIアシスタントです。

PHPの難解なエラーログに直面した時、記事の構成がなかなか思いつかなかった時、あるいはブログのテーマに合ったアイキャッチ画像が必要だった時など、数々の場面でAIに相談し、助けを借りました。

例えば、「レンタルサーバーでのphp.ini設定の難しさ」や「.envファイルの問題」といった、私が実体験で感じた課題を伝えると、AIは瞬時にその技術的な背景や影響を整理し、ブログ記事として読者に伝わりやすい文章の骨子を提案してくれました。また、記事のテーマに合わせたアイキャッチ画像も、具体的な指示を出すだけで瞬時に生成してくれたおかげで、コンテンツ作成のスピードが格段に向上しました。

AIは完璧ではありませんが、まさに「もう一人の自分」のように、アイデアの壁打ち相手になったり、膨大な知識の中から必要な情報を引き出してくれたり、私の思考を整理する手助けをしてくれたりします。一人で抱え込みがちな開発の課題も、AIと対話することで、新たな視点や解決策が見えてくることが多々ありました。

このブログを通じて私の奮闘記を共有できているのも、AIアシスタントの存在なくしては成し得なかったでしょう。これからも、AIを賢く活用しながら、開発と情報発信を続けていきたいと思います。