システム概要を示す設計書の必要性と作成ポイント

表題の通りですが、システム開発で本当に必要な設計書は、システムの概要を示す設計書です。
そのような設計書があれば、実装を知らない立場の人（例えば要件定義担当や上位の設計者）との意思疎通がスムーズになりますし、開発者を新たに向かい入れる時にも実装の内容をスムーズに理解してもらえるようになります。

例として、在庫確認モジュールを開発しているとします。
具体的な実装としては以下のイメージとします。
実際には、「：」の箇所に数行～数十行のコードが書かれているイメージです。

【実装イメージ】

良くない設計書の例としては、以下のようなものがあります。
（残念ながら、実務でも見かけることがあります）

・ソースコードと１対１対応の設計書

ソースコードを１行１行日本語に訳したような設計書は良くありません。
そのような設計書は記述量が多くなり、作成するのも大変ですし、それを読んで内容を理解するのも大変です。
また、日本語（自然言語）は意味が曖昧になりがちなので内容も不正確になります。
更に、ソースコードに些末な変更を行う度に、設計書の更新も必要になるという問題もあります。
（設計書の更新を忘れると、設計書を信用できなくなる）

・見た目だけで内容に乏しい設計書

経験が浅く見様見真似で設計業務に当たっている場合、以下の絵のような見た目だけで内容に乏しい設計書を作成しがちです。
（この例の絵は少し誇張しすぎですが）

しかし、設計書はかっこ良く見せる資料ではなく、実装に直接的・間接的に関わる人と意思疎通を取るための資料なので、実装内容が早く正確に伝わればそれで良いです。
どのような設計書を作れば良いかイメージが付きにくい場合は、現現場の既存の設計書や他現場の設計書を参考にしたり、先輩社員に聞いたりすると良いでしょう。

システムの概要が早く正確に伝わる設計書が良い設計書です。
例えば、以下のような処理概要を掴めるフローチャートは良い設計書です。

このような設計書があれば、要件定義担当や上位の設計者が全体像をつかみやすくなり、レビュー（要件や全体の設計の観点から見て問題がないことの確認）が捗ります。
また、新たに開発者を向かい入れる場合にも、モジュールの全体像を掴んでもらってから、必要に応じて細かい箇所を確認してもらうことができるようになります。

いかがでしたでしょうか。

良い設計書を書けるようになることが、PGからSEへのステップアップの鍵です。
システムの概要を示すことを意識することが重要で、それを意識しながら実務にあたると、自ずと良い設計書が書けるようになるでしょう。