「この新規契約社数って間違ってない？」に応える経営企画データエンジニアの普段の仕事
はじめに
社内の全てのデータを扱う資格と責任がある経営企画のデータエンジニア。
これまでの仕事でこんな問いかけに応えてきました。
「この求人の採用数のデータって取れる？」
「部門別で営業のコストって出せる？」
「この新規契約社数って間違ってない？」
「はい、取れます。出せます。合ってます」
と答えて終わり。もちろん、そんははずないです。
ただ答えるではなく、できる限り、応える。
そのデータの利用目的を問い返し、より正確にデータを定義し、各所に散らばるシステムから元の生データを取得し、定義にそって加工し集計し、エクセルとBIツールのダッシュボードに表示し、予実で比べて、原因を推測したり今後を予測する。
集計済みデータを分解して、事業領域別やサービス別に出したり、最も細かい個別の契約企業の数字を一覧で同時に表示したり、元データの取得元や集計時の計算式を明示することで、全体の集計結果と合っていることを確認でき、データに対して信頼を得られる状態にする。
これが経営企画チームの中で応えてきたデータエンジニアの仕事です。
端折ってまとめ過ぎているような気もしますが、間違ってないです。
書いてみると地味な仕事ですが、一つ一つが奥深く、データの背後にあるビジネス理解にも繋がり、とてもやりがいがあります。
僕は元々、大手会社のエンタメ動画配信サービス事業のデータエンジニアチームのマネージャーをしていました。事業部にいるデータエンジニアは顧客ユーザの動向や売上までを基本的に扱います。広告効果測定や自社サイトのユーザ行動を分析しつつ、必要なデータを自動取得し加工する基盤を構築し、可視化分析までのプロセスを安定的に稼働させる仕事です。
事業の施策に直接貢献できるマーケティングデータ分析は楽しいです。
でも、もっと広く社内の活動を見通せる位置、経営に近い高い位置で、社内の全てのデータを扱う分析をしてみたい、その仕組を作ってみたいと思い、現在のアンドパッドという会社に経営企画として入社しました。
経営企画であれば、社内のすべてのデータを取り扱うことに責任がもてる！
ただ、経営企画自体は未経験のため、有識者のお話を聞いてみたいと探していたところ、経営企画コミュニティの存在を知り参加しました。
その流れで、経営企画アドベントカレンダーを書かせていただくことになった今です。
経営企画コミュニティに参加させていただくと、経営企画としてデータエンジニアをしていることは珍しいことを知りました。
ただ、方法や職種は別としても、上記のような問いかけに応えている方々は、経営企画や事業企画に関わらず多いはず。
経営企画の要であるデータ自体に信頼性がないと、最も大事な作業である、社内の合意形成の根幹が揺らぎ、議論どころではありません。
どうやって信頼を得てデータを扱ってもらえるか僕のデータエンジニアとしての仕事です。
この記事では、信頼性のある形で冒頭の問いに応えるデータ抽出のポイントを書いていきます。
経営企画のデータエンジニアとして試行錯誤してきましたが、エンジニアか否かに関係なく意識すべきポイントとして、なるべく専門用語は使わずまとめてみました。
実際はもっと複雑な問いが多いでしょうが、紐解いていけば結局はここにいきつく、というポイントであると思っています。
同じような問いに日々応えている方々の参考になれば幸いです。
データ抽出の確認ポイント
データ分析やデータ抽出と一口にいっても、統計や機械学習やAIまで含めると幅広いです。多くの書籍や記事でデータ抽出のお手本が述べられていますが、今回のような問いに応えるケースの場合、確認ポイントが主に6つあるのでご紹介します。
ポイントまとめ
定める： データ抽出の目的と定義は何か。単純にデータの理解を深めるために探索したのか、特定の施策や説明に使用したいのか確認します。また当初言っていた言葉そのものに現れていない暗黙的な前提条件や粒度が異なる場合が多いので、厳密な定義を確認します。
集める：データを正しく全て集められたか。特定条件で絞り込みされず全件のデータを確かに入手できているか、最新版か確定版か否かを主に確認します。
入れる：データを誰がどの形式と制約条件でシステムに入力したか。主に、人が台帳マスタにカテゴリを選択して入れているのか、システムが自動的に履歴ログとして生成した値なのかを主に、確認します。手入力の場合、人によって偏ってないか、必須入力で運用されているを確認します。
繋げる：複数システムの複数データ間をどの一意キーで繋いだのか。主に台帳マスタと履歴ログに分かれますが、重複なく抜け漏れなく繋げられているかを主に確認します。
約す：正しく計算し集約できているか。計算式自体が定義と合っているか、どういう条件で絞り込まれているか、足し引きできないユニーク数かどうか主に確認します。
比べる：時系列と予実と同粒度カテゴリ間で比べて妥当か。前期の数値、事前に見込んだ数値、カテゴリ別の集計数値で比べて妥当かどうかを主に確認します。
これが全てではもちろんありません。
ただ、最低限このポイントを確認できていると、自信を持って問に応える形でデータを出し、信頼を得ることができます。
ここから、今回の問い「この新規契約社数って間違ってない？」への応え方について、これらのポイントを元に架空のサンプルエピソードを交えて説明します。
1.定める
「データ抽出の目的と定義は何か。」
この問いの目的を確認したところ、
「今月12月の新規契約社数目標である3社を達成したはずなので、もしこの社数が正しいのなら営業計画の変更をする」
とのことでした。
暗黙的な前提条件として、質問者は営業第一部の方でしたので、それで絞ってみても、指摘のあったデータは確かに12月の新規契約社数=2社にでした。何か前提条件が違うのか処理ミスがあるのか確認し、そのデータを元に営業計画の修正が必要かどうか議論します。
間違っても、「2社ですので、まずはそちらの数値を確認してください」とは答えません。笑
データの定義を
「営業第一部の今月の新規契約社数」
目的を
「営業計画の見直しの判断に利用する」
とします。
2.集める
「データを正しく全て集められたか。」
取得したデータは営業管理システムにある売上ログデータと契約社マスタをダウンロードしてました。下記のような表形式のデータです。
利用するのは、売上ログの契約日付、契約社名、契約金額、契約タイプです。営業計画上で必要な分析軸として、経営企画と営業部で議論によく挙がる業種と従業員数規模を利用します。
特に部署や日付で絞り込まれたりせず、データが最新でダウンロードできていることも確認しました。
3.入れる
「データを誰がどの形式と制約条件でシステムに入力したか。」
売上ログはシステムが自動的に作成しており、契約社マスタの手入力のデータと確認できました。
マスタ側で利用する項目は全て必須入力でしたので抜け漏れはありません。業種は選択式でカテゴリですが、従業員数だけヒアリング数値をそのまま手入力しているので信頼性にやや欠ける項目であることを確認します。
売上ログはシステムで自動生成されているため、何度も確認は不要ですが、一度はしっかりと確認をいれることが重要です。
例えば、今回利用する契約タイプが前月11月が継続なのに12月が新規になっていないかなど、そのデータ単体で矛盾点がないか確認します。
特に自動生成と手入力データが入り交じる場合、データ間でお互いに矛盾してないかより注意が必要ですので、次のデータを繋げる段階で確認します。
4.繋げる
「複数システムの複数データ間をどの一意キーで繋いだのか。」
契約マスタの一意キーは契約社名で、重複がないことを確認しました。
自動生成のデータを母体として、契約社名をキーにマスタデータを繋ぎます。繋いだデータの項目名に、データ生成元が分かるようにします。
契約マスタが一意であるため、重複なく繋げられました。
ただ、手入力データである契約社マスタに株式会社Hが抜けていたため、営業部に連絡して入力してもらう必要があります。
また、手入力である契約社マスタの担当営業部と、システム出力である売上ログの営業部が異なっているデータがあります。
マスタ側には項目変更ログと更新日時があるため確認したところ。
売上が計上された後にマスタが更新されていました。
営業部にその事実をもとに確認したとこころ、来年の計画変更による担当変更のためマスタを意図的に更新した点を確認しました。実績ログを正として進めて問題さそうです。
5.約す
「定義通り計算し集約できているか。」
新規契約の計算式を確認したところ、
「売上_契約タイプが新規、かつ、
売上_契約金額が1円以上の有償契約がある、
売上_契約月×売上_営業部毎のユニーク契約社数」
でした。売上×契約社ログの売上金額を確認したところ、12月の営業第一部によるE社の契約が0円でしたので、今回の新規契約社数にはE社は含まれません。
年末の営業部の値引キャンペーンにより初月は無償提供と判断した記録がが営業管理システムにありました。
今回はこれが問題の原因のようです。
無償を含んだ新規契約社数を追加で出力します。
6.比べる
「時系列と予実と同粒度カテゴリ間で比べて妥当か。」
新規契約社数と無償含んだ新規契約社数を出しました。
またさらに従業員数レンジ(1000人単位)の項目で分けた数字も出しました。
11月と比較しても異常なほど増減はしていません。
営業第一部の12月の新規契約社数の予算が3でしたので、無償契約を含めば達成でした。
従業員レンジ別で比較しても、その無償契約の1社が大企業だということがわかり納得できます。業種は今回バラバラでしたので意味無しと判断し削除しました。
まとめ
確認内容をまとめると、
目的である「営業計画の見直しの判断に利用する」に対して、「営業第一部の今月の新規契約社数」を確認したところ、元々の予算である3社を、無償契約を含むと達成していたが、有償契約のみだと未達成。
ただし、大企業の顧客獲得のための値引キャンペーンを実施した背景があるので、この情報を踏まえて計画の見直しについて議論ができます。
一方で、従業員数は手入力データなので、その信ぴょう性にやや欠ける。
また、これまでのポイント確認により、
営業第二部の契約状況と比較できる形式にしたり、当初利用を想定していた業種データは現時点ではバラバラのため利用できない点、契約社マスタの担当部署の変更した事実、マスタの入力漏れといった事実の洗い出しができました。
これらの確認事項そのものが、データを精査し正確性を担保した証明にもなりますので、抽出した数字自体の信頼性が高まります。
ダッシュボード上で、上記のそれぞれの条件での契約社一覧も合わせて確認できるようにしておけば、利用者自身でも検証できるため、その後の活用も容易です。
補足:分析のための追加要素
問いに対して応えるデータ抽出だけではなく、主体的により大きな価値を発揮したデータ分析を行っていく場合、より大量なデータを捌き、統計処理や機械学習も用いた検知や予測という要素が必要になっていきます。
大量データの前処理とテスト: 大量の生データを人が分かりやすい形式に変換しつつ、同時に欠損値の処理、異常値の検出のテストとアラートの自動化を行うことで、データ確認の効率化と信頼性が向上します。
統計的手法の適用: 平均、中央値、標準偏差などの基本的な統計指標を計算します。さらに、相関分析や因果関係の探求なども行います。これにより、データ内のパターンや関連性を明確にします。
機械学習アルゴリズムの活用: 回帰分析、分類、クラスタリングなどの機械学習技術を利用して、データからさらなる洞察を抽出します。特に予測モデリングでは、将来のトレンドや振る舞いを予測するのに有用です。
最適な可視化とレポーティング: 分析結果をビジュアル化することで、より深い理解を促します。チャート、グラフ、ヒートマップなどを使用して、洞察を視覚的に表現します。分析結果を解釈し、その意味やビジネスへの影響を説明します。
この中で、特に1つめの異常データ検証テストは今回の信頼性向上のためには重要で、ポイント4で繋げたデータの項目間で矛盾してないか、そもそもデータが一意か、意図しないのカテゴリや数値が入ってないかを、全て自動でチェックする方法が最近のデータエンジニアリングではあります。
今回のように手作業でよく問題となるケースを発見したら、それをテストに組み込むことで、同じ問題は今後起きないようにすることができます。
また、単にデータを集めて比べるだけではなく、より高度な統計的手法と機械学習技術を駆使すれば、データと背後のビジネス自体の理解が深まるため、より精緻にデータ抽出ができますし、もちろん本来の経営企画の役割として会社全体に価値をもたらす洞察を得ることもできるようになります。
僕自身もこの分野はまだ現在勉強中の身ですが、経営企画で扱うデータがあればより大きな価値を生み出せるワクワク感と共に楽しんでいます。
さいごに
今回は簡単なデータ抽出要件とその確認でしたが、すべてのデータ抽出や分析要件に対して、多量かつ多種類なデータ全て人の手とエクセルだけで行うのは大変です。
最近ではModern Data Stackという形で、SaaSやOSSを組み合わせてデータ取得から分析可視化までを実現する流れがありますので、データエンジニアリングにご興味ある方は、ぜひ調べてみてください。
僕個人へのご相談も遠慮なくどうぞ！
ただ、高度なツールの導入やとデータ基盤を構築より前に、そもそものデータの信頼性を担保すること、会社で生み出されるデータそのものに向き合い肌感をもって理解することは、経営企画において何よりも重要です。
データの正確性、完全性、一貫性を確保することで、皆と同じ土俵で議論ができ、信頼に基づいた意思決定を支援し、経営企画として会社全体の効率と成果を向上させることができます。そのことを理解し、手を動かして実感した上で、ツール導入を検討しましょう！
この記事で、その重要性や注意点が少しでも伝わったなら嬉しいです。
また、経営企画アドベントカレンダーは、そのデータを扱うプロフェッショナル達の記事が盛りだくさんですので、ぜひ注目してください！
最後まで読んでいただき、ありがとうございました。
この記事が気に入ったらサポートをしてみませんか？