IT企業の超階層化構造

Reference

ソフトウェアの仕様書は料理のレシピに似ている

とても鋭い指摘だと思う。そして、残念なことに、satoshi氏が知っているときよりも 現在の状況はさらに悪化していると思う。上記のエントリに書かれていることが、 まさしくわたしが前の会社をやめた理由。

わたしが派遣された全ての会社で共通していることは、 プログラマは「コードジェネレータ」でしかないということ。 つまり、上流過程を担当している人がつくった詳細設計書や指示の通りにコードを書く存在であって、 自分で考えて物を作ることが禁じられているだ。こんなんじゃ、プログラミングを楽しいと 思えるはずがない。また、最初に作られた設計が正しいという保証はどこにもない。

satoshi 氏も指摘していることなのですが、わたしの経験では、実際にコードを書いていく最中で 設計上の誤り ( エラートラップに落ちがあったとか ) や改善点に気付くことが多々ある。 仕様書や設計書はコードを書いていく中で適切にアップデートされるものだと思う。 ( Joel on Software のエントリにもそう書いてありますね。)

しかし、それが禁止されているのが実際の職場。さらに、実際にコードを書いたことがない人が 設計をしていたとなれば、当然のことながら後半になって欠陥が顕になり、プロジェクトは 火を噴くことになります。

プログラマはコードを書くことだけが好きなのではなくて、プログラムを創る一連の流れ 全てがすきなのだ。特に、スパイラル型の開発方法をとるプログラマにとってはどの工程も 切り離すことはできない。

「お前たちは上から渡された設計どおりにコードを書けばいい。責任は上にあるから」 とはわたしたちが職場でよく言われたことだ。しかし、これもまたプログラマのやる気を そぐか、怠惰心を刺激するかのどちらかになってしまう。人間は、自分に責任がある仕事にこそ 真剣に取り組み、出来上がったときに喜びをもてるのではないだろうか？
その機会を取り上げられてしまったらいい仕事なんてできないよ。

とはいえ、「責任を持たせる」ことがテスタが要らない理由にはならないけどね。
なぜならば、人間誰しも心のどこかに「自分の作ったものにエラーはないんじゃない？」 という慢心があるから。これは意識していても、していなくても誰にでもあると思う。 たいした技量がないと自覚しているわたしでも、指摘されて初めて気付くエラーがたくさんあるから、 やっぱり慢心があるんだろう。それに、プログラマが行うテストは自分の書いたコードが 正しく動くかどうかに偏りやすい。そう、主観的な視点からしかテストが行えないんだよ。 そして、テスタにテストをしていただくもっとも大きな理由は、プログラマの慢心が見逃してしまうような エラーを見つけてもらうことだ。

「プログラムを書く」「詳細仕様書を書く」に加えて、「書いたコードのテストをする」ことを開発者が行うことが全体の開発効率を上げることにも、開発者のモチベーションを上げることにもつながると思っています。開発者は、「動いた」ことに満足するだけでなく「すべてのケースで問題がない」ことを喜びとしたいしするべきです

とは同エントリのコメントにあった言葉だけど、多くのプログラマはこういうものだと思う。 そして、責任ある仕事を担当できたときに真剣に働いて、達成できたときに喜ぶんじゃないかな？

客という視点から見ても、責任がないからとてきとーに流してしまうようなプログラマが 仕事をしているような会社に委託するよりも、自分が頼んだ仕事を全てのメンバーが責任を持って胸を張って取り組んでくれるところに委託したいと思うに違いない。

レストランのシェフが自ら料理をしたり、下っ端の料理人の作ったスープの味見をするとの同じである。もちろん、レストランに行く側の立場になってみれば、そんなレストランで食事をしたいのは当然である。シェフがレシピだけ書いてキッチンにも立たないレストランには行きたくないし、ましてや自分で料理したこともないシェフが書いたレシピを元に作った料理がおいしいわけがない。( 同エントリより抜粋 )

まさしく、この通りだよ。

P.S. 責任ある仕事を担当できたときに真剣に働くというのは、 IT 業種だけではなくて全ての職業についていえることだと思う。