MotionBoard6.1 サンキーダイアグラムの肝は「データクレンジング」

MotionBoard6.1にバージョンアップに伴って搭載されたネットワーク図の新たな表示形式「サンキーダイアグラム」

私自身がこのサンキーダイアグラムを使ってみて「データクレンジングがこりゃ肝だな」とすごく感じました。あくまでも個人の所感になりますが、一読いただけると嬉しいです。（解説はMotionBoardマニュアルの図を参考にしていますし、作り方はマニュアルが優秀なので参考にしていただいたほうがいいかもしれません）

【この記事を読んでみてほしい人】

・「MotionBoardに携わる人」で「ネットワーク図」を使ったことがない人

・データクレンジングがいまいちわからない人

・BIツールで繋がりや流量を表現したい人

・BIツールでビジュアルを求めちゃう人

そもそもネットワーク図って何なの？

ネットワーク図は「繋がり」を表現するチャートです。その中でもMotionBoardで用意されている表現は３つ。

1つ目は「ネットワーク」で文字通り「繋がり」を表現します。関係性が強固である繋がりは矢印が強調されて表現される感じです。GGG会社と取引の多い会社は矢印が強調され、会社の売上が大きいと円が大きくなります。

2つ目は「階層」で「構成」を表現します。上図だと製品00001がどんな部品で構成されていて、多く使われている部品は矢印が強調され、それぞれの部品名のところにある数字は在庫数を表しています。

3つ目は今回使用した「サンキーダイアグラム」で「流れ」を表現します。上図はWEBサイトで商品が購入されるまでのページ遷移を表しています。WEBサイトを閲覧した人がどのような経緯で購入に至っているのかがわかります。

今回私が使用した表現したかったのが、ものがどういう経緯をたどってどれくらい流れているのかであり、視覚的に表現できるのが「サンキーダイアグラム」だったのです。

上図が今回製作した「サンキーダイアグラム」です。各名称は伏せていますが、実ボードはしっかり表現されています。以下、このサンキーダイアグラムチャートを作って得た気づきを記載していきます。

データソースは2つ必要

サンキーダイアグラムを含むネットワーク図には、チャートを表現するためのデータ（データソースという）が２つ必要であることに気づきました。作ってみてわかったことです。

サンキーダイアグラムは、実は２つに分解することが出来るんです。

１つ目は「プロット部分」で、ものが流れてたどり着く場所（＝拠点）で、どれくらいの量があるのかを表現する部分です。

2つ目は「ライン部分」で、プロット部分で表示されいる拠点から別の拠点へどれくらい流れているのかを表現する部分です。

それぞれにデータソースを準備する必要があります。

しかしながら、ものの流れを表現するデータって普通の会社はないような気がします。私のところもものの流れを表現するデータはなかったのです。

だったらどうするか？　もともとあるデータを加工してサンキーダイアグラムで表現できるようにすればいい。すなわち、

データクレンジングすればいいじゃないか！！

という結論に至りました。

もともと、ものを受注履歴はナレッジとしてたまっているのでこれをうまく使おうという話です。

ここでいうデータクレンジングとは、元あるデータをチャートに表現できるように加工することとしています。

例えば下図のように営業所→中継地→納品地へと流れる構成のサンキーダイアグラムを作ったとします。

受注状況をデータベースに入力するのは中継地点で行われます。

前提条件があり、ものがどこに納品されるのかは営業所を通過した時点で決まっているので、中継地点で受注履歴を残す際には、「営業所、中継地、納品地、ものの量」は決定しているということです。

そんな受注履歴は以下のような形になります。

こいつを「プロット用データソース」「ライン用データソース」に加工していきます。

※一つ注意で上図のサンキーダイアグラムと受注履歴は関係ないので注意して下さい。

ここからはデータクレンジングの話になります。

プロット用データソースを作る

カギになるのがプロットIDです。MotionBorad上の設定では「ポイントキー」に相当します。拠点にユニークに与えらえれるIDでなければなりません。しかし、もとの受注履歴を見てみると、営業所の千葉が１であり、納品地の蒲郡が１であるという具合に、番号がかぶっている可能性があると思います。うちの会社も番号がかぶっている状態でした。では、名前をIDにすればいいじゃないか！と思うのですが、営業所の千葉、中継地の千葉という具合にかぶってしまうんです。同一のチャート上に、ユニークに振られなければならない番号、IDがかぶってしまうと、ライン部分が上手く表現できなくなると思います。（やったことはないですが）

なので、データクレンジングの段階でそれぞれの拠点にユニークな番号を振るようにしなければならないのです。今回は、営業所はそのままの番号、中継地は+10、納品地は+20する形にしています。総数も最初に表現したかったので、Topという形で付け加えています。

また、同じ分類の拠点をまとめる（サンキーダイアグラムでは同じ拠点は縦に並んでいる）には、プロット種類というフィールドを用意します。MotionBoardの編集画面では「グループ」に相当する部分です。

ライン用データソースを作る

プロット用データソースを作るとき、拠点にユニークなIDを振らなければならない理由はライン用データソースを作ることに由来するのですが、FROMIDおよびTOIDがまさにプロット用データソースのプロットIDと一致しなければならないのです。でないと、流れを表現できないんです。

MotionBoard編集画面で、どこから＝「FROMキー」、どこへ＝「TOキー」、どれくらいの量＝「線の幅値」「線の色値」になります。

実際のデータクレンジングはSQLにて行った

データベースからMotionBoardに履歴を取り込む際に、SQLにてプロット用とライン用のデータソースのもとを作りました。OralceデータベースをSQL記述でクレンジングして、MotionBoardのインメモリに格納したというのが実情です。

SQLで上記の受注履歴をデータクレンジングするとどうなるか、SQLを書いてみました。（初歩すぎる記述、我流なのであまり参考にならないかもしれませんが、ちょっとでも参考になれば幸いです）

これがプロット用データソースの元を作るデータクレンジングSQLです。

そして、ライン用データソースの元を作るデータクレンジングSQLです。

履歴の例と合わせてみていただけると幸いです。

最後に

ネットワーク図を利用するとき、もともとあるデータをそのまま生かしてチャートに表現することは難しく、データクレンジングがマストになると考えています。かくいう自分も、MotionBoardのインメモリ機能を使うことがマストであったが、そのためには、SQLの記述が必須なスキルになったんです。初めの頃は、SQLはちっとも記述できませんでした。しかし、必須なスキルと化した＝壁の出現でやらねばならず、Accessでクエリデザインを利用してデータ抽出をした際に、SQLビューで確認することの繰り返しをして、何とか初歩的なSQLを記述することができるようになりました。

今では、SQLを記述できることで様々なデータクレンジングを実現することができています。最初は難しくても立ち向かう気持ちって大事だと思いました。

データクレンジングのやり方はいろいろあると思いますが、MotionBoardを含むBIツールではマストなことなので、自分なりのデータクレンジングを取得するといいかなと思います。