私は新卒のときから10年ほどIT業界、ときには会社を移りながらエンタープライズのSI（System Integration）のさまざまな現場で働いてきましたが、システム開発のチーム編成として「アプリケーション担当」と「インフラ担当」に分かれていることが長らく当たり前でした。
最近はAWSをはじめとするパブリッククラウドの台頭、特に抽象度の高いマネージドサービスの普及によって従来型の分業モデルが理に叶わなくなってきたのでは？と感じることが増えたので、ポエムを書いてみます。
みなさんの案件はどんなチーム分けですか？
私がよくいた「エンタープライズの業務システム開発」はこんなフォーメーションが多かったです。
とある社内向けWebシステムの開発体制
- ユーザー企業（発注元の会社スタッフ）
- アプリケーション担当：通称「業務」。要求定義と仕様調整。事業会社だとコードレビューまではしないところが多い印象
- インフラ担当：主にサーバー（仮想マシン）〜ミドルウェアぐらいまでを管轄
- 共通基盤担当：自社データセンターにハイパーバイザーを構築し、仮想マシンを各部署に払い出す
- ネットワーク担当：自社データセンターのネットワークを管轄。セキュリティ担当チームと同組織のことも
- 運用担当：リリース済みシステムの監視や定常作業を行う。イレギュラーは開発部門にエスカレ
- 開発ベンダー企業（プライムSIer、および再委託先のSES会社スタッフ）
- アプリケーション担当
- インフラ担当
上記は2010年台のエンプラITの基本形なんじゃないかと勝手に思っているのですが、VMware等の「サーバー仮想化」全盛期ぐらいはこのチーム分けが理にかなっていた側面もあると思います。
クラウドの登場で変わってきたこと
最近はようやく大企業でもシステム開発のプラットフォームとしてパブリッククラウドを活用することが当たり前になってきました。一見するとEC2のような仮想マシン作成サービスも充実しているのですが、従来の「サーバー仮想化」や「レンタルサーバー」の延長では扱いづらい部分が出てきます。
- これまではネットワーク担当が見ていた領域がクラウドサービス内に登場する
- エンプラによくある「共通基盤」担当の仕事がなくなる
- 逆にシステム監視やセキュリティ等の共通機能が既存のものを適用できなくなる
- 抽象度の高いマネージドサービスはこれまでの「アプリ」「インフラ」で線引きしづらい
従来型の体制でクラウドを扱うとぶち当たる課題
以下のようなケースって現代のエンプラあるあるではないでしょうか。
- 従来の「インフラ（サーバー）担当」がパブリッククラウドを扱う中心的な役割になるものの、「サーバー仮想化」の延長でプライベートネットワーク＆仮想マシンありきのハコ作り屋さんマインドでシステムを設計してしまいがち
- アプリケーション担当は従来どおり「早く環境ちょうだい」マインドとなりがち。結果的に両チームともパブリッククラウド特有のアーキテクティング思想に欠けてしまい、本来優先して活用すべきマネージドサービス（サーバーレス/コンテナ etc.）の適切な選定がされづらい
- 監視やセキュリティなどの共通機能を新たに作る必要があるため、いつもどおり「どデカい共通機能プラットフォーム」を作ろうとする動きがでてくる。慣れないクラウドに対して最初から壮大なアプローチを仕掛けるため、設計までにとにかく時間が掛かるし失敗もしやすい
うまく進まない根本的な原因には以下のような点もありそうです。
- 主に開発の実務を担当するSIerは「とにかく安定したシステムを作ること」がプロジェクト管理上優先となる。クラウドかつマネージドサービスのような、エンプラ現場で実績が比較的少なく、自社に長けた技術者も豊富でない領域でチャレンジする発想になりづらい。裏を返すと発注者側に強力なスキルと意思が必要
- 分業制の悪いところが出てしまい、クラウド特有の新出要素に対してボールの押し付け合いが発生し定例会の空気が険悪に…。チーム間の役割の整理は発注社もしくはPMO担当ベンダーが適切に整理し協力的に仕事を進められるようにすべきだが、そもそも本来技術面に強くないはずの「ユーザー企業のシステム部門」スタッフに対してクラウドという新技術の理解がハードルとなり、より適切な分担の提案を行う動きになりづらい（分からない仕事を受けたくない＝守りに入ってしまう、これは当たり前の動きにも思えます）
実際、クラウド使っても以下のような分担になってしまうとデメリットしかないのではないでしょうか。
- EC2の構築はインフラ担当。でもサブネットやセキュリティグループの設定はネットワーク担当に依頼（Excelヒアリングシートに書いてメールで送付）
- AWSのLambdaファンクション用のコードを記述するのはアプリ担当。それをAWS上にデプロイするのはインフラ担当
- Amazon API Gatewayのリソースを記述するのはアプリ担当。オーソライザーやリソースポリシーの設定はインフラ担当
- などなど…
もうイチイチ分担を考えるのが面倒すぎて、さらに無駄な伝言ゲームと調整がつど発生しまくりでアジリティもへったくれもないですね。システム作業のチーム間調整は会社をまたぐことになるので、壮大なコの字型の伝言ゲームになる点も忘れないでください。
じゃあどうすればいいの？
クラウド時代の開発体制は 「フルスタックの権限を持ったワンチーム」で小さく初めて、少しずつチームを増やしてスケールさせる のが最適解ではないかと思っています。
逆に言うと「これからクラウドやっていき！どでかいプラットフォームぶち上げるぜ〜」はリスクが上がってしまうアプローチと言えそうです。そもそもオンプレミスにおいても、ぶち上げ作戦は痛い目をみた方も多いのではないでしょうか。ぜひ草間さんの神スライドを復習しておきたいところです。
アプリ（業務）・インフラ（基盤）のチーム分けは、クラウドを活用するプロダクトにおいては独立制のワンチームで小さく初めて試行錯誤し、感覚をつかめてきたら「業務領域」ごとにチームを横に増やしてスケールさせていくのが良さそうです。
この理由として、そもそもパブリッククラウドの設計思想は「アプリケーション開発者がいかに楽して本質的なビジネスロジックに集中できるか」を起点に考えられているので、クラウドは開発者がコードを動かすために必要な補助ツール、ビルディングブロック群として活用できると合理的です。
つまり現代のシステム開発においては、従来のアプリケーション担当・インフラ担当がお互いに歩み寄って双方の技術領域を理解するリスキリングを行い、ワンチームの中で適切にタスクごとの分業をしながら共同開発を進めていくのが良いのではないでしょうか。
モブプログラミングを取り入れて、チーム全員フルスタックで対応できる形を目指すのも素敵だと思います。
おわりに
今回のお話はクラウドを例に挙げましたが、これからはAI領域でも似たような苦難がエンプラ各社を待ち受けているかもしれません。日本の伝統的なエンプラ企業（いわゆるJTC）のいいところは「みんな人が良くてビジネス総合力が高い」ところだと思うので、IT業界を次々と襲う新技術トレンドに対してうまく立ち回っていきたいですね。がんばれ日本企業！