■

プログラム仕様書が要らないとか無駄だとかは大嘘
http://d.hatena.ne.jp/oredoco/20080415/1208222548

とりあえず読んでみていろいろ思って、とりあえずほかの読んでから〜と思ったら
言いたいことが要約されて書いてあった。

日本語を読むスピードでプログラムを読めないの意味がわからない
http://d.hatena.ne.jp/kokorohamoe/20080415/1208258110

汚い仕様書なんて論外とかいわれそうだが、そういう　現実に存在していて困ってるから、いっそのことプログラムだけでも良いという議論がスタートしている　事を忘れちゃ行けない。

論理的に仕様書が不要とはいっていない。　
現実問題として、なくてもなんとかなるケースがあったり、ない方が良いケースもあるということ。
理学と工学の違い。

スタート地点忘れたらいけねぇ。
論点のポイントがコロコロ変わるの基本的によろしかない。
消化して次にいくのではない場合ね。

[体験談]

前に詳細設計という名のプログラム設計作業をやった時のこと。
この時も「誰が作っても同じモノになる」が掲げられて作業にあたることとなった。
それはいい。
フォーマットを作った。
誰が作っても同じようになるレベルの記述体裁。
クラス設計、メソッド設計をやる作業と同じことを行いながら日本語を書いた。
そしたら枚数が増えた。
クラスやメソッドは増えるもんだ。
そしたらなんと言われたか。

(..´Д｀)＜枚数増えすぎはよくない

個人的には同感な意見だが、お題をクリアするにはいたし方がない。
ついでに会議で議題にしたこと。

(,,ﾟДﾟ)＜このレベルならそのままソースに落とせます。
　　　　少なくともクラスとメソッドの構築の枠は揃えられるでしょう。
　　　　しかしてこのボリュームを書ききれる要員があと何人いるでしょうか？

構造化された書類は、実はコピペで大半の体裁が整うため、
情報整理さえしっかり出来れば書類の生産性は高いのだが、
それが万人にできるかどうかは別問題なのだ。

結局、「工数がかかりすぎる」っともっともらしい理由がつけられた。
が、
現実的には、そんなレベルの書類を作るくらいなら、
同じ人間が30倍早く実際に動作するコードを書類と同じような体裁で記述できることが、
技術者の間では同意されたためヤメになった。

書類しか理解できない人間には途方も無い話かもしれないが、そーゆー世界があるってこった。
ボクらにとって、日本語を読むようなプログラムソースを構築するのは、
日本語で構築するよりもずっとずっと早く正確に行えるのですよ。
テキストエディタとIDE万歳。

でもね。でもね。
クラスを設計書ファイルに置き換え、
メソッドを項目タイトルに置き換えたら
「誰が作っても同じような〜」に近づけるんだ。
構成そのまま翻訳すればいいだけだから。
コーダーのニーズが出るから、人月稼ぐにゃいい手法なんだよ。

ただ、書ける人間はプログラムを仕様書なしで組めた上で、
それを構造化し、日本語化できる能力が必要とされるため、
絶対数がいない。
なによりそんな人材を無駄遣いするのが心苦しい。

[オレ的結論]

綺麗な日本語と、綺麗なプログラムは等価です。どちらでも読めます。
スパゲティな日本語と、スパゲティなプログラムは等価です。どちらでも読みづらいです。。

コレに賛成した上で。

こちらの
http://www.milkstand.net/fsgarage/archives/001219.html

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

本来の目的を果たすために何をどうするか？
今ある手順はどうだろうか？
どう変えたら本来の目的を果たせるようになるのか？

それを考えていくことがいいと思います。

どちらでも作れるのは技術者として当然のことなのですが、
作業効率と費用対効果を考慮したら「技術者」ばかりなら書類後付でもかまわないし、
「技術者」がいなければ書類が先〜なんてことを言わずに手をださないのが世の中のためだとボクは言う。