More than 1 year has passed since last update.

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

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

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

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

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

20160323124006 2.png

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

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

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

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

20160323124139.png

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

20160323124153.png

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

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

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

自戒をこめてここに書いた。

<エンジニアの皆様へ>
ほとんどのエンジニアには解けるが、下位10%のダメなエンジニアにだけ解けないパズル?」なるものをシリーズ化していくつか作成した。もしご興味あれば解いてみてください。
http://tango-ruby.hatenablog.com/entry/2015/11/30/122814