株式ポートフォリオとダークモードに共通する、壊れない設計の原則

「何かが下がるとき、何かが上がる」ように設計できたら、投資だけでなくソフトウェアも壊れにくくなる。では、株式ポートフォリオの分散と、ダークモードのCSS設計は、なぜ同じ発想で説明できるのだろうか。

一見すると、金融とフロントエンド開発にはほとんど接点がない。片方は資産価格の変動を扱い、もう片方は画面の配色を扱う。しかし両者の中心にあるのは、変化するものを、変化しない仕組みから切り離すという設計思想である。

投資家は、特定の銘柄や市場の動きにすべてを賭けないために、資産やセクターを分散する。UI設計者は、画面中の色を直接書き込まず、CSS変数という共通の名前を通じて配色を管理する。前者は市場の揺れに耐えるため、後者はテーマ変更や仕様変更に耐えるためだ。

この二つを結びつけると、実務にも人生にも使える一つの原則が見えてくる。

強いシステムとは、予測が当たるシステムではない。予測が外れても、全体が壊れないシステムである。

分散の本質は「数を増やすこと」ではない

投資における分散は、単に銘柄をたくさん持つことではない。十種類の株を持っていても、すべてが同じ業界に属し、同じ金利や景気に反応するなら、見かけ上の銘柄数が増えただけである。

重要なのは、異なる要因に反応するものを組み合わせることだ。成長株は金利上昇に弱いかもしれない。一方、資源株は資源価格やインフレの影響を受ける。ある資産が下落する局面で、別の資産が相対的に上昇する可能性があれば、ポートフォリオ全体の振れ幅は小さくなる。

ここで注意したいのは、分散が利益を最大化する技術ではないという点だ。絶好調の資産だけに集中すれば、短期的には大きな利益を得られる。しかし、その判断が外れたときの損失も大きい。分散の目的は、最も良い結果を取ることではなく、悪い結果がシステム全体を破壊することを防ぐことにある。

これはソフトウェアの設計にもそのまま当てはまる。画面の各所に色の値を直接書き込む実装を考えてみよう。背景色、文字色、ボタンの色、境界線の色が、それぞれ個別の値として散らばっているとする。通常モードだけなら動くかもしれないが、ダークモードを追加する瞬間、変更箇所が一気に増える。

同じ色が十か所に書かれていれば、十か所を確認しなければならない。さらに、一部だけ変更し忘れれば、画面は不自然な配色になる。これは、ポートフォリオの資産がすべて同じリスク要因に依存している状態と似ている。平穏なときには問題が見えないが、環境が変わった瞬間に一斉に弱点が露出する。

CSS変数は、配色のための「資産配分表」である

効率的なダークモードの実装では、まず全体の配色をCSS変数として定義する。例えば、背景を表す変数、主要な文字色を表す変数、アクセントカラーを表す変数を用意する。画面の各部品は、具体的な色の値ではなく、それらの意味を参照する。

この構造では、コンポーネントは「この場所を黒にする」とは考えない。「これはページの背景である」「これは主要な文字である」と考える。ライトモードとダークモードでは、同じ役割に異なる値を割り当てるだけでよい。

このとき、CSS変数は単なる便利な記法ではない。変化する具体値と、安定した意味を分離するための境界である。

投資で言えば、個別銘柄の価格は変化する具体値であり、株式、債券、資源、現金といった資産クラスは役割に近い。価格を直接信奉するのではなく、「成長を担う資産」「防御を担う資産」「インフレへの耐性を担う資産」のように役割で捉えると、環境が変わっても構成を調整しやすくなる。

UIでも同じだ。色番号を直接使うと、設計は値に縛られる。意味を表す名前を使えば、テーマが変わっても部品の構造は変えずに済む。ライトモードからダークモードへの切り替えは、画面を一から作り直すことではなく、同じ役割に別の配色を割り当てることになる。

この考え方は、設計の「抽象化」と呼べる。ただし、抽象化は難解な構造を増やすことではない。むしろ本質的な抽象化は、複雑な変化を一か所に集約し、それ以外の場所から見えなくする。

良い設計は、予測ではなく相関を管理する

ポートフォリオでもUIでも、将来を正確に予測することはできない。どのセクターが上がるか、どのテーマがユーザーに好まれるか、すべてを事前に知ることは不可能だ。だからこそ、予測よりも重要になるのが、構成要素同士の関係である。

投資では、資産同士の値動きの相関を見る。すべてが同じ方向に動けば、資産を増やしても危険は減らない。反対に、異なる方向へ反応する資産を組み合わせれば、個別の予測が外れても全体の損傷を抑えられる。

ソフトウェアでは、変更同士の相関を見る。色の値が複数のコンポーネントに直接埋め込まれていると、一つの仕様変更が多くのファイルに波及する。配色をCSS変数に集約すれば、テーマの変更とコンポーネントの構造を疎結合にできる。

ここで使える mental model は、変動の分離である。

一つ目は、どの要素が変わるのかを特定すること。市場価格、金利、テーマカラー、ブランド方針などが該当する。

二つ目は、変わらない役割を定義すること。成長、防御、背景、主要テキスト、警告表示などである。

三つ目は、変わる要素を役割の裏側に配置すること。利用者や他の部品が、具体的な値に直接依存しないようにする。

四つ目は、一つの変更で全体を検証できるようにすること。投資なら資産配分の見直し、UIならテーマ切り替えの確認である。

この構造ができると、変化は脅威から操作可能なパラメータへ変わる。

「分散しすぎ」と「抽象化しすぎ」の共通リスク

ただし、分散も抽象化も、多ければ多いほど良いわけではない。ここに重要な落とし穴がある。

投資で銘柄を増やしすぎると、管理が難しくなり、何を持っているのか分からなくなる。また、相関の高い資産を細かく分けても、本当の意味での分散にはならない。分散とは、無秩序に増やすことではなく、異なるリスク要因を意識的に配置することだ。

CSSでも、すべてを細かい変数にすると、かえって意味が失われる。「青一」「青二」「青三」のような名前を大量に作れば、数値は隠せても設計意図は隠れてしまう。必要なのは、色の見た目ではなく役割に基づく変数である。「主要テキスト」「補助テキスト」「危険状態」のような名前なら、利用箇所の判断を助ける。

つまり、両者に共通する基準は、管理可能な複雑さかどうかである。

良いポートフォリオは、全資産を毎日監視しなくても全体像を把握できる。良いデザインシステムは、すべての画面を個別に点検しなくても、色のルールを一か所で理解できる。構成要素が増えても、意思決定の負担が増えすぎないことが重要だ。

さらに、分散にはコストもある。投資では、集中投資に比べて急上昇の恩恵を薄める可能性がある。UIでは、変数や設定の層を増やすことで、最初の学習コストが高くなることがある。

それでも分散や抽象化が価値を持つのは、将来の変更コストを下げるからだ。現在の最短距離ではなく、変化を含めた総コストで設計を評価する必要がある。

「一か所を変えれば全体が変わる」仕組みを作る

この原則を実務に落とし込むには、まず自分のシステムにおける「直接埋め込み」を探すとよい。投資なら、一つの国、一つの業界、一つの景気シナリオに過度に依存している部分である。UIなら、画面のあちこちに散らばる直接的な色指定である。

次に、それらを役割へ変換する。資産なら「成長」「防御」「流動性」「インフレ耐性」という機能で整理する。配色なら「背景」「主要テキスト」「補助テキスト」「境界線」「アクセント」「状態表示」という意味で整理する。

そして、変更が起きる場所を限定する。ポートフォリオの配分を見直すときに、全銘柄を感情的に売買するのではなく、事前に決めた配分と許容範囲に照らして判断する。ダークモードを追加するときに、各コンポーネントを作り直すのではなく、globals.cssの変数と設定ファイルの対応を調整する。

最後に、切り替えをテストする。投資では、特定の資産が大きく下落した場合に、全体の損失がどの程度になるかを確認する。UIでは、長い文章、無効状態、警告表示、画像の上に重なる文字など、通常時に見落としやすい場面を確認する。

この方法の価値は、問題が起きてから頑張るのではなく、問題が起きても被害が局所化される点にある。

柔軟性とは、何でも簡単に変えられることではない。変えるべき場所だけを変え、変えてはいけない場所を守れることである。

Key Takeaways

1. 数を増やす前に、異なるリスクや変化要因を分ける 銘柄数や変数の数ではなく、それぞれがどの役割を担い、何に反応するのかを確認する。

2. 具体的な値ではなく、意味に依存する 投資では個別価格だけでなく資産の役割を見る。UIでは色番号ではなく、背景や主要テキストといった意味を参照する。

3. 変化する部分を一か所に集約する 配分変更やテーマ変更が、システム全体への手作業ではなく、限定された設定変更になるように設計する。

4. 相関を点検する 複数の資産が同じ要因で動いていないか、複数のコンポーネントが同じ値に直接依存していないかを調べる。

5. 現在の手軽さではなく、将来の変更コストで判断する 直接書く方法は最初だけ速い。長期的には、変更範囲を制御できる構造のほうが安定する。

投資のポートフォリオとUIのテーマ設計は、別々の専門知識に見える。しかし、どちらも不確実な環境の中で、全体を守りながら部分を変える技術である。

私たちはしばしば、良い判断とは未来を言い当てることだと考える。上がる株を選び、最適な色を一度で決め、正しい仕様を先に予測しようとする。だが、現実の市場もプロダクトも、予測どおりには進まない。

だから本当に問うべきなのは、「何が起きるか」だけではない。「予想外のことが起きたとき、どこまで壊れる構造になっているか」である。

資産を分散し、意味をCSS変数に託す。これは単なるリスク管理や実装テクニックではない。変化を前提に、安定性を設計するための一つの思想である。未来を支配できないなら、せめて未来が変わっても、自分のシステムが一度に崩れないように作っておく。その控えめな設計こそが、長く機能する強さを生む。