April 13, 2008

プログラマが仕様を決めればいい - GoTheDistance

から、以下のようなはてブコメントを書いてみた。

「誰がやっても同じものを作れる」←これの目的は本来後で管理できるようにすることのはずだが、生産の観点で用いられるのが妙。紙の上で妄想する工数って前に進んでないから間違いなくコスト高いと思う。

で、他の人が以下のようなコメントをつけていたのを見た。

どうしてエラい人はインドや中国を使いたがるんだろうか？本当に謎だ。

それは受注額に対して上流工程にかかるコストが高すぎるからでは？

とか思ってみたり。お給料とかね。

みんな効率化したいという話はあっても、自分の給料を下げても良いという人はいないからね。

オフショアにせよ常駐にせよ、ネイティブ非Japaneseに対して、ネイティブJapaneseが作った仕様書使って開発するのが簡単じゃないのは上司だって当然わかってると思うけど、それでもやらなきゃいけないとしたら、儲かってないからなのかなーと。（なんか町工場みたいな話になってきたぞ。）

それはさておき、「誰がやっても同じものを作れる」ための仕様書は、成果物がビジネスで使うもので、１０年後でも管理できるべきという本来の目的上、絶対に必要だと思うので、やっぱり誰かにコストをかけて作ってもらう必要はあるんじゃないかと思います。

実装だけでは、やっぱりそこにある文脈は読めないですからね。

要件定義を元にプログラマーが開発し、コメントドリブンでソースコードから抽出したコメントに文脈を加筆して、機能仕様書として顧客とレビューすることで、ソースコードが要件にあっているか？というコメントドリブン仕様書ってのはあっても良いのかなとか妄想してみた。

文脈とコメントが分離していて、もし実装が間違っていたら、修正したソースコードからもう一度コメントを抽出して文脈の方と矛盾がなくなっていたらＯＫみたいな感じで。ソースコード中の条件分岐ぐらいは自動認識して簡易フローチャートができても良いと思う。

進捗管理だって、いつだってソースコードから実態把握できるわけだし。

今はそういう仕事に絡む機会もない生活なので、外野からの思いつきですが、そういう視点から見て、もはやペーパープログラミングのような細かい仕様書作成に時間をかけるのは、お金かけてるなーと思います。