Findy 2021年上半期の開発施策を振り返る -後編-
こんにちは、Findy CTO の @ma3tk です。次の日に出そうとして色々編集してたら失敗しました…！🥺✨
本日は、Findyのエンジニアリング組織が2021年の7ヶ月弱でどんな開発者体験向上のための施策を行ってきたかの続編(2021年5月以降〜7月)について直近3ヶ月を振り返ってみます。
2021年 5月: リポジトリ分割に向けて細かいポイントの修正
実は4月くらいでほぼ潰すべきことを潰し終わり、リポジトリ分割もあとは本番でユーザテストを待つだけという状況でした。時間を延期した分、新しい価値を先に作ろうということでUI改修やCIの改善などを行いました。分割するだけなら本当はこの改修をやるべきではないのですが、クリティカルな部分が完了したため、問題ないと判断しました。
内部ではリポジトリ分割を行い、CI環境もそれぞれ分割し移行し終わりました。高速化のための対応はこのようなものも入れました。
・テスト実行時の並列数を増やす
・Elasticsearchのテストの高速化のためにindex作成回数を減らす
・E2Eテストは特定のブランチなどで条件指定
・rspec-retryなどでテスト再実行を減らす
・実行が遅い箇所（SQLが重いなど）の把握、改善
・重いテストはCIで毎回回さないように条件指定
・テストのワークフローを分ける
・使用していない機能のテストを特定し、実行させない
フロントエンドとバックエンドでリポジトリを分けたことで、CIは30〜1時間ほどかかっていたものが、4〜8倍早く、7〜10分前後で完了するようになりました。
またリリースするにあたってリリース作業の1つ1つをドキュメントに落とし、当日は画面シェアしドキュメントにチェックを付けながら内容をコピペするだけというお手軽リストにして作業の共有を行いながらリポジトリ分割した状態でサービス提供を行いました。
いくつか対応漏れが後に発見されましたが、大きな問題にはならず解消できました。
この月はほぼ毎日上がってくる課題やバグを即時修正し、5月はほぼ新規で何かを行うというよりは保守やリポジトリ分割後の後片付けを行っていました。
2021年 6月〜7月: 古いライブラリの更新と新環境への移行
徐々にリポジトリ分割後の課題も減ってきたので、新しいことにチャレンジしてきたのがこの6月です。相当テコ入れが進んでいます。この2ヶ月一緒にしちゃっていますが、数週間ほどかけながら解決しているものもあるので、分けて書いていきます。
1. フロント: Nxの導入
Nxを入れ、フロントエンド内で複数のパッケージを同梱させる状態にしました。これにより、リポジトリ内で様々なパッケージ化を行い、関係あるパッケージでまとめられるようになりました。
2. フロント: FlowTypeの削除
過去FindyがTypeScript化できていなかった理由の一つでもありますが、FlowTypeを導入していたことにより、TypeScriptに移行できなかった背景があります。一気に移行できるかと思いましたが、Reduxなどがある関係でうまく進まず、一旦FlowTypeを削除して生JavaScript状態に戻しました。一時的に型がなくなりますが、後々TypeScriptを入れるので良さそうと判断しました。
3. フロント: Reactクラスコンポーネントの廃止と関数コンポーネント化
関数コンポーネント化する上でクラスコンポーネントで利用されていたライフサイクルを排除し、hooksにほとんどを移行しました。元々クラスコンポーネントをさらに強化していく思想になりそうと判断したのでクラスコンポーネントに密に紐付いた形で作られていましたが、Reactの方針と合わない改修を行っていたために、クラスコンポーネントから抜け出せずにいました。ここはReactが得意なメンバーが少なかったため、しかたなかったところではありましたが、クラスコンポーネントを廃止できたため結果オーライかなと思っています。
4. フロント: TypeScript化
2つのフロントエンドリポジトリのうち、まだ半分ほど残っていますが、1つのリポジトリでは3週間ほどでTypeScript化を完了しました。APIがそこまで複雑になっていなかったり、もう一方と比べるとコンポーネントがきれいな状態であったため、半分だけTypeScript化を完了させました。
5. バック: API追加とパフォーマンスチューニング
ユーザ数がここ1年で相当増え、サービスとしても驚くほど大きなものになってきていました。そのため、元々の設計で「一旦大丈夫でしょ」と思って作られていたものが使用限界になっていました。パフォーマンスとしてもAPIレスポンスとしてもなかなか使いにくく、RESTfulでなかったりフロントエンドに相当負荷をかけているような実装だったり、N+1が起こっているままにしていたりなど細かいところに気を配らないと早く安全な改修しやすいサービスにならない状態でした。各箇所の修正を行い、問題なくサービスが使えるように修正してきました。
6. バック: バッチの高速化
ユーザ数が多くなったことで問題化したものもこのバッチ処理です。直列に全データを捌いたり、事前にデータを処理できる箇所は処理するなどを行っていましたが、
・事前に処理を行っていかない部分を処理していた
・全データを並列にしないと期待する時間内に終わらない
・長時間化することでDB負荷やサーバへのデプロイができない
という課題に追われていました。そのため、実行して問題ないかチェックする作業が一番かかるバッチ処理を並列に高速化し、短時間で処理が終わるように改善しました。改修のコードの変更自体は大変じゃないのですが、検証がめちゃくちゃ大変でした。
7. フロント&バック: dependabotの運用
テストも充実してきたし、フロントエンドとバックエンドで分割もできたので、デイリーでdependabotを活用し、バージョンアップ追従を行ってきました。これにより、ライブラリ系は6〜7割ほどは最新、残りはメジャーバージョンアップのための対応が必要で徐々にアップデートを行っていきました。
8. フロント&バック: Daily Releaseの運用
これもCI環境が十分高速で安心して毎日リリースして価値を提供できるようになったため、ほぼ平日は毎日リリース作業を行っています。週に何回と決めたりせずに、リリースすべきものが少し積まれたらリリース作業が大変にならないように細かくリリースを行っています。細かすぎても大変なので、多くならない程度・フロントエンドの開発に影響が出ない程度にリリースを実施してフロントエンド・バックエンド共に月間15〜20リリース程度は行うようになりました。当初は月4〜8回程度なので、単純に2〜5倍くらいの回数リリースできるようになりました。
今後やっていきたいこと
無限にやりたいことややるべきことがあるのですが、2021年でやっていきたいことを書いてみます。
1. ユーザ体験の向上のためのフロント&デザイン改修
Findyもリリースして4年、デザインをちょくちょく改修してはいますが、細かいこだわりをまだ実現できていなかったりします。もっとこうしたらユーザにとって使いやすくなるのに、こうあったらユーザにとって新しい価値を提供できるのではないか、、、様々なことが頭をよぎりますが、それを実現するためにはある程度基盤が整うことが大事でした。
今となっては十分提供できるようになってきたため、さらにこの使い勝手の部分を根本からリニューアルしていければと思っています。しかしながらこの細かいこだわりを実現するためにはメンバーが足りていません……！！！構想はあるのですが、早く実現したいと思っています。
2. GraphQL化とデータ処理の高速化
パフォーマンスチューニングも行っていますが、増え続けるデータ量に対して、まだまだバックエンドがやるべきことが多くあります。その中でも複数のユーザに対して提供されるAPIエンドポイントを作りOpenAPIでスキーマを作る方向ではなく、GraphQLなどで型をフロントエンドに提供しながら必要なデータを取得できるようにし、その処理を高速にしていく動きです。
APIに無駄がありそれがボトルネックになってしまうと、次の施策に移っていくことも難しくなるので、こういった要素はすぐに解消し、新しいチャレンジができる仕組みにしていきたいと思っています。
3. AWSなどのインフラ改善
様々な要素がインフラにあるのですが、AWSに乗せてるサービスでも改善のボトルネックになっていたり、構成がいまいちな状態であったりなど現時点でギリギリの運用になっている部分もあったりします。
古くなったインスタンスから新しいものに変えたり、バージョンアップがしきれていない部分や責務が全てよってしまった部分を直したりなど、今後やれることがわんさかあります。
やっていはいるんだけど、人数が少なくて環境が変わってきたことに対してインフラは爆速対応が追いついていないところが課題です。ユーザ数が増えると単純な移行でも大掛かりになってしまうので、計画を立ててこの大掛かりな対応を問題なく終わらすことができる体制が求められています。
4. 社内管理画面の充実
ユーザが増えるとともに、社内ツールにもより一層価値が出てきます。このデータは取れないんだっけ？誰がどれをやっているんだっけ？というCRMや状況把握のためのダッシュボードの整備です。
現状スプレッドシートなどのスクリプトで可視化したりもしていますが、チーム内で閉じたデータだったり、スクリプト以上のことをやろうとするとどうしてもエンジニアの力が必要になりスクリプトに手を入れるのではなく管理画面でかんたんに把握できるようにする必要があります。
しかしながら、今のFindyの管理画面は管理画面用のライブラリを利用し初期に作ったままです。さらには、一部魔改造が含まれています。この状況を打破するには内部用の管理画面が必要になります。正社員の人数も50人を超え、業務委託やパートタイムアルバイトを含めると、100名を超え、業務改善をどう行っていくかで社内の生産性が一気に変わります。(初期なんて別に使い捨てのスクリプトと気合と根性でどうにでもなりましたが、今のフェーズでは運用でカバーが無理な部分が多々あります…)
課題は山積み！エンジニアを本当に本当に募集しています！
もしここまで読んでいただいて、少し話してみたいという方は是非一度お話しませんか？まだやりたいことがある中でサービスが育っていっている状況が非常に(いい意味で)辛いです！助けてほしいです！
是非興味があれば Twitter でご連絡いただいたり、直接ご応募いただいても大丈夫です👍
エンジニアだけでも20人規模で募集しています。是非お気軽にどうぞ〜！
【エンジニア組織全体】
・CTO候補 - https://herp.careers/v1/findy/MH-u5skw__Ed
【Findy 転職】
・エンジニアマネージャー - https://herp.careers/v1/findy/eRbKaEKEE6D6
・バックエンドエンジニア - https://herp.careers/v1/findy/MgtDp5Eh2cYC
・フロントエンドエンジニア - https://herp.careers/v1/findy/H5DgEiQpboQ1
・プロダクトマネージャー - https://herp.careers/v1/findy/orzBujKLKmq2
【Findy Teams】
・エンジニアマネージャー - https://herp.careers/v1/findy/ypgJQ5_ObYex
・バックエンドエンジニア - https://herp.careers/v1/findy/xOHUsVQEBA9R
・フロントエンドエンジニア - https://herp.careers/v1/findy/n3GYFS0yUnAH