データ基盤チームの橋口です。この記事はデータ基盤チーム & Unit9（エビデンス創出プロダクトチーム）ブログリレー2日目の記事です。 昨日は坂元さんの『冴えたClaude Codeの育て方（50本のSQLをdbt化した話）』でした。
私の所属するチームでは、社内のデータ活用サポート（データマート作成、分析支援など）を重要な業務の1つとしており、関連部門と一緒にプロジェクトを進める機会も多くあります。
関連部門とプロジェクトを進めていく中で、私は技術的な課題と同じくらい、ステークホルダーといかに上手く協業するかが大事だと学んできました。
なぜなら、データ利活用は「ビジネス課題の特定」から「どのデータを使うかの判断」、「技術的な実装」、「関係者との合意形成」まで幅広く、1人ですべてをカバーすることが難しい領域だからです。
本記事では、私が日々の業務で学習した、ステークホルダーとの協業を円滑に進めるための3つの具体的なコツ(Tips)をご紹介します。データ利活用に携わる皆さんの参考になれば幸いです。
- はじめに：データ整備の「壁」は技術だけではない
- コツ1：「目的」を納得できるまで掘り下げる
- コツ2：完璧な100点より意思決定できる80点を目指す
- コツ3：アウトプットはシンプルに素早く
- まとめ：データ整備は信頼関係の構築から
- We are hiring!
はじめに：データ整備の「壁」は技術だけではない
「データは存在しているだけでは無価値」とよく言われますよね。これは、データがどういう経緯で生まれたかという文脈（コンテキスト）から切り離されてしまうと、ただの数字や文字列の集まりに見えてしまい、正しい分析や判断に使えなくなってしまうからです。
データに意味を持たせ、利活用を成功させるためのハードルは、技術的なパイプライン構築だけではありません。それ以上に、プロジェクト初期のステークホルダー（ドメインエキスパート）との協業、特に要件整理や整備の進め方が大事になってきます。
なぜなら、ここで目的や仕様が曖昧なままだと、後になって「ああ、そういうことじゃなかった…」という大きな手戻りにつながってしまうからです。 最初の段階で「何のためにやるのか」をしっかり合わせることが、プロジェクトがうまくいくかどうかを左右すると感じています。
これらを曖昧にしたまま進め、完成したデータマートが全然使われない…といった切ない経験をされた方もいらっしゃるのではないでしょうか。
コツ1：「目的」を納得できるまで掘り下げる
ポイント：エンジニアがビジネス課題に踏み込み、仕様の曖昧さを解消する
データ利活用のプロジェクトで最も重要なのは、「何のためにこれをやるのか」という目的を、ステークホルダーと共有することです。
「次の施策どれやろうか悩んでいて、判断材料が欲しいんだよね…」 こんな、ぼんやりとした課題感から相談を受けてプロジェクトが始まることもあるのではないでしょうか。（むしろ、そういう関係を築けているのは素晴らしいことですよね）
ステークホルダーはビジネス課題の専門家ですが、その課題が最初からデータ仕様として完璧に固まっていることは稀です。走り出しは曖昧だった目的を、ステークホルダーとの対話を通して具体的な要件に繋げていきます。例えば、「Aというデータが見たい」と言われたら、「承知しました」とすぐに作業に取り掛かりたいところですが、「そのデータを見て、どんなアクション（意思決定）につなげたいですか？」と一歩踏み込みます。
エンジニアとしては楽しい実装フェーズのことに意識が向きがちになりますが、プロジェクト初期は役割を厳密に分けすぎず、各人がプロジェクト成功のためにベストな行動をすることで、成功の確度は高まるのではないかと実感しています。
まずは、私自身が「自分の言葉で今回のプロジェクトの目的を説明できる」状態になること、そしてその説明内容に自分自身が納得感を持てることを目指すのを心がけています。納得感が持てると、仕事の質やスピードに良い影響があると実感しています。私から積極的に動き、仕様を明確にしていきます。
話した内容はメモやドキュメントに残すのが確実な方法ですが、まずは粗くても良いので実物（データやダッシュボードの試作品）を作って見せるのもいいと思います。実際に動くものや、生に近いデータを見ながら議論することで、ステークホルダーも「あ、これだと判断できない。欲しかったのはこっちのデータだ」と具体的に指摘でき、認識のズレ（曖昧さ）を解消できます。
コツ2：完璧な100点より意思決定できる80点を目指す
ポイント：目的に見合ったデータ品質を設定し、合意する
データ整備において、クリーンなデータ（100点）を最初から作るのは難しい場合があります。
例えば、複数のデータソースを統合する場合や、長年使われ続けているテーブルにビジネス環境の変化対応で仕様変更が加えられている場合など、データの品質や粒度がまちまちだったり、同じ指標でも定義が異なったりすることがあります。
ここでリソースをどこに集中させるかという判断が求められます。100点のデータを闇雲に目指すのではなく、今回の目的ならどのレベルの品質が本当に必要か？というラインを、ステークホルダーとすり合わせることが重要です。
例えば、「全社のアクティブユーザー数が見たい」という要望が来たとします。「全社」という言葉を受け、全体の20%未満しか占めない古いシステムのデータ連携から着手し、プロジェクト全体が遅延するのは避けたいところです。
こんな時、まずは状況を素直に共有し、成果の主要部分（80点）を得られるところにフォーカスして、進め方を相談してみます。「AサービスとBサービス（全体の80%）は明日から見られますが、Cサービス（残り20%）のデータ連携は技術的に1ヶ月かかります」「今回の目的を考えると、まず80%を占めるA+Bで傾向を見るのはいかがでしょう？ Cはフェーズ2として進めませんか？」
ここでも、やはりプロジェクトの「目的」を見据えることが重要です。状況を素直に共有した上で、成果の主要部分（80点）にフォーカスしてフェーズを分けるなど、目的を達成するためのベストなアクションを提示できれば、建設的な話し合いにつながりやすいです。
完璧な網羅性（100点）より、成果の主要部分（80点）を素早く提供することを優先する。このすり合わせにより、エンジニアは目的達成に必要な開発に集中でき、ステークホルダーも現実的な分析計画を立てられるようになります。
コツ3：アウトプットはシンプルに素早く
ポイント：小さく始めてすぐに見せ、フィードバックをもらうサイクルを回す
データを整備しても、それが使われなければ意味がありません。ここで重要なのは、最初から完璧なアウトプットを目指す必要はないということです。
小さく始めて、すぐに見せて、フィードバックをもらうサイクルを回していくことが、最終的に使われるデータ活用につながります。
最初から凝ったグラフや完璧なダッシュボードを作ろうとすると、時間がかかる上に運用の難しさにもつながります。簡単なピボット集計やシンプルなグラフだけでも、これまで見えなかったインサイトを得るには十分な威力があります。
ここでも、コツ1で明確にした「目的」が活きてきます。目的がはっきりしていれば、一番見たかった数字はどれか？に集中できます。
まずは一番見たかった数字をシンプルな形（例えばスプレッドシートへのエクスポート）で提供してみます。それを見てもらい、ステークホルダーから「次はこっちの数字と組み合わせて見たい」というフィードバックをもらってから、次の改善に進む。
このような小さく作って、すぐに見せて、改善するサイクルを回すことで、本当に価値のあるアウトプットに早くたどり着けます。この進め方なら、もし方向性が違ってもすぐに修正できますし、データがただの数字から次の行動の起点に変わっていくプロセスを、ステークホルダーと共有できます。
まとめ：データ整備は信頼関係の構築から
今回ご紹介した3つのコツ（目的の掘り下げ、品質レベルのすり合わせ、小さく始める）は、すべてステークホルダーとの信頼関係を築くためにあります。
データエンジニアが単なる便利屋ではなく、プロジェクト成功を目指す頼れるパートナーとして振る舞うことが、複雑なデータ利活用プロジェクトを成功に導く、進め方のコツだと考えています。
We are hiring!
エムスリーでは、様々な領域のエキスパートとの協業を通じてビジネス課題の解決に取り組んでいます。こうした働き方に興味を持っていただけた方は、ぜひ以下のリンクからカジュアル面談にお申し込みください。まずはお気軽にお話ししましょう！
