はじめに
前編では、バフェットコードの起業後も、週1の副業(メルカリ・さくらインターネット)を続けている理由について書いた。経済的なリスクとエンジニアキャリアのリスク、その両方をヘッジするためだ。
少し間が空いてしまったが、今回は前回書くと宣言した
- 具体的なバイトの仕事内容
- バイトで大変なこと・気をつけていること
について書いていく。なお、今回も「副業」という言葉は使わず、「バイト」という言葉を使う1。
業務内容
メルカリでやっていたこと
前回も触れたが、ぼくはもともとメルカリの正社員としてデータプラットフォームを作っていた。退職の次の週からバイトを開始したので、「やっていたこと」というのは「正社員の頃にやっていたことの続き」そのものである。
2019年当時の技術スタック
ちょうど(正社員を)辞めた2019年の夏に作っていたストリーム/バッチパイプラインについて、それぞれブログ記事があるので、それを引用しておく。
engineering.mercari.com engineering.mercari.com
詳細は上記の記事に譲るが、当時の主なデータプラットフォームチームの持ち物は以下のようなものだった。
- Cloud Dataflow (Apache Beam)を使ったストリームパイプライン
- Cloud Composer (Apache Airflow)を使ったバッチパイプライン
2024年までの変遷
ぼくが(バイトを)やめた2024年3月には、技術スタックは大きく変わっていた。ストリームパイプラインはApache Flink Kubernetes Operatorを使ったApache Flinkのアプリケーションに、バッチパイプラインのオーケストレーションツールもArgo Workflowsに移行していた。簡単に言えば、よりメルカリの社内標準に則った、Kubernetesネイティブな環境での運用が主流になっていたわけだ。
ある意味では当然だけど、全くの新規開発、たとえばCDC2のようなものは特にお手伝いすることなく、DataFlowで書かれた(というか自分で書いた)パイプラインのFlink移行や機能追加、AirflowのDAGのArgo Workflowsへの引っ越しの仕込みなどが主な業務だった。もちろん、移行にはそれなりに時間がかかるものなので、レガシーなDataFlow / Airflowのパイプラインのメンテナンスも担当した。
さくらインターネットでやっていること
一言で言うと、モニタリングスイートのログ領域を担当している。
これについては、@kamijin_fanta氏の以下の発表資料がわかりやすいのでぜひ一度読んでみてほしい。
一言で言うと、Apache KafkaとApache Iceberg、Apache Trinoを使って、ログをリアルタイムに処理して、クエリできるようにする仕組みを作っている。
ここではあまり詳しい話はしないが、特に工夫している点としては「Icebergは並列・分散処理でcommit操作をするとパフォーマンスが著しく下がる」という弱点があり、それを回避するために
- Parquet fileをobject storageに保存するLoader
- Icebergのテーブルの状態を変更するCommitter
のプロセスをわけていることだ。「ここまでやる必要あるのかな・・・?」と思いながら作り込んでいたが、ほぼ同じアプローチをApache Iceberg Sink Connectorでも行っていた3ので、だいぶ勇気が出た。
バイトで大変なこと・気をつけていること
上記のバイトいずれも、ぼくは「本番環境でガッツリ運用される」タイプのコードを書いている。週1の業務委託でこれをやるのは、仕事を頼む方も頼まれる方もそれなりにリスクを背負っていることになる(と思う)。フルタイムで働くとき以上に気をつけていることがあるので、それについて書いていく。
コンテキストスイッチとやる気
ぼくの場合、本業とバイトでは技術スタックが全然違う。言語もフレームワークも違うし、もっと言えばインフラも違う4。木曜日(バイトの日だ)は、何としても朝イチで「昨日までの仕事」を一旦忘れて「今日の仕事」を始めないといけない。なによりこれが一番大切だ。
ぼくは(多くのソフトウェアエンジニアがそうであるように)「やる気」でパフォーマンスが大きく変わるタイプの人間なのだが、これは週1のバイトではめちゃくちゃ問題になる。週5日、1ヶ月20日稼働していればそのうち数日調子が悪い日があってもそれほど問題にはならないが、週1のバイトで「今日はちょっと乗らないな〜」みたいになったら取り返しがつかない。
木曜朝のコンテキストスイッチが軽いことが、非常に重要になるので
- SlackやGitHubは日頃からそれなりに目を通す
- 木曜の朝は、何より先にバイト用の開発環境を立ち上げる
この2つを徹底している。
そして、どんなに小さなPull Request(PR)でも、1つは作ってからお昼ご飯を迎えるようにしている。「コードを書き、コミットし、PRを作る」という流れを午前中で作ることが、週1バイトでまともにアウトプットを出すために重要だ。
週1でも開発の効率を落とさないための工夫
週1開発で最も厄介なのが、その日のPull Requestがマージされないと致命的に停滞してしまうことだ。 木曜にマージされなかったPRは1週間放置されるため、その間にmainブランチは進み続ける。 手元のブランチとの差分が広がるほどコンフリクトの確率は上がり、解消も困難になる。 PRを出来る限りシュッと5レビュー・マージをしてもらうことが非常に重要になる。
そのために最も効果的なのは、結局のところ、ソフトウェア開発のベストプラクティスを徹底することだ。 以下では、特に意識していることを書いていく。
テストとコメントをちゃんと書く
最も重要なのが、単体テスト6をしっかり書くことと、コード内にコメントをちゃんと書くことだ。
テストは「このコードが何をするのか」を示す、最も正確で実行可能な仕様書だ。 レビュアーはテストを読むことでコードの意図を理解でき、動作の正しさも確認できる。 結果として、レビューの負荷が下がり、PRが早くマージされやすくなる。
週1稼働では、ほとんどのシステムの運用を正社員の方にお任せすることになる。 単体テストは仕様書そのものであり、「このコードが何を意図しているのか」を最も正確に記述したドキュメントになる。同じ理由で、コード内にコメントをちゃんと書くことも非常に重要だ。
コードの見通しを良くする
簡単に言うと「なるべくきれいにコードを書く」ということなのだが、特に クラスやモジュールの責務分離とDependency Injection(DI)を徹底している。
責務が明確に分離されていれば、変更の影響範囲が明確になり、レビュアーは安心してコードを読める。「この変更は他の部分に影響しないか?」という不安がなくなり、結果としてPRが早くマージされる。また、責務分離はコンフリクトの確率を下げる意味もある。発生したとしても、適切に分離されていればマージの手間とやらかしのリスクは最小限に抑えられる。
一方、DIは「単体テストを書きやすくする」という恩恵が大きい。データ処理基盤のコードは今も昔もいわゆるETL(Extract, Transform, Load)であり、EやLは当然他のコンポーネントに依存する。IOのmockのしやすさは非常に重要で、DIを徹底することでこれが容易になる。
PRは小さく、説明を丁寧に書く
小さなPRはレビュー負荷が低いため、早くマージされやすい。 大きな機能を作るときも、なるべく細かく分割して、少しずつPRを作り順次レビューしてもらう。
PRの説明には「なぜこの変更が必要なのか」「どういう設計判断をしたのか」を丁寧に書く。 レビュアーは背景を理解した上で素早くレビューでき、週1でほとんど不在の自分の代わりに、問題が起きたときも適切な対応をしてもらいやすくなる。
レビューの単位とマージの単位を分けるという工夫も大事だ。レビューは細かい単位でしてもらいつつ、マージの単位がもう少し大きい方が良いようであれば、複数のfeatureブランチをまとめた大きめのfeatureブランチを切って、意味のある変更の単位でマージしてもらう。こうすることで、レビューのスコープを小さく保ちつつ、「意味のあるシステム変更の単位」でコードをマージすることができる。
繰り返しになるが、これらは別に週1のバイトに限らず、ソフトウェア開発における基本的なベストプラクティスだ。そういう意味では、フルタイムで働く場合に比べてむしろ「ズルができない」と言ったほうが正しいのかもしれない。
最後に、でんぱ組.inc THE ENDINGについて
前編で、
最終的に、副業をきっかけにでんぱ組.inc熱が再燃、2024年に久しぶりにみりんちゃんとチェキを撮り、そして"でんぱ組.inc THE ENDING"現地参戦に至ることになるのだが、そのお話はまた後編で。
起業と副業とでんぱ組.inc（前編） - きっと、ずっと、会議は踊る
と書いたので、最後にでんぱ組.incのお話をしてこのエントリを締めくくろうと思う。
一言で言うと、👇️が全てである。
でんぱ組はずっと昔に他界してたんだけど、バイト先の若者の話を聞いてたら興味出てきて、久しぶりにライブ行ったらめちゃ良くて、結局エンディングを現場で見届けることにした。
— しゅう / Shu Suzuki (@shoe116) 2025年1月5日
楽しくヲタクするには運命的なアレがある程度必要だと思ってる。
なお、前述の@kamijin_fanta氏はぼくよりだいぶ若い（ちなみにぼくは古川未鈴さんと同じ年である）のだが、かなりきちんとしたでんぱ組.inc（というよりディアステージ界隈）のヲタクであった。 さくらインターネットはフルリモートの会社であり、@kamijin_fanta氏ともしばらく物理的に会ったことがなかったが、我々の初の対面は聖地秋葉原ディアステージにおいてであり、その後これまた聖地Club Mograのオールナイトイベントに向かったのであった7。
さて、今日は当然こちらの曲でお別れです。 www.youtube.com
