何も起きていないから続ける、という業務 – Arkanos Insights
長年続けている確認作業や承認手続きは、本当に問題を防いでいるのでしょうか。「何も起きていないから続ける」という判断によって業務が儀式化する構造と、不要な仕事を見直すための考え方を整理します。
あるシステムで、一時的なアクセス集中が発生しました。
アクセス元を調べると、単一の端末による大量アクセスではなく、多数の端末から同じ時間帯にアクセスが集中していたことが分かりました。
さらに周辺の出来事を調べると、偶然にも、同じ時間帯に比較的大きな地震が発生していました。
地震による通信の切断や再接続が影響した可能性はあります。しかし、現時点では地震とアクセス集中の因果関係は確認できません。単に時刻が一致しただけかもしれません。
一方、インターネット上では、この地震についてまったく別の説が語られていました。
少し前に、ある歴史上の人物を祀る場所で、配信者による迷惑行為があった。その人物は古くから「祟り」の伝説で知られており、地震の震源も、その人物にゆかりのある地域だった。
そのため、一部では「迷惑行為に怒った歴史上の人物が地震を起こした」と考える人まで現れました。
この説を先ほどのシステム障害までつなげると、次のようになります。
- 史跡で迷惑行為が行われた
- 祀られている人物が怒った
- その人物にゆかりのある地域で地震が発生した
- 地震によって通信網や端末が反応した
- 多数の端末から一斉にアクセスが発生した
- アクセスが中継サーバーの固定IPに集約された
- セキュリティ機能が攻撃と判定した
- 利用者にエラーが返された
ここまで来ると、「風が吹けば桶屋が儲かる」をはるかに超えています。
もちろん、途中には確認されていない因果関係がいくつもあります。特に、迷惑行為と地震を結び付ける部分は、完全にオカルトの領域です。
そこで冗談として、次のような恒久対策を考えました。
- システムのアクセス制限設定を見直す
- 定期的にログを監視する
- 関係者が毎年、ゆかりの場所へ参拝する
最後の一つは、当然ながら技術的な対策ではありません。
ところが、もし参拝を始めた後に何年も問題が起きなかったら、どうなるでしょうか。
「参拝を続けているから、問題が起きていないのかもしれない」
そんな説明が、少しずつ説得力を持ち始めるかもしれません。
何も起きなかった理由は分からない
ある対策を実施した後に問題が起きなかったとしても、その対策に効果があったとは限りません。
問題が起きなかった理由には、少なくとも二つの可能性があります。
- 対策を実施したため、問題が起きなかった
- 対策を実施しなくても、問題は起きなかった
しかし、実際の業務では、この二つを比較することが難しい場合があります。
問題を防止するための確認作業をやめて、本当に問題が起きてしまえば、廃止を決めた担当者の責任になります。その一方で、作業を続けても問題が起きなければ、「従来どおり運用した」ということで、誰も責任を問われません。
その結果、合理的な理由が確認できなくても、作業を続けるほうが安全な判断になります。
- 続けて問題が起きない場合は、現状維持
- 続けて問題が起きた場合は、想定外
- やめて問題が起きない場合は、特に評価されない
- やめて問題が起きた場合は、廃止した人の責任
これでは、不要な業務が残り続けるのも当然です。
対策は、やがて儀式になる
企業の中には、こうして長年残っている業務が少なくありません。
- 誰が読むのか分からない報告書
- 同じ情報を複数のシステムへ入力する作業
- 自動チェックの後に行う全件目視確認
- 判断を伴わない多段階の承認
- 目的が分からないまま続いている定例会議
- 過去の障害をきっかけに追加された確認項目
導入された当初には、何らかの理由があったはずです。
しかし、システムや業務環境が変わり、別の仕組みでリスクが防止されるようになっても、作業だけが残ることがあります。
いつしか目的は忘れられ、
「以前からやっているから」
「今まで問題が起きていないから」
「念のため確認しているから」
という理由で続けられます。
ここまで来ると、その作業は対策ではなく、儀式に近いものになります。
継続にも根拠が必要になる
問題が起きていないこと自体は、決して悪いことではありません。
ただし、それを現在の業務が有効である証拠として扱うには注意が必要です。
定期的に、次の点を確認する必要があります。
- その作業は何を防ぐために始めたのか
- 対象となるリスクは現在も存在するのか
- 作業によって実際に何を検知・防止できたのか
- システム化や別の対策によって代替されていないか
- 実施頻度を下げることはできないか
- 廃止した場合に、どのような影響が考えられるか
これらに答えられない場合でも、直ちに作業を廃止すべきとは限りません。
影響範囲を限定して試行的に停止する、実施頻度を下げる、自動化したうえで一定期間監視するなど、段階的な見直しも可能です。
重要なのは、「続けるか、やめるか」の二択だけで考えないことです。
業務改善は、速くすることだけではない
業務改善というと、既存の作業を自動化したり、AIを使って効率化したりすることが注目されます。
しかし、必要性を確認しないまま自動化すると、不要な業務が高速で実行されるようになるだけです。
自動化の前に、その作業自体が今も必要なのかを考えなければなりません。
システム開発では、不要な機能を一つ作らないことが、開発費を抑える最も確実な方法になる場合があります。
業務改善も同じです。
不要な仕事を速く処理するより、やらなくてよい仕事を一つ減らすほうが、大きな効果を生むことがあります。
「何も起きていないから続ける」のではなく、何を防ぐために、どのような根拠で続けているのかを確認する。
業務を始めるときだけでなく、業務を終わらせるときにも、設計と判断が必要です。