ココナラ募集をリリースするまで
こんにちは。ココナラ募集部 開発チームのかやです。
今回は、まだリリースされて間もないココナラ募集のリリースまでの経緯や工夫したことをお伝えしたいと思います。
どんな体制で開発をしたか？
事の始まりは2023年。
ココナラの新しい機能として「ココナラ募集」の企画が立案され、各部署からメンバーが集められました。これまでココナラではサーバーサイド、フロントエンド、ネイティブアプリ等といった各分野の専門スキルを持ったメンバーが集まり、コミュニケーションを取って機能開発する事が多かったのですが、今回は少ないメンバーで多くの機能を開発する必要がありました。それぞれのメンバーが専任スキルを持っていることは良いことですが、例えば「APIのI/Fはどうするか？」、「〇〇の実装はFEでやるべきか？それともBE？」といったコミュニケーションコストが掛かってしまう面もあります。また、自分の専門領域とは違う分野を考慮できず、開発したい機能やサービスの設計を俯瞰的に見づらいという側面も考えられます。
このようなコストや懸念を考慮しつつ開発スピードを落としたくないという目的から、ココナラ募集の開発メンバーはフルスタックな技術力が求められました。
広い技術スタックを持ったテックリードを中心に、各分野のメンバーが集まってBeyond Bordersのバリューのもと、技術的なノウハウを共有しながら開発を進めていきました。正直、技術スタックのキャッチアップは大変でしたが、得意領域の幅を広げられ、かつ新規サービス開発という非常にエキサイティングな経験でした。
どんな事に気をつけたか？
そして開発がスタート！
紆余曲折があり、全く別のサービスとして開発したり、途中で仕様が大幅に変わる等の困難もありましたが、最終的にはココナラの中にある新しい機能という位置付けになりました。
ココナラは既に10年以上稼働してるWebサービスです。古くからある機能がたくさんあり、その規模もどんどん大きくなっています。
マイクローサービス化を推進していますが、まだまだ適切なサービス分割が間に合っていないシステムも多く、大きなモノリシックなシステムになってしまっているのが実情です。この大きなモノリシックシステムにまた新機能をリリースするとなると、以下の様な問題が発生します。
- 別で進行している実装・リリースとのコンフリクトが多発
- 負債化してしまっているコードに依存した実装になりやすい
- 新しく適用したいルールや実装パターンを適用しづらい
そこで愚直なやり方ではありますが、新規サービスで開発する機能に関して新しくnamespaceを切って必ずその配下に新規機能を実装するというルールを徹底しました。また、クラス名なども新規サービスに関連する共通ワードを設定して、クラス名などのプレフィックスを必ず付けるようにしたり、例外発生時はそのプレフィックスをつけた例外クラスが発火される様にしてリリース後の識別もしやすくする工夫を取りました。
リリース🎉...そしてマイクロサービス化
そして数ヶ月の実装の末、無事にココナラ募集のリリースが完了しました！とても喜ばしい事でしたが、戦いはこれからです。
リリースしたココナラ募集をスピード感を持ってグロースしていくには、リリースサイクルも細かく実施していきたいです。しかし、先に述べた通り既存機能も沢山ある大きいモノリシックなサービスに対して多くの開発者が実装しているため、リリースタイミングなどのバッティングなどが頻発し、なかなか思う様に事を運べないという問題がありました。そこで、ココナラ募集をマイクロサービス化することにしました。
出来るだけ早くマイクロサービス化したかったため、リポジトリをコピーして新しくココナラ募集専用のリポジトリとして運用し始めました。そして、リバースプロキシを使ってパスごとに分岐する方法を採用。
これまた愚直なやり方で、かつ新しいページやAPIが実装された際はリバースプロキシの設定も必須になってしまいます。が、上記の問題をいますぐにでも解消したかったため、こちらもスピード最優先で乗り切りました。
新しい環境を求めて...
無事にマイクロサービス化ができ、ココナラ募集チームとして管理しやすい体制と構成になりました。しかし、ここでまた問題が...。
新しく分離したサービスは負債化してしまっていると言えるライブラリやコードなども存在しています。そのため、ココナラ募集のグロースとは別に負債の解消もタスクとして上がってきます。単純なメンテナンスでは限界があり、これが今後の技術的課題となっていきました。
この課題に対応するために、私たちは徐々にNext.jsやNest.js（GraphQL）を使った新しい技術スタックへのリプレイスを進めることを決定しました。ストラングラーフィグパターンと呼ばれる方法で、既存のシステムから新システムへの段階的な移行を可能とし、リスクを最小限に抑えながら移行を進める方法を取っています。また、フルスタックでフロントエンドからバックエンドまで統一された技術スタックを採用することで開発の効率化も期待しています。
戦いはまだ始まったばかり...。
ここまで新規サービスとしてリリースしたココナラ募集について大まかに流れをまとめてみました。真新しい技術を採用したというわけでも無いし、「そもそも何故最初から別サービスとして実装しなかったのか？」などのマサカリも飛んできそうですが。
色々と改善や反省の余地もあり、かつ多くの学びと達成感を得られた良いプロジェクトだと思っています。
新しい技術スタックへの移行もまだ始まったばかりです。今後も多くの課題や調整が予想されますが、これからココナラ募集の成長に邁進していきたいと思います。
そして、ココナラ募集を一緒にグロースしていく仲間も絶賛募集中です！興味のある方は是非、カジュアル面談からでも🏃➡️
Discussion