他人が作ったシステムの設計書を作るには、プログラム解析以外の技術も必要らしい

情報システム部では
時々、他の人が作ったシステムの設計書を書く仕事
が舞い込んできます

今回は
・数ページ程度のマニュアルらしき資料と
・数ページ程度のプログラム定義書らしき資料と
・ほとんどコメントのないプログラム
から、設計書を作成することになりました

こうなると、地道にコツコツと
絡まった糸をほぐすように紐解くしかありません

システム概要のヒントになるものは
マニュアルらしき資料しかなく
プログラムの意図を探るヒントは
プログラム定義書らしき資料しかないので

あとは、ひたすら読み込んで
解きほぐしたプログラムの内容から
データの入出力と処理内容に分けて
構造的に組み立てていきます

大抵、こういう状況になると
残っている資料は
「わかっている人」が書いた詳細なメモで

「詳細」なプログラムと
「詳細」なメモと
今までの経験から得た「推測」から
「概要」へ組み立て直すことになります

「プログラムが読める」だけで作成した資料は
プログラムを日本語に翻訳した状態なので

ここから
設計書の「あるべき姿」にどれだけ近づけるか
が大事になってくるのではないかと思っています

となると、「あるべき姿」に近づけるには
プログラムが読めるだけでなく
読みやすい設計書が書ける人
(または、読みやすい設計書とはどういうものか
を知っている人)
でないと、できないのではないかと思います

私が思う「あるべき姿」は、下記の３つ
１．内容によって、文章、表、図、それぞれ向いている形式で表現する
２．程よい情報量でまとめる
(情報量が多いときや、読んでから推測しないと
理解できない場合は、まだ構造化しきれてない)
３．知りたい情報にすぐたどり着ける
(概要→詳細、わかりやすいタイトルと目次)

今回も、わかりやすい設計書になるように
精一杯やってみます

最後まで読んでいただき、ありがとうございました