数値・単位・ビット
120msから90msになった。何％改善した？
使うツール
改善後の数字を報告しようとすると、『25%速くなった』『33%速くなった』『元の75%になった』という表現が並ぶことがあります。同じ測定結果から出た数字でも、何を割っているかが違えば値は変わります。計算ミスを探す前に、何を基準に、何の変化を説明しているのかを確かめるのが近道です。
割合・増減率ツールで、架空の処理時間120msと90msを比べます。実サービスを測定する機能ではなく、用意した二つの値から割合を計算する機能です。測定条件が違う値でも計算自体はできるため、結果が出たことを公平な比較ができた証拠にはしないでください。
30ms減った、を元の120msで割る
増減率のモードで、元の値を120、新しい値を90にします。結果は-25%です。計算は(90－120)÷120×100。負の符号は、ここでは処理時間が減ったことを表します。減った量だけを正の言葉で伝えるなら、『処理時間が25%短縮した』と説明できます。マイナスだから性能が悪くなった、という意味ではありません。
before = 120 ms
after = 90 ms
difference = -30 ms
change = -25%120と90の単位はそろえてから入力します。120msと0.09秒をそのまま二つの欄へ入れると、道具は単位が違うと気付けません。結果の割合には単位が付かなくても、元の二値には同じ物差しが必要です。ミリ秒と秒、byteとKBなどが混ざる比較では、先に単位を統一してから割合を求めます。
75%になったことと、75%減ったことは違う
割合のモードへ切り替え、部分の値90、基準の値120を入力すると75%です。これは新しい時間が元の何割かを表しています。75%が残ったので、減った分は25%です。報告の見出しを『削減率』とするなら75%をそのまま貼らず、増減率の結果を使う必要があります。
逆に、元の120msから75%減ったなら、残る時間は30msです。90msとは三倍違います。短い説明ほど、『元の75%』『25%減』『75%減』のどれを意味するのかを省略しないようにします。数式が合っていても、主語と動詞を取り違えると、読んだ人が受け取る改善幅は大きく変わります。
元へ戻るとき、同じ25%では戻らない
元の値を90、新しい値を120へ入れ替えると、増減率は約33.3333%です。同じ30msの差でも、今度は90を基準にしているからです。増減率は対称ではありません。比較する順番を入れ替える操作は、符号だけを変える操作ではないことを、結果と式の両方で確かめます。
同じように、100から20%増えて120になり、そこから20%減ると96です。増えた後の大きい値を基準に減らしているため、100へは戻りません。割引や容量増設の数字を足し引きだけでまとめたくなるときは、途中の基準が変わっていないかを確認してください。連続する増減は、それぞれの段階を順番に計算します。
時間が25%減ると、処理件数は何%増える？
一件を終えてから次へ進む単純な処理で、ほかの待ち時間がないと仮定します。120msなら一秒に約8.333件、90msなら約11.111件です。処理件数は約33.333%増えます。時間が25%減ったことと矛盾していません。時間の逆数を比較しているため、割合が変わります。
実際のサービスでは並列処理、待ち行列、外部API、CPU以外の制限があります。この単純な逆数から、サーバーの処理能力が33%増えたと保証することはできません。報告では『一件当たりの時間を25%短縮した』という測定した事実と、『同じ条件で直列処理できるなら件数は約33%増える』というモデルを分けます。
エラー率が2%から1%へ。1%改善？50%改善？
割合どうしの差は、パーセントポイントで表すと区別できます。2%から1%への変化は1パーセントポイントの低下です。一方、元の2%を基準にした相対的な減少率は50%です。増減率モードへ2と1を入れると-50%になります。『1%下がった』だけでは、どちらの意味かが読み手に伝わりません。
さらに、元の件数も重要です。100件中2件と100件中1件、10万件中2,000件と10万件中1,000件では、割合の変化は同じでも判断に使える情報量は違います。このツールは統計的な有意差や原因を判定しません。偶然の揺れか改善の効果かを論じるなら、割合計算だけで結論を出さないようにします。
0件から1件は、何%増えたと書く？
元の値が0だと、増減率の式は0で割ることになります。このツールは通常の増減率として結果を確定せず、エラーにします。0から1になったことを100%増と書くのは適切ではありません。『0件から1件へ増加』『新たに1件発生』のように、実数と状態を説明するほうが伝わります。
0へ近い小さな基準では、有限でも大きな増減率が出ます。1件から10件は900%増ですが、増えた件数は9件です。割合だけを大きく表示すると、実際の規模が分からなくなります。小さい母数や負数を基準にした計算では、通常の増減率が読者に伝えたい意味を表しているかを特に慎重に考え、絶対差も併記します。
伝わる改善報告は、元の二値を隠さない
『平均処理時間が120msから90msへ短縮、差は30ms、元の値に対して25%減』と書けば、基準も規模も読み取れます。平均値どうしなのか、中央値どうしなのか、同じ件数・同じ条件の測定なのかもそろえます。速い一件だけを変更後として選んだり、平均と最悪値を比較したりすれば、計算が正しくても改善の説明にはなりません。
割合ツールの役割は、用意した値に対する式を間違えずに確かめることです。何を基準にするか、何を改善と呼ぶか、結果にどれだけ根拠があるかは、その外側で決めます。入力順を逆にした結果、残った割合、絶対差まで一度見比べてから文章にすると、数字だけが独り歩きする報告を避けやすくなります。
二つのエラー率を、そのまま平均してよい？
午前は100件中10件のエラーで10%、午後は900件中9件で1%だったとします。二つの率を足して2で割ると5.5%ですが、一日全体の率ではありません。全体では1,000件中19件なので1.9%です。午前と午後で件数が違うため、各時間帯を同じ重さで平均すると意味が変わります。割合ツールでは、先に元の件数を合計し、部分19、基準1000として確かめます。表示されたパーセントだけを集めると、全体を復元するための分母が失われます。
改善前後を比べる場合も、集計の範囲をそろえます。全リクエストのエラー率と、特定の機能だけのエラー率を並べて減少率を出しても、同じ対象が改善したとは言えません。測定期間、対象機能、失敗と数える条件がそろっているかを先に確認します。ツールへ入れられる数値だからといって、比較する意味まで成立するわけではありません。集計条件が変わった場合は、その変更と数値の変化を一緒に記録すると、あとから読む人が改善と定義変更を混同せずに済みます。