« 骨格→筋肉→皮膚の順序で仕様を決めよう | トップページ

2019.11.05

「ラグビーW杯」をモデリングしよう

 2019ラグビーW杯が大盛況のうちに終わった。その余韻がまだ残る11月16日(土)の午後に、名古屋で「ラグビーW杯のモデル」をテーマとするイベントが開催される。オリンピックをモデリングするためのイベントが開催できなかったので、そのリベンジでもある。

 まず、私がまとめたモデルを紹介しよう。チームとメンバーを事前に登録し、年指定の開催や試合予定に関するデータを追加してゆく。第1回から今回までを登録すれば、往年の選手が過去のW杯でどんな活躍をしたかやチーム別の実力の推移など、さまざまな情報を自在に取り出せるDBが出来上がる。

010_wcr_xtea

 当日はこれを含む何種類かのモデル(UMLやIDEF1Xを含む)の説明と、それらにもとづいて実装されたシステムの動作や開発手順が解説される。順位こそつけないが、アジャイルのためのさまざまな実装手段による大競演である。名古屋経済大学の中西昌武教授による「データ処理パターン」の数学的分類に関する特別セミナーも開催される。データ処理のパターン分けは、業務システム開発の合理化において欠かせない論点なので、開発者には有意義な学びになるはずだ。

 また、確立されたデータモデルを起点にできるのであれば、アジャイル開発の効率が最大化されることもわかってもらえるだろう。データモデルなしでアジャイル開発を進めれば、テーブル数が数十を超えるような案件では「アジャイル・デスマーチ」に陥る可能性が高い。「アプリや業務体制を明らかにすれば、データモデルはおのずと明らかになる」のではない。そもそも今回のお題について言えば、参考にすべきアプリや業務フローが存在しない。まずは、扱われる情報の本来の形(データモデル)を明らかにして、そこからアプリや業務のあり方を演繹するのでなければ、効果的なシステム仕様は手に入らない。

 そういった話題も含め、業務システムの設計・開発に関するさまざまな議論を楽しめる1日になるだろう。なお、現時点では4チームが参加予定で、あと2チームの参加を受付中である。腕に自信のある開発者はぜひ応募してほしい。

アジャイル開発大競演「ラグビーW杯データ管理システム」
2019/11/16(土)12:30~17:00、名古屋経済大学 名駅キャンパス
申し込みはこちらから

|

« 骨格→筋肉→皮膚の順序で仕様を決めよう | トップページ

コメント

いつもブログを読ませていただき勉強しているものです。
長らくブログの記事が更新されなかったので、
病気でもされているのでは?と心配していました。

「ラグビーW杯データ管理システム」面白そうですね。
東京開催だったら絶対行ったのに!

ラグビーワールドカップは開催前はそこまで興味はなかったのですが、開催してみたら見事にはまってしまいました。
自宅が東京スタジアムの近くということもあり、
最寄り駅に外国人の方々が多数おしかけ、大変盛り上がりました。
思わず、外国人の方々に声をかけて写真を撮り、
撮った写真をスライドショーにして Youtube にあげてみました。

良かったらご覧ください。

https://www.youtube.com/watch?v=8AsniQjqUaI
https://www.youtube.com/watch?v=Na0Vi1nJNfY

このコメントがこちらの規約に違反する場合は、
削除をお願いします。

投稿: MOMO | 2019.11.07 12:18

いつも勉強させていただいています。
不勉強で恐縮なのですが、リーグ戦の結果については、「リーグ戦」の中に、情報を持てばよいでしょうか。あるいは別に要素を作ったほうがよいでしょうか?


現在の「リーグ戦」にある項目(開催予定日、開始時刻)などは、試合前にわかる情報である一方、試合結果は、試合後にわかる情報なので、これらを一つにまとめてしまうのは、キレイではないかな、とも思いましたが、さて、どういうモデルがあるべきなのか、というところが、自分ではわからず、ご教示いただけますと、大変幸いです。

投稿: はじめ | 2019.11.19 14:58

はじめさん

まとめてしまって問題ないと思います。それらは値が決まるタイミングが違いながらも同じ主キーに関数従属しているからです。以下の記事でも書いたのですが、別の視点からあらたに記事をまとめてみたいと考えています。

予算テーブルと実績テーブルを分ける?
http://watanabek.cocolog-nifty.com/blog/2018/09/post-d3c7.html

投稿: わたなべ | 2019.11.22 10:00

ありがとうございます。

予算と実績の事例は、以前に実装したことがあるので、わたしにとっては理解しやすい例でした。

その際に、苦慮した点としては、

・変更があった際の日付の管理
予算の登録、予算値の変更、承認、実績値の登録など変化点あった日付が管理できていなくて苦慮しました。(記事にあるようなステータスを活用するは一案で、ステータス+日付のテーブルを別に持つべきでしょうか?)
・月々の予実績の管理、年度の予実績について
 過去に実装した際には、PKが年度としてて、結果として、1月~12月までのカラムを定義していました。
 シンプルなのですが、あまりきれいなテーブルではないのかな、と思ったり。
ご紹介の記事にある通り、年月をPKにすればよいのでしょうか、そうすると年間の合計が、テーブルを見てもわからない(SUMしないといけない)のが面倒だなと思ったりしていました。

投稿: はじめ | 2019.11.27 15:52

コメントを書く



(ウェブ上には掲載しません)




« 骨格→筋肉→皮膚の順序で仕様を決めよう | トップページ