みんなdisってるけど、本当は詳細設計書が大好きなんでしょ？
他の方からワタシのブログを読んで、意見を教えてもらえるってうれしいことです。読んでもらえればそれだけでもめっけものだし、その上、ワタシのブログでの考えに対して何らかの意見を聞くことができるということはワタシ一人だけでは成すことができないものですから。
自分の記事のリンクを含めてブログを書いてもらうとメールでお知らせが届くんですね。それを知らなかったのでメールの受信箱をみてちょっとあせったというか。IDコールされちゃうくらいでビックリするくらいの程度なのでどんだけのレベルなのかって感じではありますけど。
で、せっかくご意見をいただいたので返礼を兼ねてワタシが当時書いた気持ちを説明させていただければ、と。
あなたの作業で得られるプログラムが顧客要件をすべて満たしているのであれば設計書はいらなくなる
↑の内容をちょっと意訳させていただくと「品質保証に必要だから」
ということだと理解しました。
意図としては、その解釈のとおりです。顧客との契約としてのアウトプット(注1)として書面上に記載されているのであれば、期限までに納入する義務を負うからです。また、契約に記載した実現する要件を実装していることを証明するエビデンスでもあるからです。
ワタシは顧客の要件＝品質と捉えています。それは、顧客の要件を満たさなければアウトプットは検収されないし、要求を超える機能の実装は不要だからです。納入するシステムを納期までに届けるために契約書に記載されたアウトプットを作るために作業を積み重ねて、その結果が彼の詳細設計書なり、試験仕様書なり、試験されたシステムとなる、と考えているからです。
その試験済みのシステムに顧客の要件が含まれているエビデンスが設計書なので、それを実装する際の作業品質、実装されていることの証明の品質管理という位置づけなのです。
１．プロジェクト要件として詳細設計書作成が納品物として設定されている。
２．ユーザさんはソースコードなんて見たくもないし、見る必要もない。
（でもギリギリ詳細設計書までは見てくれる）３．ソースコードを見たくても見れない現場がある。
a.工程が開発前であるためソースコードが無い
b.プロジェクト現場にソースコードを見るための環境が無いケース
よって、上記の項番1については、契約上要求されているとするならそのとおり、となります。
項番2については、別のブログで述べているような気がしますが、顧客のITリテラシにもよりますが、多くの顧客は業務要件からシステム要件を切り出して、その機能仕様の概念までは理解に努めようとしますがそれも引継ぎ後の機能改善や維持管理を顧客自身が担当する意識がある場合でしょう。例外は、顧客がSIer出身の場合ですね。ある程度知っているので口を挟みたくなるんでしょうね。
項番3aについては同意しますね。新規や再構築のプロジェクトならコスト低減策として現行システムのコードの再利用がなければ新規でコーディングするでしょうから。ただ、3bはどうでしょうか。ちょっと想像つかないのですが、そうしたこともあるのかもしれないですね。
実はみんな詳細設計書が好きなんでしょ？
普段しないのですが、なんとなく今日はそんな気分だったので、“詳細設計書”のキーワードではてな内検索をしてみたんです。
そしたら出てくる出てくる詳細設計書のブログが。まだ、全然見れていませんけど、一部は既読のブログもあるし。なんか、これだけdisられている(んでしょ？)というか書かれているブログの検索結果を見るだけで「なんだ、結局、嫌よ嫌よも好きの内、なんじゃないのか？」とおもってしまう。実際はどうなんでしょう。
まぁ、結局、要件からプログラムに至るまでの間に何もなくていきなりコードを掛ける人は限られるんですよね。そしてコードを書いた人が要件をどう解釈して実装したかをコードの読めない多くの顧客への説明に必要なんですよね。その説明の仕方にこれと言う決定打がないので未だ試行錯誤しているのだ、というところが本質なのでしょう。建築のように2000年以上も経てばその表現方法は変わっているかもしれません。
注1 アウトプットとしているのは、請負契約なら完成責任がある成果物、準委任契約ならドキュメントなど成果物を設けない、など契約により違うのでくるっと纏めてアウトプットとした。
＃注記の印を入れていたのに何も書いてなかった。てへっ！
