寿命の短いデータ分析コードにも、ちょっとだけ優しくしてあげたい話 / kindness-for-short-lifespan-codes

2025-04-22 CHUO_Tech #7 データ分析について語ろう！
https://chuo-tech.connpass.com/event/350259/

Transcript

1. 寿命の短いデータ分析コードにも、 ちょっとだけ優しくしてあげたい話 CHUO_Tech #7 データ分析について語ろう！ (2025-04-22)
2. 自己紹介 • 品原 悠杜（@snhrytdesu） • データエンジニア@マイベスト ← データサイエンティスト@アイデミー ← ネットワークエンジニア@某N◯T ← 九州大学 • 日本に200人ぐらいしかいない名字 • Dataformの呪縛に囚われている人 → 1
3. データサイエンティストやアナリストのコードの多くは短命 スピード > 保守性になるケースがしばしば。そもそも、寿命の長いコードを書くことが求められていないことも データサイエンティストとエンジニアがチームプレイでいい感じにプロダクトをつくるためには? - なんちゃってClean Architectureとテストを添えて https://x.com/tetsuro731/status/1761354224624111732 今回のLTで 話す領域 2
4. しかし、コードを再利用したくなる場面はなんやかんやある データを更新してもう一度結果を見たい、引き継ぎ etc. そんなときに起こりがちな事故・・・ • 動かない • Pythonバージョン・ライブラリバージョンの 不整合はよくある。ありすぎる • pandas, scikit-learn, shap あたりは特に出会う印象 • 動きはするが意図していない挙動になる • ライブラリのメジャーバージョンアップによる デフォルト引数の仕様変更 • コードが読めない • コードが見つからない ←論外 max_features はscikit-learn 1.1 以降ではエラーになる 3
5. 論点: どこまでコードの保守性を追求するか • 当然、保守性は高いに越したことはないが、 追求しすぎて分析やモデリングのスピードを損なってはならない • かといって、保守性を一切考慮しなくていいわけではない • 保守性を担保するために採用する技術にチームが精通しているか？ → いろいろなバランスが重要 4
6. 寿命の短いデータ分析コードであっても 個人的に実践しているちょっとした優しさ ※1 データ分析のコード = Pythonで書かれている前提で話を進めます ※2 クラウドへのデプロイを伴うようなものは今回のスコープからは割愛します（寿命がそこそこ長いので）
7. 私はやっているし、やらないと怒ること • ソースコードのGit管理 • .ipynb だったとしてもGit管理したい • 仮想環境の準備 • Pythonバージョン管理 • ライブラリのバージョン管理 uv で全部できます （uv init で自動的に .git ディレクトリも作られる） 6
8. 私はやっているけど、やらなくても怒らないこと • Formatting & Linting • 爆速の Ruff を pre-commit 経由で使っている • これを使ったからといってスパゲティコードは 解消しないのでそこは注意が必要 • タスクランナーの準備 • Docker や uv を使うと、実行コマンドが uv run streamlit run src/hello.py みたいな長ったらしいコマンドになりがちなので make run で済むようにしたい • make でも just でも task でも。そこはこだわりなし make をタスクランナーと呼ぶことをお赦しください • READMEをひととおり書く（LLMに書かせる） • 型アノテーションつける 7
9. 私はやっていないこと • テスト • LLMで幾分ラクになったとはいえ、データ分析・機械学習の「ついで」の範疇は 超えている気がしてしまう • そもそも、テストに明るくないが故やりたくてもスキル的にやれていない部分も・・・ • サードパーティーツールを使ったちゃんとした実験管理 e.g. MLFlow • 共用する場合、インフラどう準備する？等の観点もあるので、 困るまではNotebookベースの実験管理でも問題ないと思っている • 厳密な型チェック e.g. pandera • やってる人のほうがレアだとは思うが・・・ • CI/CD • Formatting & Linting をここに担わせる場合があるが、個人的には pre-commit でローカ ルの時点で修正までやってしまいたい 8
10. やっていないが、今後やっていったほうがよさそうなこと 開発エージェント向けのドキュメントの整備 • .cursorrules, copilot-instructions.md, codex.md など • 単一のコードに特化したものを整備しようという話ではなく、前述の 技術を採用する際に使い回しが効くgeneralなものを整備しようという話 • 「それって保守性とは関係なくない？」→ そうとも言い切れない • uv を使っているときは pip install じゃなくて uv add するよう指定する、 コマンド実行は仮想環境内で uv run するよう指定するなど • 新しい or マイナーな技術になればなるほど、LLMが「よしなに」やってくれない 9
11. まとめ • 寿命の短いデータ分析・モデリングのコードを書くときであっても 実践している「ちょっとした優しさ」を紹介しました • これから実践してみたい人には uv + pre-commit の組み合わせオススメです • 中には「その気遣いいる？もっとスピード優先しなよ」と感じた人も いるかもしれないですが、ルーティンとして染み付いてくれば特段 スピードを損なうことはありません • まだ見ぬ未来の誰か（自分も含め）に感謝されるようになろう 10
12. 最後に宣伝 • データサイエンティスト・データエンジニア両職種ともに積極募集中です • DSチームにてNoteマガジンをだいたい月1〜ペースで更新しているので、 ぜひフォロー＆Likeをお願いします！ 11
13. ご清聴ありがとうございました