![見出し画像](https://assets.st-note.com/production/uploads/images/85795743/rectangle_large_type_2_dcc346e2bf8bb5f34f1e186db2fd0d89.png?width=1200)
モダンな技術も積極的に「小さく試す」ラクスの社内文化
はじめに
こんにちは。
ラクス フロントエンドチームの斉藤です。
突然ですが皆さんはそれなりに歴史のあるIT企業のソフトウェアにどのようなイメージを持っているでしょうか?
レガシーな技術を使っている
リファクタリングに苦労している
モダンな技術の導入を提案すると嫌な顔をされる
といったイメージを持っている方も多いのでは無いでしょうか?(私は思っていました)
ラクスは創業22年とIT系企業の中ではそれなりに古い会社で、私も入社前はなんだかんだレガシー環境と戦っていくんだろうな、と思っていました。
しかし蓋を開けてみると意外にもモダンな技術を積極的に取り入れており、心配していた「モダンな技術の導入を提案すると嫌な顔をされる」といったことは全くありませんでした。
事実、入社してすぐダメもとで携わっている製品へのVite導入を打診したところ、すんなりとOKが出て、大幅にビルド時間を短縮させることができました。
そんなことが可能なのもラクスが掲げる「失敗を恐れず挑戦する」「チームで成果を出す」そして「小さく試して大きく育てる」といった文化が背景にあります*1*2。
本記事では入社間もないペーペーフロントエンドエンジニアの私が、何故Viteというモダン技術の導入を任せてもらえたのかを「ラクスの社内文化」に焦点を当てて書いていきたいと思います。
*1: ラクスのエンジニアが目指すもの
*2: リーダーシッププリンシプル
1.週ごとの振り返りで問題点をあぶり出し、改善に挑戦する
私の所属する楽楽電子保存開発チームでは1週間を1スプリントとしたアジャイル開発を行っています。そこで毎週スプリントの振り返りを行いKPTを洗い出しています。
![](https://assets.st-note.com/img/1660029524873-6ZiiruwbJ9.png?width=1200)
Keepでは今週やって良かったことなどを書き、Problemでは自分が感じている課題(愚痴などどんなことでもOK)をチームで書き出していきます。一通り書き終えたら投票タイムに移り、共感できる課題や早急に対処するべきと感じた課題に一人1~3票で投票していきます。そして投票が集まったProblemをランキングし「どう改善するか」をTryの項目にチームで議論しながら書き込んでいきます。
そんな中チームのメンバーからwebpackに関する課題が上がりました。投票も多くメンバーからの共感も多い問題だったようです。
![](https://assets.st-note.com/img/1660029203794-UMM2sBimgF.png?width=1200)
Tryで議論に進みます。具体的にどんなことに辛さや難しさを感じているかを洗い出していき、どう解決しようかと話が進んでいきます。
![](https://assets.st-note.com/img/1660028986479-zdNcAAqHGF.png?width=1200)
私は前職や個人開発でViteを使ったことがあり開発体験の良さを実感していたので、思い切ってViteにしてみたらどうかと提案してみました。すると「いいね」「やっちゃってください」と結構軽い感じであっさり導入を任せてもらえる事になりました。
2.まずは一週間、小さく試す
ビルドツールをwebpackからviteに変更するのは大きめな決断だと思います。にも関わらずあっさり挑戦させてもらえたのは、ラクスに「小さく試して大きく育てる」というマインドがあるからです。これは新しい試みを積極的に小さく試して検証し、効果が大きいと判断できたらさらに育てていくというラクスエンジニアが持つ行動指針です。
Vite導入も例に漏れず「まずは試してみよう」ということで、導入に挑戦させてもらえました。楽楽電子保存ではReact、storybook、jestがwebpackに依存していたので、まずはReactだけViteで1週間試してみようということになりました。ここにも「小さく」というマインドが背景にあります。
またVite導入といった開発関連の事以外も積極的に試すことができます。例えば楽楽電子保存ではGitlabを使用しているのですが、マージリクエストを出す際にテンプレートが存在しませんでした。そこでスプリント振り返りで問題を提起しところ、まずはざっくりと作って試してみようということになりました。
![](https://assets.st-note.com/img/1660029996583-411BwVudKE.png?width=1200)
その日のうちにテンプレートを作り、まずは1週間運用します。その後、使用感をアンケートしたところ改善案が出されました。
![](https://assets.st-note.com/img/1660030103994-7uEC22gden.png?width=1200)
すぐに反映して運用というサイクルを繰り返すことで、MRのテンプレートを定着させることができ、レビュワーの負担を削減させることができました。
このように「問題提起」→「小さく試す」→「検証する」→「改善」というプロセスを繰り返すことで、製品だけでなく開発環境等の改善を行っていくことが、楽楽電子保存フロントエンド開発チームのスタイルとなっています。
3.情報共有会でオープンに相談し、社内のエンジニアに助けてもらう
Viteの話に戻ります。導入を任せてもらえたのは良かったのですが、webpackからViteへのリプレイスはなかなかハードルが高くどこから手をつけていけば良いかわかりませんでした。
そこでフロントエンド情報共有会という場で相談したところ、他のチームの担当する製品で既に導入を検討をしており、情報の共有をしてもらうことができました。ラクスでは2週間に1回の単位でフロントエンド情報共有会という、社内のフロントエンドエンジニアが集まって情報共有できる場が設けられています。ラクスのフロントエンドエンジニアは基本的には1つの製品に関わりますが、定期的にこのような場を設けることで自チーム内だけでは解決の難しい課題の相談をすることができます。
共有してもらった情報をもとにリプレス作業を行ったことで、大きな問題も無くReactへのVite導入を行うことができました。
4.振り返りで検証と情報共有を欠かさない
無事導入を終えましたが、そこで終わりではありません。
小さく試した後は「本当に導入しても問題ないか?」「効果はどれくらい出たか?」を検証しなければいけません。現在楽楽電子保存ではViteを試験導入という形で検証しています。今後バックエンドとの疎通確認や動作テストを行なっていき、問題なければ正式採用となります。無事採用されれば、次は「大きく育てる」というフェーズに入るので、storybookのVite化やjestのwebpack脱却を進めていくことになります。
また社内への情報共有も重要なタスクです。ラクスは「学習し成長し続ける」というValueも掲げているので、学んだことはみんなで共有するようにしています。
![](https://assets.st-note.com/img/1660031070568-emf0wVgmCq.png?width=1200)
まとめ
以上のようにラクスではモダンな技術でも積極的に試していける環境があります。ラクスには「楽しんで楽にする」という行動指針もあるので、技術を楽しみながら改善をしていくことができるというのも魅力の一つだと思います。
ラクスは現在エンジニア積極採用中ですので、興味のある方はぜひ、まずはカジュアルにお話ししましょう!
採用情報
イベント情報
この記事が気に入ったらサポートをしてみませんか?