OSの移行より怖いのは、複雑性が人間の脳を先に壊すこと

いちばん難しいのは、コードを書くことではない

新しいOSへ移行する話を聞くと、多くの人はまず技術的な互換性を気にする。アプリは動くのか、ドライバはどうなるのか、既存資産はどう守るのか。だが本当に厄介なのは、機械が動くかどうかではない。人間がその複雑さを理解し続けられるかどうかだ。

ここに、ソフトウェアの進化を見誤る根本的な落とし穴がある。システムの移行は、表面上は「プラットフォーム変更」に見える。けれど実際には、開発者、設計者、運用者、経営層の認知負荷をじわじわ増やす。最初は追える。次に曖昧になる。そしてある瞬間から、全体像は人間の脳の計算量を超える。

だから本当の問いは、次のように言い換えるべきだ。「このOSは動くか」ではなく、「この複雑さを組織は理解できるか」。

複雑性はコードの問題ではなく、認知の問題である

ソフトウェアの複雑性は、たいてい計算量で語られる。処理件数が増えれば、O(N)の世界ではまだ見通せる。O(N²)になると、だんだん挙動が読みにくくなる。O(2^N)になれば、もはや手に負えない。だがこの比喩の本当に面白いところは、コンピュータより先に人間の理解能力に同じ曲線が現れることだ。

たとえば、単一のOSと単一のアプリ基盤だけを考えるなら、設計は比較的単純だ。ところが、複数のOS世代、複数のUI層、複数の配布経路、複数のSDKが絡み始めると、変更のたびに影響範囲が爆発する。あるライブラリを更新しただけで、ビルド、テスト、権限、UI、性能、保守体制まで連鎖的に説明しなければならない。

この時点で、複雑なのはコードではない。説明のコストである。誰かが理解するたびに、別の誰かがその理解を前提にさらに理解しなければならない。結果として、システムの本質は「機能」ではなく「認知の連結構造」になる。

複雑性の最大の害は、エラーを増やすことではない。人間が全体像を持てなくなることだ。

この視点に立つと、OS移行の議論は一変する。重要なのは新しい基盤が高性能かどうかだけではない。その基盤が、どれだけ少ない精神コストで理解できるか。どれだけ少ない例外で運用できるか。どれだけ少ない「暗黙の前提」で成立するか。つまり、技術選定とは認知設計なのだ。

---

「ひとつの基盤に揃える」は、簡単になるとは限らない

多くの組織は、断片化した環境をまとめたいと考える。アプリはひとつのフレームワークで書けたほうが良い。UIもレンダリングも同じ思想で揃えば、開発速度は上がる。ここで浮かぶのが、共通のSDKやマルチプラットフォーム基盤だ。理屈の上では美しい。学ぶことが少なくなり、再利用が増え、実装の一貫性も高まる。

しかし、ここに落とし穴がある。統一は、単純化ではなく、複雑性の圧縮であることが多いからだ。

複雑性が分散しているとき、人はそれを局所的に処理できる。チームAはAの問題だけを知ればよく、チームBはBの問題だけを知ればよい。だが統合が進むと、ひとつの基盤の中に異なる制約が詰め込まれ、すべての人が全体のルールを学ぶ必要が出てくる。結果として、表面上は「楽」でも、深層では認知負荷が集中する。

これは、家の配線を一つの巨大な制御盤に集約したようなものだ。見た目は整理される。だが、どこかで異常が起きたとき、原因の切り分けが一気に難しくなる。複数の小さなブレーカーなら局所的に止められるのに、巨大な制御盤では、一箇所の判断ミスが家全体に波及する。

だから重要なのは、統一するかどうかではない。どこまでを共通化し、どこからを分離するかである。優れたアーキテクチャは、複雑性を消すのではなく、人間が扱える粒度に分割する。

具体的には、次の三層で考えるとわかりやすい。

1. 共通化すべき層: 変更頻度が低く、原理が安定している部分
2. 分離すべき層: OS差分や端末固有の挙動が強い部分
3. 観測可能にすべき層: 問題が起きた時に原因追跡が必要な部分

この3層が混ざると、システムは一気に理解不能になる。逆に、境界が明確なら、多少内部が複雑でも運用できる。理解のしやすさは、複雑さの総量ではなく、複雑さの境界設計で決まる。

開発基盤が変わるとき、組織の思考回路も変わる

OSの移行は、単なる実装変更ではなく、開発文化の再配線でもある。もしアプリ開発に共通のSDKが使われるなら、開発者は「OSごとの差分」よりも「ひとつの抽象レイヤーの中でどう表現するか」を考えるようになる。これは便利だが、同時に危うい。抽象化は理解を助けるが、行き過ぎると現実を見えにくくするからだ。

ここで大事なのは、抽象化を善と悪で見ることではない。抽象化には必ず視界を狭める副作用があると理解することだ。たとえばFlutterのような共通SDKは、複数のOSにまたがる開発体験を整える。一方で、その下で起きているプラットフォーム固有の制約は、普段は見えにくくなる。見えにくいものは、問題が起きた瞬間に初めて認識される。つまり、楽になったはずの体験が、障害時に一気に難しくなる。

この構造は、優れた地図に似ている。地図は道をわかりやすくするが、舗装の状態、坂のきつさ、風の強さまでは完全には示せない。都市を横断するルート検索は簡単でも、実際に歩くと別の負荷がある。ソフトウェアも同じで、抽象化はルート案内には強いが、現地の地形まで消してはくれない。

だから、組織が本当に鍛えるべきなのは、ひとつの基盤を盲信することではない。抽象化の外側に何が残っているかを見抜く能力だ。ここを誤ると、「統一したから大丈夫」という安心感が、もっとも高くつく。

優れたプラットフォームは、複雑さを隠すのではなく、複雑さの所在を明示する。

この一文は、設計と経営の両方に効く。現場の開発効率だけを見れば、統一は魅力的だ。しかし中長期で見ると、プラットフォームの価値は「速く作れること」よりも、「どこが難しいかを正しく把握できること」にある。難所が見えるシステムは改善できる。難所が見えないシステムは、問題が起きるまで最適化の余地がない。

脳が壊れる前に、計算量を減らす設計に変える

では、どうすれば複雑性の爆発から逃れられるのか。答えは、勇気を持って機能を減らすことではあるが、単なる削減では足りない。必要なのは、認知負荷を減らす設計原則である。

まず大切なのは、説明可能性だ。どんなに高機能でも、チームの誰も全体を説明できないなら、それはすでに危険域に入っている。仕様書があるから安全なのではない。仕様変更時に、影響範囲を言語化できるから安全なのだ。説明不能なシステムは、ほぼ確実に運用不能になる。

次に、境界の設計だ。責務が混ざったシステムでは、1つの変更が全体に波及する。逆に、境界が明確なら、複雑な内部実装を抱えていても、外からはシンプルに見せられる。良いモジュール化とは、内部を単純にすることではなく、外部から見た振る舞いを予測可能にすることだ。

最後に、例外の数を数えることだ。複雑なシステムほど、例外対応が「仕様」になりやすい。だが例外は、積み上がるほど認知コストを指数関数的に増やす。例外が1つなら覚えられる。5つならまだいける。20を超えると、人はルールではなく勘で動き始める。すると、組織全体が属人的になる。

ここで使える実践的な問いは、次の3つだ。

• この変更を、新人に15分で説明できるか
• 障害が起きたとき、原因候補を3つ以内に絞れるか
• 仕様の例外をなくしたとき、どの前提が崩れるか言えるか

この問いに答えられないなら、そのシステムはすでに「機能的には動くが、認知的には壊れかけている」と見てよい。

Key Takeaways

• 技術選定は認知設計でもある。OSやSDKの統一は、コードを減らすだけでなく、理解の仕方そのものを変える。
• 複雑性の本質的なコストは、説明コストである。人が全体像を持てなくなった時点で、運用難度は跳ね上がる。
• 統一は単純化ではなく、複雑性の圧縮になりうる。共通化と分離の境界を明確にすることが重要。
• 抽象化は視界を狭める。便利さの裏で、プラットフォーム固有の制約が見えにくくなることを忘れない。
• 「新人に説明できるか」は強力な健全性チェック。説明不能な設計は、たいてい改善余地が大きい。

では、何を基準に判断すべきか

最後に、OS移行や基盤統一を考えるときの基準をひとつに絞るなら、それは「性能」でも「流行」でもない。その複雑さが、組織の脳にとって線形に扱えるかどうかだ。

線形に扱えるとは、変更を入れても影響が予測でき、学習コストが増えても全体像が保てることを意味する。逆に、変更のたびに説明が増殖し、例外が例外を呼び、誰も全体を持てなくなったなら、そのシステムはすでに人間の理解能力を超えている。

だから、未来の勝者は、最も多機能な基盤を選ぶ会社ではない。複雑さを人間が理解できるサイズに保ち続ける会社だ。見た目は地味でも、その差は時間が経つほど大きくなる。システムは壊れる前に、まず理解不能になる。そこに気づけるかどうかが、これからの設計を分ける。

本当に問うべきなのは、どのOSが次に来るかではない。私たちは、その移行を理解し続けられる組織であり続けるか。この問いに答えられないなら、どんなに優れたプラットフォームでも、最後には脳のほうが先に限界を迎える。