はじめに
過去の業務経験をもとに、データ分析に関わる PoC の進め方に関する考えをまとめてみたいと思います。以下は、メーカーや SIer など、顧客に対して PoC を実施する側の視点から記述しています。
ちなみに、いきなり言い訳から入りますが、あくまで個人の経験則に基づく内容であることをご了承ください。
ダッシュボードイメージの共有
顧客が分析画面のイメージを明確に持っているか否かは、本気度を測る上で非常に重要な要素です。導入目的が明確になっている場合、分析に対する要件が次々と出てきます。後は、それらを分析するのに適したチャートを選択し、ダッシュボードのイメージを固めていくような作業を行います。
進め方として良いと思う方法は、白版にダッシュボードのイメージを描いて、顧客と一緒にイメージを固めていくことです。
導入目的が明確となっている場合、PoC キックオフ時に分析画面イメージと要件一覧を提示される顧客もいます。その場合は、もちろんこのステップは必要ありません。
しかし、多くの場合、分析画面のイメージを描き出そうとするだけで時間を要してしまいます。この時点で顧客も実は明確な画面イメージや要件を描き切れていないことに気が付くと思います。
それでも全然かまわなくて、同作業を PoC の機能要件を洗い出すステップだととらえれば良いと思います。
明確なダッシュボードイメージが描き切れない場合、チャートを 1 つか 2 つ作成してみてはどうでしょう。その流れで、要件を考えてもらえば良いのでは？
何はともあれ、PoC の第一歩はダッシュボードイメージの共有だと思っています。
データ準備
分析対象データの準備
作成したい画面のイメージが共有できたら、次は画面作成に必要なデータの在処を確認します。
分析用データを蓄積するデータウェアハウスやデータレイクが存在する場合、そのデータを活用してしまえば良いので楽ちんです。分析用にデータ構造も整っているので、データの準備にはさほど苦労しないと思います。
一方で、分析用のデータが整っていることは決して多くはありません。その場合、基幹システムなどに蓄積されているデータを分析対象とする形になります。
ただ、日中常にトランザクションが発生しているデータを直接参照して分析する訳にはいきません。そのため、中間ファイルなどを介してデータを提供してもらい、それをデータベースに取り込んで分析することになります。
PoC は非機能要件を定義する場としては適していないので、データ容量は必要最小限のものにしてもらうべきです。
問題・課題
データを準備するにあたり、良くある問題・課題を羅列します。あくまで私の経験則に基づくものなので、下記以外にもたくさん要素はあるとは思います。
データ粒度
例えば、予算と実績の粒度が異なるのは当然です。予算は月次、四半期、年次などで立てられますが、実績は毎日のように蓄積されるからです。予実分析を行うためには、実績値を予算に合わせて必要な単位にまとめる必要があります。
コード体系
複数システムにまたがるデータを結合したいという要件もしばしば出ます。システムが異なればコード体系が異なるのは当然の話で、場合によってはコードを一致させるマッチングテーブルの作成が必要なることもあります。
企業の組織コードや製品コードように、全社で共通して使うコードもあります。その場合にも、数値部分の桁合わせて 0 埋めしている場合とそうでない場合などや、大・中・小分類のつなぎ文字が異なるなど、細かな調整は必要かもしれません。
DBにデータ不在
実績値は DB に蓄積されているが、計画値はエクセルなどで管理されている場合もあります。この場合、エクセルデータを DB に取り込む必要があります。
ノイズデータの扱い
分析に不要なデータが含まれることもあります。例えば、売上実績のデータの中で、5 月に発生した高額な誤発注を 6 月の実績値で訂正するとします。この場合、本来上がるべきではない売上が上がっているため、実績を月次でまとめた場合、両月の情報が適切でなくなってしまいます。PoC と割り切って進めてしまうか、該当行を取り除くためのフラグが存在するのであれば、フラグを利用しても良いと思います。
データ精度
あくまで PoC なので、データの正確性にはあまり深入りしないことが重要です。
しかし、良く知るデータだと、可視化した結果を見て、データが不自然であることに気が付いてしまうことは普通のことです。組織毎の過去の売上を見ていたところ、「なんじゃこりゃ？」という結果が見えてしまったことがありました。理由は、組織コードの使いまわしがあったため、過去データがあり得ない結果を示していたことに起因していました。PoC のスコープとは無関係な点ではあったのですが、担当者としては気になってしまうところです。
PoC で洗い出された問題を覚えておいて、本番展開時にデータをクレンジングしましょう、という流れにもっていきたいところです。
スコープと期間
スコープ
ダッシュボードイメージと準備可能なデータがそろったところで、期間内で実施可能なスコープを確定します。PoC なので、あくまで評価に必要なものに絞ることが重要です。
期間
スコープとも関わってきますが、きっちりと実施期間を決めることが重要です。
その際に必要な考慮事項は以下の通りです。
ライセンス有効期間
評価版ライセンスを使って PoC を行う場合には、ライセンスの有効期限の考慮も必要です。
顧客社内での評価期間
PoC で作成した環境を顧客社内で評価する機会が必要です。このような機会も実施機関の一部として十分に考慮します。
具体的には、担当者が作成したダッシュボードを操作して、社内関係者に対してプレゼンテーションを行う場合があるかと思います。あるいは、サーバー上に構築した環境を展開して、オンラインで複数社員がダッシュボードを操作して使い勝手を試す機会などを設ける場合もあったりします。
こうした機会も実施期間に含める必要があります。
また、実装する要素も、評価が受けやすい機能に絞るべきかも知れません。
キックオフでの合意
ここまで記載した内容は、キックオフで顧客ときっちり握っておくべきです。
きちんと文面化しておいた方が良い気がしますね。
その他
その他、考慮が必要かなと思う事項を記述します。
サーバースペック
PoC 用にサーバー環境を準備する場合、ある程度以上のスペックを積んだものを準備すべきです。
パフォーマンスが出ないことが理由で悪印象を植え付けてしまわないようにするためです。
見た目
なんだかんだ、見た目の印象は重要です。
ダッシュボードの配色に、顧客のコーポレートカラーを選択してみてはいかがでしょうか。
顧客の公式サイトにアクセスし、色を確認します。その際、下記 ColorPocker などを使うと、16 進数や RGB などで色を確認することができます。
顧客の許可が必要ですが、ロゴの画像も使用可能であれば使ってしまうのが良いと思います。
最後に
他にも色々と気を付けることはあるかとは思いますが、私の経験上、ここに記述したことは最低限気を付けるべきかなと思っています。
何はともあれ、皆さん良いデータ分析を! Cheers!! Santé!!! Skål!!!