全3678文字
PR
無料セミナー
接触確認アプリ、本当に使う?~公益のための個人データ活用とは 6/8 18時

 IT勉強宴会というNPO法人がある。主催者は「一風変わった名称の勉強会」と自ら語っているが失礼ながら一風ではなく相当変わっている。宴会はシンポジウムの訳かと主催者に聞くと違うと言う。そうであれば酒を飲むことに専念すべきで面倒なITの勉強は別の場所でしたほうがよいと思う。

 ひょんなきっかけから主催者の佐野初夫氏と知り合い、これまでIT勉強宴会に数回参加させてもらった。ただしいずれも夕方の講演だけ拝聴し、肝心の宴会には出なかったので厳密には参加したとは言えない。

 佐野氏から「勉強会のメンバー持ち回りで業務設計やデータモデリングの面白さを若手の技術者に伝える原稿を書きたい」と連絡があり『本音で議論、企業情報システムの「勘所」』という連載を始めてもらった。

 連載の打ち合わせで佐野氏とメールのやり取りをしていた際、「本に書いてある通りに実務で設計してはいけない」という一文が目に入り、気になったので少し話をした。やり取りを以下に再現してみたい。

なぜ例外処理に泣かされるのか

教科書通りにできることは案外少なく現場では色々ある、という意味ですか。

佐野 設計やモデリングについて本がたくさん出版されていますが、実際の業務で使おうとしたとき、書いてある通りにしてはいけないこともたくさんあるのです。駆け出しのころ、設計手法を本で学んでその通りに実装したところ、本番に移行してから例外処理が色々出てきて対処に苦労したことが何度かありました。

 今思えば、それらの多くは普通のユースケースだったのですが当時は気付かず、「また例外か」と頭を抱えていました。業務設計の経験を積まれた方はだれでも1度や2度は同じように悩まれたのではないでしょうか。

例を挙げてもらえますか。

佐野 簡単な例で説明すると次のような話です。売上明細というエンティティーに次の属性があるとしましょう。

売上明細エンティティーの例
売上明細エンティティーの例
[画像のクリックで拡大表示]

属性のところに実際に入るデータが表示されていて分かりやすく感じますね。

佐野 このモデルはオープンソースソフトウエアのX-TEA Modelerというツールを使って書いています。このツールはモデルの下段に実データのサンプルを表示する機能があります。

 データベース設計の本を読むと「One fact in one placeの原則から商品名や商品単価は商品マスターに持たせるべきだ」とか、「合計金額は単価と数量から導出できる属性なので売上明細エンティティーには入れないほうがよい」とか、書いてあったりします。なるほどと思って従うと例えば次のような実装になります。

売上明細と商品マスターの設計例
売上明細と商品マスターの設計例
[画像のクリックで拡大表示]