問題を分解して考えよう -ECS移行の事例から-

はじめに

この記事はSchoo Advent Calendar 2025の12日目の記事になります。

こんにちは。Schoo 技術戦略部門・インフラチームの櫻沢です。

私のチームではインフラや開発組織に関わる様々な技術的課題を解消する役割が求められています。
そこで課題解消のプロセスについて私の考え方を整理してみました。

この記事で言いたいこと

言いたいこととしては、タイトルの通り以下に尽きます。
問題を分解しよう

「そんなの当たり前では？」と思われるかもしれません。
しかし、これを脳内だけで完結させず、図や表に落とし込んで進めることで以下のメリットが生まれます。

• 問題の見極め
  そもそも本当に工数を使って解決すべき問題なのかを判断しやすくなる
• 考慮漏れの防止
  問題の重要な要素を見落としにくくなる
• 議論の収束
  チーム内での認識ズレや議論が発散を防ぐことができる
• 納得感
  なぜその手段を選んだのかを説明しやすくなる

この記事では、具体的な方法と活用した事例について共有します。

問題解消のプロセス

ざっくり以下のステップで進めています。
ポイントは、脳内や口だけで進めず表や図で明示しながら進めることです。

活用例

Schooではコンテナ基盤をEKSからECSへ移行する方針を取っています。
本記事では、従来のEKS運用におけるバージョンアップ作業のインシデントリスク整理を契機にして、「既存の問題」を分解し、その打ち手として「ECS移行」を判断した例をご紹介します。

注意

• 本記事にEKSおよびKubernetesを批判する意図はなく、現状の弊社アプリケーション構成や運用体制に適した方法を検討した際の事例となります

もし問題を分解しなかった場合

仮に上記のリスク整理を受けて「EKSは問題あるからECSに移行しよう」という声が上がったとします。もし問題を分解せずに直線的に進むと以下のようになります

この進め方にはたくさんのツッコミ所があると思います

• 仮説
  • リスクや影響の度合いに対して、本当に解決すべき問題なのか(基盤を変える労力に見合うのか)
• 要素
  • EKSの問題はバージョンアップだけなのか
• 打ち手
  • 他にも打ち手を考えられないか
    • EKSのままでもBGバージョンアップで解消できないか
    • ECS移行のデメリットはないのか

このままECS移行をすると、本来解決すべき問題を放置したまま移行してしまうかもしれません。
このような表面的な問題解決を回避するために、問題を分解して考えていきます。

問題を分解した場合

EKSの問題を以下のように分解して考えました。

注意

• ここで挙げている問題は一般的なEKSの問題だけではなくSchoo独自の問題を含みます
• 都合上、全ての要素を記載しているわけではありません
• 今回はAIで作図していますが、通常は修正しやすいようにマークダウンの表・箇条書きやdraw.ioで表現しています

上記を分析をしてチームで話し合った結果「ECS移行する」方針で合意しました。
大きな理由は以下の通りです。

• 解決すべき問題か
  問題の要素を洗い出すことで、現状の問題がトイルの発生・コストの増加・サービスレベルの低下など様々なペインを発生させていることが分かりました。このことから工数をかけても解決すべき問題と判断しました。

• 打ち手の比較
  既存のEKSを使いやすく改修する打ち手も検討しましたが、ECS移行と工数は大きく変わらないと試算しました。であれば、最もペインが大きかった「バージョンアップ運用」を根本から断ち切れるECS移行の方が、長期的メリットが大きいと判断しました。

• 「守り」から「攻め」へ
  EKSの維持管理に割いていたリソースを、移行後はサービス改善に充てることができます。また、複雑なマニフェスト管理やデプロイフローといった技術課題もこのタイミングで一掃できると判断しました。

• トレードオフの許容
  ECS移行のデメリットとしてベンダーロックイン・エコシステムの縮小があります。しかし、今のSchooにとって重要なのは「ポータビリティ・機能の豊富さ」よりも「少人数・低工数で安定して回せる仕組み」であると判断したため、このリスクは許容範囲内としました。

問題を分解しなかった場合と方針自体は同じですが、ECS移行によって何を成し遂げたいのかをはっきりさせることができました。
解像度が低い状態で移行プロジェクトを立ち上げるのとは雲泥の差があると思います。
例えば、直線的なアプローチではマニフェスト(タスク定義)管理やデプロイフローの問題を残したECSを構築してしまうかもしれません。
これは問題を分解して考えた成果だと考えています。

終わりに

Schooの掲げるミッションは以下の通りです。

世の中から卒業をなくす

これに貢献するため、インフラチームでは様々な施策を打っています。
私はすぐに打ち手に飛びついてしまう癖があるので、今回の方法でなるべく本質的な対応ができるように工夫しています。

この手法が少しでも皆さんのミッション達成のヒントになれば幸いです。

コラム: 複雑な技術的問題をAIに丸投げできるか?

2025年12月現在は難しそう。

• AIは打ち手をリストアップして比較したり、実装することは得意
• 一方で、企業独自の問題を発見・分析させるためには、暗黙知が多すぎてコンテキストが不足している
• しばらくはAIと分担すると良さそう
  • 人がメイン
    • 問題(仮)の特定と分解
    • 問題・要素の重要度判定
    • リストアップされた打ち手の選定
  • AIがメイン
    • 打ち手のリストアップ・比較
    • 打ち手の実装

---

Schooでは一緒に働く仲間を募集しています！