マルチシステムな開発組織における独立デプロイ可能なチームについて考察してみた

はじめに

マイクロサービスを構築する大きな利点に独立デプロイ可能性という考え方があります。
独立デプロイが可能な状態とは他のシステムに依存することなくそのマイクロサービス単体でデプロイできる状態のことを指します。

マイクロサービスの運用では単一サービスを単一チームで運用することが理想とされています。
しかし、実際の開発現場では単一サービスを単一チームで運用することは難しく妥協点を見つけていく必要があると考えられます。

レバテックでは他のチームから独立してデプロイ可能なチームを編成したのでその背景とメリット・デメリットを考察します。

レバテックの状況

レバテックシステムの全体像

フリーランス向けのサービスに限定してもユーザーのサービス利用フェイズやシステムの利用者の違いによって複数のシステム/プロダクトを運用しており、以下のようなサービスがあります。

• ユーザーのランディングページとなるオウンドメディア
• ユーザーのマイページ
• 社内の営業が利用する営業支援システム
• ユーザーの登録情報を各システムに連携するマイクロサービス

システムを改修する難しさ

ここでレバテックのユーザーの流入に関するシステムや営業プロセスを改修することを考えます。

レバテックでは人材がランディングページにアクセスしてから営業活動ができる状態になるまでの工程を「流入」と呼んでいます。
流入に関する工程には、人材のユーザー登録、経験スキルや希望職種の登録、キャリアアドバイザーによる面談やそのカレンダー登録などが含まれます。

この「流入」に関連する人材の導線や営業プロセス、それらに関わるシステムを改善しようと考えた時、前述で紹介したように変更しなければならないシステムは多岐にわたります。

また現在それぞれのプロダクト/システムにはそれらの開発・運用を行っているチームがあります。
アクターの違いによってプロダクトがあり、そのプロダクトのフロントエンドとバックエンドを同一のチームが運用しているような状況です。

このような場合、どのようにシステム、チームを編成にすれば良いでしょうか。

システム/チーム編成の選択肢

以下のような選択肢が考えられます。

• 既存のチーム・システム構成を維持する
• 流入に関する機能をマイクロサービス化する
• 流入に関する機能の改修チームを編成する

これらの選択肢について、独立デプロイ可能性という観点から検討してみます。

既存のチーム・システム構成を維持する

この案では既存のシステム・チーム構成を維持し、流入に関する改修が必要な時に各チームに依頼します。

それぞれのシステムごとにデプロイすることはできますが、リリースに依存関係がある場合、チーム間のコミュニケーションが発生します。例えば、2週間スプリントで各チームが運用している場合、2週間スプリント内のリリースに組み込むために、その前から各チーム間でリリース日を調整する必要があり、小さくないコミュニケーションコストが発生してしまいます。

流入に関する機能をマイクロサービス化する

この案では、各システムの流入に関する機能だけを切り出してマイクロサービス化します。また切り出したマイクロサービスを単一のチームで管理します。

流入に関するデプロイを単一のマイクロサービスで完結できるため、チーム間のコミュニケーションコストは極小になります。
しかし、現状のシステムから流入に関する機能を切り出す必要があるため、すぐに実現することはできません。

流入に関する機能の改修チームを編成する

この案では、既存のシステム構成はそのままで、流入に関する機能の改修を行うチームを編成します。新しく編成したチームは、流入に関する改修があるときに複数のシステムにわたって改修を行います。

これは、「既存のチーム・システム構成を維持する」と「流入に関する機能をマイクロサービス化する」の中間的な案になります。単一システムではないため、マイクロサービスのように単一サービスでリリースを完結することはできませんが、チーム単位でリリースを完結することができます。これにより、リリースにかかるチーム間のコミュニケーションコストを抑えることができます。

また、流入に関する新規開発・運用を単一チームが担当することで、将来的に流入に関するマイクロサービスを切り出すことも可能になるかもしれません。（これを逆コンウェイ戦略と言います）

レバテック開発部はどうしたか

レバテック開発部では流入改善チームを新しく結成し、流入に関わる諸機能に集中して対応していくことにしました。

流入改善チームは、オウンドメディア、ユーザーマイページ、営業支援システムなど、複数システムを改修しながら流入プロセスやシステム負債を解消を目指します。
さらに、「案件」や「契約・請求」についても同様の改善チームが立ち上がっています。

最後に

チーム単位の独立デプロイ可能性に焦点をあて、流入改善チームを編成したことを紹介しました。

流入改善チームのメリット・デメリットとして、以下のようなものが考えられます。

• メリット
  • 機能改修時のリリースコストを抑えることができる
  • 既存のシステム・チーム構成からの変更が少ない
• デメリット
  • 流入改善チームで扱うシステムの数が多くなり、認知負荷や学習コストが高くなる
  • 同一システムを運用しているチームと、システムの運用方法について綿密な認識合わせが必要になる

最後までご覧いただき、ありがとうございます。
流入改善チームを運用していく中で問題点や課題が出てくると思いますので、それらも共有していければと思います。