再発防止策には「べからず」集より「開発プロセス」の見直しを

エンジニアに関わらず何か作業ミスがあると、やれなぜなぜをやれだの、再発防止策はどうしただのと、面倒なことばかり要求します。そうしたことを真面目に要求しているなら作業ミスをした真の原因を見極めたり、再発防止策の効果を検証したり効果測定まで求めて再発防止策の有効性を確かめるまでがお仕事になるはずですが、そのあとのモニタリングなんて求めませんから、形だけだけなんだとすぐにわかってしまうのです。だから、策を作る方も…以下略。

「べからず」集で作業プロセスを見直してはいけない

何かの作業ミスがあり、それが甚大な損害を与えてもべからず集で作業プロセスを見直してはいけません。

当たり前です。

例えばコード設計を上流設計でするときに、コード値とコードの意味合いをピンポイントで設計するかという話です。いきなり、「3＝○○エラー」だけを定義するかといえばそんなことはしないです。コードの取りうる値の範囲とそれ以外を定義して、取りうる値を個別に定義するものです。そうでなければ「3」以外のときの対処に困るからです。

「こうしましょう」では強制ができない

べからず集ではケースの抜けがあるなら、「こうしましょう」でいいじゃない、と思うかもしれません。というか、思いましたよね、ね。

「こうしましょう」は例えばチームの中ではどれだけ強制力があるか曖昧です。チームのメンバは必ず守らなければならないものなのでしょうか。それともできる限り守ってね、なのでしょうか。

確かに、ホワイトな職場で仲良くチーム運営をしましょうという方針であれば、ソフトな言葉で言っているだけで実際は守らないとやんわりと窘められるかもしれませんが。

作業プロセスを見直すチャンス！

今、作業ミスをしたために何かしら再発防止策を打たなければならないのであれば、それは現行の作業プロセスを見直すチャンスです。

今までなんでこれをやっていたのか意味がわからなかった作業までひっくるめて再発防止策を大儀に見直せるチャンスなのです。

作業プロセスは少なくとも初期の頃に想定して設計したとしても、実際のプロジェクトが進捗し、メンバの特性がわかってくると細々と運用で回避しているものです。

そうした明確なプロセスとして定義されていないもののうち、作業プロセスに取り込むことで、メンバ全員がそれを実行することを前提とした方がコンテキストを高めてより高い次元から会話を話すことで意思疎通を効率的に進めることもできます。

逆に、メンバの意思疎通が思ったより取れていないくて、作業品質も低ければ作業プロセスを一段と仔細化することで確実に作業のチェックをできるようにゲートウェイを儲けることもできます。それも慣れて確実にできるようになればチェックポイトを一段上げれば（元に戻せば）いいだけです。