「マイクロサービスにすべき」は中小企業には当てはまりません。 まずはシンプルなモノリス（一体型）で作り、本当に必要になったら分割する。この記事ではその理由と設計のポイントを解説します。
モノリス vs マイクロサービス
| モノリス（一体型） | マイクロサービス | |
|---|---|---|
| 構成 | 1つのアプリケーション | 複数の小さなサービスの組み合わせ |
| 開発コスト | ◎ 低い | △ 高い（2〜5倍） |
| 運用の手間 | ◎ 少ない | △ サービスごとに監視・デプロイが必要 |
| スケーラビリティ | △ 全体をスケール | ◎ 部分的にスケール可能 |
| 向いている | 中小企業の大半 | Netflix、Amazon級の大規模サービス |
中小企業の業務システムでマイクロサービスが必要になるケースは、まずありません。 ユーザー数百人程度、機能10〜30個程度なら、モノリスで十分かつ最も効率的です。
ただしモノリスでも「良い設計」は必要
モジュール分離
コード内部では機能ごとにモジュールを分離。将来分割が必要になったときにスムーズ
API設計
フロントエンドとバックエンドをAPIで疎結合に。UIの変更がバックエンドに影響しない
データベース設計
正規化されたDB設計。将来のデータ量増加やレポート機能追加に対応できる基盤
テストコード
自動テストがあれば、機能追加・改修時に「既存機能が壊れた」を即座に検出
発注側が確認すべきこと
- 「なぜその構成にするか」の説明を求める — 技術選定の理由を聞く。「流行っているから」は理由にならない
- 将来の拡張性を確認 — 「ユーザーが100人→1,000人になったら？」「新機能を追加するときの影響は？」
- 過剰な設計を警戒する — 「マイクロサービスにしましょう」「Kubernetes入れましょう」は中小企業に不要な場合が多い
- ソースコードの品質基準を確認 — TypeScript、テストコード、コードレビューが行われているか
「マイクロサービスにした方がいい」と提案された場合は注意。 本当に必要なケースは稀で、開発費・運用費が数倍に膨らむリスクがあります。セカンドオピニオンを取りましょう。
まとめ
- 中小企業はモノリスで始めるのが正解。コスト・スピード・運用の全てで有利
- ただし**良い設計（モジュール分離・API設計・テスト）**は最初から必要
- マイクロサービスが必要なのは数千〜数万ユーザー規模になってから
- 過剰な技術提案にはセカンドオピニオンを
JIT株式会社
JIT株式会社では、中小企業に最適な「シンプルだが拡張性のある」システム設計を提供しています。過剰な構成を売りつけることはしません。