🧭 はじめに
マイクロサービスという言葉が広まり、技術ブログやアーキテクチャ設計図では「理想構成」として語られることが多くなっています。しかし、実際の現場に目を向けると、すべてのシステムがマイクロサービスに移行できるわけではありません。
- チーム規模が小さい
- スキルセットがバラバラ
- 本番環境が長期運用されているレガシーシステム
そんな“あるある”な制約の中で、**「今できる最適解をどう選ぶか」**が重要です。
本記事は、現場で実践してきた「無理なく進めるモダン化」の続編です。
🔁 前回のおさらい：ステップ分離で実現した変化
前回は、以下のような分離ステップを紹介しました。
目的は「いきなり全部を変える」のではなく、「まず切り出せる責務だけを外出しする」こと。
この小さな構成の分離が、結果としてチームや運用のあり方を大きく変えていきました。
📌 Slack通知をLambdaへ切り出してシンプルにする
課題
通知処理がモノリス内の複数箇所に分散して実装されており、
- Webhook URLがコードベースにハードコーディングされている
- フォーマットもバラバラ
- 通知失敗時の再送処理が手動対応
という状態で、**「通知が止まったことに誰も気づけない」**という根本的な課題がありました。
実践構成
ポイントと工夫
- Slack通知は Lambda に一元化、Webhook/チャンネルは環境変数で注入
- モノリス側からは
POST /notifyだけで済むためロジックが明快 - エラー通知も SNS 経由で Slack に再通知可能な設計に
- 通知テンプレートもMarkdown形式で標準化し、チーム間で共有
結果： 通知処理に関する障害が「検知できない」→「即検知＋再送可能」に改善。
📌 バッチ処理をStep Functionsに移して透明性を上げる
Before（典型的なモノリスあるある）
-
crontabで毎晩3時にシェルスクリプト起動 - 実行結果は
/tmp/batch.logに記録されるが、誰も見てない - バッチが失敗しても「3日後に気づく」ことが日常
After構成
導入ポイント
- AWS Step Functions により可視化された「状態管理」と「分岐処理」
- 途中でエラーが起きたステップだけを再実行できる
- Slack通知＋CloudWatchアラートで運用の安心感が段違いに
結果：
- 担当者以外でもバッチの状態が把握できるようになり、属人化から脱却
- 月次レポート作成が自動でSlackに投稿されるようになり、業務改善に直結
📌 UIだけAppRunnerで分離。見える成果をすばやく届ける
Before：すべてがモノリスに閉じていた
- HTMLもCSSもPHPテンプレートに埋め込まれ、修正にはビルド＆リリースが必要
- デザイナーが「動くUI」を見れないため、フィードバックが遅延
- UIの改善サイクルが極端に長く、機会損失が大きかった
After：AppRunner＋API GatewayでSPA化
工夫した点
- AppRunnerは
GitHub Actionsと連携し、mainブランチへのマージで即本番反映 -
NEXT_PUBLIC_API_URLで環境切替を容易に（preview/stg/prod） - API Gateway との連携には
OPTIONSメソッドやCORSヘッダの明示設定を徹底 - Preview URLをデザイナーに共有し、Figmaとほぼ同タイミングで確認＆修正が可能に
導入後の変化
| 項目 | Before | After |
|---|---|---|
| UI修正から本番反映 | 約2日（稟議・調整含む） | 約10分（CI/CD即反映） |
| デザイナーのUX検証 | スクショ or ローカル環境依頼 | 自分でURL確認 |
| APIとの結合度 | 強（密結合） | 弱（疎結合） |
結果：
「UIは変えていい・試していい・すぐ戻せる」という文化が根づき、チーム全体がプロダクト改善に自走しやすくなった。
✅ まとめ
本記事で紹介したのは、「マイクロサービス移行」という大がかりな再構築をしなくても、“分離できる責務から切り出す” という現実解です。
以下のような変化を、小さなステップで実現してきました：
- Slack通知処理の外出し：障害の検知と再送が可能に。通知失敗でビジネスが止まるリスクを回避。
- バッチ処理の可視化・再設計：Step Functionsにより、構成と責任が明確化。属人性の排除。
- UIのAppRunner分離：開発サイクルが加速。デザイナーやフロントエンド担当も“動くプロダクト”に関与できるように。
✅ 重要なのは「技術選定の正しさ」ではなく、
✨「チームにとってリスクの低い一歩を踏み出せたかどうか」でした。
これにより、次のような“チームの体験価値”が向上しました：
- 小さな改善が即座にユーザーに届く
- 機能単位で責任を持ちやすくなる
- チーム全員が「変えていい」と思える文化が育つ
🚩 最後に：これからモダン化に取り組む方へ
- 「全部変えなきゃ」と思わなくてOK。**“できるところから始める”**で十分価値があります。
- 一つでも動かせば、「次の改善」が見えてきます。
- 一番の敵は、“変えたいのに変えられない”という無力感。