エンジニアが作業手順書で良かれと思ってトラブルを起こさないために

過日、プロジェクトの関連する別プロジェクトで大規模なトラブルがあったと情報共有が入ってきて、ざっと斜め読みして最初に思ったことは、これ、ワタシのプロジェクトでもやるかもしれないな、と言うことです。

なぜワタシのプロジェクトチームもやるかもしれないと思ったかと言えば、プロジェクトチームのメンバを信用しているしていない、の話ではなくて、どちらかと言うと、斜め読みしただけでも原因の本質をワタシなりに突き止めたから、です。

大規模なトラブルの概要は、“手順書に記載のないこと”を「(こうしておいたらいいかな。)」という他愛のない思いつきでやってしまったのです。勿論、他愛のない思いつきっていうのはワタシの想像の域を出ていませんけど。でも、これ、意外とやっちゃうんですよね。プロジェクトマネージャから言えば、他愛のない思いつきなんて余計なお世話なんでやってくれるな、ですが。でもやってしまったエンジニアからしたら、エンジニアの自己満足としてだったり、自分の好みに合わないとかも含めて、兎に角、手順書にないことをやってしまうんです。

でも、不思議と、本番システムでもやってしまうんですね。ワタシにとってはそう思う気持ちは謎、ですけど。

手順書はなぜ作るのか
手順を作る目的は、作業のスキトラだったり、作業の標準化だったり、手順の確立だったりで、その利用目的応じて違うものです。それはそれで当たり前なんですが、じゃあ、そうした目的で作った手順書どおりに現場でやらないのはなぜなんでしょう。

作業の手順を間違えないように作ったはずの手順どおりに行かない、記載に漏れがある、記載以外の画面が表示された……。そうした手順書自体に問題があるかもしれないし、ホントにエンジニアの余計なお世話の思い付き、かもしれないです。

何れにしても、その手順書を使ってみたら違ったから、とか、やっていいことといけないコトが明確になっていなかったから、とかなのかもしれません。

手順書に求める精度
手順書を使ってみたら違ったとか、そうした本来の手順書に記載すべき作業の手順を記載するための精度を上げるにはどうしたらいいでしょう。

それは、一つしかないですね。実際、作った手順書をテストする、です。適用する環境と論理的に同じ条件下の環境で、そのテストの対象となる手順書どおりにいくか、検査するしかないですね。それで、どういったシナリオで進めるのか、多くの情報を表示する画面でどこだけの情報を認識してどこの情報を更新していくのか。又は、それ以外は操作してよいのかどうか、とか。

手順書のテストは、作成者以外がやらないと見慣れている画面の機能を操作していいのかしてはいけないのかは分かりにくいです。普段から目に触れているエンジニアより、慣れないエンジニアの方がテストの向いているんです。

手順書の本当の意義
手順書の本当の意義、目的は何でしょう。それは、誰がその操作をやっても結果が変わらない、ということを確保することです。ポイントは、誰がやっても、です。前提知識である程度操作するのがエンジニアであることのハードルを設けるかもしれませんが、それでもエンジニア自身が千差万別は語る必要もないことで、そうした色々な技術背景を持ったエンジニアでもその手順書どおりに作業をすることで一定の作業品質を得るために必要なのです。

手順書の暗黙の意義も明示的にする
手順書にはもう一つ、明示的にされない意義があります。それは、手順書に“記載のない操作をしてはいけない”と言うことが暗黙にあるのですが、それは割と誰も気づかないし、誰も共有しないんです。

手順書として大事なことは、記載のないことはやってはいけない、と言うことに限ります。

だから、想定外の事態を防ぐために、手順書そのものをテストする必要があるし、テストは論理的に同じ環境下でテストをする必要があるんです。これでは手順書一つ作るのにコストがかかり過ぎる、と思うかもしれないけれど、実際の作業で“トラブルを起こしてその後始末までのコストを掛けるより何倍も安上がり”なのです。

ですから、実際の作業でそれでも想定外のことが起きたら現場の判断はさせてはいけなくて、その時点で作業を止めさせて、バックエンドの技術サポートにフィードバックして、第三者として冷静に判断できるエンジニアが解析や今後の作業について主導権を持たないといけないんです。