ITエンジニアとしてこの先生きのこるために

性能

作成: 2026.03.24更新: 2026.03.24

性能とは

性能（パフォーマンス）とは、システムが「どれだけ速く」「どれだけ多くの処理を」さばけるかを表す指標である。業務システムでは、ユーザーが画面操作した際の応答速度や、バッチ処理の処理時間、同時に利用できるユーザー数など、システムの「速さ」と「処理能力」が性能として定義される。

性能は機能要件（何ができるか）とは異なる 非機能要件 の一つであり、ユーザー満足度やビジネスの継続性に直結する重要な品質特性である。

なぜ SIer で重要か

SIer が構築する業務システムでは、性能要件が契約上の達成条件として定義されることが一般的である。「オンライン処理のレスポンスタイムは 3 秒以内」「月次バッチは 2 時間以内に完了」といった明確な数値目標があり、これを満たせなければ検収が通らない。

性能問題は開発の終盤（総合テストや本番リリース直前）に発覚することが多く、その時点での対応は手戻りが大きくなりがちである。性能の基礎知識を持っていれば、設計段階から性能を意識した実装ができ、問題の早期発見にもつながる。

基本概念

性能の基本指標

性能を測定・評価するための主要な指標は以下の通りである。

指標英語説明
レスポンスタイムResponse Timeリクエスト送信からレスポンス受信までの時間
スループットThroughput単位時間あたりの処理件数
同時接続数Concurrent Connections同時に処理できるリクエスト数
TPSTransactions Per Second1 秒あたりのトランザクション処理数
ターンアラウンドタイムTurnaround Time処理の依頼から完了までの総時間（バッチ処理向け）
レスポンスタイムの内訳:

ブラウザ → ネットワーク → Web サーバー → AP サーバー → DB サーバー
                                                          │
                                                      SQL 実行
                                                          │
ブラウザ ← ネットワーク ← Web サーバー ← AP サーバー ← DB サーバー

├─────────────── レスポンスタイム ──────────────────┤

レスポンスタイムは、ネットワーク遅延・Web サーバー処理・AP サーバー処理・DB サーバー処理の合計で決まる。どこがボトルネックかを特定することが、性能改善の第一歩である。

非機能要件としての性能

SIer のプロジェクトでは、要件定義の段階で性能に関する非機能要件を定義する。

性能要件の定義例:
┌──────────┬──────────────────────────┐
│ 項目       │ 要件                       │
├──────────┼──────────────────────────┤
│ オンライン応答│ 画面操作のレスポンスタイムは 3 秒以内  │
│ バッチ処理   │ 日次バッチは 4 時間以内に完了       │
│ 同時ユーザー数│ ピーク時 500 ユーザーの同時利用に対応  │
│ スループット  │ 1 秒あたり 100 件のトランザクション処理 │
└──────────┴──────────────────────────┘

これらの要件を満たしているかどうかは、性能テストで検証する。

性能テスト

性能テストは、システムが性能要件を満たしているかを検証するテストである。通常は結合テストや総合テストの段階で実施する。

テスト種類目的内容
負荷テスト想定負荷での性能確認想定同時ユーザー数でリクエストを送り、レスポンスタイム・スループットを計測
ストレステスト限界値の確認想定以上の負荷をかけ、システムがどの時点で性能劣化・エラーを起こすかを確認
耐久テスト長時間稼働の安定性確認一定負荷を長時間（数時間〜数日）かけ続け、メモリリーク等の問題がないかを確認
スパイクテスト急激な負荷変動への耐性確認短時間に負荷を急増させ、システムの挙動を確認

主な性能テストツール

ツール名開発元特徴
Apache JMeterApache Software FoundationOSS。SIer で最も広く使われている。GUI でシナリオ作成可能
GatlingGatling CorpOSS。Scala ベースのスクリプトでシナリオ定義。レポートが見やすい
LocustOSSPython でシナリオを記述。軽量で扱いやすい

JMeter は SIer の現場で最も利用率が高い。GUI でテストシナリオ（リクエストの内容・順序・同時実行数等）を作成し、テストを実行する。結果はレスポンスタイムの平均・中央値・90 パーセンタイル等で集計される。

性能テストの実施イメージ:

[JMeter]  ──→  同時 100 ユーザーのリクエストを生成
    │
    ▼
[対象システム] ──→ レスポンスを返す
    │
    ▼
[結果集計]
  平均レスポンスタイム:  1.2 秒  ← 要件 3 秒以内 → OK
  90%タイルレスポンス:   2.8 秒  ← 要件 3 秒以内 → OK
  スループット:        85 TPS   ← 要件 100 TPS → NG（要改善）
  エラー率:           0.1%

性能チューニング

性能テストで要件を満たせなかった場合、ボトルネックを特定して改善する。主なチューニングポイントは以下の通りである。

SQL チューニング

性能問題の多くは DB 層（SQL の実行）に起因する。

  • スロークエリの特定 --- DB のスローログから実行時間が長い SQL を特定する
  • インデックスの追加 --- 検索条件に使う列にインデックスを作成し、検索を高速化する
  • SQL の書き換え --- 不要な結合（JOIN）やサブクエリを排除し、効率的な SQL に修正する
  • 実行計画の確認 --- EXPLAIN コマンドで SQL の実行計画を確認し、フルスキャンが発生していないかを確認する

AP サーバーのチューニング

  • スレッドプール --- 同時実行するスレッド数の調整。少なすぎるとリクエスト待ちが発生し、多すぎるとリソースを消費する
  • ヒープサイズ --- Java の場合、JVM のヒープメモリサイズを適切に設定する。不足すると OutOfMemoryError、過大だと GC 停止時間が長くなる
  • コネクションプール --- DB との接続数を事前に確保し、接続の確立コストを削減する

キャッシュの活用

  • アプリケーションキャッシュ --- 頻繁にアクセスされるデータをメモリ上に保持し、DB アクセスを削減する
  • HTTP キャッシュ --- 静的コンテンツのキャッシュ制御により、Web サーバーへのリクエストを削減する

SIer での使われ方

性能問題が発覚するタイミング

SIer のプロジェクトでは、性能問題は以下のタイミングで発覚することが多い。

開発工程と性能問題の発覚タイミング:

要件定義 → 基本設計 → 詳細設計 → 実装 → 結合テスト → 総合テスト → リリース
                                              │          │
                                              ▼          ▼
                                           ここで発覚すると    ここで発覚すると
                                           まだ対応しやすい    対応コスト大

理想は設計段階から性能を考慮し、結合テストの段階で性能テストを実施することである。しかし現実には、総合テストや本番リリース直前に初めて性能テストを行い、問題が発覚するケースも少なくない。

性能テストの報告

性能テストの結果は、以下のような形式で報告書にまとめるのが一般的である。

シナリオ同時ユーザー数平均レスポンス90%タイルスループット結果
ログイン処理1000.8 秒1.5 秒120 TPSOK
商品検索1001.2 秒2.8 秒85 TPSOK
注文処理502.5 秒4.2 秒20 TPSNG

NG となった項目については、ボトルネックの分析結果と改善策を合わせて報告する。

まとめ

  • 性能はレスポンスタイム・スループット・同時接続数・TPS で測定する
  • SIer のプロジェクトでは、性能要件は非機能要件として要件定義段階で数値目標を定義する
  • 性能テスト（負荷テスト・ストレステスト等）で要件の達成を検証し、JMeter が最も広く使われるツールである
  • SQL チューニング・AP サーバーチューニング・キャッシュ活用が主な改善手段である
  • 性能問題は開発終盤に発覚しがちなため、早期からの性能テスト実施が重要である