データ活用の関係者に課題感のヒアリングをする時の型を紹介する

背景: データマネジメントのアセスメントのために各部署に現場の課題感をヒアリングしたい

データガバナンスを強化したいときにアセスメント(データマネジメント成熟度アセスメント)をやる人は多いと思う。データ基盤やデータに強い人だけでアセスメントをやって「えいや!!」と優先度を決めるのも一つの手ではある。

しかし、データを通じてユーザーに価値を届けるということまで考えると、データ活用に関わる幅広い職種の現場へヒアリングに行くことが、データガバナンスの確度や解像度を上げるためにも重要だと思っている。よいヒアリングができると、データガバナンスにとって重要な情報が得られ、手戻りも少なくコストパフォーマンスもよい施策が打てる可能性が高まる。そういった背景もあり、私はヒアリングに前々職や前職でも取り組み、現職でもやろうとしている。データ活用の関係者からうまくヒアリングができる、というのはデータマネジメントをやる人やアナリティクスエンジニアにとって割と大事なソフトスキルだと思う。

課題: よいヒアリングをするのは簡単ではない

ヒアリング、やってみると大分難しい。慣れずに何となくヒアリングに行くと

  • 「何で困ってますか?」とストレートに聞いてしまって「特に困ってないです」と返事がきたときにはそこでお葬式ムードになってしまう
  • yes / noで答えられる質問をやたらと用意して、特に深掘りの質問がうまくできずに予定時間より大分早くヒアリングが終わってしまう
  • ヒアリングの場なのに私が「こうすると解決するかなと私は思ってるんですけど、どうですかね」と解法をなぜか議論し始めてしまう
    • 押し付け商法かよ...😇
  • 時間をもらって色々ヒアリングをさせてもらった割には、元々聞きたかったデータガバナンスに対するインプットにはなっていないことが多い
    • ヒアリング中は一杯一杯になっていることが多いので、そうなっていることに自分では気付けない

などなどの課題感を自分は持っていて、仕事上必要な割にかなり苦手だった。前職はグループ3名の構成だったので、自分がうまく質問できていない / よくない方向に進み始めたとしても、グループメンバーがよい深掘り質問をしてくれたり軌道修正をしてくれることが多かった。しかし、現職では自分一人でヒアリングすることも多く、何とかしたいと思っている(切実な悩み)。

解決案: ヒアリングの型を決める

「ヒアリングがうまくなりたいなら、コミュニケーション能力を上げるしかない?」といったふわっとした願望では何も解決しない。データマネジメントのためのはともかく、ユーザーヒアリングはプロダクトやUXの分野では山ほど研究されている。そのノウハウをデータマネジメント用に型化することでヒアリングにも応用できるのではないか、と思ってこのエントリを書いてみている。「こうするとうまくいったよ!」というアドバイスなどがあれば是非教えて欲しい。

ヒアリングの質問とリサーチの質問を別々に持っておく

これは自分で編み出したわけではなく、前職のUI/UXの方から教わったノウハウ。「ヒアリングの質問」は文字通り、ヒアリング時に聞く質問。「リサーチの質問」はヒアリング対象者に直接語りかける言葉ではなく、ゴールを明らかにするための質問になっている。この文脈でのゴールとは「アセスメントを通じ、データ活用の当事者の視点も考慮した上でデータマネジメントの優先順位を決める材料を得る」ということ。

自分は「リサーチの質問」をそのままヒアリングで聞いてしまって失敗することが多く「ヒアリングの質問」を別途考えておくことでユーザーの目線から課題感を捉えやすくしようと試みている。例えば、メタデータの項目では以下のように設計する。

  • リサーチの質問
    • 利用者の観点でメタデータがなくて困っていることはどれくらいあるか
    • データ自体が何者か、出所がどこか、自信を持って使えるか、分からないときは誰に聞けばいいか分かるか
      • いつもどこを見ている? BigQueryは意外と見ていなくて、BIだけだったりする?
      • ユーザーに対してメタデータをどこにどう提供するかを決める材料が欲しい
  • ヒアリングの質問
    • ここ一ヶ月で行なったデータ分析やデータ抽出の仕事について教えてください
    • 欲しいデータをすぐに取りにいけていますか、分からないとき普段はどこを参照しますか?
      • 社歴が長い人はどこに何があるか把握してしまっていることがある
      • その場合は同じチームに新しく入ったら、どこをポインタとして教えるかを聞く
    • 使いたいデータに不明点があったときに、いつもどうしていますか?
      • 例: xxxCodeの数字の意味が分からないとか
      • 例: 契約企業にデータやカラムの意味を聞かれたとき
    • データが怪しい(例: 最新のレコードが古い)ときどうしてますか?

リサーチの質問は別に用意しておいて、ヒアリングの質問ではデータ活用者の普段 / 最近の生活に基づいて質問をしたり回答がしやすいように具体例を置くようにしている。また、ヒアリングの質問を作り終えたら、リサーチの質問に対する回答も出揃っている状態になっているかも同時に確認する。それに応じて、ヒアリングの質問を増減させる。

ヒアリング対象者について事前に理解を深める

ヒアリングの時間は限られているので、ヒアリング対象者について事前に調べられることは調べておくに越したことはない。データ活用の文脈では、ヒアリング対象者は社内の人であることが多いため、事前に調べられることが色々ある。

  • BigQueryのクエリの傾向
    • 細かいクエリの内容まで見ているとキリがないが、INFORMATION_SCHEMA.JOBS_BY_ORGANIZATIONあたりを使うと、参照しているBigQueryのテーブル(referenced_tables)が分かる
    • どのテーブルが便利と思っているか、不満があるかの引き出しになりやすいので、ヒアリングの前に調べておけるとスムーズにやれることが多い
    • Looker StudioやConnected Sheet経由で発行されたクエリは割と分かりやすいので、自分でクエリを書いているかBI経由でクエリを発行しているかの割合なども頭に入れておくとよい
  • Slackでの発言
    • どういうチャンネルで発言しているか、困ったら誰にmentionされていることが多いか。人間関係のグラフ構造が頭の中にできてくると、理解が進みやすい
    • 最近困った具体的な事例があったらメモしておく(ヒアリングのときに深掘りの材料にできることが多い)
  • Notionでの最近の投稿
    • Notionでなくても何でもよいが、社内ドキュメントでどの辺をよく書かれているか
    • (データに限らず)解決したいと思っている課題感などを掴みやすい

全員に同じ項目を聞かない & 全体のカバレッジも担保する

DMBOKは11項目あり、多岐にわたる。どのヒアリング対象者に対しても同じ質問をしようとすると「この人の普段の仕事、ぶっちゃけこの項目関係ないな...」という項目も出てくる。そのため「この項目の解像度を上げるにはあの職種の人にヒアリングをする必要がある」ということを事前に決めておく。自分の経験では、11項目のうち1職種あたり平均5~6項目ヒアリングすることが多かったように思う。部分的な項目をヒアリングしていくことになるので、全体としてヒアリングのカバレッジが担保できているかにも注意する。

職種の数やデータユーザー数がめちゃくちゃ多い場合、代表的なペルソナの設定をすることもある。データ活用といっても例えば

  • 人に作ってもらったダッシュボードの情報から意思決定する
  • BigQueryにすでにあるデータをBIツールでダッシュボード化して、人に使ってもらう
  • ダッシュボード化以前のDWHやデータマートを作る人
  • 生データからひたすらSQLを書きまくる人

などがあり、それぞれのペルソナによって聞くべき内容も変わってくる。

その場で問題解決を始めない

色んな困り事を聞いていると「それはこうするとうまくできますよ!」とついつい言いたくなってしまうことがあると思うけど、ヒアリングの最中はぐっと堪える。ヒアリングの場はあくまでヒアリングのための場なので、問題解決はしない。問題解決をどういう優先順位でやっていくかを決めるのがアセスメントの目的である。ユーザーの課題をいかに拾い出すかに全ての力を注ぎ込む。

まとめ

アセスメントのためのヒアリング、自分ではあまりうまくできている気はしていないが、それでもうまくやるために自分が意識している型を書いてみた。自分の場合はこういったこと考えている、などのフィードバックを色んな方面からもらえると嬉しい。

参考