「データ分析を頑張ったのに『で、だから何？』と言われた」「依頼通りに実装したのに、完成後に『思ってたのと違う』と言われた」——こんな経験、心当たりはないだろうか。
Qiitaに投稿されたOrbitics株式会社・上野氏の記事では、データ分析初学者が現場で陥りやすいバッドプラクティスが鋭く整理されている。記事の核心は一言でまとめられる：「失敗の多くは技術不足ではなく、設計と対話不足が原因だ」。これは刺さる。
アンチパターンの全体像
記事では以下の対比が示されている。
| アンチパターン（Bad） | 望ましいパターン（Good） |
|---|---|
| 設計を飛ばしていきなり集計 | 先に Why/What を一文で定義してからデータに触れる |
| 作った後に用途を考える | 誰が/どの意思決定に使うかを事前に合意 |
| 何でも分析して論点が拡散 | 仮説に紐づく問いを明確に限定（優先順位付け） |
| 依頼を額面通りに受ける | Why/What/How を聞き出し、モックで早期合意 |
落とし穴①：要望を額面通りに受け取る
典型シナリオは「30代女性の行動を可視化して」という依頼を忠実に実装したところ、完成後に「本当は離脱要因が知りたかった」と判明するケース。工数は倍増し、信頼も損なわれる。
回避策として記事が提示するのは Why/What/How への分解ヒアリングだ。
- Why：何の意思決定のため？
- What：知りたい因果・関係は？
- How：どんな形で/誰が/いつ使う？
さらに実践的なのが「反事例テスト」だ。「この結果がこうだったら、意思決定はどう変わりますか？」と問うことで、依頼者自身も気づいていない真の目的を引き出せる。手書きやExcelのモックを先出しして早期に方向性を合意するだけで、後戻りコストを大幅に削減できる。
落とし穴②：アウトプット後に用途を考えはじめる
ダッシュボードを作ったものの「鑑賞用」になってしまい、実際の施策や意思決定に接続しない——これも典型的な失敗パターンだ。成果が「レポート納品」で止まり、行動変容に転換しない。
回避策のポイントは、着手前に「誰が/何を決めるために/この分析を使うのか」を明確にしておくこと。分析の目的と使い手を先に定義することで、出力形式や粒度も自ずと変わってくる。
技術より先に「設計力と対話力」を鍛えよ
個人的にこの記事が刺さるのは、「技術スキルを磨くより先に、設計と対話のスキルを鍛えるべき」という主張が現場の実感と一致しているからだ。SQLやPythonは後から学べる。だが「依頼の真の目的を引き出す力」「モックを使って早期合意する習慣」は、意識しなければ身につかない。
データ分析を始めたばかりの方はもちろん、「なんか分析が空振りになる」と感じているエンジニアにも一読をおすすめしたい。続編の元記事にはさらに2つの落とし穴の詳細と具体的な回避策が掲載されているので、ぜひチェックしてみてほしい。