JX通信社シニアエンジニアの@shinyorkeです.
最近はチームの朝会でよく着ているTシャツにツッコミを受けてます.*1
JX通信社では, いい感じにデータを整備・運用しているデータ基盤を駆使して,
- BI(Business Intelligence)文脈でのデータ分析・可視化. ダッシュボード作ったり.
- 機械学習的なアプローチを使ったR&Dと機能開発(分類タスクなど)
といった業務・タスクを社員・インターン問わず行っています.
データ分析でSQLを書いたり, 「新しいアルゴリズム試すやで!」的なノリでPythonのコードをゴリゴリ書く・動かして結果を見て振り返ってまた臨む...って楽しいですよね.
チームの皆さんも, もちろん私もモチベーション高くやってるわけですが!?
あれ, notebookどこ行ったんや...🤔
よくありますよねー(震え)
自分もチームメイトも, 前のめりになって分析なり機械学習なりをやればやるほど, notebookはどこかに溜まっていき, 「そういえば前にやったnotebookどこだったっけ?🤔」ってなります.
これはきっと私(弊社)に限らずあるあるな問題だと思います.
また, 分析業務や機械学習的なR&Dなどをたくさんやればやるほど,
ワイのコード, 大丈夫だろうか(震え)
と心配になります.
このエントリーでは, 散らかったJupyter notebookを片付けるの諦めたもっとカッコよくいい感じにナレッジをシェアしながら分析したい私が,
- JX通信社のデータ分析環境の今とこれから, を紹介しつつ
- 結局, 分析屋さんのコードレビューとnotebookの管理って何のためにするんだったっけ?
というお話をいい感じにまとめて書きたいと思います.
TL;DR
- モブプログラミング的なノリでレビューするとノウハウの共有・お互いを知る意味でも最高なのでオススメ(オンラインでイケる).
- notebookの管理で神経と労力を使うのもいいけど「諦める」のも一つの手.
おしながき
JX通信社のデータ分析環境と作業スタイル
早速コードレビューの話をする...前に, JX通信社における
- データ分析ってどういう環境でしてるの?
- 現状の問題点
の話をサクッと整理しました.
なお, このエントリーの続きみたいな話です.
現在の環境
社員・インターンがデータ分析に使っている環境は, 以前のエントリーに触れたとおり, BigQueryを中心に回っています.
(一部のデータ*2を除き)大抵のデータはBigQueryのテーブルとして存在するので,
- 単にデータを見たいだけ(≒SQLで事足りる)ならBigQueryのコンソール・Redashを使う
- 機械学習や統計でちょっと凝ったことをする(≒コードを書かないと難しいタスク)ならColabを使う*3
- ダッシュボード・レポート等の最終成果物をDataPortal, Redashで行う
といった感じで活用しています(+他のツール・サービスもよく使います*4).
ちなみに手段(ツール・サービスなど)の選択は原則として各人(社員のみならずインターンも対象)に任されています(メンターとしても必ずその話をしています*5).
なお, データの抽出・変換・出力, いわゆるETLについてはAirflow, prefect(一部Luigi)でWorkflowを組み立てて行っています.
ETLの詳細は以前のエントリーをご覧いただけると幸いです(本筋と離れるためこのエントリーでは特に触れません).
現状の課題とやりたいこと
ビッグデータ・データサイエンスのエコシステムの組み合わせでいい感じに分析したり成果出したりと一見すると順風満帆に見えるこの仕組ですが, 課題とやりたいことがいくつか存在します.
- 現状の課題
- やりたいこと
- データマートの整備. 現状は「データレイクの生ログをいい感じにBigQueryにしました」的なデータを扱うことが多いためそれなりに難易度が高い*8.
- ある程度の分析・可視化(select文の結果をピボットしてグラフ描く的な)をデータサイエンス・エンジニアな人以外にも開放. つまり民主化.
「やりたいこと」の話は後日機会あれば紹介ということで一旦さておいて.
データ分析に関わってるメンバー特に若い人やインターン達にとって不安要素になるかもしれない「コードレビュー」「notebookの管理」は無視できない問題です.
コードレビューとnotebook管理をいい感じにする
「コードレビュー」「notebookの管理」という課題に対して, 会社全体としてどうしていくか?...という問いについてはまだ答えが出ていないのですが.
私(@shinyorke)のチーム*9では,
- notebookやSQLをモブプログラミング形式で作ったりレビューをしたりする
- notebook, SQLはあくまで「中間成果物」と捉え, 敢えて管理を放棄する
という方策でやっています.
モブプログラミングの積極活用
「チームで一つになってISSUEと向き合う」でお馴染みのモブプログラミングですが, これをデータ分析チームとして積極活用しています.
実際は対面じゃなくて, Zoomで一つの画面をシェアしながらやってます(みんなリモートしてる*10ので)
モブプログラミングのお題は「インターン生が書いたnotebook/SQLのレビュー」「メンターのshinyorkeがまとめたレポートのレビュー」などその日によって異なりますが大切なのは,
インターンや若い人が時折レビュアーに回る
ようなローテーションを回すようにしています.
私の場合, プログラミングそのものやシステム的・ビジネス的なスキル・知見は若い人よりありますが, 数学・統計・機械学習的なアプローチは現役で学んでいる学生さんの方が上だったりするケースも多々あるので「私もたまには見てもらう側に回る」ようにしています.
若い人やインターンの場合は「プログラミング・SQLの定石」「きれいなコードの書き方」「Pythonの便利ライブラリ」などが勉強になるケースが多いみたいです. つい先日は「コード・SQLをフォーマットして書くのが何故大事か?」という話題で30分くらい時間が溶けました*11.
この方式はそれなりに労力を使いますが, 成果物の最終チェックが進むだけでなく「関わった人の知見・スキルのシェア・勉強がはかどる」「個々人のノウハウがチームに還元される」のと何よりも楽しいので今後も継続していく感じになると思います.
notebookはあくまで「中間成果物」
そして 「散らかったnotebook」問題ですがこれについては,
すっぱり諦める
というお気持ちでやっています.
というのも,
- notebookはあくまでもアドホックな「らくがき帳」「試行錯誤するためのサンドボックス」である*12
- 「よっしゃこれはイケるぞ!」ってなった段階でちゃんとしたプロダクトのコード(テストコードを含める)に落とし込むべき
- (notebookでdiffをとるソリューションはいくつかある*13とはいえ)神経質にdiffを気にするぐらいなら最初から管理そのものを放棄したほうが良い.
これらの定義・信念を考えると「わざわざ管理する方にもっていくのはまだ先でいいかな...」ってなります.
もちろん, 安易に消されたりやってくれた方が退職したりするとそれはそれで困ってしまうので,
- 可能な限り社内限定でシェアする. 少なくともメンターの手元には残す.
- 「もしかするとプロダクトコードになるかも」なスニペットはgitに残す
ぐらいはしています.
結び - レビューとメンタリングで大切なこと
というわけで,
分析者のコードレビューには「モブプログラミング」を, notebookの管理は「諦め」が肝心
という話を紹介させてもらいました.
もちろんこの両方が絶対的な答えじゃないです, もっといい方法・考え方があったらぜひフィードバックをいただけると幸いです.
このアプローチ・考え方に至るまで色々と試行錯誤をしたのですが確かなのは,
- レビュアーはプロダクト・サービスの事に目を向けつつ, レビュイーの良い学び・気付きになるようなレビューに心がける
- メンターはメンティーにとって「超える壁」になるようなタスクを提供し続け, メンティーの成長を支えること
という想い・思考が元になっています.
なお現在JX通信社では,
- データサイエンティスト ※本日(11/18)より募集開始しました
- フロントエンドエンジニア
のインターンを募集しています!
※学生さん限定です🙇♂️
データサイエンスのコードレビューはこのエントリーで触れたとおりですが, エンジニア側もメンターやチームによっていいかんじにケアしたりしてるので興味ある方はぜひカジュアル面談にお越しください(フルリモートでもOKです!).
最後までお読みいただきありがとうございました.
*1:アカウント名(shinyorke)をUKの某バンドのボーカルから拝借する程度にUK Rock🎸好きな影響でいつもバンドTシャツ着てます(どうでもいい注釈).
*2:本文脈とは関係ないですが, 一部のデータはAWS AthenaだったりS3/GCSのストレージ上の生データです.
*3:後述の通り, Colabはマストって訳ではないので個々のPCで環境作ってやるケースもあります, 私が実はその派閥でして
*4:私の観測範囲ではGCPのAI Platformを使ったり, まだお試し中ですがstreamlitを使うこともあります.
*5:弊社はデータサイエンスのみならず, 通常の開発でもPythonを使うことが多く分析業務のデファクトスタンダードもPythonですが中にはRでタスクをこなしてバリューを出しているメンバーもいます.
*6:よくやる処理とか定石が車輪の再発明になってる的な意味での「資産活用が難しい」という話です
*7:余談ですがFASTALERTやNewsDigestといったプロダクトはこの辺しっかりやってます.
*8:正規表現頑張ったりJSONをParseしたりとかそういうレベルの難易度の高さ. もちろん仕様の話もあります.
*9:言い方を変えるとこのアプローチは会社オフィシャルでテンプレート化しているわけではないです&したいなっていう欲はあります.
*10:これはこれで苦労もありますがシフトや働く場所の成約が物理出社の時と比べて334倍以上の自由度があるので良いことのほうがおおい気がします. 首都圏以外の学生さんもインターンとして定期的に入れるとか.
*11:どのツールを使うか, 他社さんでどうやってやっていたか?という話題でもちきりになりました. お互いを知る意味でも有意義な30分でした
*12:notebookをバッチなどの定期実行処理にそのまま使うやり方もあるらしいですが個人的にはこのアプローチはとったことないです.