未来のいつか/hyoshiokの日記 このページをアンテナに追加 RSSフィード Twitter

2014-03-10

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

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

下記参照。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

http://blog.ueda.asia/?p=2157

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

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

atmark0204atmark0204 2014/03/11 03:04 >何のための詳細設計書なのだろうか。
契約のため、だと思います。

要件定義→基本設計→詳細設計と(担当は別の会社で)工程が進む際、
大手SIer「要件定義書作ったのでレビューしてね、もしレビュー・納品後に漏れがあったら別料金で対応ね」
中堅SIer「基本設計(以下略)」

SIerから企画〜運営まで内製でやってるような会社に転職した人は一度はこういう構造にやりきれない思いを抱いてたのではないかと思いますね。

nonamenoname 2014/03/11 07:07 その昔、ソフトウェアはタダ、みたいな時代があってね。
いまだに国の補助金とかはソフトにはでないものがあったりね。

そんな感じで、客が、客の客にコストを説明するために必要だったりするんだ。
詳細設計書にグラムなんぼで金と時間を出してくれるんだ。

コードを書くためには不要だし、ドキュメントをメンテするなんて無意味だけど、
客が納得して金を払ってくれるんだからやるって連中はいるんだよ。

あなたの想像を超えてるところで経済活動をしてるんだ。
金になるなら賽の河原の石積みも喜んでやるって精鋭部隊だから、づぶれないんじゃないかな。

nonamenoname 2014/03/11 10:04 要求仕様に必要なことがすべて定義されていれば詳細設計は必要ないのです。
仕様をプログラムにしていくと論理の矛盾が明らかになります。また想定されていなかったケースが明らかになっていきます。

要求仕様が完全ならばプログラムはとうの昔に自動化されていますが、人間が自然言語で完全な動作仕様を書くのは不可能です。書けたとするとそれがプログラミング言語です。
詳細設計は要求仕様とプログラミング言語を埋める存在です。

たしかに要求仕様から直接プログラムにしていくというやり方(納入ドキュメントは自動生成するなどしてでっちあげる)をする場合もありますが、そのプログラムは後にメンテナンスが出来ないものになります。プログラムはドキュメントではないからです。
設計の背景を記録するものとしても必要なのです。

nonamenoname 2014/03/11 10:17 ちょっと誤解していました。リンク先はあまりに詳細すぎる詳細設計ドキュメント化作業の弊害ですね。詳細設計自体はプログラミングの時に必ずやっている作業です(直接エディタでコーディングしていても)。
一行一行に対応するようなものはやりすぎです。
別の人(コーダー)に渡すためのものというより、プログラマがコーディングに必要な構造を自分で書くものだと思います。

まきまき 2014/03/11 11:02 同じことに疑問を持った人が、CASEツールと呼ばれるものを作ったんで、調べてみると良い。
釣りでなければね。

詳細仕様を書いたらコードになるって会社は、実在する。
上流の大手SI会社の社員は、言語仕様じゃなくて、CASEツールの使い方を教わるところもあったくらいだ。

pizzapizza 2014/03/11 18:23 コードを読み書きできない人に理解、承認してもらうためにあります。
関係者全員がコードを読み書きできる場合は不要ですね。

pocaripocari 2014/03/11 23:57 不必要という意見には概ね同意しますが、「概要/詳細設計書」と呼ばれるものがプロジェクトによって記述レベルが違うのでそれ次第な気がしますね。

スパム対策のためのダミーです。もし見えても何も入力しないでください
ゲスト


画像認証