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