RT-01｜仕事はなぜ「作業量」ではなく、“戻ってくる回数”で重くなるのか

仕事の重さは、作業時間だけでは測れない。

同じ10分の処理でも、一度で終わる10分と、数時間後にもう一度確認する10分、翌日に前提を思い出して再開する10分、差戻しのあとに判断し直す10分では、負荷の質が違う。

一般に仕事量は「件数 × 処理時間」で捉えられやすい。だが実際の仕事には、作業そのものとは別に、何度も同じ対象へ戻る時間がある。

状況を思い出す。資料を探す。前回どこまで進めたかを確認する。なぜそこで止めたのかを再構成する。関係者の返答を読み直し、条件が変わっていないか確かめる。

こうした時間は、しばしば「作業時間」としては見えにくい。

それでも、仕事へ戻るたびに発生する。

仕事には「作業時間」と「再接続時間」がある

仕事の実際の負荷は、単純な処理時間だけではなく、

Work Burden
≈
Operation Time
+
Re-entry Frequency
×
Reconstruction Depth

として見ることができる。

Operation Timeは、文章を書く、数字を入力する、資料を修正する、といった直接的な作業時間である。

Re-entry Frequencyは、その仕事へ何度戻るか。

Reconstruction Depthは、戻るたびにどれだけ前提や文脈を作り直さなければならないかである。

同じ仕事へ何度戻っても、前回の状態が十分に残っていれば負荷は小さい。

逆に、戻る回数が少なくても、毎回ほぼゼロから状況を読み直す必要があれば負荷は大きい。

問題は「戻ること」そのものではない。

戻るたびに、どれだけ現在地を再構成しなければならないかである。

小さな未完了が、未来から戻ってくる

日常業務には、小さな未完了が大量に存在する。

「あとで返信する」 「念のため確認する」 「来週もう一度見る」 「相手から返事が来たら判断する」 「月末にまた処理する」

一つひとつは大きな仕事ではない。

しかし、それぞれが未来のどこかで再び現在へ戻ってくる。

ここで未完了は、単なる「残っている仕事」ではない。

未完了
=
未来に予約された再接続

として見ることができる。

再び触れたときに、

「これは何だったか」 「どこまで進んでいたか」 「なぜ保留したのか」 「何を確認すれば終わるのか」

を読み直さなければならないからだ。

仕事が重くなるのは、大きな仕事が増えたからとは限らない。

未来から戻ってくる小さな仕事が増え、そのたびに現在の認知を占有している可能性もある。

人は前回の続きから、そのまま再開できない

システムなら、保存された状態から処理を再開できる。

しかし人間は、時間が空くほど、そのまま続きを始めることが難しくなる。

実際には、

Pause
↓
Resume

ではなく、

Pause
↓
Reconstruction
↓
Resume

になる。

このReconstructionが、反復時間の主要な負荷になる。

例えば、提出済みの資料に「ここだけ修正してください」と戻ってきたとする。

修正自体は5分で終わるかもしれない。

だが、その5分を始める前に、前回何を提出したのか、なぜその表現にしたのか、相手が何を求めているのか、どこまで直せばよいのかを読み直す必要がある。

差戻しのコストは、追加作業時間だけではない。

文脈を再構成し、判断を再起動するコストも含んでいる。

工数管理では見えにくいもの

従来の工数管理は、主に「実行中の時間」を測る。

何分かかったか。 何件処理したか。 何時間働いたか。

これらは重要な指標だが、時間をまたいで再起動される構造までは捉えにくい。

RTが見ようとするのは、

実行時間

だけではなく、

過去の未完了が
未来の現在へ再び侵入する回数と深さ

である。

一件の仕事が一度で終われば、その仕事は現在から離れる。

だが、確認待ち、差戻し、保留、例外処理によって再び戻ってくるなら、その仕事は未来の時間も占有する。

仕事の負荷は、現在使った時間だけではなく、未来にどれだけ再接続を予約したかによっても変わる。

自動化しても、「戻ってくる仕事」が消えるとは限らない

AIや自動化は、直接的な作業時間を短縮できる。

30分かかっていた文章作成が、AIによって3分になることもある。

しかし、その後に、

生成
↓
確認
↓
修正
↓
再生成
↓
再確認

が続けば、Operation Timeは減っても、Re-entry Countは減らない。場合によっては増える。

ここには、自動化をめぐる一つの見落としがある。

処理速度の改善
≠
時間構造の改善

一回の処理を速くすることと、その仕事へ何度戻らなければならないかは別の問題である。

AIが作業の一部を高速化しても、確認、承認、例外処理、責任判断が人間側へ残れば、人間は何度も同じ仕事へ呼び戻される。

結果として、「作業は速くなったのに、なぜか忙しさが減らない」という状態も成立する。

小規模組織では、反復時間が人間の中へ埋め込まれやすい

大規模な組織では、ワークフロー、チケット、ステータス、履歴、担当者といった形で、仕事の状態が外部化されていることが多い。

一方、小規模な組織では、

「覚えておく」 「あとで声をかける」 「前回と同じようにする」 「あの人なら知っている」

という形で運用されることがある。

このとき、人間の記憶や経験がシステムの一部になる。

表面上は、特別な管理システムがなくても仕事が回っている。

だが、その安定は、人間が再接続処理を吸収していることで成立しているかもしれない。

何を覚えておく必要があるか。 誰に聞けば再開できるか。 どの例外は前回どう処理したか。 次に何が起きたら動けばよいか。

これらが記録されず、人間の頭の中へ残るほど、仕事へ戻るたびに再構成が必要になる。

そして、その負荷は「一件あたり何分か」という数字には現れにくい。

反復時間は「忙しさ」とは少し違う

忙しさは、その瞬間に多くの仕事を処理している状態として見える。

反復時間の負荷は、もっと分散している。

今日は何も起きない。 明日返信が来る。 来週もう一度確認する。 月末にまた同じ処理をする。

一日単位では軽く見えても、長い時間で見ると、常に何かが戻ってくる。

これは仕事量の増加というより、時間の占有構造の変化に近い。

仕事が一日の中でまとまって存在するのではなく、細かく分散しながら何度も割り込んでくる。

そのたびに文脈を切り替え、判断を再起動する。

結果として、処理量以上に「仕事から離れ切れない」という感覚が残る。

見るべきなのは、処理件数ではなく「再起動回数」かもしれない

一件の仕事が、

初回処理
↓
確認
↓
差戻し
↓
再処理
↓
問い合わせ
↓
再確認
↓
完了

という経路を通るなら、一件の仕事の中で複数回の認知再起動が発生している。

だから、

1 Task
≠
1 Cognitive Event

である。

同じ一件でも、一度で完了する仕事と、何度も再訪する仕事では負荷が違う。

さらに同じ再訪回数でも、状態が引き継がれている仕事と、毎回ほぼゼロから読み直す仕事では負荷が違う。

RTが見るのは、この「回数」と「再構成の深さ」の組み合わせである。

「戻らなくてよい」より、「ゼロから戻らなくてよい」

ここで、反復そのものを悪いものとして扱う必要はない。

毎月の給与計算、定期点検、バックアップ、確認作業のように、繰り返すこと自体が必要な仕事もある。

問題は、繰り返すことではない。

同じ反復のたびに、どれだけ前回の状態を再構成しなければならないかである。

良い反復は、

前回の状態
↓
次回へ継承

される。

重い反復は、

前回
↓
切断
↓
再構成
↓
再開

される。

だから、仕事を軽くする条件は「二度と戻らないこと」だけではない。

次に戻ったとき、どこまで前回の状態を引き継げるかも重要になる。

仕事は、未来から現在へ戻ってくる

仕事は、現在処理しているものだけではない。

未完了の仕事は、明日、来週、来月という未来の時間から再び現在へ戻ってくる。

だから仕事の負荷は、現在の処理量だけではなく、

未来に予約された再接続

によっても決まる。

仕事の重さを考えるとき、作業時間だけを見ると、この構造は見えにくい。

何分かかったか。 何件処理したか。 どれだけ自動化したか。

それだけではなく、

「何度、その仕事へ戻ったか」 「戻るたびに、どれだけ文脈を作り直したか」 「前回の状態を、次回へどれだけ持ち越せたか」

を見る必要がある。

仕事を軽くするとは、すべてを速くすることではない。

時間をまたぐ仕事が、毎回どれだけ現在を占有し直すのか。

RTが観測するのは、その反復時間の構造である。

---

翻訳層｜接触面／再帰地点

■ 接触面（RT）

この構造は、業務設計、DX・AI導入、組織の役割分担、定期運用の見直しで接触する。処理時間が短縮していても、再接続頻度や再構成深度が増えていないかが観測点になる。

■ 再帰地点

成立前提は何か。前回状態はどこまで次回へ継承されているか。確認・承認・例外処理のどこで再接続が増えるか。再評価すべき変数は、処理時間だけでなく再起動回数、未完了差分、状態継承率である。