だいたい「頑張る」とろくなことはない
一連の観察を通じて、自分が数カ月、頑張ってもアウトカムが出なかった理由がよくわかった。
その理由は「頑張ったから」、または「無限に時間をかける覚悟があり、実際そうしたから」である。
現在のサービスのアーキテクチャを見て、「こうなっていたら精度が出ないだろう」「自分の構想を実現するにはこういうコントリビューション（貢献）をしないといけない」と考えて必死に関わった。ところが、サービスが成熟するにつれて、「スピード開発」モードから「品質重視モード」に変わり、外部からのコントリビューションが制限されるようになった。
すると、外部コントリビューターである私のPRの優先順位は落ちるので、マージが遅々として進まない。自分の書いたコードを一部変更したくても、ものすごく時間がかかる。なかなか付かないコメントに対応したり、マージまでの期間があると大きなリファクタリング（内部のコードの整理）があったりして、またコード分析からやり直すなどの非生産的な悪循環に陥った。
それでも、センスのいいエンジニアたちに自分が近づくには努力するしかないと、成果を出そうとするあまり、無限に時間をつぎこんでしまった。結果、作業時間ばかりがどんどん膨れ上がり、何のバリューも出なかったのだ。
だいたい頑張るとろくなことはない。私に希薄だったのは「どうやったら最も楽にできるか？」という「Be Lazy」のマインドセットだった。
どうやったら最小の労力、最短のルートで物事を解決できるか？ は直感的センスに優れたエンジニアの頭の使い方と深く関係している。
センスのいい技術エリートたちと働いていると、時折、彼らが“魔法使い”のように見えることがある。難解なバグを一瞬で特定したり、複雑なアーキテクチャの最適解を即座に導き出したりする。凡人である私が数時間、あるいは数日頭を抱えていた問題について、たった一言のアドバイスで解決したりしてしまうのだ。
まるで手品のように問題解決をしたポール
印象的なエピソードを紹介しよう。
ある日、私が担当している稼働中のサービスで、「Divide by Zero」（ゼロ除算）のエラーが発生した。数値がゼロで割られてしまい、システムがクラッシュしている。同僚のクーパーと一緒に調査を開始した私は、すぐに原因の候補を二つの領域に絞り込んだ。
一つは、複雑な計算ロジックが含まれるAの領域。ここはデータのバリエーションも多く、バグが潜んでいる可能性が高い。もう一つは、システム全体の設定値を管理するBの領域。具体的には、あるデフォルト設定値がゼロになっている可能性がある。
私はすぐBの可能性は外した。なぜなら、そのコードは何年も変更されておらず、長期間にわたって問題なく稼働していたからだ。値が設定されていない場合は安全なデフォルト値が入るロジックになっている。
「ここが原因の可能性は限りなく低い。長年動いていた実績があるし、コードも正しい」
そう判断した私たちは、Aの領域、つまり複雑なロジックのほうにバグがあるはずだと思い込んで、膨大なログとコードの海に潜り込んだ。
数時間が経過した頃、まだ原因を特定できずにいた私のところに天才エンジニアのポールがふらりと現れた。彼は状況を聞くと、コードすら見ずにこう言った。
「システム全体に設定できるコンフィグ（基本的な構成・動作ルール）の値を明確に設定してみよう。やってみてもよい？」
