第268章 例外の扱い
三つ目の設備で試行が始まった日の午後、レイヴンは現場責任者から、点検表の記載方法について相談を受けた。
「異常を発見したとき、担当者が不在なら、代理の人が停止を判断することがあります。この場合、共通様式には誰の名前を記載すればいいでしょうか」
レイヴンは、既存の様式と、これまでの試行結果を見比べた。
現在の様式には、対応を決めた担当者を記載する欄がある。しかし、通常の担当者が不在だった場合については、特に説明がなかった。
「実際に判断した人と、その人が代理として対応したことの両方を残せばよいと思います。通常の担当者の名前だけを記載すると、後から確認したときに、誰が判断したのか分からなくなる可能性があります」
「代理の人が、通常の担当者と同じ権限を持っていない場合は？」
「その場合は、判断した内容と、どの範囲まで対応できたのかを分けて記録したほうがよさそうです。代理だったからといって、すべての判断が無効になるわけではありませんし、反対に、代理であれば何でも決められるわけでもありません」
現場責任者は、その説明を聞いてから、具体的な例を挙げた。
設備に異常が見つかった場合、現場責任者が不在でも、作業員は危険を避けるために設備を停止できる。一方、修理の実施や再稼働については、別の担当者による確認が必要になることがある。
つまり、代理の人が何を判断できるのかは、作業の段階によって異なっていた。
レイヴンは、様式に新しい欄を追加する案を示した。
判断した人。
通常の担当者との関係。
実施した対応。
追加の承認が必要な場合は、その承認者と確認時刻。
現場責任者は、案を確認した。
「この形なら、代理の人が対応したことと、その人がどこまで判断できたのかを分けて残せますね」
「はい。ただ、すべての作業で代理の人の説明を詳しく書くと、記録の負担が大きくなります。通常の担当者が不在だった場合や、権限の範囲が通常と異なった場合に、追加情報を残す方法でもよいと思います」
二人は、例外が発生したときに必要な情報を追加する方式を採用した。
その後、レイヴンは三つ目の設備で、実際の点検記録を確認した。
点検は予定どおりに進んでいたが、一つの項目で、担当者が確認結果を記入した時刻と、端末に登録された時刻が異なっていた。
現場の担当者は、点検を終えてから、まとめて端末に入力したと説明した。
その方法自体は、事業者の手順で認められていた。
ただし、入力時刻だけを見れば、実際の点検がその時刻に行われたようにも読める。
レイヴンは、担当者に確認した。
「端末への登録時刻とは別に、実際に点検した時刻を記録できますか」
「できます。現在の様式では、入力時刻しか表示されないので、点検時刻を追加する必要があります」
「では、点検時刻と登録時刻を分けましょう。登録が遅れたこと自体を問題にするのではなく、いつ確認が行われたのかを追えるようにしたいです」
担当者は、変更に同意した。
レイヴンは、点検時刻と登録時刻を別の項目として追加し、入力が遅れた場合には、その理由を必要に応じて記載するよう提案した。
記録の時間が異なるからといって、直ちに不正があったと判断することはできない。
一方で、二つの時刻を区別しなければ、後から記録を読む人が、実際の作業と入力の順序を誤って理解する可能性があった。
その日の作業が終わると、レイヴンは修正した様式を案件の責任者に提出した。
責任者は、代理対応と時刻の記録について確認し、試行対象の三つの設備で共通して使うことに同意した。
「例外が出るたびに項目を増やすと、様式が複雑になりすぎるかもしれませんね」
責任者が言った。
「そう思います。今回の項目が本当に必要かどうかも、試行の結果で確認したいです。代理対応や入力時刻の違いがほとんど発生しないなら、別の方法で記録できるかもしれません」
「では、発生した回数と、追加記録にかかった時間も確認しましょう」
レイヴンは、その内容を作業計画に加えた。
彼は、様式を完成品として扱うことを避けていた。
現場で使う人にとって負担が大きすぎれば、記録が形だけのものになる可能性がある。反対に、簡単にしすぎれば、後から必要な情報を確認できなくなる。
どこまで記録するかは、実際の利用状況を見ながら決める必要があった。
同じ日の夕方、女性運営責任者は、権限見直しの試行に関する初期報告を受け取った。
報告によれば、申請者が記録の利用目的を明記するようになったことで、情報管理部門からの問い合わせは一部で減っていた。
一方、複数の目的に同じ記録を使う申請では、記載内容が長くなり、審査に時間がかかるケースも出ていた。
彼女は、報告担当者に尋ねた。
「時間が増えたケースでは、どの部分に時間がかかっていますか」
「主に、申請者が利用目的を具体的に説明する部分です。従来は『業務改善のため』と記載すれば申請できましたが、現在は、何を改善するために、どの情報を使うのかまで書く必要があります」
「その説明は、申請者が最初から書ける内容ですか。それとも、確認担当者から質問されて初めて整理できる内容でしょうか」
「両方あります。申請者が用途を明確にしていない場合もあれば、用途は決まっていても、必要な情報の範囲を説明できていない場合もあります」
女性運営責任者は、報告書に目を落とした。
「では、申請書の説明欄を増やすだけでは解決しないかもしれませんね。利用目的の例を示すなど、申請者が最初から整理しやすい方法も検討してください」
報告担当者は、次回の会議までに改善案をまとめることになった。
会議が終わったあと、補佐役が彼女に声をかけた。
「試行を続けると、確認項目が増えていく可能性がありますね」
「ええ。必要な項目を増やすことと、手続きを複雑にすることは同じではありません。何のために確認するのか、どの程度の情報があれば判断できるのかを、毎回考える必要があります」
「簡略化できる部分もありそうですか」
「あると思います。ただし、簡略化した結果、後から確認できなくなる情報がないかは見ておきたいですね」
彼女は、初期報告に記された審査時間と、問い合わせの件数を見比べた。
数字は、手続きの変化を示していた。
しかし、その数字だけでは、確認の質が上がったかどうかまでは分からない。問い合わせが減ったのは、申請内容が明確になったからかもしれないし、申請者が必要な説明を省略するようになったからかもしれない。
彼女は、次回の報告では、実際に審査された申請の内容も確認することにした。
その夜、レイヴンはオンラインの相手にメッセージを送った。
《今日は、点検記録に例外の項目を追加した。代理の人が判断した場合や、点検した時刻と入力した時刻が違う場合の記録だ》
返事が届いた。
《例外を全部記録しようとすると、普段の作業が大変になりそうだね》
《そうなんだ。必要なものだけ残したいけど、必要かどうかは実際に使ってみないと分からない部分もある》
《それなら、試した結果も記録しておくと、あとで減らす判断ができるね》
レイヴンは、その返事を読んでから、作業用の資料を保存した。
今回の変更によって、記録できる情報は増えた。
しかし、それが最終的な形になるとは限らない。
実際の作業でどのような例外が起き、追加の記録がどれほど役に立つのか。
その結果を見てから、残す項目を決めることにした。
