設計書が必要な理由

「ソースコードが設計書。だから別の設計資料なんか要らない」と言っている人がいた。Webでも同じような見解を見ることがあるし、こんな運用ルールで事足りる開発現場も有るのだろう。確かにこれはこれで一理あると思う。私だって個人的に作っているソフトに、必ずしも設計書を作っているわけではない。

しかし、100万行単位のレベルで組織的にソフトウェア開発を行っている現場（うちのことだ）では、こんなやり方は通用しない。理由は下記の通り。

• ある機能が100万行のソースコードの何処に入っているか分からない。
• そもそも、ある機能が100万行のコードの中に含まれているのか分からない。
• 機能追加・変更・修正に伴う影響範囲が、100万行のコードの何処まで及ぶのか分からない。

例えば、開発現場に入ってきたばかりの協力会社の人に応援を頼む場合、100万行というコードの海を直ぐに泳げと言うのは、無理な相談だろう。そこで作業の手がかりとして、設計資料の出番となる。この資料には下記の内容が記載されていることが必要だ。

• システムの概要が記載されていること。
• モジュール単位での機能・役割が記載されていること。
• 主要なデータの流れが記載されていること。

もちろんこれらは単一の資料ではない。最初の手がかりとしてはシステム構成図1枚だけで充分だし、ここを起点としてそれぞれ個別の資料を当たっていけば良い。Google Mapのように、先に進むほど詳しい情報が載っている資料を辿っていく形になれば良い。詳しいことはソースコードを見れば分かる。開発者なのだからその位のことは出来て当たり前だ。

問題なのはそのソースコードが一体何処にあり、変更・修正に伴う影響範囲がどこまで及ぶのか？ということだ。100万行のコードを一つ一つ追っていくようでは、納期に間に合わせる作業が不可能だ。開発者を適切な作業現場へ導くための道標として、テスト範囲を絞り込むための判断材料として、限られた期間で開発作業を終了させるための道具として、設計書は有効なのだ。