※書きかけのまま力尽きてますが書きかけのままです……
詳細設計なるものを書くことになりました。で、既に出来ているシステムへの機能追加なので、既存のテンプレートは山のようにあります（数百というレベルで）。本意ではありませんが、やはりそれに合わせて同じ形式にすべき、というのは理解できます（嫌だけど）。
作業にあたってのフォーマット用法把握メモを兼ねて、現状の設計書の記載項目と、自分がまずいと思う部分や改善案を書き連ねておこうかなっと。開発環境は、バージョンは伏せますがVisual Studio、.NET Framework＋Visual Studio .NETです。別に誰かのために書くわけじゃ無いので、これを読んで何か学べるものがあるとか思わないでください（苦笑）。
表紙
- まぁありがちな、タイトルと社名に、印刷して使うことを想定した署名押印欄（承認者の人数分）。
目次
- Excelなので手書き。既存資料を見てもメンテされている様子が無い。
- メンテされていない。理由は、メンテしづらい。これにつきると思う。エクセルは見出しやスタイルという概念が無いので、自動的に目次を作るような仕組みがそもそも無い。
変更履歴
- 一覧表形式で下方向に追加していくタイプ。
- 記述粒度はまちまちだが、まぁ、あってもよいでしょう（実際、設計書はVSS*1で管理されているので、履歴をそっちに書いてもよいっちゃ良いのですが、まぁVSSを離れてやりとりをする可能性があるならこれもありかと）。
モジュール仕様
そもそも、この「モジュール」という言葉がタイトルレベルで特に定義も無く登場している場合、設計/実装者は気をつけた方がいい。アナタの思い通りには作れない可能性が高い。
- モジュール一覧
- 画面ID一覧
- ここでいう「画面」とは「Windows Form」のことを指す。これも定義無しで「画面」＝「フォーム」だったりするが、まれにマルチディスプレイの片方だったり、それらをまとめたものだったり、デスクトップから全部だったりするので混乱を招きやすい。プログラミングの材料として書く資料であれば「フォーム一覧」でよいではないか？
- 内容は「画面名」「画面ID」。各Formには画面IDなる文字列が割り振られており、原則的に「アセンブリ名+通番+枝番」になっている。本当であれば「わかりやすい名称」にした方が良いのではないかと思うけれど、まぁ、センスが問われる部分なので英数字の羅列でもよしとしましょう（やってれば覚えます……残念ですけど）。
- アクセス一覧
- 細かい説明が無いけれど、どうやら「このアセンブリ｛が｜に｝アクセスする外部要素」の一覧らしい。
- 「アクセス項目」「有無（○/×）」という列があり、アクセス項目欄には1行で説明できるレベルで対象の名前が列挙される。
- これを書くんなら、入力/出力とか、接続方式との概要もここに書いてしまえばいいのにと思うのだけれど、どうもここのプロジェクトの資料は「機能ごとに1つにまとめる」とか「1つの記載対象に関する情報は1カ所にまとめる」という発想ではなく、「同じ種類の情報は1カ所にまとめる」という路線になっている。作るときはベルトコンベアみたいに1種類のことだけを繰り返すのじゃ無くて、機能単位で組み立てていくから、この書き方だとあちこちに読み飛びながら調べる羽目になって面倒なんだけどなぁ。
- 動作環境/開発言語/仕様ツール一覧
- 構成ファイル一覧
- ソースを構成するファイルの名称を列挙する。
- 「項目」列にファイルの日本語名、「ファイル名」に「****.vb」のような実ファイル名を記入する。
- 前半は数字で項番が打たれているが、後半はアルファベット。アルファベットのところは設定ファイルを列挙するらしい（推測。説明は無い）。
- これ、まぁ、最終的に記録として記載するのは良いと思うのだけど、もし、事前にレビューして「ここに書いたモノ以外を入れてはいけない」みたいなことになっているとしたら大変不便。というか実際、「1ファイルの後ろの方に、複数の細かいクラスが宣言されている」なんてソースを見つけているので、もしかしたら「ファイル名の構成はゼッタイ変えるな」という指示でアウトソーシングしていたのではないかと思われる節がある。
- 業務DB一覧
- いわゆるCRUD図*2になっている。
- 「テーブル名」列にはテーブルの和名。後半が「C」「R」「U」「D」で○とハイフンで実行する/しない、を記述している。
- これも、自分にとってはどちらかというと「最終的に情報としてまとまっていればメンテナンスや変更時の影響調査が楽」というものであり、事前にこれが無いと作れないというものではない。むしろ、実装にあたっては各処理の詳細記述にそれぞれの処理が扱うテーブル等が記載されていれば事足りる。
- もちろん、共通ライブラリで自動的にデータ取得をするようにする、などの仕組みを作るなら事前調査や取り決めは必要だけれど、このプロジェクトはSQLに関しては各アセンブリごとに独自で自力構成する方針。
概要
処理概要として以下の情報が記載される。全体的に「非技術者かつ客先業務知識保有者」も想定読者に入れている雰囲気の記述。
- 本画面の概要
- 箇条書きと表を使って処理の概要を記述。
- 機能なのか画面なのか判らないんですけど、まぁ「このプログラムが行う処理概要」と読み替えればいいのでしょう。
- 基本設計以前で取り決めておくべき情報が列挙されます。
- 本画面の主な機能
- 箇条書きで上記の「概要」よりもう一歩踏み込んだ説明を記述。ただし、「手順」的なものではなく、1つの行で1機能の説明、というレベル。
- 基本的な処理の流れ
- 「＜～処理＞」のようなタイトルをつけて、その下に番号付き（丸囲み数字）で、アプリケーション利用者観点での想定操作と、裏側でのプログラムロジックによる処理が順に記載される。
- 観点は「利用者」。たとえば「～を押下し、～を表示する」（表示する、については実際はプログラムですけどね）。
- この記述自体は必要だし、悪くないと思う。
設定ファイル内容
- ファイル情報
- レコード構成
- 設定ファイルの形式や書式について記載。「レコード種類」「区切り記号」「改行コード」の3項目が箇条書きになっている。
- 属性の説明
- 後述する設定データフォーマットの各メンバーに割り振られる「属性」について説明した表。アルファベット1文字を「数値」「半角英数」「全角」に割り当てている。
- 後述の表に「項目属性」列があって、そこにこの「属性」を記号で入れるのだが……1ページに収まる範囲でわざわざ別表参照形式にする理由がわからない。各設定項目の行に「数値」とかって書けばいいじゃないか……。
- 共通編集仕様
- 上記の属性表のコピーに対して、それぞれのデータの「空白パディング方式」を定義している…。これも不要でしょ。わざわざ表を分ける必要が判らない。っていうか、属性なる情報を記号で表すのは良いとしても、だったら上記の「属性の説明」一覧に一緒に書けばすむのに……。なんで分割するんだろ。
- レコード構成
- データレコードフォーマット
- 設定項目ごとに以下の情報が書いてあるんだけど……
- とにかく定義していない用語を見出しに登場させるのはルール違反でしょ、設計書云々以前にドキュメントとして。
画面仕様
- 画面サンプル（Formサンプル）
- ウィンドウデザイン
- 要するに、Visual StudioにおけるFormデザインプロパティの代表的なものを抜粋した一覧表。以下の内容が記載される。
- Windowタイトル…タイトルバーの文字列
- 画面フォーム配置…（画面フォーム？）…「プライマリ中央」とか書いてあるけど初期配置位置のことかね？
- 画面フォームサイズ…（だから画面フォームって）…Formの縦横サイズを「1020 * 980」のように書くらしい。アスタリスクか！？
- 画面フォームレイアウト…「パターンA」とか書いてあるけどこれはなんだ？ここの開発プロジェクトの基底クラスか何かか？何にせよ説明不足すぎ。こう書くなら名前空間をフルネームで書いてくれれば容易に推測できるのに。
- コントロールメニュー…「最小化のみ使用可」ってことはフォーム左上のアイコン右クリック時メニューかな？
- 最小化ボタン…フォーム右上のアレですね。使用可とか使用不可とか書くらしい。
- 最大化ボタン…同上。
- 閉じるボタン…同上。
- Windowリサイズ…フォームと書いて欲しいな。「固定」とか書いてあるけど、だったら具体的なVisual Studio上での設定名の方が迷いが無くて良いな。
- メニューバー…メニューバーの有無を書く。
- アイコン…「システムアイコン」って書いてあるけど、どうやら.NET Frameworkのアプリ標準アイコンのことらしい。
- 種類…よくわからない。「メインWindow」って書いてある。と思ったら文末に注釈があった．種類は「メインWindow」「サブWindow」「ダイアログ（モーダル）」のみらしい。実際はモードレスで開くやつとかあるんだけど（笑）。
- ステータスバー…有無を書く。
- 画面文字書式…いきなり細かい内容を列挙するみたい。要するにフォントのサイズやフォント、色などを一気に書いてある。
- ボタン文字書式…同上。ただ、ボタンはボタンで全部同じ…じゃないでしょ実際。だったら個別と共通ととか分けて書けばいいのに。
- ボタンのサイズ…これも同じ。全部共通って前提で書いてあるけれど、実際の既存デザインは機能ごとにボタンが違う。共通化できていないのにこういうところだけ共通風に書くと、あとで管理クラスの人が「見積もりするよ」とかって見たときに「共通化されてるなら楽じゃない」と誤解するからやめて欲しい。
- 要するに、Visual StudioにおけるFormデザインプロパティの代表的なものを抜粋した一覧表。以下の内容が記載される。
（書きかけ）
*1:Microsoft Visual SourceSafe。ソース管理システム。ファイルなら何でも格納できるので、差分比較などが出来なくても良いのならExcelやWordのファイルでもOK。
*2:クラッド図。Create/Read/Update/Deleteの各処理を行う/行わないを一覧にまとめたもの
