技術選定力の正体──「選ぶ力」ではなく「技術を組織の力に変える力」

最近、Claude Code と技術選定について長めに話をする機会がありました。

最初は「技術選定力とはどう定義しますか？」という割とオーソドックスな問いから始めたんですが、対話を重ねるうちに自分の考えがどんどん整理されて、最初に抱いていた定義とは全然違う場所に着地しました。

「技術選定力 = 優れた技術を見極める目」だと思っていたんですが、それ、かなり表面的な理解だったんですよね。

この記事はその対話のプロセスを振り返りながら、技術選定力の正体について考えたことを整理したものです。結論を急ぎたい方は最後のセクションだけ読んでいただければ。ただ、思考プロセスを一緒に辿っていただく方が、より納得感があるかもしれません。

最初の定義──技術選定力は「評価軸の立て方」か？

最初に出てきた定義は、こんな感じでした。

どれも正しいことは正しい。でも読み返してみると、どこかよそよそしい感じがする。「書いてあることはわかるけど、これで本当に選定がうまくいくのか？」という感覚が抜けない。

「失敗の原因」という問いで崩れ始める

少し掘り下げてみたのが、「判断時点では合理的だったのに、あとからうまくいかないとわかってきた──これは技術選定力がなかったということなのか？」という問いでした。

ここで出てきた整理が面白くて。

「決定の質」と「結果の質」は別の話、という視点です。ポーカーで正しい確率計算をしても負けることがある、というやつ。

ただ、これに対して自分の実感として「でも、丁寧にやってたら不運が起きることってそんなにないんじゃない？」という感覚があって、そこを突っ込んでみました。

「不運」はほとんど言い訳──プロセスの省略が失敗の本質

自分がエンジニアとして技術選定を行ってきた経験を振り返ると、大きな失敗がほとんどなかった。その理由を言語化してみると、

こういうプロセスを踏んでいたからだと思っています。

そこで気づいたことがあって。よく言われる「技術選定の失敗」って、結局こういうプロセスの省略から来ているんですよね。

純粋な「運の悪さ」で失敗するケースは、正直ほとんどない。

そう考えると、先ほどの「判断プロセスが良くても不運で失敗することがある」という整理は、技術選定に関しては少し違う気がしてきました。技術選定はポーカーほどランダム性が高くない。検証可能な意思決定だからこそ、プロセス次第でほぼ制御できる。

「組織のリソース」という視点

スケールの問題（10万ユーザーで起きる問題は小規模検証では見えない）や時間軸の問題（2〜3年運用してみないとわからないメンテナンス性の劣化）など、検証しきれない領域は確かに存在する。

これについての自分の考えは、「限界を認識した上で足を踏み入れるしかない。問題が出てきたら、ねじ伏せて運用できる状態にする。それが組織の力じゃないか」というもの。

引き返すことばかり考えていたら、前に進めない。

ただ、ここで「ねじ伏せやすい技術」と「ねじ伏せにくい技術」の差は、選定段階である程度わかるんじゃないか、という問い返しがあって、それはその通りだと思った。コミュニティの厚さとか、内部構造の透明性とか。

さらに重要な観点として出てきたのが、組織の中にどれだけリソースの余裕があるかという話。同じ技術でも、リソースに余裕があれば踏み込んでねじ伏せられるし、余裕がなければ撤退が正しい判断になる。

技術の評価と組織の自己評価の両方ができて、初めてまともな技術選定になる、ということです。

バランス感覚こそが差をつける

「やりたいこと」と「自分たちにできること」のバランスが取れていない人は、大規模な技術的変更でも失敗する確率が上がる。逆にそのバランス感覚がしっかりしている人は、大規模な変更でも失敗しにくい。

これは感覚として持っていたことで、ここで少しはっきりした気がします。

技術選定の失敗って、技術の知識が足りないから失敗するんじゃなくて、「やりたいこと」と「自分たちにできること」のバランスが取れていないから失敗する。

組織のリソースや対応力の見積もり精度は、経験を積むほど上がっていく。「技術選定力は経験を積むほど伸びる」というのも、技術知識が増えるからというよりは、むしろこっちの精度が上がるからという面が大きいかもしれない。

ちなみに、背伸びして少し難しい技術に踏み込むことで組織自体が成長するケースもある、という視点も出てきましたが──これも結局、「失敗リスクをあらかじめ許容できる体力があるかどうか」の話なので、リソース依存という構造は変わらない。

Resume Driven Development という問題

「技術者が単純に興味があるだけで手を出して、結果運用・定着できずに失敗した」ケースは、実際によく見かけます。業界でも認識されている問題で、名前までついています。

Resume Driven Development（経歴駆動開発）

自分の履歴書に書きたい技術を選ぶ。転職市場での価値を上げることが動機になっている。

Hype Driven Development

カンファレンスで聞いた、ブログで見た、SNS で話題、だから採用。「GAFA が使っている」が根拠になりがち。

なぜこれが起きるかというと、構造的な原因があって。

つまり、導入のインセンティブと運用の責任が分離していることが根本的な原因だと思っています。

自分の場合、技術に興味がないわけじゃなくて、いいと思うものは取り入れたほうがいいというスタンスは持っている。でも「自分以外が置いてけぼりになってしまうものを選んだところで、うまくいかない」という感覚も同時に持っている。

結局、「いいと思うもの」の定義の中に、最初からチームが扱えるかどうかが含まれているということなんだと思います。技術単体の良さではなく、自分たちの文脈での良さで判断している。

では、体系化はどうなっているのか

世の中に存在するフレームワークを確認してみると、いくつかあります。

技術評価系

成熟度系

普及・採用系

ただ、正直に言うと、これらを見ていて気になることがあります。これらのフレームワークは「技術をどう評価するか」に偏っていて、「組織として技術をどうものにするか」という視点が薄い。

技術選定は本来、ソフトウェア工学・組織論・ビジネス戦略にまたがる話なのに、学問としてはそれぞれ別の人たちが別の文脈で研究している。だから統合的なフレームワークが生まれにくいという構造的な問題がある。

なんのために技術選定を行うかというと、事業において成果を出すためです。それが一緒に考えられていない体系化は、実務的な価値として薄くなってしまう。

最終的な定義

ここまでの議論を整理すると、技術選定力を構成する要素として：

ただ、この5つを並べると、まだ「項目の羅列」感がある。根っこにあることは一つで、

技術選定力とは、技術を選ぶ力ではなく、技術を組織の力に変える力である。

これが今の自分の定義です。

「選ぶ」ことが目的ではなく「ものにする」ことが目的であり、技術単体の良し悪しではなく、技術と組織の現実を噛み合わせて事業成果に結びつける、総合的な力。

おわりに

最初の定義──「機能要件への適合性、トレードオフの判断、リスク見積もり、説明力」──と比べると、かなり解像度が変わりました。

最初の定義は技術選定を「一時点の意思決定」として捉えていて、「最適な技術を選ぶ判断力」という枠組みで考えていた。でも今回の整理では、技術選定は選ぶ瞬間だけに閉じたものじゃなくて、選定→検証→導入→運用→修正というサイクル全体を組織として回す力だという認識になりました。

もう少しだけ個人的なことを言うと、こういう「定義を疑い直す」思考が好きなんですよね。一見「そういうものだろう」と思っていることを丁寧に問い直してみると、全然違う場所に着地することがある。内省とエンジニアリングって、意外とそこが似ているなと感じます。

参考

技術選定やアーキテクチャ設計の意思決定について、より体系的に学びたい方には以下の書籍が参考になります。