この記事に出てくる「当社」や「顧客」その他はフィクションです。ポエムです。実在のものとは関係ありません。
一部ではエンジニアの供給源として早く滅びろとまで言われているSIer、その中でも何ら価値を生み出さないゾンビ扱いのSIerのシステム運用が、もし生き延びることが出来るとしたらどんな姿なのかを考えてみるだけのポエムです。
ダラダラ書きますので、お付き合いしたいひとだけどうぞ。
社葬は嫌でもSIerで運用が好きという変態さんには、下記などを。
オカンや嫁をコアにするのではなく、システム運用をコアにしたドメイン駆動設計を、という差し迫った夢です。
システム運用のドメイン駆動設計、または運用の抽象化（とりあえず背景「SIerの伝統的な運用」）
システム運用のドメイン駆動設計、または運用の抽象化（ドメインを隔離する）
とりあえず、Qiitaを読んでる方が、いわゆるDevOpsやアジャイルという言葉でイメージされているものはこんなんですよね。
役割
素敵なDevOpsがSREとパイプライン
さて、ここで、もう一度ご注意。
自社サービスでスクラム組んでアジャイルDevOpsでSREしているみなさんはお帰りください。ここからとてもつまらない話が始まりますので。
自称Opsのオペレータ、Devだと思ってる実はOps、Ops知らずのDev向けです。
まずは、伝統的なSIerの役割分担概念で、たとえばざっとこんな風にウォーターがフォールするわけですが。
もしこの伝統的ロールの上にDevOpsを重ねるとしたら、いったいどこになるのか？
ここ？
それともここ？
あるいはここ？
はたまたここ？
とまあ、どこまでいっても無意味なのは、そもそもDevとOpsが分かれていること自体、カルチャーとして間違っているからだ。とあなたはおっしゃるかもしれません。
しかし、特定の顧客の複数システムをスクラッチアプリとオンプレシステムと専任運用でアウトソーシングするモデルが、アジャイル&DevOpsのCD/Clに限りなく近かったことは確かな事実。
開発・運用のフェーズではなく、役割的な絵
大中小規模の開発(Dev)と運用(Ops)を継続的インテグレーション
けっこうDevOpsでアジャイルな感じでしょう？ しかも、運用（オンコール）と運用エンジニアリング（設計・開発）が同じSEなので、ほら、みんな大好き SREですよ。
たぶん日本では10年～5年前が全盛のビジネスモデルで、箱物もおさえたそこそこの規模のSIerなら、オペレータや運用基盤インフラ、データセンタなんかも丸ごと抱え込んで、内製している顧客からフルアウトソーシングして囲い込むのがひとつの理想型でした。
そんなアウトソーシングは今や5周目あたりにさしかかり、アウトソーサー同士の奪い合いでもはや単なるコストの叩き合いに過ぎなくなっています。
さてそうなると、戦略として丸ごとが無理なら、システムの開発は余所（他社・他部署）に明け渡し、基盤レイヤの運用だけに絞ってアウトソーシングしようというモデルもよくあります。（この記事はSIerの運用中心でお送りしております）
基盤運用モデル
というか、SIerとしては、開発をプロジェクト単位で終らせ、基盤オンプレやプライベートクラウドなどの基盤のみを対象にした運用を行いながら次の開発を提案するのが普通です。
そうすると、運用期間のリファクタリングは組織に分断されてこうなります。
無理やりアジャイルDevOpsにするなら、ここらの壁を壊していかなければなりませんが、顧客理解を進めれば何とかなるかも…。ガンバレガンバレ。
こんなふうに、さまざまなお客様に営業をかけて、プロジェクト開発&基盤アウトソーシングを繰り返してきたSIerが、どのようになるかというと、
- 複数の顧客を運用し続ける必要が出てくる
- 運用の分割損を防ぐために、運用部門をプール組織化し始める
- 今後の開発受注のために、個々の顧客ルールや技術的個別性を担保する必要もある
といった理由で下の図のような、いわゆる平成のサイロ化組織になっていくのがありがちなところかと思います。（運用SEがアカウント担当とプール化に分かれたところを赤字で強調しています）
そうすると、もう、組織の壁に顧客の壁が重なり、
どれほど顧客理解を進めても、どうにもこうにも無理やりアジャイルDevOpsにはなりそうもない、難しい運用になっていきます。
ああ、いかん、アジャイルDevOpsはこんなモデルだったはず。
再掲
よし、SIerもいっちょかみするぞ。
あー。SIerは意思決定が遅い、と言われる理由の一端はこんな感じで、顧客のサービスではなく顧客の情シスにターゲットを合わせる組織だからなんでしょうね。
なので必然的に、ユーザー企業の内製回帰が起きるわけです。真っ赤。
内製化の流れの中で、SIerが生き残っていくためにITパートナー戦略と一般的には呼ばれている戦略が模索されております。即ち上流SES独占戦略。
これを成功させるためには、
- とても大勢の
- 業務ドメインへの深い理解を持ったSEを
- あちこちの顧客に長期間食い込ませる
というとてつもなく高いハードルがあるわけですが、とにかく次の図のようにうまくいきましたとします。
上流SES独占戦略
しかし、ユーザー企業はベンダーロックインを当然嫌いますので、結果として、ユーザー部門（サービス）ごとに複数のベンダー（SIer）がからむことになります。
縦割りDevOpsとでもいうのでしょうか。
これでも、横のサービスと疎結合でありさえすればそこそこ共存できるモデルではあるかもしれません。
が、ユーザー企業としては、そんなラインを幾つも抱えているのは非効率。必ず、運用は統合したいという話が出ます。運用をアウトソーシングしているSIerはとびつきます。
縦割りアジャイル独占Ops時代の到来です。
いや、ひとつのお客様様内でも単純に運用を集めただけではアジャイルできないし、運用コストが下がるかも非常に疑わしい。
しかも、SIer視点で見ると、そういう様々な運用を要望する複数の（もちろんできるだけ多くの）顧客に同一部門で提供していかなければいけないビジネスモデルなわけです。（下図、マルチテナントOps）
そんなわけで、様々な運用要件をもつサービスを受け入れられる組織・仕組みを作り上げたSIerだけが生き残れるのだと思います。SIer滅亡まであと数年。
図式的には下図のようなものだろうと思います。
もちろんこの図は単一顧客になっていますが、これを複数顧客にも拡張していかなければいけないわけです。
といった背景もあり、システム運用をドメイン駆動設計する、なんてことを考えていたのでした。
システム運用のドメイン駆動設計、または運用の抽象化（とりあえず背景「SIerの伝統的な運用」）
システム運用のドメイン駆動設計、または運用の抽象化（ドメインを隔離する）
どなたかに届いてお役に立てれば幸いです。長寿と繁栄を。