ここ最近、よくわからない設計書を目にしている。
わからない理由は、その設計書に”想い”がないためだと思っている。

　何のために作成しているのか。

作成した人が、この問いに答えられなければ、第三者が読んで理解できるとは到底思えない。
仕事だから？作らなきゃいけないものだから？、、、そうじゃないでしょ。
また、外部設計(ユーザーインターフェースなど)は出来ていても、内部設計(内部アーキテクチャなど)が無いことがある。
その会社やプロジェクトで方針が決まっていれば良いのだが、真っ新の状態では話にならない。
『開発者(プログラマー)の自由度を上げる』とか言うけど、何も考えていないだけではなかろうか。。。

設計書は、開発するために必要なこともあるけれど、メンテナンスでの方が私は重要だと考えている。
開発するときは、包括的なドキュメントよりもコミュニケーションや動くソフトウェアの方が必要となる。
システムは、作って終わりと思われるかもしれないが、作ってからが本番である。
永遠に同じ開発メンバーが、メンテナンスするはずもなく、いつかどこかで引き継ぐことがでてくる。
そのときに、当時の資料として第三者が理解できなければ意味がない。
現状がどうなっているかは、プログラムを見れば良いわけなので、『なぜそういう設計になったのか』『どうしてこういう方針をとったのか、または、とらなかったのか』が分からないと設計として役に立つレベルと言えるのだろうか。
システム稼働後に、どうしてこうなっているのか？という問いに『仕様です。』と言いたいならば、書くべきことは書いておく方がいい。

ネットで関連情報を検索していたら、こんなのが見つかった。
[url=http://itpro.nikkeibp.co.jp/article/COLUMN/20060825/246408/]意図が伝わる設計書作成の心得【第1回】[/url]
[quote]もちろん、標準の設計フォーム（ひな型）や設計書作成ガイドラインを用意することで、このような事態を避けようとしている開発現場は多いだろう。しかし、型通りに作った設計書が、常に目的にかなった“正しいもの”であるとは限らない。一番怖いのは、「設計書は何のために存在しているのか」という点を設計者がうっかり忘れているか、そもそも意識していない場合である。

筆者が考える設計書は、システム構築を目的としたコミュニケーションの「ツール」であり、そのコミュニケーションの「結果」を記述したものだ。設計書を作成する上で、標準化や定型化にとらわれ過ぎてしまうと、設計書を「何のために作るのか」という根本的かつ重要な情報が抜け落ちやすくなる。「とりあえず標準に沿って作成すればよい」という設計者の態度は、後の工程でトラブルを生む原因になりかねない。[/quote]

私もそうだと思う。
“ひな形”もあると便利なことは間違いないが、型にとらわれがちになってしまう。
その設計書のその欄に記載することが、何の意味があるのかその想いを込めたい。

[quote]それは、「設計者の口頭説明が資料に反映されていたかどうか」という点である。設計者は資料と口頭説明を駆使することで、ユーザーにシステムの仕様をうまく理解させていたかのように感じていたはずだ。しかし、ユーザーが基本設計書を読み返しても、打ち合わせで聞いた内容を思い出せなかったとしたら、実際には口頭説明の比率が高かったと思われる。

口頭説明は、話し手と聞き手の感情、その場の雰囲気、手書きの図解などによって、お互いの理解を深められる有力なコミュニケーション・ツールである。これを使わない方法はないが、口頭説明はその場限りであり、その場にいた人にしか伝わらない。後になって忘れてしまうことも多い。しかし、基本設計書は検討の結果として、後に残す必要がある。[/quote]

まあ、こういうことですね。
議事録でもいいんですが、設計書に記載してステークホルダーとの合意が大切です。

これだけ言ってるんだから、私が書いた設計書はさぞ素晴らしいと思われるかも知れないが、それは別のお話8-)

合わせて、読みたい・・・。
[url=http://xp.miyacomp.net/modules/d3diary/details.php?bid=624]ソフトウェアは、知的生産活動[/url]