アジャイル開発大競演「ラグビーW杯データ管理システム」＜第75回IT勉強宴会in名古屋＞

20191116(土)　13:00、名古屋で開催しました。東京方面からも大阪方面からも多数お越し頂き、23名の方に集まって頂きました。案内はこちら

IT勉強宴会としての名古屋開催は2014年2月、2016年9月に続いて3回目でした。懇親会で「5年前にも来ました」と仰る方がおられたのはうれしかったです。ただ、主催者の佐野が前日にお腹を壊し発熱し、ほとんど眠れていませんでしたので充分なおもてなしが出来なかったかも知れません。謝っておきます。

懇親会は17名でカラオケボックスの20名部屋にお酒を持ち込んで、3時間熱い議論をワイワイやりました。渡辺さんがギターとアンプまで持ち込んでくれて披露してくれました。私は何も食べられず熱いお茶しか飲めませんでしたのでそこで失礼しましたが、常連さんは2次会に繰り出されたようでした。

★このブログでは、私も含む発表者がテーブル、オブジェクトと発言した時も「エンティティ」と表記します。発表者の趣旨と違った時はお許し下さい。
★それぞれの発表された資料、前提としたモデルなどはここに公開しています。
https://drive.google.com/open?id=1dVcvzSJ1gPrPGdFhmxsPCbyY6RKnWWd3
発表資料はタイトルにもリンクしておきます。

１．データモデルの基本と今回のモデル解説

　デービーコンセプト　渡辺幸三さん

ネット記事か何かで、ワールドカップラグビーのUMLが載っていました。オブジェクトIDがキーになっています（ID方式）ので構造が読み取れません。そこでデータモデルを書いてＩＴ勉強宴会のメーリングリストに投稿しました。すると色々な意見をいただきシェープアップすることが出来ました。ところが、モデルだけをみてもわからないことも多いです。プロトタイプを使ってみないと本当に良いデータモデルは作れないのです。

ID方式で実装してしまうと、プライマリーキーがIDになりますので、どんなデータでも登録出来てしまいます。ユニーク制約をロジックで担保することを漏らすと、必要なユニーク制約が入っていないために10年後にバグが出るような事になります。

本日は実装ツールのイベントですが、「ツールを使わなくてはいけない」のではなく「データモデルを改善するためには実装ツールが必要」ととらえて下さい。

モデルをみて気付くのは、「開催年」という項目です。これはUMLモデルにはありませんでした。恐らくW杯ページだけを見てそのままモデリングしたので、ページに出てこないものは対象にしていないのでしょう。情報管理を長年やっていると「何となくわかる」ことがあります。名詞だとか動詞だとか、モノだとかコトだとかを集める分析的プロセスでは本来必要な要素を見逃すことが良くあります。
下側にある、代表チームと代表メンバーには年度を持っていません。つまりここには往年の名選手である平尾さんなども入っています。ワールドカップの開催年ごとに出場できる国（地域）とメンバーが決まりますのでここには開催年が入るという構造になっています。
背番号というのも調べると面白くて、代表メンバーに選出された時の標準（？）背番号はあるのですが試合ごとに先発かどうかで背番号が変わるようです。そのため公開時点では「出場メンバー」だけに持っていた背番号項目を「リーグ戦出場メンバー」にも持たせました。

「リーグ戦」と「リーグ戦チーム」の関係も最初は親子関係としていました。そのため、リーグ戦チームの主キーを「開催年、プール区分、L戦行番、チームID」としていました。ところがプール区分は「開催年＋チームID」だけに関数従属する事に気付き、プール区分を導出項目としました。カッコ(  )で括っている項目は導出項目です。他のエンティティから導出出来るという意味です。導出をどういう風に行うかというのがツールの個性だと思います。この項目を実装してはいけません。この例では「出場チーム」エンティティにプール区分を持つ事が出来ると気づきました。

実装すると、２つのメニューが出来ました。これも実はデータモデルから必然的に出てくるものです。一つは一番上にある「W杯開催」エンティティからのメニュー、もう一つは一番下の「代表チーム」エンティティからのメニューです。アプリ開発に丸1日、実データの登録に半日ほどかかりました。
勝利チームを自動的に判断するロジックが想像以上に複雑になりました。XTEAのロジックはJavaScriptで書きます。データモデルを作成する時とこういうロジックを考えている時こそが技術者の仕事だと実感します。メニューや画面など単純作業はツールに任せるべきだと思います。

２．Salesforceでの実装

　　　株式会社テラスカイ　　佐野初夫

セールスフォースは1999年にOracleの上級副社長であったマークベニオフが創設したクラウドサービスです。基本はCRM（Customer Relationship Management）ですので、顧客接点を管理する仕掛けです。
セールスフォースでシステムを構築する時は、データモデルありきになりますので、ほとんど失敗しません。データモデルが決まらないためスタートしない事はありますが、それさえ確定すれば動かないという事はありません。複雑な処理には向いていませんが、「セールスフォースごときで出来る仕事は若い技術者の時間を使わずにツールに任せましょう」というのが私の主張です。

このデベロッパーフォースから一生無料のライセンスが取得出来ます。トレイルヘッドではプログラミングまで無料で学ぶことが出来ます。

セールスフォースで実装する時には、「取引先と担当者」とどう紐づけるかを考えます。この2つのエンティティはセールスフォースのライセンスがあれば必ず無料で使えますしこのエンティティに関連する便利機能が多くあります。そのためこれらをどう上手く使うかがポイントになります。今回は、出場チームと出場メンバーの関係として使う事にしました。そのため、開催年は持っていませんのでご理解下さい。

エンティティ間のリレーションについて、特徴的な機能として「連結オブジェクト」というものを使っています。これは、親子関係の親が2つある構造です。親から子エンティティは「関連リスト」という機能で一覧を見る事が出来ます。ところが、この子が連結オブジェクトだと、親１の関連リストに、子をスルーして親２の項目を出すことが出来るのです。

セールスフォースの標準画面だと、複数のレコードを一度に登録する事は出来ません。今回の業務だと、例えばプール戦の出場メンバーを登録する時に1レコードずつ登録するのは相当大変です。そこで、テラスカイ社のSkyVisualEditorというGUIツールを使った画面を作りました。左側で検索したプール戦の試合について、「メンバー入力」ボタンを押すと右側のLightningComponentに通知されて自動検索されます。右側の「マスター取得」ボタンを押すと、検索窓が開きメンバー一覧が出ます。メンバーを選択し「選択」ボタンを押すと元の画面の明細に入るという動きになります。

３．Rmenuでの実装

　　　エルゴ　　　下山吉洋さん

大阪の下地忠史さんという方が作られたRmenuというフレームワークを使った実装について説明します。本当なら下地さんが説明された方が良いのですが、仕事の関係で来れないという事でしたので私から紹介します。

データモデルさえ出来れば画面が自動的に出来る「RmenuVisualTools3」というWizardを使って実装しました。エンティティを定義して、画面の項目を指定するだけで画面が出来上がります。

実際に私自身が業務で使っている画面も少しお見せします。タイムレコーダーは実際に動くものを持ってきました。QRコードをかざすと遅番早番なども自動で処理されます。トラックの幌を設計するシステムはパラメータを入れると図面が画面に表示し、必要ならPDFでも出力出来ます。最初は画面とPDFを別々に処理していたので修正が大変だったのですが、今は一旦SVGで出力してから画面やPDFに表示するように変更しました。

４．パターンとは何か

　　　名古屋経済大学　　中西昌武教授

名古屋経済大学は犬山市にある大学ですが、この名駅サテライトには働きながら税理士を目指す方が多く通われています。東海地区屈指の300名以上の税理士が誕生しています。

パターンとは何かというお題なのですが、私はパターンとは何かを話せません。それは一生かかってパターンとは何かだけを考えている学者の方がおられるからです。学者だけなのかと思っていたのですが、トヨタの方と話をしたところ、一生歯車だけの専門家という方もおられるそうでした。今回は「パターンとは何かを考えるとは何か」について最近考えている事をお話します。

5年前にフォームを自動生成する機構ということで「概念フォームエンジン」について、このIT勉強宴会で説明しました。データソースの構造が決定するとそこから派生されるフォームは限定的になるという証明でした。

パターンとは「情報構造」です。構造とは「要素とその間の関係」ですから、パターンとは「関係づけ」だという事も出来ます。「これをパターンにしたら作りたいシステムが作れるよね」と考える時、そう考えるという事は何なのでしょう？良かれと思ってお奨めパターンを与えると、他の可能性が見えなくなる危険性があるかも知れません。

システムの施主（エンドユーザ）が、「あ、自分にも見える！」というパターンを与え、施主みずからの責任で業務要求解明に取り組む動機づけを与えることは可能か？
世界の学者は「鳥の目」で方法論を作っていますが、日本人（の匠）には虫の目からのアプローチの方が向いていると考えて業務を見る視点を提案してみます。

＜探究レベル１：管理対象の認識態度（施主に自分の目を自覚させる）＞

１）対象識別態度[I:identificcation]
　→個体識別、同一視識別、カテゴリ識別

＜探究レベル２：管理対象の基本形（施主に業務を観察させる）＞

２）活動事象[E:event}
３）活用資源[R:resource]
４）データ抽出編集[A:abstraction]

＜探究レベル３：管理対象の相互関係（施主に業務の構造を観察させる）＞

５）組織[O:organization]
６）受払[D:due]
７）進捗[P:progress]
８）監視[M:monitoring]
９）相同[H:homology]
10）制約[C:constraint]

上から順に、対象から離れて観察するイメージ。問診票のように使えないかと考えています。これで完備しているかは数理科学的に解明したい（学者の性分として）
最後の煮詰めこそ、プロの専門家の仕事となる

５．OutSystemsによる実装

　　株式会社BlueMeme　　山下さん、沈さん

OutSystemsは2001年にポルトガルで生まれたプラットフォームです。当社BlueMemeは2009年に創業しました。2012年にOutSystemsに出会い日本で初めてOutSystemsを紹介し導入企業を増やしている会社です。現在150社程度導入頂いています。

OutSystemsでの実装手順について説明します。次の4つにわけて構築します。開発ー保守ー運用という全工程の最適化が出来るPlatformです。
１）プロセス
２）インターフェース
３）ロジック
４）データ

頂いた要件のEXCELデータは項目名、シート名が日本語でしたので英語に変えました。それをデータに登録すると自動でエンティティが作られます。
緯度経度がありましたのでGoogleMapを表示しています。これはforgeと呼ばれる、無料で様々な部品などを提供・利用出来るOutSystemsユーザのコミュニティにあったものを使っています。

６．TALONによる実装

　　株式会社HOIPOI　古関雄介さん

TALONというツールはデータ構造さえ出来れば、あとはコアとなる処理を書くだけで構築が終わるという思想で作ってあります。今回の実装は会社のメンバにやってもらいました。

１．開発担当者とブレストし与件とモデルの確認（40分）

渡辺さんのモデルから、「トーナメント戦チーム」「リーグ戦チーム」というエンティティはその子供の「メンバー」の積上げ集計で導出可能ではないかと考えて、物理テーブルなしで対応する事にしました。
また、リーグプールの「1位チームT戦行番、2位チームT戦行番」も自動算出可能だと考えて物理テーブルなしとしました。

２．実装時間　12時間

１）出場チームのメンバ登録
開催年の代表にする時は、代表メンバーエンティティから、選手の一覧を出力し背番号とポジションをセットするとその年の代表として登録されます。
リーグ戦出場メンバーを集計して「リーグ戦チーム」を自動算出するにあたり、ラグビーは必ず2チームで対戦するという前提を置かせていただいて、同じエンティティに2チーム入れるようにしました。
これにより一覧として見やすくなっていると思います。この真ん中の明細をクリックすると、下に出している結果ブロックが動的に変化します。これはブロックとブロックの通信機能を使っています。

＜考察＞

全部の発表が面白かったと思います。貴重な時間をありがとうございました。

今回初めてアンケートを取ってみました。あれだけ「事前にご自分で実装してみて下さい」とお願いしたのですが残念ながら1人も実装にチャレンジしてくれていませんでした。1人だけ「30分モデリングだけしました」と正直に書いてくれた方がおられました。勉強会というものは聴いているだけで知識が増えて役に立つという幻想から抜けられておられない方が多いのだと思いました。データモデルはいくら教えてもらっても実際に描いてみて実装してみない限り何の役にも立ちません。ハンズオンとかモクモク会とかの方が良いのでしょうか？ご希望などありましたら連絡をお願いします。

少しでも多くの方に方法論を知ってもらいたいと考えて、同じテーマを6種類のノーテーション（記法）で公開しました。半分程度の方が全部目を通して下さっていたので苦労して準備した甲斐がありました。
ほぼUMLしかご存じない方が4名もおられました。懇親会にこられてなかったので何でこのイベントを知ったのかお聞き出来ませんでしたが少しでも変わるきっかけになって欲しいです。

以上