コードが仕様です。

プログラミングという作業は、「仕様書の内容を単純にソースコードに変換する事」
だと思っている人もいるかもしれないが、それは違う。

また、「仕様書があれば、誰が作っても同じものができあがるんだ」
と思い込んでいる人がいるようだが、それは違う。また、そうであるべきだという考え方もあるが、
その場合、どれ程の詳細な仕様書を揃えれば実現できると思っているのだろうか。
ヘソで茶が沸くくらいに非現実的な話である。人月神話とはまさにこのこと。

数学の「解」を導き出す方法がいくつもあるのと同じように、
アプリケーションの単純な機能を１つを作るにも、プログラムとして実装する方法はいくつもある。
プログラマは、そのいくつもの選択肢から最良の方法を選択する必要がある。
つまり、仕様書で実装方法についての説明が全くなされていない場合、
どのような方法で実装するかは、プログラマ個人の判断に委ねられる部分が大きい。
そのため、同じ仕様書からでも、産まれるプログラムの品質*1はピンキリとなってしまう。

例えば、オブジェクト指向に精通しているプログラマと、
そうではないプログラマが作ったプログラムでは、その差は顕著に現れるだろう。*2
また、いわゆる"プログラミングセンス"の差は、面白いくらいに品質の差を広げる。
そして、プログラマ同士の意見交換やコミュニケーション不足も、品質に大きな影響を与えるだろう。

品質がどちらに転ぶかは、プログラマの持つ実力の違いはもちろんのこと、
過去の言語経験やプログラミングに対する思想、あるいは体調やモチベーションの高さ、
更に言えば性格によるものなど、非常に多岐に渡る要素次第ということになる。*3
それらの要素に品質が左右されないためには、有識者によるソースコードレビューが当然必要となってくる。

プログラミングとは、与えられた仕様書を見ながら、
更に細かいレベルの設計*4を行う作業であるといっても過言ではない。
少々乱暴な言い方になるが、プログラマが書いているソースコードこそが、
プログラムを作るために必要なすべての仕様が記された、本当の意味での仕様書だと言っていいだろう。
その本当の意味での仕様書がザルだと・・・、結果は明らかである。

*1:ここで言う品質とは、ソフトウェアそのものの品質という意味に加え、ソースコードの価値、クラスの価値、保守性・拡張性などを含めた意味での品質である。

*2:オブジェクト指向言語を用いているならば、オブジェクト指向によるロジックを記述するのが「普通」なのだが、それを出来ない(オブジェクト指向を理解していない)プログラマがまだまだ多いという「不良債権」が足枷となっているのが実情。これは由々しき問題であるが、本人達に自覚がない以上改善は難しい。

*3:中でも、軽視されがちな「モチベーション」は無視できない大きな要素のひとつだろう。

*4:実装レベルの設計。あるいは要件レベルに対する突っ込み、あるいは提案など。