Findy Engineer Lab

エンジニアの"ちょい先"を考えるメディア

よりよい開発体験を求めて─ OSSと本業であるインフラエンジニアの二軸を生かし、自らの力で組織の開発力を向上させる

ファッション通販サイト「ZOZOTOWN」の開発・運用を担うZOZOテクノロジーズでは、2004年の設立から使われ続けてきたモノリスなアプリケーションをマイクロサービス化するとともに、オンプレミスからマルチクラウドへと大きなシステムのリプレースを進めています。

その中心でMLOpsやSREといった基盤の構築を担う瀬尾直利@sonots、そのっつ)さんは、インフラエンジニアとして事業にコミットしているだけでなく、CRubyやFluentd、Chainerといったさまざまなオープンソースソフトウェア(OSS)のコミッターという顔も持っています。

瀬尾直利さん

一貫して「開発体験の良さ」を追い求めてきた瀬尾さんの中で、プロジェクトの課題を解決する業務と、OSSコミュニティにおけるプライベートの活動はどのようにシンクロしているのでしょうか。キャリアの軌跡を振り返りながら、2つの軸を生かしたソフトウェアエンジニアのあり方について伺いました。

基盤構築を通じてZOZOTOWNのリプレースを支援

── 瀬尾さんはZOZOテクノロジーズに2019年1月の入社で、現在はMLOps(Machine Learning Operations)とプラットフォームSREという2つのチームのリードということですが、ともに瀬尾さんが入社してから立ち上がったチームですよね。

瀬尾 はい。まずMLOpsチームは、私がゼロから作って2019年4月に立ち上げました。このチームでは、ZOZOTOWN本体に提供するML APIをマイクロサービスとして開発しています。

ただプロジェクトを進める中で、たくさんML APIを作ってもZOZOTOWN本体の開発効率が上がらないと、機能として本体に組み込んでユーザーに届くまでに時間がかかってしまうという課題が見えてきました。そこで、リプレースプロジェクトにも関わりたいと相談して、もともとリプレースを進めていたチームと合流する形で2020年4月に「プラットフォームSREチーム」を立ち上げました。

── チームのリードとは具体的にどういった仕事なのでしょうか?

瀬尾 一般的にリーダーに求められる役割は3つあると思います。1つは、調整ごとなどプロジェクトマネージャーとしての役割。2つ目は、チームメンバーの育成やキャリアプランを考えるエンジニアリングマネージャーとしての役割。そしてもう1つがテックリードとしての役割です。このうち1つか2つの役割を担うパターンが多いと思いますが、私の場合はこの全てを2つのチームでやっています。

── マネジメントの仕事が増えてくると、開発の現場に直接コミットすることも少なくなりますよね。

瀬尾 自分自身で手を動かす場面は最近かなり減りましたが、後追いでもレビューだけは全部に目を通すようにしています。マネジメントの役割だけでなく、システムも分かっているリーダーでありたいので。まだまだ若い者には負けんよという気持ちはあるかもしれませんね(笑)

── 先ほどの話に戻りますが、ZOZOTOWN本体の課題とは何だったのでしょう?

瀬尾 ZOZOTOWNのリプレースはモノリスtoモノリスの形で進んでいたのですが、かなり巨大なシステムだったため、何かリリースするにも順番待ちせざるを得ない状態でした。それならば、あまり密に連携を取らなくてもいいようにマイクロサービス化し、API仕様を決めて、それぞれ個別にリリースできる仕組みにした方が開発体験がよりよくなるだろうなということはすぐ想像できました。

ちょうど先行する形で、モノリシックなシステムからID基盤だけを切り出すプロジェクトや、検索機能をリプレースするプロジェクトが進んでいたので、これをマイクロサービス化しつつ、リプレースプロジェクト全体も同じ方針で進める方がいいと提言した形です。

── ZOZOTOWNも歴史の長いサービスなので、リプレースはかなり大変そうですね。

瀬尾 そうですね。かれこれ16年くらい運用されてきたものなので、かなり巨大です。巨大であるがゆえに、コードを書き換えた先で新しいビジネス要件が浮上するたびにリプレースプロジェクトのチームが対応に呼び出され、リプレース作業が止まってしまうという状態になっていたので、その体制も含めて変えようとしています。

── いつごろ完了する見込みですか?

瀬尾 プロジェクトを進めていくとまた新しい課題が見えてくるという感じなので何とも言いがたいです。このプロジェクトは、マイクロサービスプラットフォームとしてリプレースを終えたら完了だとは思っていません。開発者の開発体験が向上して、ビジネスサイクルをより早く回せるようになってはじめて成功だと捉えているので、そういう意味では終わりはないのかもしれません。

Webの世界の「開発体験の良さ」がキャリアのきっかけ

── 瀬尾さんのエンジニアとしてのキャリア全体のお話を伺っていきたいのですが、まず直近の選択としてZOZOテクノロジーズを選んだのはなぜでしょう?

瀬尾 前職(DeNA)にはとくに不満もなかったのですが、入社当時に作ってほしいと言われていたものを汎用的な仕組みとして作りきったし、難易度の高い新しいチャレンジはあらかた片付けてしまったところで、「じゃあ、次に何をやろう」と考えて、もっとインパクトが大きい仕事が残っている会社にいくことを考えはじめました。

── 転職直前のお仕事は、現在のMLOpsというキャリアにもつながっているかと思いますが、深層学習フレームワークChainerの開発に協力されてましたよね。

瀬尾 Chainerの開発自体は非常に面白かったですし、かなり優秀なメンバーが集まっていて刺激になりました。けれどそのときは出向という立場だったこともあり、事業がどこに向かっているのかを把握せずに開発だけをやっている状態には少し違和感がありました。

次はビジネス的にどこに向かっているかを把握し、場合によってはその方向性を考えながら開発したいな、とそのとき思いました。だからフリーランスという選択肢もなかったです。

── 前職でのキャリア全体では主にどんなミッションを担っていたんでしょうか。

瀬尾 基盤作りです。みんなの開発体験をよりよくすることが大事だと考えていて、複数の案件で同時に使える、より使いやすい基盤を作ることがチームのミッションでした。その一環として、インフラのコード化も進めていました。

── ということは、もともとインフラのエンジニアだったんでしょうか?

瀬尾 いえ、会津大学を出て、それからアメリカのメリーランド大学大学院に進学して画像処理関連の研究に携わった後、国内のメーカー系SIerに就職して組み込みエンジニアになりました。向こうで就職しないで帰国したのは、日本食がどうしても食べたかったもので……。

── 最初の仕事は今とずいぶん違っていたんですね。Web系の開発はいつごろからでしょうか?

瀬尾 組み込み機器のソフトウェア開発を担当する中で、2010年ごろWeb関連の開発に携わることになりました。それまでも、個人でホームページを作ってCGIを書いて……ということはしてましたが、仕事として本格的にWebに触れはじめたのがこの時期で、バックエンドのAPIサーバ開発とインフラ構築を担当しました。その流れで、Rubyにも触るようになりました。

── 組み込みとWebではかなり世界が違いますよね。

瀬尾 そうですね、開発体験が非常にいいことに衝撃を受けました。ちょうどアジャイル開発が注目され始めた時期で、Jenkinsを使って自動で単体テストをして、通ったらデプロイするとか。Capistranoなんて自動デプロイツールも出てきて、そういった仕組みに触れてましたね。

組み込み機器って、開発が終わってから半年くらいQAをやって、一回リリースすると、あとはもう一切触れなくなるんですよ。それに、10年前に出たハードウェアでも動作させなくてはいけないので、古いままの技術スタックで開発しなければいけない。

そういう世界と比べて「Webは開発体験がこんなにいいんだ」と思いました。枯れた技術もいいんですが、組み込みだとある程度経験を積むと新しい挑戦がほとんどなかったりもするので、そういった意味でも新鮮でした。

話を聞くだけじゃなく切磋琢磨できる関係になりたい

── Web関連の勉強会に積極的に参加するようになったのもその時期ですか?

瀬尾 組み込み開発の時代にはそもそも勉強会がなかったんです。Webの世界ではけっこう勉強会があることに気づいて、参加するようになりました。

そうしたコミュニティに行くと、いろいろなオープンソースソフトウェアの開発者がいたり、自分で勉強したことを発表している人たちがたくさんいて、とても楽しかったです。2012年に前職に転職したのは、勉強会に参加するだけじゃなくて登壇して話したいということも理由の1つにありました。

── どういった勉強会に参加されていたのですか?

瀬尾 Shibuya.rbには転職前からよく参加していました。けれど、一度も発表したことはなかったんですよ。周りからは、「なんかTwitterのタイムラインにいろいろ流している人がいるな」くらいの認知をされていたらしいです。転職して、それまでできなかった分、一気にたくさん発表をするようになって「あなたがあの人だったのか」ってなりました(笑)

── 参加して話を聞くだけで満足する人も多い中、なぜ登壇にこだわったんでしょうか?

瀬尾 もともとブログのようなものを書いて知見を共有するのが好きな方だったので、その延長かもしれません。それに、聞いているだけだと、そのコミュニティの仲間には入れませんよね。話を聞くだけじゃなくて、対等に話して切磋琢磨できる関係になりたいと思ってました。

── 以前のブログを拝見すると2011年からアーカイブがありますから、今のお話だとメーカー系SI時代からなんですね。ちなみに、それ以前にも何かあったりするでしょうか?

瀬尾 大学時代に遡りますが、自分でデスクトップPCを組み立てて、勉強がてらサーバを立ち上げて、自分のメモを大学と自宅で共有できるようにPukiWikiを使ったりはしてました。PukiWikiはプラグインもたくさん書いてましたね。

── じゃあ、その頃からコミュニティに参加していたんですね。

瀬尾 いえ、そのころは会津にいたので、コミュニティには関わっていませんでした。参加したいと思ってはいたんですができなくて……周りからも「リモートで何かやってる人がいるな」くらいの認識だったんじゃないかなと思います。

── それがOSSに関わる原体験だったかもしれませんね。

仕事とOSSコミュニティの活動、2つの軸を両立させる効果

── その後のコミュニティやOSSでの活動としては、2013年9月にログ収集基盤Fluentdのコミッターになり、2015年12月には先ほどから名前の出てきてるRubyのコミッターにもなっています。そういったプライベートでのソフトウェア開発と、仕事としてのインフラエンジニアではレイヤーも違うと思いますが、どのように両立させていったのでしょう?

瀬尾 業務でやっているSREやインフラエンジニアと、Rubyコミュニティのような開発者コミュニティってちょっと別ではありますが、自分の中にはその二軸があって、両立させてきたと思います。例えばSREとしては、基盤を見るだけでなくアプリケーションコードに手を入れて高速化するといったこともやっているので、そこにソフトウェア開発での知見も生きていると思いますね。

── 確かに勉強会で発表されていることも、2014年あたりから仕事の成果と関連した内容をセミナーなどで報告されていて、本業とコミュニティ活動が次第に合流しているような印象を受けました。

瀬尾 そうですね。自分で自分のキャリアをそうなるように持っていったのはあります。ばらばらだと時間やリソースの配分がどうしても難しかったりしますが、自分が得意としているところで業務ができたらさらに成果が出せるだろうと思っていたので。

最初の部署で関わったFluentdもそうですが、Rubyコミッターになったこともあり、Rubyコミッターとして分析基盤部や会社全体のRuby力の底上げにもかなり貢献できるようになりました。その頃から組織レベルでの発表もするようになりましたね。

── 自分が楽になるだけではなく、会社全体の技術力向上を視野に入れてということですね。

瀬尾 いやー、当時はそこまで大それたことは考えていなくて、自分の働きやすさやキャリアの方を重視していたと思います。けれど結果として分析基盤部を代表していろいろ発表する機会を持ったり、設計段階から関わって作成した基盤を置き土産にすることができました。

仕事に取り組んでいくなかで、自分で楽しいと思えば成果が出るし、そうじゃないと成果が出ないということも体験しているので、「自分がやりたいことと業務をうまくからめられないかな」という戦略を練っていたりはしますね。

── 当時のインタビューで、会社の業務によって「息を吸うようにOSSに貢献している」と瀬尾さん発言されているものがありましたが、具体的にはどういう状態だったのでしょう?

瀬尾 OSSのコードを見て、手を入れて、コントリビューションして、自分達の環境にデプロイするっていうのが当たり前のようにできていたなと思います。プルリクエストを送る前に自分たちの環境で試して、「ちゃんと動いたよ」とコメントしてマージしてもらうといったことまでできていました。チームメンバーには、「何かおかしいところがあってもOSSならコード読めるし、コード読んだ方が解決早いよ」と話していました。

OSSを利用する文化を浸透させて開発体験をよりよくしたい

── 業務とOSS開発の二軸を両立させてきた経験が、現職で「オープンソースソフトウェアポリシー」を策定したこと(2020年7月)に生きているのですね。

瀬尾 そうですね。ZOZOテクノロジーズには最近入ったメンバーがかなり多くて、もともとOSSコミュニティで活動してきたメンバーも増えています。自分も含めたそういうメンバーや、これからOSSをやりたいメンバーにとって、OSS開発しやすい環境を作ることを目標にまとめたのが、このポリシーです。

── 業務用にGitHubアカウントを使い分けるのを廃止したのも、その一環でしょうか?

瀬尾 はい。会社の業務で使うアカウントとプライベートのOSS開発時に使うアカウントが別々に存在していると、使用用途に合わせて都度アカウントをスイッチする手間が発生します。そういった手間を解消するため、アカウントを統一させたいと思ったのが動機の一つです。

── そういった活動をされている背景には、開発にかかわる文化のギャップもありそうですね。

瀬尾 あると思います。これまでZOZOでは、商用ソフトウェアを購入し、それを利用する対価としてお金を払う。そういう形で動かす基盤がけっこう多かったんです。でもFluentdなどのOSSで構築して、しかもプラグインを開発できるメンバーがいれば、それで作れちゃうんですよ。

── 具体的に開発したものはありますか?

瀬尾 うまくいっている例を挙げると、最近作った「リアルタイムデータ基盤」があります。テックブログでも紹介していますが、Qlik Replicateという商用製品を使っていた基盤を、Fluentdベースのものに置き換えました。インフラのコストがかなり減って、しかもいいものができたので、OSS開発の成功体験としていい実例になったと思います。

ただ、OSS文化に触れてこなかったメンバーたちに、これがどういう意義があるのかを理解してもらい、浸透させるには、まだ時間がかかるかもしれません。

── ZOZOテクノロジーズでは、今後もどんどんOSSを導入して置き換えていくわけでしょうか?

瀬尾 OSSにこだわっているわけではありません。自分たちだけでインフラを作ろうとは思ってませんし、必要に応じてAWSなども使っています。

ただ自分の原体験として、OSSを自分でいじって改修し、それを自分たちのインフラで運用していくことができれば、エンジニアリングの幅がかなり広がるし、開発体験がいいものになると思っています。

商用製品を使っていると、何か困ったことが起きたときにベンダーに修正を依頼して、直るのは半年後なんてこともありますよね。OSSなら自分たちですぐに直せますし、さらにその修正を本体にコントリビューションできます。それって開発体験として最高ですよね。

ZOZOでのエンジニアリングを、自分が考えているよりよい開発体験に持っていきたいと思っています。

インフラエンジニアとOSSコミッターの二軸でよりよい「開発体験」を追求するそのっつさん

取材・構成:高橋睦美
編集:はてな編集部
写真提供:ZOZOテクノロジーズ

※新型コロナウィルス感染拡大防止の観点から、インタビューはWeb会議ツールを用いてリモートで行いました。