なぜ優れた設計は、仕事を部品に近づけるのか

May 28, 2026

1 min read

2 views

84%

私たちはいつから、機能を「画面」に閉じ込めるようになったのか

新しい画面を作るたびに、関連するデータ取得、表示、状態管理、更新の責務が一箇所に固まり、結果として「この画面を作るときは、この巨大な塊を理解しないといけない」という状況になりがちです。これは多くのプロダクトで見覚えのある風景でしょう。見た目は一つの画面でも、内部には複数の関心事が密に絡み合っています。

では、もし設計の単位を「画面」ではなく「機能の断片」に変えたらどうなるでしょうか。あるいは、もし CPU 的な発想で中央集権的に組み立てるのではなく、GPU 的な発想で小さな仕事を大量に並列に処理するように考えたら、ソフトウェアの作り方はどう変わるでしょうか。

一見すると、iOS の UI 設計と Haskell から Vulkan を触る話は別世界です。しかし両者には、驚くほど深い共通点があります。どちらも本質的には、複雑さをどこに置くかという問題を扱っているのです。

中央で組み立てる設計は、いつか必ず重くなる

従来の作り方では、画面が中心です。ビューは表示を担当し、ビューモデルやプレゼンテーション層がロジックを集約し、下層にデータ取得や変換がぶら下がる。これは分かりやすい反面、成長するとすぐに摩擦が増えます。なぜなら、変更のたびに中央の塊へアクセスする必要があるからです。

この構造の問題は、単に「コードが長い」ことではありません。もっと厄介なのは、変更の局所性が失われることです。本来なら新しい UI 部品を追加するだけで済むはずなのに、実際には関連する状態、型、クエリ、表示条件、エラー処理、テストまで広がっていく。すると開発者は次第に「何を変えればいいか」ではなく「どこまで壊れるか」を先に考えるようになります。

これは、中央集権型の都市計画に似ています。すべての道路が一つの巨大な駅に向かっている都市は、最初は便利です。しかし人口が増え、移動が多様化すると、駅前は渋滞し、少しの工事が全体に波及します。ソフトウェアでも同じで、中央の抽象が増えるほど、便利さは一時的に増し、後から保守コストとして回収されます。

複雑さは消えない。消えるように見えるだけで、たいていは中央に蓄積される。

ここで重要なのは、問題は「抽象化が悪い」ことではない、という点です。むしろ抽象化が足りないのではなく、抽象化の配置が悪いのです。中央に全部を集めるのではなく、仕事が生まれる場所に責務を置くべきなのです。

Fragment Colocation が教えるのは、責務はデータの近くに置くべきだということ

Fragment Colocation という考え方は、データをどこで取るかと、そのデータをどこで使うかを近づける発想です。つまり、表示に必要な断片は、その断片自身の近くに置く。これは単なるコーディング規約ではなく、設計思想です。

たとえばユーザー名、アイコン、フォロー状態、未読数が必要なカードがあるとします。従来は、画面の上位で必要な情報をまとめて取得し、下位のコンポーネントへ渡し、各所で整形していたかもしれません。しかし Fragment Colocation 的に考えると、そのカードは自分に必要な情報を自分の定義の近くに持ちます。すると、カードは独立した意味のある単位になります。

このとき起きる変化は大きいです。第一に、意図が見えるようになります。第二に、変更範囲が縮みます。第三に、再利用ではなく再配置がしやすくなります。ここで大切なのは、コンポーネントを「小さくする」こと自体が目的ではないことです。小ささは手段にすぎず、目的は関心事の局所化です。

これは SwiftUI と特に相性が良い考え方です。SwiftUI は UI を状態の関数として表現しやすく、部品化が自然に進みます。しかし、部品化の恩恵を最大化するには、見た目だけを分割しても不十分です。表示に必要なクエリやデータ境界まで一緒に設計しないと、結局は上位が肥大化します。つまり、真に重要なのはコンポーネントの分割ではなく、情報の境界設計なのです。

この視点で見ると、Fragment Colocation は「コードをきれいにするテクニック」ではありません。むしろ、画面という巨大な器から、意味のある断片へと設計の重心を移す方法です。

GPU を自由に動かしたい欲求は、設計の重心を分散したい欲求でもある

GPU を使う話も、実は同じ問いに向き合っています。CPU は一般に自由度が高く、順序立てて何でもこなせる。けれど、目の前にはもう一つの強力なプロセッサがあり、そこにはまったく異なる得意分野があります。GPU は大量の似た仕事を一気にさばくのが得意です。

ここで重要なのは、GPU を活用するとは単に「速くする」ことではない、という点です。GPU を使うとき、私たちは仕事の粒度や並列性、データ配置を再考せざるを得ません。CPU 的な発想のままでは、GPU の本当の力を引き出せないからです。Vulkan API を通じて GPU を自由に動かしたい、しかも Haskell らしいやり方で扱いたい、という欲求は、単なる性能最適化ではなく、制御の仕方を再発明したいという欲求に近いのです。

この構図は、UI 設計における Fragment Colocation とそっくりです。中央で全部を組み立てるのではなく、仕事を必要な場所へ分散する。巨大な上位レイヤーがすべてを知るのではなく、各断片が自分に必要な情報を持つ。どちらも、単一の賢い中央管理者に頼る設計から、自律した局所単位の協調へ移行する話です。

GPU の比喩を使うと、従来の画面設計は CPU 的です。1つの大きな関数が多くの状態を順番に処理し、最終的に UI を描く。一方、Fragment Colocation はより GPU 的です。各カードやフラグメントが、必要な入力を持ち、自分の役割を並列に果たす。中央は交通整理に徹し、意味のある仕事は境界の内側で完結します。

優れた設計とは、中心を強くすることではなく、中心がなくても回る部分を増やすこと。

もちろん、完全な分散が常に正しいわけではありません。GPU も万能ではなく、管理コストや同期コストが発生します。UI コンポーネントの局所化も、やりすぎると重複や断片化を招きます。だから本質は「何でも分散」ではなく、変更頻度が高く、意味的に閉じる領域から局所化することにあります。

本当に設計すべきなのは、画面ではなく「変更の半径」だ

ここで一つ、視点を変えると理解しやすくなります。私たちはしばしば「どの層に置くか」を議論しますが、もっと本質的なのは「変更がどこまで広がるか」です。これを変更の半径と呼べます。

変更の半径が大きい設計では、1つの小さな要件変更が広い範囲に波及します。たとえば、カードに一つバッジを追加したいだけなのに、上位のデータ取得、型定義、条件分岐、テストケース、ナビゲーションの状態まで触る必要がある。これは、修正そのものより、影響範囲を読むことに時間がかかる状態です。

Fragment Colocation は、この半径を縮めます。各断片が自分の表示と必要データを持てば、変更は局所化されます。GPU 的な発想も同様です。大量の小さな仕事に分解し、各仕事が独立して進めば、全体の制御点は減り、1箇所の遅延や複雑さが全体に広がりにくくなります。

この二つを合わせると、次のような原則が見えてきます。

責務は、使う場所に置く。
データは、表示や計算の境界に寄せる。
中央は決定を持ちすぎず、接続だけを担う。
変更の半径が小さい単位を、最初から設計する。

この原則は、見た目の美しさよりも強いです。なぜなら、保守性は「後から頑張る」ものではなく、最初の単位設計でほぼ決まるからです。

実践のための一つのフレームワーク: 画面を「発注者」ではなく「契約」として見る

ここまでを実務に落とし込むなら、画面を「何かを指示する親」ではなく、契約の束として捉えるとよいでしょう。各コンポーネントは、何を表示するか、何が必要か、どの状態でどう振る舞うか、という契約を持つ。上位層はその契約を接続するだけで、内部の詳細には深入りしない。

たとえば、プロフィールカードなら次のように考えます。

このカードはユーザーの名前とアイコンとフォロー状態を必要とする
エラー時はこの見せ方をする
ローディング時はこのプレースホルダーを出す
必要なデータ取得は、このカードの近くに定義する

こうすると、カードは単なる表示部品ではなく、意味を持つ自立した単位になります。Haskell 的に言えば、外部に依存しすぎず、入力と出力が明確な関数に近づく感覚です。Vulkan 的に言えば、命令を中央で逐一指示するのではなく、必要なバッファやパイプラインを明示して、局所的に実行可能な形へ整える感覚に近い。

このフレームワークの利点は、設計判断が感情論から離れることです。「分割したほうが気持ちいい」ではなく、「変更の半径が縮むか」「契約が閉じるか」「中央の責務が増えていないか」で判断できるからです。

Key Takeaways

画面ではなく、変更単位を設計する。 小さな見た目の単位ではなく、変更が閉じる単位を作る。
データと表示を近づける。 必要な情報は、使うコンポーネントの近くに置くほど保守しやすい。
中央に知識を集めすぎない。 上位層は接続に徹し、意味のある仕事は局所に置く。
GPU 的に考える。 大きな一括処理より、小さな独立した仕事の協調として設計する。
契約を明示する。 コンポーネントが何を必要とし、どう振る舞うかを近くに書く。

結論: 優れたソフトウェアは、中央が賢いのではなく、断片が自律している

私たちはしばしば、良い設計を「うまくまとめること」だと誤解します。しかし本当に強い設計は、まとめることよりも、分けても壊れないことに価値があります。Fragment Colocation が示すのは、責務をデータの近くへ戻すことで、画面を意味のある断片へ変えられるということです。GPU を自由に扱いたいという欲求が示すのは、中央で何でも抱えるのではなく、並列に動ける単位を増やすことで、計算の形そのものを変えられるということです。

この二つを重ねると、ソフトウェア設計の見方が少し変わります。中心をどう賢くするかではなく、中心が賢くなくても成立する局所をいかに増やすか。その問いに向き合い始めたとき、画面設計も、状態管理も、API 設計も、驚くほど似た原理で理解できるようになります。

そしておそらく、これが本当に長持ちするシステムの条件です。大きな頭脳を一つ作ることではありません。むしろ、小さな自律した断片が、必要なものを自分で持ち、自分で動き、自分で完結できるようにすることです。設計とは、巨大な中心を作る競争ではなく、依存を減らしながら意味を増やす技術なのです。