「技術的に正しい・新しい選択」が常に正解なのか🤔について
はじめに
最近、技術選定において「技術的に正しい・新しい選択」と「組織として持続可能な選択」が一致しないことに直面しました。
Developers Summit 2026でのnwiizoさんの発表 意志を実装するアーキテクチャモダナイゼーション と、その基盤である書籍『Architecture Modernization』（Nick Tune & Jean-Georges Perrin著、スリーシェイク訳）の視点を借りて、この体験を振り返ってみたいと思い書いてみました。
スライドは以下に貼っておきます。
「説明しやすい嘘」と「説明しにくい真実」
「説明しやすい嘘より、説明しにくい真実を選べるか。それがリーダーの仕事。」
私は現在、リーダーではありませんがプロジェクトを前に進めていく上でこれは
とても重要かつ必要な視点だと感じています。
説明されていた例としては以下で
| 説明しやすい嘘 | 説明しにくい真実 |
|---|---|
| 「マイクロサービス化に2年かかります」 | 「まず半年かけて現状を理解します」 |
| 「新しいフレームワークで生産性2倍」 | 「今のコードを理解できる人を増やします」 |
これを私が直面したフロントエンドにおける技術選定の文脈に置き換えると
| 説明しやすい技術的正しさ | 説明しにくい現実 |
|---|---|
| 「FW非依存で長期的に安全な可能性が高い」 | 「その技術の経験者が市場に非常に少ない」 |
| 「ブラウザネイティブで軽量」 | 「デザインシステムが未整備で抽象化の前提がない」 |
| 「最適なJS配信アーキテクチャーの仕組み」 | 「少人数で運用していけるのか」 |
技術的な正しさはその優位性を 「説明し易い」 です。
特にベンチマーク等は定量的に示されているものがある為、比較すると一目瞭然なことも多々あります。
一方で「この技術を選んだとき、3年後に保守できる人が居続けるか？」などは非常に定量化しにくく、説明も難しい為、技術的な優位性にだけフォーカスがあたると途端に現実的な視点での分が悪くなります。
三体問題 【技術・組織・戦略】の相互干渉
「技術」「組織」「戦略」の3つが相互に影響し合う。どれか1つだけを変えても、残り2つが引き戻す。
こちらについてもフロントエンドの技術選定でも同じことが考えられると思っております。
先程の話にもありましたが 技術軸だけで見れば、Web標準寄りの構成は合理的であり、ブラウザネイティブ・フレームワーク非依存・パフォーマンス最適化など、技術的なスコアリングをすれば上位に入ると思います。
ですが、組織軸を加えると、話が変わります。
少人数チームであることや、選定した技術の経験者が採用市場に少なければ、メンバーが離職した場合に引き継ぎ先が見つからない問題などが発生しうる可能性が高いからです。これは『Architecture Modernization』で言及されている 「属人化という静かな爆弾」 が生み出される瞬間です。
戦略軸を加えると、更に変化します。数年後に別プロダクトへの変革の構想がある場合など、
今の技術選定がそこへの資産になるか、それとも負債になるかはエコシステムの充実度などにも寄与してくる為、エコシステムの小さい技術で組んだ資産は次に引き継げるのかは定かではありません。
nwiizoさんは「3つの変数に解析解はない。正解を計算するな。小さく動いて観測せよ」と仰っているので技術選定を技術だけで解こうとするのは、三体問題を一体問題として解いているのと同じことかなと思います。
コンウェイの法則は「物理法則」
「システムを設計する組織は、その組織のコミュニケーション構造をコピーした設計を生み出すことを余儀なくされる」—— Melvin Conway (1968)
これを「選択肢ではなく物理法則」と表現されておりました。
小さなチーム内で技術的な方向性が揃っていない場合、何が起きるか？
その状態である場合どんな技術を選んでも、コンポーネント設計がチグハグになり、暗黙の前提がズレ、どの思想も中途半端に実装される可能性が高くなります。
コンウェイの法則が教えてくれるのは、技術選定の前に「チーム内の合意形成」がボトルネックだということです。
逆に言えば、明確な合意のもとで選ばれた技術であれば多少マイナーでもうまくいく可能性があると思います。問題は技術そのものではなく合意なき選定がもたらす物理法則を無視したエゴだと感じます。
「AIで書けるから大丈夫」は本当か？
最近常々、感じていることではありますが「経験者がいなくても、AIがコードを書いてくれるから問題ない」という想いについては
「AIは『How』を加速する。だが『What』と『Why』は加速しない。」
を受けて、少し考え方が変わりました、確かにAIは任意の技術のコードを生成できます。
経験がなくても「○○で書いて」と言えば出力はされる。
学習コストは信じられないほど下がっている。これは事実です。
しかし
- その技術固有の挙動に起因するバグの原因に気づく力
- 複数技術の組み合わせで問題が起きたとき切り分ける力
- 想定外の挙動に遭遇したときAIに正しい質問を立てられる力
これらについてはnwiizoさんのプレゼンで紹介されていたBirgitta Böckeler（Thoughtworks）のHarness Engineeringの概念が参考になります。
AIエージェントを活用するには、Context Engineering（正しい文脈を与える）とArchitectural Constraints（制約で方向を定める）がまだ一定程度必要です。
つまりAIを使いこなすにもドメイン知識が要るということに帰結する為、AIの回答品質自体が学習データ量に依存するということです。
故にメジャーなフレームワークとマイナーな技術では、情報量に桁違いの差がありエコシステムが小さい技術ほど、AIの回答精度も構造的に下がるという点においてはまだ、存在していると思っています。
「意志」と「好み」を区別する
タイトルにもなっている「意志を実装する」点において
「どんな価値を届けるか（ビジネスへの意志）、どこに境界を引くか（アーキテクチャへの意志）、チームをどう分けるか（組織への意志）。」
技術選定において「意志」と「好み」は似ているようで全く違うと思っております。
意志とは、ビジネス目標・チーム状況・将来計画を踏まえた上での判断。三体問題のすべての変数を考慮していることです。
一方、好みとは、技術的信念や過去の成功体験に基づく選択。技術軸だけで完結しています。
ある技術を選ぶ理由が意志なのか好みなのかについては以下のような質問を行えば把握できると思います
- 「この選択は、チーム構成が変わっても持続可能か？」
- 「数年後、この技術スタックで人を採れるか？」
- 「次のプロダクトに資産として引き継げるか？」
これらのようなビジネス的な視点での質問に対しても 「Yes」 と答えられるなら意志である可能性が大きいですが、答えに詰まるようであれば意志のように見える好みかもしれません。
Simon Wardleyの言葉がプレゼンで引用されていましたが
"Success breeds inertia, and the greater the past success, the greater the inertia."
（成功は惰性を生む。過去の成功が大きいほど、惰性も大きくなる）
過去にある特定の技術でうまくいった経験があるほど、文脈が変わっても同じ選択を繰り返してしまう。それは意志ではなく惰性だと。
見えないコストを見る
書籍『Architecture Modernization』では、機能的価値（新機能、画面、API）は目に見えるが、非機能要件（セキュリティ、可用性、属人化リスク）は目に見えない、と指摘しています。
フロントエンドにおける技術選定も同じように考えることが可能です。
見えるコスト：パフォーマンスベンチマーク、バンドルサイズ、Lighthouseスコア。定量化できる。比較表として示すことができ、定量的である為見栄えもよいものです。
見えないコスト：引き継ぎコスト、採用コスト、離職リスク、ドキュメントの陳腐化など、定量化し難いものです。
ただし、ビジネスとしてのプロダクトについて長期的な存続を決めるのはこちらの方（見えないコスト）がより大きな影響を及ぼします。
「いくらかかるか」ではなく「何のリスクを誰が引き受けるか」で判断する。
この問いを技術選定に適用すると、「この技術を選んだリスクを、誰が引き受けるのか」 になります。選んだ人が引き受けるのか。実装する人が引き受けるのか。それとも、将来入ってくるまだ見ぬメンバーが引き受けることになるのか...
「権限なき責任は拷問」、そして小さく動く
「権限なき責任は拷問。チームに責任を求めるなら、権限もセットで渡せ。」
技術選定の決定権を持たないまま、選ばれた技術で保守する責任だけを背負う。
これはフロントエンドの現場で珍しくない構図だと思います。
このような状態対して二つの方向性を示しておられました。
一つは、「この壁を越える権限がないなら、その権限を獲りに行け」。
もう一つは、「正解を計算するな。小さく動いて観測せよ」。
私が出した答えは後者に近く。議論するよりも簡単に動くものを見せる。です。
その為のTipsとしてはこちら（自分の宣伝です🙇）
技術選定の議論は結局のところ抽象的になるほど平行線を辿り「○○の方が技術的に優れている」「いや△△の方が」というように永遠に決着しない場合があります。
ただ、その時に動くプロトタイプがあれば、パフォーマンス・開発体験・保守性、全部触って確かめることができ、「説明しにくい真実」が「目に見える事実」に変わります。
議論のテーブルが「思想 vs 思想」から「プロダクト vs プロダクト」に変わっていくのです。
おわりに
フロントエンドの技術選定は、フレームワークの優劣比較だけでは留まらず
「技術」「組織」「戦略」の三体問題であり、コンウェイの法則が支配する領域であり、見えないコストとの戦いということです。
nwiizoさんのプレゼンの冒頭に、こんなフレーズがありました。
「事情でレガシーシステムと呼ばれ、敵にされる全てのシステムに敬意を表します。それらのシステムは、かつて誰かが全力で作り、ビジネスを支え、価値を生み出してきた。」
新しい技術選定もいつか「なぜこの構成にしたのか」と問われる日が来ることでしょう。
そのとき「技術的に正しかったから」では足りず、「この文脈で、このチームで、このビジネスにとって、最善だった」と言えるかどうかだと
それが「意志を実装する」ということだと思います。
Q.結局何が言いたかったのか?
A.「黙って全部オレに投資しろ」という意気込みでやるし、ちゃんと考えてるから色々決めさせてよ🥹！！
参考
-
アーキテクチャモダナイゼーション ―組織とビジネスの未来を設計する - Nick Tune & Jean-Georges Perrin著、スリーシェイク訳（翔泳社、2025）
-
Harness Engineering - Birgitta Böckeler / martinfowler.com
Discussion