LASSIC Media らしくメディア
性能改善とは｜IPAの定義は応答時間から資源使用量まで
監修・編集責任者：牛尾 昭昌（株式会社LASSIC 執行役員）
この記事の結論
- 性能・効率性は4つを指す：IPAの定義は応答時間・処理時間・処理能力・資源の使用量です。*1
- 性能の不具合は入れ子の一番内側：発生不具合総数の内数として、流用部性能問題が定義されています。*1
- 数えるのは1か月・3か月・6か月の累計：現象数と原因数に分け、稼動からの累計で記録します。*1
※ 本記事は2026年9月時点の公式情報（省庁・公的機関・ベンダー公式ドキュメント）に基づきます。
「画面が遅い」という報告が続いているが、どこが遅いのかまでは誰も言えない。あるいは、外部の要員に来てもらったのに、最初の2週間が現状の測定で終わった——。性能改善を外に出そうとすると、多くの現場が「何を渡せばいいのか」に突き当たります。手がかりになるのが、IPA（独立行政法人情報処理推進機構）が公開している「ソフトウェア開発分析データ集」です。開発案件の実績を集めるために、性能に関する項目をどう定義し、どう数えるかが決められています。*1
この定義をそのまま使えば、依頼に書く条件と、あとで効果を見る物差しが同時に決まります。ただし万能ではなく、どの値なら速いのかという基準は書かれていませんし、改善のやり方も載っていません。本記事では、開発の現場を預かるマネージャに向けて、性能改善が何を指すのか、ほかの不具合との違い、なぜ「遅い」だけでは外に出せないのか、どう数えるのか、つまずきやすい点、そして外注の勘所を整理します。
目次
性能改善とは——IPAが定める要求レベルの中身
IPAの「ソフトウェア開発分析データ集2022」は、企業から提供された開発案件の実績を集計した資料です。発行は社会基盤センターで、案件ごとに集める項目が1つずつ定義されています。*1 その1つが「要求レベル(性能・効率性)」です。
定義はこう書かれています。「システムを実行する際の応答時間・処理時間・処理能力、及びディスク・メモリのハードウェア・その他の資源の使用量などに関する、要求の厳しさ」。*1 挙がっているのは応答時間、処理時間、処理能力、資源の使用量の4つです。ただし「など」と書かれているので、この4つで尽きるとは資料も言っていません。
資料はこの4つを並べているだけで、それぞれの測り方までは書いていません。それでも、報告が「遅い」の一言で上がってきたとき、4つのどれの話なのかを聞き返す手がかりにはなります。画面が返るまでの時間なのか、夜間バッチが終わるまでの時間なのか、同時に捌ける件数なのか、メモリが足りていないのか。
要求レベルの選択肢は、a：極めて高い、b：高い、c：中位、d：低い、e：不明の5つです。*1 性能・効率性は、信頼性・使用性・保守性・移植性・ランニングコスト要求・セキュリティと並ぶ7項目のうちの1つとして記録されます。*1 性能改善を頼むときに渡す条件は、この7項目のどれなのかから始まります。
性能の不具合と、ほかの不具合の違い
性能改善の効果を見るには、稼動後の不具合の数え方のほうを見ます。資料は、システム稼動後に報告された不具合を4段の入れ子で記録します。*1
| 記録する項目 | IPAの定義 | 数え方 |
|---|---|---|
| 発生不具合総数 | システム稼動後（サービスイン後）に報告された不具合の総数。発生不具合とは、サービスイン後に判明したソフトウェアの不具合を指す | 現象数と原因数に分け、1か月・3か月・6か月の累計 |
| 発生不具合数（重大性別内訳） | 重大は顧客へ損害を与え緊急対応を要するもの、中度は顧客への損害はないが緊急対応を要するもの、軽微は顧客への損害はなく緊急対応も不要なもの | 発生不具合総数の内数 |
| 発生不具合数（流用部） | パッケージソフト利用開発またはOSSを含む流用開発で、稼動後に報告された母体の不具合の数 | 全体数の内数 |
| 発生不具合数（流用部性能問題） | 同じ流用開発で、稼動後に報告された母体の性能に関する不具合の総数 | 全体数の内数 |
一番外側が発生不具合総数で、その内数として重大性別の内訳、流用部、流用部性能問題が並びます。*1 性能の不具合は一番内側にあり、「母体の性能に関する不具合の総数」と定義されています。*1 資料は、性能の問題をほかの不具合と分けて数えることを前提にしています。
重大性の定義も書かれています。重大は顧客へ損害を与え緊急対応を要するもの、中度は顧客への損害はないが緊急対応を要するもの、軽微は顧客への損害はなく緊急対応も不要なものです。*1 「遅い」が重大なのか軽微なのかは、この定義に当てはめれば決まります。
なぜ「遅い」だけでは外に出せないのか
外部の要員に「性能を改善してほしい」とだけ伝えると、最初にやることは現状の測定になります。どの処理が、どの条件で、どれだけかかっているのか。それを社内の誰も答えられなければ、測るところから始めるしかありません。
測定そのものは要る作業です。ただし、4つのどれを直したいのかが決まっていれば、測る対象が絞れます。応答時間だと決まっていれば画面と処理の対応を追えばよく、資源の使用量だと決まっていればメモリとディスクの推移を見ればよい、という具合です。
ここは資料が述べていることではなく、資料が性能を4つに分けて定義している理由として読める説明です。IPAは案件の実績を集めるために分けていますが、同じ分け方は依頼を書くときにも使えます。
どう数えるのか
数え方も定義されています。発生不具合数は現象数と原因数に分け、それぞれ稼動から1か月、3か月、6か月の累計で記録します。*1
累計なので、値は後の時点ほど小さくなりません。資料は「1ヶ月経過時点の合計値＜＝3ヶ月経過時点の累計値＜＝6ヶ月経過時点の累計値でなければならない」と明記しています。*1 稼動から5か月しか経っていない案件では、1か月と3か月の値だけを書きます。*1
なぜ現象数と原因数を分けるのかは資料に書かれていませんが、1つの原因が複数の現象として報告されることはあります。性能改善の効果を見るなら、数えるのは原因数のほうです。現象数だけを追うと、同じ原因の報告が何度も立って、直ったかどうかが分かりません。
つまずきやすい難所
一つめは、この資料に「速い」「遅い」の基準を求めることです。要求レベルはaからeの5段階で、どの値なら極めて高いのかという閾値は書かれていません。*1
二つめは、流用部性能問題を自社の全案件に当てはめることです。この項目はパッケージソフト利用開発とOSSを含む流用開発が対象で、新規開発だけの案件は含まれません。*1
三つめは、稼動前の性能テストの結果をここに混ぜることです。発生不具合はサービスイン後に判明したものを指す、と補足されています。*1
外注時に確認しておきたい点
依頼を書くときは、4つのうちどれなのかと、対象の処理と、期間を並べます。「夜間バッチの処理時間を来月末まで」といった粒度で構いません。外部の要員（フリーランスを含む業務委託）は、対象と期間が決まっているほど合わせやすい調達の仕方になります。
測定から任せるのか、原因の特定と修正だけを任せるのかも分けます。前者なら計測の組み立てから経験が要りますし、後者なら社内が測った結果を渡せる状態にしておく必要があります。この区別を曖昧にしたまま声をかけると、着任してから作業を詰め直すことになり、社内の確認工数がかえって増えます。
一方、どこまで速くなれば終わりかの判断は社内に残してください。ここを外に出すと、受け取った結果を評価する基準が社内からなくなります。効果は1か月・3か月・6か月の累計で見る、と先に決めておけば、引き渡しのあとも同じ物差しで追えます。
テストの人手が足りないときの切り分けは外部エンジニアのテスト体制、IPAが定める4つの区分にあります。同じ資料の別の項目です。
品質そのものが崩れたときはシステム開発の品質はなぜ崩れる？ベンダーのスキル不足が過半数で整理しました。
日程が押したときの切り分けは開発遅延の要因は社員のスキル不足が46.5％を占めるにあります。
刷新そのものに人が足りないときは既存システムの刷新と新規導入の違い、予算増の理由は66.3％で扱っています。
まとめ：性能改善で押さえる3つの視点
性能改善は、「遅い」の一言では外に出せません。押さえておきたい視点は3つに整理できます。第一に、IPAは性能・効率性を「システムを実行する際の応答時間・処理時間・処理能力、及びディスク・メモリのハードウェア・その他の資源の使用量などに関する、要求の厳しさ」と定義しており、まずこの4つのどれなのかを決めること。*1 第二に、稼動後の不具合は4段の入れ子で記録され、性能の不具合は一番内側にあること。*1 第三に、数えるのは現象数と原因数に分けた1か月・3か月・6か月の累計で、稼動前の性能テストの結果は含めないことです。*1 この3点を踏まえておけば、「性能を改善してほしいと伝えたのに、最初の2週間が現状の測定で終わった」という事態を避けやすくなります。4つのどれなのかを決め、対象の処理と期間を書き出すところまでは社内でできます。その先、計測から原因の特定までを担える人が社内にいなければ、外部の手を借りるのも一つの選択肢です。
よくある質問
IPAは性能をどう定義していますか
「ソフトウェア開発分析データ集2022」は、要求レベル(性能・効率性)を「システムを実行する際の応答時間・処理時間・処理能力、及びディスク・メモリのハードウェア・その他の資源の使用量などに関する、要求の厳しさ」と定義しています。*1 確認日は2026年9月18日です。
要求レベルの選択肢は何段階ですか
a：極めて高い、b：高い、c：中位、d：低い、e：不明の5つです。*1 性能・効率性は、信頼性・使用性・保守性・移植性・ランニングコスト要求・セキュリティと並ぶ7項目の1つです。*1 確認日は2026年9月18日です。
性能の不具合はほかの不具合と分けて数えますか
分けます。発生不具合総数の内数として「流用部性能問題」が定義されており、母体の性能に関する不具合の総数を数えます。*1 確認日は2026年9月18日です。
どの期間で数えますか
稼動から1か月、3か月、6か月の累計です。*1 現象数と原因数に分けたうえで、1か月の合計値が3か月の累計値を超えてはならないと資料が明記しています。*1 確認日は2026年9月18日です。
どの値なら速いと言えますか
今回参照した資料に記載はありません。要求レベルはaからeの5段階で、閾値は示されていないためです。*1 確認日は2026年9月18日です。
直したい処理が決まったら相談
「夜間バッチの処理時間を来月末まで」といった形で対象と期間が書けていれば、そのままご相談いただけます。まだ4つのどれなのか決めきれていない段階でも構いません。
Remoguとリラシクなら、計測から任せる要員も、原因の特定と修正を分担する要員も、対象と期間を決めたうえでお探しいただけます。
Remoguは、リモート前提で全国から即戦力のITプロ人材を調達するサービスです。リラシクは、扱う求人がすべてリモートワークのITエンジニア専門転職エージェントです。どちらもLASSICが運営しています。
出典
- *1 参考：IPA「ソフトウェア開発分析データ集2022」（PDF）（https://www.ipa.go.jp/digital/software-survey/metrics/hjuojm000000c6it-att/000102171.pdf）。出典：IPA「ソフトウェア開発分析データ集2022」。独立行政法人情報処理推進機構 社会基盤センター発行。A5.2.9「システムの特性」のデータ項目514_要求レベル(性能・効率性)（定義と選択肢）、および A5.2.11「品質」のデータ項目発生不具合総数・発生不具合数(重大性別内訳)・発生不具合数(流用部)・発生不具合数(流用部性能問題)（定義と回答内容）の一次情報として。本書の著作権はIPAが保有し無断の改変や公衆送信などは禁じられているため、この記事は示された定義を引用し、図と表は定義をもとに筆者が作成した。資料の図表そのものは複製していない（2026年9月確認）
- *2 参考：IPA「ソフトウェア開発分析データ集2022」（公開ページ）（https://www.ipa.go.jp/digital/software-survey/metrics/metrics2022.html）。本編と業種編・サマリー版という構成と、収録されている指標の範囲の確認として（2026年9月確認）
- *3 参考：IPA「ソフトウェア開発分析データ集」（https://www.ipa.go.jp/digital/software-survey/metrics/index.html）。年度ごとに公開されていることの確認として（2026年9月確認）
