「このデータ出して」が何度も戻ってくる?営業・企画と情シスで決める依頼票

営業やマーケ、経営企画から、情シスに「このデータ出して」が届きます。頼む側にとっては、チャット1行のお願いです。受けた側は、どの表に入っているかを探し、項目の意味を確かめ、Excelに整えて渡します。そして数日後、期間を延ばしてほしい、もう少し細かく分けてほしい、と戻ってきます。

販売管理や基幹システムを入れた情シスは、データのありかを知っている人として、こうした依頼を受けることがよくあります。この記事では、データの依頼で起きるすれ違いを、公開されている体験談や発表から整理し、営業・マーケ・経営企画と一緒に使える依頼票と、受けるときの聞き方をまとめました。

「このデータ出して」、どこですれ違う?

公開されている体験談と発表を読んで整理すると(公開されている体験談と発表8件、編集部)、すれ違いは次の4つの場面に集まります。

• 頼む側にはひとこと、出す側には数時間から数日
• データの意味を、社内の誰も言い切れない
• 手間が見えないので、すぐ出せると思われる
• 渡したあとに、条件の追加が続く

頼む側は、仕事を進めるために数字がほしいだけです。出す側も、できれば早く渡したいと思っています。それでもすれ違うのは、頼む前と受けたときに確かめることが、決まっていないからです。

あるある1: 「SQLが書ければ、すぐ出せるでしょ」

ただ、SQLが書ける＝データ抽出ができる、と思っている人がとても多い。 (中略) 出てくるのは、ローデータが出力されているExcelファイルのみです。

筆者は、SQLは文法なので覚えれば書ける、大変なのはその前の「データの理解」だと書いています。何十、何百もの表があり、1つの表にいくつもの事実が入っていて、今も使われているのかも分からない。そうした中から正しい数字を探す作業は、最後に渡すExcelからは見えません。

引越しの見積もりで「荷物はちょっとです」と言われて行ってみたら、押し入れの奥から段ボールが次々に出てくる。データの依頼も、開けてみるまで量が分かりません。

こうするとうまくいく: データを渡すときに、「どこから取ったか」「何を確かめたか」「どこに注意してほしいか」を3行だけ添えます。筆者も、偉そうにせず、自分がどんな環境でどんな知識を使っているかを伝えることを勧めています。手間が見えると、次の頼み方が少しずつ変わります。

あるある2: データの意味が「そうっぽいね」で決まる

事業会社の情報システム部で働く方の体験談です。検査のデータを、システムから出したCSVからExcelへ手で写している作業を自動にしたい、という依頼を受け、データベースを調べました。

DBのテーブル設計書も、システムの仕様書もない！！！ DBのテーブルから、それっぽいデータを持ってきて、これですかね？と聞いても データに詳しい人がおらず、そうっぽいねという返答しか出てこない…！

システムの管理番号には、文字や数字、日付らしきものまで入っていたそうです。部署や担当者によって、入力のしかたがばらばらだったのが原因でした。筆者は最終的にそれらしいデータを取り出し、100%の保証はできないことを伝えたうえで、グラフにしました。さらにBIツールで試作を見せたところ、結果は「惨敗」。使い慣れたExcelがよい、という答えだったそうです。

情シスは、データの置き場所は分かっても、その数字が業務で何を意味するかまでは分かりません。業務の意味を知っているのは、依頼した部署です。

こうするとうまくいく: よく使う項目だけでも、「この列は何の数字か」を1枚の表にまとめ、依頼した部署に確かめてもらいます。意味を決めるのは業務を知っている側、置き場所を書くのは情シス、と分けます。渡すときは、保証できる範囲を最初に書きます。

あるある3: 「ちょっと聞きたいんだけど」の「ちょっと」

依頼者にとってはひとことで済むことでも、裏側では数時間から数日の作業が動いていることがある。 「ちょっと聞きたいんだけど」の「ちょっと」が、実際には複雑な条件分岐を書く必要があるかもしれない。

同じ記事は、自分の依頼が「無料」に見えるのは、コストが見えていないだけだ、と続けます。少人数の情シスでは、この見えにくさがさらに強くなります。

通常のシステム会社と違い、工数の概念が希薄なため「情シスが頑張れば開発費用はかからない」という無意識の上で依頼されます。 当然残業祭りになります。

「当然」と書けてしまうところに、少人数の情シスの日常がにじみます。頼む側に悪気はありません。社内の人に頼む仕事には、見積書が付いてこないだけです。

こうするとうまくいく: 受けるときに、先に「いつまでに、何に使うか」を聞き、「どこまでなら、いつ出せるか」を返します。データ整備の勉強会で発表された資料では、「なるはや」と言われたら、そのままにせず、いつどんな時に使いたいのかをざっくりでも聞く、と勧めています。後回しにしたら必要な時が過ぎていた、を防ぐためです。

あるある4: 「3年分で」「もっと細かく」「あと、これも」

BIの仕事をしてきた方は、よくある困った依頼として、データを渡すと、期間を1年ではなく3年分に、さらに細かい区切りでも、別のデータも、と追加が続いてきりがない、という形を挙げています。同じ記事には、データを自分で見られる仕組みを作ったあとの話も出てきます。

名前の似ている、copy, v2, v3, new, finalといった名前の亜流ダッシュボードが大量に出来上がりました。 (中略) 結果的にTableauは全部廃止されました。亜流ダッシュボードとともに。

きっかけは、部署の偉い人が、これだけお金を使って自分たちの意思決定の役に立っているのか、と聞いたことでした。まともに答えられる人は、分析する側にもビジネスの側にもいなかったそうです。筆者は、背景にあるのは、なんとなくみんな不安だから、関係のありそうなデータを手当たり次第集めていることだ、と見ています。

依頼を出す側の心がけを書いた別の記事でも、データを頼む前に「そのデータを見て自分は何をするのか」を考えることが勧められています。それが決まっていないと、どの期間で、どの区切りで出すべきかも決まらないからです。

こうするとうまくいく: 依頼票の最初の欄を「このデータを見て、何を決めるか」にします。決めることが1つ書ければ、期間と区切りは自然に絞れます。書けないときは、出す前に15分だけ話を聞きます。

依頼の対応時間を減らした例

Sansan株式会社の発表では、ある事業部からのデータの依頼への対応時間が、1件あたり約6.8日(2024年11月時点)から1.2日(2025年2月時点)に減ったと紹介されています。依頼が大きく増え、1件を片づける速さが落ちていたことが出発点でした。理由として、ばらばらだったデータを全社で使う基盤にまとめたこと、「秘伝のタレ的クエリ」をなくしたこと、データの持ち方を整理したことを挙げています。

データの専任チームがある会社の例ですが、考え方は少人数の情シスでも使えます。毎回、一から表を探して手で整える依頼が多いほど、時間がかかります。毎月決まって見る数字は形を決めて自動で出し、その都度の依頼は、決めることが違う分だけにします。ただし、見られる仕組みを作るときは、あるある4のように、コピーが増えていかないよう、誰がどの会議で見るのかを先に決めておきます。

分担の表(編集部の整理)

依頼票の型

【データの依頼票】
このデータを見て決めること:
使う日(会議・提出の日):
見たい数字(売上・件数など):
期間と区切り(月別・得意先別など):
外すもの(返品・社内の取引など):
個人の情報が入るか/見てよい人:
1回だけか、毎月か:

CSVで渡したときに、先頭の0が消えたり日付に化けたりする問題は、CSVをExcelで開くと0が消える・日付に化けるにまとめています。

言い方の例です。

今日からできること

1. この1か月に受けたデータの依頼を書き出し、かかった時間をざっくり並べる
2. 依頼票の型を営業・マーケ・経営企画に渡し、「何を決めるか」と「使う日」だけは必ず書いてもらう
3. 毎月くる依頼を3つ選び、形を決めて自動で出せないか調べる
4. よく使う項目の意味を1枚の表にまとめ、依頼した部署に確かめてもらう
5. データを渡すときは、「取った場所・確かめたこと・注意」を3行添える

データを出す仕事は、売上の表にも、新しい画面にも、名前が残りにくい仕事です。それでも、会議で何かが決まるとき、その数字の裏には誰かの半日があります。依頼票の1行目がそろうだけで、その半日はずっと報われやすくなります。

(この記事は、公開されている体験談と発表8件をもとに、編集部が整理しました。)