エンジニア自身が説明できなければ成果と呼べない

同じ担当チームのエンジニアが終わったから見て欲しいと言うのでレビューをすると一見良さそうな成果物があるきっかけを境に「なんじゃこりゃ」となってしまう。

そのエンジニアには、過去の作業のリポジトリと言うかまとめたものがあって自分で作業した結果が客観的に外れていないかを確認することができる。もちろん、ググって情報を集めて自分の判断を下すこともできる。

仕事にアサインする際にも、局所的な作業手順は後回しに全体の作業の流れ、作業のポイント（外してはいけない考え方）を繰り返し説明し、仔細なプロシージャを実物をハンズオンしながらスキルトランスファーしている。

ところが実際に起きているのは、そういった勘所の意思決定で外してはいけない考え方をわざわざ踏むのである。

これを見抜くのはとても簡単で、意思決定したところの根拠を説明してもらうことで判別ができる。

インプットがこれとこれで、評価基準がこれだから、結果はこうなった、と説明してくれれば結果が間違っていたとしても、インプットの不足なり、評価基準の捉え方なりを修正すれば良いので軽傷で済む。

ところが、説明できないとこれは次元が違う。説明できないケースでは、自分がそう思ったから、と言う意思決定の再現性がない判断方法を返してくる。これでは判断する基準に合致しておらず説明になってもいないので、どうしようもない。

エンジニアが担当した成果物は、エンジニア自身が説明できなければ成果と呼べない。

こうしたことはシステム開発の仕様の設計やコードのデザインでも同じである。何をインプットにして、制約を受ける様々な条件を並べた上で、処理を並べて、アウトプットする。ロジックを構築する際のロジックの作り方が自分なりに構築出来ていないのかもしれない。

エンジニアの仕事も様々で、全部を経験しているわけではないのだから、先行して作業しているエンジニアやリーダやマネージャに聞けばいい。忙しそうだからとか時間をとって悪いからと変な気を使って成果になっていない成果物を作られるより、こう作るがいいかとか、最初の１つ、２つを見て欲しいとかいってもらった方が何倍もいい。

何がいいかと言えば分かりきっていることは、手戻りのインパクトが小さくて済む。もう１つは、どう作るかが予めわかるので、やばさ加減とかどこでポーリングすればいいとか、レビューするときの不安材料が少なくて済むことだ。