「マイクロサービスにしたい」と言ってくる現場エンジニアに、僕はまず「なぜ？」と聞くことにしている。返ってくる答えの半数以上は、技術的なメリットではなく「最近の大手はみんなそうしているから」「モノリスだと古く見えるから」だ。それが問題の本質だと思っている。
マイクロサービスは流行だ。Kubernetes、Docker、API Gateway——言葉は現場に溢れている。でも設計の判断根拠を説明できるエンジニアは、思ったより少ない。「なんとなくマイクロサービスがかっこいい」「最近の大手はみんなそうしている」という理由で導入を進めて、運用で痛い目を見るチームを何度も見てきた。
K.Platinumでは、社内エンジニアに対してアーキテクチャ研修を定期的に実施している。今回はその中身の一部と、僕が「設計判断」についてどう考えているかを書いてみたい。技術選定の話だけれど、本質はエンジニアとしてのキャリアの話でもある。
モノリスvs.マイクロサービス — 本当に大事な判断基準
「モノリスは古い、マイクロサービスが正解」という誤解が根強い。でも実際のところ、アーキテクチャに正解はない。あるのは「今の文脈における最適解」だけだ。
実はマイクロサービスを世に広めたMartin Fowlerら自身が、「Monolith First」——まずモノリスから始めて、モジュール構造を保って、モノリスであることに問題が生じたら初めてマイクロサービスに分割すべき——という立場を取っている。提唱者本人がそう言っているのに、現場では真逆の判断が横行している。判断軸として僕がよく使うのは以下の3つだ。
① チームの規模と自律性
Amazonの有名な「Two Pizza Team」ルール——ピザ2枚で足りる人数（だいたい5〜10人）で1つのサービスを担当する——が、マイクロサービスを成立させる最低条件だと思っている。チームが5人以下なら、モノリスのほうが圧倒的に速い。マイクロサービスはサービス間の通信コスト、デプロイパイプラインの複雑さ、障害の分散トレーシングなど、管理のオーバーヘッドが大きい。その複雑さをペイできるのは、複数チームが独立して動ける規模になったときだ。逆に言えば、10人以下のスタートアップがマイクロサービスにこだわるのは、多くの場合オーバーエンジニアリングだろう。
② デプロイ頻度と独立性
「このモジュールだけ週3回デプロイしたい」という要件が出てきたとき、モノリスでは全体に影響が及ぶ。サービスごとに異なるデプロイサイクルが必要になった段階で、マイクロサービスの検討が現実的になる。ただし、デプロイを独立させるためには、サービス間のインターフェース設計が最初から明確である必要がある。後からAPIの設計を変えるコストは、思ったより大きい。
③ スケーリング要件の非対称性
ECサイトで言えば、商品検索と決済では負荷パターンがまったく違う。全体を一括でスケールさせるより、ボトルネックになるサービスだけスケールできる設計のほうが、コスト効率がいい場合がある。ただし、そこまでの規模にならない多くのプロジェクトでは、このメリットは享受できない。「将来スケールするかもしれないから」という理由でマイクロサービスを選ぶのは、現時点の開発コストを無視した判断だ。
要は、「技術的に面白そう」ではなく「ビジネス要件からの逆算」が判断の出発点でなければならない。それを言語化できないエンジニアは、どんなに実装が速くても上流の仕事を任せてもらえない。
K.Platinumがやっているアーキテクチャ研修の中身
K.Platinumのエンジニアは、ITコンサルとして上流設計から開発・運用まで一貫して関わることが多い。そのため、コードが書けるだけでなく、「なぜこの設計か」を説明できる力が求められる。
研修では教科書的なアーキテクチャパターンの説明より、「実際のプロジェクトでどう判断したか」の事例を中心に扱っている。例えばこんな演習をやる。
ケーススタディ型の意思決定演習
架空のプロジェクト（製造業のECシステムリニューアル、SaaSの管理機能追加など）を題材に、モノリス・マイクロサービス・モジュラーモノリスのどれを選ぶかをチームで議論させる。ポイントは「選択」ではなく「説明」だ。「なぜその設計を選んだのか、クライアントにどう説明するか」を言語化するプロセスに一番時間をかける。
答えは一つじゃない。「このチーム規模ならモノリスのほうが現実的だが、将来の拡張性を考えてモジュラーモノリスから始める」という選択もあり得るし、「デプロイの独立性を最優先するならマイクロサービス一択だが、そのためにCI/CDのコストが増えることをクライアントに納得してもらう必要がある」という説明もあり得る。大事なのは、どちらを選んだかではなく、その判断にどれだけの根拠があるかだ。
コードレビューではなく設計レビュー
機能を実装する前に設計書のレビューを挟む。サービス境界線の引き方、データの一貫性をどう担保するか、障害時のフォールバック設計——こうした判断を事前に言語化する習慣をつけることが目的だ。最初は時間がかかって非効率に感じるかもしれないが、実装後に設計を変えるコストと比べれば圧倒的に安い。
guildboard（社内のギルド型学習プラットフォーム）を使って、研修の知見や事例をナレッジとして蓄積し、チーム全体で参照できる仕組みも整えている。過去の失敗事例も含めて共有するのが大事で、「なぜこの設計が失敗したか」のポストモーテムこそ、一番学びが多い素材だと思っている。
エンジニアとして上流設計から関わりたい方を募集中。 K.Platinumの求人を見る
研修で必ず教える3つの設計原則
研修内容は更新し続けているが、以下の3つは変わらず核心として扱っている。
原則1: 設計意図を先に言葉にする
実装に入る前に「このサービスは何のために存在するか」を一文で書かせる。これができないまま設計すると、後でサービス境界があいまいになり、結局スパゲッティになる。意図が言葉にならない設計は、たいてい間違っている。「Userサービスはユーザーの認証と認可を一元管理し、他のサービスはユーザー情報の問い合わせのみを行う」——この一文が書けるかどうかで、設計の質は大きく変わる。
原則2: 境界はデータではなくビジネスケイパビリティで引く
テーブル単位でサービスを分割すると失敗する。「注文管理」「在庫管理」「通知」といったビジネス上の責務単位で境界を設定するのが鉄則だ。Conway's Lawが示すように、システムのアーキテクチャは組織の構造を反映する。チームの責務と合わせて境界を考えることが重要だ。「データをどう分けるか」ではなく「誰が何の責任を持つか」を先に決めると、自然と適切な境界が見えてくる。
原則3: 障害前提で設計する
マイクロサービスでは、サービスAがサービスBを呼ぶ。Bが落ちたとき、Aはどう振る舞うか——この設計を最初から考えておかないと、本番で痛い目を見る。Circuit Breaker、リトライ設計、冪等性の確保は「後でやる」ではなく「最初から設計する」ものだ。「部分的な障害が全体の障害にならない設計」を意識するだけで、システムの信頼性は大きく変わる。
「技術選定の説明責任」を持てるエンジニアを育てる
ITコンサルとして現場に入ると、クライアントから「なんでこの技術を使うの？」と聞かれる場面は必ずある。「流行っているから」「チームが慣れているから」では話にならない。
ビジネス要件・チーム規模・運用コスト・将来のスケール要件——これらを総合的に判断して「今のプロジェクトにとって最適なのはこれで、トレードオフはこうです」と説明できる人材の価値は高い。
僕がK.Platinumのエンジニアに求めているのは「技術に詳しいこと」ではなく「技術選定の文脈を読めること」だ。同じマイクロサービスでも、100人のチームで動かすエンタープライズシステムと、3人で作るスタートアップのMVPでは、採用の判断がまったく変わる。その文脈を読む力は、技術書を読むだけでは身につかない。実際のプロジェクトで判断し、説明し、フィードバックを受ける繰り返しの中でしか育たない。
逆に言えば、コードを書く技術だけでは市場価値の天井が低い時代になっている。2026年現在、生成AIがコードを書く速度は人間より速い。でも「どのコードを、なぜ書くべきか」を判断するのは、まだ人間の仕事だ。設計判断の説明責任を持てるエンジニアに、僕は投資し続けている。
まとめ — 設計を判断できる人材の市場価値
マイクロサービスの採用可否は、技術的な話ではなくビジネスの話だ。チームの自律性・デプロイ頻度・スケーリング要件という判断軸を持ち、「なぜその設計か」を言語化できるエンジニアが、クライアントから本当に求められている。
K.Platinumの研修では、技術の使い方より「技術選定の意思決定プロセス」を教えることに重点を置いている。ITコンサルに必要なのは、実装力だけではなく設計の説明責任を持てる思考力だからだ。
「コードが書けるエンジニア」はコモディティ化が進んでいる。「設計判断ができるエンジニア」は、まだ市場に少ない。どちらを目指すかで、5年後のキャリアは大きく変わる。それを一緒に考えたいと思える人に、ぜひ来てほしい。
筆者プロフィール
沼田 海斗 / 株式会社K.Platinum 代表取締役
沖縄高専卒業後、トヨタ自動車、スタートアップITコンサルを経て、24歳で株式会社K.Platinumを創業。現在3期目、27歳。製造業・SaaS・官公庁など幅広い業界のDXプロジェクトに上流から開発・運用まで一貫して関与。社内では「設計の説明責任」を重視した独自の研修プログラムを実施している。
K.Platinumでは一緒に働くエンジニアを募集しています。「実力で正当に評価される環境」に興味がある方は、ぜひ採用ページをご覧ください。