ジャバ・ザ・ハットリ
Published on

エンジニアのハマり時間とその技術的難易度の相関関係

Authors
  • avatar
    ジャバ・ザ・ハットリ

めちゃくちゃにハマったからと言って、その問題は技術的難易度が高い訳ではないんじゃね?という話。
ここで言う「ハマる」とはなにかに没頭することではない。バグとかエラーがあって、なかなか解決できなくてそのために時間を割かれてハマる、の「ハマる」。

先日、ハマった問題が解決した瞬間の感情は「ついに解決したぞ」という安堵感と「しょーもないハマりポイント作りやがって、あのボケが!」という前任者への怒りが混ざった状態だった。

あるサイトの SSL の有効期限切れが2週間後にせまっていた。やらなければならないのは証明書の更新、その新しい証明書を AWS の ELB に入れること。ただこれだけ。しかしハマった。どうやっても ELB から「あなたのキーは無効です」みたいなエラーメッセージが返ってきた。2年前に SSL を設定したエンジニアは退職してしまって、もう居ない。その前任者とほぼ同じことをすれば Ok なはずなのに、なぜかできなかった。

ググっていろいろ調べて pem ファイルのフォーマットを openssl コマンドで変換したりして入れるのだが、一向にエラーが解決しない。期限は2週間後に迫ってるしどうしよう、と焦った。

image

詳しく内容説明しても面白くもなんともないので省略するが、要は以下の3つの枠内にそれぞれのキーを入れるのだ。

あまりにできないので3日ほど放置して、ふと「もしかして秘密鍵が違うのかも」と考えた。今の会社では20以上のプロジェクトがあって、それぞれの秘密鍵は<プロジェクト名>.pem という名で保存されている。もちろん今回もその<プロジェクト名>.pem を使っていたのだが、ここまでエラーが返ってくるということは、前任者はこの秘密鍵とは異なる鍵を使って証明書を発行したのかもしれない、と考えた。そこであらゆるところを探して社内にあるいろんな pem ファイルを入れて、総当りで試してみた。するとあるフォルダからその<前任者の名前>.pem なるファイルが見つかった。ここでは仮にその前任者の名前をのび太として「のび太.pem」とする。いくらなんでも「のび太.pem」はないだろ、と思ったが一応試してみた。すると見事に前回の証明書と合致して、新しいのに更新され ELB に入ったのだ。

だいたい大切に保管しなければならない証明書をありえない場所に保管しておくのもどうかと思うし、そのファイル名が「のび太.pem」でファイルを眺めているだけで、のび太に対する怒りがこみあげてきた。腹立たしいこと限りない!おい、のび太!!テメーしょうもない地雷設置して会社辞めやがって、マジええかげんにしとけよ、このクソボケがぁああ!!!

しかし今回の件と歴代のハマった内容を思い返してある結論に達した。それはハマり時間に比例して技術難易度が高くなる訳ではない、ということだ。

例えば1時間悩んで解決した問題と100時間悩んで解決した問題を比較した場合に必ずしも100時間の方が100倍技術的難易度が高度か?というとそうでもない。
このグラフに示すように考えがちだが、現実はちょっと違う。

image

実際はこのようなグラフの方が実感としてはしっくりくる。

image

もう1日悩んで解決できなかったら、だいたいその技術難易度は低い。
最初の5時間ぐらいまではそのハマり時間に比例して技術的難易度は高くなる傾向がある。どんなエンジニアでも5時間とかググッて調べまくったら、その件に関しては相当な知見が貯まる。 その詳しくなったエンジニアの知識を持ってしても解決できない場合、もうほとんど問題の根本は技術じゃないことが多いのだ 。1日経っても解決できなかったら、それは技術どうこうではなく、前述の例でいうフォルダからファイルを探す、みたいな極めてローテクな内容を試してみるのもいい。

ハマった時ほどこのグラフにあるように考えようと思った。

ハマった時は怒らない、焦らない、落ち込まない、感情を乱さない。足元にあるとても基本的なことに目を向け、冷静に冷静にひとつひとつ確かめるべし。

自戒をこめてここに書いた。
しかしもうハマりたくないわ。

関連記事