株式会社松尾研究所のごうやです。
本記事は、松尾研究所 Advent Calendar 2025の記事です。
株式会社ブレインパッドの浅野様から先輩データサイエンティストからの指南書をご恵贈賜りましたのでレビューします。
はじめに
データサイエンティストとして働いていると、「分析はできたけど、その先どうするの？」と素朴な疑問が湧きました。手元のNotebookで精度の高いモデルができた。技術検証としては成功。それを本番環境で動かして、クライアントに実際に使ってもらうとなると、途端にハードルが上がります。
本書『先輩データサイエンティストからの指南書』は、エンジニアリングの観点から「分析の先」について体系的に解説した技術書です。
例えば、コード品質を扱う類似の本で言うと『リーダブルコード』などの名著もあります。本書ではこれらの内容も踏まえながら、実際のPythonコードを交えて具体的に解説されているので、データサイエンティストのはじめの一冊としておすすめな本となっています。
こんな人におすすめ
本書は、以下のような方に特におすすめです。
- これからデータサイエンティストとして働く方
- 分析スキルは身につけてきたが、チームでの開発経験が少ない方
- データサイエンスチームの教育担当者
本書の全体像
本書は全6章構成で、データサイエンスプロジェクトの「分析前後」に必要なスキルを扱っています。
第1章で全体像とモチベーションを示した後、第2章で環境構築、第3章でコード品質管理、第4章でデータ品質確認、第5章で実験管理、第6章でプロトタイプ開発と続きます。分析モデリングそのものではなく、それを「価値につなげる」ための周辺スキルに焦点を当てているのがユニークだと思いました。
第1章
昨今CursorやClaude CodeなどAIコーディングツールの普及により、基本的な分析は誰でもできるようになりつつあります。そのような中でデータサイエンティストには、分析結果を実際のビジネスに活用できるかという点まで意識することが求められています。一方で、体系的に必要なスキルを学ぶことができる経験が実務以外だと乏しいのが現状です。
本書では、データサイエンティストのスキル習得プロセスによる課題とデータサイエンスプロジェクト特有の難しさとして課題を整理し、価値を届けるまでのスキル習得を目的としています。
- データサイエンティストのスキル習得プロセスによる課題
- 適切な環境構築ができておらず、作成したコードの再現性がない
- コードの品質が低く、PoCや運用時のコーディングに想定以上に時間がかかる
- データサイエンスプロジェクト特有の難しさ
- 現場のデータは汚い
- モデルを作成する際は、試行錯誤の結果を記録しておく必要がある
- 分析結果や機械学習モデルの予測結果をそのまま提供しても運用は難しい
一般的な入門書であると、機械学習モデルを作る、であったり、Kaggleでタイタニックにサブミットする、であったりで終わってしまうものもありますが、「価値を届けてこそ」という本書のメッセージは自身のこれまでの経験からも強く思うことでした。
第2章
PoCや手元でのアドホックな分析をしているだけだと、精度改善に意識が向きがちで実運用のことは二の次になりがちです。ライブラリのバージョンも、ディレクトリ構成も、その場しのぎで済ませてしまうことが多いです。いつの間にか依存関係がカオスになっている。そんな経験は誰しもあると思います。
しかし、チームで開発する、本番環境にデプロイする、他の人に引き継ぐ、となった瞬間に「環境が再現できない」という問題が顕在化します。「自分のPCでは動くのに、環境が変わると動かない」という経験は、全データサイエンティストが一度は通る道と思います。
面白いなと思ったのはまず初めにディレクトリ構成の節から始まるということです。
入門的な本でありながら、環境構築でディレクトリ構成から整えるところに実務での大切さを強く感じました。どのディレクトリは何用で、というのも細かく説明されており、そうする意図もわかりやすくてよかったです。また、Cookiecutterについてもコラムに紹介があり（他のコラムも面白いのがとてもズルい）、丁寧な印象を受けます。
ディレクトリ構成
.
├── Dockerfile
├── LICENSE
├── README.md
├── app
├── compose.yml
├── data
├── docs
├── model
├── notebook
├── outputs
├── pyproject.toml
├── scripts
├── src
├── tests
└── uv.lock
他にもDocker、Dev Container、uvによるパッケージ管理などが説明されており、新しいメンバーがプロジェクトに参加したときも、環境構築が迅速に対応できるのかなと思ったりしました。
サポートページがあるのでDockerfileなども参考にするのが良さそうです。
弊社参考記事もありますのでぜひ…！
第3章
第3章はコード品質管理について触れており、良い品質のコードの書き方や、コードレビューについて説明されています。
一番内容が濃い部分となっており、読んでいて一番面白い章でした。
NotebookではあくまでEDA用として可読性や保守性を蔑ろにしてしまうことが多くあります。その結果、セルを行ったり来たり試行錯誤したせいで、変数の状態が不明確になり、「このセルを実行する前に、あのセルを実行しておく必要がある」といった暗黙の依存関係が生まれます。数ヶ月後に同じNotebookを開いたとき、どの順番で実行すればいいのかわからなくなります。悲しいですが本当に同じ人間が書いたのかを疑うレベルです。
実運用を踏まえて脱Notebookとするときに保守性に優れたコードを書く必要があります。
そのために本章では、関数化、モジュール化、設定の外出しなど、段階的に品質を上げていく方法が解説されています。
特に本書を読んでいて印象的だったのは、クラス設計におけるアンチパターンやデザインパターンにまで触れている点です。分析業務だけをやっていると、こうした設計の観点を意識する機会は少ない気がします。オブジェクト指向がいまいち理解できず、神クラスを作ってしまったり、そもそもそれの何が悪いのかよくわからないということもあると思います。本書ではストラテジーパターンを紹介し、インターフェースを作ることでモデルの変更を容易にしています。
この様に、分析用に「とりあえず動けばいい」で書いたコードが、後から見ると何をしているのかわからない。他の人に引き継ごうとしたら、説明に何時間もかかってしまう。これを防ぐため、本書では「なぜそれが問題なのか」「どう改善すればよいのか」が、分析者の目線でわかりやすく書かれています。
コードレビューについても触れており、どの様にPull Requestを出すとよいのか、レビュアーとしての心得などのベストプラクティスが書かれているので、チーム開発をどの様にすべきなのかを知るきっかけとしてかなり有用に感じました。
第4章
この章ではデータ分析をする前の品質確認の重要性について触れています。
- 意図していない欠損が多い
- 重複がある
- 異常値を含む
- バイアスがある
などのデータを分析の品質を低下させる「汚いデータ」とし、対応策を説明しています。
特に本章で触れているデータ品質の評価軸としてDMBOK(データマネジメントに関する知識を体系立ててまとめた書籍。Data Management Body of Knowledgeの略称)の観点から下記7項目を取り上げています。
| 評価軸 | 説明 | 具体例 |
|---|---|---|
| 有効性 | データの値が定義された領域の値と一致しているか | ・存在しない日付がないか ・年齢に負の値がないか |
| 完全性 | 必要なデータがすべて存在しているか | ・指定した全期間のデータが揃っているか ・指定した全ユーザーのデータが揃っているか |
| 一貫性 | データが特定のテーブル内で一貫して表現されているか、あるいは、テーブル間で一貫して関連付けられているか | ・ある日を境にデータの分布が大きく変化していないか ・カラムの中で値に表記揺れがないか |
| 整合性 | データが定義されたビジネスルールや制約に基づいて正しく関係付けられているか | ・複数のカラム間の大小関係は正しく成立しているか ・複数のテーブル間で、ID情報を正しく連携・更新できているか |
| 最新性 | データが新しく、現在の状況と比較して「まだ正しい」と言えるか | ・顧客マスタは最新のデータか ・パンデミック前のデータなど、現在の状況とかけ離れたデータを使用していないか |
| 妥当性 | データパターンが期待に合致しているか | ・年齢の分布が感覚値と大きな乖離がないか ・人口はフェルミ推定の値と大きな乖離がないか |
| 一意性 | 同じ実体を表すデータが、同じテーブル内に複数存在していないか | ・重複しているレコードはないか ・重複しているカラムはないか |
これまで分析業務だけをやっていると、この領域はあまり意識しにくかった部分です。Kaggleなどもそうですが、分析に使うデータは「誰かが用意してくれたもの」という感覚になりがちです。
しかし実際では、欠損値が意味することや、どう計測されたデータなのかを意識することなどが本質的な分析にも求められることです。
そこで、上記観点に沿ってデータの品質を確認することで、意図しないデータの存在に気づいて手戻りの可能性を下げることができそうです。
その後のデータ加工についてもPanderaを使ったデータフレームのバリデーションについて取り上げています。Panderaにより、データフレームのスキーマを定義しておき、データがそのスキーマに適合しているかを自動でチェックできます。PanderaやPydanticのバリデーションライブラリももっと活用しなきゃなあという気持ちになりました。
また、データサイエンティストがデータマネジメントを学ぶ重要性が触れられており、そこではデータ基盤チームとの連携についても触れられています。本章を読むことで、データ基盤チームと同じ目線で会話ができるようになるきっかけにもなると思います。
第5章
あるあるですが
- 「あのときの実験、どのパラメータで動かしたんだっけ」
- 「前のバージョンに戻したいけど、どれが前のバージョン？」
- 「この結果、どのコードで出したんだっけ」。
痛みを味合わないと人は学ばないんだなあという気持ちになります。（白目）
試行錯誤が多くなるPoCのフェーズでは実験管理を行わないと実験の比較やNextActionの決定など、開発のPDCAを回しにくくなります。
管理ツールとしてHydra, MLflowが紹介されています。このへんは好みがある部分ではありそうなのと、時代で変わる部分かなと思います。（僕は最近はtyro, wandb使ってます。）
大事なのは、パラメータをどう管理し、実験の再現性をどう担保し、継続的な改善開発をどう回していくかという観点です。データマネジメントと合わせて運用フェーズの土台となる部分になると思います。
第6章
実際の業務では、開発しているものをクライアントにすぐ見せられるわけではありません。本番システムとして完成するまで、動きがイメージできないクライアントも多いです。「モデルの精度が上がりました」と言われても、それが実際の業務でどう役立つのかピンとこない。そんな状況は珍しくありません。
だからこそ、検証してきたことが実際にどう業務に取り入れられるのかを「動くもの」として見せることが重要です。Streamlitなどのプロトタイプがあれば、「こういう入力をすると、こういう出力が返ってくる」という体験をクライアントに提供できます。実際に触ってもらうことで、「ここはもっとこうしてほしい」「この情報も一緒に見たい」といった具体的なフィードバックが得られます。
その結果、プロジェクトの方向性を早い段階で修正できます。本番システムを作り込んでから「思っていたのと違う」と言われるのは避けたいです。プロトタイプの段階で認識を合わせておけば、そうしたリスクを減らせます。
こういった、どうわかってもらうのか的な章があるのも、開発の方向性を都度確認するような苦労が著者の皆さんにもあったんじゃないかと推察でき、実務のリアルを感じました。
おわりに
個人的には第2章~第3章で刺さる部分が多く、パラパラと読むだけでも勉強になる部分が多くありました。私自身、これまでの業務が分析などPoC中心であったりチーム開発の経験が乏しかったりするので、そういった部分で参考になる書籍となっていました。
読み終えて改めて感じたのは、書かれている内容の普遍性です。
紹介されているuvやStreamlitも、数年後には別のツールに置き換わっているかもしれません。
しかし 「なぜ環境構築が大切なのか」「なぜコード品質を管理するのか」「なぜ実験を記録するのか」「なぜプロトタイプを見せるのか」こうしたエッセンスは、プロジェクトを進めるうえで重要な考え方で、そこが大きく変わることはありません。
これからのデータサイエンティストは、データを分析するだけでなく、本番で運用し、価値を届けられることが求められます。本書を読むことで、プロジェクトを進めるために必要な技術の全体像を把握し、前後の工程のメンバーと協働する目線を揃えるための一歩となります。まさに、実務で生き抜くためのきっかけを与えてくれる本だと感じました。
新人データサイエンティストはもちろん、経験がある人が改めて読んでも学びが多い内容だと思います。
本書をきっかけに、他の技術書に興味を持つこともできると思います。
体系的なので自分が何を知らないのか、無知の知に気づくことができる良書でした。
Discussion
著者です！
丁寧に読み込んでくださったのが伝わってくる、熱量のあるブログでとても嬉しいです！
ありがとうございます！