【コラム】データ活用型組織づくりを成功させる、データのあり方のベストプラクティスまとめ

※本記事は、アタラ合同会社 Official noteにて公開中の記事を転載したものです。



目次

・データ活用型組織づくりを成功させる、データのあり方
・その1. ワイド型データは活用に不向き
・その2. 表記のゆれにも注意
・その3. IDは数値型かつ、文字列を含んだ形にする







データ活用型組織づくりを成功させる、データのあり方

昨今、デジタライゼーションやデジタルトランスフォーメーション(DX)などのニュースや記事が巷を賑わせていて、データの活用に関する話題を耳にしない日は少ないでしょう。私が日々、クライアント企業様のBIツールのご導入や定着化をご支援する中でも、「DXはいずれ取り組むべき課題」ではなく「今向き合う課題」であるという危機感を抱く企業も少なくなくないと感じます。


デジタライゼーションやDXを進めるにあたって、社内に分散するデータを収集し、可視化&分析し、意思決定&アクションするといった「データ活用のプロジェクト化」を行うことは、成功に欠かせない重要なステップです。そのため、日々多くの企業や組織でデータ活用プロジェクトが推進されています。


データ活用プロジェクトでは、データを統合して簡単に可視化でき、かつシームレスに分析して次のアクションにつなげらるれるBIツールをいかにうまく活用するかがポイントとなります。


そのBIツールを活用するにあたり、可視化や機械学習などで分析の対象となるデータのあり方は、データ活用プロジェクトの推進に大きく影響してきます。


ではなぜ、データのあり方がプロジェクトの推進に影響を及ぼすのでしょうか。BIツールを用いたデータ活用プロジェクトにおいては、”データの準備 → 可視化 or 分析 → 新たな可視化 or 分析対象の発見 → データの準備 → …” といったサイクルを繰り返して行きますが、データはプロジェクトの一番最初に準備する、言わば基盤です。ここを疎かにしてしまうと、仕切り直しが多くなるため、結果的にプロジェクトを推進するスピードが遅くなります。


逆にデータがきちんと活用できるように整っていると進行がスムーズになり、プロジェクトを回すサイクルも速くなります。


本記事では、プロジェクトの進行がスムーズになるように「データ活用のためのデータのあり方」のベストプラクティスをいくつかご紹介します。






その1. ワイド型データは活用に不向き

まずは2種類のデータの持ち方、ワイド型データとロング型データについてです。ワイド型データとは、新しい情報が行ではなく列としてテーブルに追加され、横に伸びていくものです。ExcelやGoogle スプレッドシートなどテーブルそのものを完成形として扱う場合は、視認性が良いのでワイド型のデータ形式がよく使われています。


しかし、年次 → 月次 → 日次のようにデータの粒度が細かくなればなるほど、横幅は大きくなるため、ワイド型データはデータの蓄積には向いていません。また項目数が増え、テーブル構造そのものに影響を与えるため、加工や整形にも手間がかかることがあります。


ワイド型データの例


ダッシュボードへ活用にはロング型データがおすすめ

一方でロング型データは、新しい情報が行として追加され、縦に伸びていきます。ぱっと見たときの視認性はワイド型データに劣りますが、テーブル構造には変化を与えないので蓄積や可視化のための加工や整形もしやすい形です。


またあらかじめ最小粒度でデータを持っておくことで、他のデータとの突合時や可視化、分析時に集計することもできます。非常に柔軟性のあるデータ型なので、ダッシュボードに活用するデータはロング型をおすすめします。



その2. 表記のゆれにも注意

次に表記のゆれについてです。表記のゆれとは、同じ意味を表すテキストにおいて、複数の表記が混在している状態のことを指します。


特にデータの突合や集計時に使用する項目で表記のゆれが起きている場合は、データの値などが大きく変動、分散してしまいます。日本は表記が豊富(ひらがな、カタカナ、漢字、ローマ字、半角or全角)なので、これらを加工や整形で修正するのは大変手間がかかります。あらかじめ社内で表記のルールを定めて各メンバーがそれを遵守し、定期的にメンテナンスを行うことで、表記のゆれは予防できます。






その3. IDは数値型かつ、文字列を含んだ形にする

最後にIDについてです。他のマスタテーブルとの結合や集計のキー項目としてIDを設定して使用することで、前述した表記のゆれを回避する手段にもなります。またIDはメジャーではなくディメンション、連続データではなく不連続データとして扱うことが、一般的には扱いやすいとされています。なぜならば、IDは数値として扱ったり集計や平均を出すことはなく、常に独立したデータとして扱うためです。(※「ディメンションとメジャー、連続データと不連続データ」について詳しく解説した記事は、今後作成予定です)


また、データを取り込んだ際に、テキスト型のディメンション & 不連続データとして判別されるようにするため、IDは数値のみではなく文字列も含んでおくことをおすすめします。


例:
○ a0001
✕ 0001


これらのベストプラクティスを意識しておくことでデータの取り扱いやすさや可視化する際にデータ周りでつまづく可能性がグッと減り、結果的にデータ活用プロジェクトの推進力に雲泥の差がつくでしょう。


一つ一つは小さな工夫かもしれませんが、ぜひチーム内で共通ルールを設けて、ルールに則って実施することをおすすめします。


【お知らせ】LINE@では、Unyoo.jp最新記事の公開情報を配信しています。ぜひご登録ください。
友だち追加

Related posts

Top