こんにちは。
Findy で Tech Lead をやらせてもらってる戸田です。
先日、弊社からFindy Toolsがリリースされました。
今回は、そのFindy Toolsがどのようにして開発されたのか、開発の背景や工夫点などを紹介していきます。
それでは見ていきましょう！
Findy Toolsの概要
紹介
Findy Tools は開発ツールに特化したレビューサイトです。第三者の視点で実際にツールの選定をした企業の生の声を集めることで、ツール選定に関する不安を解消し、導入検討に必要な情報を提供します。
「Findy Tools」を開発ツールの導入検討をしているユーザーが利用すると、実際にツール選定をした大手企業やメガベンチャー企業の技術責任者やエンジニアによるレビューを集めることができ、導入検討がスムーズになります。
また、開発ツールを掲載するベンダーには、実際の利用企業の声を活かしたコミュニティマーケティングによる新規顧客の獲得や、認知向上をご期待いただけます。
システム構成
システム構成は次の通りになっています。
- Ruby on Rails
- React
- Next.js
- App Router
- bulma
- GraphQL
- AWS
- S3
- CloudFront
- Aurora
- Fargate
上で挙げた構成に特に強いこだわりはなく、既存資産の流用をしやすかったことと、リプレイスや変更しやすいという理由でこの構成になっています。
APIとフロントエンドを疎結合で設計し、どちらか一方を作り直しやすくしたり、GraphQLを用いることでqueryそのものを変更することなく、呼び出し先のエンドポイントを切り替えることでアプリケーションの振る舞いを変えずにAPIを切り替えることができるような構成にしています。
開発
スケジュールとリソース
今回の開発はα版、β版と2回に分けて段階的にリリースしました。
α版は2023年9月から2023年10月で開発し2023年11月上旬にリリース、β版は2023年11月から2024年1月まで開発し、2024年1月下旬くらいにリリースしています。
開発リソースはα版は1人、β版は2024年に入ったあたりから2人で、それに加えてインフラ担当1人で開発をしました。
基本的にβ版リリースまではアプリケーション側の1人で開発していました。
新規サービスが当たるかどうかは実際に世に出してみないとわからないので、「最小限のリソースで最速でリリースする」という方針でした。
開発のポイント
既存資産を活用
最小限のリソースで、最速でリリースするという方針だったので、まず「全てを1から作る」という選択肢は可能な限り避けました。
幸い弊社には既に運用されてるシステムがあり、そこからの流用を決めました。
具体的には次の内容を流用しました。
- アプリケーションの実行基盤まわりの共通コード
- フレームワークの各種設定ファイルや設計思想
- デプロイやCIのワークフローのコード
共通コードや各種設定ファイル、設計思想は既存の各サービスでほとんどが統一されており、コピペして少しいじったらすぐに使えるような状況に整備されています。
またデプロイやCIまわりは全てGitHub Actionsに統一されており、こちらもワークフローのファイルをコピペして少しいじるだけですぐに使えるようになっています。
これらの既存資産を流用することで、コードを書き、テストで守り、動作環境にデプロイし、最低限動くものを確認できる環境をすぐにセットアップできました。
ゼロからモノを作るうえで動くものを用意することは非常に重要です。動くものをメンバーと共有して確認することで、認識の齟齬を防ぎ、余計な修正作業を減らすことが出来ます。
データ投入を簡略化
データ投入は開発の中でも時間を取られる作業の1つです。
レビュワーの方から頂いたレビューデータや、各種マスターデータをデータベースに投入する必要があります。
α版の時点ではデータ投入を簡略化するために、全てのデータをseedで投入することにしました。
本来であればデータ投入用の管理画面を作るのがベストなのですが、α版のリリース前に1人で開発してる状況で管理画面を作るようなリソースはありませんでした。
機能の取捨選択
初期リリースの目的は多くのユーザーを獲得することではなく、「サービスが受け入れられるかどうかを可能な限り早い段階で判断する」ことにあります。
そのため、「サービスが受け入れられるかどうかの判断に必要のない機能」を初期リリースのスコープから外しました。
具体例を挙げると、β版リリースまでは画像アップロードの機能を外しました。
レビューデータやアバター画像などをアップロード出来るようにしたかったのですが、画像アップロードを実現しようとすると、色々と考えないといけないことがあります。
画像のアップロード先はどうするのか？削除は許可するのか？画像サイズはどこまで許すのか？などなど色々出てきます。
今回は画像のアップロードを許可せず、運営チームが用意した画像をS3に直接アップロードして、そこへのパスをseedに直接書くことで画像ファイルの管理を単純、簡略化しました。
この機能を簡略化するだけだと良くて1,2日程度の開発工数削減に留まると思います。しかし、このような取捨選択をいくつかすることによって、結果的に半月や1ヶ月程度の工数削減に繋がりました。
この機能を削減して大量に工数削減、といったものではなく、ミニマムな削減の意思決定を大量に行うことによって実現しているのです。
テストコード
色々な取捨選択の意思決定の中で、テストコードだけは切らずに必ず用意していました。
「時間が無いからテストを書かないのではなく、テストを書かないから時間が無い」というのは事実で、結果的にテストが守ってくれているおかげで、余計なことに時間を取られずにやりたいことに集中できるのです。
テストコードのお陰で、α版リリース以降に本番環境で発生した不具合、障害は記憶しているだけですが片手で数えられる程度でした。
管理画面を内製
α版のリリースにより、「このサービスが世に受け入れられる」ことを確認できたため、β版のリリースに向けて着手しました。
α版からβ版に向けて何を実現させるのかを検討している間、開発するものがなくて時間を持て余していたので管理画面を内製で実装することにしました。
各種マスターデータやレビュワーの方から頂いたレビューデータなど、運営で管理したいデータは多数あります。
それらの変更のたびにseedの再実行、データの変更を依頼するようなフローにしてしまうと、エンジニアが機能追加の作業に集中できなくなってしまいます。
β版リリースからはエンジニアを介さずにデータの追加、変更を運営メンバーだけで完結出来るようにしました。
管理画面の画面数は25個程度で、APIとフロントエンド込みで1人で2、3週間程度で開発しました。
管理画面はSSRが必要ないので純粋なReactのSPAで、CSSフレームワークにBulmaを採用しました。
管理画面を用意できたことによって、β版以降の開発時に運営メンバーからのデータ管理周りの依頼が無くなるので、開発作業に集中できるようになりました。
反省点
Findy Toolsの開発では、チャレンジ枠としてNext.jsのApp Routerを採用しました。
既存プロダクトに用いられているPages Routerからの移行を検証する狙いもありましたが、今回は上手くいかなかったと反省しています。
誤解を与えないように言うと、Next.jsのApp Router自体は悪いものではありません。
何が上手くいかなかったかというと、既存資産の流用をした結果、利用していたライブラリがApp Routerに対応出来ておらず、想定していた以上の工数を取られてしまったことです。
弊社ではApp Routerを初めて採用したケースであり、社内にノウハウが蓄積していなかったため、問題解決に時間がかかってしまいました。
今後、他サービスでのApp Routerの採用時に今回のノウハウを活用できるようになったと思いますが、今回のような開発スピードを優先されるケースで採用するべきではなかったかなと思います。
まとめ
いかがでしたでしょうか？
新規サービスの開発時にはリソースやスケジュールに大きな制約が課せられます。そのような状況下でやるべきこと、やるべきではないことの取捨選択の意思決定が非常に重要になってきます。
半年近く1人で開発をしてきたFindy Toolsですが、みなさまのおかげもありサービスが順調に成長しており、今では開発に着手しているエンジニアの人数を増やすことができました。
今後もFindy Toolsをより良いサービスにしていくために、引き続き開発を進めていきます。
現在、ファインディでは一緒に働くメンバーを募集中です。
興味がある方はこちらから ↓ herp.careers
