お客様の Excel は計算が正しくても、それでも間違っている

誰もがこのExcelを知っています。左にプロセスのステップ、右に平均所要時間、下に合計。6つのステップ、各平均3日、合計18日間のリードタイム。 この数値は見積もりやキャパシティ計画、顧客への約束に使われます。

しかし実際にはもっと時間がかかることがよくあります。いつもではないにせよ、あまりに頻繁です。よくある説明は「見積もりが楽観的すぎた」です。言い訳として都合がいいですが、たいてい間違いです。見積もりは正しくても、計算の結果は外れることがあります。

まず不都合な事実から始めましょう：Excelは間違って計算しているわけではありません。

まずExcelの弁護

もしプロセスが本当に鎖状（ステップ1→2→3、待ち時間なし、共有リソースなし）なら、平均値の合計は合計の平均値と正確に一致します。これは近似でも経験則でもなく、期待値の線形性です。各分布がどれだけ歪んでいても常に成り立ちます。

我々は検算しました：6ステップ、各ステップは右裾の長い分布で平均3日、40万件をシミュレーションしました。

[
  { "label": "Excel: 平均値の合計", "value": "18,0", "unit": "Tage" },
  { "label": "シミュレーション： 実際の平均値", "value": "18,0", "unit": "Tage", "tone": "positive", "note": "差異： 0 %" },
  { "label": "シミュレーションのP90", "value": "24,3", "unit": "Tage", "tone": "critical", "note": "+35 % gegenüber dem Excel" },
  { "label": "18日を超える事象", "value": "44", "unit": "%", "tone": "critical" }
]

Excelは平均値を正確に出します。だからこそ誰もそれを疑いません。 ある一つの問いについては正しいのです。しかしそれは通常、人が本当に問いたいことではありません。

なぜならここで既に第二の事実が立ち現れます：44％のケースで18日より長くかかる、という点です。平均値はそれがどれくらいの頻度で成立するかを示しません。平均値は多くの事象の平均についての記述であり、今まさに約束しようとしている一件についての記述ではありません。

隣の数値はP90です。それが何を意味するか、どのパーセンタイルでキャパシティを計画すべきかはFlowVisualにあります： P10, P50, P90 richtig lesen。ここでは統計の説明は省き、結論だけ述べます：なぜ平均値の合計が約束値としては間違っているか、たとえ正しくても。

ただし：あなたのプロセスは鎖ではない

実務で純粋な直列鎖だけのプロセスはほとんどありません。実際のプロセスにはほとんど常に3つの構造要素が含まれます。どれもがExcelの計算を崩します。

ゲート（門）。 2つの事項が両方とも完了してから次に進む必要がある場合：たとえば技術確認と与信確認の両方が必要で、どちらも平均3日かかるとします。Excelは3日と書きますが、実際には両方のうち遅い方を待つため、平均して3日では済みません。

ループ（手戻り）。 あるステップが時々やり直しになることがあります。15％の手戻りは端数に見えますが、無視できるものではありません。

キュー（待ち行列）。 1人の担当者が6ステップのうち2ステップを処理している場合、Excelにはその人の純粋な処理時間しか書かれません。そこに書かれないのは、担当者が別の作業をしているために案件が卓上で待つ時間です。

同じステップ所要時間、同じ平均3日。ただし構造が異なります：

{
  "caption": "Excel値からの実際の所要時間の差、プロセス要素別（シミュレーション、各30万件）",
  "unit": "%",
  "data": [
    { "label": "鎖： Aの後にBの後にC", "value": 0, "tone": "positive" },
    { "label": "ループ： 15 % 手戻り", "value": 18 },
    { "label": "ゲート： AとBの両方が完了する必要あり", "value": 33 },
    { "label": "ループ： 30 % 手戻り", "value": 43 },
    { "label": "ゲート： A、B、Cの全てが完了する必要あり", "value": 54 },
    { "label": "待ち行列、利用率67 %", "value": 124, "tone": "critical" },
    { "label": "待ち行列、利用率80 %", "value": 231, "tone": "critical" },
    { "label": "待ち行列、利用率90 %", "value": 531, "tone": "critical" }
  ]
}

この中で待ち行列が最も衝撃的です。利用率67％は多くの人が余裕があると考えますが、その時点で実際の滞留時間は純粋な処理時間の2倍以上になっています。90％では6倍になります。これは組織の悪さではなく数学です：利用率が100％に近づくほど待ち時間は急激に増えます。そして増加は線形でなく爆発的です。

人を90％まで稼働させるのは効率的ではありません。単に待ち時間を自分の損益表から顧客のリードタイムに押し付けているだけです。

なぜ誤差は常に同じ符号を持つのか

図のパターンは偶然ではありません。名前があります。

Excelは**f(平均値)を計算します：各ステップに平均を入れてプロセスを通します。現実は平均値のf(X)**を返します：各事象が揺らぎのある実際の所要時間でプロセスを通り、その後に平均を取ります。

これは同じではありません。ジェンセンの不等式によれば、関数が凸なら結果の平均は平均値を評価した結果より大きくなります。

そして決定的な観察：ゲート、ループ、待ち行列のいずれもが凸的です。 最大値をとる操作は凸、幾何学的な繰り返しも凸、待ち行列は特に強い凸性を持ちます。だから図中の差分は負にはなりません。

つまりExcelの誤差は単なるばらつきではなく偏りです。たまに高く、たまに低くなるのではなく、体系的に楽観的です。プロセスに構造が増えるほどその偏りは大きくなります。

同じプロセス、二つの計算方法

現実に即した6ステップのプロセスを考えます：ステップ2と3は並列で両方とも完了する必要がある。ステップ5は15％の手戻り。他は特に変わった点はない：待ち行列も共有担当者もなし。各ステップの平均は3日です。

Excelは平均を代入して計算し、15日となります。この計算自体は正しく、並列のゲートも正しくモデル化されています。

[
  { "label": "Excel: ステップごとの平均", "value": "15,0", "unit": "Tage" },
  { "label": "シミュレーション： 平均", "value": "16,5", "unit": "Tage", "tone": "critical", "note": "+10 %" },
  { "label": "シミュレーション： P90", "value": "22,8", "unit": "Tage", "tone": "critical", "note": "+52 %" },
  { "label": "15日を守れた事象", "value": "43", "unit": "%", "tone": "critical" }
]

約束されるのは15日。しかし実際に15日で終わるのは43％のケースだけです。

これが要点です。Excelが10％ほど外れること自体は問題ではありません（それなら耐えられる）が、問題はExcelが約束のように見える数値を出し、それが実際にはコイントスに等しい点です。これを基に計画するということは、存在しないプロセスを計画することになります。

下でご自身でシミュレーションを動かせます。シミュレーションは所要時間だけでなく、どのステップがどの状況でボトルネックになるかも示します。状況が変われば答えも変わります。

唯一逆向きになる要素

もし凸的な構造がExcelを楽観的にするなら、逆に凹的で計算が悲観的になる要素はあるでしょうか？

はい。あり、それが多くの場合で最も安価な改善策がソフトウェアでない理由です。

例を想像してください：2人の担当者、それぞれが別分野を担当し、それぞれに専用の待ち行列がある。1人は新規顧客担当、もう1人は既存顧客担当。速さも利用率も同じです。

ここで1点だけ変えます：共通の待ち行列にする。 空いた人が次の案件をどちらでも処理する、という運用にする。人も処理時間も総 workload も同じです。

{
  "caption": "同じ能力・同じ負荷での滞留時間：分離された待ち行列と共通待ち行列の比較（シミュレーション）",
  "unit": "Tage",
  "data": [
    { "label": "2人の専門家、各自のキュー（平均）", "value": 20.7, "tone": "critical" },
    { "label": "2人の専門家、各自のキュー（P90）", "value": 43.5, "tone": "critical" },
    { "label": "2人の汎用担当、共通キュー（平均）", "value": 12.5, "tone": "positive" },
    { "label": "2人の汎用担当、共通キュー（P90）", "value": 23.9, "tone": "positive" }
  ]
}

滞留時間は**40％減り、P90は45％**下がります。追加の人員なし、追加のソフトウェアなし、月額ツールの費用も不要です。

理由はまた数学です。ただし今回は符号が反転します：2つの分離したキューは相互に助け合えません。一方は遊んでいる間にもう一方に仕事が溜まります。これらの遊休時間は再利用できず失われます。共通キューにするとこの損失が消えます。複数の自由な処理者の最小値は凹関数であり、したがってここでは符号が逆になります。

我々にとってこの記事で最も正直な発見はここです。分析がボトルネックを待ち行列だと示したら、正しい提案はしばしば「ソフトウェアを買う」ではありません。むしろ「2つの専門分野を1つに統合してください」です。費用はかからず、我々のプロジェクト時間は減ります。

実務への帰結

第一に：点推定値はプロセス分析に不適切です。 所要時間は数値ではなく幅です。各ステップについて楽観値、典型値、悲観値を記録してください。平均を推測するのと同じ時間で済みますし、それが唯一計算可能な情報です。

第二に：平均値を約束しないでください。 平均値は年間平均についての記述であり、次の1件の約束ではありません。納期はP90に置くべきです。平均値を約束するということは、約束の半分を破ることに同意するということです。

第三に：構造は見積もりより重要です。 ステップ所要時間を10％の精度で見積もっても、ゲートや待ち行列を見落とせば桁違いの誤差になります。逆に荒い見積もりと正しくモデル化された構造なら驚くほど正確になります。

第四に：利用率は目標ではない。 90％の利用率は管理がうまくいっているように感じさせますが、それがリードタイムを爆発させる原因です。

だからFLOWにはOがある

我々の手法はFLOWREFYと呼び、最初の4文字は測定を表します：Find — 対象プロセスを見つける。Lay bare — 現状のコストをユーロで明らかにする。Observe — シミュレーションする。Weigh — 比較検討する。

F、L、Wについては当社の無料電卓があります。Oについては存在しません。隠して有料にしているからではなく、シミュレーションは入力フィールドに収まらないからです。プロセスの構造が必要です：誰が誰を待つか、誰と共有するか、どこで手戻りが発生するか。まさにExcelの合計式に現れないものであり、15日と22.8日の差を生むものです。

そのために我々はFlowVisualを作りました：プロセスを描き、幅を入力し、状況を走らせる。それは所要時間だけでなく、需要が増えたときどこで詰まるか、今直そうとしているボトルネックが負荷時にまだ同じかどうかを示します。

まずは年間で最もコストのかかるボトルネックがいくらなのか知りたいだけなら、ここから始めてください： hier。無料で約10分です。

---

手法について

この記事の数値はすべてMonte Carloシミュレーションに基づき、顧客プロジェクト由来のものではありません。ステップ所要時間は対数正規分布で平均3.0日、変動係数が約0.65になるばらつきです。分布は右に裾が長く、実際の処理時間と同様に0未満にはならず上には大きく伸び得ます。各要素ごとに30万から40万件をシミュレーションし、待ち行列は8万の到着と切り捨てた立ち上がりフェーズで評価しました。

具体的なパーセンテージ値はこれらの仮定に依存します。だが方向性は依存しません：ジェンセンの不等式に従い、分散が0より大きければ常に成り立ちます。分布が狭ければ差は小さくなりますが、符号は変わりません。