ソフトウェアを開発していると、ときどき幽霊に出会うことがある。正確にはまるで幽霊のしわざかに思えるような謎の挙動に悩まされるときがある。

実際には幽霊などおらずコンピュータは書かれたとおりに動作しているだけで、さらに大抵は自分がプロトコルや仕様を把握していないか誤ったプログラムを書いているのだが。

これは私がOAuth2.0の仕様を把握していなかったが故に謎と思った挙動になやまされたとき。

複数の要因が重なっていたりして挙動の説明がすぐにはつかないとき、原因を追求するためにだいたい次のようなことをする。

  1. 原因を考える (現状を整理する、アタリをつける)
  2. 挙動を確認するためにプログラムを実行する (手を動かす)
  3. 仕様やドキュメント等を調べる
  4. 人に聞く

ここでは特に1つめの原因を考える事と2つめの手を動かす事について注目する。1 これらは、手を動かさないとわからない事を考えても意味は無いし、逆に無鉄砲に手を動かしても意味はない。現状を整理すること、アタリをつけること、手を動かしてみること、これらを組み合わせてやっていく必要がある。

しかしながら特に昨日の私は原因を考えることと手を動かすことの比率が悪かった。またそもそも、目下の謎な挙動に対峙するとき、あまり自分の行動を分解して自らで認識せず全部一緒くたにしてやっているところがある。それですぐ解決できれば良いが、深みにハマったときに困る。

二分探索的に考えていた筈が条件に漏れがあったり、試せばすぐにわかったことを最後まで放置していたりする 2 のはこういったところに原因があるかもしれないと思っていて、だとすると改善の余地がある。

そこで、次に対峙するときは今整理してアタリをつけるべきなのか、情報が足りないから手を動かすべきなのか、自分の現状を認識して意識的に切り替えることを試してみたい。3 そのとき脳内で私が発すべき言葉は「現状を整理したいのか？新たな情報を得たいのか？ (=手を動かすべきか) 」という二択の自らへの問いかけである。

Footnotes

  1. 3 のドキュメントを調べるという行為についても英語の仕様書をさくっとしっかり理解できるようにするだとかライブラリのコードを読み込むといった部分ががまだまだだし、4の人に聞くという行為も業務の中で最適なタイミングを逃していたり状況を整理して伝えるのが下手で時間がかかったりと、結局全部未熟なので粛々とやっていくしかない。 ↩

  2. 解決したあとだからそう思うだけかもしれないが。 ↩

  3. 実際には脳の力をそんなところに使う余裕はないのかもしれない。一方で業務でエンジニアリングに取り組むなら、時間的な見積もりをすべきである点と、再現可能な手法で行動して成果をあげるために自分の状態を認識するのは大切だろう点から、無心に対峙するのではなく上記の方法を試してみるべきだと感じた。 ↩