こんにちは。
この記事は freee 基盤チーム Advent Calendar 2023 12/09(9日目)の記事です。
昨日は imariku さんの TerraformのAWS ProviderでRoute Table Resourceを利用するときに気を付けたほうがよいこと - freee Developers Hub でした。tfstate の変化を確認することの大切さが書かれていますね。
今日は今年の7月に基盤側の開発組織である「共通Admin 基盤開発チーム」に異動した にいおか が書きます。 freee の「異動戦国」制度を利用した経緯やら思いやら、そういうのを書いていきます。やっていきましょう。
こういう話を書くよ
- freee の異動戦国とは
- どうして異動しようと思ったんよ
- 異動してから何していたの
- 異動してみての感想
異動戦国 is なに
異動戦国とは、1年に1回自分の希望するチームに異動の立候補をすることができる社内異動制度です。 freee のエンジニアの成長を後押しする制度として定着しており、異動戦国の時期は各チームで異様な盛り上がりを見せています。
freee Developers Hub にも過去の異動戦国についての記事がありますので、是非読んでみてください。
異動戦国応募に至った経緯
今までは CRE というチームに在籍しており、主に freee人事労務 における問い合わせやユーザビリティの向上に対する対応をしていました。 CRE でどういうことを行なっていたかは freee 技術の本に書いていたり下記のスライドに書いています。
第16回Customer系エンジニア座談会〜freee CRE の体制と人事労務チームの問い合わせへの向き合い方 - Speaker Deck
さて、CRE ではお客様からのお問い合わせ対応において、いわゆる「Admin」画面を使うことがよくありました。 freee では利用しているプランによって使える機能が異なったりするため、お客様がどのようなプランを契約しているか・何名程度で freee を利用しているかの規模感などを Admin 機能によって確認できるようになっています。
この Admin 機能、freee プロダクト群の開発の歴史から各プロダクトに各々独自に作られていたりします。 一方で、ものによっては提供機能の中で他プロダクトへの依存が生じているものもあり、freee 全体として見たときに統制が効いておらずなかなか混沌とした状態になっていたりもします。 結果として利用するほうもテクニック(というよりも暗黙知)を必要とする状態になっていました。
freee が提唱する「統合体験」の概念*1 の実現に対して、Admin のレイヤーの統合の重要性も高まりつつあり「共通Admin 基盤開発チーム」が作られるに至りました。 もとより Admin 機能をよく触るチームに所属していた人間として、Admin 機能の使い勝手の悪さや特定プロダクトへの依存度の大きさ、実装の混沌具合などに対してどうにかして整えていきたい！という気持ちが強くありました。 今なお成長を続けている freee 開発組織全体がスピード感をもって開発に取り組める環境を、自分の力で共通Admin という基盤を提供することで推し進めたい、というのが応募に至った経緯です。
そこからは異動先の JM とのお話を経て、あれよあれよと異動した次第です。
異動してからの半年弱、どういうことに取り組んできたか
まずは、一番依存度の大きいプロダクトの Admin から Admin 用に利用しているライブラリへの依存排除や実質的に不要なコードを取り除くことをしばらくの間行なっていました。 別の手段に置き換え可能でありながら、既存の実装で特定 gem に依存していた処理などの置き換えなどをバシバシやっていったり、ついでにオブジェクト参照のメモ化をして無用な読み出しの軽減を進めたりしていました。
大きい成果として、気がついたら Redis へのアクセスを半減させていたようです。 意識していなかった部分に対して作用していたため、思わぬ方向で価値が出て聞いた時は驚いたものでした。
最初の四半期である程度いいところまで進められたので、現在はAdmin 機能の統合に向けた処理系のリアーキテクトについて設計を進めたり、インフラを構築していたりしています。 ただ単純にアプリケーション開発に務めるだけではなく、色々なことに手を出せていますね！楽しいね！！！
共通Admin 理想論(個人のお気持ち表明)
統一的な Admin 機能提供や権限制御統制の実現を共通Admin で進めることにより、これからも増えていくであろうプロダクトに対しての初期開発速度の後押しの実現を目指しています。 また、プロダクト本体との開発や保守と疎にすることで、Admin 機能それ自体がプロダクト開発のブロッカーとならないような効果も期待しています。
利用者の観点では各プロダクトAdmin のドメインを意識せずに、統一された操作感による Admin 操作を提供します。 ログイン操作をいちいち繰り返さないといけなかったりタブを延々と切り替える必要があったりせずに済むような世界を目指しています。
インフラ観点でも統一されたリソースを利用することでプロダクトへの負荷を軽減したり、費用面でもメリットが生じるようにしたいものです。
異動してみての感想
求められるスキルセットが大きく変わったので、そういう文脈で毎日勉強になることがたくさんありますね。 何となく、ぼんやりと言葉は知っているけれども仕組みは知らない、そのような技術要素について知ること・使うことができて新鮮な日々を過ごしています。
また、コードに触れる時間が単純に多くなったので、開発のブランクを取り戻すべく試行錯誤に日々取り組むことができているのは異動して良かったことの一つです。
チームのメンバーも、分からないことを Slack に投げ込むと知を全力で投げ込んでくれるので心強いですね。いやはやありがたい。 異動する前は「なんもわからん」な人が飛び込んでいって良いのか？という気持ちはありましたが、なんとかやっていけてます。 これからもやっていきます。
良いもの作っていくぞい！
おわりに
今日は「異動戦国」制度を利用して「共通Admin 基盤開発チーム」に異動したお話を書かせていただきました。
freee では「マジ価値」を生み出していくためには既存のものをただ大きくするだけではなく、壊して作り直してブラッシュアップする挑戦もできる会社です。 Admin 機能というユーザーからは見えない部分ではありますが、freee を支えるものの一つとしてより良い価値を提供できるように努めたいものです。
明日は Uryy さんによる pagerduty に関するお話です！お楽しみに！
*1:freee の vision は以下のリンクをご参照ください
