まずは自分を疑え

私は大学を卒業してから10年ちょっとの間、ITエンジニアとして働いていました。
お客様の要望を聞いてシステム全体の設計をする、みたいなこともやっていましたが、基本的にはキーボードを叩いてプログラムを書くのが私のお仕事でした。

そんなことをしている中で学んだことはたくさんあるのですが、今回はその中から

うまく行かない時は、他人を責める前に自分に非がないか何度もチェックせよ

という教訓をご紹介したいと思います。

システム開発は分業制

ある程度以上の規模になると、システム開発は分業制になります。

たとえばオンラインバンキングで定期預金を申し込む

1．金額と預入期間を指定して「申込」ボタンを押す
2．「この内容で良いですか？」という確認画面を表示し、そこには金額と期間に応じた利率が表示されている

という機能を開発するにあたって、Aさんが画面周りを、Bさんが利率の計算処理を開発するとします。

Aさんは利率の計算方法など知らなくても、Bさんが作ったプログラムに

・ユーザの情報（優遇金利の情報とか）
・画面に入力された金額と預入期間

を伝えれば、利率を教えてもらえる。あとはそれをそのまま画面に表示するだけ、という役割分担です。

で、このBさん作の利率計算プログラムを使って

「なんか利率の数字がちゃんと計算されてないんだけど」

ということが起きた場合に、Aさんとしてはどう振る舞うべきかという問題です。

やりがちなこと

やってしまいがちなのは

「Bさんのプログラムが挙動不審なんだから、Bさんに聞こう」

です。
そして実際にそれをやると、多くの場合、Bさんはこう言うのです。

「それ、使い方が悪いだけですよ」

たとえば、定期預金は10万円以上でなければ利率が計算できないが、1万円で計算せよと指示を出していた。

たとえば、1年未満の預入期間は1か月、3か月、6か月しか許されないのに2か月で計算せよと指示を出していた。

たとえば、もっと単純なミスでユーザ情報を伝え忘れていた。

そしてBさんに「お渡ししたマニュアルに使い方書いてありますよね。読んでください」と呆れられるのです。
他人の非を指摘したはずが、実は非は自分にあったのだということで、Aさん、なかなか気まずい。1回や2回ならともかく、これが何度も続けばBさんの心証を悪くする恐れもあります。

これは私の実体験。
Aさんの立場でも、Bさんの立場でも、何度も経験したことでした。

まずは自分がポンコツである可能性を疑え

そうこうするうちに、人は学習するのです。

「人に聞くのは、自分の使い方が悪い可能性をすべて潰してからだ」

と。
もちろんBさんのミスで、提供された利率計算プログラムがバグっている可能性はあります。

が、まず考えるべきは他人がミスした可能性ではなく、自分が何かを間違えている、見落としている可能性です。そして、往々にしてそっちの方がよくある。

無駄に問い合わせてBさんの時間を奪って全体の効率を悪くしないためにも、人間関係を損なわないためにも、あらゆる事象についてまず自分がポンコツである可能性を疑え。

それがITエンジニア時代に学び、今も心掛けていることだったりします。