数字を見える状態にする。データ集計と分析をAIで日常業務化する

「数字を見て判断する組織にしたい」という話はどこでも出ますが、たいていの場合、定着しないまま終わります。

原因を追っていくと、意識の問題ではなく、数字を見られる状態にするまでの作業が重いのだと分かります。
複数の場所からデータを集めて、形をそろえて、集計して、資料にする。
ここに数時間かかるので、月1回になり、忙しい月は飛びます。

今回は、データ分析の前段にある集計をボトルネックから外して、業務として回す話を整理していきます。
データの置き場所そのものの設計はスプレッドシートを社内DBとして扱う。AI自動化の土台設計にまとめてあります。

数字を見る習慣は、たいてい同じ理由で定着しない

分解すると、理由は3つあります。
集計に時間がかかる点、見る指標が多すぎる点、見た後の行動が決まっていない点です。

集計に時間がかかるのは、データが複数の場所にあって形が揃っていないためで、これが最大の要因になります。
また、見る指標が多すぎるのも理由の一つで、20項目のレポートは作るのも読むのも重くなり、どれを見て判断するかが決まりません。
加えて、見た後の行動が決まっていない点も見過ごせず、数字を見て「そうか」で終わってしまうと、次に何をするかが紐づいていない指標は見る意味がなくなります。

集計の時間はAIと自動化で解決しますが、指標の数と行動の紐づけは設計の問題なので、AIでは解決しません。
集計を解いたあとに、この2つが残るという順序を理解しておくのが重要です。

手間の重い工程から先に外していく順序を業務全体で組み立てるときは、業務のAI化の進め方。棚卸しから優先順位付け・実装までの手順を押さえておくと迷いにくくなります。

任せる範囲は、判断か作業かで分ける

工程を分けたうえで、任せる範囲を決めていきます。
どこまでをAIに渡してよいのでしょうか？

まず、データを集める工程は自動化のフローかスクリプトで組み、AIの判断を入れないのは、決まった場所から決まった形で取ってくるだけの処理だからです。

何で組むかの判断軸はAIによる業務自動化の全体像。手段の選び方とコスト設計にまとめてあります。

次に、形をそろえる工程は、表記の統一や項目名の対応付け、日付の形式の統一といった、手作業で最も時間がかかっていた部分にあたるので、AIが効きます。
集計は数式で計算し、AIに集計させないのが原則で、ここを混ぜた時点で数字の事故が起きます。

傾向を読む工程が、最も効く領域になります。
「前月と比べて大きく動いた項目」「他と傾向が違う部門」「異常に見える数値」を挙げさせると、人が見落とす箇所を拾ってくれます。

示唆を出す工程では、「この変化の考えられる要因」を挙げさせます。
ただ、確定した原因ではなく仮説として扱っておかないと、判断を誤ります。

報告文にまとめる工程は、決まった様式に流し込むだけなので、ここも任せられます。

週次で見る3つを決め、行動を紐づける

指標が多すぎる件への対処です。
週次で見るのは3つまでにします。
これ以上あると、見る作業のほうが重くなって飛ぶからです。
選ぶ基準は「動いたら手を打てるか」で、動いても打つ手がない指標は見る意味がありません。

例えば営業なら、商談数・提案数・受注率の3つで、動いたら「訪問を増やす」「提案の質を見る」という手が打てます。
一方で売上の累計は、動いても打つ手が直接には出てこないので、月次で見る指標になります。

週次の3つは部門ごとに決めます。
全社共通の指標を週次で見せても部門は動けないので、自部門で手を打てる指標であるのが条件です。

そのうえで、見た後の行動を紐づけます。
ここが最も飛ばされるところで、指標ごとに「こうなったらこうする」を1行書いておきます。
「商談数が前週比で2割減ったら、訪問計画を見直す」「受注率が下がったら、失注の理由を5件確認する」といった形です。

この1行があるとレポートを見る意味が生まれますが、ないと数字を眺めるだけの会議になってしまいます。
この1行は、数字を見始める前に決めておきます。
数字を見た後に決めようとすると、数字に合わせて基準のほうが動いてしまうからです。

レポートの型を固定し、示唆は仮説として扱う

作る側の設計もしておきます。
まず、レポートの様式を固定しておきます。

毎回違う形で作ると読む側が毎回理解を求められますし、前回との比較もできなくなります。
入れる項目は5つです。
週次の3指標、前週との差、特に動いた項目とその要因の仮説、今週の打ち手、確認が必要な点です。

作る手順のほうも文書にし、どこからデータを取り、どう処理し、どの様式に入れるかを明確にしておきます。
ここが文書になっていないと、作っている人が休むと止まります。

手順を残す様式は担当が変わってもAI業務が止まらない。引き継ぎパッケージの設計で扱っています。

最後に、作る時間の目標も決めておきます。
「30分で作れる状態」を目標にすると、超えたときに工程のどこかが手作業のまま残っていると分かります。

分析の工程では、もう1つ注意が必要な点があり、AIが出す要因の説明はデータから読み取った相関の記述であって因果ではありません。
「広告費を増やしたので問い合わせが増えた」という説明が返ってきても、他の要因の可能性があります。

だから報告書では「仮説」と明示して、仮説を検証する方法を1行添えます。
「この仮説を確認するには、流入元別の内訳を見る」といった形です。
ここを確定した原因として報告すると、誤った打ち手につながり、数か月後に効果が出ていないと分かる結果になります。

もちろん、AIが出す仮説がそのまま正しいとは限りません。
人が思いつかない切り口が出る場合があるので、それを検証すればよいのです。
出させて、検証する。
この2工程にするのが正しい使い方です。

数字が意思決定を変えた例と、よくある失敗5つ

ある会社で、問い合わせの記録を集計できるようにしたときの話です。

着手前は問い合わせ自体は記録されていたものの、内容の分類がされていませんでした。
「最近こういう問い合わせが多い気がする」という感覚で議論していた状態です。
やったのは、記録の本文からカテゴリを分類する列を作り、週次でカテゴリ別の件数を出す形にした点です。

表の中で分類を作る方法はスプレッドシートのAI関数で終わる業務・終わらない業務で扱っています。

分かったのは、感覚で「多い」と思われていたカテゴリが実は全体の1割にすぎなかった点です。
誰も注目していなかったカテゴリのほうが、3割を占めていました。
つまり、印象に残る問い合わせと、件数が多い問い合わせは別だったのです。

結果として、件数が多いカテゴリについて案内の文書を作り、問い合わせ自体が減り、対応の時間も短縮されました。
この話で示唆的なのは、集計ができるようになった結果、議論の前提が変わった点です。
「感覚」から「件数」に変わると、打ち手の優先順位のほうも変わります。

よくある失敗は5つです。
集計をAIに任せる、指標を10個以上並べる、「こうなったらこうする」を決めない、要因の説明を確定した原因として報告する、様式を毎回変える。
どれも、集計は数式で行い、週次は3つまでにして、1行を先に書き、仮説として扱い、様式を固定すれば避けられます。

AI活用そのものの数字も、同じ構造で見える化する

ここまで書いてきたのは業務の数字の話ですが、AI活用そのものの数字にも同じ構造があります。

推進担当が報告に困るのは、集計が手作業だからです。
誰がどのツールをどれだけ使っているか、部門別の利用率、削減時間の積算を毎月手で集めていると、忙しい月から報告が止まり、報告が止まると経営の判断材料のほうが消えます。

見るべき指標も同じ構造で、「動いたら手を打てるか」で選びます。
部門別の利用率が下がったらその部門に手を打ち、作成者の人数が伸びていなければ内製化の支援を強める、といった形です。

AI活用の数字については、私たちの組織のAIポータル「AI Portalize」で、部署・職種・グレードごとの利用率と前期比が集計の手間なしで出ます。
業務の数字は見えるようになったが、AI活用の数字が手作業のまま、という状態なら、考え方の参考になるかもしれません。

数字を眺めるだけの会議には、しない

数字を見る習慣が定着しないのは、集計に時間がかかる、指標が多すぎる、見た後の行動が決まっていない、の3つが原因で、AIで解けるのは集計だけ、あとの2つは設計の問題です。

工程の任せ方は、データを集めるのは自動化、形をそろえるのはAI、集計は数式、傾向を読むのはAI、示唆は仮説として出させる、報告文はAI、の並びです。
指標は週次で3つまでで、選ぶ基準は「動いたら手を打てるか」であり、指標ごとに「こうなったらこうする」を1行書いておきます。
この1行がないと、数字を眺めるだけの会議になります。

レポートは様式を固定して5項目に絞り、作る手順を文書にして、30分で作れる状態を目標にします。
要因の説明は仮説として扱い、検証の方法を1行添えておきます。
出させる行為自体に価値があるので、出させて検証する、という2工程にしておきます。

自部門で週次に見る3つの指標は、もう決まっているでしょうか？
それぞれに「こうなったらこうする」を書いておけば、判断に迷う場面は減っていきます。