詳細設計書は必要でしょ

不定期に不死鳥の様によみがえる話題、今週は「詳細設計書不要論」でーす(笑)

もちろん自分は詳細設計書は必要だと思っているが、SIerの仕事において、という前提がある。
一人で要件決めから実装まで行うなら設計書なしでもいい。
しかしSIerの仕事、つまり「発注者から依頼を受け、複数人で開発するプロジェクト」は、設計書が無いと成り立たないと思う。
（あと、自分はウォーターフォールモデルを前提にしていてアジャイルは知らないが、アジャイルでも設計書という呼び方ではないかもしれないが設計書相当のものはあるはずだと思う） 

---

自分が考える詳細設計書の使い道は、以下の通り。

１．【設計フェーズ】発注者に対して処理内容を説明する（承認をもらう）
２．【実装フェーズ】実装者に渡して実装してもらう
３．【試験フェーズ】出力結果を検証する
４．【保守フェーズ】現在の仕様（過去の経緯）を確認する

順序として、設計フェーズ→実装フェーズ→試験フェーズ→…→運用・保守フェーズ と考えている。
（試験にも色々種類があるので、実装フェーズに含まれる部分もあるかもしれないけど） 

１は、要するに詳細設計書のレビュー。
レビューするのは発注元の企業であることもあるかもしれないが、一次SIerであることの方が多いと思う。
実際に詳細設計書を書くのが二次SIer以下であっても、一次SIerが確認・承認して責任を持つものだと思うが。ただ単に伝言ゲームをするだけだったら（以下略）

２は、“実装”以外に説明する言葉を知らない＾＾；
実装者側も、何を作ればいいのか示してもらわないと作りようが無いからねぇ(笑)
複数の実装者が居る場合に、設計書抜きで（口頭で？）何を作るか指示するとか、ありえないでしょう。

３は、単体テストになるのか結合テストになるのかはよく分からないけど。
ブラックボックステストの入力データおよび期待される出力結果は、詳細設計書から抽出する。
設計書に書かれていることが正しい（その為に事前に設計書レビューを行って承認を得ている）ので、作ったプログラムが設計書通りに動くかを確認するのがテストの目的だと思っている。
（ちなみに、受け入れテストは発注者の思っている通りになっているかを確認するものだと思うが、この「思っていること」が文書化されていないと揉める原因になるよなぁ） 

４は、運用・保守に入ってから、現状の仕様を確認するという想定。
バグっぽいと思われる動きを見つけたり仕様変更をしたりしたい場合に、今の仕様がどうなっているのかを確認したくなるのはよくあること。
まぁ、紙（設計書）に書かれていることが本当に実装されているかどうかが疑われて結局ソースを見ることになる、というのがほとんどな気もするけど＾＾；

１～３については、詳細設計書はそのフェーズより前に必要。
４については実装後の話になるので、仕様を確認できる資料がありさえすれば、詳細設計書である必要は無い。
むしろ、実際に動かしてから分かった知見や注意点などをまとめた資料はあると便利なのだが、それは設計書ではないわなぁ。
（設計書を書かずに実装して、後から実装を見ながら設計書を作るという話もちらほら聞くが(苦笑) 「プログラム説明書」なら、後から作ってもおかしくないと思うんだけど） 

---

「詳細設計書は不要」と言う人の話を聞いていると、「それは詳細設計書の内容がおかしいんじゃないか？」と思うことがある。

実装したプログラムと１：１になるようなドキュメントは、自分は詳細設計書ではなく「プログラム仕様書」と呼んでいる。
プログラム仕様書はまさにプログラムと１：１になるようなイメージで、メソッド名やら引数やら変数名まで書く。あるいは日本語で書いたプログラムのようになる。
そして、プログラム仕様書だったら、それは要らないと思う。

自分は、詳細設計書は1バッチあるいは1画面につき1つずつ作るイメージでいる。
画面の場合は、例えば入力画面→確認画面→完了報告画面という一連の流れで1つの詳細設計書、というくくりは出来るかもしれないが。 

で、詳細設計書には、どういう入力からどういう出力をするか、を書くものだと思う。
入出力先はファイルだったりDBのテーブルだったり画面だったりする。さすがにこれが具体的でないと実装のしようが無いので。
出力内容は、要するにどういう演算をするか、ということになる。ここを具体的に書くと、場合によってはプログラムと１：１に近くなることもあるかもしれないが、それは仕方ない。
それと、詳細設計書は発注者の業務内容を表しているものであり、発注者に確認してもらう必要もあるので、処理内容は発注者が使っている言葉（つまり日本語）（業務ドメインと言うの？）で書くべきだろう。

詳細設計書における処理内容の記述では、「どういう演算を行うか」を書くべきであり、「演算をどうやって行うか」は書くべきではない。

例えば明細テーブルから指定された顧客の金額A,金額B項目のそれぞれの合算値を取得したいとする。SQLっぽいイメージで言うと「select sum(金額A), sum(金額B) from 明細 where key=顧客番号」みたいな。
（プログラマーだと、SQLの方が分かりやすいし誤解が無いよねー(笑)）
ところが、実装方式としては、「select sum(金額A) from 明細 where key=顧客番号」「select sum(金額B) from 明細 where key=顧客番号」とSQLを2回発行しても望む結果は得られる。
あるいは、「select 金額A, 金額B from 明細 where key=顧客番号」で集計前のレコード一覧を取得し、取得した側で合算を行うことでも望む結果は得られる。
どの方式でもやりたかったこと（明細テーブルから指定された顧客の金額A,金額B項目のそれぞれの合算値を取得）は満たしているから、詳細設計書の期待する通りに実装されていると言えるだろう。
必要なのは設計書通りにシステムが動いていることなのだから、どう実装されているかは関係ないのだし。（設計書は発注者にレビューしてもらって承認を取っている前提なので、開発側としては「設計書通りにシステムが作られている」のを目指すことになる）
（余談だが、今の例は単純なので一番最初のselect文がいいと思うが、DBサーバーの負荷が高くて集計処理はさせない、という現場もありうるorz（あくまで可能性の問題ですじょ?!）。それだと一番最後のselect文の方がいい。でも将来DBサーバーが良くなったら、最初のselect文に変更してもいいだろう。どちらであっても詳細設計書上に書かれている仕様は満たしている。しかしもし設計書上にSQL（実装方式）を書いていたら、その他の方式のSQLは仕様を満たしていないということになってしまう）

もちろん、実際に実装する際に実行効率や保守効率が悪いプログラムを作るのは良くない。
でも実装レベルのそれは、プログラマーの実力やソースコードレビューで担保するものであり、詳細設計書とは別の話だと思う。
（したがって、プログラマーは“ただ単に詳細設計書の日本語をプログラミング言語に変換するだけの作業者”ではない）

プログラマーの質が低いことを想定して詳細設計書に実装レベルの話まで盛り込むのは筋が違う。
実装レベルの話を書きたいなら、詳細設計書でなくプログラム仕様書を書くべき。（プログラム仕様書を書くのは机上でコーディングするに等しいので、本当に無駄だと思うが）

（もっとも、自分も詳細設計書にプログラマー向けのSQLを書いたこともあるけどね＾＾；
保守フェーズに入ってからの追加開発とかだと実装イメージの方が先に浮かぶし、実際にSQLを書いて実現可能性を検証できるし伝える際も誤解が無いし。とは言え詳細設計書の本文に堂々と書くのはやりすぎなので、詳細設計書がExcel方眼紙だった！のをいいことに、セルのコメント機能で埋め込んでた(爆)） 

---

予想通り長くなってしまったので、これくらいにしておきます＾＾；

本当は、
・（「詳細設計書」という）言葉からイメージされる内容が人によって違うので、それをどうやって統一すべきか（教育の問題）とか
・設計書に業務ドメインで物を記述するなら、SEにはプログラミングの知識よりも業務知識が優先されるというSIerの考え方にも一理ある？とか
・とは言え詳細設計書に実現不可能なことを書くわけにはいかないので、実現可能かどうかを試すの（プロトタイピング？）はどこでやるべきなの？とか
・実装レベルの品質を上げる（各プログラムの統一を図る）為にフレームワークを用意したりコーディング規約を定めたりサンプルを用意したりレビューを行ったり徹底させたりする人（自分はそれをアーキテクトと呼んでいる。SIer内の上級プログラマーとして目指すならアーキテクトかなぁ）が必要だよねとか
の話も書きたかったけど、まぁ機会と気力があったら。