読者です 読者をやめる 読者になる 読者になる

判断がブレるエンジニアはwhyが足らない

例えば、インプット情報があって、判定基準があれば、そこから導き出されるアウトプットは毎回同じになるはずです。

ところが、そういう仕組み、導出の仕方のルールがあるのに毎回違う結果を出しくるエンジニアにときどき遭遇するのです。

「いやいやいや、待って。この判定基準もあなたが設定したのでしょう。それなのに、なぜ、毎回判断を変えるの」

とまるで笑えないコントに付き合わされることになるのです。どう考えたらそういう考え方ができるのか不思議でしかありません。

客観的に見えていること

そうしたアウトプットを出すエンジニアは、判定基準、言い換えると意思決定のプロセスを通す度に違う結果を作っているように見えます。

処理のプロセス、ロジックを作る目的は、どのような情報がインプットされても、同じルールにより判定することで、同質の情報については同じ処理をすることで同じ結果を得たいためです。

当たり前ですよね。

ところがブレるエンジニアは、そうしたルールを自分で作ったとしても、外観からは、インプットする情報を元に、毎回、新規に判定基準を作り変えてアウトプットしているように見えます。

どうしてそのように見えるかというと、アウトプットがどうしてそのようになったか説明を求めると、インプットとなる情報から説明を始めるためです。インプットの情報が「○○だから」とインプットとなる情報を判断の主体として話すのです。これは、判定基準である判断条件を基軸に思考していないことの証左ではないか、と思うのです。

whyが足らない

毎回、突飛なアウトプットしてくるエンジニアには何か別の次元での思考があるのではないか、若しくは、処理のプロセスでルールを使わずに別の意思決定のルールを持っているのではないか、と思わざるを得ません。

さて、どうして何を考えた結果、ブレているのか。

思い当たったのは、なぜそれを処理するのか

「作業を始める際の目的、whyの認識が足らないのではないか」

とうことです。単純にルールに沿ってインプット情報を判定することが作業の目的である、と認識できれば、それ以上でもそれ以下でもない目的に沿った結果が得られるはずですから。

ブレないようにできるか

こうした思考をするエンジニアをブレないようにできるかどうか。経験値の中ではかなり難しい、と思うのです。実体験で観測した範囲では。

多分、同じチームでいるときに一番困るのは、毎回判断基準を作り直すために結果がブレているときがあるが、それが予測できない、ということです。

予測がある程度できる、このエンジニアはこうした結果を出す傾向がある、とするならば、それはその範疇だけをフォーカスしてウォッチすればいいのです。

ところが、軸のないエンジニアは、それが読めないのです。そうすると誰かが全部チェックしなければ、異常を見逃してしまう危険があり、品質が得られないということになります。

こうしたエンジニアを使い続けなければならないとき、作業を単純作業にして渡す他、対処の方法はありません。