創り出そう、躍動する社会を。挑戦しよう、技術とともに。
ＪＢＣＣグループ
ＪＢＣＣグループ
2021.07.21
上司や経営者からの「今すぐ欲しい」を一発でクリアする！ 分析データ作成のポイント
データ分析を通してビジネスを解析する作業は、健全な企業運営にとって欠かせないも のです。ところが分析には数々の問題点が隠れています。データ分析が正確なものでなけ れば確固たる運営方針を示すことは不可能と言ってもいいでしょう。 ここでは、分析データの信頼性を獲得するためのポイントを分析にあたる際の姿勢と、方 法のアプローチを多角的に解説していきましょう。
- 目次
データ分析で欠かせないポイントとは
データ分析を行う時は最初に「狙い」と「要件」を的確に掌握しなければいけません。例えば、成果物の書式イメージを想定したり、顧客を含めた関係者全員で「狙い」を共有化したりして提出の「要件」を確認するわけです。
次に、完成した時の内容について一定のイメージを予想しておきます。こうしておけば、作業の方向性を早期に修正することができるようになります。上記の作業を終わらせた後、要件を満たすために必要なソースデータ例・方針・手順・手続等の作業プロセスを決定します。
この作業を行うことで必要な時間やツール等が具体的に判ってくるため、納期や費用の見積りを回答することが可能になるのです。
データが示唆する事実を知るために詳細に分割する段階を「分析/ａｎａｌｙｓｉｓ」と言います。料理に例えると、食材を切り刻み加熱する段階です。その作業を積み重ね、最終的な結論を導き出す段階を「総合/ｓｙｎｔｈｅｓｉｓ」と言います。つまり、食器に盛り付ける段階です。
顧客に満足してもらう、つまりお客様が笑顔になるには、ここまでの作業の両方を確実かつ正確に行うことが欠かせません。最初のオーダーと給仕するタイミングを間違えないことが大切という点も同じです。
だから、そのレポートはやり直しになる！ ダメなレポートとは
どんなに高度な統計手法やツールを駆使して明快な結論を報告しても、そもそもの要求事項と合致していなければ、それは「失敗レポート」です。そのような典型的な失敗例と修正例を挙げていきましょう。
《ケース１》
【「狙い」を捕捉できていない例】
「前期の業績が悪かった原因を調べる」という要求に応えて「営業本部別売上分析」を提出した場合、それを受け取った側は部署別の実績について分析を検討することになります。
たとえば「第二営業本部の売上達成率が７６％だった。これが会社全体の業績低下につながった原因だ」と理解するかもしれません。だとすると結果的に、第二営業本部に対して「翌期は売上計画を達成してください」と指示を出すことにしかなりません。ほとんどのケース で、このようなレポートでは本当の解決策を導き出すことはできません。敢えて新たに分析しなくても、その程度のことは経営陣も第二営業本部自体も判っていたはず。つまり「失敗レポート」です。このように、失敗レポートの多くは「だから何？」「すでに知っている」 という反応を呼んでしまいます。
◎改善策◎
１.より細かく分ける⇒営業本部別だけはなく、営業部・営業課・営業掛・営業担当者まで 突っ込んで分析する
２.別の分析軸を用いる⇒品目別・商品番号別・月別・週別・金額帯別・地域別など細かく 分析軸を増やして解析する
３.複数の分析軸を組み合わせる⇒営業部門別・品目別・月別などの分析軸を加える
《ケース２》
【「要件」を捕捉できていない例 1】
「１月３０日１０:００からの経営会議で重要な主張を行う際に、この根拠が示せなければ 説得力が半減すると認識されているバックデータを作成する」という要件があった場合に、 １月３０日１３:００に提出したら、このレポートは「失敗レポート」でしかありません。
ケースによっては許容される場合もあるかもしれませんが、一般的には「期限や納期は至上 命令」と考えておくようにしましょう
《ケース３》
【「要件」を捕捉できていない例 ２】
「１５分後に重要な得意先へ出掛けるので過去５年間の取引のうち特徴的な資料をプリントアウトする」という要求があった場合、重要なのは資料の細かな体裁や完璧さではなく、１５分後に資料として完成し手渡さなければならないというポイントです。それを踏まえ て作業を進めない限り失敗レポートとなる可能性が高いのです。
数値が概算であることや、体裁が不完全であっても、要件を満たすためには１５分以内に資料を渡すことを念頭に置いて作業を進めてください。
《ケース４》
【「要件」を捕捉できていない例 ３】
「金額の単位を百万円とする要件だったが一円単位の資料を作成して提出してしまった」
「分析は完璧だったがＡ４縦という要件だったものをＡ４横で作成してしまった」
「Ａ３用紙に小さなフォントで細かな数字が並んだ資料を作成したため、重要な問題を示唆する箇所に辿り着くのが容易ではなかった」
「１０数枚に渡る分析レポートで、最終的な結論を最終ページの最終行に記載した」
「水産物の品目別実績の分析表なのに、なぜか鉄道会社の記念乗車券の数字が混入した。シ ャケとジョウ‥シャケ‥ンいう検索単語による誤検索から発生した抽出ミス」
管理資料や分析資料等の作成作業を進める際の留意点は、共通項目としてチェックリスト化することが出来ます。但し業界・企業・事業等に依って項目優先度は異なりますので、自社のチェックリストを準備することが重要です。考慮すべき項目の漏れ抜けを防止するこ とが出来ます。
《ケース５》
【「分析ミス」の見逃し】
分析作業では微に入り細にわたる作業が続くため、いつのまにか大きなミスを看過してしまうことがあります。このような事故を防ぐためにも、分析の前段階でおおよその数値想定 を行っておきましょう。 「分析」は「総合」を終えた時点でその想定値と比較できるように なり、大きなミスも発見できるのです。副次的な効果ですが、作業ミスがない場合でも想定値や直観的なイメージとの差異には重要なヒントが隠れていることも少なくありません。
分析が必要となったのは仮説を立証する為ですから、その仮説が要求する結果数値を事前に想定し分析結果と照合する手続を行いましょう。
《ケース６》
【資料の妥当性の問題】
提出する資料がどんな手順で作成されたにせよ、内容の妥当性は立証できていなければなりません。例え信じ難い結果であっても妥当性が立証できていれば、その結論は使用出来る のです。下記に立証するために必要な要素の具体例を挙げておきましょう。
１.ソースデータまたはそのサンプリングの妥当性の確認
２.分析手順や各作業の妥当性。具体的にいうと簡単な作業仕様書や作業ステップ毎の 投入データ例・算出データの記録
３.分析に用いた手法やツール、操作等の記録
４.総合に用いた仮説やツール、操作等の記録
明日からできるデータ分析方法
必要なデータの種類とその収集の仕方を理解したうえで、最終的な分析ＢＩ（Ｂｕｓｉｎｅ ｓｓ Ｉｎｔｅｌｌｉｇｅｎｃｅ：企業内の膨大なデータを、蓄積・分析・加工して、企業 の意思決定に活用しようとする手法）を中心に記述する方法について順を追って解説していきましょう。
ステップ①
必要な資料を作成するために、対象とするソースデータを決め、範囲を限定したうえで必要なメッシュで収集・抽出します。例えば、取引毎の明細データが必要なのか、集約したデータが必要なのかを判断します。
また、データ発生・実現の期間範囲も定義します。直接的に 使用できるソースデータが存在しない場合には、他データからの変換を検討し、それでも不足ならアンケートや更なるデータ収集の実施を検討します。
この時点で行うべき作業としては、使用するＢＩツールを決定して、その優位性や特徴及び機能の限界を共有することです。
ステップ②
[ＢＩツール操作]
分類するキー項目を検討する。項目が複数になる場合には、その優先順位を決める。
ステップ③
[ＢＩツール操作]
作表時には一次元・二次元・三次元等の種別を検討、三次元以上なら行列式やグラフの利用も検討する
ステップ④
データ分析手続を設計する。どのような手続をどのような順序で実施するかを予め記述しておきましょう。
ステップ⑤
[ＢＩツール操作] 設計どおりにデータ分析を実施する。具体的には抽出・分類・集計・統計資料等が対象になります。
この際、事前想定との乖離がある場合にはステップ④からやり直します。
ステップ⑥
[ＢＩツール操作] 仮説に基づいて分析データからデータ総合を実施する。
ステップ⑦
[ＢＩツール操作] 強調表示等のデコレーションを施したうえで報告資料を作成する。
データ分析上の落とし穴と対応
データ分析に用いるソースデータを獲得したとしても、そのソースデータに信頼度がある かどうかは別途検証する必要があります。
財務報告の信頼性に係るデータには「ＩＴ全般内部統制(以下ＩＴＧＣ)」が厳格に求められ ます。それだけに、そのデータを作成したＩＴの信頼度を検証する必要性があります。言い換えれば、財務報告の信頼性に係るＩＴアプリケーション（ＦＳＡ：財務会計的に重要なア プリケーション）のインフラ上の方針と手続を検証する作業です。一般的にこの作業は財務 報告の信頼性ほどの厳格さは求めないにせよ、一定水準の信頼性は必要だと考えられてい ます。また、ＩＴツールやＭｉｃｒｏｓｏｆｔ Ｅｘｃｅｌ等のスプレッドシートを使用す る場合にもＩＴＧＣに準ずる信頼性が求められます。
データ分析資料の仕様書整備
ソースデータの生成にしても、それを用いた分析資料作成にしても、ビジネスの場では必ず再現可能性が求められます。
「高度で複雑な手続と直感的操作の連続のため二度とできません」という言い訳は通用しないのです。
誰が実施しても同じ結果になることが必須です。
そのため、分析資料には仕様書や解説文書が整備されていることほうが望ましいと言われています。
万一、誤りの可能性が指摘された場合でも、それを否定するにも肯定するにも確固たる根拠が必要だからです。
極めて複雑な手順を行わなければ作成できないデータ分析資料の場合は、その手順自体をプログラム化して自動化するという方法もあります。
ただし、プログラム化＝ブラックボックス化ですから、詳細かつ完全でシステム変更のたびに更新されるようになったシステム仕様書の整備は必須なのです。
カットオフ問題の解決
分析に使用するデータはその発生期間が、分析すべき期間の範囲内に収まっていることが 厳密に求められていますが、データで嘘をつく人間はここで誤魔化します。会計・監査でいう「カットオフ」です。
たとえば、検収基準で売上計上する三月決算企業が３月３１日に出荷して、クライアントが４月 1 日に受領検収した取引は翌期に帰属して当然ですが、そうせずに３月期に計上するわけです。
このカットオフ問題をクリアしていることは、どんなデータ分析資料でも完全に立証されていなければならないことは言うまでもないでしょう。
上司や経営者を唸らせる分析データのまとめかた
経営者が見る数字のポイントはどこにあるのでしょう。ここでは、経営者が欲している情報だけでなく、気づいていない情報に関しても解説していきましょう。
データを総合する段階では最初に要求との合致を確認します。つまり、データを選び、分析し、総合した過程で最初の要求から離れていないことを確認するのです。想定通りに仮説を 証明する結果になっていれば完成です。そうでない場合にはミスを疑い、ソースデータやプロセスあるいは資料作成手続を再確認してミスを探します。それでも問題点が発見できなければ、仮説を破棄して仮説設定からの作業を再実施する必要があるかもしれません。なお、 ミスもなく仮説も正しいことが証明されたのなら、未知の事象が隠れている可能性を追及します。経営上の新発見となるかもしれない事象が見つかるかもしれません。
いずれの場合でも、最終成果物は重要な結論がひと目で判るように構成されたものであることが重要です。時間と費用を使って経営者をミスリードすることは絶対に回避するという姿勢が大切なのです。
そのためには「読み込まなければ判らない資料となってしまっていないか？」「誤解を生ずる表現になっていないか？」を自問自答することが必要です。
場合によっては「結論は出ませんでした」「必要なデータが得られませんでした」「分析したがよく判りませんでした」という最終報告を、勇気を出して提出することがあるかもしれません。ですが、不正確な資料や誤った資料、偏った資料を提出するよりはずっとましです。この段階で的確な判断を行うためにも、分析の当初に行う「狙い」の掌握が重要なのです
■この課題を解決するソリューションは ビッグデータを利活用する情報分析の BIツール 『WebReport 2.0 Smart』
必要なときに、必要な人が必要なデータを簡単に取り出してすぐ利用！
いつでも誰でも、わかりやすい形でデータを閲覧・共有することが可能 直感的な操作ができるレポーティングツールで、高機能な見える化システムを実現します。
必要なときに、必要な人が必要なデータを簡単に取り出してすぐ利用！
いつでも誰でも、わかりやすい形でデータを閲覧・共有することが可能 直感的な操作ができるレポーティングツールで、高機能な見える化システムを実現します。
