私的なメモです。自分以外の人にとってはあまり役に立たないと思います。 メモというより独り言になっている部分もありますが、今更編集しなおすのも辛いので軽くスルーしてください。 また、同じような内容が繰り返し記述されている可能性もありますが、まとめる気力がないのでスルーしてください。
現在ナッシングです。
2次、3次の開発を行う場合、実際に変更される仕様と全体の仕様の2種類のドキュメントが必要になる気がする。 実際に変更される仕様がまとまっていないとどこが変わるのかわからなくてテスト仕様書作成やコーディングも的確に行えないし、 全体の仕様がないと全体的な仕様を知りたい時にそれまでの全てのフェーズのドキュメントを参照しなくてはならなくなる。 まあでも順番としては、開発中はそのフェーズでの変更仕様書が必要で、 全体的な仕様書はテストが終わるときぐらいに一気にまとめちゃうのが楽な気がする。 開発中は仕様が変更されることが多いと思うので、その度に両方を間違いがないようにメンテするのは結構大変な気がする。
コーディングの前に各処理で使用する関数や実際に記述する内容の詳細についてドキュメントに書いても、あまり意味がない。 と言うか、無理。 もちろん、公開メソッドの引数や処理内容をドキュメントにまとめる事はまだ可能だとは思うが、 例えば「このボタンをクリックしたらこの関数とこの関数を呼んで・・・」みたいな事は、所詮は机上の論理。 ドキュメントには「そのアクションで何をする必要があるのか」ぐらいの説明が必要なだけで、 その処理を実装するのにどのようなコーディングを行うのかはドキュメントに書くべきではない。 ドキュメントに無理に合わせようとするとコードの共通化やリファクタリングなども無理と言うことになる （その度にドキュメントも修正するんだったら別だけど）。
ドキュメントを作成するときは、雛形になるドキュメントがないのにみんなで一斉に同じようなドキュメントを作成するべきではない。 参考にするドキュメントがない場合、みんなが作成したドキュメントに統一性などないことになる。 統一性がなくて良いんだったら別にいいけど、結局最後は「書き方を合わせましょう」みたいな感じになることが多いので、 だったら一番初めに雛形となるドキュメントを1つ作成して、関係者でレビューしてから本格的なドキュメント作成に入るべき。 雛形となるドキュメントがレビューしてOKになるまでは、本格的なドキュメント作成に入るべきではない。
また、上記ドキュメントは不必要に別々のファイルとして分けないほうが良い。 いずれも関連が深い情報なので、無理に別ファイルに分けると参照しづらくなる （コントロールの処理内容は分かったが、画面イメージが別ファイルになっているので頭の中でイメージしづらいなど）。
画像を張ったり保存するときはそのフォーマットとしていくつかの選択肢があるが、 フォーマットによって画像の質やファイルサイズが大幅に異なる。 ここではWinXPで1280×1024の32ビットのデスクトップのプリントスクリーンをペイントに貼り付け、 それぞれのフォーマットの違いをテストした。
・Excel（Wordも一緒）に貼り付ける場合のフォーマット
選択できる形式として、ビットマップイメージオブジェクト、図（拡張メタファイル）、
ビットマップの3種類がある（Wordでは名称が微妙に違うが意味は一緒のはず）。
それぞれ、テスト用のイメージを1枚貼り付けて保存した場合のサイズと画質、印刷時画質は以下のようになった。
1.ビットマップイメージオブジェクト
サイズ：4103KB 画質：良い 印刷時画質：良い
2.図（拡張メタファイル）
サイズ：238KB 画質：良い 印刷時画質：良い
3.ビットマップ
サイズ：171KB 画質：良い 印刷時画質：良い
上記結果から、単純に画面のハードコピーを貼り付けたい場合「ビットマップ」を選択すると問題ない画質で一番小さいサイズで保存できるため、
特に問題がなければビットマップで貼り付けるべき。「形式を選択して貼り付け」ではなく、
普通の貼り付けを行うと「ビットマップイメージオブジェクト」として貼り付けられる（＝ファイルサイズが大きくなる）ようなので注意。
また、サイズが大きいイメージをコピー＆ペーストする時はクリップボードへのコピー（？）に時間がかかっているようで、
その間は「形式を選択して貼り付け」で選択できる選択肢が少ないので注意。
次に、Excelに貼り付けるときのフォーマットではなく、画像を保存する時のフォーマットについて比較してみる。元画像は前述した画像と一緒。
1.24ビット（オリジナルの形式）
サイズ：3841KB 画質：良い
2.256色
サイズ：1282KB 画質：良くない
3.16色
サイズ：641KB 画質：悪い
4.モノクロ
サイズ：161KB 画質：耐えられない
5.GIF
サイズ：113KB 画質：良くない
6.PNG
サイズ：152KB 画質：良い
上記結果から、画像として保存するときは特に理由がない限りPNGで保存すれば、画質、サイズともに満足できる結果を得られる。
PNGで保存しても、ペイントで再び24ビットのビットマップに変換して保存することも可能（意味があるのかは不明）。
GIFについてはPNGよりもサイズ的には小さいものの、画質の劣化が目立つので止めたほうが良い。
ただ、ここでの実験はあくまでXPに付属しているペイントで変換した結果のため、
別のツールを使用した場合の結果については（当たり前だが）異なることが予想される（特にGIFについてはもっときれいに減色できて良いはず）。
ちなみに、一旦PNG形式などに変換して保存したファイルをExcelなどに貼り付けても、
結果的にはオリジナルのビットマップを貼り付けた時とあまり変わらなかった。
よって、単純に貼り付けを行うだけであれば、
いちいちPNGに変換してファイルサイズを小さくしてから貼り付けるとかやってもあまり意味がない。手間がかかるだけ。
[ページ設定]で「印刷の向き」を適切な向きを選び、「余白」は全て0にし、「拡大縮小」で「適合 1×1ページ」を選ぶ。
画面の項目とＤＢの項目とを紐つける転送項目仕様書はマトリックスっぽく作っておいて、 テスト仕様書では単純に転送項目仕様書を参照みたいにした方が良い。 転送項目仕様書に記述されているのと同じ事をテスト仕様書にも記述するのは馬鹿らしい。 ただ、転送項目仕様書のほうも文章っぽく記述するとテスト時にチェックしづらいので、マトリックスにしておく。 番号を振っておくとテスト項目数などもはっきりするのでなお良い。 また、転送項目以外にも、画面項目のタブ順や表示形式などの設定などはマトリックスなどで仕様書もかけるはずなので、 そういうやつはテスト仕様書のほうから「設計書を参照」みたいにできると思う。 基本的に書かなくて済むんだったら書かないほうが良い。
各画面の設計書を作成する前に、アプリケーション全体の共通動作を決めて、共通仕様書としてまとめておく。 エラー時の動きや、各コントロールの使用方法、などなど・・・。 仕様書にまとめておくのはもちろんだけど、もしコードとして共通化できるんであれば、共通化する。 共通化できる処理なのに、共通化しないで各画面ごとにバラバラに処理を作成するような事はやるべきではない。 また、共通化できるような処理は極力共通化するように、チーム全体に意識の統一をはかっておく。
コードなどを定義しているカラムであれば、リンク先のテーブルとカラムの情報が必要。 できれば、大元のカラムのサイズとかが変わったらリンクしているカラムのサイズも自動的に変わってくれると便利だけど・・・ 自動で変わらないとしても大元のカラムの情報がドキュメントで管理されていれば修正及び管理が楽になる。 直接リンクしているカラムと、大元のカラムの2種類の情報が併記されていた方が良いかな？ 基本的には同じ要素だし、 直接リンクしているカラムを辿れば大元のカラムも分かるはずなので大元のカラムの情報は冗長といえば冗長なんだけど、 併記されてるに越したことはない気がする。
区分値、区分名については、各カラムごとに定義するよりも区分定義表みたいなのを作って一括で管理した方が良いかも。 で、区分値と区分名の定義は個別にハードコーディングはしない方がいいかも。 少なくとも共通で定義、できれば外部に定義。 でも、そうそう変更される項目でもないので共通でハードコーディングしておくのが楽か。
区分値と区分名の定義は個別にハードコーディングしない方が良いかもと言うか、してはいけない。 またこの場合、設計書の記述で使用する区分値を書く場合も、 （ドキュメントに対する）ハードコーディング（いわゆる値そのものを直接記述すること）はいけない。 区分定義表に従った抽象名で記述すること。 これは区分値に変更があった場合ドキュメントの値も修正しなければならないと言う理由もあるが、 それよりも「実装者がドキュメントに記述されている値をそのままハードコーディングする可能性が高い」方が理由付けとしては大きい。 実装者の意識の問題と言われればそこまでだが、現実的な問題として、 ドキュメントに直値が記述されていればコードにもその値を記述したくなる。 そういう記述を抑止する為にも、設計書の段階で直値を記述しないのは重要だと思う。
また、区分値は大抵区分種別ごとに分かれていると思うので、定義書にも区分種別ごとに定義しておき、 プログラムでもたぶん必要になると思われるであろう区分種別ごとのDataTable（みたいなもの）も共通で用意しておく。 区分種別ごとの区分値一覧は検索条件などのドロップダウンで使用することが多いはず。
項目説明の文言とコントロール名のベースとなる名称を共通のドキュメントで管理する。 各画面では基本的にはその名称を使用する。 そうしないと、同じ項目なのに画面作った人によって文言やコントロール名がバラバラになる。 コントロール名は開発者にしか関係ないが、項目名はユーザーと直接関係があるので、バラバラはまずい。 当たり前だが、上記ルールはあくまでもベースの情報。画面によって必要があれば変わってくる。 必要がないんだったら共通を使用。 ちなみにコントロール名に関しては無理に単語を省略しない方が良い。まあ、これはコントロール名に限った話ではないが。
ソースは言うまでもないが、テーブル定義書などのドキュメントもVSSで管理すべき。 バイナリなので履歴の比較はできないが、履歴データ自体は残ってるのと誰がいつ修正したかがわかるのである程度の管理はできる。 VSS管理してないと誰が最後に修正したのかすらわからない・・・。
当たり前かもしれないけど、複数人で設計書を作成する場合は設計書作成の初期の段階である程度のレベルの汎用的なテンプレートを作成し、 それに対して関係者でレビューを行い、且つ、 各関係者がテンプレートを元にそれぞれの設計書作成に入った後も、 初期の段階ではそれぞれの設計書がある一定のレベルの品質で書かれているかのレビューを行う必要がある。 でないと、テンプレートはあるけどある人の設計書は全然書かれていなかったり、 ある人の設計書は凄い細かく書かれていたりと言う事が往々にして有り得る。 設計者同士の連携や意思疎通が密な場合は特に何もしなくても品質が揃っている可能性はあるが、それを当てにするべきではない。 上を見ればキリがないと思うけど、下限の品質をある一定のレベルまで上げる必要はあると思う。 そんな事に時間を割くのはもったいない、意味ないと思っている人もいるかもしれないけど・・・ 設計書が出来上がってから品質がバラバラな事に気がついても遅い。 この辺りの基本的な考え方はソースレビューと同様。
共通仕様についてのドキュメントは、必要以上に細かく分けないようにする。 必要以上に別ファイルなどにわけてしまうと、自分が必要としている情報がどのファイルに記述されているのかわからなくなってしまう。 乱暴な言い方をすれば、共通のドキュメントは細かい単位でまとめるのではなく、ある程度の大雑把な単位でまとめるくらいが丁度良い。
トランザクションって処理が流れていく中でどこかのフラグの状態が遷移していくことが多いと思うけど、 できればそのフラグの各画面（状態）における状態遷移図が欲しいなぁ。 特にそのフラグに関わる設計者が複数人いる時は、 意思疎通が十分でないと必要な箇所でフラグを操作していない可能性が出てくる（そもそもフラグの存在自体知らないとか。いやマジで）。 まあでも、この状態遷移については単純に遷移状態を書き出せないことが多いとは思うので、 もしちゃんとやろうとしたら大変だろうとは思うけど。
設計書や定義書には、バージョン番号とかはともかく、最低でも更新日付と印刷日付はヘッダに持った方が良い。 いくつも印刷していると、どれがいつの定義なのか分からなくなる。