技術選定の評価基準

はじめに

技術選定で最も難しいのは、「何を基準に判断するか」を決めることです。明確な評価基準がないまま議論を始めると、個人の好みや経験に基づいた主観的な判断になりがちです。

本記事では、技術選定における評価基準を体系的に解説し、実際に使える評価マトリクステンプレートを紹介します。

機能要件 vs 非機能要件

技術選定の出発点は、要件を「機能要件」と「非機能要件」に分類することです。

機能要件（Functional Requirements）

「システムが何をするか」を定義するものです。

例: ECサイトの場合
+-------------------------------------------+
| 機能要件                                   |
+-------------------------------------------+
| - 商品の検索ができる                        |
| - カートに商品を追加できる                   |
| - クレジットカードで決済できる                |
| - 注文履歴を確認できる                      |
| - 商品レビューを投稿できる                   |
+-------------------------------------------+

非機能要件（Non-Functional Requirements）

「システムがどのように動くか」を定義するものです。技術選定では、非機能要件がより大きな影響を持ちます。

例: ECサイトの場合
+-------------------------------------------+
| 非機能要件                                 |
+-------------------------------------------+
| - ページ表示が2秒以内                       |
| - 同時10,000人のアクセスに耐えられる         |
| - 99.9%の可用性                            |
| - 個人情報を暗号化して保存                   |
| - 24時間365日稼働                          |
| - 障害発生時に30分以内に復旧                 |
+-------------------------------------------+

なぜ非機能要件が技術選定に大きく影響するのか

機能要件は、ほとんどの技術で実現できます。ECサイトはJavaでもPythonでもGoでも作れます。しかし非機能要件は、選んだ技術によって達成の難易度が大きく変わります。

非機能要件	技術選定への影響例
高スループット	Node.jsの非同期I/O vs Rubyの同期処理
低レイテンシ	Rustのゼロコスト抽象化 vs Pythonのインタプリタ
高可用性	Erlang/OTPの耐障害性 vs 一般的なWebフレームワーク
リアルタイム性	Go/Elixirの並行処理 vs PHPのリクエスト/レスポンスモデル

パフォーマンス

パフォーマンスは複数の指標で測定します。

主要なパフォーマンス指標

+-------------------------------------------------------------------+
|                      パフォーマンス指標                               |
+-------------------------------------------------------------------+
|                                                                   |
|  レイテンシ (Latency)                                              |
|  → リクエストを送ってからレスポンスを受け取るまでの時間                  |
|  → 単位: ミリ秒 (ms)                                               |
|  → 例: API応答時間 50ms以下                                        |
|                                                                   |
|  スループット (Throughput)                                          |
|  → 単位時間あたりに処理できるリクエスト数                              |
|  → 単位: requests/second (rps)                                    |
|  → 例: 10,000 rps                                                 |
|                                                                   |
|  同時接続数 (Concurrency)                                          |
|  → 同時に処理できる接続の数                                         |
|  → 例: WebSocket 100,000同時接続                                   |
|                                                                   |
|  レスポンスタイム分布                                               |
|  → P50, P95, P99で測定                                            |
|  → 平均値だけでは不十分（外れ値の影響）                               |
|                                                                   |
+-------------------------------------------------------------------+

パーセンタイルの重要性

パフォーマンスを「平均値」だけで判断するのは危険です。

例: API応答時間

平均値: 100ms（一見問題なさそう）

しかし実際の分布:
  P50 (50%):   50ms  ← 半数のリクエストは50ms以下
  P95 (95%):  200ms  ← 95%のリクエストは200ms以下
  P99 (99%): 2000ms  ← 1%のリクエストが2秒かかっている！

1日100万リクエストの場合:
  → 10,000リクエストが2秒以上かかる
  → これは無視できない数字

言語別パフォーマンス比較（Web API処理の目安）

言語/ランタイム	レイテンシ（P99）	スループット（rps）	メモリ使用量
C/C++	極めて低い	極めて高い	極めて少ない
Rust	極めて低い	極めて高い	極めて少ない
Go	低い	高い	少ない
Java (JVM)	低い（ウォームアップ後）	高い	多い
C# (.NET)	低い	高い	やや多い
Node.js	中程度	中〜高い	中程度
Python	やや高い	中程度	中程度
Ruby	やや高い	低〜中程度	やや多い
PHP	中程度	中程度	少ない（リクエスト単位）

注意: これは一般的な傾向であり、フレームワークや実装方法によって大きく変動します。

スケーラビリティ

垂直スケーリング vs 水平スケーリング

垂直スケーリング（スケールアップ）
  サーバーのスペックを上げる

  Before:          After:
  +--------+       +--------+
  | 4 CPU  |       | 16 CPU |
  | 8GB RAM|  -->  | 64GB   |
  | 100GB  |       | 1TB    |
  +--------+       +--------+

  メリット: シンプル、アプリ変更不要
  デメリット: 物理的な上限がある、コスト効率が悪い


水平スケーリング（スケールアウト）
  サーバーの台数を増やす

  Before:          After:
  +--------+       +--------+ +--------+ +--------+
  | Server |       | Server | | Server | | Server |
  +--------+       +--------+ +--------+ +--------+
                         \       |       /
                        +-----------------+
                        | Load Balancer   |
                        +-----------------+

  メリット: 理論上無限に拡張可能、コスト効率が良い
  デメリット: アプリの設計が複雑になる、状態管理が難しい

技術選定とスケーラビリティの関係

技術特性	垂直スケーリング向き	水平スケーリング向き
ステートフル（状態を持つ）	向いている	セッション管理が課題
ステートレス（状態を持たない）	問題なし	非常に向いている
マルチスレッド	CPUコア増加で性能向上	問題なし
シングルスレッド	CPU増加の恩恵が小さい	プロセス分散で対応
共有メモリ	向いている	分散キャッシュが必要

開発生産性

開発生産性は技術選定で最も議論が分かれるポイントの一つです。

学習曲線

                    習熟度
                    ^
                    |
                    |                              ......... Python
                    |                       .......
                    |                 ....../
                    |           ...../
                    |       .../        _ _ _ _ _ TypeScript
                    |     ./      _ _ _/
                    |   ./   _ _/
                    |  /  __/    .  .  .  .  .  . Rust
                    | / _/   . .
                    |/_/ . .
                    |. .
                    +---------------------------------> 学習時間

開発生産性を構成する要素

要素	説明	測定方法の例
学習曲線	新しいメンバーが生産的になるまでの時間	オンボーディング期間
ボイラープレート	繰り返し書く必要のあるコード量	同じ機能を実装するのに必要な行数
デバッグ容易性	バグの原因特定にかかる時間	エラーメッセージの質、デバッグツール
ツールチェーン	ビルド、テスト、デプロイの自動化しやすさ	CI/CDパイプライン構築時間
IDE対応	コード補完、リファクタリング支援	主要IDEのプラグイン数
ドキュメント	公式ドキュメントの質と量	主観的評価 + ページ数

採用市場

技術選定がビジネスに直接影響する領域の一つが「採用市場」です。

プログラミング言語の採用市場（2025-2026年の傾向）

言語	求人数（相対値）	平均年収（目安）	候補者数	採用難易度
JavaScript/TypeScript	非常に多い	中〜高	非常に多い	低
Python	非常に多い	中〜高	多い	低
Java	多い	中〜高	多い	低
Go	中程度	高い	やや少ない	中
Rust	少ない	高い	少ない	高
Ruby	中程度	中〜高	中程度	中
PHP	多い	中程度	多い	低
Kotlin	中程度	高い	やや少ない	中
Swift	中程度	高い	やや少ない	中

採用市場を考慮した技術選定の考え方

                      採用コスト
                      ^
                      |
                      |  *Rust
                      |
                      |     *Go    *Kotlin
                      |
                      |        *Ruby
                      |
                      |  *Java      *TypeScript
                      |        *Python
                      |  *PHP
                      +-------------------------> 候補者プール
                      少ない               多い

コミュニティとエコシステム

パッケージマネージャー別パッケージ数（2025-2026年時点の概算）

パッケージマネージャー	言語	パッケージ数（概算）
npm	JavaScript/TypeScript	200万+
PyPI	Python	50万+
Maven Central	Java	60万+
NuGet	C#	40万+
crates.io	Rust	15万+
RubyGems	Ruby	17万+
Packagist	PHP	35万+
pkg.go.dev	Go	100万+ モジュール
pub.dev	Dart	5万+

エコシステムの健全性を評価する指標

パッケージ数だけではなく、以下の指標も重要です。

指標	説明	確認方法
メンテナンス頻度	パッケージが定期的に更新されているか	最終リリース日
セキュリティ対応	脆弱性が報告されたときの対応速度	CVEデータベース
ドキュメント品質	使い方が分かりやすく文書化されているか	READMEとAPI doc
テストカバレッジ	パッケージ自体のテストが充実しているか	CI結果
ライセンス	商用利用が可能か	ライセンスファイル
ダウンロード数	実際にどれくらい使われているか	パッケージマネージャーの統計
依存関係の深さ	間接依存がどれくらいあるか	依存解析ツール

セキュリティ

セキュリティ観点での技術評価

評価項目	説明	重要度
メモリ安全性	バッファオーバーフロー等の脆弱性	高
型安全性	型に起因するバグの防止	中
脆弱性対応速度	CVE公開から修正までの時間	高
セキュリティ機能	暗号化、認証、サンドボックス	高
依存関係の監査	サプライチェーン攻撃への耐性	高
セキュリティツール	SAST、DAST、SCA対応	中

言語別メモリ安全性

メモリ安全性のスペクトル

安全 <-------------------------------------------------> 危険

  Rust     Go      Java     JavaScript    C++       C
  (所有権   (GC +    (GC)     (GC)         (手動     (手動
   システム) ポインタ                       管理 +    管理)
            制限)                          スマート
                                          ポインタ)

コスト

TCO（Total Cost of Ownership / 総所有コスト）

技術選定のコストは初期費用だけでなく、運用期間全体を通じた総コストで評価します。

+-----------------------------------------------------------+
|                   TCO（総所有コスト）の構成                    |
+-----------------------------------------------------------+
|                                                           |
|  初期コスト (Year 0)                                       |
|  +-----------------------------------------------------+ |
|  | ライセンス購入費                                      | |
|  | 環境構築費                                            | |
|  | トレーニング費                                        | |
|  | 移行費（既存システムからの移行がある場合）               | |
|  +-----------------------------------------------------+ |
|                                                           |
|  年間運用コスト (Year 1-N)                                 |
|  +-----------------------------------------------------+ |
|  | インフラ費用（クラウド、サーバー）                      | |
|  | ライセンス更新費                                      | |
|  | 保守・監視費用                                        | |
|  | セキュリティ対応費                                    | |
|  | バージョンアップ対応費                                | |
|  +-----------------------------------------------------+ |
|                                                           |
|  人件費                                                    |
|  +-----------------------------------------------------+ |
|  | 開発者の給与                                          | |
|  | 採用コスト                                            | |
|  | トレーニングコスト（新メンバー）                        | |
|  +-----------------------------------------------------+ |
|                                                           |
+-----------------------------------------------------------+

OSSとプロプライエタリの比較

項目	OSS	プロプライエタリ
ライセンス費	無料（多くの場合）	有料
サポート	コミュニティ依存	公式サポート
カスタマイズ	自由	制限あり
ベンダーロックイン	低い	高い
セキュリティ	コミュニティ監査	ベンダー責任
隠れコスト	自前サポート、運用	追加ライセンス

評価マトリクステンプレート

実際のプロジェクトで使える評価マトリクスのテンプレートを紹介します。

手順

評価観点の選定: プロジェクトに関係する評価観点を選ぶ
重み付け: 各観点の重要度を1〜5で設定する
候補技術のスコアリング: 各候補技術を1〜5で評価する
加重スコアの計算: 重み x スコアを計算する
定性的評価の追加: スコアだけでは表現できない要素を補足する

テンプレート例

プロジェクト名: [                    ]
評価日: [YYYY-MM-DD]
評価者: [                    ]

+-------------------+------+----------+----------+----------+
| 評価観点           | 重み  | 候補A     | 候補B     | 候補C     |
|                   |      | スコア(加重)| スコア(加重)| スコア(加重)|
+-------------------+------+----------+----------+----------+
| 機能適合性         | [ ]  | [ ]( )   | [ ]( )   | [ ]( )   |
| パフォーマンス     | [ ]  | [ ]( )   | [ ]( )   | [ ]( )   |
| スケーラビリティ   | [ ]  | [ ]( )   | [ ]( )   | [ ]( )   |
| 開発生産性         | [ ]  | [ ]( )   | [ ]( )   | [ ]( )   |
| 学習コスト         | [ ]  | [ ]( )   | [ ]( )   | [ ]( )   |
| エコシステム       | [ ]  | [ ]( )   | [ ]( )   | [ ]( )   |
| コミュニティ       | [ ]  | [ ]( )   | [ ]( )   | [ ]( )   |
| 採用市場           | [ ]  | [ ]( )   | [ ]( )   | [ ]( )   |
| セキュリティ       | [ ]  | [ ]( )   | [ ]( )   | [ ]( )   |
| コスト             | [ ]  | [ ]( )   | [ ]( )   | [ ]( )   |
+-------------------+------+----------+----------+----------+
| 合計               |      |          |          |          |
+-------------------+------+----------+----------+----------+

定性的評価:
候補A: [                                                    ]
候補B: [                                                    ]
候補C: [                                                    ]

最終判断: [                                                  ]
判断理由: [                                                  ]

技術レーダーの読み方

ThoughtWorks Technology Radar とは

ThoughtWorks社が半年ごとに発行する、技術トレンドのレポートです。技術を4つのカテゴリと4つのリングで分類しています。

4つのカテゴリ（Quadrants）

カテゴリ	説明	例
Techniques	開発手法やプロセス	マイクロサービス、TDD
Platforms	インフラやプラットフォーム	Kubernetes、Cloudflare Workers
Tools	開発ツール	GitHub Copilot、Terraform
Languages & Frameworks	言語やフレームワーク	Rust、Next.js

4つのリング（Rings）

+--------------------------------------------------+
|                                                  |
|   +------------------------------------------+   |
|   |                                          |   |
|   |   +----------------------------------+   |   |
|   |   |                                  |   |   |
|   |   |   +--------------------------+   |   |   |
|   |   |   |                          |   |   |   |
|   |   |   |       ADOPT（採用）       |   |   |   |
|   |   |   |    業界で実績あり。        |   |   |   |
|   |   |   |    積極的に採用すべき      |   |   |   |
|   |   |   |                          |   |   |   |
|   |   |   +--------------------------+   |   |   |
|   |   |          TRIAL（試行）            |   |   |
|   |   |       リスクを管理して試すべき     |   |   |
|   |   +----------------------------------+   |   |
|   |            ASSESS（評価）                 |   |
|   |          調査・検討する価値がある          |   |
|   +------------------------------------------+   |
|                  HOLD（保留）                      |
|               慎重に扱うべき。新規採用は非推奨      |
+--------------------------------------------------+

リング	意味	技術選定での扱い
Adopt	業界で実績があり、推奨	本番環境での採用を積極的に検討
Trial	十分に成熟しており、試す価値がある	PoCでの検証を推奨
Assess	将来性がある。調査する価値がある	情報収集を開始。PoCはまだ早い
Hold	注意が必要。新規採用は推奨しない	既存プロジェクトの移行を検討

技術レーダーの活用方法

自社の技術レーダーを作る: ThoughtWorksの形式を参考に、自社の技術レーダーを定期的に更新する
新技術の評価基準にする: 「Adopt」の技術は安心して採用、「Hold」の技術は新規採用を避ける
チーム内の共通言語にする: 「この技術はTrialフェーズなので、PoCから始めよう」という会話ができるようになる

まとめ

技術選定の評価基準は多岐にわたりますが、以下のポイントを押さえておけば、大きく外すことはありません。

機能要件と非機能要件を分けて整理する -- 特に非機能要件が技術選定に大きく影響する
パフォーマンスは平均値ではなくパーセンタイルで測定する -- P99を見落とさない
スケーラビリティは水平・垂直の両面で評価する -- 将来の成長を見据える
採用市場は軽視しない -- 素晴らしい技術でも人が採れなければ意味がない
コストはTCOで計算する -- ライセンス費だけでなく、人件費や運用費も含める
評価マトリクスを使って定量的に比較する -- 感覚ではなくデータで判断する
技術レーダーを参考にする -- ただし、自社の文脈に合わせて判断する

参考資料

ThoughtWorks Technology Radar: https://www.thoughtworks.com/radar
TechEmpower Web Framework Benchmarks: https://www.techempower.com/benchmarks/
Stack Overflow Developer Survey: https://survey.stackoverflow.co/
GitHub Octoverse: https://octoverse.github.com/