作業計画書について

　数年前まで、弊社では作業計画書は必須ではありませんでした。
　リリースを行うベンダーや作業者側では、本番リリース作業を行うときには作業計画が必須となっています。ここまで来るには、結構長い道のりがありました。。。

きっかけは世代交代によるミス続発

　きっかけは、作業を行っている部門や、委託しているベンダー側で世代交代があり、作業ミスが頻発したことです。
　おそらく今までも起きていたのだとは思いますが、起きた時に熟練者が大きな事態にならないように何とかしていたのでしょう。

　このままではいけないので、それまでのミスの分析を行い、作業計画や、運用作業の手順化を行うことになりました。

導入当初の反発

　これは、最初のうちは不満ぷんぷんでした。もともとこういったことをやっていなかったのですから、とくに最初のうちは工数も上がりますし確認手順も増える。しかも、熟練者ほど、決められた手順通りにやらずに手間を省こうとしてミスが露見するといった事象が発生しました。

　つらかったのは、尊敬している先輩エンジニアの方から、「何かあったときにはその場の判断なんだ、ここまで細かいことを書いたってそのとおりにやる保証なんてない、計画なんかに頼るな！」と怒られたことです。

なんというか、全否定。

ここはもう、その方がお辞めになるまで理解して頂けませんでした(..)

事故対応フローの見直しと体制変更と

　そんなこんなでスタートしたものの、しばらくはチェックは形骸化されていました。社内作業だと「前日夜に承認を投げて事後報告にする」なんてワザも公然と使われていたりもしました。しかも、何事もなく承認されてるし！

　承認したマネージャーの方と話しましたが、「作業計画を作ること自体が大事なんだ。だからこれでいい」というお返事で。なんだそりゃあ。。。

　とりあえず、現場の文句はおいておいて、管理者側では、事故が続いていたので、分析と改善案についてディスカッションを続けていました。
　すべての事故報告について、作業報告をチェックして改善ポイントを確認するといったことをやるようになったのです。

　分析を行っているうちに、一部チームで、小規模の作業で、作業計画通りにやっていなかったり、作業計画で詳細に決めていない箇所で問題が発生していることがわかりました。
　結果、下記のような改善を設けました。

・ベンダー内で、機能リーダーの内部承認フローを設ける
・ベンダー内の管理者への報告を義務付ける
・システムマネージャーには前日までに承認依頼が届くようにする

　双方のレビューやチェック体制を見直したことで、ミスは激減したのです。

フローや体制の見直し

　上記とあわせて、社内作業についても承認や確認フローなどの見直しを行っていきました。
　結果、上の事後報告を承認したマネージャーは交代になりました。それだけが理由ってわけじゃないんですけど、まあちゃんと現場を管理できる人がやりましょうよってことで。

　そんなこんなで、手当を始めてから２年が経過。以前は３日にあげず発生していた事故報告が、２～３週間に１回という頻度まで減りました。

　さらに、作業計画があると、やはり引継ぎがやりやすい。業務の見える化というのは、やはり大事だなあと思っています。