誰かの役に立つものを作れるから、プログラミングは楽しい。:63.8kg

なぜプログラミングが楽しくなくなったのかにて、浜口さん曰く、

　ともかく、プログラマーのレベル認定をきちんとしそれに対応する処遇を行うこと、そしてプログラマーが創造的な能力を発揮できるよう、仕様をきちんと決めるということの重要性を世の中全体で認識し、ソフトウエア開発の仕事の割合をふやしていくことが必要なのだ

浜口さんの中では仕様を決めるという仕事とプログラミングという仕事は別のものという認識のようです。つまり、プログラマの能力とは、決められた仕様をどれだけ早く、正確に、ソースコードに落とせるかで決まってくる、と。

私はそうは思いません。プログラマの仕事には、仕様を決める作業も含まれるべきであると思います。なぜなら、ソフトウェアの動作はソースコードによって決まるからです。さらに、最近のプログラム言語は抽象度が高いので、仕様と切り離せる純粋に技術的な問題はプログラマにあまり残されていないという事情もあります。
このような理由から、私は明確な「ソースコードが仕様だ」派なのです。

仕様を決める作業と、コーディングの作業を別のものと考えたときに、仕様を決めるという作業に取り組む態度としては、以下の２通りの考え方があります。

1. ざっくり決める
2. こまかく決める

もし、プログラマに仕様を決めることを求めないのであれば、
1. の態度をとった時、仕様に書かれていない部分のソフトウェアの動作は不定となります。2. の態度をとったとき、実質的にはコーディングとほぼ同じ作業を仕様を決める作業の中で行わなければならない。しかも、仕様書はソースコードと違ってコンパイルもテストも出来ないので、仕様書のバグを検出できる可能性は、ソースコードのバグを検出できる可能性よりずっと低くなります。

どちらにしても、顧客が得をする作業分担ではなさそうです。
プログラムがかけないSEも、仕様に思いを馳せないプログラマも、顧客にとってのソフトウェアの価値を高めるということに関しては、等しく無能なのです。

だから私は、

「プログラマの仕事とは顧客の求めるものを作ることであり、仕様書どおりのものを作ることではない」

というのです。

優秀な人でも意外に基本的な知識が欠落していることはあるし、パフォーマンスが環境に左右される部分も多いので、単純なレベル認定でプログラマの能力をはかることは困難ですが、
それでも、自分以外の誰かのためにプログラムを書きたいという思いをもち、そのためにどれだけ真摯な努力を積み重ねているかが一つの判断基準になるとは考えています。

面接とかでそこを見抜くのがまた難しいのですが。。