Diverseの須藤（id:kurotyann） です。
昨年10月から婚活サービスのyoubrideのリプレイスを開始しました。
しかし、このリプレイスは今年の3月に経営判断により終了しました。
このリプレイスを最後までやり切りたかったですが、Diverseの今後の成長を考慮した判断となります。5ヶ月間という短期間ですが、得られた知見は多く、Techブログに結果を残すことにしました。
今回は、以下の2部構成でリプレイスの結果を共有し、このブログは前編になります。
世の中のプロジェクトは成功か失敗のどちらかに区別されます。しかし、今回のリプレイスは成功とも失敗とも言い切れないまま終了しました。ある意味で珍しい事例です。この成果が社内だけなく、サービスのリプレイスを検討したり、実施中の社外の方々への参考になると幸いです。
老舗サービスの変遷と構成
婚活サービスのyoubrideは、スマホがないガラケー時代からあるサービスです。運営会社が変わりながら、2007年2月にyoubrideというサービス名になりました。開発言語もJavaからPHPへと変わり、2013年ごろのリニューアルと同時にPHPからPerlへ変更されています。さらに、モバイルクライアントは、2019年にFlutter+gRPCの構成へリプレイスされています。詳細は過去のTechブログをご覧ください。
現在のyoubrideの構成を簡略化した図がこちらです。今回のリプレイスに関係するリソースに絞って構成を書いてます。
構成図を説明すると、SledgeというPerlのWebフレームワークが、PCとスマホ向けのWebページを別々にレンダリングしつつ、一部のREST APIを担当しています。そして、一部のWebページはWebViewを経由してFlutterで参照しています。gRPCはモバイルアプリのAPIであり、Flutterからのみ呼び出されます。他にもサービスの管理画面や各種バッチ処理が、PerlやRubyで稼働しています。
なぜリプレイスするのか
リプレイスを決めた理由は「サービスの改善速度を低下させる技術的負債を解消するため」です。これを解決すると、youbrideを起点に会社（経営/組織/技術）を改善することに繋がっていくと考えました。
youbrideの技術的負債は、まずはPerlへの依存です。Perlから得られるメリットは年々少なくなっています。さらに残念ながら、Perlを使ってサービスを改善したい人が社内外で減少しています。最も改善すべきドメイン部分が全てPerlなため、改善する人手が足りず、改善コストが上がってしまいます。
もう一つの負債は、Webページがモバイル、フロント、サーバーで密結合している点です。あるWebページのデザイン変更のとき、モバイルアプリ、PCのWeb、スマホのWebと3つの領域に影響が出ます。もちろん、これは場合によってはメリットです。サービス共通で表示する静的なページ（例：利用規約、会社概要など）は変更コストが低く、変更漏れの心配も最小限にできます。
しかし、youbrideは静的ページ以外でも共通で利用中のWebページが複数あります。特に課題なのは、新規登録のオンボーディングページです。各プラットフォームのUIコンポーネントで体験を最適化したいのに共通であるため、各プラットフォームの変更が大変でした。理想は、モバイルはFlutterでUIをレンダリング、Webはレスポンジブにレンダリングして、新規登録に必要なAPIをサーバーに用意してリクエストです。
近い将来は、以下の構成へ段階的にリプレイスしようと計画していました。なお、開発言語はTypeScriptとDartへ統一する計画です。
TypeScriptとDartへ統一する背景は過去の記事をご覧ください。
リプレイスチームを作る
リプレイス専任のチームを作りました。このチームのメンバーは、youbrideを改善中の現行チームからは編成しませんでした。理由は現在のサービス改善速度を下げずに、リプレイスを進めるためです。
チームメンバーはCTO室から3名と、業務委託から3名の合計6名で進めました。業務委託は週1~2の稼働で技術的なアドバイスを担当し、リプレイスを行うのはCTO室の3名です。
フロント、バックエンド、インフラと全領域を3名で担当するため、TypeScriptやDartで統一したのは間違いではなかったと思います。工数の見積もりやタスクのアサインなどが、少し楽になったと私がPMをしていて感じました。
リニューアルではなくリプレイスです
リプレイスの基本方針を以下にまとめました。
- 画面デザインやAPI仕様は「基本的に現行のまま」とする
- ただし、「ニーズに合わない仕様やデザインまで移行しない」
- 変更は「ユーザーのニーズを損なわず、工数削減できる変更なのか」を考える
つまり、リニューアルではないことを前提にリプレイスを進めようとしました。仕様を一度に変更するとデグレが起きて失敗する可能性が高いです。また仕様調査を十分にしたとしても、次はどう仕様変更するかを考える調整コストが発生します。
リプレイス担当とサービス改善担当のチームを別にしたのは、リプレイスに注力するためです。ユーザーのUX改善するリニューアルなどは、リプレイスの後にしました。
もう一つ、この方針にした理由は、デザイナーリソースが足りず、リプレイス専任でデザイナーをアサインできなかったのもあります。リプレイスの対象画面の新デザインまでエンジニアに負担させると、作業負担が重すぎると判断しました。よって、画面デザインはそのまま、ただし容易に変更可能だったり、廃止可能な部分は「ユーザーのニーズを損なわない範囲」で対応するとしました。
段階的にリプレイスする
リプレイスは段階方式で実施しました。一気に変更は加えず、リプレイスをフェーズとステップの段階にわけ、各フェーズの変更を本番へデプロイします。youbrideは歴史あるサービスで機能も豊富です。プラットフォームもモバイルアプリからWeb（PC/スマホ）まであります。一気に変更して広範囲に影響が及び、安全なデプロイが困難になる事態を避けようとしました。
さらに、段階的な本番デプロイで成果を確認しやすくしたかったのも理由の一つです。フェーズごとの変更に不具合がないか、フェーズの終盤で変更を本番へデプロイして確認します。フェーズは安全にデプロイできる範囲で分割しています。フェーズの対象範囲が大きすぎる場合は、さらにステップに分割しました。実際に作成したリプレイスのロードマップはこちらです。
このロードマップは1枚でリプレイスの計画を伝える資料です。左から右へ進み、フェーズ0からフェーズ7へと進みます。フェーズ0はリプレイス前の状態です。youbrideはプロダクトチームがサービスの改善を担当しています。フェーズ1から、リプレイスを専任で担当するCTO室がリプレイス作業を開始します。フェーズ3までCTO室は関わり、フェーズ4以降は既存チームに移譲できる体制にまで改善する計画をつくりました。フェーズ4以降の期日は、フェーズ1~2の成果で決める予定でした。
フェーズ1では、静的ページ（会社概要や利用規約など）のリプレイスのために以下を実施しました。
- Next.jsやNestJSのツールをセットアップ
- Terraformで必要なAWSのリソースをセットアップ
- CI/CDやドキュメントの整備
- 静的ページを本番へデプロイする
AWS ELB（主にALB）のリスナールールを使い、新旧画面のパスを切り替えながらリプレイスします。失敗したとしても、ユーザーへの影響が限定的なページで試しながら、新しい構成へ安全にデプロイできる環境をフェーズ1で整えました。
実際にはフェーズ1は予定より早く完了し、次のフェーズ2へ進んでいました。フェーズ2に認証処理を選択したのは、以下が理由です。
- 認証を突破しないと、他の主機能へのアクセスが技術的に困難なこと
- モバイルアプリの登録やログインはWebViewであり、改善要望が多かったこと
- Flutterから、Perlでレンダリングされた画面の依存を無くし、モバイル側の開発速度を改善したかったこと
なお、このフェーズ1〜2の技術的な知見は後編にて説明します。
Notionへの移行
リプレイスの開始と同時にドキュメントシステムをDocBaseからNotionへ移行しました。Notionへの移行もリプレイスに必要な準備でした。リプレイス中に、youbrideの仕様を新たにドキュメントにまとめ直すことにしたのです。
10年以上つづくyoubrideの仕様を把握している社員はおらず、その仕様がまとまったドキュメントも十分にはありません。DocBaseには利用価値のあるドキュメントなのか、微妙なページが多数存在しました。これらもサービス改善速度を低下させる一つの要因でした。
リプレイスのまとめ方はフェーズやステップごとにドキュメントを分け、ページ内の構造をテンプレにしました。さらに、今後の新規参入者も考慮してオンボーディング資料もまとめていました。
そして、プロダクトチームに現在も有効なドキュメントをDocBaseからNotionへ移行してもらいました。ドキュメントが多いため、すべての移行が順調に進む訳ではないですが、今後の仕様をどう書き残すか一定の方向性ができました。システムだけでなくドキュメントも試行錯誤しながら、改善するサイクルが出来てきました。
Notionへの移行は、別記事でもまとめているのでご覧ください。記事では今年の1月となっていますが、リプレイス専任チームは先行してNotionを使って移行準備を進めていました。
リプレイスは計画的に
ここまで「リプレイスの理由と、リプレイスをどのように進めたのか」を紹介しました。youbrideのリプレイスは一人では不可能でした。複数のチームとメンバーへの説明と理解が必要です。事前の計画は必須でした。
リプレイスは計画を立て社内に共有後、実行します。想定とズレた部分は適宜修正しつつ、ゴールに向かって進む。書いたり言ったりするのは簡単ですが、実際に実行すると本当に大変です。このとき計画がないと軸がなく、メンバーが混乱してチームがバラバラになります。
多くの場合、リプレイスしたいサービスは歴史があり、機能も豊富で仕様も複雑でしょう。計画を立てることが大変な作業で、とりあえず見切り発車したくなります。それでも計画は誰かが事前にたてる必要があります。なぜなら、絶対にすべては思うようにいかないからです。そして、繰り返しになりますが、一人ではできないからです。
このリプレイスも計画どおりに進まず、経営判断での停止で終了しましたが、計画がなければ経営判断の前に終わっていたでしょう。リプレイス完遂という形で成果は共有できませんが、得た知見は今後の会社の成長にとって価値あるものでした。後編では、その成果を書きました。
