状況

相手(経営・PM・他チーム)がこう言う。

「大きなシステムをマイクロサービスに分けたい。スケールするし、今どきそうすべきでしょ」

技術ブログの言葉を借りた要望であることが多い。中身は「チームを増やしたい」「障害を局所化したい」「リリースを独立させたい」など、組織の痛み である。

「まだ早い」「複雑になる」だけだと、また反対屋に見える。


たとえ

モノリスとマイクロサービスは、店舗運営に置き換えるとわかりやすい。

モノリス=一軒の総合店
会計・在庫・接客・発注が同じ屋根の下。一人(または一つのチーム)が全体を把握しやすい。

マイクロサービス=専門店を並べた商店街
パン屋・肉屋・レジ専門など、店ごとに扉・鍵・シフトがある。独立は強いが、店同士の連絡と配送ルール が必要になる。

分割のメリットは「専門店化」。コストは「商店街の運営(API・監視・権限・障害のたらい回し)」である。


提案の型

  1. 目的を聞く
    「分けて解決したい痛みは、リリース速度ですか? 障害の影響範囲ですか? チームの境界ですか?」

  2. たとえで現状を描く
    「今は総合店です。レジと倉庫が同じ建物なので、小さな変更も建物全体の点検が要ることがあります」

  3. 分割の条件を共有する
    「専門店にするなら、店ごとの責任者・営業時間(SLA)・荷物の受け渡し方(API)が先に要ります」

  4. 段階案
    「まずは店内の区画整理(モジュール分割)から。交通量が増えた区画だけ別店舗化しましょう」

ミーティングで使える一文

「マイクロサービスは商店街です。便利ですが、店の数だけ鍵と連絡網が増えます。総合店のまま区画をきれいにしてから、混雑する区画だけ独立させる方が失敗しにくいです。」


例外(分割が妥当なサイン)

  • チームがすでに別れていて、同じコードベースで毎日衝突している
  • 障害のたびに全サービス停止が事業リスクになっている
  • スケール特性が大きく違う部分がある(例: 画像配信だけ極端に重い)

このときは「商店街化」を 目的つき で肯定する。


まとめ

相手の言葉 たとえ 返し
マイクロサービスにしたい 商店街にする 鍵と配送ルールを先に
スケールしたい 人気コーナーだけ拡張 全体解体より区画整理
チームを増やしたい 店長を増やす 店の境界=責任の境界を先に決める

アーキテクチャ用語を減らし、店の分け方 の話にすると合意が進む。