疑似コードまで記述する
表記法が確立している場合は，それに従えばよい。標準的な表記法がない場合はやっかいだ。
ウルシステムズの竹田正和氏（シニアコンサルタント）は，あるプロジェクトで業務フロー図をどこまで書けばよいか悩んだ。オフショアの開発会社を含めて4次請けまであり，意図が伝わりにくいと感じたからだ。
そこで作成したのが図3の業務フロー図。まず意識したのは，設計の背景を明らかにすること。結果だけを連ねるのではなく，読み手が「なぜ？」と思いがちな部分に吹き出しを付けた。データ操作は対象のテーブルだけでなく，カラム単位まで記述した。
図3●設計の背景やカラム単位のデータ操作を書き込んだ業務フロー図の例
ウルシステムズの竹田正和氏が製造業向け開発プロジェクトで作成した設計書。設計の背景を吹き出しで示したほか，データ操作をテーブル単位ではなく，カラム単位まで書き込んだ。例外処理を含めた分岐処理も漏れなく記述している
[画像のクリックで拡大表示]
さらに，疑似コードまで書き込んだ。「4次請けまであろうが，オフショアに発注しようが，ここまで書き込めばそれに従ってプログラミングしてくれる。時間はかかったが，その分手戻りや問い合わせがほとんどなかった」と竹田氏は振り返る。
読み手ごとに不足を確認する
不足を回避するには，そもそも何が必要な情報なのかを整理する必要がある。富士通の廣瀬守克氏は2007年8月，現場の経験に基づき設計書の抜け・漏れ確認リストを作成した（図4）。画面レイアウトや画面項目定義など11のドキュメントを対象に全257項目を洗い出したものである。
図4●読み手ごとに観点を分けた「抜け・漏れ確認リスト」の例
富士通の廣瀬守克氏は，基本設計書（11種類）の抜け・漏れ確認リストを作成した。全部で257項目ある。読み手を4タイプに分け，タイプごとに情報の重要度を付けている
[画像のクリックで拡大表示]
各項目に読み手ごとの重要度を付けた。読み手には「ユーザー」「プロジェクト・マネージャ（PM）/SE」「プログラマ」「運用/保守」の4タイプを設定した。例えば「画面項目の名称（日本語/英字）を明確にする」という項目は，ユーザーやPM/SEには必須である。「必要最低限の情報を確実に押さえることに主眼を置いた」と廣瀬氏は言う。
