データ分析とインテリジェンス

[データ整備/抽出] 打ち合わせの進め方と取るべき合意

抽出をうまくやる鍵はコミュニケーションにあり

依頼を受けてから(多くの場合SQLを使って)データの抽出を始めるまでには必ず依頼者とのコミュニケーションが発生する。抽出の役割ががうまくできるかはそのコミュニケーションに大きく左右されると実感している。

データ活用におけるコミュニケーションについてはいろいろな面がある。今回はデータ整備の中でも抽出の役割を担う際に行うコミュニケーションのうち、依頼を受けてから起きる「打ち合わせ」だけに話を絞る。それでも以下のように検討することは結構ある。

ヒアリングではなく打ち合わせをすると考える

依頼があったらまず「ヒアリング」だと考える人も多いだろう。間違いではないが、「ヒアリング」だと依頼者から要望を聞くことに意識が向いてしまう。

抽出依頼に本当に必要なのはヒアリングだけでなく双方での「打ち合わせ」だ。ここに気づいてから言葉を変えるだけでも認識が変わった(気がする)ので、以後打ち合わせと呼ぶことにする。

打ち合わせの目的は本当に必要なデータを探し出すこと

「打ち合わせ」は何を目的に行うのか。依頼者はデータそのものが欲しいわけではなく、知りたいことがあってそのためにデータが欲しいと思っている。依頼として抽出担当者に提示されるのは最後の「こういったデータが欲しい」という部分だけだ。

しかし、提示された内容は依頼者が本当に知りたいことのために必要なデータになっているとは限らない。むしろなっていないことの方が多い。そのギャップを埋めるのはデータの扱いに長けている抽出担当者の役割である。

つまり「打ち合わせする」とは「依頼者が知りたいことのために本当に必要なデータを探し出すこと」であると言えよう。

打ち合わせの進め方

まずは一通り依頼者の希望を聞く。徹頭徹尾無視する必要はないが、参考程度でいい。話を聞いたら、改めて打ち合わせを始める。言われたことをそのまま鵜呑みにして作業をすると関係者全員もれなく不幸になる。

なぜならば、データの扱いを得意としていない人からの依頼の内容は、その人の知るべきことを満たさないことがある。例えば以下のようなことが頻繁におきる。

  • 依頼してきたデータでは知りたいことにたどり着かない
  • 内容に不足が多く何度も追加の依頼が出る
  • その時には不要な内容が多く含まれている
  • 依頼者の限られた知識の中での選択肢しか考えられていない

「打ち合わせする」とは「依頼者が知りたいことのために本当に必要なデータを探し出すこと」と書いた。実現するためにはまずゴールとなる「何を知りたいのか」を聞かなければならない。続いて知りたいことのために必要なデータを依頼者と一緒に検討していく。

打ち合わせで取るべき合意は「抽出する内容」「アウトプットの形式」「納期」の3つ

打ち合わせで具体的に決めることは何か。それは以下の3つになる。すべての合意が取れたら再度整理してお互いの認識が合っていることを確認した上で進める。

  • 抽出する内容
  • アウトプットの形式
  • 納期

どれが抜け落ちても手戻りや最悪の場合は作業が無駄になってゼロからのやり直しに繋がる。

打ち合わせで取るべき合意1:抽出する内容

「今あるデータで何が抽出できるか」は考えない

まずは「知りたいこと」を達成するために「何を抽出するか」の内容を決める。内容には「定義」と「条件(対象、期間、除外)」が必要だ。

この時に重要なのは「どんなデータがあれば依頼者の希望を叶えることができるか」を考えることだ。とにかく最初は理想的な状態は何かを問うこと。今あるデータで何が抽出できるかだけを先に考えてしまうと、実は入手できた重要なデータが視野に入らなくなってしまう。

理想のデータが見えたらそのうち実現できることは何かと、できるならどれぐらいの期間とコストで実現できるかを検討する。ひとまとめにせずこのデータなら全部だとこれだけかかるけれどもここまでなら早い、と段階を分けるのがいい。

定義は詳細まで決める

データの定義をあいまいにするとあとで混乱する。従って詳細まできちんと決める必要がある。ただし実際に抽出するのに使うテーブル名、カラム名、条件のクエリまで理解してもらうことは難しいし必要ない。

例えば、集計の対象が「6月に入会した会員」ならば「何をもって入会とするか」に双方で誤解の余地が無いのであれば依頼者と合意するのはここまででいい。入会が申し込み時点なのか、無料期間が終わって有料期間になった時点なのかで解釈が分かれる余地があるならば必ず確認が必要になる。

選択肢を提示する

データの種類にどのような選択肢があるのか依頼者が気づいていない場合は抽出側から提示する。それぞれの場合での定義・条件の違いに加えて、インプットやロジックの作り方が変わることでかかるコストや時間の違い同時に伝える。

依頼に細かい条件の指定がたくさんあるとインプットが大量になり、さらにロジックが複雑になる。この時、一部のデータを使わないようにしたり、正確性を少し犠牲にすることで格段に抽出の難易度が下がる場合がある。

20%時間で80%の結果が得られるならば、残りの80%の時間を別の依頼や整備の他の仕事に使った方が全体では良い結果を得られるはずだ。依頼者も少しでも早くデータを提供されることで損することはない。

例えば以下のようなやり取りをして、どうするかを依頼者に決めてもらう。

  • ある指標を作るのに、大きなテーブルをいくつか使う
  • それぞれのテーブルから複雑な条件を指定してIDを取得するがそれがすごく大変
  • 1つのテーブルだけで取るようにすると値が3%ほど小さくなるが、処理がとても簡単になる
  • それでも全部のテーブルを使うなら来週になりそう。でも、簡単にすれば明日に出せる

どうするかを決めるのは依頼者

抽出が楽になるから正確でないけれども簡単にしたくなることや、データを出しても意味が無さそうだからと項目を絞りたくなることはあるだろう。しかし、抽出担当者が勝手に選択肢を絞ってしまうことは絶対に許されない。

抽出担当者が行うべきは選択肢と各選択肢における影響の提示である。そこに個人的にどう思うかを加えるのはよいだろう。しかし、依頼者が知らないからと選択肢を絞って都合よく誘導するのは責任の放棄でしかない。

打ち合わせで取るべき合意2:アウトプットの形式

スプレッドシート、CSVファイル、ダッシュボードのいずれかになることが多い。データは次に使う人のことを考えて相手の好みに合わせたアウトプットを作る。

その際にはわかりやすさにも気を付けよう。データに慣れていない人にはカラム名を日本語にする、nullではなく0や別の言葉に置き換えるなどの対応も考える。

データを渡してから数日たって「このカラムは何」「nullはどういう意味」と聞かれることがある。自分でも忘れていて調べなおししなければならないかもしれない。無駄な時間なので問合せが発生しないように最初はできるだけ丁寧にしておき相手が慣れてきたらそのまま渡すようにするのがいい。

また依頼者のその次の作業も聞いておく。別のツールに投入するのにヘッダー無しや列の順番が決まっているなど特定の形式でなければ使えないかもしれない。であれば最初からその形式でアウトプットするのが良い。出し直しで戻ってきても、依頼者が自分で加工するのも余計な時間がかかる。

打ち合わせで取るべき合意3:納期

納期には余裕を持たせよう

「いつまでに」できるかを検討して提示する。その際には以下を加味する。

  • その依頼の複雑度や難易度
  • 担当者の熟練度
  • インプットに使うデータの入手と加工にかかる時間
  • 他の依頼の状況

よほど簡単な依頼でない限り最初から最後まで予定通りにいくことはない。それと、急ぎの差し込み依頼はいつでもありえる。なので日程には少しの余裕を持たせておくことも大切だ。

一度の打ち合わせではでうまく納期が決められない時もある。データがあるかわからない、外部からの入手が間に合わないかもしれない、ロジックが複雑で出来ないかもしれないなどの懸念があれば「調べてからから改めて返信する」と一旦保留にしてもらう。

急ぎの依頼への対応

ルールを逸脱した急ぎの依頼の場合、内容を確認した上で対応できる自信が無ければ確約はしない。そのかわりに「その内容であればいつなら対応可能」または「希望する納期までにそのうちのどれならできるか」を提示する。

もし依頼が詰まっているなら先に入っていた他の依頼よりも前に対応することになる。急ぎの依頼を優先することで他の依頼に影響が出るならば、影響される側の依頼者に納期を遅らせられないかを打診する。調整がつかない場合はエスカレーションして判断を仰ぐ。それも無理ならば先に入った依頼を優先すべきだ。

わからないことやできないことをできると言わない

依頼を受けた際に「わからない、できない」と言うことを極端に恐れる人がいる。そのような人は何か言われると「はい、わかりました」と言う。

もし納期当日の夕方になって様子を聞かれて「全然できてません」などと答えたらその時点で全ての信用を失う。これは一番まずい。その後相手にされなくなっても自業自得だ。

できるかどうかわからないならば打ち合わせの時点ではっきりさせる。その上で「この部分がこの期間でできるかやってみないとわからないので後日様子を知らせる」でもいい。

抽出は打ち合わせで5割、準備で8割決まる

抽出の仕事はコードを書くことも大事だ。しかしコードが書けるだけでは抽出の役割はうまくこなせない。どちらか、ではなくどちらも必要だ。

そして抽出がうまくいくかどうかは打ち合わせで全体の半分ぐらいが決まり、コードを書く前に8割ぐらいは決まっている、というのが実感だ。

もし「コードは書けるけれども依頼がうまくさばけない」と思うのであれば、コードを書くまでにやるべきこと、特に打ち合わせがうまくできているかを見直してみることをお勧めする。

コミュニケーションの話はまだまだ尽きない

コミュニケーションが苦手で好きでもないのにやるはめになりこれまで大分痛い目にあってきた中で身に着けた方法を書いてみた。これが一番いいかどうかはわからない。なのでこっそりどこか書き換えるかもしれない。あと書いておきながらなんだが、いまでもよく失敗したり忙しいとつい忘れたりすることもある。

それから冒頭に「抽出を担当する側が取るべきコミュニケーションのうち「打ち合わせ」に話を絞っている」と書いた。抽出のためのコミュニケーションはこれだけではなく他にも「依頼を管理するための」「データを入手するための」「抽出の途中や完了時の」コミュニケーションがある。これはそのうちまとめる。

その前に、実は今回の話はまだ続きがある。いくつかのより悩ましい問題についても書いていたのだが、長くなりすぎたので今回は基本的なところで話を終わりにする。

整備の仕事は段取りとコミュニケーションだとどこかで言ったが、改めて整理してみると結構いろいろなことをしているものだ。誰か代わりにやって欲しい。

関連記事:打ち合わせについて

カテゴリー:データ整備