詳細設計書が必要・必要でない論が盛り上がっているようです。
詳細設計書という名のゴミ | Gm7add9
プログラムの自動生成という夢想
中には、詳細設計書＝プログラム1行1行を日本語っぽいもので書いたものが詳細設計書っていうプロジェクトもあるんですが、そういうプロジェクトのリーダとかは「詳細設計書からプログラムの自動生成できてハッピー」という現状できていないことに対して夢想しているだけです。
プログラムを全部読むのが大変なので、簡潔に何をやっているかを把握するために設計書が存在するのに、なぜそれをぶち壊そうとするのかが全然理解できません。
Javadocでいいんじゃね？
詳細設計書は結局Javadocレベルで個人的には十分だと思っています。コメントにこのクラスやメソッドが何やっているのかを書いて、それを自動生成させてドキュメントとして認めさせる。
WordやExcelではありませんので「設計書」と呼ぶのは抵抗があるかもしれませんが、どうせ誰も見ません。
プログラムから設計書を自動生成させる
中には、Excelからプログラムソースを生成させて「自動生成Happy！」って叫ぶ人も居ますが、管理すべきものが増えてどちらか一方だけのメンテナンスになることは目に見えていて、それはいくらルールで縛っても無駄ってものです。
こんなルールを作ると、ルールを守っているかチェックする人がプロジェクトに追加され、もう、目も当てられません。
大事なことなので二度目ですが、プログラムから設計書を自動生成させるのが効率が良く、設計書からプログラムを生成させてはダメです。
やることが曖昧
さて、そもそもプロジェクトの各工程でやることと工程の成果物が曖昧になっているのが今のSIerの問題と思っています。
基本設計・詳細設計・プログラミング・机上デバック・単体テスト・結合テスト・総合テストと各工程がありますが、それぞれ何をやって何が成果物か定められているプロジェクトをここ数年、見たことがありません。
基本設計とか詳細設計とか
基本設計工程や詳細設計工程では、基本設計書に書くことと詳細設計書に書くことがまったく定義されずに、予定されている時間が来たら「ここまで書けている内容で基本（詳細）設計書としましょう」となり、あとの工程に先延ばしにします。う〜ん、ウォーターフォールは先延ばしにすると死ねるってみんな習うのに、なんていとも簡単に先延ばしするんですかね。ココらへん、プロマネやQAが全くもって仕事していないように思えます。
あ、結局、詳細設計工程で書くべき内容が書かれていないので、プログラムの自動生成なんて出来ないのは明らかですね。
続いて、プログラミング以降の工程。
COBOLでバッチを作っていた時はまだ明らかで、ソースファイル1本がプログラム1本に対応していました。このため、詳細設計書も単体テストも結合テストもそれぞれ分かりやすく分類できたのです。
今では、1つのWeb画面が複数のソースファイルで構成されています。それを無視して、単体テストをプログラム単体のテスト、結合テストを複数の画面を組み合わせたテストと定義し、単体テストと結合テストの間に大きなギャップを生じさせています。
どう考えても工程が足りないのです。それでいて机上デバックという工程では「コーディングルールが守られているかA3にフォントサイズ9で書かれたチェックリストによるチェックを目視で行う」というものがあって、本当に21世紀ですか？と思う今日このごろです。そんなチェックリスト作る暇があったら、Eclipseプラグインの調査して、自動チェッカツールの整備でもすればいいものを。
