ビジネス版マッチングアプリ "Yenta" 事業でアプリケーション開発をしているエンジニアの青野 @ysk_aono です。
YentaはこれまでiOSアプリとAndroidアプリのみを提供していたのですが*1、2021年9月に Web版 (PC版) を新しくリリースしました。
今回は、新しく0から作り、リリースしたWeb版の開発について、振り返ります。
Web版を提供することになった目的は？
主だった理由はやや抽象的にはなるのですが、「今後の製品拡張とサービス成長を踏まえた上で、必要なピースだった」というのが近いかなと思います。
「人と人とのマッチングを生み出し、良い出会いに繋げる・気付きを提供する」というのがYentaの目指すコア体験で、現在もそれは変わっていません。 しかし、より良いマッチングを生み出すための仕掛け・良い出会いに至るまでの経路の多様化を考えていく上で、新しい仕組みを作ることを決めました。
それが、「特性診断」機能 (2021年6月リリース) と、「Q&A」機能 (2021年9月リリース) になります。
これらの機能はPC (Web) からのサービス流入やSNSへのシェアも見込まれるものであったため、 Webアプリが存在しないことが、利用していただいている方にとってシームレスな体験を阻害することに繋がります。 今後のプロダクト改善・マーケティングを見据えた上でも必要な存在だとチームで認識し、開発に着手することを決めました。
※コロナ禍によるテレワーク促進でビジネスパーソンがPCの前にいる時間が長くなった、という環境変化も、もちろん意思決定の要因として存在します
Web版の機能
iOS版/Android版で提供している機能は、ほとんど変わらず利用可能*2です。
今回の主目的である「モバイルとPCで分断のない体験」を実現する上で、同等の機能にすることは必要不可欠でした。
プロジェクトの期間やメンバーの人数、進め方etc.
関わった人数や進め方の方針
ネイティブアプリ側に既に存在する機能はできるだけ早くリリースして、 その先のプロダクト改善/価値向上に時間を割いていくことが重要です。
Yentaの開発チームは、少人数ながらいくつかのプロジェクトを並行して進めることが従来多かったのですが、 スピードUpを期待して、Web版 (+ 上記の特性診断/QA機能) の開発を行う際にはその方針を変えました。 ほぼ全員で一つのものに立ち向かい*3、一気に敵 (敵ではない) を倒しにいく方法です。
Web版に関してはフロントエンドのみの開発で完結したのですが、関わった人数としては 3~5人 になります。内訳は以下。
- フルコミット : 3人
- ただし、Web開発に慣れ親しんでいたのは1人のみ
- ほか2人は、普段はネイティブアプリ開発が主戦場
- 助っ人 : 1人
- Webフロント開発経験のあるチームのバックエンドエンジニアに、2-3週間程度手伝ってもらった
- 他事業プロジェクトチームからの助っ人 (週2日) : 1人
- Webフロントに強い助っ人に、途中の1ヶ月ほど入ってもらった
こうやって書くと日頃からWebフロントに慣れ親しんでいるメンバーがあまり多くないのですがｗ、全員で必死にキャッチアップしながら開発をしていました。
役割分担
一定以上経験のあるエンジニアのみでメンバー構成されていたため、マイクロマネジメント的なタスク管理はしませんでした。 中核の機能から順番に作っていくこと、それぞれが1ページ (URL) ずつ受け持ち実装を完了していくこと、というやり方で進め、最後にQAで出てきたバグや仕様漏れを全員で直していくようなイメージです。
1つ特徴的だったのは、レイアウト (tsx側の土台作り) 実装とロジック (ViewModelの実装とtsx側へのデータセット) 実装の役割をきっちりと分け、レイアウト (とAtomコンポーネント) 追加 → ロジック追加、という順番で開発を行っていったことでしょうか。
これは決して望んだ手段ではないのですが、Webのレイアウト組み経験のないメンバーが多かったこともあり、最速の手段を考えた結果そういった布陣となりました。
開発期間
開発期間としては、2ヶ月強くらいでした。
(※Reactが初めてのメンバーもいたのでプロジェクトに入る前にキャッチアップをしたり、設計方針のFixやライブラリの選定をしたり、という部分は含んでいません。)
既に5年以上運用しているサービスの全機能を含んだWebアプリ1つを開発したと考えると、 リリースまでのリードタイムはかなり短く終わることができたのではないかと思います。
技術スタック
フロントエンド
- TypeScript
- React
- Next.js
- Chakra UI
を利用しました。
2021年にWebフロントエンドのプロジェクトを開始するという意味で、非常にオーソドックスな構成なのではないかと思います。
アトラエでは全てのサービスのWebフロントエンドでReact + TypeScriptを採用しており、他事業プロジェクトからの知見を展開できるという意味でもほぼ一択の選択肢でした。
Next.jsについては初めて利用するメンバーがほとんどだったのですが、Next.js由来の問題で困ったことはほとんど無く、"ゼロコンフィグ" で煩わしいビルド周りの設定をほぼする必要がなかったり、ルーティングがファイルベースで分かりやすかったりと、プロジェクトを円滑に進める上で受けた恩恵の方が大きかったと考えています。
レンダリングに関しては、基本的にログインを前提として使うサービスであることもあり、クライアントサイドでAPIにアクセスし画面を描画しているページがほとんど (一部SSR利用) です。
また、Chakra UIについては、同僚が所感などを別の記事で書いてくれる予定ですので割愛します。
インフラ
プロジェクトのホスティングに使っているのは、AWS Amplifyになります。
(最近はだいぶ解消されましたが) こちらは当初、Next.jsとの相性があまり良くなかったです。
Next.js v10に対応していない時期もあり、不用意に next/image を使ってデプロイすると全く画像が出ないといったことが起きたり*4、デプロイ時のbuildエラーに悩まされたり (aws-amplifyのnpmパッケージのアプデで起きたりする) といったことがありました。これは我々が悪いのですが、getServerSidePropsでのAmplify関連処理が誤っており、SSRを一部利用しているページが開けなくなったりしたこともあります。
インフラ構築に時間と人的コストをあまり割きたくない状況において、サーバレスにこういった環境を立ち上げられるサービスは非常に魅力的ですし、 選択として間違ったとは思っていないのですが、思わぬところで足を取られた印象はありました。
ちなみに、Next.jsなのにVercelにホスティングすることを選択しなかった理由は、トラフィックが正確に見えない状態でのコスト面 (1TBの帯域幅を越えるのか/超えた時に価格はどうなるのか) が不透明だったからです。リリースしてある程度経ったことで、別のサービスへの乗り換え or 自前で環境を用意する etc.の方向性を再度検討しやすくなったと考えています。
感想とこれから
駆け足でYenta Web版開発のプロジェクトを振り返りました。
かなりストレッチしたリリーススケジュールを引いたのもあり、しんどかったなーと思う部分もあるのですがw、 Next + React + TS を組み合わせた開発は非常に快適であり、開発者としてその生産性の高さには驚かされました。
iOS版でSwiftUIを正式採用していないこともあり、いわゆる "宣言的UI" に触れるのも本当に久しぶりで*5、フロントエンドを作っていく上での知識のインデックスが増えた感じがあります。
現状の課題としては、例えば
など、色々あるなとは考えています。 他にも、突貫工事で進めてきた弊害が今後出てくる可能性はあるでしょう。 まだまだ成功したとは言えない事業を作るエンジニアとしては、こういった借金の返済に100%時間を割きたい状況ではないのですが、 インプットをしながら解消を随時進めていきたいと思います。
また、チームとしては以下の状況からやや特殊な開発の進め方をしましたが、
Webのレイアウト組み経験のないメンバーが多かった
- ロジックに強いメンバーが、レイアウトまでさくっと組めるようになる
- レイアウト組みに強いメンバーが、ロジックまでしっかり書けるようになる
といった得意領域の流動化を起こしていかないと、今後の開発スピードが上がっていかないと考えています。
おわりにいつもの宣伝
アトラエのエンジニアは、いろいろな領域に足を踏み入れてチームに貢献しています。
今回のような大きめの開発プロジェクトや技術選定をやることもあれば、 サービスグロースを目的にデータ分析・KPIなどの指標決め・Figmaを使ったプロトタイピング (そして自分で開発) などもやったりと、 その領域はプログラミングだけにとどまりません。
そういった働き方に少しでも興味がある方は、ぜひお声がけいただければと思います！
