Findy 2021年上半期の開発施策を振り返る -前編-
こんにちは、Findy CTO の @ma3tk です。半年でトレーニングのやり方もガラリと変え、新しいことを始めたり、トレーニングのルーティンを変更したりなど新しい変化をしてきました。
本日は、Findyのエンジニアリング組織が2021年の7ヶ月弱でどんな開発者体験向上のための施策を行ってきたかについてご紹介したいと思います。本日は前編として4ヶ月を振り返ってみます。
リリース頻度が1週間に1度状態だった2021年当初
今年の頭のFindyのプロダクト開発チームは、以下のような状況でした。
・サービスを利用いただけるエンジニアユーザの方や企業の方が増え、内部のメンバーも増え、過去課題にならなかった内容を素早く解決する必要が出てきた
・サービスリリースから3年半が過ぎ、フロントエンドもバックエンドもライブラリや利用しているインフラなどのバージョンアップが課題となっていた
・リリース作業が丸一日かかり、中でもウェブアプリのビルド時間が30分以上かかっていた
この状況の中、サービス開発するメンバーとしては、
・このままサービス開発して何が起こるかわからない状況に不安を感じていた
・毎週のリリース作業に負荷を感じていた
・新しいことにチャレンジしたくてもチャレンジしにくさを感じる
このような心境で開発を行っていました。この状況を打破するために、7ヶ月での基盤の変化について記載してみます。
2021年 1月: 上記の環境の課題で危機感
Findy は今後上場に向けて大規模なサービスとなって提供していく上での大事な基盤をテコ入れする必要があるんじゃないかと感じていました。
イシューが100以上あり、中でも古いものは数年前のものも存在し、やりたいことリストには入っているが、着手ができていない状況でした。思い切って100以上のイシューで「やりたいけど急ぎではない」というMUSTではないタスクを一度スプレッドシートに移し、「やるべき」というMUSTなタスクのみに絞ったものをイシューに残すという状況にしました。
いきなりメンバーにはイシュー整理大会を数時間かけて行いましたが、それでも半分近くが「いつやるか」…否、「いつやれるか」が未定なものが多かった状態でした。
一度のリリース作業で1日かけてリリースしていたり、CIも30分〜1時間かかって回っていた状況だったため、レビューもすぐにできない状況で、これらの課題を紐解いていくと、結局はリポジトリ内にフロントエンドとバックエンドが共存し、それぞれの修正に対して直接関係ないユニットテストが複数実行されていたり、一部フロントエンドとバックエンドが密結合になっている為でした。
そしてフロントエンドとバックエンドのリポジトリ分割を行い、この肥大化したプロジェクトではモノリス環境を脱することにしました。
とはいえリリース作業は定常的に行わないといけないので週1回時間をかけて実施している状況でした。大きくやったことは1ヶ月でどんなタスクを回しているかの確認と、何をやらないかを改めて整理したことでした。
2021年 2月: どこまで何ができるかの検証の実施
リポジトリ分割そのものがサービス全体に影響するため、別チームで分割の知見のあったメンバーと相談し、タスクを洗い出すことからスタートしました。
最低限どこまでをやるか？でゴールを決めることから。
こういう大きい移行や作り直しなどを行う体験は過去何度かやってきましたが、大事なことは、「新しいことをなるべくやらない」ということ。
今回のリポジトリ分割においても、必要最低限で進めて、最低限がクリアできないなら新しいやり方を取り入れる。「これもついでにやっちゃおう」は初期段階ではなるべくやらずに必要になったタイミングで都度チームで相談し、工数が膨れ上がらないように調整するようにしていました。
この検証の結果、以下のようなスケジュールでフロントエンドとバックエンドのリポジトリ分割を行うことにしました。
・3月頭: エンジニアユーザ側のベースコンポーネントを新規リポジトリで作成(サーバサイドレンダリングなどが要件にあるが、とりあえず移行)
・3月頭〜半ば: ユーザ側をNext.js化する(サーバサイドレンダリングを入れる)
・3月半ば〜末: 企業側のベースを作る(サーバサイドレンダリングはないのでもう少しシンプルに行けそうと判断)
・4月: QA、リリース
をしていくような形で進める状態にしました。
今思えばなかなかタイトでしたが、数もそこまで多くないし、過去に別チームで同様の対応を行ったので問題ないかと判断しました。このどこまでの影響範囲かを調べることが地味に時間がかかっており、技術検証とやるべきことをフォーカスしたTODOリスト作りを行いました。
2021年 3月: エンジニアユーザ側を作る→見積もり不足
実際にここから実作業に入っていきました。エンジニアユーザ側はおおまかに、50パターン前後くらいあり、認証系が一番重い印象でした。
ページの移行自体はそこまで難しくはなかったように感じましたが、数をたくさんこなす部分で時間がかかったような状況でした。
その他、このエンジニアユーザ一番苦労したのがビルドフローの構築が一番時間かかっていた状況でした。設定したこともない設定ファイルを設定する必要があったので、ここのキャッチアップが一番難しかったのではないかなと感じています。何がわからないのかわからん状態が続きました。
さらに、様々な作業の着手をしていくと「これもやらなきゃだめだ」「これもじゃん」というのが結構多くて想定の見積もりがシビアな状態でプラスでやるべきタスクが増えていったところもあり、ページ全体がどうなっていたかを理解しきれてないまま作っている状態でした。
2ヶ月くらいで移行しよう、という意識が先行しすぎて正しく見積もりがこの時点ではやりきれてなかった気もします。ビルドフローの構築、実際のコード修正を行いながら、バックエンドではAPIの認証機構を変え、APIの作りも根本的な部分で変えたりしました。
2021年 4月: QA作業→未完成の部分が目立った&GWがあったため延期
4月に入ってQAを行っていくと、どうしても目をつぶっても現状のクオリティだとリリースできない状態かも、ということで2回ほどリリースを延期を選択せざるを得ませんでした。
一見普通の表示はできていても、
・データが変わるとうまく表示できない
・移行されたタイミングとカニばってうまくログイン・ログアウト・表示ができない
・機能がそもそも動かない
などの状態が多々ありました。元々の保守性の低いコードも一部あり、さらにタイトなスケジュールですべてを考慮して正しく動く状況に仕上げるのが難しくありました。
作る時点で「これを検証できればOK」のボーダーがなかったことが大きい気がしていますが、スタートアップ初期からそれがテキストでまとまってるかといえばまとまっていませんし、それを作ろうとすると「ユニットテスト」や「E2Eテスト」による品質保証が行われている必要がありますが、品質保証をしやすい環境にすべくリポジトリ分割をしている、、、という鶏卵状態でした。
4月後半のリリースは難しく、29日からゴールデンウィークが始まり、最低でも10日ほどは影響がないかのリリースの確認が必要だと判断したため、GWを開けて十分にテストをして問題ない状況でリリースするということで5月中旬に再度リリース日を定義しました。
QA、バグフィックス、足りてない機能の把握と即時実装、これの繰り返しでした。
4ヶ月での進捗は仕込みがほとんど
この4ヶ月で実施したことは、ほぼほぼ地道な設定作業ややるべきことの可視化と愚直な実装がほとんどでした。書いていく中で大きなインパクトがあることは明日の記事でお伝えしますね！
※先にこの施策の結果を知りたい方はこちらの記事に書いています。是非どうぞ！
エンジニアも同時に募集しています！
もしここまで読んでいただいて、少し話してみたいという方は是非一度お話しませんか？
是非興味があれば Twitter でご連絡いただいたり、直接ご応募いただいても大丈夫です👍
エンジニアだけでも20人規模で募集しています。是非お気軽にどうぞ〜！一緒に熱いルーティン回していきましょう！