状況
相手(経営・PM・他チーム)がこう言う。
「大きなシステムをマイクロサービスに分けたい。スケールするし、今どきそうすべきでしょ」
技術ブログの言葉を借りた要望であることが多い。中身は「チームを増やしたい」「障害を局所化したい」「リリースを独立させたい」など、組織の痛み である。
「まだ早い」「複雑になる」だけだと、また反対屋に見える。
たとえ
モノリスとマイクロサービスは、店舗運営に置き換えるとわかりやすい。
モノリス=一軒の総合店
会計・在庫・接客・発注が同じ屋根の下。一人(または一つのチーム)が全体を把握しやすい。マイクロサービス=専門店を並べた商店街
パン屋・肉屋・レジ専門など、店ごとに扉・鍵・シフトがある。独立は強いが、店同士の連絡と配送ルール が必要になる。
分割のメリットは「専門店化」。コストは「商店街の運営(API・監視・権限・障害のたらい回し)」である。
提案の型
-
目的を聞く
「分けて解決したい痛みは、リリース速度ですか? 障害の影響範囲ですか? チームの境界ですか?」 -
たとえで現状を描く
「今は総合店です。レジと倉庫が同じ建物なので、小さな変更も建物全体の点検が要ることがあります」 -
分割の条件を共有する
「専門店にするなら、店ごとの責任者・営業時間(SLA)・荷物の受け渡し方(API)が先に要ります」 -
段階案
「まずは店内の区画整理(モジュール分割)から。交通量が増えた区画だけ別店舗化しましょう」
ミーティングで使える一文
「マイクロサービスは商店街です。便利ですが、店の数だけ鍵と連絡網が増えます。総合店のまま区画をきれいにしてから、混雑する区画だけ独立させる方が失敗しにくいです。」
例外(分割が妥当なサイン)
- チームがすでに別れていて、同じコードベースで毎日衝突している
- 障害のたびに全サービス停止が事業リスクになっている
- スケール特性が大きく違う部分がある(例: 画像配信だけ極端に重い)
このときは「商店街化」を 目的つき で肯定する。
まとめ
| 相手の言葉 | たとえ | 返し |
|---|---|---|
| マイクロサービスにしたい | 商店街にする | 鍵と配送ルールを先に |
| スケールしたい | 人気コーナーだけ拡張 | 全体解体より区画整理 |
| チームを増やしたい | 店長を増やす | 店の境界=責任の境界を先に決める |
アーキテクチャ用語を減らし、店の分け方 の話にすると合意が進む。