はじめに
タイトルは釣りです（テンプレ）
はじめましての方ははじめまして。特にこの記事がバズるとも思ってないんですが、なんとなく新しく僕のことを知っていただいた方のために自己紹介しておきます。
ZOZOテクノロジーズ開発部に所属するインフラエンジニアのようなことをやっている者です。チーム的にはMLOpsチームという組織にいます。Dockerが好きです。
社内では本名の太田さん、pchan、いんだくたーさん、こうちゃんなどと呼ばれています (Ref: @sonots)
自分のことを知っている方はご存知だと思いますが、自分語り満載のエントリーになる予定です。だるいと思った方はスルーしてもらって大丈夫です！
入社の経緯とか
そもそもの入社のきっかけは、前職で働いていた頃に遡ります。前職では小さな(?)Web制作会社で受託案件のPHPを書いたりAndroidアプリ(Java)の保守などをメインに担当していました。
もともと開発だけでなくインフラも含めていろいろやりたいと希望していたのですが、担当案件で人が足りなかったり、本来想定していない規模の追加改修が入るなどのタイミングが重なって自分がやりたかったインフラ側のタスクはほとんどできず、もやもやを抱えたので転職を考えていた矢先にお話をいただいてトントン拍子で入社が決まったという形です。
入社して最初にアサインされたのは当時新規で行っていたプロジェクトで、ZOZOの技術スタックをご存じの方が聞くと「え、そんな感じでやってるんだね」と言えるくらいには比較的モダンな構成で作られていました。
いろいろなことはありましたが、それなりの規模のチームでプロダクションでサービスを運用することの良さや難しさを経験するにはとても良かったなと思っています。
インフラエンジニアなのにプロジェクトにDeployGateの導入をしたり、フロントエンドのビルド最適化とかいろいろ細かいことをやっていたのは前職の知識を活かしつつできたのもあってやりがいがありました。
初めての異動
入社して半年ほど経った頃、チーム異動の話がありました。端的に言うと社内でAWS一番詳しい人のチームで基礎能力を鍛えましょうみたいな話でした。
僕自身、未経験でインフラをすることに不安を抱えていたこともあったので、是非お願いしたいということで次の月から社内でAWSのいろいろな案件を見ているチームに移りました。
異動前のチームでは良くも悪くも個人の裁量がとても大きく、大まかなスケジュールと要件があって、それをタスクごとに割ってアサインしていくような感じでやっていました。当時は気付きませんでしたが、今思えば未経験であのやり方だと何がいいのかわからない状態になってしまうので、当時の自分には合っていなかったように思います。
もしかしたら、それを汲み取っての異動だったかも、というふうに思いました。
この新しいチームではAWSを使ったいろいろなタスクを経験しました。最初、リーダーのやり方に合わせていくのが非常に大変で何度か問題が発生してしまったこともあったのですが、少しずつ自分なりにチームに合わせる方法を見つけられるようになって、最終的には(レビューなどは入りますが)一人で中規模のインフラ設計などがこなせるようになりました。
特に重要なのはドキュメントを残すという点や、どのようなドキュメントを残すべきなのかといった内容で、このような基礎的なレベルの内容を辛抱強く身につけられたのは、当時のリーダーのおかげです。逆に言えば、今までは本当に雰囲気でしかやっていなかったんだなということも思います。エンジニアリングなにもわからない。
一人立ち？
年末になって、今までとは毛色の全く違うタスクが入ってきました。AWSメインのチームでGCPをやるそうです。しかもKubernetesだそうです(最近プレスリリースが出たやつです)。
実は、自分の周りでは社内でGCPを使ってインフラを動かすというのは当時そんなに活発ではなく、Terraformなどを使った構成管理も主流ではありませんでした(使っているプロジェクトもありましたが、全社的に広めるとかそういう事実はありませんでした)。Kubernetesについても、社内に事例はあるもののGKEではなかったですし、Kubernetes激強なエンジニアもいなかったということや、機械学習のパイプラインが必要といったいくつか特殊な要件があったので一部についてはほぼほぼ1から設計を考えることになりました。
ここまでくるとレビュー以外の作業は全部自分でやる必要があります。Terraformの設計思想を固めるのにも苦労しましたが、上に乗っかるアプリケーションのCICDパイプラインやGCPのVPC設計、Kubernetesのこと、GKE特有の概念など、本当にたくさん考えなければならないことがありました。kubectl applyやterraform applyをチームやプロジェクトの要件に沿いながら自動適用できるようにしたのは個人的には偉いぞ自分と思っています。手動でやるのはもぅマヂ無理って感じですよね。
長いインプットとの戦い
Kubernetesの勉強には1ヶ月以上の時間を有しました。そもそもDockerやDocker Composeしかやったことがない人間です。分散システム何もわからないです。
あまりにも何もわからないのでKubernetes公式ドキュメントを読みました。全部英語でした。英語を読むのがめんどくさかったので、年末年始に死ぬほどたくさんのドキュメントを翻訳してGitHubの翻訳プロジェクトに投げつけたらびっくりされました。
Kubernetesのことが本当にわからなかったのでお家のPCを使ってkubeadmでクラスターを立てたりしました。なんとなく気持ちがわかるようになりました。KubeConにも行かせてもらいました。雰囲気がわかりました。シアトルは4000人規模のカンファレンスだったのですが、お祭り感があってめちゃ楽しかったです。当時のことはブログにも載せています。
シアトルに行ってよかったことはAmazonのオフィスに遊びに行けたことと、とあるつよつよ日本人エンジニアの方たちと一緒にラーメンしばきに行けたことです。彼らとは今でもいい友人(?)だと思っています。
チームの変化
このチームは3人だったのですが、そのうち1人が辞めることになりました。このタイミングで別のインフラチームとの統合が決まり、チームの体制が変わりました。
さらに、このタイミングで本案件を機械学習の運用を専門とするMLOpsチームに引き継ぐ、という話も出ました。つまり、僕の手から離れるようになるということが決まりました(これに関してはいろいろありますが、最初に名乗ったとおり今自分はMLOpsチームにいるので、結果としてはそのままプロジェクトと一緒に異動しました)。
引き継ぎに関してはそんなに大変ではなく、ドキュメントがもともとあったのと、むしろ引き継いでからKubernetes上だったりモデルのパイプラインに対して本格的に様々な要素を入れたため機械学習専門チームに引き渡したのは大正解だったと思っています。僕としても多くのことを学びました。
とまあ引き継ぎを進めていたのですが、前述の通り気がついたら僕もMLOpsの一員になっていました。いろいろ新しいことがあって大変ですが、技術的な挑戦もあればサービスを良くするための議論を広げられるチャンスがたくさんあって、とても楽しく働けています。
MLOpsという取り組みについて
僕はDevOpsとかSREを「スキル」だと呼ぶのが正直あまり好きではありません。これらは組織による問題解決の取り組みの一環に過ぎず、あくまでもそのサービス、プロダクト、チーム、組織、ひいては会社によって定義づけられるべきだと思っているからです。システムの自動化や監視などはそのための手法であって、それ自体がDevOpsを指すわけではないと認識しています。
MLOpsもDevOpsから派生した言葉の1つで、機械学習という特殊な枠組みを本番で運用するための技術や、それに対する取り組みの抽象的な概念です。まだまだ言葉が生まれてから日も浅くどの組織でも手探りにそれぞれのMLOpsを探っている状態だと思います。
僕たちの組織も同じで、これから一緒に仕組みを作ってくれる人を募集しています。
サービス志向 vs 技術志向?
弊社では”とあるECサイト”の開発が一番大きなプロジェクトで、利益の多くはそのサイトによって生み出されています。当然、日々様々な施策や新しい機能の追加などを行うチームもあります。
今回ボクがMLOpsチームに入ることになったこのプロジェクトについても、この「新しい機能」に属すものだと思っていて、ある種の投資でもあり、こういう挑戦が許される環境というのは特に小さな資本の会社だとあまり無いのかなと思います(資金調達の上手なベンチャーは本当に凄いなと尊敬しています)。
これは僕の印象なのでみんながそう思っているわけではないと思いますが、弊社は比較的にうちのサービスが好き、というエンジニアが多いです。技術はサービスを良くするための手段という考えを持つ人達も少なくありません。コレ自体は全く問題ではないと思っていて、こういう考えの人達が多いからこそ、(ユーザーさんや周囲の反応は別としても)サービスのために攻める企画を実現できているという事実もあるんだと思います。
一方で、技術的な挑戦というのも、エンジニアやエンジニアリング組織にとっては大きなミッションでもあります。これはサービスの開発とは少しテイストが違って、技術力を高めることによってより良いサービスを提供する、というような発想だったり、技術によって新たな価値を生み出すといった考え方なのかなと自分は認識しています。
これらの考え方は往々にして反発するもので、よくネット上でも議論が分かれているように思います。実際、さまざまな分野で働くエンジニアたちにとって、要求されるマインドセットやスキルは違うので、それ自体はしょうがないと思います。プロトタイピングと保守で要求されるスキルが違うのと同じじゃないでしょうか（雑）
僕はこれらのエンジニアたちは一緒に働くことによってお互いの能力を高め合えると考えていて、さまざまなタイプのさまざまなエンジニアたちがいることによって、提供できるサービスの内容や質の幅が広がります。こうした様々な性質のエンジニアたちをまとめるのがマネージメントで、エンジニアリングをマネジメントすることは特に規模の大きな会社では至上命題になっているように思います。
まあ、要するに、どんなエンジニアでも働ける場所はあるんだと思うよってことです。
会社の変化
話は変わりますが、僕の在籍する1年半でたくさんのことが変わりました。入社直後にベンチャーの買収があって、研究所ができて、今まで勉強会なんてやってなかったのにオフィスで勉強会が企画されて、さまざまなカンファレンスでスポンサーや登壇する人が増えて、リモートやフレックスが自由に選択できるようになって、他にも内部の細かいところでいろんな変化がありました。多分、まだまだいろいろなことが変わると思います。そのうち出てくるものもあると思いますので楽しみにしていてください。
入社して一番よかったのは技術発信をきちんと応援してくれることです。Tech Blogも超大手ほどではないにせよいろいろな人達が書くようになってきていますし、今までになかった部分でも少しずついい文化が形成されようとしているのを内部から感じています。
さいごに
駄文でしたが、あんまり書いてても面白くないのでこのへんで締めます。
嘘は書いてないつもりですが、もし編集されていたら大人の事情と察してください（）
もしこの文章を読んで一緒に働いてみたいと思った方、個別に連絡いただくか、採用ページまでお願いします！
