エンジニアとして仕事を始めて、そろそろ2年が経ちます。
今回は、これまで2年間エンジニアとして仕事をしてきて、エンジニアが「なんとなくこう思います。」と考えることは、致命的なバグを引き起こす。ということを身をもって知ったので自戒がてら書いておこうと思います。
エンジニアの「なんとなくこう思います」は、バグの温床
エンジニアが仕事の中で遭遇する「なんとなくこう思います。」には、以下のようなものがあります。
なんとなくこう思いますの具体例
・エラーログを読んで、原因ははっきりとは分からないけど、なんとなくこんな感じの問題が起こっているっぽいと判断。
・「なぜAという実装方法をとったのか、なぜBの書き方をしなかったのか？」と聞かれ、「なんとなく、Aの書き方の方がいいと思ったので。」と答える。
・自分の実装箇所のコードを読む際に、「なんでこの書き方になっているか？」を考えず、「こんな実装になってるんだな〜。」となんとなく読解し、わかったつもりになって実装を進める。
・会社内で上司とのキャリアの話になって、「〇〇はどんなキャリアを描きたいんだ？」と聞かれて、「特にないっすね〜。」となんとなく答える。
これらが仕事上で生まれてしまう、「なんとなくこう思います。」たちです。
普段特に意識せずに仕事をしている自分ですが、今日仕事をしていて緊急で対応するべくエラーに遭遇し、そのエラーの調査をして、そのエラーの原因を上司に報告する際に、「なんでそう思ったの？」「こういう可能性もあるよね？」「問題の切り分けできてる？」と問われ、明確に調査結果の根拠を示すことができませんでした。そこで、「自分って、なんとなく。で仕事を進めることがめちゃくちゃ多いな！」と気付くことになりました。今振り返ると、なんとなくで思考・行動を決めてしまうことが多い結果として、後々考慮してなかった問題が発覚してその対応にめちゃくちゃ時間を取られたり、同僚・上司に自分の行動・思考の説明を求められても合理的な説明ができず、「多分そうだと思います！」という説明しかできないことが多いなあと...。
そんな日々を送っている自分に気づいたわけですが、そもそもなぜ「なんとなくこう思います。」の思考の癖がついてしまったのか？
原因を考えてみると、以下の3つの大きな思考習慣があることに気付きました。
❶帰納的に物事を考えて、仮説を真実として思考を進めてしまう。
❷どこまでが仮説で、どこまでが確からしい真実なのか分けられていない。
❸「なんとなくこう思います。」がヤバいことを自覚していない。
これだけではよく分からないと思うので、それぞれ具体的に説明していきます。
❶数値を伴わず帰納的に物事を考えて、仮説を真実として思考を進めてしまう。
自分は物事を考える時に、帰納的に考える癖があることに気付きました。具体例として、日々の生活でのシーンを挙げると、「カフェに行ったら作業に集中できることが多い気がするから、カフェに行って作業しよう。」みたいな考え方をよくします。その考え方をする時に、「カフェに行ったら4時間作業できて、家で4時間作業する時に比べて1.5倍の読書量が取れたな。」などと、定量的に物事を測定して振り返ることは皆無なので、結果として、「Aを選択するとBになるっぽいな」というなんとなくの思考をして、「なんとなくAを選択すると良さそう。」という結論を導き出します。
ここまでであれば、カフェに行って読書したらたまに作業効率あがってそんなに問題ではないように感じます。しかしタチが悪いのは、そのなんとなくの思考の結果得た結論を真実だと誤解し、さらに思考を進めてしまいます。その結果として、「カフェで作業をすると作業効率がいいから、じゃあ土日も平日の夜もカフェに行って作業しよう〜。」という行動が生まれます。ここで、「カフェにいく = 作業効率が上がる」というのは、最初の頃の数回は機能していたのですが、平日の夜もカフェに行くと作業で集中できない日が出てきます。それもそのはずで、カフェにいくことで作業効率が上がっていたのではなくて、「読書しかできない環境を作ることで、必然的に読書の効率が上がっていた。」のであって、平日にPCを持ち込んで読書をしようとしても、Youtubeを聴き始めてすぐにYoutubeを見ることに時間を奪われ、作業効率が悪くなっていたのでした。
このように、「カフェで読書したら集中できたから、カフェで作業すると効率上がるんだろうな。」となんとなく結論づける癖を持つことで、「カフェに本だけ持ち込んで、本を読むことしかできない環境を作ることで、必然的に読書しかすることができなくて集中できて作業効率が上がったんだな。」という思考にまで至ることができず、確からしい真実を見逃してなんとなくそれっぽい考えで間違った行動に行き着いてしまうのです。
この思考の癖がエンジニアの仕事において発揮されると、「このエラーは前回のリリースタイミングで出ていたけど、そのあと時にユーザーに悪影響を与える不具合は出なかったから、今回のリリースで同様のエラーが出ているけど問題ないだろう。」という、致命的なバグ見逃し行動を生んでしまいます。そして、さらにこの現象が組織内に浸透すると、「よく原因は分からないけど、特に問題が出ていないから無視してOK！」というバグが無限に積み上がっていき、最初に問題ないと判断した人がその開発チームから抜けると、もはや誰も、なぜそのエラーが出ているのかもわからないけど、特に問題はなく無視していいらしい。というエラーの地雷をどんどんとプロダクトに積み上げていく形になっていってしまいます。
個人の思考の癖が組織に浸透してしまい、組織風土にまでなってしまったらもう手遅れ。後世の開発者がエラーの地雷を毎月・毎週と踏み続けることとなり、毎月・毎週の頻度でエラーの対応に時間を取られ、本当にしたい開発に着手できず、優秀なエンジニアがどんどん去っていって誰も関わりたくない不毛の地（プロダクト）だけが残ってしまいます。
❷どこまでが仮説で、どこまでが確からしい真実なのか分けられていない。
これは❶とも関連する問題です。先ほどの例で言うと、「カフェに本だけを持ち込んでで読書することで、読書量アップにつながった。」という一つの事例は真実であったことにして、その上で、「カフェで読書をすることで、読書量アップにつながった」のか「本だけを持っておくことで、読書量アップにつながった」のか、どちらが真実なのかを切り分けるということを普段の生活であまり意識していないことに気付きました。
これはエンジニアに限らず、給料をもらいながら仕事をしている社会人の最も貴重な「時間」に関わってくる問題です。どこまでは正しいことがわかっていて、どこからが間違っていそうなのか・問題になっていそうなのか、全体の中での問題箇所の切り分けを行っていくことで、問題を早期に発見し、本質的な問題の特定と解決に全時間を投下することで、最短の時間で最大の問題を解決することができる。というのが理想ですよね。ですが、この問題の切り分けの作業をしないと、なんでアプリケーションが立ち上がらないのか。ビルドの設定がおかしいのか？と思って、ビルドの設定に関して時間を使ってググって調べまくって時間を使ったとします。しかしこの場合に、そもそもデータベースが立ち上がってなくて、データベースにアクセスできずにエラーになっていた場合には、どれだけビルドの設定を調べてもアプリケーションが立ち上がらないという問題を解決することはできず、貴重な時間だけが永遠に奪われていきます。このような事態を防ぐためにも、まずは目標のために何が揃っている必要があるのか？例として、アプリケーションの立ち上げであれば、「ソースコードのコンパイルが成功して、ビルド設定が正しく行われていて、データベースにアクセスできる状態になっていて、ビルドコマンドが正しく打ち込まれて、アプリケーションの起動ボタンが正しく押され初めてアプリケーションの立ち上げに成功する」という全体のざっくりした仕組みを理解して、その上でどこまで正しく機能していて、どこからが問題が起きていそうなのか？問題の発生していそうな箇所を最初に正しく切り分け、その上で問題となっていそうな箇所を集中的に調査する。という方法をとることで、より短時間で問題となっている箇所を特定し、問題の解決をすることができるようになります。
物事はどのような仕組みで動いているのか？成り立っているのか？を正しく理解すること。その上で、どこまでが正しく機能しており、どこからが問題が起きていそうなのかを迅速に切り分けること。そして最終的に、問題になっていそうな箇所を集中的に調査する。という一見回り道のような手順を踏むことが大事であることを自覚し、回り道をしっかりとたどること。これこそが重要ですが、自分は全くできていません。
経験の深い職業人（エンジニア歴20年以上のベテランエンジニア）や、問題の発見・解決が頭にパッと閃く天才なのであれば、このような回り道は必要ないでしょう。ですが、自分のような一般人にとっては、回り道をしてでも手順を追って問題の特定をしていく方が、次回以降の問題解決の精度を上げることができるようになり、結果的に時間の短縮になるなっていたなぁ...。と、振り返って思います。
❸「なんとなくこう思います。」がヤバい事態であることを自覚していない。
これが最も重要である一方で、気づくか気づかないかの問題なので、解決は難しいものです。自分の生活を振り返ってみると、大学生までの生活（特に文系）では「なんとなくこう思います。」でも、アルバイトで給料をもらうことはできたし、テストで点を取ることもできたし、生活に苦労はないほど、ヌルゲーで生きることができました。しかし、社会人になって、「限られた時間の中で、答えのない問題に取り組んで最短の時間で問題解決をし続けていく。」というようにゲームのルールが変わると、途端に戦うことができなくなっていきました。
なんとか仕事の中で求められた仕事をこなすことはできますが、演繹的に物事を考え、物事の仕組みを理解し、問題が起きた時に迅速にどこに問題がありそうか切り分けることができ、その上でその問題を迅速に調査して解決することができるかどうか？によって、日々の仕事での生産力は天地の差が生まれ続け、2年、5年、10年と時間が経つにつれて、その差は塗り替えることのできない差になっていくのだと思います。
普段から「こういう根拠で、こう思います。」という思考の癖を持つこと、その根拠と結論の精度を上げていくことを継続改善していかないと、いつまでたっても問題解決能力は伸び悩みます。ポケモンでいうと、いつまでもトキワの森でキャタピーを倒すだけの人生で、四天王に挑戦できるようになるまでに定年を迎えてしまうような。そんな感覚です。
せっかく職業人になったのに永遠にトキワの森でキャタピーを倒す（バグ潰しする）ために生まれてきたわけではないですよね。「なんとなくこう思います。」を続けると、キャタピー狩りの人生で終わってしまう気がします。かなりやばいですよね。
「なんとなくこう思います。」という思考の癖を自分が持っていることを自覚すること。
まずはこの自覚を持って、何か結論を出すときや、行動をする時には口にするか否かを関係なく、根拠を持つこと。そして、結果が出たら、当初持っていた根拠と照らし合わせて、根拠と結果の精度を上げていくこと。これを繰り返すことで、社会人として四天王に挑戦できることを目指す。
これを当面1ヶ月間は意識して仕事をしてみます。
とりあえず、早くトキワの森抜けたい。（なぜなら、得られる経験値が低くて、レベルの上がる速度が遅いから。）
では！
