Feedback Loop

プログラミングをしていると、よくわからないけど何故か動く、みたいなことがある。目当ての実装をググればそれなりに情報が得られる時代。実装の中身を理解していなくてもコピペだけでそこそこのものは作れてしまう。

ただ自分の肌感だと、理解が曖昧なとこは立ち止まってその場で調べたほうが結局早い。その場を適当に凌いで前に進んだ先で原因不明のバグにつきあたり、よく調べてみると曖昧にしていた部分が影響してたりすることがとても多い。理解を正確にするために誰かのブログではなく公式ドキュメントをよく読み、簡単なデモアプリを作っていろいろ試す。こうしておくとシステム全体への理解度があがり、何か想定外のことがあってもすぐにアタリをつけて修正できるため、結局早い。長いスパンで考えると同じような実装をするタイミングが必ず来るため、そのときにちゃんとした理解をもっていると爆速で実装できて、結局早い。

プログラミング以外の仕事でも近しいことが言える。チームで働いているとき、判断を求められて意思決定するときがある。その場凌ぎで曖昧な判断をすることもできるが、よく考えて誰にでも説明できる自分なりのロジックを作ったうえで判断するほうが結局早い。まったく同じ判断は二度ないものの意思決定の内容は抽象化すれば似てることが多く、ロジックを一度作っておくと次からの判断を爆速にできるようになる。例えばプロダクト開発でよく求められる判断として、利益をあげるような機能とユーザーの利便性をあげる機能のどちらを優先するか、というものがある。正解はなくバランスが求められる判断だが、自分は小さいチームのうちはユーザーの利便性をあげる機能を優先していくのが良いと思っている。ユーザーの抱えている課題を解決して、それに対してもらっている対価が利益だと整理しているので、まずは課題をたくさん解決するのが良い。ただし決め打ちではなく、チームの資産状況とかユーザーの数とか開発にかかる工数とか、多くの変数を考慮して細かくチューニングは必要。自分なりのロジックにその時の状況をトッピングしていくのがイメージに近い。

GoogleやAIに聞けばすぐに答えが得られる時代だからこそ、逆に時間をかけて理解することが違いになるかもしれない。目先でつくっている機能の提供が1週間遅れても実は別に大した影響はないので、落ち着いて理解を深めながら前に進むようにしたい。