こんにちは。
Eight でエンジニアをしている鳥山（@pvcresin）です。
最近は芸人のラランドのラジオにハマっています。「お母さんヒス構文」が好きです。
さて今回は、私が普段行っている Frontend Enabling 業務の紹介をしたいと思います。
背景
Eight というプラットフォーム上には、名刺を起点として個人や企業に向けた様々なサービスがあります。 これら複数のサービスにはそれぞれ対応した開発チームが存在しますが、Web フロントエンドの分野において以下のような課題感がありました。
- 知見の蓄積が各チーム / メンバーの努力に頼りきりで、共有もされづらい
- 改善活動がボランティア的な動きに支えられており、なかなか進まない
これらの課題を解決するため、サービス開発チームとは別に、技術で横断的に支援していくことが必要なのではという話になりました。 そこで昨年の 3 月から、
- サービスを横断したフロントエンド支援で、プロダクトを推進すること
- 各サービス / チームのフロントエンドにまつわる不安を解消すること
を目的とした活動を「Frontend Enabling 業務」として行っていくことになりました。
実は私は、それ以前からボランティア的に改善を進めているうちの一人だったので、その活動に Enabling 業務という名前が付いたという感覚でした。 最初は当時所属していた採用サービスの開発チームと兼務でしたが、現在は専任となっています。
立ち位置
Enabling 業務の内容は常に模索中ではありますが、基本的に Eight の各サービスの開発を加速するためなら何でもやるといった感じです。
そのため、各サービスのメンテナンスに当たる部分にも多少踏み込んでいます。
また、各チームの不安を払拭し、自立して快適に仕事ができるように支援する役割のため、
ただ人手として動くのではなく、その後に開発チームが再現性を持って開発にあたれるような指針を残すことを意識しています。
加えて、誰が対応するのかわからないボールはひとまず拾うようにしています。
業務内容
業務は、主に以下の 4 つの活動から構成されています。
- 支援
- 知見共有
- メンテナンス
- 改善
一つひとつ見ていきます。
支援
プロダクトの推進には機能開発が必要不可欠なため、各サービスの開発を支援しています。
具体的には、設計や実装方針の議論、コードレビュー、ペアプロ / モブプロの実施などがあります。
そして、その前提理解に必要な仕様策定やタスク出しの場にも適宜参加しています。
仕様や API 設計レベルでうまく行っていない場合、それらがコードに染み出してきてしまうため、できるだけ早期に防ぐように心がけています。
知見共有
組織として再現性を持った開発を行うためには知見共有は重要です。
そのため、積極的にドキュメントやオンボーディング資料に落とし込んでいます。
また、技術検証に基づくアウトプットも知見共有に含まれます。
先に利点やハマりどころなどを知っておくことで、開発がスムーズに進むよう努めています。
メンテナンス
動いているサービスを持続可能にするためには継続的なメンテナンス作業が必要です。
ここでは主に、コードや依存ライブラリの構成を大きく変えずに、サービスの品質を保つための活動をイメージしています。
例えば、本番で起きているエラーや警告の対応、破壊的変更が多く含まれるライブラリ更新や脆弱性のあるライブラリの対応などです。
ライブラリ更新に関しては各サービスの開発チームに基本的に対応してもらっていますが、マイグレーションが難しい場合やトラブルが起きた時に対応しています。
その他には、社内向けに公開しているライブラリ群の更新作業や CI/CD 周りの整備が含まれます。
改善
サービスに関する様々な要素は経年劣化してしまうため、常に改善活動を行っています。
コードやライブラリのモダン化、ビルドや CI の高速化、パフォーマンス改善などがこれに当たります。
また、フロントエンドっぽい話で言うと、一貫性のない UI/UX などデザイン負債の解消のため、
デザイナー陣と連携してデザインシステムの改善を行っています。
これもサービスと同様に、一度作ったら終わりではなく育てていくものと認識しています。
Enabling 業務の難しさ
様々なサービスを見られて多くのエンジニアと議論できるため、楽しい業務ではありますが、難しいと感じる部分も多いです。
まず前提として、方針などを決めるには各サービスのドメインや採用技術の知識、既存コードの理解が必要になります。
キャッチアップはなかなかハードですが、適宜、開発チームにも教えていただきながら頑張っています。
また、悩んでいる時間が多いため、成果が見えにくいです。
ありがたいことに各チームから Help を求めてもらうことも増えましたが、
設計的に難しい部分だったり、謎のバグだったりして、調査や検証で一日過ぎることもあります。
しかし、対応方針を間違えると負債化して今後数年間苦しめられるリスクもあり、慎重に判断するようにしています。
最後に、やりたいことはたくさんあっても時間は有限なため、優先順位付けが難しいです。
改善に終わりはないので、できるだけコスパの良いものを選ぶようにしています。
また、Web フロントエンドの分野は流れが速いので情報収集は重要ですが、流されて自己満足な改善を行わないよう、注意しています。
まとめ
今回は、Frontend Enabling 業務について簡単に紹介しました。
最初の頃はキャッチアップにヒーヒー言っていましたが、現在は少し落ち着いて支援できるようになってきたと感じています。
多くの部分で各サービスのエンジニアに助けられており、感謝してもしきれません。
今後もプロダクトを推進できるように開発支援や改善を進めると同時に、カバーできる範囲を増やしていけるように頑張りたいと思います。
