2021 年 2 月、 ANDPAD の通知基盤刷新プロジェクトが開始されました。 チームが直面したのは RDB に積み重なった 1 億レコードを超える notifications テーブル の存在でした。 このデータ量では RDS 以外への移行が必要という明確な目的のもと、企画から完了まで、実に 4 年もの歳月を要する大規模プロジェクトとなりました。

この記事では、この 4 年もの大規模プロジェクトをどのように進めたのか、チームへ取材し、ドキュメンタリーとしてまとめています。

プロジェクトの実質的な体制は、 PdM の 米山 諒 、エンジニアの 小島 夏海 、 榊原 徹哉 、そしてメインの移行フェーズでは QC から 安室 博文 という少数精鋭のメンバーで構成されていました。

米山 諒

早稲田大学大学院在学中、創業期のビズリーチにインターンとして参加。 2011 年 4 月、リクルートに入社し、プロデューサーとして新規事業の立ち上げ、事業運営責任者を務める。 フリーランスとして複数社のスタートアップを支援後、株式会社 LiB を創業し取締役 CTO に。 現在はアンドパッドのプロダクト本部の部長として、主に新規事業/プロダクトの開発に携わる。  

小島 夏海 @replu5

社内開発者向けの分散 DB 基盤の運用・ライブコマースサービスの開発・ toB 向けサービスの開発を経て、 2021 年にアンドパッドに入社。 現在はバックエンドエンジニアとして、マイクロサービスの基盤開発に従事。 Go Conference 2024 / 2023 、 Go Conference mini 2023 Winter IN KYOTO で登壇。  

榊原 徹哉

ゲーム会社、大手電子書チームのバックエンドを担当した後、新規スタートアップのサービス立ち上げに携わり、プレシリーズ A まで成長をさせる。 2021 年にアンドパッドに入社し、通知基盤移行プロジェクトを立ち上げ、現在はバックエンドエンジニアとして、移行プロジェクトに従事。

安室 博文

有名国立大学の再生生理学研究室でイモリの網膜再生について研究。博士課程を修了。29歳で就職活動を開始し、ソフトウェアテスト専門会社に入社。ソフトウェアの品質改善に貢献し、チームリーダーを経験。ベンチャーのスピードと混沌を求めて、アンドパッドにジョイン。QCチームの構築と品質を能動的に改善する仕組みづくりに没頭している。  

通知基盤のシステム構成と技術スタック

この通知基盤は ANDPAD 内の 17 ものプロダクトから利用されており、ユーザー向けの「 Notification 」と、お施主 (オーナー) 様向けの「 Notification Owner 」の 2 つに分かれ、メール、プッシュ、デスクトップ通知の送信を担っています。

技術要素として、裏側は基本的に Go で書かれており、 リクエストを受け取る gRPC サーバと非同期で通知の送信等を行う worker が稼働しています。  worker とのやりとりに使用するキューは SNS/SQS の構成のものと SQS FIFO を使い分けて構築されています。

データベースとしては DynamoDB と RDS の 2 つが併用されています。 また、システムは社内のいくつかのサービスと連携し、メール送信には Mailgun などの外部サービスも利用しています。 最近では Web プッシュ通知送信のサポート開発も進んでおり、これが完了すれば、現在 Firebase のリアルタイムデータベースで独自に実現しているデスクトップ通知の置き換えが可能になる見込みです。

テックリードの限界と PdM の参画

プロジェクトの規模が明らかになるにつれ、コミュニケーションに関する大きな課題が浮上しました。 通知基盤に影響を及ぼすプロダクトは、小さな影響も含めて 17 プロダクト。 そこでアサインされたのが PdM の米山でした。 米山は当時の状況を振り返り、 PdM の役割をこう語りました。

米山:
「アンドパッドの中でも、稀にみる一大プロジェクトでした。 通知チームのテックリードが一人で17 プロダクトの PdM とエンジニアと共通認識を築くのは至難の業です。そもそも対話の相手が多すぎて、実装する時間が取れなくなってしまいます。」

米山がプロジェクトに参加することで、「コミュニケーションは PdM に任せつつ、実装はエンジニアが集中できる」という切り分けができ、プロジェクトのスピードが上がりました。

そして、参画した米山が 17 の開発チームとのコミュニケーションの次に注力したのは、技術的なサポートではなく、ユーザー視点でのコミュニケーションでした。

米山:
「システムが MySQL から DynamoDB に変わるといった話は置いておいて、ユーザーから見たらどうなるの？ という話をしようと考えました。 特に重要だったのは、ユーザーへの影響の具体的な説明です。 例えば、リリース時の設定切り替えで RemoteConfig の反映に最大 1 時間のタイムラグが発生するといっても、実際にユーザーをサポートする社内のカスタマーサポート担当にはピンと来ません。 ユーザーから見た時の振る舞いについて詳細な認識のすり合わせができなければ、トラブルになりかねませんでした。」

それを踏まえ、米山は今回の通知基盤移行のような組織を横断する大規模プロジェクトを担当する PdM やテックリードに重要なことを挙げました。

米山:
「影響範囲が大きくなればなるほど、技術的な変更を、ユーザー体験で説明する翻訳スキルが必要です。 この翻訳まで気を配れるかが、大規模プロジェクトの成否をわけるポイントの一つだと思います。」

安全な移行戦略よりデータの正しさが重要だったことに気づく

チームは、ユーザーへの影響を最小限に抑えるため、段階的なリリース戦略を採用しました。 新基盤から通知の送信を担う「ファーストリリース」(2024 年 5 月末に完了)　と、新基盤から通知データの取得を担う「セカンドリリース」 (2025 年 6 月末に完了) に分けました。

チームの立ち上げから携わってきた当時のテックリード、榊原にファーストリリースでのポイントを聞きました。  

榊原:
「既存デプロイとリリースの分離ができるフィーチャーフラグを採用し、何か問題が発生した際に、即座に切り戻しが可能な状態を確保しました。 実際、緊急対応が発生しても、素早く検知でき、落ち着いて切り戻しの対応ができました。」

(当時の状況がわかる発表資料)
創業当初から存在する巨大なモノリスを慎重にマイクロサービス化を進めている取り組みについて - Speaker Deck

しかし、安全なリリース速度や切り戻しの容易さばかりに焦点が当たった結果、後にエンジニアチームは移行において最大の反省点に直面することになります。

榊原の育休に伴って、セカンドリリースでテックリードとなった小島は、技術的な側面で最大の教訓を述べます。

小島:
「今回、リリースをいかに安全に、速くするかを重視しましたが、一番重要だったのは データの正しさ を担保できる仕組みを入れることでした。 最初にそれを考慮できておらず、あとから入れようとしたのですが、それが非常に大変でした」。

通知サービスからデータを取得する赤い線 (RDB から取る箇所と通知サービスから取る箇所) の操作が、 レスポンスレベルで等しいか どうかを担保する仕組みが、初期段階で欠けていたのです。 小島はこの点が「一番大事なこと」であり、次に同様のプロジェクトを行う人が踏まないように伝えたいと強調しました。

地道な検証作業でリカバリ

仕組みが欠けていた「正しさの担保」を後付けで実現するため、チームは地道な検証作業に注力しました。

まず、データチームに協力を依頼し、データベース情報を BigQuery へ同期させました。そして、「作成されていない通知がないか」や「未読数の一致はしているか」をひたすらログと BigQuery で調査しました。 その模様を小島と安室はこうふりかえります。

小島:
「BigQuery で既読状態のズレなどがありそうな挙動を特定して、ログからその画面や操作にあたりをつけて、あとは私と QC の方とひたすら ANDPAD のアプリで確認し続けることをやっていました。 もう本当に地道な努力でどうにか検証を続けました。」

安室:
「私個人だけではなく、横断的に色々なチームに入っている QC として、全体で協力しあいながら各プロダクトの知見を集めて通知基盤チームをサポートでき、 QC 組織としても非常に良い事例だったと思います。」

結果として、この地道な努力によりリリース時の未読数のズレの割合は約 1 ヶ月でピーク時の 1/5 を切り、大幅に削減できました。 BigQuery との同期のタイミングのズレから一定数は残るので、ほぼ解消した状態です。 小島は、このプロセスを「根性論はあまり言いたくないのですが、結局それかな」と語り、チームの粘り強さが不可欠であったことを示しています。

この経験から、小島は横断的なプロダクトに取り組むエンジニアに、自身の担当領域に留まらない心構えの重要性を説きます。

小島:
「みなさん担当プロダクト以外触らないこともあると思うのですが、横断のプロダクトやプロジェクトに携わるなら、自分の領域など考えないで全部プロダクトを触るぐらいの覚悟が必要だと思います。 実際、私のスマートフォンや iPad はこんな感じで ANDPAD で占められていました。」

チーム連携の反省と進化

横断プロジェクトの成功には、他チームとの協働が不可欠でした。

ファーストリリース時、チームは各チームに「とりあえず依頼すれば、よしなにやってくれるだろう」という気持ちで確認してほしい観点を明確に提示せず、結果として手戻りが発生し、時間がかかってしまいました。 この反省を活かし、セカンドリリースでは QC の安室と通知チームが一緒になって QC 観点を事前に洗い出し、依頼側が「どういうことを気にかけて確認して欲しい」のか明確に提示しました。　これにより、お互いの時間の無駄を防ぎました。

安室に当時のことを聞くと、横断的プロジェクトの進め方の難しさに気付かされたとのことでした。

安室:
「基盤系のチームは、プロダクト開発チームとの関係性が 1：n になりやすい構造で、それゆえに認識違いや漏れなどが起きやすくもなります。横断的プロジェクトを協力して進めていくには、具体的にどのようなことをしてほしいかを事前に明確にし、チーム間の認識を揃えていくことが重要だと改めて気づかされました。」

この徹底した動作確認の結果、洗い出された不具合は全体で 50 件にも上りました。 これらの不具合は QC 観点シートで可視化され、毎日の朝会で状況を確認しながら一つずつ潰していきました。 小島もこの解消に加わり、テックリードというポジションながら最後の 2 週間は QC のみに費やしたといいます。

小島:
「ふりかえると、メンバーの増員が必要な際にも、ただ "人が欲しい" ではなく、 "具体的に何が困っており、どういうスキルがあるとうまくいくか" を組織に伝えることが重要ですね。」

やり切る覚悟とめげない心

ANDPAD の通知基盤移行は、 RDB への書き込み停止という最後の「サードリリース」を残すのみとなりましたが、ユーザーへのサービス提供は新基盤に完全に移行しました。

この約 4 年間という長きにわたる大規模プロジェクトから得られた教訓は、以下の 3 点に集約されます。

1. 移行の正しさをどう担保するのかを最初から検討しておく。（これが一番大事）
2. 適切に社内と協働し、必要な場合は協力（増員）を依頼する。
3. やり切る覚悟とめげない心。（根性論に近いがこれは必須）

特に 3 番目の「めげない心」は、長期間にわたる大規模リリースと切り戻しの繰り返しの中で、チームが何度も「折れそうになるポイント」を乗り越えるために不可欠でした。 小島は、技術的な側面での監視体制や切り戻し準備はもちろんあったものの、「それ以外のところを中心」に、このプロジェクトをやり切るためのチームの精神的な強さが重要であったことを強調しています。