詳細設計書ってよくわからない

わたしは、情報システムと呼ばれているものを作った経験がないので、よくわからないのだが、世の中には詳細設計書というのがあるらしい。

下記参照。
http://gm7add9.wordpress.com/2012/11/30/%E8%A9%B3%E7%B4%B0%E8%A8%AD%E8%A8%88%E6%9B%B8/

プログラムの詳細設計をやる人というのがいて、その人が書くらしい。あくまで自分には経験がないので、伝聞、想像でものを言っている。

プログラムの詳細設計というのは、プログラムへの要求仕様というのがあって、それを実現するために書くらしい。要求仕様というのは最終的な利用者が、こーゆーものが欲しいとか、こーゆーことができたらいいなということを、なんらかの方法で、なんらかの形でまとめたものらしい。

そんでもって、要求仕様を作る人と、詳細設計を作る人と、プログラムを作る人と、テストをする人と、保守する人というのがいて、それぞれ別の人がやることが多くて、同じ時間働いても、稼げるお金が違うらしい。

要求仕様を作ることを上流の作業とか工程といい、だんだん下に流れていって、プログラムを作ることを下流の作業とか工程というらしい。

自分は経験がないので、あくまで想像でものを言っている。

昭和の時代には、そーゆーこともあったのかもしれないが、さすがに21世紀、ソフトウェア開発の大半は機械化、自動化されていて、そのような作業とか製造方法は、ほとんどないのじゃないかと勝手に思っていたのだけど、どうもそうではないようだ。

なんでそんなものがいまだにあるのか理解ができない。それらしきことを教えてくれる人がいるんだけど、まったくもって素人には意味がわからない。何か、経済合理性でもあるのだろうか。

例えば、プログラムの一行一行にほぼ対応するような手順をエクセルの１行にせっせと記すとか（伝聞で書いているので真偽のほどは不明だ）、作業手順書と称して、コマンドを一行一行書いて、人がそれを打ち込んで実行するとか、なんだかよくわからない。

かりにそーゆーものがあったとして、それをそのままスクリプト化すればよくて、べつにエクセルにしこしこ書く意味がわからない。スクリプトにすれば、機械が自動的に実行してくれるわけで、人間と違って速いし、間違いもないし、不平不満も言わない。

大規模なシステムの保守をするためには、詳細設計書が必要なんだと、ありがたいことに説教してくれる人がいたりするんだけど、そこにコードがあるのに、その詳細設計書の必要性がわからない。

何十万ステップをいきなり読めと言っても読めないから詳細設計書が必要だという謎の主張をされるわけだが、何十万ステップのコードの詳細設計書が何万ステップもあったら、より素早く正確に理解できるとは到底思えない。しかも、その詳細設計書と実装が正しく一致しているとは限らないし、保守もされていないとしたら、何のための詳細設計書なのだろうか。

そんなことに時間とコストをかけるくらいだったら、ビヘイビアを記すためにテストスクリプトを書けといいたい。テストは、どう実装するかについては一切語らないが、実行結果がどうなっているべきか（期待する結果）について厳密に記している。

テストは、実装を変更したとき、リグレッション（退化）していないことを確認するほぼ唯一の方法だ。一方、詳細設計書は、リグレッションの発見に全く寄与しない。無駄である。

繰り返すけど、わたしは情報システムを作ったことがないので素人の戯言なんだけど、誰か、この詳細設計書が未だになぜ必要なのか教えてほしい。どこかに経済合理性があるのだろうか。

いや、夏祭りには花火が必要なのと一緒で、世の中経済合理性だけで語るな、ということであれば、それはそれで納得はしないけど、理解はできなくはない。

だけど、IT業界がIT使わなくてどうするのよ？と思っていたら、火にガソリンをぶっ込んでくれるエントリーを発見して、それが下記ですな。
http://blog.ueda.asia/?p=2157

結局、詳細設計書を書くような仕事の進め方をしているところは、金も時間もかかって人も浪費するので、競争力もなくて、つぶれちゃって、大変だということなんでしょうね。不思議なことになかなかつぶれないけど。

やっぱ、自前でガシガシ、内製して、詳細設計書なんか作らないで、アジリティー高く作るというのがよろしいのじゃないかと思ったり思わなかったり。あくまで想像でもの言っていますから。すいません。（ぺこり）