[iOSアーキテクチャ #8] iOSアーキテクチャ選択ガイド：チーム規模・アプリ寿命・状態の複雑さで選ぶ方法

iOSアーキテクチャシリーズをここまで読んでいれば、選択肢はすべて出そろっています。MVC、MVVM、MVP、VIPER、Clean Architecture、MV、TCAです。

「では、私たちのアプリにはどれを使えばいいのでしょうか？」

「正解はなく、トレードオフしかない」というのはそのとおりですが、それだけでは何も決められません。今回はシリーズ最終回として、実際に判断できる具体的な基準を整理します。

---

基準1：チーム規模 — アーキテクチャは人の問題です

まず、アーキテクチャの重さはコード量ではなく人数に合わせるべきです。

1〜2人のチームなら、構造の統一より速度が重要です。SwiftUIならMV（Model–View）＋Repositoryで十分で、UIKitならMVCから画面遷移とネットワークだけ分離しても構いません。この規模でVIPER（View・Interactor・Presenter・Entity・Router）やTCA（The Composable Architecture）を導入すると、構造の維持にかかる時間が機能開発を圧迫しがちです。

3〜10人のチームになると、「ロジックをどこに置くか」についてチームで合意する必要があります。この規模ではMVVM＋UseCase/Repositoryが無難な標準です。画面ごとの構造をそろえると、コードレビューとオンボーディングのコストを下げられます。

10人以上、複数のスクワッドなら、統一性とモジュール境界が最優先です。機能単位のモジュール化にClean Architectureのレイヤーを重ねるか、状態が複雑ならTCAを標準にする選択が出てきます。VIPERやRIBsが実際に採用されたのも、この規模の組織でした。

---

基準2：アプリの寿命 — 長く使うアプリほど境界に投資する

寿命の短いアプリ（プロトタイプ、検証用MVP（Minimum Viable Product）、イベントアプリ）にレイヤーを積むのは無駄です。素早く作り、素早く学ぶことが目的だからです。

3年以上使われるプロダクトでは話が違います。その間にサーバーAPIは改修され、デザインは一新され、UIKit→SwiftUIのようなフレームワーク移行も起こります。ここで価値を持つのは華やかなパターンではなく境界です。データソースを隠すRepositoryや、ビジネスルールを収めるUseCaseのようなものです。境界があれば部分的に置き換えられ、なければ全面書き換えになります。

---

基準3：状態の複雑さ — TCAが正当化される唯一の軸

画面の大半が「サーバーから取得して表示し、入力をサーバーに送る」アプリなら、MVVM/MVで十分です。一方、複数の画面が同じ状態を同時に編集したり、リアルタイム同期・オフラインマージ・複雑なundoが絡んだりするアプリでは、状態変更の経路を強制的に管理するTCAのコストが正当化され始めます。

前回まとめたように、TCAは間違った選択肢ではなく、高価な選択肢です。この軸の複雑さが低ければ、そのコストを回収できません。

---

1枚にまとめると

状況	推奨
個人・プロトタイプ	MV（SwiftUI）またはMVC＋最小限の分離
小規模チーム・一般的なサービスアプリ	MVVM＋Repository（必要ならUseCase）
レガシーUIKit・バインディング導入の負担	MVP + Coordinator
大規模組織・長寿命プロダクト	Clean Architectureのレイヤー＋機能単位のモジュール化
状態が複雑なドメイン	TCA（チームの学習投資を前提）

表より重要なのはこれです。**表のどの項目から始めても、あとで隣の項目へ移れます。**ただし、移行するには条件が1つあります。

---

どの選択をしても守るべき不変条件

シリーズ全体を貫く原則を1つに圧縮すると、こうなります。

ViewがネットワークやDBを直接操作しないようにし、ビジネスルールを画面コードの外に置いてください。

この不変条件さえ守られていれば、MVCからMVVMへ、MVVMからTCAへ移る作業は「画面レイヤーの置き換え」に絞れます。逆にこれが崩れていると、どんな流行のアーキテクチャを導入しても全面書き換えになります。アーキテクチャ名は履歴書に残りますが、プロダクトを守るのは境界です。

最後に、アーキテクチャ移行はビッグバンではなく、新しい画面から段階的に進めるのが定石です。正常に動いている既存画面を流行だけを理由に作り直すと、多くの場合は後悔します。

---

シリーズを終えて

8回の内容を各1文に圧縮すると、こうなります。

• MVC：UIViewControllerに責務が集中する構造を理解することが出発点
• MVVM：画面状態を切り出し、バインディングで同期する。バインディングがなければ不完全
• MVP vs MVVM：中間オブジェクトがViewを知っているかどうかの違い
• VIPER：分離の極限。その遺産はCoordinatorとUseCaseとして残る
• Clean Architecture：依存性は内側にのみ向け、Repositoryから始める
• TCA：状態変更の経路を制御し、複雑さがコストを正当化するときに使う
• MV論争：本質は名前ではなく、ロジックの場所と依存性の方向
• 選択ガイド：チーム規模・アプリの寿命・状態の複雑さで選び、不変条件を守って段階的に移行する

アーキテクチャは目的地ではなくツールです。チームとアプリの成長に合わせて乗り換えられるよう、境界に投資しておきましょう。

あわせて読みたい

• [iOSアーキテクチャ #10] Uber RIBs：ビジネスロジックでアプリを分割する