Feedback Loop

プログラミングをしていると、難しい場面にあたることがある。意図せぬ不具合、原因不明の挙動、ドキュメント通りに実装しているのになぜか動かない、など。プログラミングというと新しい機能を作り上げていくイメージがあるが、実はこういう調査系の時間がとても多い。3時間くらい問題を調査してコードの修正は1行だけ、というのも珍しくない。

問題を調査するのに大事なのが原因の切り分けで、これはセンスが問われる。経験が浅いとよくやってしまうのがいきなり問題を修正しようとコードを書き始めることで、これは良い手ではない。全体像が見えない状態での修正は根本原因の解決にならなかったり、別の箇所で同様の不具合が発生しているのに気づかなかったり、新たな別の不具合を生んでしまったりする。まずは全体を見渡して仮説を立て、ツリー構造の上から順にそれを確認していく。ある値を変更して不具合が再現するのを確認したり、ログを追加して不具合が起きたときに期待通りの出力があるのを確認したり、少しずつ問題を絞り込んでいくのが良い。

こういう問題特定のアプローチはプログラミングの外の世界でも役立つと思っていて、なにかトラブルがあったときにいきなり解決に当たらず、まずはその問題を網羅的に考えるようにしている。人間関係の揉め事であればAさんとBさん両方に話を聞く、他のメンバーで同じように感じている人はいないか聞く。サービスの新機能が使われていない場合は慌てて機能を継ぎ足すのではなく、なぜ使われないのかを関係者で議論し、そこで出た仮説をデータ分析で裏付ける。結局同じ対応に着地することも多いが、こうした議論を経るのと経ないのとではその後がまるで違う。長い目でみると地に足のついた議論ができるチームになる。

最近は仕事で採用面接をする機会も多い。問題特定を特定する思考法はとても大事だと思うが、曖昧なスキルなため履歴書には書かれない。どういう仕事をしていますか？と聞いて答えられるようなものでもない。強いていうなら論理的思考と近いが、それだとMECEとか三段論法とかが出てきてちょっとニュアンスが違ってくる。ただ、履歴書には書けないが、直接話せばすぐにわかる。こちらの質問を解釈する力や聞かれたことに順序立てて答える力。そういうところに自然と染み出しているように感じる。