技術選定でよくある失敗
はじめに
技術選定は「正解」を選ぶことよりも、「大きな失敗を避ける」ことの方が重要です。多くのプロジェクトが技術選定の失敗によって、スケジュールの遅延、コストの超過、最悪の場合はプロジェクトの中止に追い込まれています。
本記事では、技術選定でよくある10の失敗パターンを、具体例と対策を交えて解説します。これらの失敗パターンを知っておくことで、同じ轍を踏むリスクを大幅に減らすことができます。
失敗パターン一覧
+-------------------------------------------------------+
| 技術選定の10大失敗パターン |
+-------------------------------------------------------+
| |
| 1. 流行に飛びつく（Hype Driven Development） |
| 2. 得意技で全部やろうとする（ゴールデンハンマー症候群） |
| 3. 要件を無視して技術ありきで進める |
| 4. スケールを考えずにMVPを作る |
| 5. 採用市場を考慮しない |
| 6. PoCをスキップする |
| 7. 既存チームのスキルセットを無視する |
| 8. ベンダーロックインを軽視する |
| 9. 技術的負債を先送りにする |
| 10. 全部自作する（NIH症候群） |
| |
+-------------------------------------------------------+
失敗パターン1: 「流行っているから」で選ぶ（Hype Driven Development）
概要
SNSやカンファレンスで話題になっている技術を、自社の要件に合っているかどうかを検討せずに採用してしまうパターンです。
具体例
あるスタートアップが、社内のシンプルな管理画面（CRUD操作が中心）を作る際に、「マイクロサービスアーキテクチャ」と「Kubernetes」を採用。結果、3人のチームでインフラの運用に大半の時間を取られ、肝心の機能開発が遅延した。モノリスなRailsアプリで十分だった。
なぜ起きるのか
話題の技術が登場
|
v
カンファレンスで事例発表
|
v
「大企業が使っている」「Xで盛り上がっている」
|
v
「うちも使わないと遅れる」という焦り
|
v
要件を無視して採用
|
v
オーバーエンジニアリング
|
v
開発遅延・コスト超過
対策
- Hype Cycleを理解する: Gartner社のHype Cycleを参考に、技術の成熟度を判断する
- 「なぜその技術が必要か」を言語化する: 具体的な課題と結びつけて説明できなければ、採用すべきではない
- 先行事例を調べる際は「規模感」を確認する: GAFAMの事例をスタートアップに適用できるとは限らない
Gartner Hype Cycle（概念図）
期待度
^
| *
| / \ ← 過度な期待のピーク
| / \
| / \
| / \
| / \ * * * ← 安定期
| / \ *
| / \ * ← 幻滅の谷
|* *
+-----------------------------------------> 時間
技術の 過度な 幻滅の 啓蒙の 安定期
黎明期 期待 谷 斜面
失敗パターン2: 「得意だから」で選ぶ（ゴールデンハンマー症候群）
概要
「ハンマーを持つ人にはすべてが釘に見える」という格言の通り、自分が得意な技術で全てを解決しようとするパターンです。
具体例
Javaが得意なテックリードが、リアルタイムチャットアプリケーションの開発にJava + Spring Bootを選定。WebSocketの処理やリアルタイム性の要件に対して、Node.jsやElixir（Phoenix）の方が適していたにもかかわらず、「Javaでもできる」という理由で押し通した。結果、パフォーマンスチューニングに膨大な時間を費やした。
判断基準
| 状況 | 得意技術を使うべきか |
|---|---|
| 要件と技術が合致 | 積極的に使うべき |
| やや合わないがカバー可能 | 条件付きで使える |
| 根本的に合わない | 別の技術を検討すべき |
| 得意技術にバイアスがある | 第三者のレビューを入れる |
対策
- 最低2つの候補を比較する: 得意な技術以外の選択肢を必ず検討する
- 「なぜこの技術でないとダメなのか」を問う: 消去法で技術を選ぶ
- チーム外の意見を取り入れる: 社外のエンジニアやコンサルタントに相談する
失敗パターン3: 要件を無視して技術ありきで進める
概要
「この技術を使いたい」が先にあり、後から要件を当てはめてしまうパターンです。
具体例
「GraphQLを使いたい」というエンジニアの希望から、社内の単純なCRUD APIにGraphQLを導入。クライアントは1種類のWebアプリだけで、複雑なクエリの必要性はゼロ。REST APIで十分だったが、GraphQLのスキーマ定義やリゾルバの実装に余計な工数がかかった。
技術と要件の正しい関係
正しい順序:
要件 → 技術選定 → 実装
誤った順序:
技術 → 要件に合わせる → 無理が生じる
具体的に:
◯ 「複数のクライアントから異なるデータ構造が必要」→ GraphQLを検討
× 「GraphQLを使いたい」→ 要件を後付け
対策
- 要件定義を先に完了させる: 技術の話は要件が固まってから
- 「Why（なぜ）」を3回繰り返す: 技術採用の理由を深掘りする
- 要件に対する技術のFit/Gap分析を行う: 合致する点（Fit）と不足する点（Gap）を明確にする
失敗パターン4: スケールを考えずにMVPを作る
概要
MVP（Minimum Viable Product）段階で「とりあえず動くもの」を作ることに注力し、スケーラビリティを全く考慮しないパターンです。
具体例
スタートアップがSQLiteをデータベースとして採用してMVPをリリース。順調にユーザーが増加したが、同時アクセスが増えるとSQLiteのファイルロックで書き込みが詰まり、サービスが使い物にならなくなった。PostgreSQLへの移行に3ヶ月を要した。
スケールを考慮した技術選定のバランス
オーバーエンジニアリング 適切な設計 アンダーエンジニアリング
<---------------------------------------------------------->
Kubernetes + マイクロサービス モノリス + SQLite +
+ 分散DB + メッセージキュー PostgreSQL + 単一サーバー
キャッシュ層
100万ユーザー対応可能だが 10万ユーザーまで 1000ユーザーで
月100万円のインフラ費用 対応可能。 限界。
3人チームでは運用不能 適切なコスト 移行に3ヶ月
対策
- 「10倍ルール」で考える: 現在の10倍のトラフィックに耐えられる設計にする
- 拡張ポイントを意識する: DBの選定は最初から慎重に。後からの移行コストが高い
- 段階的なスケーリング計画を作る: Phase 1（1万ユーザー）、Phase 2（10万ユーザー）のように段階を設定
失敗パターン5: 採用市場を考慮しない
概要
技術的に優れていても、その技術を扱えるエンジニアが市場にいなければ、チームを拡大できません。
具体例
Elixir + Phoenixで素晴らしいリアルタイムWebアプリを構築。しかしサービスが成長し、エンジニアを増員しようとした際に、Elixirエンジニアの候補者がほとんど見つからず、採用に半年以上かかった。その間、既存メンバーに負荷が集中し、離職者が出た。
技術の市場規模と採用リスク
| 市場規模 | 特徴 | 採用戦略 |
|---|---|---|
| 大きい（JS、Python、Java） | 候補者が多い。競争も激しい | 待遇や環境で差別化 |
| 中程度（Go、Ruby、Kotlin） | 候補者はいるが限定的 | 技術コミュニティで採用 |
| 小さい（Rust、Elixir、Haskell） | 候補者が非常に少ない | 社内育成 or 高待遇 |
| 極小（Nim、Zig等） | 候補者を見つけるのが困難 | 社内育成のみ |
対策
- 求人市場を事前に調査する: 転職サイトで該当技術の求人数・候補者数を確認する
- 「育成にかかる期間」を算出する: 未経験者を採用して育成する場合のコストと期間
- コア技術とサブ技術を分ける: コア技術は採用しやすいもの、サブ技術は少し挑戦的でもOK
失敗パターン6: PoCをスキップする
概要
「調査だけで十分」「公式ドキュメントに書いてあるから大丈夫」と、実際に手を動かして検証するProof of Concept（概念実証）をスキップするパターンです。
具体例
公式ドキュメントとベンチマーク記事だけを見て、新しいORMライブラリを採用。実際にプロジェクトで使い始めると、複雑なJOINクエリのパフォーマンスが悪く、N+1問題の検出機能もなかった。ドキュメントには「高速」と書かれていたが、実際のユースケースとは異なる条件でのベンチマークだった。
PoCで検証すべきこと
+-----------------------------------------------------------+
| PoCチェックリスト |
+-----------------------------------------------------------+
| |
| 機能面 |
| [ ] 主要なユースケースを実装できるか |
| [ ] エッジケースの処理は可能か |
| [ ] 既存システムとの連携は問題ないか |
| |
| パフォーマンス面 |
| [ ] 実際の負荷に近い条件でベンチマークしたか |
| [ ] メモリ使用量は許容範囲か |
| [ ] コールドスタートの影響はあるか |
| |
| 開発体験 |
| [ ] エラーメッセージは分かりやすいか |
| [ ] デバッグしやすいか |
| [ ] IDEのサポートは十分か |
| |
| 運用面 |
| [ ] ログは十分に出力されるか |
| [ ] 監視ツールとの連携は可能か |
| [ ] デプロイ方法は確立されているか |
| |
+-----------------------------------------------------------+
対策
- PoCの期間を必ずスケジュールに組み込む: 1〜2週間のPoC期間を計画する
- PoCの成功基準を事前に定義する: 何が確認できれば「合格」なのかを明確にする
- PoCは「本番に近い条件」で実施する: トイプロジェクトではなく、実際のユースケースで検証する
失敗パターン7: 既存チームのスキルセットを無視する
概要
技術的に最適な選択肢であっても、チームがその技術を使いこなせなければ意味がありません。
具体例
Python中心のデータサイエンスチームが、高パフォーマンスなAPIサーバーを構築するためにRustを採用。Rustの学習曲線の急峻さにチームが苦戦し、当初3ヶ月の見積もりが9ヶ月に延長。結果的にGoを選んでいれば、チームの既存スキル（Python）からの移行が比較的容易で、半分の期間で完成できた可能性が高い。
チームスキルと技術選定のマトリクス
| チームのスキル | 技術との距離 | 学習期間（目安） | リスク |
|---|---|---|---|
| 同じ言語/FW | なし | 0 | 低 |
| 類似の言語 | 近い | 1〜2ヶ月 | 低〜中 |
| 異なるパラダイム | やや遠い | 3〜6ヶ月 | 中〜高 |
| 全く未知の領域 | 遠い | 6ヶ月以上 | 高 |
対策
- チームのスキルマップを作成する: 誰がどの技術を使えるかを可視化する
- 学習期間を見積もりに含める: 新技術の学習コストをプロジェクト計画に組み込む
- 段階的に導入する: いきなり全面採用ではなく、小さなプロジェクトから始める
失敗パターン8: ベンダーロックインを軽視する
概要
特定のベンダーやプラットフォームに強く依存する技術を選んでしまい、後から移行が困難になるパターンです。
具体例
Firebase（Google）のRealtime Databaseを全面的に採用してアプリを構築。サービスが成長し、複雑なクエリやトランザクションが必要になったが、FirebaseのNoSQLでは対応が難しく、RDBへの移行を決断。しかしデータモデルが根本的に異なるため、移行に半年以上かかった。
ロックインのレベル
ロックインの深さ
浅い <----------------------------------------------> 深い
言語レベル FWレベル DBレベル クラウドレベル
(移行容易) (中程度) (移行困難) (移行非常に困難)
例: 例: 例: 例:
JS→TS Express→Hono MySQL→Postgres AWS Lambda→
(比較的容易) (ルーティング (SQL互換性 GCP Cloud Functions
の書き換え) はあるが (API、ランタイム、
独自機能の 権限モデルが
移行が必要) 全て異なる)
対策
- 抽象化レイヤーを設ける: データベースアクセスをリポジトリパターンで抽象化する
- クラウドネイティブサービスの利用は慎重に: マネージドサービスの便利さとロックインのリスクを天秤にかける
- マルチクラウド戦略を検討する: コストとリスクのバランスを取る
- 退出計画（Exit Plan）を作成する: 技術採用時に「もし移行するなら」の計画を立てておく
失敗パターン9: 技術的負債を先送りにする
概要
「今はとりあえず動くから」と、既知の問題を放置し続けることで、技術的負債が積み上がり、いつか爆発するパターンです。
具体例
Node.js 12で開発を開始し、EOL（End of Life）を迎えてもアップグレードを後回しに。依存ライブラリも古いバージョンのまま放置。3年後にセキュリティ脆弱性が発見された際、アップグレードに必要な変更が膨大で、対応に2ヶ月を要した。定期的にアップグレードしていれば、各回30分程度で済んだはず。
技術的負債の増加イメージ
負債の量
^
| /
| /
| / ← 放置した場合
| / （指数関数的に増加）
| /
| /
| ___/
| ___/
| ____/ ............. ← 定期的に返済した場合
| ____/ ..... （線形で管理可能）
| ____/ .....
|/ ......
+-----------------------------------------> 時間
対策
- 定期的なアップデートスケジュールを設定する: 月次でライブラリのアップデートを行う
- 技術的負債の可視化: テックデットとして管理し、返済計画を立てる
- 20%ルール: 開発リソースの20%を技術的負債の返済に充てる
- EOLカレンダーを管理する: 使用技術のサポート期限を一覧化する
失敗パターン10: 「全部自作」症候群（NIH症候群）
概要
NIH（Not Invented Here）症候群とは、外部で開発されたものを受け入れず、全てを自作しようとする傾向です。
具体例
「既存の認証ライブラリはセキュリティが信用できない」という理由で、認証システムを自前で開発。結果、OAuth 2.0の実装に3ヶ月を費やし、さらにセキュリティレビューで複数の脆弱性が発見された。Auth0やFirebase Authを使っていれば、1週間で安全な認証基盤が構築できた。
自作 vs 既存ソリューションの判断基準
| 項目 | 自作すべき | 既存ソリューションを使うべき |
|---|---|---|
| コア機能 | ビジネスの差別化要因 | 差別化に関係ない共通機能 |
| 品質要件 | 既存ソリューションが要件を満たさない | 十分な品質のものが存在する |
| セキュリティ | セキュリティチームが十分な場合のみ | 認証、暗号化等はプロに任せる |
| コスト | 長期的にOSSより安くなる場合 | 短期〜中期で見てOSSが安い場合 |
| 保守 | 自社で保守し続ける覚悟がある | 外部に保守を委ねたい |
対策
- 「Build vs Buy」の意思決定プロセスを設ける: 自作する前に必ず既存ソリューションを調査する
- コア機能と非コア機能を区別する: コアビジネスに直結しない部分は既存ソリューションを活用する
- OSSのセキュリティは「多くの目」で支えられている: 多くの場合、自作よりOSSの方が安全
チェックリスト: 技術選定前に確認すべき20項目
以下のチェックリストを技術選定の前に確認することで、上記の失敗パターンを回避できます。
要件の確認
[ ] 1. 機能要件は文書化されているか
[ ] 2. 非機能要件（パフォーマンス、可用性等）は定義されているか
[ ] 3. スケーラビリティの目標値は設定されているか
[ ] 4. セキュリティ要件は明確か
[ ] 5. 予算の上限は決まっているか
チームの確認
[ ] 6. チームのスキルマップは作成されているか
[ ] 7. 新技術の学習に充てられる期間はあるか
[ ] 8. 採用市場での技術の人気度を調査したか
[ ] 9. チームメンバーの意見を聞いたか
[ ] 10. 外部の意見（他チーム、コンサルタント等）を取り入れたか
技術の調査
[ ] 11. 最低3つの候補技術を比較したか
[ ] 12. 各候補技術のメリット・デメリットを文書化したか
[ ] 13. PoCを実施したか（または計画しているか）
[ ] 14. 既存システムとの互換性を確認したか
[ ] 15. ベンダーロックインのリスクを評価したか
長期的な視点
[ ] 16. 技術のロードマップ（今後の開発計画）を確認したか
[ ] 17. コミュニティの活発さを確認したか
[ ] 18. ライセンスの条件を確認したか
[ ] 19. 3年後、5年後の保守性を考慮したか
[ ] 20. 退出計画（Exit Plan）を策定したか
失敗パターンの関連性マップ
失敗パターンは独立しているわけではなく、一つの失敗が別の失敗を引き起こすことがあります。
流行に飛びつく (1)
|
+---> 要件を無視 (3)
| |
| +---> PoCスキップ (6)
| |
| +---> 技術的負債 (9)
|
+---> チームスキル無視 (7)
|
+---> 採用市場無視 (5)
得意技偏重 (2)
|
+---> ベンダーロックイン (8)
|
+---> 全部自作 (10)
スケール無視 (4)
|
+---> 技術的負債 (9)
まとめ
技術選定の失敗は、以下の3つの根本原因に帰結します。
- 情報不足: 要件、市場、チームの状況を十分に調査していない
- バイアス: 個人の好み、流行、過去の経験に引きずられる
- 近視眼的判断: 短期的なメリットだけを見て、長期的なリスクを見落とす
これらを避けるために:
- チェックリストを使って網羅的に確認する
- 複数の候補を比較し、定量的に評価する
- PoCを必ず実施する
- 長期的な視点で判断する
- チーム全体の意見を取り入れる
技術選定に「正解」はありませんが、「明らかな不正解」は避けることができます。
参考資料
- Martin Fowler "Technical Debt": https://martinfowler.com/bliki/TechnicalDebt.html
- Gartner Hype Cycle: https://www.gartner.com/en/research/methodologies/gartner-hype-cycle
- ThoughtWorks Technology Radar: https://www.thoughtworks.com/radar