アーキテクトな猫の図書館

についてです。

まとめに入る前に、背景について補足します。

• 業務系ソフトウェアが開発対象である
• 複数名で外部設計を担当している（担当は機能ごとに分割されている）
• ３層環境で動作するアプリケーションである
• リレーショナル・データベースを利用している
• マスタデータ（※１）とトランザクションデータ（※２）とが別管理されている

ウォーターフォール型の開発手順に則り、
要件定義→外部設計（基本設計）→内部設計（詳細設計）→開発
と進む中、【外部設計】の段階でデータベースに保存するデータの構造を決定します。

この時、「機能に紐付けて、特定のテーブルの構造のみを設計書へ記述」を進めていた頃から、不幸は始まります。

機能に紐付けて作成された設計書のそれぞれは、「その設計書の中では」整合性が取れた状態で済んでいました。

しかし、時が経つにつれて徐々に設計のほつれが明らかになりました。

• 期待したデータが対象の項目に保存されない
• 特定条件を満たすデータの件数が、想定していた件数と異なる
• 検索を想定していたテーブルとは別のテーブルに情報が保存されている

といった具合に。

上記のような現象が発生した理由を考えてみました。

• 複数の外部設計担当者が読み書きするテーブルが多数あった
• データベースの関連を表す資料が存在しなかった
• 各機能やデータ構造について、充分考察できる時間が用意されていなかった

業務の流れに沿って、業務の担当者が切り替わるタイミングなどに合わせてテーブルが切られています。
その都合上、機能を横断するテーブルが多数存在します。
機能ごとに区切って外部設計の担当者が割り当てられているため、複数名が同じテーブルの構造について考察する環境が頻発しました。

また、各外部設計書を横断するような、テーブルの構造を示す資料がありませんでした。
そのため、担当者間の設計思想が共有されづらい状況にありました。
※もちろん、担当者間で相談をしながら進めましたが、限度がありました。

更に、よくある話ですが、「納期」が重たい錨として降ろされており、人も少ない状況での設計でした。
自身の設計力のなさを嘆きつつ、「個人の担当範囲においてはおおよそ整合性が取れている」という状況にするので手一杯でした。
他の設計者の方も、精度の個人差はあれ、似た状況で開発フェーズを迎えました。

開発の途中、データベースの関連図をいよいよ作ろうという話が上がり、作成に踏み切りました。
すると、ぽろぽろと音を立てて、積み上げたデータベースの穴が、乱雑に配置されたテーブルの中から見えて来ました。
「一枚の絵を囲んで設計者間で議論」をし、穴がなくなるように改造をしていきました。

「一枚の絵」（※３）を書き始めたことで、データの整合については、鎮火の兆しが見えました。

以上が、データベースの関連を纏めずに開発した時に起きる不幸と、その回避の一策です。
僅かながらの備忘録として。


※１　マスタデータ
ソフトウェア全体に対して、動作を制御したり、情報を整理したりする場合に用いるデータの総称。
変更の少ない情報を取りまとめる事が多い。
例）　ログインユーザの情報、企業の情報、取り扱う商品の情報など

※２　トランザクションデータ
ソフトウェアの機能が動作する上で、機能の動作途中や、ユーザの操作によって発生するデータの総称。
変更や新規発生の多い情報を取りまとめる事が多い。
例）　商品の発送状況、商品購入履歴、ユーザー投稿コメントなど

※３　一枚の絵
通称ER図。
テーブル間で、データがどのように結びつくかを表現する図。
各テーブルの主キーとその他、テーブル間のデータが１：１なのか、１：ｎなのかなどの関連を示す図。
今回のプロジェクトでは、特殊な外部結合の条件なども色で結びつけて、表現してみました。