株式会社 石川設計 システム開発をとことん極めます！

　今日も見に来てくれて、ありがとう。地道に書いていきますので、また見に来てくださいね。先週、700%にユーザー数がいきなり増えていて、びっくりしました。なぜかカナダから、同時期に34ユーザの訪問があったのでした。ま、そのひとたちは、二度と来ないと思いますけど。そう34ユーザーでも700%です♪

　さて、先日エンティティの定義について書きました。エンティティが定義できたら、次はエンティティの種類について検討します。システム設計では、データをマスタ系とトランザクション系というふうに分けて管理することが多いのですが、TM(T字形ER手法)では、エンティティをリソースとイベントの二種類に分けて考えます。リソースはその名の通り、その組織の中で管理されている資源にあたるものになります。イベントは基本的にはその組織の中で発生した出来事（実施した仕事）を記録したものになります。また、イベントはリソースから生成することができるので、全てのリソースを把握することがとても重要なことだと思います。なので、リソースとイベントの数を比べたときに、リソースの数が多ければ、その組織はまだまだ改善の余地（新たに仕事を生み出す可能性が残っている）があり、イベントの数が多ければ、打つ手が少ないのでは、という可能性が考えられます。

　TMでは、エンティティの種類の定義は以下の通りです。このように、明確に定義されているのがTMの特徴です。他の手法でもリソースとイベントを分ける場合はあるようですが、その場合でも例示（社員はリソース、受注はイベント等）のみで、定義は示されていないということだそうです。

イベント：日付（タイムスタンプ）によって並べられる
リソース：イベント以外

　例えば、認知番号が「受注番号」だとエンティティは「受注」になり、「受注日」という属性があれば、そのエンティティはイベント、ということになります。そう、とっても簡単ですね。これで世の中のエンティティをすべてイベントとリソースに分けることができるようになりました！

　めでたし、めでたし、と、なればよかったのですけど、現実世界はそんなに甘くありません。ある日、最初の悩みが生まれました。それは、イベントのふりをしているけれど、イベントではないエンティティがあるんじゃないか、という悩みです。基本的な考え方として、イベントは、取引の実績など、事実を記録していくもの、という特性があり、リソースは、仕事をしていく上で必要な資源、という特性があります。上記のルールどおりに考えると、資源にあたるものだけれどもイベントに分類されてしまうものが出てくるのです。例えば、契約番号に契約日があればイベントです。でも、「契約」エンティティが組織にとって重要な資源として扱われそこからさまざまな仕事が生まれてくるような場合、リソースになるような気がするのですよね。仕事とともに忘れ去られてしまってよい情報ではありませんのでどうしてもリソースとして扱いたくなったのでした。で、よくよく考えてみたところ、日付が表していることがらに違う意味があったのです。

日付の違い：
１．記録のためのタイムスタンプの日付（監査証跡）
２．開始、終了などの、範囲を表す日付（未来日付）

　そう、この「１．」の方がイベントのよりどころになる日付で、「２．」の方は違う、ということを発見したのでした。ぼくが悩んだ今回の「契約日」は、契約を交わしたイベントを記録した日付ではなくて、もうちょっとていねいに表現すると、この日から契約が始まりますよ、という「契約開始日」だった、というわけです。このように日付の意味を考慮した場合には、契約がリソースになることがあるので注意が必要です。契約をリソースとして正しく管理できれば、譲渡や継承の問題も解決しやすくなりそうですね。

　このリソースとイベントの分類、なにがうれしいの？というひともいるかも知れませんので、ちょっとだけ補足します。例えば、海外旅行保険契約やレンタカーの貸渡契約などは、ルール通りイベントで問題ないと思います。ただ、その時に契約したひとの情報をイベントの中に記録しておくだけだと、新たな仕事も生まれません。でも、これら契約者の情報をリソースとして管理できるような仕組みにした場合、新たな可能性が考えられるようになります。例えば、契約者に対して、他の類似商品の販売や、サービス向上の可能性を考えられます。イベントとして埋もれてしまったままだと、その可能性に気づくのはなかなか難しいと思います。システム設計上はもちろんですが、ビジネスとして考えた場合にも、リソースを把握して見える化する、ということがとても重要ですね。

　今日も見に来てくれて、ありがとう。励みになります♪

　先日「エンティティ」という単語を何となく使ってしまいましたが、それほど一般的なことばではないよねぇ、ということが気になっていて、ちょっと補足したいと思います。

　ぼくが初めてエンティティということばを聞いたのはいつでしょうかねぇ、たぶん、システム開発の中で必要だと言われていた、「ER図（Entity-Relationship-Diagram）」というドキュメントからでしょうか。日本語では実体関連図、と翻訳されています。ぼくはこの図を見たとき、リレーショナルデータベースのテーブルとその関係を表す図になっていたので、単純にこう思っていました。

エンティティ　　　　＝　テーブル
リレーションシップ　＝　テーブルとテーブルの関係

　システム開発の製造工程、プログラムを作成するうえでは、この理解で充分でした。画面や帳票があって、どのテーブルのどの項目が画面や帳票とマッピングされるのか、どんな条件で取り出せばいいのか、ということさえわかればプログラミングできたからです。当時はほとんどのひとがそんな認識だったんじゃないかなぁ。どうしてそんな風になっていたかというと、当時、リレーショナルデータベース(RDB)は新しく登場した概念だったし、システム開発においては、単なるファイルに替わるものとして利用されていたからだと思います。画面のプログラムを作るためにはそこに表示するデータを格納するためのテーブルが必要で、これがなかなか決まらなくて、苦労していたのをよく覚えています。

　TM（T字形ER手法）を習ったときには、エンティティは以下の通り定義されていました。あまりにも簡単で明快！でも、それまでモヤモヤしていたのがスッキリしました！

エンティティ：管理したい対象で、認知番号があるもの

　当時「認知番号」は、個体指定子と言われていました。英語では、entity-setterです。その前は、identifierと言っていました。日本語だと「識別子」という意味になるのですけど、あまり適切な訳ではないということで、当時はidentifierを英語のまま使っていたということでした。このあたり、佐藤正美先生（TM（T字形ER手法）の考案者）が考えられることですので、またちょっとしたら呼び名は変わるかもしれません。いずれにせよ、簡単に言うと、認知番号は、番号、No、ID、コードがついた項目で、これらをもとにエンティティを作る、ということになります。例えば、以下のようになります。

認知番号：顧客番号　→　エンティティ：顧客
認知番号：商品No　→　エンティティ：商品
認知番号：店舗番号　→　エンティティ：店舗
認知番号：取引ID　→　エンティティ：取引

　「エンティティ＝テーブル」と思い込んでいて、テーブルって、何を基準に作るんだろうねぇ、と思っていたぼくにはかなりの衝撃でした。それまでぼくが知っていたエンティティは実体と訳されていて「業務におけるひとまとまりのモノ」みたいに言われていたのです。「モノ」ってなんなんだよ、誰がどうやって決めるんだよ！というぼくの疑問のような不満なような問題は、簡単に決着がついたわけです。

　この衝撃の事実を知ったことで、うれしくなったぼくは、ずっといろんなひとに説明して回っていたのですけど、あるときなんと、「そんなの当たり前のことでしょ。どうして大発見みたいな感じなのか、よく分からないんですけど？」というひとが現れました！ぼくにとってのこの大発見は、プログラムもテーブルも作ったことがないひとからすると、別に声を大にして言うようなことでもなんでもなくて、自然なことだったようです。む～、確かに！余計な前提知識があったために、ずいぶんと遠回りしちゃったようです。もうちょっと、素直になろう♪

　今日も読みに来てくれてありがとう。来てもらってうれしくなったのでまた記事を書こうと思います。
　どうしてこんなことを書いたかというと、Facebookでつながっている方がブログアクセス数500を超えた、と、大喜びをしていたのです。ぼくのブログは完全に自己満足なものなので、ほとんどのひとが読んでいないだろうなぁ、と、思っていたのです。それでもまあ勉強になるよね、と思ってその方のまねをしてGoogle Analyticsを設定してみたところ、なんと、意外にも毎日ひとりとかふたりとか、ちょくちょくアクセスがあることが発覚しました。（予想通りアクセスのない日もありましたよ。）
　来てもらったひとにあんまりがっかりさせては申し訳ないので、もうちょっと記事を書いていこうかと思った次第です。今後とも、よろしくお願いしますね。

　さて、タイトルの「日頃のトレーニング」について、です。かれこれ20年ほど前、佐藤正美先生の「ビジネスの実態がわかるデータベースの作り方」という早稲田大学エクステンションセンターのセミナーで、衝撃を受けました。野球選手なら、日頃のトレーニングとして色んな練習をしてから、試合に臨みます。それに比べて、練習なしで、いきなり試合に参加してくるエンジニアが多すぎる、というお話をしていただきました。確かに！ぼくはエンジニアとしてということを意識した練習、何にもしてませんでしたね！でも、エンジニアの日頃のトレーニングって何だろうねぇ、というのが、今日のお話です。

　池袋ジュンク堂書店では、書籍などを１万円以上お買い上げの方には、４階にあるMJブックカフェ池袋店のブレンドコーヒー引換券がもらえます。今日はこの引換券を使ってただでコーヒーをいただきました。ただ券でも、レシートをもらったら、必ずトレーニング開始します。

　セミナーで教わったことは、データベースの論理設計をしながらビジネスの分析をする、というもので、まずは「番号、No、IDなどの管理するための番号を認知番号として、エンティティを作る」ということです。この認知番号が取られているモノは、その企業などの組織の中で、管理したいモノであるということが現れているので、まずは、そこを起点にします。

• 端末番号　→　端末
• 取引ID　→　取引
• ID　→　Wi-fi
• No.　→　？

　という感じです。このレシートに情報を出力するためには、店舗も管理しないとねぇ、とか、取引IDとNoはどちらもこのレシートを特定するために使えるけど、その違いは何かなぁ、とか、Noの桁数が多すぎるので、桁の上の方は他の何かを管理している番号かもねぇ、とか、Wi-fiはホントに管理されているかなぁ、管理するとしたらどんな管理方法になるかなぁ、とか、【IK】って何かなぁ、とか、引換券は「割引100%」として入力されているのかぁ、とか、他の割引方法はないのかなぁ、とか、取引IDが連番なら、いつからの連番なのかなぁ、いまお客さんが10人入っていて、一時間ごとに入れ替わるとしたら、一日10時間営業だとおよそ100人、取引IDの138130を100で割ると1381、365日で割ると、およそ4年分くらいなのかなぁ、とか、端末番号には47AEと書いてあるけど、この店舗に1個しかないのに、変な番号だなぁ、どういう付け方をしたらこうなるんだろう、とか、とか、とか、ずっと妄想、いや、これがトレーニングですね。
　こうやって、日々、思考力（妄想力）を鍛えておけば、試合で考えることを要求されたときにも、パッと答えが出せる、ということになりますね。そう考えると、コンサルタントって、妄想力が強いひとに向いた職業なのかなぁ。