設計は画面の中だけで完結しない: 未来の変化に強いチームが持つ2つの型

May 26, 2026

1 min read

2 views

62%

ひとつの画面を作るとき、何が一番難しいのか

新しい画面を作るとき、難しいのはUIをきれいに並べることではありません。もっと厄介なのは、その画面がこれからどう変わるかを、今の時点でどれだけ受け止められるかです。今日の要件にぴったり合わせた実装は、明日のデザイン変更や要素追加でたちまち脆くなります。

ここに、意外なほど共通した2つの世界があります。ひとつはiOSの画面設計です。もうひとつは、野球のバッティング動作を骨格推定で捉えるような、動きの解析です。一見まったく違うように見えますが、どちらも本質は同じです。複雑な現実を、後から扱いやすい単位に切り分けることです。

画面もスイングも、最初から完成形で存在するわけではありません。実際には、表示も入力も状態も変化し続けます。その変化に強い人やチームは、偶然に強いのではなく、最初から「変わる前提」で構造を作っています。

変化に弱い設計は、見た目の整合性に引っ張られる

多くの実装が壊れるのは、コードが汚いからではありません。表示の都合で、関心事がひとつの場所に密集してしまうからです。UIを描くコードの中に、データ取得、条件分岐、ロジック、状態管理、表示の変換が混ざり始めると、画面は動いていても、構造はすでに崩れ始めています。

これは野球の分析でも似ています。バッティングフォームを動画で見ると、人はつい「今の見た目」に引きずられます。ところが本当に知りたいのは、構えからインパクトまでのどの瞬間に重心が動いたのか、肩や腰の回転がどう連動したのか、という時間方向の構造です。見た目が整っていても、力が伝わる順序が破綻していれば、結果は安定しません。

変化に強い設計とは、見た目をきれいに保つことではなく、変化が入る場所をあらかじめ限定することです。

この視点で見ると、優れた設計は「美しいコード」ではなく「変化の境界線」を持っています。どこが頻繁に変わるのか。どこは安定させるべきか。どこに情報を置けば、あとから取り出しやすいか。設計とは、静的な整理ではなく、動的な予測です。

Fragment Colocationが教えるのは、部品を近づけることではない

Fragment Colocationは、単に関連コードを近くに置くという話ではありません。もっと本質的には、「その画面が必要とするデータの形」と「その画面が描く断面」を一緒に持たせるという発想です。これにより、画面全体の都合でデータを引っ張ってくるのではなく、必要な断面ごとに必要な情報を宣言できるようになります。

たとえば、プロフィール画面の上部に名前とアイコン、下部に投稿一覧があるとします。従来の発想では、画面全体が巨大なデータ構造を受け取り、その中から各UI部品が勝手に必要な値を拾うことが多いです。しかしFragment Colocation的な考え方では、名前とアイコンはこの断面、投稿一覧は別の断面として定義し、それぞれが自分に必要なデータを明示します。

この違いは、見た目よりもずっと大きいです。なぜなら、UIの変更がそのままデータ契約の変更になるからです。画面に「あとでこのカードを追加したい」と思ったとき、その追加は単なるレイアウト変更ではなく、どの情報がどの断面に属するかの再編成になります。逆に言えば、断面をうまく分けておけば、変更は局所化されます。

この発想は、バッティング動作の骨格推定にも似ています。人間は全身をひとつの塊として見がちですが、解析では関節ごとの座標、各部位の相対関係、時間的な連なりに分解します。すると、フォーム全体をいきなり理解しようとするのではなく、肩、肘、腰、膝という観測可能な断面から全体像を再構成できるようになります。

つまり、Fragment Colocationが扱っているのは、画面の整理術ではなく、意味の分割です。何をひとまとまりの意味単位として扱うべきかを決める技術だと言えます。

スイング解析と画面設計に共通する、3つの分解原則

ここで重要なのは、ただ細かく分ければ良いわけではないことです。細分化しすぎると、かえって全体が見えなくなります。大事なのは、変化に対応できる単位で分けることです。そこには、次の3つの原則があります。

1. 観測単位を、変更単位と一致させる

分析の世界では、関節や骨格の座標が観測単位になります。設計の世界では、UIの断片やデータフラグメントが観測単位になります。重要なのは、観測している粒度と、実際に変わる粒度を揃えることです。

たとえば、画面全体が一度に更新されるような設計では、小さな文言変更でも広い範囲に波及します。反対に、名前表示だけ、ボタンだけ、一覧だけが独立して更新されるなら、変更の影響は狭くなります。これは動画解析で、全身を一枚絵として扱うよりも、関節ごとに追跡する方が異常箇所を特定しやすいのと同じです。

2. 先に「意味の境界」を決める

よくある失敗は、実装の都合で境界を決めてしまうことです。これは、あとから見ると境界が不自然になります。意味の境界とは、「このまとまりは何を表しているのか」を基準に切ることです。

野球の動作解析でも、1フレームごとに分けるだけでは意味がありません。重要なのは、構え、始動、テイクバック、インパクト、フォロースルーのような、動作上の節目です。UIも同じで、ただファイルを分けるのではなく、ヘッダー、サマリー、アクション、詳細情報といった意味のある単位で分けると、保守も理解も楽になります。

3. 局所性は、知識の再利用を生む

フラグメントや関節のような局所単位があると、それぞれの部品が独立して理解しやすくなります。これは単なる実装の話ではありません。チームの認知負荷を下げる効果があります。

新しいメンバーが画面を理解するとき、巨大な全体図を一気に覚える必要があると辛いです。しかし「このカードはこの断面の責務」「ここで必要なデータはここにまとまっている」と分かれば、学習コストが下がります。動画解析でも、全身を一度に解釈するより、部位ごとの特徴を学習した方が再利用しやすい。局所性は、複雑さを小さくするだけでなく、理解の再利用可能性を作ります。

本当に強いチームは、コードではなく「予測可能な変化」を設計している

ここで見えてくるのは、設計の本当の目的です。多くの人は設計を、今の複雑さを整理する作業だと考えます。しかし実際には、設計の価値は未来に出ます。数週間後、数カ月後の変更が、どれだけ狭い範囲で済むかです。

たとえば、デザインリニューアルの局面では、見た目の変更が連続します。余白、フォント、画像の配置、ボタンの文言、カード構成。これらを画面単位でべったり結合していると、変更のたびに広い面積を触ることになります。逆に、フラグメント単位で責務が整理されていれば、変更は局所的になります。

これはデータサイエンスの現場でも同じです。骨格推定でバッティング動作を扱うとき、映像のどの部分から何を抽出するかが雑だと、後で分析が難しくなります。ところが、最初に関節座標という安定した表現を得ておけば、スイングの比較、異常検知、時系列解析へと展開しやすくなります。最初の分解が、後続のあらゆる分析を可能にするのです。

強い設計とは、今の実装を楽にすることではなく、未来の変更を予測可能にすることです。

この観点は、開発だけでなく、組織にも当てはまります。担当者ごとに知識が閉じているチームは、変化に弱いです。逆に、意味のある境界で責務が共有されているチームは、誰が入っても理解しやすく、変更の影響を追いやすい。設計はコードの話であると同時に、チームの認知の配線でもあります。

Key Takeaways

画面や動作を、見た目ではなく意味単位で分ける。 どこがひとつの責務なのかを先に決めると、変更に強くなる。
観測単位と変更単位を揃える。 変更が起きる粒度に合わせてデータやUIを切ると、影響範囲を狭められる。
局所性を設計する。 関連する情報を近くに置くことは、コード整理ではなく、理解と再利用のための基盤づくり。
未来の変更を基準に構造を選ぶ。 今日の美しさより、明日の改修コストを下げる構造を優先する。
全体を一気に理解しようとしない。 断面を積み重ねて全体を見る方が、複雑な対象は正確に扱える。

変化するものを、変わる前提で扱う

設計とは、静止画を描くことではありません。むしろ、時間の中で形を変える対象に対して、どこを固定し、どこを変えてよいかを決める行為です。画面も、スイングも、最初から完成しているわけではなく、変化の連続の中で意味を持ちます。

だからこそ、優れた構造は「全部をひとつにまとめる」のではなく、変わるものを変わる前提で扱えるようにする。Fragment Colocationが示すのは、そのための設計原理です。そして骨格推定のような分析が教えるのは、複雑な現実を理解するには、まず意味のある断面を取り出す必要があるということです。

結局のところ、私たちが本当に設計しているのは画面でもデータでもありません。変化に対する姿勢です。未来に何が起きても壊れにくい構造は、偶然できるのではない。最初から、変化を前提に世界を切り分けているのです。