はじめに
こちらは バイセルテクノロジーズ Advent Calendar 2024 の 11 日目の記事です。 昨日は鴨野さんによるlog/slog と context で妥協しないロギングを実現するでした。
こんにちは、テクノロジー戦略本部 開発 1 部でバックエンドエンジニアをしているメントス (@m_t_tion1) です。
2024 年 2 月に入社して以降、リユースプラットフォーム Cosmos の出張訪問買取アプリケーション Visit と、 Visit を支える買取基盤バックエンドサービス Deal の開発・運用に従事しています。
本記事では、Cosmos で開発を行う新規サービスのバックエンドを、新たなマイクロサービスとして切り出さず、Deal に組み込むという意思決定をした話を紹介します。
前提
本記事で出てくる用語
はじめに、本記事で出てくる用語に関して整理します。
| 用語 | 意味 |
|---|---|
| フィールドセールス | 出張訪問に伺う査定員 |
| Visit | フィールドセールスが査定業務で使うアプリケーション |
| Deal | 出張訪問だけでなく、将来的に店舗や宅配などの、買取領域全般で使われることを想定して作られた基盤サービス |
| 決裁 | 特定の決定や承認を行うプロセス。主に出張訪問買取業務では、フィールドセールスの結んだ契約が承認されるかどうかを意味する |
現状の Cosmos のアーキテクチャ
Cosmos は、買取から販売まで様々な業務領域にて必要な機能を提供し、将来的に特定の機能単位でリユース業者に提供でき、利用される世界線を目指して開発を行っているプロダクトです。
そのため、マイクロサービスアーキテクチャを採用し、顧客管理や出張訪問査定・契約決裁など「サービス単体で提供可能な独立した業務領域」をサービス境界として、DB ごとサービスを分割して、開発を進めています。
次に、私が担当している出張訪問買取アプリケーションの Visit と 買取基盤の Deal のアーキテクチャを紹介します。
フィールドセールスが扱う Visit アプリが、Visit BFF を経由して、買取業務に関する情報なら Deal へアクセスしデータを取得します。 それ以外の情報は他のマイクロサービスにアクセスしデータを取得、という設計になっています。
また、買取基盤である Deal は、買取業務において共通のプロセスである、案件・商談/査定/契約 の 3 つをそれぞれ独立したモジュールとみなした、モジュラモノリスで構成されたプロジェクトです。 選定理由の背景・詳細を知りたい方はこちらをご覧ください。
新規サービス開発の決定に至った背景と開発体制
バイセルの出張訪問買取では、フィールドセールスがお客様との商談において契約を締結した後、契約内容の精査を決裁課に依頼するプロセスが存在します。
現在、出張訪問買取における決裁業務は、廃止が予定されている既存の基幹システムで実施されています。 つまり、新規のプラットフォームである Cosmos で業務を遂行できる必要があります。
そのため、今回新たにお客様との契約の決裁に関わるデータを管理するサービス (以降、決裁管理サービス) の開発をすることになりました。
また、決裁管理サービスの開発は、開発ロードマップの兼ね合いやリソースなどの状況を踏まえ、弊チームではなく、別チームが担当することが決定していました。とはいえ、買取における決裁は、Deal と密接に関連する業務領域のため、サービスのアーキテクチャを弊チームと開発担当チームで慎重に検討する必要がありました。
決裁管理サービスのアーキテクチャ議論
マイクロサービスに改めて向き合う
意思決定を行う前に、マイクロサービスアーキテクチャに改めて向き合い、技術的側面/事業・組織的側面 での Pros/Cons の理解を深める必要があると考えました。 その上で、決裁管理システムの要件を踏まえ、Cosmos として最適な選択肢を模索することにしました。
まずは技術的側面の Pros/Cons を整理しました。*1
技術的側面における Pros
- 開発するサービスの要件・チームメンバーに応じて適した技術を採用することが可能
- サービス全体に影響を与えることなく、一部のサービスに限定することが可能
- スケーリング
- デプロイ
- 障害の影響範囲*2
技術的側面における Cons
- サービスのインフラコストの増加
- サービスの増加に伴う保守運用工数の増加
- 技術的に考慮すべき点の増加
- データの整合性を保つための分散トランザクションの考慮
- サービス間通信の遅延の考慮
次に事業・組織的側面の Pros/Cons を整理しました。
事業・組織的側面における Pros
- 特定のサービスに限りスケールが可能
- サービス単位でチームを分割することで、各チームは担当するサービスの業務領域に集中できる
事業・組織的側面における Cons
- サービスとして統一したい点 (ex. デザインシステム, SLO/SLA) の不統一が起こりうる
- チーム分割により、業務知識の局所最適が進み、サービス全体を俯瞰できる人材が不足
決裁管理サービスの要件の確認
決裁管理サービスの要件を確認しました。 達成したい要件は、決裁課の方がフィールドセールスが結んだ契約内容を確認し、承認・却下などの必要なアクションを取れることです。
そのため、Deal で保存しているデータのうち必要なものを決裁課が確認できるようにして、アクションに応じた決裁の状態を管理すれば、要件は達成できるということがわかりました。
意思決定
現状整理をした上で、決裁管理サービスをどう作るか考えていきました。
フロントエンドに関しては、事業部ごとに UI を分ける方針で、決裁課向けにフロントエンドは新しく作る方針で固まりました。
しかし、バックエンドの設計は以下の 3 案で意見が分かれました。
案1. サービスとしての分割: 新たなマイクロサービスとして、決裁管理サービスを作る
案2. モジュールとしての分割: Deal の中に新しく決裁のモジュールを作り、DB ごと分ける
案3. 既存モジュールに組み込み: Deal の契約のモジュールの中に、決裁管理のバックエンドを組み込む
次に、その 3 案から 1 つを選定するために、技術的な判断軸と、Cosmos におけるサービスの事業側面の判断軸の 2 点を整理しました。
技術的な判断軸として
- 個別最適性がある (e.g. 開発の自由度: 既存のデータ構造に左右されない / 開発ルールを独自に最適化できる)
- データ整合性を保ちやすい (e.g. 複数 DB に書き込みを行う上で、分散トランザクションの考慮が必要かどうか)
- ロジック再利用性がある (e.g. 案件・商談/査定/契約それぞれで使っている、一部の業務ロジックを必要なら流用できるか)
- インフラコスト/保守・運用工数が必要以上にかからない (e.g. 監視対象が増えることにより、インフラコスト/保守・運用工数が増えるかどうか)
- サービスレベルの変更容易性が高い (e.g. 後々マイクロサービスに切り出すか、一つのサービスに統合するかどちらが大変か)
Cosmos におけるサービスの事業側面の判断軸として
- 「サービス単体で提供可能な独立した業務領域」のサービス境界が守られているか
が挙がりました。これらの観点に基づき、3 案を比較しました。(⚪︎: 良い/優れている, △: やや良い/中程度, ×: 悪い/不十分)
| 案 1 | 案 2 | 案 3 | |
|---|---|---|---|
| 個別最適性がある | ⚪︎ | ⚪︎ | × |
| データ整合性を保ちやすい | × | × | ⚪︎ |
| ロジック再利用性がある | × | ⚪︎ | ⚪︎ |
| インフラコスト/保守・運用工数が必要以上にかからない | × | △ | ⚪︎ |
| サービスレベルの変更可用性が高い | △ | △ | ⚪︎ |
| 「サービス単体で提供可能な独立した業務領域」の サービス境界が守られているか |
× | × | ⚪︎ |
結果、案 3 が
- 決裁管理サービスの要件が、既存の Deal のデータ・業務ロジックを使うことにより達成できること
- DB を分けないことにより、開発/保守・運用の考慮ポイントの削減が見込めること
- 「決裁」は「契約」がないと生まれない概念であり、決裁単一でサービスに切り出すのは Cosmos として適切ではないこと
の観点から採用されました。
案 1 と 2 は、チームに合わせた開発ができるという個別最適性の点では良かったのですが、それ以上に他の観点での懸念点が多く、見送りました。
意思決定のその後
決裁管理サービスを Deal のモジュールに組み込むという意思決定にチームを跨いで納得し、開発が開始しました。その上で、良かった点・難しかった点がそれぞれありました。
良かった点
開発担当メンバーは、Deal を触るのが初めてなので、まずは既存の Deal のソフトウェアアーキテクチャや開発手法について理解する必要があります。
現在、Deal ではオニオンアーキテクチャを採用しており、ドメイン駆動設計の考えに基づき、扱っているドメインのモデリングを適宜実施しています。 しかし、前提となるドメイン駆動設計の考えを知らない状態では、参入のハードルが高いのは事実です。
そこで参入のハードルを下げるために、弊チームと合同でドメイン駆動設計の勉強会を実施しました。*3
その結果、開発担当チームだけでなく、弊チーム内で認識を改めて合わせることができたり、新しい気づきを得られる良い機会になっています。
また、現状抱えている負債に関して相談し、お互いの知見を共有し解消に共に取り組んだりと、相乗効果が出ていると感じています。
難しかった点
一方、個別最適性の観点で難しさを感じる部分もあります。チーム間で開発のルールやコーディングで重視するポイントが異なる問題がありました。
その結果、お互いに納得して開発を進めたいという思いから、頻繁に認識を合わせる機会が必要になりました。
議論をすることは良いことですが、あらかじめ予測し、開発に入る前に細かくすり合わせておく必要があったと反省しています。
最後に
ここまで読んでいただきありがとうございました。今回の意思決定の機会を通じて、マイクロサービスは考慮する点が多く、複雑で学習コストが高いと改めて痛感しました。 ただし、マイクロサービスと要件に向き合い、Pros/Cons を踏まえた上で、最終的に「安易にサービスを分割しない」という、複数チームを巻き込んだ意思決定をしたことは、貴重な経験だと感じています。
最後に、バイセルでは一緒に働くエンジニアを募集しています！Cosmos は鋭意開発中のフェーズであり、全員が納得して開発するための意思決定の場が多くあります。興味がある方は、以下よりご応募ください。
明日の バイセルテクノロジーズ Advent Calendar 2024 は 渡邊 さんによる 「スクラム経験者がエンジニア採用チームを立ち上げた話」です。 お楽しみに！
*1:マイクロサービスアーキテクチャ 第 2 版を参考に一部を抜粋して、私の言葉も交えつつ紹介しています。
*2:単一障害点となりうる共通で使われているサービスで障害が起こった場合を除きます。
*3:ドメイン駆動設計 モデリング/実装ガイドを利用し、輪読会形式で実施しています。
