2024.10.10
将来は卵1パックの価格が2倍に? 多くの日本人が知らない世界の新潮流、「動物福祉」とは
DeveloperSuccessとして何を届けられるか、様々な分野を経た先として何ができるか(全1記事)
リンクをコピー
記事をブックマーク
鈴木雄大氏:鈴木です。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って何?」というと、開発者の幸せのためにはなんでもするロールというところです。たとえば、後回しにしていたけど、やると開発が速くなってうれしいことを時間を取ってやったり、負債になる前に潰したりルールを作ったり、DXを上げるための組織作りをすることを全部やっていくのかな、という認識で方針を立てています。
こういうことを何でもするには幅広いスキルセットが必要ですが、私がいろいろ回り道をしてきたことが、巡り巡って役に立っています。
Developer Successの人がいると何がうれしいかというと、リリースフローで承認を5回挟まないといけないとかにならないようにするとか、メンテ不可能にならないように事前に防ぐとか。セキュリティを高めるけど、開発効率も高める動きをすることで、開発者を幸せにする仕事をしています。
逆に、Developer Successの人がおらずDeveloperFailureしてしまうと、社内のパワーバランスでみんなが不幸になったり、必要な承認が多すぎたり、OSS活動に対して会社が保守に入りすぎるみたいなことがあったりします。
そういったことにならないように活動していくと、開発者は成功して、みんながハッピーになって、ゆくゆくは会社としても採用につながるし、離職も減るし、会社の成長につながると思っているので、すごいやりがいを持ってやっています。
実際に何をやったのかと言うと、さっき「社内パッケージ管理が大変だ」という話をしましたね。これをやらないとどうなるかというと、プライベートのgitのHEADを参照しているので破壊的変更が入ると普通にバグるんです。
そうなっているのはみんな知っているのでむやみに手を出せない状態で開発速度が停滞していました。依存の関係も影響範囲もわからない状態です。
そのうえ、リリースには承認を挟んで手動で手元からpublishする感じだったので、すごく煩雑かつ疲弊するフローになっていたので、「直さないと!」と思ってやりました。
私はnpmパッケージのしくみを昔調べたことがあったり、Node.jsでファイルシステムを操作するスクリプトを書いていたり、複雑になっているシステムを整理するのが好きな性格というのもあって、1人で戦っていました。
これは別スライドにあるのでTwitterに貼ったリンクから見てもらえれば助かるんですが、7階層の npm 依存を全部PeerDependencies に直すということをしました。これはDeveloper Successかなと思います。
後日、このプロジェクトで整理した対象だったコードのテストを触っていた同僚から「天才さが伝わってくる」と褒められました。その人もうれしくなっているし、私も褒められてうれしいという、みんながハッピーになった話かなと思います。
ほかにも「承認・デプロイフローを、効率的かつガバナンスにも耐えられるようにしたい」というものがありました。
これをやらないと、ガバナンスのために承認ワークフローをいちいち通さないといけない問題とか、デプロイ環境がEC2なのでサーバに依存してクリーンなデプロイができないとか、権限分割ができないので、いちいちCTO承認を通さないといけないなど、面倒くさいことになってしまいます。
そういったところをどうにかしないといけないというところで、私がGitLabに詳しかったこともあり、GitLab Runnerによる CI/CDの知識や、Dockerの元から持っていた知識や、AWSへのデプロイに必要な権限、クロスアカウントロールの取り回しについての新しい知識などを使ってこの環境を構築しました。
これによって、今までCTOの承認後にデプロイサーバからデプロイしてたのが、CTOが承認してマージをするとそのままデプロイされるようになりました。
こうした安定的なデプロイを構築した結果、問題が起こっても自分自身で解決できるようになりました。「runnerガチャっぽい」「runnerガチャだなこれ」「自分が天才で助かった……」と、自分自身の恩恵を受けられるという、なかなかない体験でやってよかったなと感じられる、すごいやりがいがあったと思います。
最後にまとめなんですが、このタイトル「Developer Successとは何であるのか? 私にとってどうか?」というところなんですが、答えとしては「回り道した数だけ誰かを幸せにできる。そう信じてもっと回り道をどんどんしていってもっと新しいことをしていく」ことが私のDeveloper Successとしての今後の生き方かなと思います。
私の好きな言葉をもじったものとして「自分が回り道をしたせいで、ほかの開発者に手助けくらいしなくちゃな」という思いがあります。今まで回り道をしてきましたが、その回り道はそれでも血肉になっていたということが、Develolper Success の活動を通して実感しました!
以上、ありがとうございました。
(会場拍手)
関連タグ:
2024.10.29
5〜10万円の低単価案件の受注をやめたら労働生産性が劇的に向上 相見積もり案件には提案書を出さないことで見えた“意外な効果”
2024.10.24
パワポ資料の「手戻り」が多すぎる問題の解消法 資料作成のプロが語る、修正の無限ループから抜け出す4つのコツ
2024.10.28
スキル重視の採用を続けた結果、早期離職が増え社員が1人に… 下半期の退職者ゼロを達成した「関係の質」向上の取り組み
2024.10.22
気づかぬうちに評価を下げる「ダメな口癖」3選 デキる人はやっている、上司の指摘に対する上手な返し方
2024.10.24
リスクを取らない人が多い日本は、むしろ稼ぐチャンス? 日本のGDP4位転落の今、個人に必要なマインドとは
2024.10.23
「初任給40万円時代」が、比較的早いうちにやってくる? これから淘汰される会社・生き残る会社の分かれ目
2024.10.23
「どうしてもあなたから買いたい」と言われる営業になるには 『無敗営業』著者が教える、納得感を高める商談の進め方
2024.10.28
“力を抜くこと”がリーダーにとって重要な理由 「人間の達人」タモリさんから学んだ自然体の大切さ
2024.10.29
「テスラの何がすごいのか」がわからない学生たち 起業率2年連続日本一の大学で「Appleのフレームワーク」を教えるわけ
2024.10.30
職場にいる「困った部下」への対処法 上司・部下間で生まれる“常識のズレ”を解消するには