原因の混入を自分で作っているということに気付かないエンジニアに信用はおけない

「この仕事、どのくらいでできますか。」
「3日掛かります。」
「じゃあ、作業のパートで分担するなり、二馬力にするなりしましょう。」
「一人でないとできません。」
「？？？」

(おかしいなぁ、この仕事初めてじゃないんだけどなぁ。単純作業のハズなんだけどなぁ。)

「ちょっと、どういった段取りで仕事をしているか教えてくれないかな。」
「1番目に……、2番目に……、3番目に……して1番目の……、4番目に……して1番目の……。」
「ちょっとまって。」
「このやり方でいいと思ってやってる？」
「はい。大変ですけど。」

そのまま書けないんでぼかして書きましたが、大元のデータを作るときに自信が持てないからあれもこれも根拠なく取り込んでいて、それを次工程に移しながらちょっとずつ精度を上げようとしていたらしい。

こうした一つひとつの作業のしくみを設計する能力はエンジニアに必要なのだと思っているんだけれど、この担当エンジニアにはそうした業務を設計する能力が全くないらしいと分かった。

「え？手順を作っているじゃないか。」だって？いや、おかしいでしょ。何をインプットにするか、そのインプットとするデータの確からしさをきちんと定義できているかどうかも自分で設計できないんですよ。インプットとなるデータが確かでないものをインプットにするなんて、なんて馬鹿らしいことか。そんな業務設計をされて、その業務をいやそこまで大げさに業務と言わなくてもいいけれど、少なくとも自分が行う業務はアウトプットさえ合意すれば自分で好き勝手に変更できるのに、自分で作った業務が自分の手数を増やしているにもかかわらず、変えようとしないなんてとっても可笑しい状況で、それを変えようとしない感覚がワタシとはズレまくりなんですよ。

さらに、自分で大変だ、と思うなら、誰かに雑談風に相談してみるくらいできるじゃないですか。「ねぇ。これ、すげー大変なんだけど、どうしたら楽にできる？」って。そうしたら、だれでも、「手順教えて。」って聞くでしょう。

おおげさじゃないですが、この手順を聞いて2分で「はぁ？」って目が点になりましたね。一緒に聞いていたリーダも同じでした。リーダが割ってあるべき正論を言い始めようとしたので、「ちょっと待って。全部、ゲロさせろ。」って思わず言っちゃいましたもの。

これは、エンジニアが自分が振る舞うことに何も疑いを持つことがないというある面を写しているのではないかと思ったんですね。これでは、自分でバグを見つけられない、このエンジニアは。そのエンジニアに対する品質の期待値はゼロに再評価しました。つまり、アウトプットがそのエンジニアでは品質保証を得られない。なので、そのエンジニアのアウトプットは、他に人に再鑑させることしました。

エンジニアは自分のする業務を設計する能力が必要です。そして、その業務をカイゼンすることも必要です。まして、自分が見積もった以上に時間が掛かっている場合、仕組み自体か、使用しているデータがおかしいんです。だから、何度も作業を繰り返したりするんです。

エンジニアは、原因の混入を自分で作ってい無いかを何時も気にかけていないといけません。