VBAで仕様書は書きますか？

VBAで仕様書(設計の仕様書？)を書く人はいらっしゃいますでしょうか？それともVBAくらいでは書かないと言う人は多いのでしょうか？


サンプルがあるかググって見ましたがほとんどありません。
勉強がてらもし私がいなくなっても何がやりたかったのかわかるように書いてみています。
いなくなったあとド素人コーディングと陰口を叩かれるために書くわけではありませんが…(笑)
ワードにまず
1・作ったものの目的
2・物を作ったパソコンのスペックと動作確認したOS
3・各シートで出来る処理を箇条書き(プログラムではありません)
4・プログラムの内容 処理として重要!という部分を抜粋して載せる 例えばプログラムを書きそこに説明として"For Each～Nextステートメントでシート名を検出し無ければシート名を作成する"などコメントを箇条書きしてみましたがどんなものでしょうか？
もし皆さんがこのような記述の仕様書をみたらどんな感想を持ちますでしょうか？参考にしたいので意見をお聞かせください。お願いいたします。


また、Visual Basic 6.0 仕様書作成サポートというソフトがあるらしいですがVBAで利用できるようになりますでしょうか？

No.5 ベストアンサー 回答者： piyo2000 回答日時： 2008/05/29 02:55

＞サンプルがあるかググって見ましたがほとんどありません。

無いでしょうね。

そもそも、仕様書は「VBAだから書かない」「C/C++だから書く」という性格のものではないからです。
言語はあくまでもそれを実現するための道具であって、
仕様書自体は、書く必要があれば書きますし、必要が無ければ書きません。
そして、どのような言語であっても仕様書の体裁は基本的に変わりません。
（少なくとも私は変えてはいけないと思っています。理由は後述。）

最近はPGとSEの分業化も進んでいますので
（SEが最新の言語についていけない・・・という説も（笑））
言語に依存しない仕様書を書くのが普通ですし、
仕様書として優れていると思います。

ユーザーに対して「このような機能のものを作ります」と言う意味で書く仕様書は
お金をもらう為にも、そして仕様を明確にする為にも必要です。
家を建てたときに施工主が「部屋の数が１つ少ない」といってゴネても
事前に渡した図面通りであれば、突っぱねることが出来る・・・というわけです。

＞このような記述の仕様書をみたらどんな感想を持ちますでしょうか

仕様書は基本的に「プログラムがわからない人が読むもの」・・・
という意識が足りないように思います。

＞1・作ったものの目的

目的というよりは、「何をしてくれるものか」と言うことを
概要として最初に書いておくのがいいと思います。
小説でいうならあらすじのようなものです。

＞2・物を作ったパソコンのスペックと動作確認したOS

これはあまり重要ではないと思います。
OSはともかく、VBAであるならExcel等のバージョンのほうが重要でしょうし。

＞3・各シートで出来る処理を箇条書き(プログラムではありません)

これはいいと思います。
基本的に仕様書は箇条書きです。

＞4・プログラムの内容 処理として重要!という部分を抜粋して載せる

不要です。

わざわざ処理を日本語で噛み砕いて書くのは、
プログラムが分からない人でも何をやっているのかを理解してもらうためです。
プログラムが分かるのであればソースコードを読めば事足りますし
第一、載せたコードを修正した場合はこちらも書き換えないといけませんよね。

No.4 回答者： K-Sogacchi 回答日時： 2008/05/28 15:55

ANo.3です。

すみません、ちょっと追記しておきます。
本来は、仕様書はプログラム作成「前」に書くものですし、プログラム自体を
仕様書に盛り込んで、それに説明を加えるといった書き方は、普通はしないですかね。
別にダメって訳では ないと思いますが、後になって改修の必要が出た場合、
仕様書の修正も面倒な事になりそうですし…
基本設計書として処理の流れを書く場合は、基本的には段落番号等を付けながら
インデントも行いつつ、処理の内容（意味）を、そこそこ簡潔に書いてしまえばいいと思います。
例えば、
1.初期処理
　　1-1.○○○ファイルオープン
　　　　　1-1-1.○○○からファイル名を取得
　　　　　1-1-2.オープン処理
　　　　　　　　　エラーの場合はメッセージ「○○○」を出力して処理終了
2.メイン処理
　　2-1.以下の処理をデータ数分ループ
　　　　　2-1-1.取得したデータの○○○を○○○に追加
　　　　　2-1-2. .....
　　2-2.データ書き込み
　　　　　2-2-1. .....
3.終了処理
　　3-1.○○○ファイルクローズ
　　3-2.オブジェクト解放
　　　　　3-2-1.○○○解放
　　　　　...
　　3-3.アプリ終了
…かなり曖昧な書き方ですが、こういう流れとか。
もちろんVBAですので、イベント別に書いたりする必要は出てきますが…
あと、もちろん、後で他人が見ても やりたい事が十分分かるよう、省略し過ぎないように
する事も大事です（汗）。

No.3 回答者： K-Sogacchi 回答日時： 2008/05/28 15:37

一口にVBAとは言っても、いろいろですので…

それなりにデカいプログラムも当然書けますし、やろうと思えば
クラス等を定義したExcelファイルを共有して、それを参照設定して使い回すとか
多少難儀な事も出来ます。
そうなって来ると、ドキュメントが残っていないと、後で困ることになるかもしれません。

開発業務での話でしたら、仕様書、設計書の作成・納入が契約上定められているかが
もちろん大きな要因になりますが、そうでなくても書く余裕があれば、
書いておいた方が無難では あるでしょうね。
（時間が経ったら、作った自分でさえ内容を忘れたりしますし…）
私が過去に携わったVBAを使ったシステムでは、基本設計書の作成は義務付けられ、
詳細設計書は必要ないと判断されれば作らない、って程度のものでしたが、Excel VBAアプリの設計書は作りましたよ。
ちなみに基本設計書だと、処理の流れも多少 概要的な書き方をしますので
（参照するデータ等は、きっちり定義しますが）、それを元にプログラムを
作成する場合、多少の脳力が必要となります。
komarimonoさんが書かれてるのは、こっちが近いかな？
要は、処理の流れや使用するデータがはっきり分かれば、それでいいかと思います。
もうちょっと細かい事を言うと、画面定義や画面入出力項目の一覧、エラーメッセージ一覧とかも
表などで付加したりする場合もありますが、フォーマルなものでなければ、そこまでは
必要無い気もします。
（きっちり書こうとすると、表を書く場合が多いので、Excelの方が楽かも）

詳細設計書は（書いた事ありませんが）、ほとんどプログラムを文章にしただけって
感じの詳細な内容らしいので、その文章をプログラムに翻訳すればプログラムが
出来てしまう、ぐらいのもののようです。

その辺の定義は、企業等によって色々あるかとは思いますが、ネットで検索してみれば
色々出てくるかもしれませんね。
（サンプルは なかなか無いでしょうけど、どういう事を書くかという定義的な部分は、あるような気も）

No.2 回答者： Ishiwara 回答日時： 2008/05/28 10:03

私は趣味でプログラムを作っているので、ソースをひと様に見せることは、めったにありません。

しかし、仕様、処理や変数の一覧、コメント、修正情報などは「将来の自分のために」なるべく書きます。その際、一瞥して自明のものは省略しますが。

No.1 回答者： k_sidina 回答日時： 2008/05/28 02:20

仕様書が必要であると思われるなら仕様書を書くと思います。

趣味で作成されたプログラムの仕様書は当然ながら必須ではありませんが、仕事で作ったもので、納品物としてプロ仕が必要なのであれば作るでしょう。

仕様書を自動で作成するソフトですが、
質問者さまは VBA とかいておられますが、Access でも Excel でもその他オフィス製品でも VBA が動くと思いますが、どの VBA でしょう？
うちの会社でもだいぶ前に、仕様書作成ソフトを購入しました。
その際、使用したのは A Hot Document だったと思います。

プロ仕は必須ではありませんが、適切なコメントは、最終的に自分を助けてくれる存在になりますので、入れるのはよいことだと思います。