会社の組織形態でアプリチームとインフラチームが別れていることについて、メリットよりデメリットの方が大きいと感じており、記事にしてみます。
書きたいことがちょっとわからなくなったので、ChatGptに書いてもらいました。少し加筆しています。
1. はじめに：なぜ今「チーム分割」が議論になるのか
クラウド・コンテナ・IaC（Infrastructure as Code）が当たり前になった現在、アプリ開発とインフラ構築・運用の境界は昔よりも曖昧になっています。 一方で、組織が大きくなるにつれ「アプリチーム」と「インフラチーム」を分けるケースも多く見られます。 両チームを分けることのメリット・デメリットを整理し、自分の意見を考えます。
2. チームを分けることのメリット
2-1. 専門性を活かせる
インフラにはネットワーク・セキュリティ・クラウドリソース・運用監視など、アプリ開発とは異なる深い専門知識が必要です。 専任のインフラチームを置くことで、セキュリティポリシーやインシデント対応を組織的に強化できます。
2-2. 責任範囲が明確になる
「誰がどこまでを見るか」が分かれていることで、障害対応やセキュリティ事故などのときに責任の所在が明確になります。 SLA/SLOの定義や監視設計もインフラチームが一貫して管理できます。
2-3. スケーラビリティと再利用性の向上
複数プロダクトを支える共通基盤（共通VPC・ログ基盤・CI/CD環境など）をインフラチームが横断的に管理することで、アプリチームは機能開発に集中できます。
3. チームを分けることのデメリット・課題
3-1. コミュニケーションコストの増大
分業すると「依頼・調整」が発生します。 例：アプリのリリース時に「このセキュリティグループを開けてください」「このLambdaに環境変数を追加してください」といったチケットのやりとりが頻発し、スピードが落ちることがあります。 例：予算はどちらのチームにつけるか、提案したチームに予算をつけるか。必須のことしか対応しなくなります。
3-2. 境界領域の「グレーゾーン」が発生しやすい
アプリ側もリソースを触るケースが増えると、「これはどちらが管理する？」という中間的なリソース（例：S3バケット、Lambda、API Gateway）が出てきます。 明確なルールがないと属人化や二重管理につながります。
3-3. 組織規模
少人数のスタートアップなら「アプリ＋インフラ一体」で十分。
中〜大規模では専門性の分離が有効になりそうです。
4. まとめ
「グレーゾーン」が個人的に一番よくない部分だと思っています。
例えば「ログを記録すること」が抜けている場合、アプリが指定しないことが悪いのかインフラが設定しないことが悪いのか、どちらにも言えることになります。
こういう部分がコミュニケーションコストの増大につながり、アプリチームはできるだけインフラに依頼しないよう工夫したりするでしょう。
書いていて思うことは、コミュニケーションが行いやすい組織であれば、チームが分かれていてもいいのかな。と思えるようになりましたね。
