直す前にしか取れない数字がある
改修に着手すると、「直す前はどうだったか」は二度と測れなくなります。直した後に測っても、それは「直した後」の数字でしかありません。
だから、改修の前に必ず問う一問があります。この値は、直した後でも取れるか？ 取れないなら、着手より先に測ります。時間はそれほどかかりません。5 分で済むことが多いです。
私たちは日々の作業の多くを AI に任せています。AI に渡すと手が速いので、測る前に改修が進んでしまいやすいという別の難しさがあります。だからこの一問は、渡す前の順番に入れています。
実際に測った日と、出た数字
測ったのは 2026 年 8 月 25 日です。対象の処理ひとつにかかった時間は、実測で 194 ミリ秒でした。
ここで終わらせず、内訳まで見ました。そのうち計算に使われていたのは 30 ミリ秒で、全体の 15%です。残りの 85% の正体は、データベースと外部サービスへの待ち時間でした。
合計ではなく、内訳を見る
194 ミリ秒という合計だけを見ていたら、「まあまあ速い」で終わっていたはずです。それでは打ち手が出ません。
内訳を見て初めて、遅さの正体が計算ではなく待ち時間だとわかりました。だから正解は、計算する力を足すことではなく、待っている間に、先に返すという設計でした。この計測は、プラットフォーム側の機能で、コードを触らずに測れています。
実測と外挿は分ける
ここでひとつ、注意していることがあります。実測と外挿を分けるということです。
「1 件が 194 ミリ秒だから、10 件なら 1.94 秒になる」という計算は、実際に測ったわけではないので実測ではありません。測っていない値を、測った値のように書かないようにしています。
測ってわかったこと、確認できたこと
改修に着手する前の引き継ぎ書には、「1 件あたり 0.1〜0.3 秒程度」という推定値が書かれていました。今回の実測は、この範囲に収まっていました。
つまり今回の計測は、改修の判断材料であると同時に、事前の推定が当たっていたことの確認にもなりました。推定と実測は、混ぜずに書き分けています。
よくある質問
なぜ改修の前に測るのか。
改修してしまうと、「直す前」の状態は二度と測れなくなるからです。直す前にしか取れない数字があります。
内訳を見ずに合計だけで判断するとどうなるか。
見当違いの場所を直すことになりかねません。今回も、合計だけで見ていたら、計算を速くする方向に進みかねないところでした。
推定値と実測値は同じ扱いでよいか。
いいえ。分けて書いています。今回は推定値の範囲に実測が収まったので推定の裏づけにはなりましたが、推定はあくまで推定です。
出典
- 本文の実測値（2026 年 8 月 25 日 / 194 ミリ秒 / 30 ミリ秒・15% / 85%）は、TEDIT社内の判断フレーム記録に基づきます。（2026-08-25 確認）