「あと10分で終わります」が60分に化けるバグ。進捗の数字を狂わせる「不確定因子」の正体

③ 判断のバグ

2026.10.30 2026.10.24

※本記事にはプロモーション（広告）が含まれています。

「あと10分で終わります」――。この記事では、ビジネスの現場で起きるこの現象の裏にある「OSのバグ」を、アーキテクトの視点で解剖します。

よくある場面

「あとどれくらいでできそう？」
「うーん、10分くらいかな」

キッチンでの会話です。ご飯が出てくるまでの時間を逆算し、それまでに自分が何かのタスク（メール1件など）を処理できるか設計するための質問です。

ところが、大概10分では出てきません。実際にご飯が出てきたのは、そこから60分後。「60分あったら、もう一つ大きな仕事が終わっていたじゃないか」と絶望することになります。

なんてルーズな奴だ、と思うでしょうか。このバグが衝撃的なのは、QA層だけでなく、PMである私たち自身も無意識にやってしまうという点です。

なぜ、私たちは終了時間をこれほどまでに正確に見積もれないのでしょうか。

それは、脳が「不確定因子（外部からのブロック処理）」を計算から除外してしまっているからです。

駅まで「普通に歩けば」10分だから、10分で着くと見積もる。ところが実際には、前の人が歩きスマホをしていて歩みが遅い。信号が運悪く赤になる。つまり、自分でコントロールできない不確定因子（変数）が介入し、10分が12分、15分と膨張していくわけです。

先ほどのキッチンの例も全く同じです。「普通に調理プロセスを回せば」10分で終わる。しかし、まな板を置くスペースに洗い物が残っていたり、冷蔵庫の奥から調味料を探し出すのに手間取ったりという【事前の環境構築（インフラ整備）】の遅延が重なり、最終的に60分という致命的なエラーを引き起こします。

ここでの最大の問題点は、PMが「どれくらいかかる？」と聞いた際、部下が「10分」「90%」といった【具体的な数字】で返答してしまうことにあります。

具体的な数字がシステム（PMの脳内）に入力されると、それが強烈なアンカー（基準値）となり、「10分で終わるなら別の処理を走らせよう」というスケジュールが組まれます。そして、その数字から少しでも遅れると「遅い」「見積もり違いだ」という相対評価（エラー）が生まれてしまうのです。

実行者（部下）の頭の中にある「10分」は、すべての条件が完璧に整った理想空間（テスト環境）でのみ成立する幻の数字です。

では、この不確定因子にまみれた現実のプロジェクトにおいて、PMはどのように進捗をヒアリングし、狂ったプログレスバーを修正すべきでしょうか？

数字を聞かれるから、部下は直感で数字を返してしまいます。聞き方を、数字から「中身」に変えます。

「『あと少し』や『90%』ではなく、終わったタスクと、まだ手をつけていないタスクを箇条書きで教えてください」

残りのタスクが見えれば、PMは「調理は終わりそうだが、盛り付けと洗い物が残っている。10分では終わらない」と、自分で状態を判断できます。数字ではなく要素で受け取ることが、狂ったプログレスバーを直す第一歩です。

ここまでが、最初の一手です。この一手を習慣にして、同じバグを繰り返さない仕組みにするための残りの手順は、noteで公開しています。

ここから先の具体的な解決策・コマンドは、noteの記事「アーキテクトの過去問」として公開しています。

『ファスト&スロー』（ダニエル・カーネマン）
人はなぜ作業時間を楽観的に見積もってしまうのか（計画の誤謬）。直感が数字を狂わせる仕組みを、行動経済学から理解できる一冊。
▶ 楽天で探す
▶ 耳で読むなら：新作続々追加！オーディオブック聴くなら – audiobook.jp