Developer Successとしてのキャリア戦略
鈴木雄大氏：鈴木です。Developer Successチームのリーダーとして何をやってきたかをお話させていただきたいと思います。よろしくお願いします。
まず私の自己紹介なんですが、鈴木雄大と言います。インターネットではユーンと名乗っています。ビットバンク株式会社のエンジニアで、最初はフロントエンドエンジニアでAngularをやっていて、そこからTypeScript でのバックエンドで、現在ではDeveloper Successチームをやっています。
ビットバンクという会社をご存知でない方も多いと思うんですが、ビットコインなどの仮想通貨を扱う取引所ということで、金融機関ならではの安全かつ堅牢なシステムと、それだけだと開発が遅くなってしまっては良くないので、Web由来の開発技術や開発の効率化、速度を取り入れて、そういった両方が求められる開発をやっています。
実際にそうやっていくためには何が必要かというと、メンバーにはフロントエンドができる人、バックエンドができる人、そういった両方できる人が揃っていますので、ダイナミックにアサインが可能なようにTypeScriptを全面的に採用をしています。こういった、TypeScriptをフルで使っている会社はなかなかないと思っています。というところで会社の紹介とさせていただきます。
こういった会社でやらなければならないこととしては安定かつ堅牢かつ、金融機関であるので、ガバナンス性も高めなければいけないんですね。そういったものを保とうとすると、どうしても開発は遅くなっていってしまうものだと思います。
ただ、そういったところを遅くしないために開発効率や開発体験……たとえばリモートワークができるだとか、高機能なエディタが選べるとか、メモリの高いマシンがもらえるとか、そういったところを向上して開発効率を高めるために、そういった開発者の権利を守るために取り組むのがDeveloper Successチームかなと思っております。
昔は一貫性がないキャリアだった
まず、なぜ私がDeveloper Successになったのかをお話しさせていただきます。昔話になってしまうんですが、私は文系出身で最初は学生時代にRailsをやっていたのに入社したらRailsをやらなくなってみたいな感じで、あっちいってこっちいってで、いろんなことをやっていて自分の得意なものがないキャリアだったことが悩みでした。
1社目でNode.jsやCoffeeScriptをやったと思ったら、機械学習をやるといってPythonをやったり、IoTをやるといってGoをやったり、VRのためにReactとかthree.jsなどをいろいろやってきました。先輩から「このままじゃ器用貧乏になっちゃうぞ」と心配されまして、自分としてはいろいろ悩んだんですが、「フロントエンドでやっていくぞ！」と、ここでいったんキャリアを決めたところです。
そのあと良い縁があってフロントエンドの会社に転職してRailsとつなぎのReactを書いていたり、TypeScript化をしたり、jQueryを潰していったり、jQuery-templateを読み解いてReactに書き直すみたいな話を去年ここでしたりしました。
そういった中でフロントエンドのレガシーコードを書き直すみたいな、JavaScriptの本来の特性を活かせてなくて、たとえばCSS in JSで開発が楽になるなどのアプローチに興味があったのでCSS in JS in Rubyみたいなことも考えてやっていました。そういったJavaScriptの特性を活かした仕事をしたいという気持ちが徐々に芽生えてきました。
そういったJavaScriptならではのパフォーマンス性を活かした仕事を求めて、サーバサイドでNode.jsを使っているビットバンクに入社しました。
今まで自分の使っていたのがReactだったのが、ビットバンクではAngularでTypeScriptでNode.jsで、となったと思ったら、AWSをやりだしたりして、ここまでで見ると、最初に話した通り私のキャリアに一貫性がなくて、唯一あるとすれば、Node.jsを触っていたくらいなんですけど、これでは先に決めたようなフロントエンドエンジニアとしても名乗れないんじゃないかという不安がありました。
しかし、私がいろいろやってきたところはCTOにはすごい評価をしていただきまして、「フロントエンド以外の経験もあるみたいだし、全社基盤をやってみないか？」という話を持ちかけられました。
たとえばビットバンクの社内言語はTypeScriptなので、全部のパッケージはサーバでもフロントでも使えるようになるはずなんですが、実際には Isomorphic になっていないライブラリがあるのを Isomorphic にするとか、デプロイが一部手動でやっていたり、JSのままになっていたり、BFFがないのでモノリシックなAPIフロントサーバになっていたり、そういうところを直していくのを「旗振りしてくれないか？」と言われました。
私としては「これやったら、またキャリアがブレちゃうのかな」と思ったんですが、今まで学んできた知識が、年数を重ねていくうちに身に染みてきたという実感もあったので、「ここでいっちょ試してみるか」と思って、この仕事を快く引き受けることにしました。このときは、まだDeveloper Successではなかったのですが、前身として取り組みを開始しました。
たとえばやってきたこととしては、社内パッケージの整理をしたり、npm audit をして脆弱性の対策をしたり、あとはNode.jsのバージョン6のEOLになるのでバージョン10に上げたりしました。
なので、「全社Node基盤1人チームかな（笑）」と言っていたんですが、そのタイミングで入社してきた同僚から「それ、Developer Successじゃない？」と言われました。
Developer Successチームが発足
ここでDeveloper Successチームが発足しました。私のキャリアにも名前が付いて、ちょっとうれしくなりました。
「Developer Successって何？」というと、開発者の幸せのためにはなんでもするロールというところです。たとえば、後回しにしていたけど、やると開発が速くなってうれしいことを時間を取ってやったり、負債になる前に潰したりルールを作ったり、DXを上げるための組織作りをすることを全部やっていくのかな、という認識で方針を立てています。
こういうことを何でもするには幅広いスキルセットが必要ですが、私がいろいろ回り道をしてきたことが、巡り巡って役に立っています。
Developer Successの人がいると何がうれしいかというと、リリースフローで承認を5回挟まないといけないとかにならないようにするとか、メンテ不可能にならないように事前に防ぐとか。セキュリティを高めるけど、開発効率も高める動きをすることで、開発者を幸せにする仕事をしています。
逆に、Developer Successの人がおらずDeveloperFailureしてしまうと、社内のパワーバランスでみんなが不幸になったり、必要な承認が多すぎたり、OSS活動に対して会社が保守に入りすぎるみたいなことがあったりします。
そういったことにならないように活動していくと、開発者は成功して、みんながハッピーになって、ゆくゆくは会社としても採用につながるし、離職も減るし、会社の成長につながると思っているので、すごいやりがいを持ってやっています。
実際に何をやったのかと言うと、さっき「社内パッケージ管理が大変だ」という話をしましたね。これをやらないとどうなるかというと、プライベートのgitのHEADを参照しているので破壊的変更が入ると普通にバグるんです。
そうなっているのはみんな知っているのでむやみに手を出せない状態で開発速度が停滞していました。依存の関係も影響範囲もわからない状態です。
そのうえ、リリースには承認を挟んで手動で手元からpublishする感じだったので、すごく煩雑かつ疲弊するフローになっていたので、「直さないと！」と思ってやりました。
私はnpmパッケージのしくみを昔調べたことがあったり、Node.jsでファイルシステムを操作するスクリプトを書いていたり、複雑になっているシステムを整理するのが好きな性格というのもあって、1人で戦っていました。
これは別スライドにあるのでTwitterに貼ったリンクから見てもらえれば助かるんですが、7階層の npm 依存を全部PeerDependencies に直すということをしました。これはDeveloper Successかなと思います。
後日、このプロジェクトで整理した対象だったコードのテストを触っていた同僚から「天才さが伝わってくる」と褒められました。その人もうれしくなっているし、私も褒められてうれしいという、みんながハッピーになった話かなと思います。
この先のDeveloper Successとしての生き方
ほかにも「承認・デプロイフローを、効率的かつガバナンスにも耐えられるようにしたい」というものがありました。
これをやらないと、ガバナンスのために承認ワークフローをいちいち通さないといけない問題とか、デプロイ環境がEC2なのでサーバに依存してクリーンなデプロイができないとか、権限分割ができないので、いちいちCTO承認を通さないといけないなど、面倒くさいことになってしまいます。
そういったところをどうにかしないといけないというところで、私がGitLabに詳しかったこともあり、GitLab Runnerによる CI/CDの知識や、Dockerの元から持っていた知識や、AWSへのデプロイに必要な権限、クロスアカウントロールの取り回しについての新しい知識などを使ってこの環境を構築しました。
これによって、今までCTOの承認後にデプロイサーバからデプロイしてたのが、CTOが承認してマージをするとそのままデプロイされるようになりました。
こうした安定的なデプロイを構築した結果、問題が起こっても自分自身で解決できるようになりました。「runnerガチャっぽい」「runnerガチャだなこれ」「自分が天才で助かった……」と、自分自身の恩恵を受けられるという、なかなかない体験でやってよかったなと感じられる、すごいやりがいがあったと思います。
最後にまとめなんですが、このタイトル「Developer Successとは何であるのか？ 私にとってどうか？」というところなんですが、答えとしては「回り道した数だけ誰かを幸せにできる。そう信じてもっと回り道をどんどんしていってもっと新しいことをしていく」ことが私のDeveloper Successとしての今後の生き方かなと思います。
私の好きな言葉をもじったものとして「自分が回り道をしたせいで、ほかの開発者に手助けくらいしなくちゃな」という思いがあります。今まで回り道をしてきましたが、その回り道はそれでも血肉になっていたということが、Develolper Success の活動を通して実感しました！
以上、ありがとうございました。
(会場拍手）
