その用語が何だろう…と思って、ググることはよくある。意味を知らなければ何を言っているのか理解できないから。
そういえば、ちょっと前に下記のような記事を見かけた。東洋経済のサイトでの記事だ。
ちなみに、「ググる」に関しては、下記のような記事もあったりする。
こちらはプレジデントオンラインの記事だ。さて、別にこれらの記事は矛盾していることを言っているのではない。単に考え方だ。闇雲に調べても正しい答えは得られないということであり、別に調べることが悪と言っているわけではない。
「分からないものは調べる」は技術系の人間にとって基本だと思うのだが、そうでもない人たちもいるのだ。私もこんな風に言ってはいるが、興味のあること (や、業務を進めるために必要なこと) 以外は積極さが劣る。面倒くさい！ と思ってしまうのだが、これは仕方のないことかもしれない。でも、お金もらってやる仕事が面倒とか、プロ意識がないとしか…と個人的には思うのだけれど。
業務でトラブルが発生した時、こういうことが起こってエラーになっているのだろう、とまずは推測 (仮説を立てる) する。ログやプログラムのソースコード、仕様書などを読み、仮説通りなのか検証する。違っていれば見直す、というようなことを自然にやっていると思う。
ところが、十分に検証を行わずに、過去の経験から判断してしまう事例をつい最近、複数体験した。
ん？ なんかおかしい…本当に原因として報告してもらっているものは正しいのだろうか。自分の考えと異なった見解が出た時、自分とは、どこが、何が違うのか、それを確認したいと思ったことが発端だった。論理的に過不足なく説明できるのか、それを確かめたかった。
実は、その件は根本原因まで突き止められなかったのだが、それでも当初の原因として報告されたものが誤っていたことが分かった。原因を解消するために間違った方向で解消していくような無駄な対応が避けられたのは幸いだった。
ちなみに、私は調査の途中経過などをアウトプットとして報告用のチケット (業務の Web 上の報告書みたいなもの) に度々書き込んでいる。記録をとることで、どこで何を間違えたのか後からわかるようにするためだ。
当の担当者は結論しか書かない。なので、第三者がそれを見て、何故その結論に至ったのかが分からない。今回も、どうしてそういう結論に至ったのかをヒアリングしたところ、説明がつかないものが出てきて、結論が矛盾していることに気づけたのだ。
結局、ん？ 何これ？ と気づけるかどうかなのだが、自分で報告用の説明を書いていると、私自身は、何かおかしいということに気づく。なので、途中経過や記録を取るように勧めているのだが、どうも苦手な人は本当に苦手なようで、週1回のチケットの更新すらもやらない…なんてこともよくある。以前は、結論だけ書けばよかったので、どうもしっくりこないようだ。