「何が問題か？」→「問題は何なのか？」→「問題は本当のところ何か？」（注意とプログラマについて）

タイトルに挙げた3つの問いは、問題解決について書かれた『ライト、ついてますか』という本のそれぞれ第１・２・３部のタイトルだ。

ライト、ついてますか―問題発見の人間学

これは決して冗談で付けられたタイトルではなく（むろん茶目っ気もあるだろうが）、問題解決に取り組んでいる間に問題それ自体が二転三転するという事実を冷静に指摘していて非常に本質を突いていると思う。

技術調査はググる前が肝心 - seri::diary

今日見たこの記事に掲載されているフローチャートに非常に共感した。

著者はオレンジ色にされた「何がやりたいかを改めて整理する」以降の4つのフローが重要だと指摘しているが、それはまさに僕がここ最近すこしずつ、プログラミングの最中に生じる問題を解決する際に必然的に身に着けてきた感覚そのものだった。

例えば以下のような問題に対して、最終的に解決に至った方策は→以下のものであった。

• rails製の英単語帳アプリをインストールしようと考えた。しかし実行環境が特殊で使用されているgemの一つであるcapybara-webkitがインストールできず起動に至れない。エラーメッセージを頼りに、依存しているQtというライブラリをビルドしようとするがビルド中に対処法不明のエラーが出る（ここまでで数日間経過している）。
  
  　→英単語帳アプリの開発者にメールで問い合わせ、capybara-webkitはテスト用なので除いて起動しても問題ないとの解答を貰い、実際それで起動に成功した。　
  
  
• HerokuにTwitterボットを上げようと考えた。しかし考えていたcronによる自動実行頻度が有料であることを知り、clockworkというgemを用いて自動実行をするようにした。しかし原因不明のバグで思うように動作しなかった。
  
  　→最新のドキュメントを読んだところ現在ではHeroku Schedulerという追加機能を使うことで、望んていた実行頻度が無料で実現できることを知り、それを利用した。

　前者は「そもそもこのgemが無くても僕が利用したい部分は動くのではないか」と思ったことが鍵だった。利用したかったのは一部の機能のみであり、そのgemを無くしたとしても動く可能性がある。ただしそのgemがアプリの起動自体に関わっている可能性もあり、その判断には開発者に聞いたほうが確実だ。そのような思考回路だった。

　後者は「そもそも僕がやりたいような実行頻度はほかの客も要望として出しているのではないか」というものだった。数千万のアプリを動かしているようなデータセンターが数時間間隔での定期実行を本当に許していないのだろうか、と疑うような気持ちで最新機能あたりに目星を付けたら見つかった。

　どちらの着眼点も「そもそも」が付いているように、自分が直面している現状をメタに捉えなおそうとする心のあらわれである。

　これはまさに冒頭に挙げた「問題は何か（←何がやりたいかを改めて整理する、どこまでは出来たか整理する、出来ていないことを整理する、足りない情報を洗い出す）」の典型例に他ならないと自覚している。

プログラミングをやり始めたときと比べ、解決策を３つも４つも連続的に思いつく傾向が出てきたと感じる。それは恐らく、自分にとって本当に解決しなければならない問題は時間的にも直近で空間的にも目の前のターミナルに表示されている「SnowLeopard環境下でQtがビルドできない」「ClockworkがHerokuで動かない」というものではなく、その問題が問題スタックに乗せられる前にpushした「アプリが動かない」「定期実行ができない」というちょっと遠くにある問題であることから注意が離れなくなった、いわば注意の持久力のようなものが付いたからだと思う。

思えば高校生時代の体力テストでは筋瞬発力が要求されるものだけ点数が良くて筋持久力が要求されるようなシャトルランやらマラソンやらはひどいものだった。あれも僕が根性無しだから記録が悪いというのではなく実際には筋組織や肺胞のレベルで鍛錬が足りていないということなのだろう。

その点からするとプログラマの「注意」に対する鍛錬というのは(ソースコード内に限れば)かなり人外なレベルに来ている気がする。