はじめに
TalentXでCTOをしている籔下です。
3〜4年ほど前にtech blogを数本書いたまま更新ができていなかったのですが、この数年でエンジニアの人数も3〜4倍ほどになり、新しいプロダクトのリリースや社名変更、インフラのアーキテクチャリプレイスなども行い、大幅にアップデートしています。
これらのアップデートにとどまらず、今後も様々なチャレンジを控えており、これからもっと発信していきたいということでtech blogを再開することにしました。
新装第一弾ということでこの3〜4年の取り組みなどをまとめてTalentXのプロダクト開発の現状を伝えていきたいと思います。
開発組織
現在の開発組織の体制やリモートの状況などをお伝えします。
体制
前回のtech blog記載時点では運用しているプロダクトはMyReferしかなく、スクラムチーム2ライン体制で新規機能をひたすら開発しながら事業を牽引することにほぼ全リソースを費やしていました。
当時正社員のエンジニアは4〜5名で、この人数と同人数程度の業務委託者で構成していました。
現在TalentXはMyRefer、MyTalentという2つのプロダクトに加え、それらのプロダクトをMyシリーズとして認証を統合し一つのプラットフォームとして展開しています。このMyシリーズの共通管理画面をアーキテクチャ上、1つのプロダクトとして開発を行っており、計3つのチーム体制となっています。加えてプロダクトチームに所属せず、横断的に活動するメンバーもいます。
リモート
現在一部地方在住者も含むリモートワーク中心になっています。
コロナ禍以前より試験的に週一でリモートワークを取り入れていたのですが、その後コロナ禍に突入し、週一の制約をなくし、実質フルリモート可の現状へと変わっていきました。
ただ出社不可とした訳ではないので、現在もですがほぼ毎日出社する人もいれば週一で出社する人もいれば月に一回出社するかどうかの人もいるという自由な形をとっています。
そのため、地方在住の方も採用ターゲットに含めて採用活度をしており、実際に地方よりフルリモートで業務をしているメンバーもいます。
今後に関してはオフィス環境や組織のスケール、全社の方針に基づいて適宜形を変えながらにはなると思いますが基本方針として組織の生産性を第一に考え、個人が選択できる制度にしたいと考えています。
開発プロセス
開発プロセスに関しては全チームでスクラム開発を採用しています。自分がジョインしたタイミングで既にスクラムを取り入れていましたが、元々前職時代に自分が認定スクラムマスターを取得していたこともあり、tech leadになったタイミングでより本格的に導入を始めました。
現在3つのスクラムチームがあるので各チームごとに違いはありますが（プランニングにかける時間とか、レトロスペクティブのやり方とか）、1week sprintで毎週プランニングと共にSprintが始まり、Sprint終わりにレトロスペクティブをして終わる流れは全チーム共通です。
採用技術
複数のプロダクトチームに分かれており、プロダクトの要件や参画メンバーのスキルセットに応じて多少プロダクト間で差分はありますが、基本方針としてフロントエンドはReact, バックエンドはGo, クラウドにはAWSを採用しています。
MyRefer
アプリケーション
私がジョインしたタイミングでMyReferはFuelPHPを利用し、プログラミング言語はHackで実装されていました。
FuelPHPもメンテされていない＆Hackも導入した人間は既に社におらず、新しいバージョンがPHPとの互換性を外すという発表があり、このままHackをバージョンアップしてもFuelPHPのフレームワークを使いながらの開発は難しい状況になっていました。
またフロントエンドに関しては徐々にjQueryからReactに移行し始めており、このままFuelPHP+Hackの構成からSPA構成へとリプレイスする方針で動き出しました。
バックエンドに関していくつかの選択肢があったのですが以下の観点でGoを選択することにしました。
- 将来の事業構想
- 文化・ルール
- 好み
将来の事業構想
当時、今後複数事業立ち上げ計画があり、独立した事業ではなく既存事業とのシナジーを生み出す位置付けであったため、プロダクト間の密な連携などが想定されました。
複数のサービス間が連携し合うような構想を想定したときに、マイクロサービス化を考えましたが、まだ組織的にもそこを進めるのは課題が多く、まずは共通的な機能からでも汎用的なサービスとして切り出したいと考えました。その際、バックエンド間通信をgRPCで実装するところも構想にありGoに親和性があると判断した部分は大きいです。
文化・ルール
FuelPHPがだめならHackをPHPの最新バージョンへの移植を行い、フレームワークにLaravelを採用することも選択肢としてはありました。何なら最も現実的な解だったかも知れません。
この選択肢を選ばなかった理由として、創業当初から（創業当時はほぼ業務委託社で開発していたため）人の移り変わりも激しかったため、コードの統一感が徐々に崩れてきていました。創業初期ということもあり基準となる考えなどの明文化まで手が回っていなかったため、このタイミングで自分達でコードに対する文化やルールを一から策定していきたいという思いがありました。HackからPHPへの移植はある程度互換性があるので、スピード優先で既存コードを流用してしまうことは容易に想像でき、であれば別言語にして、改めて自分達の文化・ルールを策定しながら技術的選択を意志をもって進めたいと考えたためです。
好み
自分がGo言語が好きだったという理由も包み隠さずここに記載しておきます（笑）
（他のメンバーとも話し合って満場一致で決まったのでトップダウンで無理やり決めたわけではないです）
現時点でのステータスとしてはフロントエンドはほぼほぼReactへの移植を終えており、バックエンドはGoへの移植が開始されたフェーズで数本のAPIがリプレイスされている状態となります。
AWSへのリプレイス
MyRefer創業以降さくらのクラウドを利用して運用していましたが、2022年10月にAWSへのリプレイスを完了しました。
リプレイスを進めた当時の課題感として以下がありました。
- エンジニアの人数が数名の頃、インフラの運用やセキュリティ周りを自分一人で対応しており、今後SREなど専任の採用も考慮した時にデメリットが大きいと感じた
- 元々DBの冗長構成がMariaDBのGarela Clusterで組まれていたが、データ量増加に伴い、重たいバッチ処理など裏側の同期の性能が追いつかず、途中で落ちるなどの弊害が出てきた
- さらに複数台で構成されていたDBのうち1台がお亡くなりになり、新たにDBサーバを構築してクラスタに組み込もうとしたが、データ量が多すぎて同期の途中で異常終了し、クラスタに組み込めず、今後のサービススケールに危機感を感じた
さらにリプレイス先としてAWSを選んだ理由としてはAWS Activateを申し込んでおり、既にアプリケーションのUnit TestでGitLab Runnerを利用しており、その構築での利用やアクセスログ分析などでAthenaを利用するなど利用が進んでいたのがほぼほぼの理由です。
（ActivateがシリーズA着金時点が利用開始日になるのを知らず、まだ1年経っていないタイミングで課金が始まってビックリした記憶があります）
またMyReferリプレイスより半年ほど前の2022年2月には新規事業としてMyTalentをリリースしており、こちらもAWSで構築しております。
加えて今年の2月末にMyRefer, MyTalentの認証を統合し、Myシリーズプラットフォームとして展開しており、これらを全てAWSで構築・運用しています。
AWSのリソース管理はTerraformを利用しています。
Flutter
MyReferでは導入企業様の従業員向けアプリがあり、こちら元々iOSはSwift、AndroidはJava + Kotlinで開発していたのですが、Flutterでスクラッチから開発をし、2023年6月にリプレイス版をリリースしました。
リプレイスした目的はこれまでアプリの開発は業務委託者にお願いしており、AndroidエンジニアとiOSエンジニアそれぞれ抱える必要があり、かつロードマップ上アプリの新規機能が定常的に行われることが少なくなり運用中心になってきたことから、週5フルタイムで参画いただく必要性が薄れてきていました。
また月一で社内勉強会を実施しており、その中でメンバーからFlutterをテーマとした発表があり、また1on1で別のメンバーとの会話の中でFlutterに興味があるという話題があがったことから、Flutterに移植を進める意思決定をしました。
もちろん未経験者のみで進めるにはハードルが高かったので、お手伝いいただける方に入っていただき、メンバーにキャッチアップしてもらいながら約一年がかりでなんとかリプレイスを完遂しました。
技術的負債ばかりやってないか？
上記の通り、かなりの部分（というか全部？）を作り直したり作り直し中ですが、開発業務の多くは新規機能開発に割り当てています。
現在はMyReferというプロダクト単体での開発というよりMyシリーズとしてコンパウンド型のSaaSへと発展を遂げ、全プロダクト横断でプロジェクトを進行しています。
コンパウンドに関しては弊社代表鈴木のブログを一読いただければと思います。
MyTalent
MyTalentは2022年2月にローンチしたMyReferに続く二本目のプロダクトでNuxt.js + Goで実装しています。
新規事業のため軽やかにスピーディーに立ち上がるところに注力し、エンジニア数も初期は2名スタートだったため、技術選定はこの2名のスキルセットをベースに選定する形になりました。
現状大きな課題もなく開発を進めていますが、MyReferがReactで開発しており、後述するMyシリーズ管理画面でもReactで開発していることから、モジュールの共通化や横軸でのナレッジ蓄積観点で今後Reactに寄せたいと考えており、近い将来リプレイスも視野に入れています。
まだローンチして1年半ほどしか経っていないサービスで、こちらはMyシリーズ横断での開発と並行してMyTalent単独での新規機能開発も進めています。
Myシリーズ管理画面
Myシリーズ管理画面は、元々完全に独立していたMyReferとMyTalentをMyシリーズとして認証を統一し、ログイン画面や、ログイン後の各種統一的な機能（アカウント管理など）をまとめた画面を開発し、MyRefer、MyTalentとのハブとなる位置付けのUIを提供しています。 こちらはReact + GoでSPA構成で開発をしています。
Myシリーズプラットフォーム
上記のMyシリーズ管理画面でも記載していますが、2023年2月にMyReferとMyTalentを統合し、Myシリーズとしてプラットフォーム展開しています。
MyReferとMyTalentはそれぞれインフラから全て別れており（それぞれのAWSアカウントをOrganizationで作成しており、その上でそれぞれ構築しています）、認証もそれぞれで実装していたのですが、インフラはそのままに認証だけ統一する形で開発を進めました。
またプロダクトごとにDBも別れているので、共通的なデータの移管や、各サービスのデータとの紐付けなど色々と負債が溜まっていきそうな構造にはなっていますが、プロダクト横断でのアーキテクチャ刷新などは中期的な目線で取り組んでいきたいと考えています。
今後
やりたいことは山ほどありますが、今後もMyシリーズとしての新規事業を立ち上げる計画があり、現在2プロダクト + 共通管理画面の構成からより複雑化していくことが想定される中で、複数プロダクトを統合したプラットフォームとしてのインフラを意識したアーキテクチャに移管することを目指したいと考えています。
また各プロダクトの開発生産性を上げるための横断的な仕組みが必要不可欠になっています。これはDX（Developer Experience）文脈としての各プロダクトチームの生産性向上はもちろんのこと、プロダクト特有の要件のないものに関しては、コア機能として提供し、新規プロダクトを立ち上げるときには既にそれらのアセットを使える状態にするなど、複数プロダクトから構成されるMyシリーズプラットフォームにおいてコア機能の共通サービス化は必要不可欠になってきています。
インフラアーキテクチャ
現状各プロダクト間の連携はREST APIでサービス間通信用NW経路でやりとりしており、必要なデータは一部各プロダクトに同期して格納している部分もあります。現状Myシリーズ横断的に提供する機能のリリースに関しては、各プロダクトで同期的にリリースする必要があり、いわゆる分散モノリス的構造の問題を抱えており、様々な課題と向き合わなければならない状況です。
既に記載した通り、AWSアカウントからプロダクトは分かれており、インフラのアーキテクチャ、デプロイフロー、運用、コストなど様々な観点で大幅なアップデートが必要とされています。
現在既に新規事業に着手し始めており、これ以上独立した構成で作ったプロダクトを組み込む形での運用となると、稼働率の低下や、障害発生時のログトレース、各種メトリクスモニタリングなどにおいて課題感が強まっていくことが想定されます。
8月よりようやくSRE部隊を立ち上げ、この辺りの課題の解消に向け地道に進み出しています。
共通サービス化
認証以外の部分は全てプロダクトごとに個別で開発をおこなっており、まずはプロダクト独自の要件の無い機能（メール配信やpush通知など）を中心にコア機能として共通サービス化していきたいと考えています。
今後プロダクトの成長や増加、組織のスケールに応じてマイクロサービスも視野に入れるタイミングがくることも想定されますが（それくらいグロースしていきたい！）、まずは現状の組織規模や今後のスケール予測に基づいて判断していきたいです。
またフロントエンドに関しても現在複数プロダクトを横断した共通的なUIコンポーネントの構築を進めており、将来的にはマイクロフロントエンドの導入なども検討したいと考えています。
BFFアーキテクチャの導入などはそろそろ真剣に検討しないといけないフェーズにきていてエンジニアチーム内で継続議論しながら将来の理想像の共通認識をとるところから進め出しています。
最後に
長文となりましたが、数年にも渡りtech blogを放置していましたがある程度エンジニアも増え、様々なアップデートを進めている中で、改めて今後定期的に発信していきたいと思います。
エンジニア採用も進めていますので、是非ご応募お待ちしています！
私とのカジュアル面談も受け付けていますので気軽にご応募ください！
