FIXER cloud.config Division General Managerのいさおです。
今、DevOpsを勉強しているところなんですが、初見じゃないような気がしています。
15年くらい前まで担当していたメインフレームの環境管理で見てきたことを思い出しながら書いてみたいと思います。

DevOpsとは

Wikipediaによると、こんな説明だ。
・開発担当者と運用担当者が連携して協力する（さらに両担当者の境目もあいまいにする）開発手法をさす。
・厳密な定義は存在しておらず、抽象的な概念に留まっている。

うーむ。
あいまいで抽象的なので、なんのこっちゃかわからない。
さらに、アジャイル開発だとかCI/CDだとかIaCだとか、先進的なワードのオンパレードである。
もっとわからない。

Wikipediaより
DevOps（デブオプス）は、ソフトウェア開発手法の一つ。開発 (Development) と運用 (Operations) を組み合わせたかばん語であり、開発担当者と運用担当者が連携して協力する（さらに両担当者の境目もあいまいにする）開発手法をさす。厳密な定義は存在しておらず、抽象的な概念に留まっている。ソフトウェアのビルド、テスト、そしてリリースの文化と環境を以前よりも迅速に、頻繁に、確実に発生する確立を目指している。 また、DevOpsにビジネス部門を追加したBizDevOpsというワードも広がりつつある。

https://ja.wikipedia.org/wiki/DevOps

だがしかし。
「 開発担当者と運用担当者が連携して協力 」というワードにビビっとくるものがある。

ITむかしばなし

むかしむかしあるところに、コボラーという開発者とメインフレーマーというインフラ管理者がおりました。

コボラーは、メインフレーマーが構築した開発環境でコーディング→コンパイル→テスト→リリース申請を行い、メインフレーマーは、コボラーからリリース申請があったモジュールを一定の手順で本番環境にデプロイしておりました。

すると、ある日オープン系という波が押し寄せ、高額なインフラをメインフレーマーが購入して一元管理しなくても、インフラを簡単に手に入れることができるようになり、アプリケーション開発者が独自で作り出すインフラ環境ができあがってきました。

独自に進化し最適化されていったオープン系の開発と運用は、自由というすばらしい権利を得てしまったため、クラウドという波が押し寄せてきた時に、提供されるプラットフォームの制限の中で最適なアーキテクチャを設計するということの難しさを知ることとなりました。

しかし、メインフレーマーが構築したプラットフォームという制限の中で最適なアプリケーションを開発していたコボラーは、すでに絶滅の一途をたどっており、その知見が活かされる機会を得ることは難しくなってしまいました。
むしろ、それにすら気づけていないかもしれません…。

メインフレームの開発と運用

私の記憶によると、下図1のような感じだったと思います。
青い部分がインフラ担当が構築、管理していたような。
緑の部分がアプリ開発者が使っている部分。
運用部門が 「ストレージ」「磁気テープ」「プリンタ」の使い方を定義し、 アプリ開発者は、それに従ってプログラミングしたりJCLを作っていたので、インフラや監視の運用を作り上げた側のルールに従って、アプリ開発に注力していた気がします。
この運用部門が定義した「ストレージ」「磁気テープ」「プリンタ」の使い方というのがいわゆるクラウドのNative機能に相当するんでしょうね。
下図1を見てみると、Jira、GitHub、Jenkins、AnsibleやTerraformに相当する機能やToolもあったように見えます。

最後に

クラウドの利用基準を作りたいとか、クラウドの導入手順を作って適切なクラウドジャーニーを楽しみたい方々。
DevOpsを実現するには、アジャイル開発だ！マイクロサービス化をしなければならぬ！！とか、GitとGitHubのどっちにする？だとか、JenkinsとCircle CIのどっちにする？とかで悩むのも大事なことですが、コボラーとメインフレーマーに概念を聞いてみたり、ルールを作ってもらうのも一つの手かもしれません。
信じるか信じないかはあなた次第です。