【真のデータサイエンティストになるために#4】“独り立ち”データサイエンティストへの道

Techブログ

2026.01.23

この連載では、データサイエンティストの視点で、筆者が以前勤めていた外資系コンサルティングファームの経験を踏まえ、価値のあるデータサイエンティストについて記載させていただきます。

【第4回】“独り立ち”データサイエンティストへの道

第1回では“問題だらけのデータサイエンティスト”のリアルな姿を暴き、第2回では“本物”になるためのマインドセットや必須スキルを整理、第3回は“見習い期”に注意すべきポイントを記載しました。今回の第4回は見習い期から一人前のデータサイエンティストになるために必要な、データサイエンス以外の能力を中心に記載していきます。

「この分析、誰かに説明しておいて」「次のミーティング、1人で入っていいよ」「この提案、任せるね」。そんなセリフを言われた時、「もう自分は一人前なんだろうか」と戸惑ったことはありませんか。

本記事では、私がこれまでデータサイエンティストとして様々な案件に携わり、“独り立ち”に至るまでに必要だった「7つの力」について、リアルな失敗談や現場エピソードを交えてご紹介します。

①ビジネス理解と巻き込み力

筆者がまだまだデータサイエンティストとして駆け出しだった頃、地方銀行のプロジェクトでカードローンの分析を担当しました。経験不足もあり、金融サービス部門のコンサルタントにお客様への報告を任せることにしたんです。

分析結果そのものはコンサルタントに報告したのですが、分析の目的や手法などを早い段階からともに作り上げていませんでした。そのため、コンサルタントが独自の解釈でお客様へ報告してしまい、筆者の意図しない内容がお客様へ伝わってしまいました。

この経験から、分析終了後ではなく分析設計の段階から関係者を巻き込み、共通意識を持つことで防げたミスであったと反省しています。

②リサーチ力とドメイン知識理解

製薬会社の営業効率を上げることを目的としたデータ分析プロジェクトに携わった際、「どのようなタイミングで病院に営業を行えば自社の薬を採択してもらえるか」を分析しました。EDA（※1）をしたものの、なかなか傾向が掴めず、壁にぶつかりました。

そこで当時の同僚で、かつて製薬会社で営業をしていた経験のある方に相談に乗ってもらいました。その中で知ったのが、病院の規模によって薬の採択プロセスが大きく異なるという事実です。

大きな病院では、薬の採択にあたり薬事審査会を経る必要があり、意思決定までに3〜4ヶ月かかる場合があります。一方で、小さな病院では院長の判断で比較的短時間で薬の変更ができるところもあるようです。つまり、病院の規模を考慮せずに一律で分析していたこと自体が、壁にぶつかっていた原因でした。

このドメイン知識を踏まえることで、「どのようなタイミングで」、「どのような医師に」営業を行えば効果が最大化できるかを把握できるようになりました。

この案件を通じて、業界知識を無視しながらデータだけを見ていても、本質的な課題解決に繋がらないことを痛感しました。データ分析には、データだけではなく、ドメイン知識を組み合わせることが不可欠であると気づかされた経験でした。

※1 EDA：データ分析の初期段階で行われる、データの特徴やパターンを把握するための手法。データの可視化や統計的な分析を通じて、データの傾向や異常値、変数間の関係などを理解することを目的とする。

③伝える力（グラフ・資料・ストーリー）

飲料メーカーにて、過去の時系列データから需要予測を行うプロジェクトに参画したときのことです。

筆者は、時系列データ用の交差検証（※2）の結果を報告用スライドとして共有しました。内容としては専門的に見て必要な情報ではあったものの、意思決定には直接関係しない情報が中心となっていました。その結果、お客様から「この資料は結局何が言いたいの？」と言われてしまったのです。

この経験から、まず共有すべきだったのは、「結論として何が言えるのか」と「その判断を支える最低限の根拠」でした。そのうえで、専門的な内容の共有にする必要があったと反省しています。

※2 時系列データ用の交差検証：一般的な交差検証では、データをランダムに分割し、予測・検証を実施するが、時系列データでランダムに分割すると未来のデータで過去のデータを予測することになり、現実には起こり得ないことが発生してしまう。時系列データに対する交差検証では、常に過去のデータで未来のデータを予測するように分割する必要がある。

④生成AIを正しく使う力

筆者が現在所属しているアルサーガパートナーズでは、生成AIを日常的に活用しています。筆者の例で言うと、データサイエンスに詳しくないお客様に説明する際の表現を相談したり、本連載の執筆にあたって構成などの作成を手伝ってもらったりと、あらゆる場面で生成AIの力を借りています。

一方で、生成AIの利用にあたっては注意点もあります。広く言われていることですが、利用に際しては情報漏洩に気をつけることや、生成AIの文章を信じ切ってしまうのではなく、最終的な事実確認は必要です。筆者自身も、かつて生成AIにVBAコード（※3）を書いてもらったのですが、やり取りを重ねても望む結果が得られず苦労した経験があります。

こうした問題は、近年「ポチョムキン理解」と呼ばれる概念とも関連しています。ポチョムキン理解とは、概念を説明することはできるが、それを使って正しく推論したり、応用したりすることができない状態を差します。

生成AIは言葉のつながりや文脈をもっともらしく生成するため、表面的には正しそうな回答を出せますが、実際には知識の根拠や意味理解が欠けている場合があります。具体的な例として「ABAB韻律」がよく知られています。詩を書くとき「A行とB行の韻を交互に踏む」という定義は正確に説明できるが、詩の穴埋め問題でABAB韻律を正しく適用できないことが挙げられます。

生成AIを有効に活用するためには、こうした特性を理解したうえで、あくまで“補助的な存在”として使い、人が最終的に判断することが重要だと感じています。

※3 VBAコード：Visual Basic for Applicationsの略で、Microsoft Office製品（Excel,Word,PowerPointなど）に組み込まれたプログラミング言語のことです。

⑤最先端を追う力

以前所属していた会社で、当時の上司が施策効果の検証としてCausalImpact（※4）という手法を用いていたことがありました。CausalImpactは手軽に使えるように見える一方、正確な推定には因果推論（※5）に近い強い仮定が成り立つ必要があります。（当時筆者も深くは理解できていなかったため、一生懸命勉強しました）

その過程で、上司の説明資料のappendixにはその強い仮定が成立する根拠が示されておらず、また成立するとも思えなかったのです。不安に感じて上司に確認したところ、「問題ない」との回答でかなり焦った記憶があります。幸いにも、その手法はいつの間にかお客様への報告内容から外れていたため、嘘の報告をすることは免れました。

最先端を用いることで、それまで難しかった分析が可能に、あるいは簡単にできるようになることは多くあります。しかし最先端であるからこそ、使用の注意点などが十分に共有されていない場合もあります。この経験から、手法の新しさだけでなく、その前提や限界を理解した上で使うことの重要性を学びました。

※4 CausalImpact：施策やイベントといった介入がビジネス指標などに与えた因果的な影響を推定する手法。介入がなかったと仮定した場合の予測との比較により算出する。
※5 因果推論：「ある行動や出来事が結果にどんな影響を与えたか」をデータから科学的に推測する手法。相関とは違い、他の要因も考慮する必要があるため、正確に因果関係を見極めるのは非常に困難で、推定のために強い仮定を置く場合もある。

⑥再現性の担保と精度改善の“勘所”

分析やコードのレビューではあまり大きな問題にならないこともありますが、お客様への分析結果共有において、Pythonやライブラリのバージョン管理は非常に重要となります。（筆者はエンジニアリングの知識が乏しいため、この点は苦手なのですが…）

たとえ全く同じコードを乱数固定で実行しても、実行環境の違いによって結果に微妙な差異が生じることがあります。このような状態では、条件を一部のみ変えてシミュレーションを行う際に、信頼性を担保することができません。そのため、Gitを用いてプログラムのバージョンを管理する、あるいは仮想環境をエクスポートしてチームで共有し再現性を担保する必要があります。

また、精度改善のためには地味な作業も欠かせません。ときには分析結果のデータを1件ずつ見ながら「どのようなときに分析が外れ、どのようなときにうまく分析できているか」を丁寧に確認することもあります。

経験を積むとデータサイエンスへの慣れと、分析対象への慣れの両方が深まり、分析の外れ方から問題点の検討がつくこともあります。一方で慣れないうちには、こうした泥臭い作業に時間を割くこともデータ分析の現実だと感じています。