MindmapModeling「1回のメール配信で売り上げ数千万アップの驚異」

11月17日(土)に横浜モデリング勉強会(facebook group)を行いました。また、会場には(株)アットウェア様の会議室をお借りしました。参加された皆さん、アットウェア様、どうもありがとうございました。

この勉強会で、浅海が作成したモデルを紹介します。モデルはMindmapModelingの手法で作成しました。(勉強会で使用したチュートリアル)

ワークショップの流れ

モデリング勉強会はワークショップ形式で以下の作業を行います。

• 雑誌記事から情報システムの企画書、提案書、RFPの元ネタとなるモデルを作成する。

その上で、「要求仕様確認、実装可能性確認、開発のベースとなるプログラムを自動生成するモデルを目指」します。詳細は「ワークショップの進め方 第2版」になります。

テーマ

モデリングの対象は、日経ビジネス誌の記事「1回のメール配信で売り上げ数千万アップの驚異 - 良品計画のWebサイト『MUJI.net』の秘密を聞く（前編）」です。タイトルがキャッチーでよいですね。メールによるO2Oも旬のネタといえます。

用語の収集と整理

まず用語の収集と整理します。

MindmapModelingに慣れてくると、用語がだいたいどこの枝に収まるのかわかるようになるので、用語を拾いながらラフなモデルを作っていきます。

今回の記事は、色々な規則的やノウハウ的なことが多く書かれていたので、これらの記述は「規則」に分類しました。

登場人物の「顧客」は常識的な線でモデル化します。

ポイントとなりそうなのが出来事です。メールを使ったクーポンの発行がこのモデルの軸になりそうです。

クラス図

この段階でのマインドマップをSimpleModelerでクラス図化したものが以下になります。

顧客の島とイベントの島ができていますが、全体としてはまだばらばらです。

物語

次の作業は「物語」です。

モデルは中心軸がないと単なる「用語」の集りなのでまとまりがでてきません。何らかの目的を実現するための構造を抽出したいわけですが、この「目的」と「目的を実現するための構造」を掬いとるためのツールとして有効なのが「物語」です。オブジェクト・モデリングの概念ではビジネス・ユースケースということになります。

「物語」を中心軸と定め、「物語」のスコープで用語を取捨選択、組織化し、足りない用語を補っていきます。

その手順は:

1. 物語の名前をつける。目的(goal)が明確になる名前がよい。
2. 物語の主人公、相手役、脇役などの登場人物を定める。
3. 物語で使用する道具を定める。
4. 出来事または脚本の列として脚本を記述する。

となります。2の登場人物と3の道具は最初から完全なものはできないので暫定的なものを定め、4の脚本の作業を通して洗練させていきます。

「物語」として、「メールの店舗売上効果を測定する」を設定し、この「物語」の作成を軸に、「出来事」の整理、「道具」の整理を進めました。

出来事はあくまでもイベントの記述に特化して、クーポンは道具の方に分離しました。

また、今回新しいBOI構造枝として「要約」を追加しました。これは、「MindmapModelingと集合知(7) - クラウド拡張」などでクラウド・アプリ向けのメタモデルの拡張を説明してきましたが、この中の「サマリー」に相当するものです。

出来事の発生によって道具の状態が遷移していくのが、モデルの基本的な振舞いですが、「メールの店舗売上効果を測定する」という形で測定を行う必要があるので、測定対象のエンティティが必要になります。この測定対処のエンティティとして「要約」を用意しました。要約はバッチ処理で一定期間内のイベントの発生結果を集約する処理に用います。

クラス図

この段階でのマインドマップをSimpleModelerでクラス図化したものが以下になります。

だいぶまとまってきた感じです。クラス図を見ると、ユースケースから各種イベントをへて顧客に至る関係は確保できたことが分かります。その一方で、クーポンとイベントの関係がまだ設定できていません。

このあたりの関係はクラス図にしてみるとよく分かりますね。

一点、ビジネス・ユースケース「メールの店舗売上効果を計測する」からビジネス・タスク「BTメールの店舗売上効果を計測する」への呼出しをinclude依存性で記述する図になっています。ビジネス・タスク「BTメールの店舗売上効果を計測する」は内部的に自動生成したものですが、こういった図の場合は冗長なので自動生成させないようにしたいと思います。

ちょっと洗練

上の「物語」の作業からあまり時間が取れなかったので、道具にあるクーポン周りをブラッシュアップしました。

クラス図

クラス図は以下になります。

ここまでの作業で時間切れとなりました。

上のモデルから引き続いて出来事と道具の間の関係が設定できていない状態です。また、「メールの店舗売上効果を計測する」の要となる、RFM(Recerency, Frequency, Monetary)を計測対象とした計測の振舞いをクラス図の上で表現するところまで持っていけませんでした。

やるべき事はだいたい見えてきた感じです。作業を続けるとすると、まずは上記2つのポイントを埋めていくことになります。

ノート

今回のモデリングでは「要約」の他にいくつか機能拡張を行いました。機能拡張についてはSimpleModelerでの使い方を含めて別途説明したいと思います。

次回

次回は12月15日(土)です。

詳細情報はfacebookグループ「横浜モデリング勉強会」を参照してください。

今回と同じく「ワークショップの進め方 第2版」の手順で、「雑誌記事から情報システムの企画書、提案書、RFPの元ネタとなるモデルを作成する」を行う予定です。