プログラミングの本質は問題解決
- 発端:
- 自分もプログラマの仕事の本質は問題解決だと常日頃言ってるし、プログラミングの参考書を聞かれたら『方法序説 (岩波文庫)』とか『問題解決の心理学―人間の時代への発想 (中公新書 (757))』とか『ライト、ついてますか―問題発見の人間学』を薦めようと思っているぐらいだ。
- 問題解決というのは問題を解決する事だ。ではここで言う問題とはなんだろうか。受託開発などで職業としてプログラマをやっている場合、大抵は「自分と関係のある自分以外の人が目的や課題を持っていて、それを自分が(プログラムを作る事によって)解決する、」ということになるだろう。「他人の問題を解決する」というのがまずはスタート地点になる。
- 振り返ってみれば、そうやって与えられた問題だけが問題なのではない。開発を進める過程で、例えば品質や開発効率が悪いとか、工数見積もりの精度が低いとか、要件通りに作ったのになぜか満足度が低いとか、そういった仕事自体に関わる問題に向き合わなければならない。当然これらの問題を解決するのもプログラマの仕事の範囲になるだろう。「問題を解決するのが仕事だが、その仕事自体も解決するべき問題に含まれている」と言える。*1
- ある程度長く仕事を続けていると、個々のタスクに留まらない、少し大きな問題が見えてくる。人によっては顧客との向き合い方だったり、開発プロセスの改善だったり、より便利なフレームワークを作成する事だったりする。そしてそれは、「他人の問題を解決する」という日々の仕事と、その過程での「仕事自体を問題として解決する」という行為の繰り返しによって、徐々に見えてくるものだと思う。これが自分自身のものとして引き受けられる「自分の問題」になる。
- 十年泥というのは結局、この「自分の問題」を見つけるのに必要な時間であったり、過程であったりするのではないだろうか。10年も必要ないかもしれないし、泥のように働く必要もないかもしれないけど、「自分の問題」を見つけるために、まず社会に(あるいは「問題の海に」)身を投じよ、ということだと思う。
- どっちにしろ、メタ問題解決というべき俯瞰的な視点は必要だと思う。そうでなければ真のプログラマとは言えないし、10年経っても何も得られないだろう。
- 「ライフワークを見つけるのにはまず社会に揉まれよ」と言うととても陳腐だけど、お手頃なプラクティスと割り切って考えればそう悪くないと思う。特に自分の進むべき道が分からない、という場合には。あくまで選択肢の一つだけど。
蛇足だけど
「他人の問題」を「他者の欲望」と置き換えれば、精神分析になぞらえてプログラミングの主体を論じたりできそうだよね。要求とソリューションのキャッチボールですよ。
