エンジニアのハマり時間とその技術的難易度の相関関係
移転しました。
めちゃくちゃにハマったからと言って、その問題は技術的難易度が高い訳ではないんじゃね？という話。
ここで言う「ハマる」とはなにかに没頭することではない。バグとかエラーがあって、なかなか解決できなくてそのために時間を割かれてハマる、の「ハマる」。
先日、ハマった問題が解決した瞬間の感情は「ついに解決したぞ」という安堵感と「しょーもないハマりポイント作りやがって、あのボケが!」という前任者への怒りが混ざった状態だった。
あるサイトのSSLの有効期限切れが２週間後にせまっていた。やらなければならないのは証明書の更新、その新しい証明書をAWSのELBに入れること。ただこれだけ。しかしハマった。どうやってもELBから「あなたのキーは無効です」みたいなエラーメッセージが返ってきた。２年前にSSLを設定したエンジニアは退職してしまって、もう居ない。その前任者とほぼ同じことをすればOkなはずなのに、なぜかできなかった。
ググっていろいろ調べてpemファイルのフォーマットをopensslコマンドで変換したりして入れるのだが、一向にエラーが解決しない。期限は２週間後に迫ってるしどうしよう、と焦った。
詳しく内容説明しても面白くもなんともないので省略するが、要は以下の３つの枠内にそれぞれのキーを入れるのだ。
あまりにできないので３日ほど放置して、ふと「もしかして秘密鍵が違うのかも」と考えた。今の会社では２０以上のプロジェクトがあって、それぞれの秘密鍵は＜プロジェクト名＞.pemという名で保存されている。もちろん今回もその＜プロジェクト名＞.pemを使っていたのだが、ここまでエラーが返ってくるということは、前任者はこの秘密鍵とは異なる鍵を使って証明書を発行したのかもしれない、と考えた。そこであらゆるところを探して社内にあるいろんなpemファイルを入れて、総当りで試してみた。するとあるフォルダからその＜前任者の名前＞.pemなるファイルが見つかった。ここでは仮にその前任者の名前をのび太として「のび太.pem」とする。いくらなんでも「のび太.pem」はないだろ、と思ったが一応試してみた。すると見事に前回の証明書と合致して、新しいのに更新されELBに入ったのだ。
だいたい大切に保管しなければならない証明書をありえない場所に保管しておくのもどうかと思うし、そのファイル名が「のび太.pem」でファイルを眺めているだけで、のび太に対する怒りがこみあげてきた。腹立たしいこと限りない！おい、のび太！！テメーしょうもない地雷設置して会社辞めやがって、マジええかげんにしとけよ、このクソボケがぁああ！！！
しかし今回の件と歴代のハマった内容を思い返してある結論に達した。それはハマり時間に比例して技術難易度が高くなる訳ではない、ということだ。
例えば１時間悩んで解決した問題と１００時間悩んで解決した問題を比較した場合に必ずしも１００時間の方が１００倍技術的難易度が高度か？というとそうでもない。
このグラフに示すように考えがちだが、現実はちょっと違う。
実際はこのようなグラフの方が実感としてはしっくりくる。
もう１日悩んで解決できなかったら、だいたいその技術難易度は低い。
最初の５時間ぐらいまではそのハマり時間に比例して技術的難易度は高くなる傾向がある。どんなエンジニアでも５時間とかググッて調べまくったら、その件に関しては相当な知見が貯まる。その詳しくなったエンジニアの知識を持ってしても解決できない場合、もうほとんど問題の根本は技術じゃないことが多いのだ。１日経っても解決できなかったら、それは技術どうこうではなく、前述の例でいうフォルダからファイルを探す、みたいな極めてローテクな内容を試してみるのもいい。
ハマった時ほどこのグラフにあるように考えようと思った。
ハマった時は怒らない、焦らない、落ち込まない、感情を乱さない。足元にあるとても基本的なことに目を向け、冷静に冷静にひとつひとつ確かめるべし。
自戒をこめてここに書いた。
しかしもうハマりたくないわ。
tango-ruby.hatenablog.com
