部分成立が全体完了として継承される位相

Observation

複写機のSMBスキャン障害対応では、

設定変更と再起動が行われ、

操作者から、

「設定した」 「再起動した」

という報告があった。

しかし、

操作後に確認された状態は、 変更前と同じだった。

業務上の試験も成立しなかった。

その後、

画面共有によって、

設定変更を行った対象と、

実際に使用されている対象が 一致していなかったことが確認された。

使用中の対象を選び直し、

再度設定変更を行ったところ、

対象状態の変化と、 業務上の試験成立が確認された。

この過程では、

それぞれの時点で、

・操作した ・再起動した ・使用できている ・設定を変更した

という報告が存在していた。

しかし、

その報告だけでは、

・どの対象を操作したか ・変更が実際の使用対象へ反映されたか ・業務結果まで成立したか

は確定できていなかった。

Structure

ここで露出しているのは、

操作ミスそのものだけではない。

「完了」という一つの言葉の中に、

異なる成立状態が 圧縮されていることである。

例えば、

操作を実施した

ことと、

対象の状態が変化した

ことと、

目的としていた業務が成立した

ことは、

同じではない。

構造としては、

操作実施
↓
反映確認
↓
状態変化
↓
業務試験
↓
目的成立

という複数段階が存在する。

しかし、

途中の一つが成立した時点で、

完了

と扱われると、

後続段階は 確認されないまま継承される。

部分成立
↓
完了報告
↓
次工程
↓
未確認事項の残存

という経路である。

Dynamics

人間同士の業務では、

毎回すべての状態を 詳細に確認することは高コストになる。

そのため、

「設定した」 「再起動した」 「できた」

といった短い報告が、

複数の確認工程を 圧縮する役割を持つ。

通常は、

その圧縮によって 業務速度が上がる。

しかし、

操作対象が複数存在する場合や、

見た目が似た設定画面、 複数経路、 複数端末、

などがある場合、

同じ報告でも、

双方が参照している対象が 一致しているとは限らない。

依頼者が想定した対象
≠
操作者が操作した対象

という差が残る。

この差が確認されないまま、

「設定済み」という状態だけが 次工程へ渡されると、

次の担当者は、

設定は正しい

ことを前提として 別の原因を探索し始める。

すると、

本来前段に残っていた差分が、

後工程では、

新しい問題として 再び現れる。

未確認差分
↓
完了として継承
↓
次工程の前提化
↓
別原因を探索
↓
後から未確認差分が再出現

となる。

Silence

この配置で見えにくいのは、

実施された操作そのものではない。

むしろ、

何がまだ確認されていないか

である。

「設定した」

という報告からは、

どの対象を設定したのかが 見えない場合がある。

「再起動した」

という報告からは、

変更内容が使用中の対象へ 反映されたかは分からない。

「使えている」

という報告からは、

どの経路が実際に使用されているかまでは 確認できない。

したがって、

短い完了報告では、

確認済みの領域

だけでなく、

未確認の領域

も同時に圧縮される。

しかも、

完了という言葉が付いた瞬間、

未確認領域は、

次工程から見えにくくなる。

今回、

画面共有によって、

初めて、

操作対象と使用対象の差が 確認可能になった。

つまり、

問題の解決には、

追加情報だけでなく、

確認媒体そのものの切り替え

が必要だった。

Implication

この構造は、

IT障害対応だけに限定されない可能性がある。

例えば、

組織内では、

説明した

ことと、

相手が理解した

ことは異なる。

申請した

ことと、

承認された

ことも異なる。

対応した

ことと、

問題が解消した

ことも異なる。

納品した

ことと、

利用可能になった

ことも異なる。

しかし、

それらが一つの

「完了」

として扱われると、

後工程は、

成立していない前提を 成立済みとして引き受ける。

すると、

後工程で生じる問題は、

新しい失敗に見える。

実際には、

前工程で閉じられなかった差分が 時間差を持って再出現しているだけかもしれない。

したがって、

完了管理で重要になるのは、

完了条件を増やすことだけではなく、

何を確認した完了なのか

を分離することである。

例えば、

Operation Complete
操作実施

State Complete
状態変化確認

Outcome Complete
業務結果成立

というように、

完了の対象を分ければ、

「どこまで成立しているか」を 残しやすくなる。

ただし、

すべての業務で 細かい確認を要求すれば、

確認コストが過剰になる。

必要なのは、

完全確認ではなく、

次工程の判断を変える未確認事項がどこにあるか

を見極めることになる。

Question

「終わりました」

という報告を受けたとき、

実際には、

何が終わったのだろうか。

操作なのか。

対象状態の変更なのか。

目的の成立なのか。

部分的な成立を、

全体完了として扱うことで、

どれだけの未確認事項が 後工程へ渡されているのだろうか。

後工程で起きた問題は、

本当に、

その工程で生まれた問題なのか。

それとも、

前工程で確認されなかった差分が 再び現れただけなのか。

そして、

業務速度を落とさずに、

「確認済み」と「まだ確認していない」を 分離して継承すること

は、

どのように設計できるだろうか。