「設計書」というのは、作るものの構造を抽象的に表現したものと言うことができます。
ただ、ソフトウェアの抽象化の仕組みはプログラミングコード自体に備わっているので、ソフトウェア生成可能な抽象的表現というのはコード表現ができるはずですね。コードで表現しておくと、整合性のチェックとかも行いやすいです。
でも、コードではない「詳細設計書」というものが一部業界には必要とされているので、その「詳細設計書」というのは実際はなんなのか考えてみます。
※ 最初はタイトルは「設計書」としてましたが、話を限定するため「詳細設計書」に変更しました。
追記：納品物に関する記述を追加しました。
表現を変えたコーディング
ソフトウェア生成可能な抽象的表現というのはコード表現ができるわけですが、文字で表記する必要もなく、ダイアグラムで表現することもできますね。
代表的なのがER図やクラス図で、これは文字表現との相互変換が可能です。クラス図はclass定義から生成したほうが楽だったり、DB定義は図でやるほうが楽だったりします。
処理については、フローチャートやScratchがありますね。
画面仕様も、最初から画面デザイナでやっておけばーという気持ちになったりします。
その点では、このような文書を作る「設計」の作業は、プログラミング作業を表記を変えて前倒しでやっているとも言えます。
実装可能性を高めれば高めるほど、プログラミングに近づきます。実装力が低いプログラマを想定するときは、一度実装したものを書き起こす、みたいな話を聞いたりもしますね。
机上プロトタイプ
設計書が表現を変えたコーディングであるなら、その検証作業は机上での実行シミュレーションになりますね。ということは、設計書というのは、机上プロトタイプであるとも言えます。
それであれば、最初からソフトウェアとしてプロトタイプを作ればいいのではという気もしますが、ソフトウェア実装しようとすると、つい作りこんでしまいがちなので、ちゃんと動かない環境でやるのも大事だったりします。
設計作業と言われるものは、ペーパープロトタイピングに近いかもしれません。
ペーパープロトタイピング 最適なユーザインタフェースを効率よくデザインする
分析資料
ハードウェアを作るときに状態遷移の設計が必要というやりとりをしたことがあります。
現実世界との接点になるソフトウェアでは現実世界とのやりとりの状態を管理する必要があるので、状態遷移が大事になります。
ただ、そういった資料を作るときの作業は、「どう作るか」を考える設計作業というより、「どうなっているか」を考える分析作業としたほうがいいんじゃないかと思います。そのため、その過程ででる「設計書」は分析資料に近くなるように思います。
この場合は、設計というよりは、仕様や定義としたほうが適切な場合も多そうです。
保守資料
「設計書」の必要性について触れると「メンテナンスのときに必要」という話がたびたびでてきますね。納品物になるときに期待されるのも、メンテナンス資料という位置づけが多いと思います。
でもまあ、メンテナンスのための保守資料なら事前に作る必要はなく、事前につくると開発作業中に同期をとるのが面倒ということを考えれば、完成が近づいたころか完成したあとに作るほうがいいと思います。
1992年にC++ Jounalに載った「What Is Software Design?」というエッセイは、「コーディングは設計」というようなことが書いてありますが、「設計ドキュメントをコードの前ではなく後に書くとはるかに正確なドキュメントが作成されるということを、全てのプログラマが知っています」と書かれていますね。
https://www.developerdotstar.com/mag/articles/reeves_design.html
コードとの同期を考えるとコメントを書いて自動生成がいいんではないかと。概要がわからないならChatGPTにコード全部なげて聞きましょう。
保守を考えるなら、こういった資料をがんばるよりは、プロダクトコードについての質問に答えてくれる、クローズドに使えるサービスのほうが大切になりそう。
作業指示書
SESで行われる「SE」と「PG」が分かれた水平分業では、コードを書く人への作業指示が必要になりますね。
「詳細設計書」にまつわる話は、基本的に水平分業由来であることが多く、ソフトウェアの性質から来るものというよりSESという業務形態で必要なビジネス文書であるように思います。
契約資料
多重下請け構造だと、「SE」と「PG」は別会社になるので、そうすると上記の作業指示書は会社をまたがった契約資料にもなります。納品物になるときには、問題が起きたときに責任を後から追跡できる資料にもなりうるという点では、契約資料としての納品という面もあるかも。
「PG」が勝手に設計を変えてはいけない、変えるにしろ確認が必要、という話には、トラブルが起きたときの責任という話がついてきて、つまり「設計書」が契約資料でもあるからですね。
「詳細設計書」について「ソフトウェア開発作業として、なんか変なこと言ってるなぁ」と思うときには、だいたいこの契約資料としての性質によるものな気がしています。
ところでこの本、Jackson法をベースにデータフロー->モジュール化->ふるまい定義と、かなりいい感じにまとまってるのだけど、ここで書いたような「設計書」の書きかたを求める人の需要は満たせなかったようで評価低い。
