データ組織の日常あるある 7選 - Leverages データ戦略ブログ

はじめに

こんにちは！データ戦略室の小山です。
今日は普段のブログとややテイストを変えて、「データ組織の日常あるある」に関しての記事を書きます。

データに関する仕事をしている人ならきっとなんとなく共感してもらえるリアルなあるあるを7つ用意しました。

普段データを使って試行錯誤している方は多かれ少なかれ共感していただけるのではないかと思いますし、普段そこまでデータに関わる仕事をしていない方は新たな領域としてデータの世界を知っていただける内容になるのではないでしょうか。

ややニッチなものもありますが、楽しくゆるっと読んでいただきつつ、ビジネスでのデータ活用に興味を持って貰える人が増えたら嬉しいなと思います！

1. 分析で使いたいカラムほど欠損だらけ

データベースにカラムは存在するが、中身のデータを見てみたらほとんど入っていないパターンですね。使いたいデータに限って欠損が多い気がしますが、これに関しては大いに個人としての感情が入っている気がします。笑

「あるデータでなんとかしよう」から「今後必要だからこういったデータを貯めていくにはどうしたら良いか考えよう」という文化を私達も今まさに作っていっている最中です。経営者や意思決定者がデータを資産として貯めることをコストではなくて投資として捉えられるようになってくると、会社のデータ活用が進んだ証拠なので、データ組織として影響力を発揮していく必要があります。

2. 「データ間違ってるんで直してください」と言われたときのなんとも言えなさ

よくありますね。BIツールで作成されている定常的なモニタリング体制、定期的に抽出しているデータセットなどのデータが、現場の肌感と乖離したときに言われる言葉です。

これまで正しく動いて(表示されて)いたものが、アーキテクチャを変更していないのに違う値を表示するようになるということはありえないので、ほとんどの場合は「データが正しい」です。システムの仕様変更、ETL処理上のタイムラグ、など様々な原因が考えられますが、経験上一番多いのが元データの誤入力です。「データは間違っていない。間違えるのはいつも人間である。」という言葉を心の中でつぶやきながら粛々と対応します。ビジネスサイドの皆に指標の定義を常に分かってもらえる環境を作れると、こういった状況は減っていくのだと思いますが、組織も大きくなってくると簡単ではないですよね。

ちなみに、「データ間違ってるんで直してください」に対応する際に最も大切なことは、報告してくれた人と一緒に「どのようなデータになれば正しいとみなせるのか」を合意することだと思います。

3. データに詳しい人が辞める時に大慌て

元データをクレンジングしてきれいにしたり、データマートや中間テーブルを定義して処理を共通化したり、ETL仕様やKPIの算出定義をドキュメンテーションして保守したり、、、

いわゆる「データアーキテクト・データ整備」と言われる仕事は、時にはビジネス側から後回しにされることも多いです。「整備しなくても今は特段困ってないから～」という理由で後手に回ることが正直なところだったりします。だいたいそういった状況が一転するのが「データのことをよく知っている生き字引がいなくなった時」。

急に言われても無理です。みなさん、データ整備は計画的かつ継続的なご利用をよろしくお願いしますね。
正確性が保証されたメタデータ(データに関するデータ)を常に整備していおくのもデータ戦略室が担保していく役割なので、今も徐々に体制を作っていかねばならぬと自戒しています。

4. 予測すればするほど人間の凄さを実感

ビジネスの意思決定を効率化するために、機械学習で人間の判断をトレースしようとチャレンジする場合も最近は多くあります。

仮説を立てて特徴量を作って試行錯誤するのですが、どうしても精度には限界があります。何をしてもなかなか人間の判断に寄せきれない領域。そんなとき、奥に進めば進むほどデータサイエンティストは思うのです。「人間ってすげぇ。」

ちなみに、同じ機械学習の話でいくと「結果が悪すぎるから多分ミスってる、結果が良すぎるから多分ミスってる」というのもありました。データで完全に再現できすぎても気持ち悪かったりするんですよね。

5. 誰も認識していないシステムバグをよく発見する

しょっちゅうあります。データ分析しようと思ってデータを眺めていると、データに違和感を覚えることがあります。

想定と違うデータ。原因調査をしても、想定される要因はイマイチ当てはまらない。どうしようもないのでエンジニアにデータの生成ロジックを質問しにいくと「バグですね。逆に良く見つけましたね」という言葉。

「システムがビジネス上問題なく通常稼働すること」と、「正しいデータが常時蓄積され続けること」は完全に別物。
社内では、社内のシステムやプロダクトから発生するデータが最も多いので、社内のプロダクト開発情報は常にキャッチアップしてデータ仕様の変更について連携できる仕組みを作っているつもりです。まだ完璧にできないときもありますが。

6. SQLの予約語がカラム名になっていて発狂する

データ基盤を作っていると、様々なシステムのデータベースを触ることがありますが、「なんか処理動かないなー」という時の原因がたまにこれです。

よく使われているカラム名個人的ベスト3は「to」「from」「date」です。軽い気持ちで混ぜるのはやめましょう。どこかできっとデータエンジニアが発狂しています。

最初は「まさかそんなことはあるはずない」と思うのですが、だんだん「予約語が混入していることも考慮して処理考えないといけないよね」という思考になってきます。これが成長。(前向き)

7. 他社の入力フォームからテーブル定義を想像しちゃう

完全に職業病ですね。「このデータは裏側では階層化されて溜まってそうだな。」「このデータの入力形式だとデータ活用する時に使いにくいのでは？」「お、ちゃんと入力バリデーションかかってるな、いいぞいいぞ。」など謎の視点で入力フォームと向き合い出したら立派なデータマンです。

いわゆる「設計」には必ずメリットデメリットが存在し、設計者の思想やその選択肢を選んだ理由が必ず反映されているので、どうしても裏側にある思考の流れをトレースしてしまうのですよね。
共感していただける方、ぜひ一緒に働きましょう。笑
ちなみに、こういった観点で物事を見ることができると、レビューをする際に役立ったりします。