プログラマに足りないもの

今回はメカAGさんのブログからご寄稿いただきました。

プログラマに足りないもの

だから、たとえば、「できない」って言うプログラマーがいたときに、「なんとかしなさい」って言うんじゃなく、「どういう仕組みになってるの？」って訊くんですね。すると、仕組みを説明されるので、「じゃあその仕組みをこう利用したらこういうことはできないの？」って提案すると、「それならできます」ってなるんです。

「樹の上の秘密基地 | 宮本茂はどういうふうに構造をつくっていくのか。」 『ほぼ日刊イトイ新聞』
http://www.1101.com/nintendo/pikmin3/2013-07-19.html

これを読んでて思い出したが、俺も若いころ、こういう人に出会ったんだよね。その人はソフトウェア開発とは全然畑違いの人で、俺達はとある製品を作る機械を作っていた。しかしどうにもこうにもうまくいかない。物理的なものを相手にしなければならないので、いくらCPUが「こう動け」と命令を出しても、実物がその通り動いてくれるほど単純じゃない。あの手この手でフィードバックが必要。

さまざまな計測器からデータを受けつつ、それをもとに機械を制御するのだが、一生懸命アルゴリズムを考えても、なんかうまくいかないんだよね。で、また別のアルゴリズムを考える、の繰り返し。あーでもない、こーでもないと試行錯誤を繰り返していると、プログラムもぐちゃぐちゃになっていくし…。

で、その頃俺は若くて、生意気盛り(苦笑)。プログラミングについては自分の方が専門という自負があったので、主導権を取られまいと、意味もなく張り合っていた。というか張り合ってるつもりだった(笑)。

　　　*　　　*　　　*

その人の「こんなふうなやり方を試してもらえないですか？」という提案に、「それはできません」とか答えていた。今思えば、プロジェクトを成功させなければとの思いが、どうも変な方向に向かっていたように思う。決して非協力的なつもりはないのだが、どうしても「ちゃんと動くものを作らねば」という気持ちが、防衛的なスタンスを取らせていたのだろう。

しかしその人はいろいろプログラムの作りを尋ねて来た。細かな部分はもちろんわからないのだけど、全体的に現状のプログラムはこういう作りになっていて、その処理をいれるには、こことここを変えなければならない…という俺の説明を熱心に聞いていた。

で、俺が「修正は難しい」といった部分は、決して否定しないのだよね。「それならば」と別な方法を提案してくる。そして悔しいことに、その方法だと、少なくとも最初に俺が「こう変えなければならない」と言った方法よりは、楽に実装できそうに思えてくる。

　　　*　　　*　　　*

最初のうちはこれが悔しくて悔しくてね～。なんでプログラミングを知らない人の方が、俺よりうまい方法を考えられるんだ、と。まあその人の頭が俺よりはるかに良かったってことなんだろうけど、それで話を終えてしまうのもつまらない。

思うに、プログラマというのはしばしば「汎用的」に考えすぎる傾向があるのではなかろうか。実際に実現しなければならないのは、かなり特定の状況。しかしプログラマはどうしても一般化した解決方法を考えようとしてしまう。

一方その人は製品の製造全体を見ているので、「○○のケースはありえない」というのがわかっている。俺が「その方法だと○○のケースが処理できません」というと、一旦持ち帰って、いろんな部署に確認して、「○○のケースは処理できなくて構いません」と答えてくる。○○を考えなくていいなら、実装ははるかに簡単になる。

　　　*　　　*　　　*

あるいは全体の製造工程を変更して、そういうケースが起きないようにする。俺は自分のプログラムしか裁量の範囲がないのに、その人の裁量権は全体なんだよね。これもなんか悔しかったのだが、結果的にその人があちこちに手を回してくれるおかげで、俺の作業は楽になる。複雑な心境(苦笑)。

結局、こりゃいくら張り合っても勝負にならんとバンザイして、その後はむしろその人の考え方を見習うようになった。悔しいが…。さっきから「悔しい」を連発してるけど、本当に悔しかったんだよ！

一見、行き当たりばったりに見えることがあるんだよね。一般的な解決方法ではなく、ネックとなる部分を絶妙に回避して綱渡りしている。ただそれは俺の視界からはそう見えたのだけど、全体を見ているその人にとっては、別に問題をどこで解決してもいいわけで。俺の担当の工程で解決するのが難しいなら、その一つ前とか一つ後の工程で解決しても大勢に影響ない。

俺は自分のところしか見てないから、すべて自分のところで解決しなければならないと思い込んでしまう。

　　　*　　　*　　　*

プログラミングの能力はそれなりにあるのに、なにかと「できません」を連発するプログラマは、やたら汎用的な解決方法にこだわりすぎの傾向があるように思う。もちろんその方向で解決できるに越したことはないのだが、割り切ることも大事で、むしろあるレベルから先は、いかに割り切った思考ができるかで、設計者としての能力の差が出てくるように思う。

逆に言えば割り切り方を発見できる人間が、他の人間ができないことをできる。正攻法での解決にこだわらず、ちょっと斜めの回避方法。ただこれは自力でその境地にたどり着くのは難しいかもしれない。俺も上記の人に出会わなかったら、そういう考え方はできなかったかもしれない。

　　　*　　　*　　　*

どの本か忘れたけど、下記の本だったのではないかと思うけど、

「ライト、ついてますか―問題発見の人間学」 ドナルド・C・ゴース(著), G.M.ワインバーグ(著), 木村 泉(翻訳) 『amazon』
http://www.amazon.co.jp/dp/4320023684

こんなエピソードが載っていた。エレベーターの制御プログラムにバグがあって予定したパフォーマンスがでない。なのでいつもそのエレベーターの前には行列ができて、利用者からは不満のあらし。

そこで考えた解決方法とは…プログラムのバグをとるのではなく、エレベーターの前に鏡を設置したこと。利用者は待っている間に鏡を見て、身だしなみを整えたりするので、待ち時間の長さの不満が減った、と。

最初読んだ時「なんじゃそりゃ～」と思ったけれど、これぐらい大胆な発想ができる人というのは、ときどきいる。俺が聞いてあんぐり口を開けるような(苦笑)。そういう人はやっぱいろんなプロジェクトで活躍している。

正攻法は大切。でもそれだけだと、差がつかない。他の人がみんな失敗し、その人だけがいつも成功する…というのは、やっぱ理由がある。ここぞという時に繰り出すキワモノ的なアイディア。「問題を解決する」とはどういうことか？人間がいかに先入観にとらわれているか。その先入観を打破できる人が、一歩他人よりも先行できる。

執筆： この記事はメカAGさんのブログからご寄稿いただきました。

寄稿いただいた記事は2013年07月30日時点のものです。