2024.12.24
ビジネスが急速に変化する現代は「OODAサイクル」と親和性が高い 流通卸売業界を取り巻く5つの課題と打開策
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 の活動を通して実感しました!
以上、ありがとうございました。
(会場拍手)
関連タグ:
2025.01.16
社内プレゼンは時間のムダ パワポ資料のプロが重視する、「ペライチ資料」で意見を通すこと
2025.01.20
組織で評価されない「自分でやったほうが早い病」の人 マネジメント層に求められる「部下を動かす力」の鍛え方
2025.01.21
言われたことしかやらないタイプの6つの言動 メンバーが自主的に動き出すリーダーのマインドセット
2025.01.15
若手がごろごろ辞める会社で「給料を5万円アップ」するも効果なし… 従業員のモチベーションを上げるために必要なことは何か
2025.01.14
目標がなく悩む若手、育成を放棄する管理職… 社員をやる気にさせる「等級制度」を作るための第一歩
2025.01.21
今までの1on1は「上司のための時間」になりがちだった “ただの面談”で終わらせない、部下との対話を深めるポイント
2025.01.07
1月から始めたい「日記」を書く習慣 ビジネスパーソンにおすすめな3つの理由
2025.01.14
コンサルが「理由は3つあります」と前置きする理由 マッキンゼー流、プレゼンの質を向上させる具体的Tips
2025.01.22
部下に言いづらいことを伝える時のリーダーの心得 お願いを快く引き受けてもらう秘訣
2025.01.09
マッキンゼーのマネージャーが「資料を作る前」に準備する すべてのアウトプットを支える論理的なフレームワーク
チームの生産性を上げるマネジメント術
2024.12.11 - 2024.12.11
特別対談「伝える×伝える」 ~1on1で伝えること、伝わること~
2024.12.16 - 2024.12.16
安野たかひろ氏・AIプロジェクト「デジタル民主主義2030」立ち上げ会見
2025.01.16 - 2025.01.16
国際コーチング連盟認定のプロフェッショナルコーチ”あべき光司”先生新刊『リーダーのためのコーチングがイチからわかる本』発売記念【オンラインイベント】
2024.12.09 - 2024.12.09
NEXT Innovation Summit 2024 in Autumn特別提供コンテンツ
2024.12.24 - 2024.12.24