世界一流エンジニアは自分と考えが真逆だった話

　今日はちょっと驚いたことがあったので、自分の記録のためにも書き残しておきたい。

ライブサイトの問題

　自分のやっているプロジェクトで問題が起こって、その障害の復旧と調査にあたっていた。問題は大きいが、DividedByZero が起こっている。これはスポットしやすい。
　自分の見慣れたコードパスをログを頼りに DividedByZero が起こりうるところを特定する。
　実際にそれが起こるところは２点と特定する。

• フロントエンドが０台になる

• アプリケーションの必須の設定が０になっている

　どちらも通常あり得ないが、どう考えても前者である可能性は低い。もし前者だとしたら、問題はここだけに収まらない。最近変更を他のチームが加えた後者が最も有力だろう。何せ今までそれは起こったことが無いから。調査に協力してくれた Cooper も同意見だった。

問題の特定に時間を使う

　残念ながらログが出てないので、調査が難しい。しかし、デプロイされたバージョンのコードを読むと下記のことが分かる。

• コンフィグのパース（新しいロジック）がデフォルト値などで０を設定している

• システム全体に設定できるコンフィグの値が０である

これもどう考えても前者の可能性が高い。なぜなら後者は、もう何年も何事もなく動作して誰もいじっていないスポットだからだ。しかも、コードをちゃんと読んでも、設定されていないときはデフォルト値が設定されている。

　自分は何とかして、コンフィグのパースや、それが格納されているデータベースの値がどうであるかを確認することに時間を費やしていた。

Paul の一言

　そしたら、自分の本のタイトル「世界一流エンジニアの思考法」の由来である、まさに世界一流レベルの Paul が参加してきてこんなことを言い出した。

　システム全体に設定できるコンフィグの値を明確に設定してみよう。やってみてもよい？

ガチ世界一流エンジニア曰く

　私としては、そこは最も可能性が低い場所とわかってるけど、いろんな可能性を狭められるので、もちろんと言った。Cooper は Paul のいう通りに、その設定を変えた。そしたら DividedByZero は消えた。

　まるで手品を見ているようだった。だって Paul は一切コード見てないし、その場所のコードを書いたのは Cooper だし、自分がその辺については詳しい。Paul が行動した一つのSuggestionだけで、問題は収束した。マジ、神か、Cooper と二人で結構時間つかったのにw

世界一流の舞台裏

　あまりにもびっくりしたので、あとで、Paul にどういう思考回路でそう思いついたの？という話を聞いた。彼はこんなことを言ってくれた。

　君はきっと「どこが最も可能性の高いところだろう」と考えてそこを調べていただろう。しかし、僕のアプローチは違う。「最も簡単に可能性を狭められるところを探して、そこを実際に実行」しただけだよ。それだけで、沢山ある可能性が狭まる。コードにジャンプして複雑に考える前にしたらいい。そしたら、問題の収束 (Mitigation) が出来るかもしれないし、そもそも、自分には、そこに問題があるに違いないとわかってたわけではないよ。

魔術の様でした

そうか、自分が「最も可能性が高い」と「思い込んで」いるところをいくら丁寧に調べても何もおこらないだろう。世界一流の人はどうやら複雑には考えていないらしい。自分はやっぱ考えすぎの感がある。
　だから、積極的にシンプルにFact を積み重ねて可能性を絞り (Narrow it down) 、問題を解決するのに、問題を完璧に理解する必要すらないことに気づいた。もちろん完璧に理解できることが望ましいが、ライブサイトではまず問題の収束が第一優先となるはずだ。

「可能性が高い思い込み」ではなく、「実際に可能性を狭める」ことにフォーカスする

　そういえばライブサイトの電話番の時に、Pragna も、システムの設定を変えてみようと言い出して、実際にそれで治ったのだが、自分は当時「なんで？そんなん関係ないやん」と正直思っていたことも思い出した。ああ、やっぱみんなすげぇんだなぁ。多分似たような思考だったのだろう、彼女もなぜ治ったのかについてよくわかってない様子だった。

　こういったシンプルに考える習慣を私も真似して試していきたい。ほんまPaul マジ一流。こうなりたいものだわ。

お陰様で７万部突破したのでせっかくなので１０万部いきたいな。よかったら読んでくだされ！

世界一流エンジニアの思考法 | 牛尾 剛 |本 | 通販 | Amazon