「企画マンの思いつきによる変化を嫌がる」のがプログラマ

http://d.hatena.ne.jp/ryoko_komachi/20050625/1119754319　を読んで。
技術系の人たちには常識だけど「変化を楽しむ」というプログラマはかなり少数派。
砕けた言い方をすると「文系のマネージャーだとか企画マンのちょっとした気まぐれみたいな思いつきでコードを書かされるなんて真っ平ごめんだ。技術論を吹っかけてそんなのは出来ないよとつっぱねちゃえ。悔しかったらコードをどれだけ修正する必要があるのか把握してから修正案を出せよ」という感じ。
そういえばid:naoyaさんの僕やはてながPerlを選ぶ理由 - naoyaのはてなダイアリーで、Perlという動的言語を使っている話を書いていたけど。
これの根本は「変化を続けられる開発体制」ということだよね。ウォーターフォールを否定するなだの仕様書を書くのが必要だのという妙な方向に議論が発火したりもしたけど。話のフォーカスはそこにはなくて「はてなが進化し続けるために選んだ言語がPerlだった」ということだと俺は解釈している。改善だとか進化ってのはエンジンを点火させたまま飛行機の整備をするみたいなもんで。壊して墜落させないようにとても気を使う作業だ。だからコード量が少なくて済むPerlだのRubyだのPythonみたいな軽量言語が向いている。（OOPで書けて処理を分離できるというのも重要）

「あー、あそこを修正するともっと気持ちよくなるな」と思いついて、それをノリノリで「夜のコーディング」で構築する。これが開発者にとって一番面白いところ。（その後に「XSS脆弱性があるじゃんか!!」とか指摘されて「朝のデバッグ」で直したりするのだが。「次こそは脆弱性を組み込まないようなコーディング手法をしよう。めんどくさくてたまんねぇや」と嘆いたりする）
こういうサイクルに乗せるためには、企画マンと開発者が同じ方向を向いている必要がある。だから「コードで書くとどれだけめんどくさいのか」を把握していないと企画マンは通用しない。
（追記 作ったプログラムなんてすぐに忘れる : blog.nomadscafe.jp ）