Ayumiさんの記事を読んで、自分なりに整理してみる。

Ayumiさんは現役のプロだから、求められる仕様書の種類や内容の詳細度について、私が思っているのとは違うだろうけれども、仰っておられることの空気感は凄くよく伝わった。

（Ayumiさん、私が趣旨を取り違えているようであればご指摘ください。）

私が現役のSE（システムズエンジニア）だった1980 - 2000年代。

COBOLプログラム開発では製品としてのソースコードの他に、コンパイルリスト、修正したマクロ（JCL）リスト、プログラム仕様書、更新条件表、JCLフローチャート、マクロ管理台帳、、、を準備し、上長レビューの後に品質管理部門の審査をパスしなければならなかった。

ドキュメントの作成は、本当に面倒臭かった。
種類は多いし、よく書類不備でつっかえされるし、そもそも手書きだったし。

私が物臭であるのは置いておくにしても、それらの仕様書が往々にしてそれほど信用できずに役に立たない事が多く、それほど重要だとは思えなかったのも否定できないからである。

確かに、常に最新で正確に記述されている仕様書が揃っていれば、そのプログラムを修正したり機能拡張するのが容易になるのは分かってる。

でも、

仕様書の記載ミスや曖昧な記述は、すぐに大きな混乱を招く。

なにが一番信頼できるかというと、結局は本番環境で稼働中のモジュールのソースコードということになるが、それだって実際に本番環境で稼働しているモジュールとはバージョンが違っていることだってあり得る。

メンテナンスを開始する前に、実行モジュールとソースコードの更新日付を確認して、管理表に記されたバージョンとマッチしているかを確認するところから仕事が始まる。

対象とすべきソースコードが確定したのち、保管されている仕様書に記載されたバージョンナンバーとリリース日付等を確認し、マッチしているかを確かめたのちにやっと内容の検証に入ることができる。

こうまでしてやっとゲットした仕様書は、必ずしもソースコードと一致しているとは限らない。記述ミスや記載漏れ、誤解を招く表現が含まれる可能性が排除できない。

そうなるとどういうことになるか？

結局、仕様書で概要を把握しても、詳細はソースコードを見るしかないのである。

プログラマはプログラマで、どうせこうなるとわかっているから仕様書を重視しなくなる。

悪循環であり、仕様書の品質が改善することに繋がらない。

問題はプログラマの怠慢とか、品質管理部門の能力の低さではなく、実際にプログラマが必要となる粒度の情報は、そのプログラムのソースコードを見ない限り、決して満足できないということだ。

どうしたらいいんだろう。

仕様書には、プログラムの概要を把握する程度しか期待できないのかもしれない。

そういうことであれば、流行のChatGPTにソースコードをコピペして「次のコードの機能を述べよ」と指示すると、コードを解析して解説してくれる。
ひょっとしたら、これでも十分かもしれない。

＜ChatGPTによる解析結果例＞

次のコードの機能を述べよ。

#include<stdio.h>
#include <stdlib.h>
#include <time.h>
#include <sys/time.h>
#include <string.h>

long int counter;
long int loop_count;
char e_string[14]; // 編集した文字列

void swap (int *x, int *y) {
  int temp = *x;
  *x = *y;
  *y = temp;

  counter++;
}

（、、、　以下省略）

（以下、私の記事で取り上げたｃ言語ソースコードをコピペ）

＜ChatGPTからの回答＞

荒いといえば荒いけど、初見でこれだけ分析できるChatGPT凄いと思う。

結論、

今日日、仕様書って要らないんじゃないかな。

とはいえ、手書きのプログラムフローチャートを書いたり、変数名一覧表をエクセルでまとめたりしている自分がいる。

本当に仕様書を無くしちゃってもいいのかな、

、、、「ソフトウェアに仕様書は必要か？」考（その２）へと、続く、、、多分、、、。

ここまで読んでいただき、有難うございました。