読み物：『少人数インフラチームで「何でも屋」をやめ、専門領域に分割してみた』

こんにちは。マイクロアドでインフラエンジニアをしているハダです。
今回は技術そのものの話ではなく、インフラチームの組織体制（エンジニアリングマネジメント）について書いてみました。
マイクロアドのインフラチームが2年前（2024年）から試行錯誤している取り組みで、
これが正解とかバッチリ成功したという内容ではなく、こんな取り組みしていますというような現在進行形の読み物になっています。
何かの参考になれば幸いです。

背景

マイクロアドでは、初期の頃からインフラを管理するチームが存在しています。
当然ながら、最初は数名のチームで始まり管理するインフラの規模も今ほど大きくはありませんでした。
その後事業の拡大とともに、インフラの規模も大きくなりそれに伴ってインフラメンバーも増員して行きました。
増員しているとはいえ、それでも最小の人数でインフラを管理している状況となっています。

なぜ「全員で何でも屋」をやめたのか？

徐々に拡大していくインフラを当初から管理しているメンバーは、拡大していくインフラのみについて追加で学習していくだけで済んでいました。
しかし、途中から合流したメンバーはその様々なミドルウェアや稼働しているアプリケーションの特性など、
一度に学習しなければならず独り立ちするまでにそれなりの時間を要するようになりました。

あるタイミングまでは、「全員がすべてのことに対応できる状態」が理想的な状況でしたが、
学習コストが大きくなった影響でそれも叶わない状況が発生してきました。

いつの間にか、「あの人が詳しい」とか「私に任せろ」みたいな暗黙的な分担が存在し始めました。
この暗黙的な分担がオフィシャルなものではないため、チーム外から見ると「この件って誰に頼むのが良いんだろう⋯」みたいな迷いを生む原因になっていました。
またチーム内でも、「詳しい特定の誰か」にタスクが集中し、実質的な属人化が進んでしまうという、少人数チームならではの限界が見え始めていたのです。

少人数チームをどう「分割」したのか？

もともと少人数だったため、そもそも分割することが正しいのかといった意見もありました。
また、簡単に「ここからここまで」というような業務分割ができず、どうやって分割するかが、大きな課題でした。
検討を始めてから、時間ばかり過ぎていき、果たしてどの程度の規模に分割するのが理想的なのか全く見当がつかない状況でした。

全体をきれいに分割しないことにした

正直行き詰まっていました。
ですが、このままではこの先大きな問題になっていくという懸念もあり、思い切って発想を変えることにしました。
それは、「きれいに分割しようと努力しない」ことでした。
まずは「全体の中から明確に領域を切り出せる部分」を小さな1つのチームとして分離することを検討してみました。

その頃マイクロアドでは、データ基盤の移行計画が進行していたこともあり、このデータ基盤の移行に係る部分と
それに付随するログ転送などのシステムを管理する1つのチームを作ることにしました。
それ以外のことについては、今まで通り1つのチームで管理することにしました。
このようにアンバランスな形ではあるものの、２つのチームに分割し領域を明確にしたことで、
データ基盤を管理するチームは、「データ基盤の移行準備に集中的に取り組める環境」ができ、
もう1つのチームも「それ以外をやるチーム」として線引きを作ることができました。

すべてがうまく行ったわけではなかった

環境の変化はメンバーへの負担にもなっていて、かなり大変な思いをさせてしまっていました。
特に、「明確に分けられるところ」と言いつつ分担したはずが、「どっちが管理すべき？」というような
グレーゾーンがやはり発生してしまっていたのです。
そういった状況も生まれてしまい、今まで通り１つのチームでやってたほうが良かったのに…ということも多々発生していました。
それでも、専門領域の分割によって心理的な負担の軽減が少なからず起きていたのも事実です。

課題を糧にさらなる進化

2つのチームに分けてからしばらく経ち、新たに別の課題が発生してきました。
その他の領域を受け持っていたチームの負荷が高くなり始めました。理由は、チームを分けた際に技術レベルの高いメンバーがデータ基盤を管理するチームに集中してしまったためです。そういった状況も発生してきたため、2つに分けていたチームをより細かく分けていくことを検討し始めました。
その時に、改めてインフラがどういった技術で成り立っているのかというのを整理しながら、
どういう切り口で分けていくのが適切なのか考え始めました。

技術領域の整理

インフラと一言でいってしまうと分ける必要はないのでは？と考える方もいるのではないでしょうか。
ですが、実際には「サーバ」と「ストレージ」、「ネットワーク」という分野に分けることができたり、
「サーバ」の分野も「OS」、「ミドルウェア」、「アプリケーション」、さらには「仮想化」、「コンテナ化」などいくつかの切り口で分けることができます。

細かい領域に分けてみることに

そういった、技術領域を整理していく中でざっくり大きな領域毎に安易に分けてしまうと、業務的に分けづらいということが発生しそうだったため、
領域を細分化したうえで近いところはまとめつつ、切り離せそうな箇所は分けるということを行うことにしました。
そうすることで、マイクロアドでは大きく以下の6つの領域に分けて管理してみることにしました。

データ基盤領域
監視・セキュリティ・DevOps領域
ストレージ及び仮想化・コンテナ化領域
配信サーバ、管理画面サーバ領域
ネットワーク、サーバOS領域
パブリッククラウド管理領域

このように6個の領域に分割しました。

少人数×専門化の「最大の課題」にどう立ち向かっているのか？

分割することでそれぞれ専門化はできたものの、別の視点では属人化がより進んでいる状況になったと捉えることもできます。
この属人化の課題が発生することはあらかじめ認識していたので、専門化をする際にメイン担当（基本1名）＋サブ担当（複数名）のような割り振りを行うことで
可能な限り2名以上のメンバーが状況を理解できるようにしていきました。
ただ人員は多くないため、一人が少なくとも2つの領域に参加するという状況にしました。
これによって、最低2名以上いるチームを6個作ることができました。

今現在、チームはどう変わったのか？

最初にチームの体制を変えてから2年3ヶ月、現在の技術領域体制になってから約1年が経過した2026年6月現在。
私からみたチームの状況はまだまだ荒削りな感じで、メンバーに負担をかけていると考えています。
領域を分けたからといって、業務量そのものが減ったわけではありません。

ただ、業務の内容に対してコンテキストスイッチによる負荷は下がったように感じます。

私がみている視点だけでは、実際どうなのか読者の皆さんもわからないので、
メンバーの協力を得てアンケートを実施することにしました。

メンバー意識調査

質問は10個で、Q1〜Q7は1〜5の5段階評価、Q8~Q10の3つは選択式にしました。
そして、可能な限り本音で回答してもらいたいと思い、無記名でアンケートを行ってみました。

回答としては、以下のようになりました。

「技術領域の分割について全般的にどう思ったか」

約16％が「少し良くなかった」
約33％が「良かった」
約50％が「どちらでもない」

「知識の深堀りができるようになったか」

約50％が「深堀りできるようになった」
約33％が「少し深堀りできるようになった」
約16％が「どちらでもない」

「チームをもとに戻したほうが良いか」

約67%が「今のままで良い」
約16％が「戻さなくてもよいが、改善が必要」
約16％が「戻したほうが良い」

全員が満足している状況ではなく、少なからず課題に感じている部分があるということがわかりました。

見えてきたもの

アンケートの状況を振り返ると、ポジティブ・ネガティブ両方の意見がありました。
ポジティブな意見が若干多めではありましたが、そんな中でもネガティブ意見を出してくれている方には感謝しています。
このアンケート結果は当然なことだと思っており、またある意味でメンバーがそれぞれ主体的に考えてくれているということでもあると思っています。
全員が納得感を持って前進していけるチームを作ることは、並大抵の努力では叶わないということが改めて分かってきました。
それはチームマネージメントだからこそ仕方のないことで、課題がありつつも前進・進化していくというのがチームにとっては必要ではないかと思っています。