自社の業績を正確に把握できていますか？｜経営者こそデータリテラシーが必要
突然ですが、経営者の方に質問です。
営業会議に使われている資料がどのように作成されているか説明出来るでしょうか？
多くの会社では、自社の業績を俯瞰してみるための「営業会議資料」を作成されています。
商品・サービスごとの売上・利益のだったり、営業担当者ごとの業績だったり、組織によって様々な切り口があり、意思決定や評価に活用するのが一般的です。
それ自体の必要性・重要性は言うまでもありませんが、それがどのように作成されているか、意識したことはあるでしょうか？
- 担当者が定期的に作ってくれているから細かい話はよく分からない。
- 経営者がそこまで知る必要はない。まとめた結果だけ分かればよい。
といった答えが大半ではないでしょうか。実際に聞いてみた範囲においては、大半がそうでした。
大筋は同意なのですが、しかし、個人的にそのスタンスには一部異論があります。
というのも、経営者自らが資料の裏付けとなるデータの構造を正確に知ることこそ、素早い意思決定や業務改善、情報システム投資判断・評価に繋がりうると思うからです。
確かに経営者が細かな実作業をする必要はありません。
ただ、データがどのように集計・加工され、最終的な意思決定の資料となっていくのかというプロセスは、身体で言えば血液の流れのようなもので、それは組織全体の健康状態を左右する重要なものです。
それを知ることが、経営者にとってどれだけ重要なことか、今回はそこを掘り下げた話題になります。
長いエントリになりますので、忙しい方はまとめだけお読みください。
この記事の目次
担当者のブラックボックスになりがちな資料作成業務
ある例を紹介します。仮にA社とします。
A社ではOA機器の販売会社で、40人の営業社員を抱えており、営業地域ごとに部門を分割しています。営業会議に関しては、月1回の部門ごとの営業会議を行う他、月1回営業部門長以上が集まる幹部会議も開催しています。
資料作成に関しては、各営業担当者がエクセルで入力した「月報」を元に営業部門ごとの事務員が集計し、それを元に管理部門の担当者が営業部門長会議用資料に加工していく流れです。
各営業担当者が作成するエクセルには月ごとのシートがあり、主要項目として顧客名、日付、商品名、売上、粗利が記載されています。
それを営業部門の事務スタッフが毎月部門ごとにエクセルで集計し、「部門別営業月報」として管理部門に送ります。
管理部門では専任スタッフが集まった「部門別営業月報」を顧客マスタ、商品マスタデータなどを追加してAccessに取り込み、さらに加工して幹部会議用の「営業資料」に整えます。
「営業資料」は、営業部門別売上粗利実績、担当者別売上粗利実績、商品・商品カテゴリ別売上粗利実績表というエクセルデータに、それぞれ、前月対比、前年対比情報を付加して出力されます。
ビジュアル化するために、推移グラフなども付加しています。
言葉で書くと簡単ですが、エクセルに文字で書かれた情報の正規化やマスタデータとの突合せ、集計クエリの多段階の実行、グラフの微調整など、作業は細かく、時間を要する業務になっています。
そしてこの作業は、エクセルやアクセスに詳しい業務担当者が現場主導でフローを作成したものであり、データ集計の抽出条件や結合条件は、担当者のみ把握しています。
いわゆるブラックボックスになっていると言えます。
ブラックボックス化した資料作成業務の問題点
この問題点はいくつかあります。
問題点１：属人化
まずは属人化です。
エクセルや、アクセスのクエリを駆使してデータを作成していますが、管理部門担当者が個人的に作った複雑なクエリやマクロが混在しているため、本人しかメンテナンスできません。サブの担当者も手順は分かるけど仕組みは分からないということになり、イレギュラーなデータがあったりした場合には手を出しにくくなります。
問題点２：正確性
次の問題点は正確性です。
エクセルからAccessに取り込む際、手作業でのデータの正規化、マスタデータ追加作業が発生するため、ミスが入り込む余地が出来てしまいます。
もしかしたら、担当者が恣意的に「特定の部門の業績を良く見せる」といったような操作するということもありえなくはありません。A社は上場企業ではありませんが、仮に上場企業であった場合は「内部統制どうなってんだよ」という話にもつながります。
問題点３：費やす時間
次の問題点は時間です。
資料作成は自動化されておらず、手作業が入り込むため、どうしても一定の時間が掛かります。
資料は毎月決まったタイミングで作成しなければなりません。しかし、各営業担当者から出てくる報告データの提出が遅れたりすると、アウトプットも遅れてしまいます。その辺は残業や休出でカバーします。それでもカバーできない場合は遅れます。
一見、「デジタルデータなんだから加工にやたら時間が掛かるのは意味不明」と思えますが、中身的には手作業による正規化やイレギュラーデータの訂正などが介在する、極めて労働集約的な作業内容になっています。
このように蓋を開けてみると、実は極めてアナログなやり方で資料が作成されているのでした。
なお、A社はこのやり方を15年続けており、現在も変えていませんが、担当者の定年も視野に入ってきたことから、改善に着手しようとしているところです。
経営者・幹部こそデータの構造・流れを把握することが必要
経営者がデータリテラシ―を持つことは、現場との意思疎通や、組織としての業務改善の在り方に目を向けることに繋がります。
ブラックボックス化した資料作成業務の例を挙げましたが、データリテラシ―がなければ、そこで何が問題になっているのか、作業のボトルネックになっている要因は何なのかが理解出来ません。
そこには業務改善のヒントがゴロゴロ転がっているのに、経営者や幹部にデータリテラシ―がなければそれを認識することすら出来ません。
話はそれますが、私は自動車にあまり興味がありません。走れば良いと思っている派です。なので道を走っている車を見ても特に何も感じることはありません。ところが、ものすごく自動車が好きで興味のある知人にとっては、道路は情報収集で忙しい場になります。個人個人が持っている知識や価値観によって、同じ日常の風景であっても目に見える世界が全く異なるということです。多分、知人には道路はとてもキラキラした世界に映っているのだと思います。
話を戻しますが、経営者がデータリテラシーをもって現場に接すれば、きっと宝の山に見えるでしょう。業務改善の具体的な道筋がイメージ出来るようになると思います。
「業務改善なら常に指示している」という場合でも、多くのスタッフは「現場の大変さも分からずに口だけだすな」と思っているかもしれません。それでは面従腹背で業務改善など進みません。スタッフのモチベーションの低下にもつながるでしょう。
口を出すなら「何が大変なのか」「何が足りないのか」をきちんと理解することが必要です。そうすればより具体的な指示や改善イメージの提供が出来るでしょう。その共通言語になるものの一つがデータリテラシ―であると言えます。
こういう状態の場合は要注意
何社も見てきた中で、データの管理がうまく出来てない組織には共通点がいくつかありました。以下の設問に当てはまる項目があれば、注意が必要と思われます。
- 営業資料を見るとまあまあの推移のように見えるけど、試算表を見るとどうも数字が追い付いていないように感じる。
- 営業資料の作成に半月以上かけている。
- 集計は担当者にお任せしてるので、経営者はデータ作成プロセスに関しては全くノータッチ。
- 基礎となるデータは、営業担当者に報告させているが、報告内容の裏付けはない。
- パソコンを使ってはいるが、主な用途はメール送受信である。
いくつか当てはまる項目があったでしょうか。
感覚的に、3つ当てはまると改善が必要と思われます。
要は経営者や幹部がどれだけデータを注視しているか、という指標になります。「そういうの得意じゃないし、ていうか苦手だから」と忌避するのは、気持ちとしては分かりますが、マネジメントという立場を考えるとあまり良い状態ではありません。
経営者として最低限備えておくべき知識としては、一般的に、業務に関する知識、業界に関する知識、法律（民法、会社法、労務系…）の知識、会計・税務の知識などが挙げられると思います。
私はそれに加え、データリテラシ―も挙げたいと思います。
「素早い意思決定には、リアルタイムなデータの把握が必要である」という想いからです。
経営者がいわゆるデータサイエンティストのようなスキルを身に着ける必要はありません。しかし、データがどのように加工・集計されて数字が出てくるのかの「仕組み」は把握しておいた方がよいです。
経理のスペシャリストである必要はありませんが、簿記の基礎知識は備えておく、というのと同レベルのお話になります。簿記の基礎知識がなければ、経理担当者と業務上の詳細な話は出来ませんし、税理士が何を言ってるのか分からない、ということになってしまいます。
データリテラシを身につけるには？リレーショナルデータベースの概略
いきなりリレーショナルデータベースという言葉を出してしまいましたが、私の申し上げるデータリテラシーを身に着けるには、リレーショナルデータベースへの理解が必要なため、少し解説いたします。
リレーショナルデータベースとは？
世の中の情報システムの多くは、特に業務系に関しては、RDBMSでデータを管理していることが大半です。
RDBMSとはRelational Database Management System（リレーショナルデータベース管理システム）の略で、単にRDBと言ったりもします。代表的なものにMicrosoft社のSQLServer、Oracle社のOracle、IBM社のDB2、オープンソースソフトウェアのMySQL、PostgreSQLなどがあります。
これらは二次元の表データを相互に関連（リレーション）させながら管理できる仕組みを備えています。
エクセルのワークシートだと行と列だけの二次元的な表現しかできませんが、RDBは特定の行に関連するデータをリンクさせながら多次元的に保持することが出来ます。
例えば、買い物のレシートを見ると、取引情報として取引時間や支払金額が記載されています。これをエクセルで表現するには、取引時間、支払金額という列を作成し、その下の行に時系列に沿ってデータを記入していけば済みます。
ところが、レシートには明細情報（商品名、単価、数量、金額…）も記載されています。お買い上げ商品の明細数はその時々で変わります。
それを前述のエクセルに入れ込むとします。例えば明細用の列を前述のエクセルに追加したりすると、集計がしにくくなりますし、そもそも明細数はその時々で変動するため、どこまでを明細列にすればいいのかも分かりません。程なくして行き詰ります。
そこで、RDBを利用し、取引情報とそれに紐づく明細情報をそれぞれ別のシート（テーブルと言います）で管理します。スッキリ管理できるようになります。
単純ですが、RDBの本質は以上です。テーブルのリレーションの親子関係を理解することが「データの構造を理解すること」に繋がります。
レシートの情報はたった2つのテーブルで表現できましたが、もっと多くのテーブルを利用しなければ表現できないデータもあります。その場合も一つ一つのテーブルの関連性を紐解けば理解できるはずです。
複雑性に高低はあれど、世の中の多くのデータはこの形で管理されています。
一意なデータを知ること
仮に「スタッフ名簿」を作ってみるとしましょう。その場合、とりあえず、苗字、名前の列があれば用が足りると思います。
ところが、同性同名の方がいた場合はどうでしょうか。どちらも山田太郎であれば名簿上は見分けがつきません。そこで、二人を区別するために「年齢」という列も追加します。そうすることで山田太郎（40）なのか、山田太郎（25）なのか見分けられるようになります。
このようにデータを一意に特定できるキーとなる情報のことを主キー（しゅきー、PrimaryKey）と言います。
この場合は「苗字」「名前」「年齢」の3つがあれば、スタッフを一意に特定出来るので、3つセットで主キーとなります（複合主キー）。
しかしそこでさらに40歳の山田太郎が中途入社してきた場合はどうなるでしょうか。苗字、名前、年齢だけでは区別がつかなくなってしまいます。そうなる場合があるので、現実の世界ではスタッフコードのような連番を付与することで重複を排除します。この場合はスタッフコードだけが主キーとなります（単独主キー）。
スタッフコードがあれば、同じ属性を持つ山田太郎が何人入社しようと、一意に特定出来ます。このように、一意に特定できる主キーは何か？を知ることはデータを読み解く上で必要な土台となります。
現実問題、40歳の山田太郎が何人も入社することなどありえないかもしれません。しかし、「あり得ないだろう」で設計されていたのが「消えた年金」のデータです。「あり得ないはあり得ない」というスタンスで考えるくらいが丁度良いのです。
ちなみにマイナンバーは日本国民を一意に特定できるコードです。同性同名だろうが、年齢が一緒だろうがマイナンバーが違えば別人として一意に認識できるようになります。
なお、一意なデータのことを「ユニークなデータ」と表現することもあります。
データの粒度を把握すること
参照しているデータがどのレベルで集約（サマリ）されたものなのか、を把握しておくことも重要です。
例えば経理の話で言えば、仕訳というデータエントリーがあり、元帳というデータベースに蓄積され、勘定科目ごとに集計され、さらにBS/PLの項目に集計されるという流れになります。
それぞれに集計レベルがあり、ここでは、その集計レベルのことを「粒度」と呼びます。データの粒度を正確に知ることで、データが何から構成されているのかが把握できます。詳細が見たければ、一段ブレークダウンすればよいですし、最小レベルまで見たければ元帳まで遡れば良いのです。
営業会議に使われる資料も基本は同じです。
データエントリーがあり、あるレベルで集約・加工され、営業資料に整えられていきます。ただし、最終の結果だけ見ても、内容が分かりません。データの源泉まで遡りたい場合もあるかと思います。ところが、営業資料の場合、データエントリーが仕訳のようにカッチリしたものでなく、正確性に欠いたりする場合もあります。また、入力のフォーマットがバラバラなこともあります。
データリテラシーを身に着けることは、そこでどこが正確でないのか、フォーマットを統一するにはどうしたらよいのかという視点を持つことに繋がります。
RDBは当面なくならない
RDBMSの話ばかりしていますが、ここ数年、ビッグデータだ、NoSQL（RDBMSとは違う形のデータベースシステム）だ、という言葉が飛び交っています。なので、RDBMSはオワコンになるのか？という危惧を持たれる場合もあるかもしれません。しかし、調査会社のガートナージャパンのコメント（2019年2月26日）によれば、多くのRDBMS（リレーショナル・データベース管理システム）は当面現役で生き続けるものとされています。私もそう思います。
2023年を迎えてもなお、日本の大企業における基幹系システムの80%が商用のリレーショナル・データベース管理システム (RDBMS) を使い、オンプレミスで運用し続ける
さらに言えば、多くの中小・中堅企業では、まだビッグデータと呼ばれるような量のデータを持っていないケースが殆どです。
せいぜい数万件～数百万件程度のデータです。安心してRDBMSを使ってよいと思います。また、RDBMSの概略を知っていれば、他の管理方式の理解もしやすくなります。
RDBを理解できるアプリケーション
では、どうすればデータリテラシーが身につくのでしょうか。
これはもう、実際にデータを見ながら手を動かすしかありません。座学のみでは、身につきません。
その手を動かすためのツールとして気軽に導入できるのが、ズバリ、マイクロソフトAccessです。BI（ビジネスインテリジェンス）ツールもあるにはあるのですが、導入の敷居は費用面も考えるとどうしても高くなってしまいます。また、Accessを使いこなすことが出来れば、大抵のBIツールも操作出来るでしょう。
Accessの概要
Accessはパソコン上で動作する簡易的なRDBMSです。
RDBMSは通常、専用のサーバやクラウド環境で提供されるものですが、Accessの場合、データベースはパソコン上のファイルとして提供されます。
Accessが他のRDBMSと違うのは、データベース機能だけでなく、入力用のフォーム作成や、帳票出力にも対応している点で、少人数で利用する小規模な業務システムであれば入出力含め、Accessだけで構築可能です。
なお、Accessを導入するには、パッケージ版のOfficeを購入するか、Office365のBusinessプランで入手することが可能です。
Accessで出来ること１：エクセルデータの取り込み
エクセルのワークシートと、Accessのテーブルは同じマイクロソフトOfficeシリーズなので親和性があります。
エクセルのワークシートをテーブルにコピペして、Accessのデータとして管理することも可能です。もちろん、CSVファイルを取り込むことも可能です。そうすることで、テーブル化されてないデータを、Access上で一元的に管理出来るようになります。
次に述べるクエリを利用すれば、柔軟にデータを抽出・加工出来るでしょう。
Accessで出来ること２：クエリの実行
クエリとは、「問い合わせ」という意味ですが、多くのRDBMSでは、SQL（エスキューエル、Structured Query Language）という「問い合わせ言語」を利用してデータを更新、管理します。
AccessにはSQLをビジュアル的に簡易に作成できるツールが備わっているので、Accessを使えば、クエリで何が出来るのか（抽出、結合、集計…）が身をもって分かります。指定条件のみの抽出、グループ化、四則演算、サブクエリの活用など、様々な用途があります。
データの加工には正規化されたデータが必要であるということも理解できるでしょう。
Accessで出来ること３：生データへの読み取り専用アクセス
Accessを使えば、大抵のRDBMSには「ODBCドライバ」という仕組みを経由してアクセスすることが出来るので、データベースをサーバやクラウド環境で運用している場合でも、業務の生データに触れることも可能です。
販売管理の生データ、在庫管理の生データ、などを集計するクエリをあらかじめ作っておけば、文字通りリアルタイムなデータを参照することが出来ます。
読み取り専用のリンクテーブルにすれば、本番データを壊すこともありません。安全にデータの集計が可能になります。
本番生データにリンクして、必要なデータをAccessでリンクさせ、自在にクエリを操れるようになれば、十分だと思います。
まとめ
経営者や幹部がデータリテラシーを身に付けることには、以下のようなメリットがあります。
- データをリアルタイムに把握することで、意思決定に役立てることが出来る
- 現場とより深い関係で意思疎通が出来るようになる
- 業務改善のヒントを拾えるようになる
ただ、今回書いた内容はほんの触りです。個別に話を聞いてみたいという方はお気軽にご相談下さい。
要望が多ければ集合研修を企画するかもしれません。
ITと経営に関するお悩みはありませんか？
お一人で悩まれずに、些細なことだと思われることであっても、お気軽にご相談ください。
もちろん、お問い合わせメールへは無料で対応いたします。
