理論派プログラマの憂鬱qune理論派プログラマの憂鬱2009/12/04ここ1ヶ月ばかり,自分の仕事の一部を某氏に頼んで作ってもらっています。あたしにそういう感覚はあまりないんですけど,役職的には部下ということになります。某氏は,問題に対して適切な実装を提供するのが仕事。あたしの仕事は,泥臭いところを整備して(上司と折衝したり他モジュールとのインターフェイスを検討したり),某氏に開発に専念してもらうことです。一応,上司っぽく振舞っていることとして,こちらで開発方針を立てて内部設計を作ってはいるんですけれど,これも本当は某氏に預けたいところだったりします。手持ちの仕事がいっぱいいっぱいなもんで。その某氏,開発方針や内部設計のあれこれを自分で決められるようになれば,(やや)自由にモノが作れるようになるわけで(もちろん,マイルストーンごとにレビューは行うが),本人のためにもなると思っているんですけれど,なかなか預けられなかったりします。言ったことはかなり正確に深く理解できるし,成果物のバグ数も性能も申し分ありません。悪いことに,今のところ「言ったものしか作れない」んです。そのことについて,「早く仕事を渡したいんだけどねー」みたいな話を話したところ,本人にもその自覚はかなり深刻な問題としてあった様子。なんでも,頭で深く考えすぎてしまうために,実装してひとつのモノを作り上げるところにまで至らないんだそうです。人から一方的に言われたものなら,しっかり作れるけれど,自分で考えたものはなかなか形にならない。これはおそらく,本人にとってもストレスになるんだと思います。開発者だったら,少なからず人から言われた方針について「自分だったらこうするのに」と思うところがあるはずだからです。話は少し変わるけれども,あたしゃ常々,プログラマには理論派と実践派がいると思っていたりします。理論派は頭でよく考えて,「できる」と踏んでから実装するタイプ。実践派は,作りながら考えるタイプです。前者は,しっかりした設計さえあれば,かなり正確に実装できる一方で,取り掛かるまでに時間がかかる。後者は,取り掛かりが早い一方で,できるものに不確実な要素が含まれることがあります。主要な開発過程では,設計と製造を分担するのが普通ですけれど,うちの部署(やや研究寄りの製品部門)では,自分で企画から製造まで担える必要があります。理論派プログラマの場合,「いける」と踏むまでの深い検討は必須だけれど,その過程さえ体系付けられていれば,割とその時間は短縮できるんじゃないかと思います。中間成果物の粒度を細かめに設定して,成果物を中心に物事を考える方法は,やってみて割といいやり方だと思いました。ある物理量を検出するプログラムで閾値を設定して処理するか,もっと上手いやり方に進むか迷っているようだったら,いきなり完成品の設計書を成果物として求めるのではなくて,まず検出されるデータの散布図を描く小さなプログラムを作ることにして,そのプログラムと分析結果を中間成果物にするとか。あと,頭だけで考え込んでしまう理論派プログラマとは,よく話した方がいいんじゃないかとも思います。言葉にするとひらめくこともありますから。産婆法よろしく,なるべく考えていることを表出させる話し方をするのがいいんじゃないかと。今日某氏の話を聞いていて,思っていた以上に素養があることに気づいたんですけれど,最終成果物を作れないがために,周囲から過小評価されているのはなんとも残念です。なんとか自信を持ってもらいたいんですけどね。手持ちの仕事を振って,自分の仕事を減らしたいってのもあるんですが。