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.11.13
週3日働いて年収2,000万稼ぐ元印刷屋のおじさん 好きなことだけして楽に稼ぐ3つのパターン
2024.11.11
自分の「本質的な才能」が見つかる一番簡単な質問 他者から「すごい」と思われても意外と気づかないのが才能
2024.11.13
“退職者が出た時の会社の対応”を従業員は見ている 離職防止策の前に見つめ直したい、部下との向き合い方
2024.11.12
自分の人生にプラスに働く「イライラ」は才能 自分の強みや才能につながる“良いイライラ”を見分けるポイント
2023.03.21
民間宇宙開発で高まる「飛行機とロケットの衝突」の危機...どうやって回避する?
2024.11.11
気づいたら借金、倒産して身ぐるみを剥がされる経営者 起業に「立派な動機」を求められる恐ろしさ
2024.11.11
「退職代行」を使われた管理職の本音と葛藤 メディアで話題、利用者が右肩上がり…企業が置かれている現状とは
2024.11.18
20名の会社でGoogleの採用を真似するのはもったいない 人手不足の時代における「脱能力主義」のヒント
2024.11.12
先週まで元気だったのに、突然辞める「びっくり退職」 退職代行サービスの影響も?上司と部下の“すれ違い”が起きる原因
2024.11.14
よってたかってハイリスクのビジネスモデルに仕立て上げるステークホルダー 「社会的理由」が求められる時代の起業戦略
2024.11.13
週3日働いて年収2,000万稼ぐ元印刷屋のおじさん 好きなことだけして楽に稼ぐ3つのパターン
2024.11.11
自分の「本質的な才能」が見つかる一番簡単な質問 他者から「すごい」と思われても意外と気づかないのが才能
2024.11.13
“退職者が出た時の会社の対応”を従業員は見ている 離職防止策の前に見つめ直したい、部下との向き合い方
2024.11.12
自分の人生にプラスに働く「イライラ」は才能 自分の強みや才能につながる“良いイライラ”を見分けるポイント
2023.03.21
民間宇宙開発で高まる「飛行機とロケットの衝突」の危機...どうやって回避する?
2024.11.11
気づいたら借金、倒産して身ぐるみを剥がされる経営者 起業に「立派な動機」を求められる恐ろしさ
2024.11.11
「退職代行」を使われた管理職の本音と葛藤 メディアで話題、利用者が右肩上がり…企業が置かれている現状とは
2024.11.18
20名の会社でGoogleの採用を真似するのはもったいない 人手不足の時代における「脱能力主義」のヒント
2024.11.12
先週まで元気だったのに、突然辞める「びっくり退職」 退職代行サービスの影響も?上司と部下の“すれ違い”が起きる原因
2024.11.14
よってたかってハイリスクのビジネスモデルに仕立て上げるステークホルダー 「社会的理由」が求められる時代の起業戦略