金曜深夜2時半、ヒルトン小田原
家族で来ている。花金だ。
なのにロビーのソファでMacを開いている。BigQueryのバッチジョブが終わらない。推定残り時間、100時間。
100時間。4日以上。やり直した方が早い。
問題はわかっていた。並列度の調整、クエリのJOINパターン最適化、クラスタリングテーブルの活用。手は見えている。どの手を打つか、どの順番で打つか。それを考えていた。
2時間、同じ高度をぐるぐる回っていた。
5分で終わった
AIに投げた。プロジェクトのコードベースを読ませて、状況を伝えた。
返ってきた構造整理はこうだった。
9つのエリアを並列処理しているが、1つだけデータ量が桁違いに大きい。そのエリアで重いクエリを走らせると、他の数倍から数十倍の時間がかかる。
9エリアを均等に並列化しても、その1つが律速になって全体が引きずられる。
解は単純だった。重いエリアを隔離する。
そいつだけ時間帯分割で別ジョブにする。残りは並列一括で数時間で終わる。クエリのリライトは来週でいい。
5分だ。2時間潜っていた問題が、5分の構造整理で消えた。
葉脈が見えすぎる
なぜ2時間も潜っていたのか。
クエリの書き方を変えれば処理量を8割減らせることを知っている。テーブル設計を変えれば安定動作することも知っている。並列度を上げたときのリソース争奪の挙動も、プラットフォーム側の上限値も、頭に入っている。
葉脈が全部見えるから、葉脈の中で最適解を探してしまう。
クエリを1本書き換えれば10%速くなる。並列度を調整すれば15%速くなる。テーブル設計を変えれば8割のコスト削減。どれも正しい。どれも「中の話」だ。
一歩引いて「そもそも処理の構造自体を変えるべきでは」という問いは、葉脈の中からは出てこない。
「戦略の人」と「実装の人」が分かれていない
普通、組織には2種類の人間がいる。森を見る人間と、葉脈を触る人間だ。
マネージャーが「全体最適を考えろ」と言い、エンジニアが「このクエリを直します」と答える。視座の切り替えは、人と人の間で自然に起きる。
全領域を一人で回すと、この切り替えが全部自分に乗る。
SQLを書いている脳は「この行をどう直すか」を考えている。戦略を練る脳は「そもそもこのジョブは必要か」を考えている。同じ人間の中で、この2つの脳を切り替えなければならない。
しかも厄介なことに、葉脈は快楽だ。手を動かせば進む。進む実感がある。目の前のクエリを1つ直すたびに、小さな達成感がある。
森に戻るには、その快楽を自分で断ち切る必要がある。
仕組みで引き戻す
意志の力で視座を切り替えるのは、再現性がない。深夜2時半に疲弊した頭で「一歩引いて考えよう」と思えるなら、最初から2時間も潜っていない。
だから、引き戻す仕組みを持つ。
今夜の場合、それはAIだった。コードベースを5分で読み、構造を整理し、「重いエリアを隔離すれば？」と返してきた。
重要なのは、AIが正解を出したことではない。「一歩引いた視点」を強制的に挟んだことだ。
葉脈に潜っている人間に足りないのは、知識でも能力でもない。引きの視点を入れるタイミングだ。
壁打ち相手でも、コーチでも、AIでもいい。「潜ったら投げる」を仕組み化する。視座を上げるのは能力ではなく、習慣だ。
戦術で10%削るより、戦略で90%消す
100時間のジョブを前に、並列度を4から9に上げるか悩んでいた。仮にうまくいっても、せいぜい40%の短縮だ。それでも60時間かかる。
重いエリアを隔離するだけで、残りは数時間で終わる。重いやつだけ時間帯分割で個別に回せばいい。全体の処理時間は1/10以下になる。
同じ2時間を使うなら、戦術を磨くより、戦略を変える方に使え。
葉脈に潜る力は武器だ。全領域を一人で触れることは、替えの効かない強みだ。だがその武器が、自分を葉脈に縛りつける鎖にもなる。
潜れることと、潜り続けることは違う。
潜ったら、一度浮上しろ。浮上の仕組みを、あらかじめ作っておけ。
森は、葉脈の中からは見えない。