株式会社FLINTERSの和泉です。
FLINTERS BLOG Advent Calendar 2025 6日目の記事です。
今期私が所属するチームでは、数千行のクエリをSparkのコードに置き換えることに取り組みました。
機械学習のモデリング、予測に利用する特徴量をTreasure Dataで生成しているのですが、クエリの長大化が開発のボトルネックとなっていました。
そのため人間が理解できるサイズまでクエリを解体し、単体テストができる状態を目指しました。
その際、チームで「やらないこと」を決めたのが良かったよ、というお話です。
数千行のクエリの問題点
読めない
何度かクエリを読もうと挑戦したのですが、途中で追いきれず、挫折しました。
(SELECT *があると一気に追うのが辛くなります。)
読んだところで覚えてられませんしね。
処理のトレースが困難で、今の特徴量が意図通りに処理されているのか不明です。
クエリのレビューも不可能です。
変更できない
どこに影響があるかわからないので、クエリ自体の改修が難しい状態でした。
特徴量を試行錯誤しながら、トライアンドエラーを繰り返して精度を上げていくという特性を持つ、機械学習プロジェクトには都合が悪い状態になっていました。
自分の認知の限界に挑戦！
総じて、ツラいです。
やらないことを決めた
作業を進めていく中で、「やらないこと」を方針としてチームで決めていきました。
チーム内での意識が統一されて、進行がスムーズになったと思います。
以下の理由から現行のクエリの処理手順を完全再現することを放棄し、参考にする程度にとどめました。
- 意図通りの処理が行われているかわからない
- クエリが作成された当時の仕様と現在の要望が合致しているか不明
- 複雑で長いクエリはトレース困難でクエリ再現のコストが高い
代わりに作成されている特徴量の仕様を再度定義し、実装することとしました。
結果、現行のデータと仕様が変わる可能性がありますが、利用者へ説明を行なって合意を得ることにしました。
チームでコードを書き始めときに型パラメータを使って抽象化を試みたのですが、うまくいきませんでした。
そもそも具体的に「何を作っているのか」が見えていない段階では、適切な抽象化は難しいです。
「まずは完成させる」を目指すことにして、一つ一つ実装していくことにしました。
解体してどう変わったか
処理内容が理解できる
特徴量ごとにコードが分割できたため、人間が理解できるサイズに収まるようになりました。
安全に変更ができる
コードを個別に実行できるようになったため、単体テストを行えるようになりました。
すべての特徴量の処理コードに対して、単体テストがあるため、細かい変更を入れやすくなりました。
まだ道半ばですが、やって良かったなーと感じています。
まとめ
「やった方がいいこと」は無限にあるので、全部やってると終わらないんですよね…(リファクタリングとか)。
まず終わらせるのは大事で、そのために「やらないこと」を決める、チームで共通認識を持つのは有効だなと感じました。
ただ、そのまま放置してしまうとまた負債が積み上がっていくので、いつ整理するの？という判断は必要です。
Tidy First
なんとか一個を解体しただけなので、まだまだ先は長いです。
できることを一つずつやっていこうと思います。
読んでいただきありがとうございました。
和泉
Discussion