確認者は確認できる知識とスキルが必要

IT業界に入った年、会社の部門の戦略的に「ひとつのプロジェクトでじっくり育てる」のと「いろいろ動かして経験を積ませる」と、人に応じて２種類の育て方をしていた。私は後者で、１年目の新人研修と部門研修の３ヶ月半を抜いて、５つのプロジェクトを経験した。言語はCOBOLばかりだったが、表記が決まり切っていると思っていたCOBOLでも、若干書き方の差違、特にPERFORM文の表記はプロジェクトごとに特色があったのが印象に残っている。

その４つめのプロジェクトだったか。どこかの会社のシステム部門のＰＧを担当し、作成してテストして納品したが、先方の役付に呼ばれた。
「こんなコードが動くか！」とのことだったが、PERFORM文の書き方がちょっと違ったらしい。しかし、こちらとしてはテストもしているし、バグも出ていなかったのに、だ。特にコーディング規約があった訳でもない。が、コードだけを見て責められた。

これは、私の記述方法で動くことをその方が知らなかった、ということなのだ。
怒られた時点で「この人、こういう書き方知らないんだ」と思い、敢えて「これで動きます」と言わなかった。彼にそんな知識を与えるのが癪だったから。

その彼は
・動くのかどうかの確認
・動くのなら、既存COBOLと表記が違うので変更の指示
が必要だったのではないか。そうすればこちらも歩み寄れたに違いない。

上の立場で物事を確認し、判断する場合、確認できる知識があるに越したことはない。しかし、特に昨今は技術の動向は非常に速いこともあり、技術的に知らないことが合っても仕方がない。プロジェクトの目的は知識自慢ではなく、システムで提供しようと計画したモノをきちんと提供することである。
そのためには、知らないことは確認し、それに問題がないかをチェックできるスキルが必要だろう。