UIは部品を作る場所ではない。変更の痛みを閉じ込める場所だ

May 12, 2026

1 min read

3 views

77%

いちばん高くつくのは、見た目の変更ではなく「どこを直すか」が毎回迷うこと

UI開発で本当にコストが膨らむのは、ボタンの色を変えることでも、画面を一枚増やすことでもありません。もっと厄介なのは、変更が必要になるたびに、どこまでがその画面の責務なのかを毎回考え直さなければならないことです。

見た目の修正が、なぜいつも想像以上に重いのか。画面の構造が曖昧だからです。コンポーネントが大きすぎる、状態が散らばっている、データ取得と表示と操作が混ざっている、テンプレートがチームごとに違う。すると、1つの修正が局所的に終わらず、関連するコードを探し回る作業に変わります。

ここで面白いのは、最新のUI開発で重要になっている2つの実践が、まったく別の話に見えて実は同じ問題を解いていることです。ひとつは、UIレビューを差分ベースで素早く行える仕組み。もうひとつは、画面設計の段階で必要な断片をその場に寄せて、責務の境界を明確にするやり方です。どちらも結局は、変更の痛みを、広がる前に閉じ込めるための工夫です。

UIレビューの本質は「完成品を見ること」ではない

多くのチームは、UIレビューを「できあがった画面を眺めて、違和感を探す作業」だと思っています。しかし本当に価値があるのは、完成品を鑑賞することではなく、変更の差分を安全に観察できることです。

たとえば、あるボタンの余白が8pxから12pxに変わったとします。完成画面だけを見ても、その変更が意図的なのか、隣接する要素に悪影響を与えたのかは判断しにくい。ところが差分として見られれば、何が変わり、何が変わっていないかが一目でわかる。レビューは「美しさの評価」から「意図の検証」に変わります。

これはUI開発における大きな転換です。デザインの良し悪しは、静止画の完成度だけでは測れません。優れたUIは、変更されたときに壊れ方が小さい。つまり、レビューで見るべきなのは見た目の結果そのものより、変更がどの範囲に波及したかです。

この視点を持つと、ホスティングやレビュー環境の価値も見え方が変わります。単に「ブラウザで見られる」ことが重要なのではなく、チーム全員が同じ基準で差分を確認できることが重要なのです。UIをコードとして扱う以上、レビューの単位もコードのように差分中心であるべきです。

UIレビューは、完成した絵を見る儀式ではない。変更の影響範囲を測る計測器である。

画面は大きな箱ではなく、文脈を運ぶ容器である

一方で、Fragment Colocationという考え方は、UIの責務を分散しすぎないための強力な整理術です。名前は少し専門的ですが、発想はとてもシンプルです。画面に必要なデータと表示の断片は、できるだけその断片を使う場所の近くに置く。これにより、Presentation層が肥大化しにくくなります。

この考え方が効くのは、UIが単なる見た目の寄せ集めではないからです。画面には必ず文脈があります。例えば、ユーザー名の表示にはプロフィール情報が必要で、商品カードには価格、在庫、割引条件が必要で、購入ボタンには権限や状態が必要です。これらを全部ひとまとめにすると、画面は便利な一方で、どこが何を担当しているのかが見えなくなります。

Fragment Colocationは、そうした曖昧さを減らします。関連するデータを、その表示に近い場所へ寄せる。すると、画面全体を理解するのではなく、断片ごとの契約を見ればよくなる。これは設計の話であると同時に、レビューの話でもあります。変更が局所化されれば、差分も局所化されるからです。

たとえば、ECアプリの商品詳細画面を考えてみましょう。従来の設計では、ViewModelが商品情報、配送可否、レビュー、在庫、キャンペーン情報を全部まとめて持ち、画面側がそれを分岐で描画することがよくあります。すると、キャンペーン表示を少し変えただけで、画面全体のロジックを追う必要が出る。

Fragment Colocation的な設計なら、商品カード、配送情報、レビュー一覧、購入アクションが、それぞれ自分に必要な断片を持ちます。すると変更は、関係する断片に閉じる。画面は巨大な箱ではなく、責務が分かれた小さな部屋の集合になるのです。

本当の敵は「部品化」ではなく「責務の拡散」

ここで注意したいのは、単にコンポーネントを細かく分割すればよいわけではないことです。部品を小さくしすぎると、今度は文脈が飛び散ります。何を表示しているのかは見えても、なぜその表示なのかがわからない。結果として、分割はしたのに理解は楽にならない、という状態になります。

つまり問題は、大きすぎることでも、細かすぎることでもありません。問題は、責務の境界がコード上で自然に見えないことです。

この観点から見ると、UI開発でよくある失敗は2種類あります。

中央集権型UI すべてのデータと条件分岐が1か所に集まり、変更はしやすそうに見えるが、実際には全体が絡み合う。
断片分散型UI コンポーネントは細かいが、必要な情報が遠く離れた場所にあり、追跡コストが高い。

目指すべきはこの中間ではありません。むしろ、断片の近くに文脈を置き、画面全体ではなく局所的な理解で前進できる構造です。つまり、変更の単位と理解の単位を揃えることです。

これは設計原則として見ると地味ですが、開発体験に与える影響は大きい。レビューのしやすさ、実装のしやすさ、テストのしやすさが、同じ構造から同時に改善されるからです。

良いUI設計とは、見た目を分けることではない。変更の理解単位を揃えることだ。

差分で見る文化と、文脈を寄せる設計は同じ方向を向いている

この2つの実践を並べると、ひとつの重要な共通点が見えてきます。それは、「何が変わったか」を早く、正確に、局所的に把握できるようにすることです。

UIレビュー環境が差分を見やすくするのは、変更の可視化です。Fragment Colocationが文脈を近づけるのは、変更の局所化です。可視化と局所化は別のことのようで、実際には同じ目的に向かっています。どちらも、変更が発生したときに、チームが迷わず判断できるようにする仕組みです。

ここで考えるべきなのは、UI開発において「レビューが速い」とは何かです。単にページ遷移が早いとか、ビルドが速いとかではありません。変更の説明コストが低いことです。レビュアーが「何が変わったのか」「なぜこの変更で他が壊れないのか」を短時間で理解できる状態。これこそが速いレビューです。

同じように、「設計が良い」とは何かも再定義できます。抽象的に美しいことではなく、変更の波及半径が小さいことです。波及半径が小さい設計ほど、怖がらずに直せる。怖がらずに直せるコードほど、改善が続く。改善が続くUIほど、品質が積み上がる。

この循環はとても重要です。UI開発では、設計が悪いからレビューが辛くなり、レビューが辛いから小さな改善が避けられ、改善が避けられるからさらに設計が悪化する、という負のループが起こりがちです。逆に、差分の見やすさと責務の局所化が揃うと、改善の心理的コストが下がり、UIは少しずつ強くなります。

たとえるなら、優れたキッチンの設計に似ています。調理器具が全部一つの引き出しに放り込まれていると、料理のたびに探すことになる。逆に、用途ごとに近くへ配置されていれば、手が止まらない。UIも同じで、表示とデータと意図が近いほど、変更は自然に流れます。

では、何から変えるべきか

ここまでの話を実務に落とすなら、ポイントは3つです。大げさな刷新より、変更の観察可能性と文脈の近接性を上げることから始めるのがいい。

まず、UIレビューを「最終確認」ではなく「差分検証」に変えます。完成画面のスクリーンショットを見るだけではなく、何が変わったかを比較できる状態にする。これだけで、レビューの質はかなり上がります。

次に、画面の責務を見直します。1つの画面が持っている状態やロジックを棚卸しして、表示に必要な断片が遠くに散らばっていないか確認する。もし、特定のUI断片が他の多くの画面要素に触れているなら、その断片はまだ大きすぎる可能性があります。

最後に、テンプレートや雛形を標準化します。これは軽視されがちですが、かなり効きます。新しい画面を作るたびに構造が変わると、チームは毎回ゼロから設計を再考する羽目になる。逆に、最初からFragment Colocationのような考えを反映した雛形があれば、よい設計を毎回の意思決定にしなくて済む。標準は創造性を縛るものではなく、迷いを減らすための足場です。