エンジニアが感じるプロジェクトのムダはエンジニア自身が作り出している

「このエビデンスの整理の作業がすごいムダなんですけど。」
「はい。」
「どうにかならないですか。」
「ワタシとしては、試験結果のエビデンスは、試験仕様書と紐付けできるように分類したうえで確認されていればいいのだけれど。」
「すごく時間がかかるんですよ。」
「そのエビデンスの整理の作業は誰が段取りを作ったのかな。」
「Aさんです。」
「で、Aさんとか、その作業に携わるメンバでそういった“実際に作業をしてみた結果”をフィードバックしたのかな。」
「えー、してないです。」
「ワタシの要求はさっきも言ったけれど“試験仕様書と紐付けできるように分類したうえで確認されていればいい”んだよ。それ以上は望んでいないよ。」
「？？？」
「その作業のインプットとアウトプットの仕様は決めるけれど、−それはアウトプットの仕様が別の世界で決められているからね−、変換するプロセス、つまり箸の上げ下げまでは決めていないよ、ってことなんだけれど。」
「希望を言わせてもらうなら、“一番少ない手数で”要求する品質を確保してくれるとうれしいなぁ。」
「？？？」
「手段は問わないよ。みんなが一番楽なやり方でいい。でも、要求した仕様は守ってね。」
「じゃあ、みんなで見直します。」

割と一度決めたプロセスに対して、それを守らないといけないと思ってしまう心理が働くようで、一度決めたプロセスよりもっと簡単だったり、楽ちんだったりすることを思いついても“今のプロセス”を頑なに護ろうとするエンジニアが多いのは、プロセスを順守するということにかけては一定の作業品質を確保できるという作業の標準化の観点でとても助かります。

プロジェクトを構成するメンバの経験が多様であるとき、メンバひとり一人の作業の品質のレベルを合わせることがどれだけ大変かは経験した人でないとわからないものです。

ただ、自分たち若しくは程度はあるにしても決められた作業手順がある場合、それが合理的でないと感じるならそれを変える行動が必要だと思うんです。その点で言えば、先のエビデンスの整理作業がムダだ、と思って相談に来たエンジニアは、現状を良しとしない、もっと楽なやり方があるはずだ、と思い伝えてきた点でとても良い行動だと思います。その対象が自分たちで決めたプロセスはもちろん、外部から作業標準を決められている場合であってもそれを変えることで得られるメリットと続けるデメリットが明確なのであれば、それをベースに会話することができるのですから。

でも、ちょっと待って♡
でも、ちょっと待ってください。そのプロセスはだれが作りこんだのでしょう。

そう、プロジェクトのメンバ自身が作り込んでいるんですね。そうしたケースはよくある話だと思うんです。じゃあ、そうならないように「見てあげたら？」っておもかもしれないですけど、作業の一つひとつまで、箸の上げ下げまで「こと細かく決めて欲しいですか。」って思うんです。

ワタシは嫌だなぁ。

統一した手順として必要なことが必要な作業なら決めておくでしょうし、そうした決めておかないといけないようなものは、手続きのワークフローとして決めておくモノのレベルなのではないか、と思うんです。

だって、そこがプロジェクトのメンバでありエンジニアとして工夫出来るところでしょうし、自分やメンバの業務を設計できる唯一の経験を得られるところなのだと思うのです。

と思うからこそ、自分の身近なプロセスの設計は誰かに委ねるのではなく、自らがイニシアティブをもって裁量としてとるのが良いことだと思うんです。

自分のプロセスやチームのプロセスに疑問を抱くということの意味
その観点から、自分の作業やチームの中でのプロセスがあるとするなら、いや、あるんですけど、それがいつまでも同じでは“オ・カ・シ・イ”と思っておく必要があるのです。

もっと、楽な方法があるはずだ。
もっと、短時間でできる方法があるはずだ。
もっと、早く帰れるやり方があるはずだ。

楽をするために、思考を費やすことは決して悪いことではないのです。試行錯誤することも同じです。自分が楽をできるということは、それをチームで共有できれば、チームが全体で楽を享受できるということです。

エンジニアには、自分を、チームを楽にも大変にもできるforceを発揮できる場を持っています。作業を大変にすること、作業の段取りを大変に作り込めるならそれは“ムダ”を自ら拵えているということ、でもあるんです。

なら、それに気付いたのなら、それを取り除きましょう。だって、楽になれるのですから。