技術選定で後悔しないための判断基準 流行との距離を測る

TL;DR

• 技術選定で後悔する原因は「hype追従」「過剰設計」「予測ミス」の3つ。
• 判断軸は「コスト / 可逆性 / チーム適合 / 将来性」の4軸で整理できる。
• 意思決定は個人の勘ではなくチームで記録に残すプロセスに乗せる。

シリーズ記事一覧

本記事は「技術選定（tech-decision）」シリーズの親記事です。各テーマの詳細は以下の子記事で解説しています。

1. とりあえず microservices が失敗する理由 過剰分割と回帰の判断軸
2. 責務分離が崩壊する理由と設計原則 AI生成コード時代の境界設計
3. 速度と品質どちらを取るべきか 開発のトレードオフ設計
4. Technology Radar の作り方｜30分会議テンプレ付
5. 自社IDP構築の現実的なロードマップ

はじめに

こんにちは、みねです。

AIツールが毎週増え、マイクロサービスが再評価され、責務分離は崩れやすくなっています。「なぜこれを選んだのか」を1年後に説明できない技術選定は、ほぼ間違いなく後悔する方向に進みます。

この記事のゴール: 技術選定の失敗パターンを整理し、再現可能な判断軸と意思決定プロセスを示すこと。特にAIツール乱立の今は、決めた後に正当化する文化と決める前に議論する文化の差が1年後の負債量に直結します。

この記事がカバーしないこと:

• 特定技術の比較（React vs Vue など、各論は個別記事へ）
• 採用面接での技術選定評価
• 大規模組織固有のベンダーマネジメント

1. 技術選定で後悔する3パターン

後悔する技術選定には共通の型があります。

hype追従

「話題だから導入する」。これ自体は悪くないんですが、チームで議論した記録が残っていないと、半年後に「結局何が良かったんだっけ」が誰にも答えられません。X や HN で流行っているだけでプロダクションに入れると、後から「誰かが勝手に決めた」事になりがちです。最近だと、AIツールの流行の変化が速く、3ヶ月前にMVPを作ったツールがもう別のツールに置き換わっている、というケースも増えています。流行自体を追うことは悪ではないですが、追う前に議論の軸を合意することがどれだけ重要かが、改めて問われています。

過剰設計

「将来スケールするかもしれない」を理由に、今必要ない抽象を入れるパターン。マイクロサービスへの早すぎる分割、使わない Kubernetes、不要な GraphQL などが典型。運用コストが先に来るので、スケールする前にチームが疲弊します。「YAGNI（You Aren't Gonna Need It）」は30年前から言われている原則ですが、いまだに最もよく踏む地雷です。判断軸として「この機能は今月使うか」を問うて、答えが No なら保留にするだけで、多くの過剰設計は避けられます。

予測ミス

「このツールは今後も伸びる」という予測が外れるケース。予測は必ず外れるという前提で、可逆性（戻せるかどうか）を設計時点で評価するのが定石です。予測の正確さを上げようとするより、「予測が外れても傷が浅い構造」を作るほうが現実的な戦略です。ツール依存を抽象化レイヤで隔離する、データ形式を標準化する、移行パスをドキュメント化する等。撤退の設計が上手いチームは、結果的に新技術を積極的に試せます。

3パターンの根本原因

この3つに共通するのは「決めた理由を記録しない」という運用問題です。技術選定は技術力よりプロセスの問題。Tech Lead 個人の感覚ではなく、チームとして議論の跡が残る形に乗せるだけで、失敗率は大きく下がります。ADR（Architecture Decision Record）を運用している組織とそうでない組織で、1年後の「これなぜ入れたんだっけ」の発生率に明らかな差が出ます。

深掘り記事: とりあえず microservices が失敗する理由

2. 判断軸の体系

選定時に問うべき軸は4つに整理できます。

この4軸で明確に「◎/◯/△/×」を付けるだけで、議論が一気に進みます。ポイントは全軸で満点を目指さないこと。コストが高くても可逆性が確保されていれば試せるし、将来性が読めなくてもチーム適合が高ければ組織学習として価値があります。

流行との距離を測る

流行との距離も重要です。最先端すぎるとドキュメントが薄く、遅すぎると競合に置いていかれる。目安として「主要な技術メディア3つ以上で半年以上取り上げられている」を採用ラインにすると、hype 追従と周回遅れのどちらも避けやすいです。

軸に優先順位をつける

4軸はフェーズごとに重みが違います。PMF 探索期ならコストと可逆性、スケール期ならチーム適合と将来性が重い。同じツールでもフェーズが変われば選定結果が変わる、という当たり前のことを明示的に扱います。また、候補が2つ以上ある時に4軸で採点すると迷いが減ります。候補が1つしか無い時の「消去法」は、後悔の典型ルートなので、最低2つは並べるのがコツです。

関連テーマとして、AI導入によるリポ設計の原則は AIが迷わないリポジトリ設計 に整理されています。

深掘り記事: 責務分離が崩壊する理由と設計原則

3. 意思決定プロセスと棚卸し

判断軸があっても、意思決定プロセスが無いと属人化します。最低限仕組み化すべき3点:

ADR を書く

Architecture Decision Record（ADR）を PR に添付。1ページで「背景 / 決定 / 代替案 / トレードオフ」を記録。後から「なぜこれを選んだか」を遡れる状態にします。

# ADR-0042: Vite 8 へ移行する

## Status
Accepted — 2026-04-10

## Context
Webpack のビルドが120秒を超え、DX が悪化。

## Decision
Vite 8 + Rolldown へ段階移行。

## Consequences
- Pros: ビルド 30秒台
- Cons: 一部プラグイン非互換
- 撤退条件: 6ヶ月後に CI 失敗率が 5% 超なら戻す

試す前に可逆性を定義

「6ヶ月後に効果が出なかったら戻す」という条件を、導入時に明文化。戻す工数も見積もっておきます。撤退条件が無い導入は、惰性で残り続けます。

四半期の技術棚卸し

導入済み技術を3ヶ月ごとに棚卸し。使い続ける / 撤退 / 様子見 の3択で全員合意。この場で速度と品質のトレードオフ判断も行います。棚卸しは 30分で終わるフォーマット に絞るのがコツ。長くすると誰も来なくなります。ADR のリストを画面共有しながら、各項目に 使い続ける / 撤退 / 様子見 の1語をつけて終了。

失敗した時のリカバリ

意思決定は外れる前提です。外れた時に素早く戻すための撤退条件を ADR に明記します。「6ヶ月試して効果が出なければ撤退」「月次障害が5件以上なら撤退」など、数値で決めます。定性的な条件は、結局誰も引き金を引かないので無意味です。

AIツールに関しては特に、30日間の試用期間 を最初から宣言しておくのが効きます。「このツールは30日後に再評価して、継続判断する」と決めておけば、気まずさなく撤退できます。

深掘り記事: 速度と品質どちらを取るべきか 開発のトレードオフ設計

意思決定権の所在

もう1つ見落としやすいのが「誰が最終決定するか」の明示です。チームで議論してもコンセンサスが取れない時に引き取る人が曖昧だと、議論が永遠に続きます。Tech Lead か EM か、あるいは持ち回りか。1人を指名して記録に残すのが運用として安定します。責任と権限をセットで渡すと、議論のスピードも上がります。

組織が大きくなると、Technology Radar のような全社的な技術棚卸しの仕組みも有効です。採用/試用/評価/非推奨の4段階で技術を分類し、四半期ごとに更新する文化を作ると、プロジェクトを跨いだ一貫性が担保されます。

4. まとめ

技術選定の後悔を減らすには、「軸で評価する」「可逆性を設計する」「プロセスで属人化を避ける」の3点です。AIツールが増えた今こそ、個人の勘に頼らずチームで記録に残すプロセスが効きます。特にAI関連ツールは進化が速いので、撤退条件を数値で持つ ことの重要性が増しています。

• 次に読む: とりあえず microservices が失敗する理由
• 次に読む: 責務分離が崩壊する理由と設計原則
• 次に読む: 速度と品質どちらを取るべきか 開発のトレードオフ設計
• 次に読む: tRPC を採用すべきか 型安全API設計の現実解
• 運用フレーム: Technology Radar の作り方｜30分会議テンプレ付（本記事の判定軸を月次会議で運用に乗せる手順）