プログラミングファースト開発とか

正直あんまり賛成はできないかなー。

現状が「仕様を決める(仕様書を書く)→プログラミング」という順番が一般的になっているので、その反発として「ファースト」とするのには気持ち的にはわかるけど．．．

実際問題として仕様書に残しながらやったほうがいいことと、プログラミングをしながら確認してもらったほうがいいことがあるので、両方同時にBreakDownしていくのが一番よいと思うし、僕はできるだけそうしてる。

ソースと仕様書は対等であって相互補完の関係であるべき。少なくても業務アプリケーションではそれが理想だと思ってます。

さらに何故そういうことができないのかというと、売り上げの問題を指摘しているけど、根本的な問題はソフトウェアの品質の定義が違うからなんだと思う。

ソフトウェアの品質とは何ですか？という問いに対して、ソフトウェアが仕様の通りに動くことです！って答えがあって、さらに仕様とはもちろん仕様書に書いてあることです！。こういう品質の定義の前では仕様書→コードという順番になるのは当然だし、そうなってくるとソースを見ないでもメンテナンスができるドキュメントがありますとか、ソースと同じドキュメントがそろってますというのが品質とみなされるのは必然的な流れなんじゃないかと。これが仕様書ベースの品質。

一方でアジャイルに代表されるソフトウェアの品質というのは、「どれだけユーザの役に立つか？」という所に重点を置く品質。極端な話、仕様書がなくても、ソフトウェアがバグバグだったとしても結果としてユーザの役に立ちさえすれば品質が高いということになる。だからバグが怖いからと言ってユーザの要望に背いてソフトウェアを変更しないという判断は低品質に向かうことになる。反対にソフトウェアを変更したことでユーザに利益をもたらせれば仮にバグが混入して小さな迷惑をかけることになったとしてもトータルでは高品質になる。こっちはあえて言えばアジャイル的な品質。

ややこしいのはケント・ベックの白本でさえこの違いを認識していなくて「高品質」をバグがないと言う意味で用いていて、アジャイルという手法がソフトウェアの品質を根本的に定義し直していて、開発者もユーザも愚直に「役に立つソフトウェア」にコミットする手法なんだと指摘していない事。

だから、アジャイルとかプログラミングファーストとかしたいんだったらソフトウェアの品質を定義し直すのが近道なんじゃないの？とか思う今日この頃。