← 概念辨析に戻る

Concept Contrast Fable

タスク成功率とステップ成功率

先に結論:一つの数は仕事全体が成し遂げられたかを教え、もう一つの数は各段階がしっかり踏まれたかを分解して見せる。タスク成功率だけを見れば、途中で何度もつまずいた代償を見落とす。ステップ成功率だけを見れば、最終的に納品されたものが価値に見合うか分からない。

一つの数は仕事全体が成し遂げられたかを教え、もう一つの数は各段階がしっかり踏まれたかを分解して見せる。タスク成功率だけを見れば、途中で何度もつまずいた代償を見落とす。ステップ成功率だけを見れば、最終的に納品されたものが価値に見合うか分からない。

寓話

二つの成績表

老林の水車工房は染坊の仕事を請け負い、八台の水車で染料、清水、布巻き、乾燥棚を毎日順番に届けなければならなかった。契約にはただ一条だけ書かれていた:毎日最後の布は時間通りに工房を出なければならない。

最初の月、老林は立派な帳簿を提出した。毎日の出坊率は九割七分。染坊の主人は満足していたが、夜勤の店員が、水車がしばしば途中で詰まり、直しては回り、回っては詰まり、最終的に納品には間に合ったものの、油と人件費が何倍にもなったと不平を言うまでだった。

老林は再び水路のそばにしゃがんで見た。八つの工程のうち、第一の取水は安定し、第二の材料追加はよく詰まり、第四の布巻き交換は人を待たせ、最後の乾燥棚は前の遅れでごった返していた。一日中終点だけを見ればすべて順調に見えるが、一歩ずつ見れば道中で何度もつまずいている。

彼はまず、終点で人を増やして急かすことを考えました。催促の声は大きくなりましたが、詰まりは消えませんでした。また、失敗するたびに最初からやり直せばよいと言う人もいましたが、布は出るものの、夜には長い行列ができました。

老林は各水車を個別に記帳した:どの水車が止まり、どれだけ止まり、なぜ止まり、現地で修理できるか。材料投入口は二重槽に変え、布巻きの交換は事前に札を用意し、乾燥棚はバッチごとに分けて待機させ、ライン全体を最初からやり直させなくなった。

三か月後、最終的な出坊率は依然として九割七分だったが、各水車が無事に通過する割合は大幅に高まり、夜勤は二時辰早く終わるようになった。東家はここでようやく理解した。同じ終点に到達するにしても、順調に走り続けるのと、転んでは這い上がるのとでは、コストがまったく違うのだ。

老林はそれ以来、帳簿を二行並記するよう求めた。第一行は物事全体が完了したかを見て、第二行は各段階が順調かを見る。二行の差が大きいほど、終点の数字が現場の問題を覆い隠す。後に彼が新しい仕事を引き受けるとき、まず東家にどの区間をより安定するよう金を払うか尋ねた。最終納品だけを見れば、工房は手戻りを隠す。各段階を見れば、水車を直すべきか、人手を増やすべきか、水路全体を変えるべきかが分かる。彼はまた、終点だけを気にする客もいれば、プロセスの安定をより気にする客もいると気づいた。前者は手戻りに耐え、後者は夜中の補修を受け入れない。二つの帳簿を分けて初めて、工房は自分が売っているのは納期どおりの納品か、予測可能な運用かを知る。

タスク成功率

完全なタスクが開始から最終納品まで成功したかどうかの比率を測る。中間ステップの得失は区別せず、終点の状態だけに注目する。一つのタスクが複数回の失敗と再試行を経ても、最終的に完了すれば一度の成功と数える。

ステップ成功率

タスク内部の各ステップ操作の独立した成功率を測定する。各ステップの失敗後は再試行、スキップ、または降格処理される可能性がある。ステップ成功率が低いことは、システムが安定して実行しているのではなく、多くのフォールトトレランス機構に頼って持ちこたえていることを意味する。

物語の対応

  • タスク成功率は97パーセントだがステップ成功率は62パーセント:高いフォールトトレランスが下層の実行の不安定さを覆い隠している。
  • 平均で四回半リトライ:ステップ成功率が低い直接的な結果であり、各リトライが時間とリソースを消費する。
  • 二つの曲線の対比図:タスク成功率は滑らかに上昇し、ステップ成功率は繰り返し振動し、隠れたコストを露呈する。
  • タイムアウトする API 呼び出しを非同期キューに変更する:タスクレベルのリトライで間に合わせるのではなく、ステップレベルで根本問題を修正する。
  • 二つの数字の間の赤い字の缺口:実世界で最も価値のある信号であり、缺口が大きいほどシステムが運と再試行に依存していることを示す。

プロジェクトに落とし込む

検収報告書には常に二つの成功率を併記する。タスク成功率は納品結果を明示し、ステップ成功率は実行コストを明示する。ギャップが十五パーセントポイントを超える場合は、リトライを重ねるのではなく、まずステップ失敗の根本原因を調査する。自動化の度合いが高く、呼び出しチェーンが長いほど、この二つの数値の差は分析価値を持つ。

京ICP备2026014272号