DevOpsが文化を持ち出す理由　ー20年前の大規模システム開発でのDevOpsー

DevOpsDays tokyo2018は興味があったけれど結局は予定がみっちりで行けず、いくつかの公開資料を眺めながら20年前に参画していた大規模システム開発での開発からリリースするまでのプロセスを思い出す。

これまで経験してきたシステム開発とプロダクトのデプロイが幾つだったか数えていない。つまり、エンジニアは無意識に、いや、当たり前にプロダクトの開発とデプロイを、今風に言うならDevOpsに関わっているのである。

ただ、それがDevOpsの概念的に一致しているかどうかはわからないが。

契約としてのDevとOps

20年前の大規模プロジェクトではっきりと意識したのが契約としてのDevとOpsの違いだ。Devは開発、SI、システム開発である。Opsは維持管理、保守、SOである。前者は準委任契約若しくは請負契約で契約を締結する。Opsは人工契約で締結される。

絶賛設計中や絶賛開発中であればシステム開発オンリーだから、Devしかないし、それ以外意識しないものだ。ただ、UAT工程の準備が始まると工程推進の作業主体は顧客に戻るのでプロダクトの管理も顧客に移転される。

このタイミングで維持管理が発生する。こうしたことを理解できるようになると、契約が２本発生する理由も理解できる。

これが契約面でのDevOpsを意識したキッカケである。

UAT工程に入るとプロダクトの管理主体は顧客に移ると上述した。これによりプロジェクト推進で大きな転換点を迎える。

それは何かというと、Dev都合でコードの変更ができなくなる。プロダクトが顧客に移転されたからだ。それまで、Devサイドのテストまではバグがあれば手続きはするとしても比較的気軽にコードのリプレースができた。エンジニアもまた、バグは修正すればいいんでしょ、くらいな気持ちでいたものだ。

ところが顧客にプロダクトが移転されるとどんなバグであっても容易に置き換えることはできなくなる。顧客に申し出て承認を得なければならなくなる。承認をもらうために変更に伴う影響調査、設計変更、何段階ものテスト。それらのレビューと証跡を記録し、顧客のレビューを超えられたものだけがデプロイされる。

それがエンジニアの手続きを経て行われていた。

稀に致命的な不具合が見つかる。多くは考慮漏れである。それだけ複雑な要件が起因で、エンジニアの考慮をすり抜けていた業務ロジックが存在したということだ。

致命的な不具合で業務上の影響が甚大な場合、顧客の手続きも行われるが緊急事態であることから最優先の特急で手続きが進められる。

これはとても象徴的である。

リリース案件が1件であれば大規模システムでのプロダクトのリリースも数時間で可能ということだ。システムの特性上、必ずリリースには人的判断が伴うとしてもそれ以外では数時間で可能ということを証明している。

ただ、リリースに関係する処理全てを人海で対応しなければならなかったのかと言えば、それは違う。当時は、テストまでのプロセスを人手に頼らなければならなかったのだ。今は、それをシステムで対応できるまで技術が追いついたのだ。

見方を変えれば、20年前の大規模なシステム開発のDevOpsと今のDevOpsに違いはない。人海かシステム対応かだけの話だ。

こういうことからもこれからエンジニアはどこの技術にフォーカスすれば良いのかある程度推測できるだろう。今の技術の延長でいつまで飯が食えるか。

そんなことを考えているエンジニアの方が稀有なのかもしれないが。

変わったのは顧客だったのではないか。20年前なら技術的に不可能だという言い訳に仕方がないと諦めることができた。今はそれは諦められなくなった。それが最大の理由だろう。

DevOpsの定義は諸説あるようだが、文化が持ち出されるところが腑に落ちなかった。スライドを見つつ、これまで目の前を過ぎ去っていったシステム開発での知見から導き出されたのはこれだった。

テクノロジーのパラダイムシフトにエンジニアが転換するためのクッションとして文化を引っ張り出しているのではないか

と思い至った。結局、エンジニアが変われということをソフトに示唆しているだけなのだろう。