昨日，DBゼミ初回発表を聞きました．
属性名で「姓」ではなく「性」とあったのは，3年連続です．「11月31日」に並んで，もうお腹いっぱいです．
さて，与えられた課題文に書かれている仕様を満足していないという指摘も出ましたが，仕様をすべて満足するような設計方法の説明はなかったし，時間の制約もあって私自身，口を開けませんでした．ここに書いておきます．
使用する道具は，「（紙の）課題文のコピー」「テキストエディタ」「Excel」です．
- 課題文をすべて電子化（テキスト化）します．箇条書きの箇所だけでなく，いわゆる前文も*1．
- 課題文を，断片化します．設計で解決すべき，小さな課題ごとに，ぶつ切りにします．一つの文の中でも，切れ目を入れていって，かまいません．
- Excelを起動し，新規に表を作成します．先頭行（表頭）の各セルには，「済」「No.」「課題」「説明文」「状況」「テーブル・属性」と書きます．2行目以降で具体的な内容を書いていきますが，各列の意味は，次のとおりです．
- 済：課題の達成状況です．2値とします．その行に書いた課題を解決したら，「1」と書き*2，そうでなければ空欄とします．すべての行を「1」にすれば，仕様をすべて満たす設計の完成です．
- No.：課題の識別番号です．全体の通し番号でもいいのですが，大分類・小分類に分けることをおすすめします．前文はO1, O2, ...，箇条書きのそれぞれにA, B, ...と大分類のラベルを振っておいて*3，識別番号としてはA1, A2, ..., B1, B2, ...とするのです．課題文のコピーには，各識別番号の開始位置を手書きしておきます．
- 課題：何を解決しなければならないかを，一言で表します．理想的には一つの単語で，長くても10文字以内とします．班内のコミュニケーションで使います．
- 説明文：断片化した課題文を貼り付けます．No.と並んで，最初に埋める欄です．
- 状況：課題の達成状況を，文で書きます．設計後の（もしくはすでに設計した）実体関連図を見て，その行の課題に対してどのように対処しているかを書きます．発表用スライド作成の際，根拠として貼り付けられるような文にします．未対処なら，基本は空欄ですが，対策（方針）をメモするのもいいでしょう．
- テーブル・属性：その行の課題に対処しているテーブル名や属性名です．複数あるかもしれません．
ただしこの設計検証法には，いくつか注意すべき点があります．これを使って適切に作業を管理すれば，「与えられた仕様にどれくらい準拠しているか」は教えてくれますが，「作図した実体関連図の持つ矛盾」や「隠されているが，実用的なシステムを構築するために不可欠な仕様への対応」については，教えてくれません．
また，このExcelファイルによる進捗管理表は，班内の作業を分割し，効率化するための内部資料です．表を配布しても他の班の人は読みませんし，発表時にうっかり，識別番号を口に出してしまうと，誤解のもととなります．
あとはこのExcelファイルをどのように共有するかですね．メールでやりとりしていると，班の3人のうち2人の最新版と，残る1人の最新版が違っている，なんてことにもなりかねません．Dropboxなどのオンラインストレージで，共有機能を使うといいでしょう．
*1:前文にヒントが隠されている，というのは大学入試センター試験の国語対策の基本でしたね．
*2:Excelの「条件付き書式」を使って，1にしたら色を変えるといいでしょう．
*3:箇条書きが15個以上あったら…まあうまいこと回避してください．前文の大分類用ラベルをOとしているのは，話の始まり(origin)という意図です．
