はじめに
こんにちは。クラウド勤怠チームでエンジニアをしております katuoです。今回の記事ではタイトルの通り、今期、クラウド勤怠内にフロントエンドギルドチームというスモールチームを作って、活動したことについて、振り返っていこうと思います。
チーム誕生の背景
日々開発業務に追われるなかで、チーム内に大きく分けて以下3つの課題がありました。
- 生産性: 機能開発を優先してその場限りのコードや負債が溜まったりして、生産性が低下している
- 成長環境: メンバー間での知見を共有をする機会が少なく、スキルアップの機会が損失している
- 採用力: 技術環境面において、エンジニアへのアトラクトが弱い土壌になっている
それぞれの課題は互いに依存しあっている状態でした。
これらの課題を解消・改善を目的に業務時間の1~2割程度の工数を使って活動を行う、フロントエンドギルドチームが誕生しました。(以下、FEギルド)
どのようにチームを運用したか
ロードマップ策定
初めにメンバーとこの先の未来予想図を考えながら、今期で実施していくことを定め、ロードマップを策定しました。ロードマップの具体的な内容は差し控えさせていただきますが、モダンフロントエンド部分のリアーキテクト、コード規約の作成、E2Eテストの導入 ...etc などを盛り込みました。
定例MTGの開催
週1で定例MTGを行い、以下の項目について確認・議論をする機会を設けました。
- 進捗確認・担当者アサイン
- 生産性向上のための提案
- 技術的相談・雑談
ロードマップで拾い切れなかった生産性を低下させている課題や、さらなる生産性向上のための課題を拾って開発チケット化をする体制にしました。PRレビュー等で出てきた全体に波及しそうな相談事項も本MTGで揉み合い、意思決定を行ったりもしました。
FY22 半期でやったこと
社外に公開できる範囲で今期、実施したことを並べてみました。
- Vue Composition APIの移行&運用
- 新ディレクトリ・ファイル名規約の導入
- Prettier & ESLintの運用
- E2Eテスト(mabl)の導入
- Webパフォーマンスの測定環境構築
- Tailwind CSSの実運用
- Stimulus.js 3系へのバージョンアップ等
- API利用規約の作成
- 勉強会の実施
- 技術ブログの公開
公開できる範囲でも少し量が多いのですが、それぞれ簡単に説明します。
Vue Composition APIの実運用
クラウド勤怠のフロントエンドはVue 2で構成されています。その中で一部コンポーネントは@vue/composition-api を利用してCompostion APIを利用していました。今期はVue.jsを2.7系にマイグレーション&アップグレードしたことで <script setup> が使用できるようになりました。
これによりOptions APIの弱点であった関心ごとの分離ができない問題の解消やボイラープレートを大幅に削減することができました。
また多くの汎用コンポーネントや専用コンポーネントを<script setup>を用いたComposition APIの構成に移行し、かつ新規追加されるコンポーネントは全て<script setup> の構成にする運用に持っていくことができました。
また同時にHooksのコード規約も整備を進め、VueUse を活用しながら再利用可能なモジュールを追加、各所で利用できるようにしました。
新ディレクトリ・ファイル名規約の導入
数年前の当初のクラウド勤怠のフロントエンドはslimに対して、Stimulus Contollerを差し込み、Stimulus ControllerからVueインスタンスを生成するという構成でした。
機能開発が進むにつれて、高度なUI/UXが求められるようになった結果、Vue.jsで構成される画面比率が多くなり、Stimulus Controllerを間に挟むことによってボイラープレートの増加やコードの難読化などが発生して、この構成で運用するメリットがなくなってしまいました。 直近では開発効率を上げるためにslimから直接Vueインスタンスを生成するためのエントリーポイントとなるJSファイルを差し込む構成に変わりました。
今期はこの構成のページをモダン化ページと呼び、このモダン化されたページのディレクトリ構成やファイル名の規約をGithubのWikiに作成、移行作業を実施しました。 参考: ディレクトリ構成図の一部
app/javascript/vue /** ① 共通ディレクトリ */ ├── atoms ├── components ├── helpers ├── hooks ├── molecules ├── constants ├── pages /** ② ページディレクトリ */ │ └── books │ ├── edit │ ├── index │ │ ├── common │ │ │ └── components │ │ ├── entry.ts │ │ ├── index.vue │ │ └── parts /** ③ パーツディレクトリ */ │ │ ├── book-list │ │ │ ├── book-list.vue │ │ │ └── parts │ │ │ └── book-item.vue │ │ └── index.ts │ ├── new │ ├──show │ └── common /** ④ 【重要】スコープディレクトリ */ │ ├── components │ │ └── book-form.vue │ ├── helpers │ │ └── calcBookPrice.ts │ └── hooks │ └── useBookPublishedDate.ts └── types.d.ts
詳細は他メンバーが別記事として公開する予定なので、興味ある方はしばしお待ちください。
Prettier & ESLintの運用
過去にコードフォーマッターをきちんと運用できていなかった時代があり、そのファイルをいじると自分が編集した箇所以外も差分が発生してしまう辛い状態になっていました。(PRを作成時にエンジニアに掛かるストレスが非常に大きかった) フォーマッター設定を見直し、触る頻度が多いディレクトリページを中心に修正作業を行い、余分な差分が発生しないようにしました。
PR上でコードの書き方について意見が分かれたりする場面が定期的に発生していたのですが(Vue Componentのサイズ感、interfaceとtypeのどっちを使うか …etc) このようなコミュニケーションも中長期でみると無視できないコストになるため、定例などでメンバーと相談してチームとしての技術的判断を行い、固まったルールはESLintで縛る活動をイテレートさせました。
E2Eテスト (mabl) の導入
テスト実行の工数の削減、リリース時のテストの属人化の解消を目的に自動E2Eテスト「mabl」を導入しました。
参考: Intelligent Test Automation for Agile Teams | mabl
今期、新しく追加した機能の一部ではmablでテストケースを作り、独自の検証環境でE2Eテストがを自動実行できるようになりました。
宣伝ですが、導入を支援してくださった@hona_suke さんがmabl Experience '22に登壇します！
Webパフォーマンスの測定環境構築
これまでクラウド勤怠ではフロントエンドのWebパフォーマンスを計測する仕組みがなく、リアルユーザーのパフォーマンスを定量的に把握できない、リリースごとにパフォーマンスがどのように推移しているか把握できないといった課題がありました。これを解決するためにDatadogの「Real User Monitoring」を導入、一部ユーザーのWebパフォーマンスのフィールドデータを計測・蓄積できるようにしました。
Tailwind CSSの実運用
FY22下期が始まる直前、CSSの実装効率を高めるためにTailwind CSSを導入したのですが、さらにメンバーが新機能開発などでスムーズに利用できるようにGithubのWikiにコード規約を作成しました。
さらにTailwind CSSの静的解析の仕組みが存在しなかったので「eslint-plugin-tailwindcss」と「prettier-plugin-tailwindcss」を導入して、class名の並び順やその他記法などをESLintで程度縛る、自動整形できるようにしました。
API利用規約の作成
axiosの呼び出し箇所やAPIレスポンスの型適応に関するコード規約がなく、ページ毎に使い方が異なっており、新機能を追加で実装するときに開発メンバーが混乱して、余分なコミュニケーションコストが発生するという課題がありました。この課題を解決するためにaxiosの呼び出し箇所や型ファイルの定義箇所などをメンバー間で何度も壁打ちしながら設計を行い、規約をGithubのWikiにまとめ実運用できるようにしました。
Stimulus.js 3系へのバージョンアップ等
チーム内でしばらく放置されていた、Stimulus.js 2系から3系へのマイグレーション & メジャーアップデートをやり切りました。また他の勤怠が依存するライブラリもバージョンアップ対応 (Waringアラートの修正、セキュリティアラートの対応)を放置せずに、1つ1つ着実にバージョンアップを行うことができました。
勉強会の実施
メンバー全員でVue 3(Compostion API …etc)の知見を習得・深めるために「Design Patterns for Vue.js 3」という書籍を使って、勉強会を開催しました。(合計12回実施)
また次の勉強会ではメンバーのJS力を向上させるために「patterns」という海外の技術関連記事を使って、デザインパターンをJSで学びつつ、JSの言語仕様を深掘る勉強会を開催しました。(現在、第8回まで進行中)
技術ブログ公開
まだ公開されてないものありますが、本記事と下書きも含め合計5本、ブログ記事を公開しました。
- [勤怠FEギルド] 意外と知られていないVue.jsのRender Functionを紹介する
- [勤怠FEギルド] Jestを使ってファイル・ディレクトリの命名規約をテストする
- [勤怠FEギルド] TailwindCSSの導入とFigmaTokensとの連携
- 近日公開予定: 勤怠のディレクトリ構造について
活動の結果
今期、FEギルドで活動してきたことを振り返ると、以下のポジティブな結果を残すことができました。
- ローカル環境における生産性の向上
- コードレビューのコミュニケーションコストの軽減
- 心理的安全性の向上
- チームで溜め込んでいた技術的負債の解消
- メンバーのスキルアップとモチベーションアップ
- チーム認知度の向上
- 緊急度は低いが重要度が高いタスクの消化
ローカル環境における生産性の向上
コードの再利用性の向上や可読性の改善、おまじない的に書いていたボイラープレートの減少、コードフォーマッターが運用に載せたことなど、さまざまな改善が効いて、ローカル環境の生産性や開発者体験も大きく改善できました。
またコード規約が整ったことで新機能開発ときに以前と比べて、シームレスに設計・実装が実施できるようになりました。
コードレビューのコミュニケーションコストの軽減
静的解析等を充実させたことで、一部コーディング規約は自動でレビューされるようになったり、コードレビューをするときに説明がし易くなったり、レビュー依頼を出す前に自分で規約を確認できるなど、PR上でのコミュニケーションコストを削減することができました。
メンバーで同じ技術的な課題感を持って、PRレビューを行えるようになったおかげで、現状を考慮した上でのベストなレビューができたり、全体のアーキテクトの話に広がったりとコードレビューの質自体も向上しました。
心理的安全性の向上
勉強会や定例MTGを通じて、メンバー間での心理的安全性が高まりました。これにより日常の技術などのコミュニケーションも取り易くなったことで、1人で悩む時間が減ったり、メンバーがチャレンジしやすいチーム状態になりました。
メンバー間の距離感も縮まり、雑談や飲み会などでプライベートな話も交えて相互理解が深まり、確実にチームの絆も深まりました。
メンバーのスキルアップとモチベーションアップ
勉強会を通じて、Vue 3やJSのスキルを磨くことができました。勉強会ではJSの言語仕様について深堀りできたのも、自身の今後のキャリアを考えると非常にプラスになりました。
各メンバーが持つ知見をチーム内でシェアすることが活発に行われたのも、スキル向上のための環境作りとして、非常に良かったです。後日、メンバーから「機能開発の息抜き的にこのような取り組みができたことはモチベ維持として非常に良かった」など声をいただいたりしたので、中長期でのチームへの定着率の向上にも繋がったのではないかと思ってます。
チーム認知度の向上
技術ブログで外部発信をしたことで、SNSやトレンド記事サイトで拡散して頂いたりしたことで、社外への露出機会が増えました。昨季、採用面談などで技術ブログを見ましたなど、お声がけいただくことが良くあったので、定量的に把握するのは難しいですが、認知度向上に繋がったと思ってます。
緊急度は低いが重要度が高いタスクの消化
リリース時の手動テストの負荷を軽減するためのE2Eテストの導入やWebアプリケーションパフォーマンスの定常観測の仕組みなど、重要ではあるが、緊急度は高くはないため放置されてしまっていた開発チケットをギルド内の活動で完了させることができました。
参考: アンケートでの定量比較
チームのエンジニアに対して、以下の項目(10点満点)でアンケートを実施しました。
- No1: 既存コードの再利用ができていると感じるか
- No2: 業務で新しいフロントエンド技術が使えていると感じるか
- No3: コード規約などのドキュメントが充実していると感じるか
- No4: 業務でフロントエンドのスキルが付いていると感じるか
- No5: 開発環境が感じるストレスが低いか
全平均スコアが半年前と比べて、向上しました。
最後に
振り返ると、機能開発に大きなリソースを割きながらも、技術的な負債を解消していくという今回のギルドチーム制はうまく機能したのではないかと思ってます。機能開発で忙しいチームですが、日常的に時間を割いて、前々から溜め込んでいた技術的負債を返却し、中長期で見た時に機能開発のスピードを上げられる施作を進めることができたのは非常に良かったと思ってます。
また、開発生産性や開発体験は一気に改善されるわけではなく、日々に小さい積み重ねによって、改善されていくことを実感しました。もっと言えば、勤怠チーム全体でベロシティの仕組みを整備して、定量的に生産性の推移を測定できると良かったなと思いました。一旦、今期試験運用で結成されたチームのため、来期もこのチームが構成されるかはまだわかりませんが、チーム形態よらず常に生産性が高く、エンジニアがこのチームで働きたいと感じてくれるチーム環境作りに尽力していこうと思います。
最後までお読みいただきありがとうございます。
マネーフォワードでは、エンジニアを募集しています。 ご応募お待ちしています。
【会社情報】 ■Wantedly ■株式会社マネーフォワード ■福岡開発拠点 ■関西開発拠点（大阪/京都）
【SNS】 ■マネーフォワード公式note ■Twitter - 【公式】マネーフォワード ■Twitter - Money Forward Developers ■connpass - マネーフォワード ■YouTube - Money Forward Developers
