「作業ミスは責めないけどミスの原因と特定して本番の作業に臨もうぜ。」とワタシは何十回と言っただろう


昨日の残業100時間越えのプロジェクトチームを残業ゼロに変えた7つのことで、チームの仕事の仕方を変えて残業を一掃したことを書きましたが、そのしてきたことは1回メンバに教えればすぐにやってはくれますが、頭の中の理解と実際に体を動かしてやってみると頭の中の理解と体の動作が一致するまでズレでしまって上手くいかないものです。


やろうとしていることと実際の結果として頭の中の理解と体を動かした結果は、作業のミスとして現れます。メンバは一人ひとりスキルレベルも性格も違うので作業ミスの程度も軽度のものから重度のものとメンバの数だけ様々です。そうした事象を見てどうするか。どうやってメンバの作業ミスをカイゼンしていくか。それを考えながらやらないといけません。


プロジェクトマネージャの本分をおさらいする
プロジェクトマネージャの本分は、納期までに顧客の要求品質のdeliverableを届けることです。

「顧客が求めるdeliverableを期日に納める」


たったこれだけ、なのにチームのメンバもプロジェクトマネージャも大変な思いをしてdeliveryしているチームもあるんです。


「いや、おまえだって大変だったんだろう?」って思うかもしれないですが、大変だったかどうかと言えば大変だったし、そうでもないよ、だったし。どっちにしても、いや、そうした大変とそうでもないの混ぜこぜが正直なところなのかもしれないですね。そしてそれを少しだけ上回る大変さの中に大変さをゲームに変えるだけの余裕を持っていたことが、その大変さを楽しみとして捉えてしまう自分の適当なな性格に少しだけ呆れるというか、歳を取ったんだなぁ、と終わってみれば感嘆するほかないわけで。


作業ミスはプロセスのミス
メンバが作業ミスをした間違いの原因分析をしてもらうと、すぐに原因のようなものは誰でも抽出してもらえます。それは、

「担当者が作業を理解していない。」
「手順が間違えている。」


の2つです。この2つは間違いではないと思うのですが、ワタシは前者の「担当者が作業を理解していない。」がまだ原因には辿り着いていないと思うのです。それは何に引っかかっているかと言えば、作業ミスの起因が本当に「作業担当者の理解だけでいいのか?」ってことです。

作業ミスをする ← 担当者が作業を理解していない ← 作業の何を理解していないの? 


ふりかえりで「作業ミスは作業者が作業を理解していない」の様なproblemを出してくれる場合、出してくれたメンバに一つ質問をすることにしています。「作業手順書どおりにはやったのか?」と。「やった。」と答えるなら、それは「手順が間違えている。」わけです。そうとするなら「担当者が作業を理解していない。」に振り分け直されるです。


でも、その「担当者が作業を理解していない」も、何を理解していないのか?に興味を持つんです。作業の何を理解していないのか、って。若しかしたら、こういうことじゃないですか?

「作業担当者は、作業ではどこのシステム環境で、どんな作業をすると、どういう結果となるのか、そうした作業の目的とその作業をしたことで期待する結果は何であればいいのかを理解していないのかも。」


若しかしたらこうかもしれません。

「作業担当者は、作業のシステム環境、作業、得られる結果そして作業の目的も理解している。でも作業を間違えた。」


前者と後者では、その後の対応が違います。後者は場合によっては、最初の「手順が間違えている。」の対応になるかもしれません。

作業ミスをする ← 作業者が作業手順書どおりにやっていない 
        ← 作業者が作業手順書を理解していない ← 作業者のスキルが足らない
        or
        ← 作業を理解しているけれどそのとおりやると間違える ← 作業手順が間違っている
        or
        ← 作業を理解しているけれどそのとおりでは手順が足らない ← 作業手順の記述が足らない


「担当者が作業を理解していない。」は3つに分かれたのですがそのうちの2つのカイゼン対象は手順書なので1つに見えるかもしれないけれど、やる対処が違います。ここをきちんと押さえないと明後日の対処をしかねません。


それより、本当に「担当者が作業を理解していない。」なら、これは急いでメンバをプロジェクト内教育をするか、メンバの入れ替えを判断しなければなりません。プロジェクトは人的リソースが進捗を左右するのでとてもリスキーな話にクラスチェンジしかねません。こうしたところに本番環境での作業ミスの芽が隠れているのです。