Feedback Loop

先週末の話。カフェで個人開発をしていて、どうにも解決できない問題があった。この実装で正しく動くはずなのに動かない。ネットで調べても情報はなく、自分と同じ問題に直面している人は他にいないように見える。実装を楽にするためにとあるライブラリを使っていたが、それが良くないのかもしれない。2時間くらい奮闘していたが夕方から予定があって調査を切り上げる必要があり、最後に調べた内容をまとめてそのライブラリのコミュニティに聞いてみる（GitHubのIssueを立てる）ことにした。

発生している問題や期待値、自分が試した内容などをまとめていく。このケースは動くのにこのケースでは挙動がおかしい。そんなことをまとめていると検証しきれてないパターンがあったことに気づく。情報は全部揃っていた方が良いので、漏れていた部分を検証する。すると不可解な挙動になっていて、そこを深掘りすると問題の原因に行き着いた。原因がわかってしまえばすぐ直せる。10分くらいで修正して良い気分でカフェを出る。そして、こういうことってよくあるなと思い返していた。

前の職場でエンジニアとして働いていたとき、行き詰まって同僚に相談することがよくあった。相談するときはソースコードや実際の画面を見てもらいながら、起きている問題について整理して話す。すると不思議なことに、相談しはじめた途端に怪しい箇所が判明し、問題が解決する。これは問題に直面して狭くなった視野を俯瞰して整理するタイミングが必要ということだと思う。問題をツリー構造で理解し、すべてのパターンを試す。このパターンではうまくいくが、このパターンではうまく動かない。その違いを深ぼっていく。問題に直面して1時間くらい経っていると、こういう冷静な脳が働かなくなる。一度画面から離れて、人に話したり状況をテキストにまとめたりするのは視野を取り戻す効果がある。

今回カフェで当たった問題は、自分があまり詳しくない技術の周辺で発生した。勉強中の身なので自信がない。そうなるとエラーの内容でググって一発で誰かの答えを探そうとしてしまう。熟達した分野なら早い段階で落ち着いて問題整理に時間をつかい、一つずつ可能性を潰していったと思う。詰まったら立ち止まって状況を整理すること、自信がなくてもいつも通りのプロセスをふむこと。これらは意識しておきたいポイント。