コラム

BTCクラウドCoEの野口です。
BTC Tech Blogの記念すべき１回目のブログを書くことになりました。DevOpsについて少々書きたいと思います。

DevOpsとは

猫も杓子もD・e・v・O・p・s！という昨今ですが、とても抽象度が高い概念でして、TPOによって内容が大きく異なっていますので、さらっとDevOpsについて今一度整理しておきましょう。

そもそもDevOpsとは

Devはソフトウェア開発（software development）、OpsはIT運用（information technology operations）の略です。DevOpsは、これら2つの用語を組み合わせた混成語であり、ソフトウェア開発手法の一つです。システム開発における開発ライフサイクルの短縮化を狙いとしています。

しかしながら、日本人が欲するアカデミックな皆様による一意な定義、というものが残念ながら見当たりません。「既存のシステムを変更するとき、高い品質を希求することは当然のこととして、それだけでは飽き足らず、さらに短い期間でシステムを置き換えられるようにする実践的取り組みなんだぜ、ベイベー」というあたりが、大きな反論も招かないコンセンサス可能な定義となりますでしょうか。

このDevOps、開発担当者と運用保守担当者の間で長く続く闘争に終止符を打ち、互いが愛の手を差し伸べて協力し合う開発手法としても注目されています。犬猿の仲ともいえる開発と運用が、仲良く手を取り合うことなどできるのでしょうか。DevOpsの本質を知る上では、このような観点からのアプローチも必要となってきます。

ここでは、DevOpsという言葉が生まれた背景について、筆者の私見をちりばめながら記していきます。

DevとOpsに、何故分かれたか

遙か昔、大企業のシステム部門は開発（Dev）と運用（Ops）とに分かれていました。私が過去所属していた会社も、いわゆる大企業、中小企業と規模は異なりますが、確かに分かれていました。いま、周りを眺めても　～事業部、部門、課などのレベルは違えども～　開発と運用とに部門を分けている企業が多いように思います。大企業では、戦略子会社がその役を担う、ということもありますね。これは、IT産業が、ハードウェア中心に育ってきたことに起因している、と筆者は考えています。ハードウェアを作るためには、研究開発、製造といった工程は外せません。また、その作ったハードウェアをお客様に提供するためには、運用保守という工程も必要です。これらの各工程に要求されるスキルや要員の数は当然のことながら異なってきます。組織の形態を職能別組織、つまり、研究開発、製造、運用保守のように分割することは、経営的な視点からも合理的な選択です。このような経緯がもとで、開発と運用は袂が分かれてしまったのだと考えます。

開発と運用に求められていたもの

さて、職能別に組織を分ければ、必然的にその組織の目標や評価もその特性を踏まえて定義することになります。この組織目標・評価を、開発と運用の間でうまく平衡（バランス）させることが、犬猿の仲と言われるDevとOpsとが手と手を取り合い、一丸となってDevOpsを推進するためのキーポイントとなります。

開発と運用の一般的な目標・評価を考えます。

開発担当者は、ハードウェアまたはソフトウェア（以降、二つあわせたものを「システム」と呼びます。）に対する改修を施することで新しい付加価値を提供すること、つまりシステムに変化を与えることを任務としています。新しい技術が生まれれば、それを試行してみて、「いいぢゃないか！」と思えば「それ採用！」という、変化を恐れない気質の集団と言えばいいでしょうか。

一方、運用担当者は、システムの安定稼働がその主たる任務です。作業の効率化を求めますが、ドラスティックな変化を自ら望んで求めることはしません。システムを不安定にする要素は徹底的に取り除く、黒子集団のようなイメージです。

まとめると、それぞれの担当者に求められているものは、変化と安定であり、対局に位置するものであることがポイントです。

不具合対処の考え方と変化

システムを新規に開発する、または改修を施せば、当然のことながら不具合（いわゆるバグ）の発生は避けることはできません。不具合を発生させないために、システムを開発・改修しない、という考えもありますが、企業が存続し発展していくためには、そのような考えは絵空事であることは言うまでもありません。

ここで、ハードウェアとソフトウェアに分けて、この不具合への対処についての考え方の変化を見てみましょう。

ハードウェアで不具合が生じたとき、その不具合を改修することはとても困難です／でした。なぜならば、その不具合を改修したハードウェアを、物理的に置き換えなければならないから、です。ハードウェアが設置された場所に赴き、一つ一つ置き換えていく…。全国行脚、キャラバン、といえば聞こえはとてもいいですが、これはとても大変な作業ですし、コストも掛かります。このため、ハードウェアの開発は、一度リリースしたら最後、不具合が発生したとしても適切に改修されることはほぼないまま「運用で回避！」「運用マニュアルの改版で乗り切るぞー」という考えに至ってしまう、そんな時代でした。

20世紀の末からは、産業の中心はハードウェアからソフトウェアへとシフトしてきました。有形であるハードウェアから無形であるソフトウェアへのこのパラダイムシフトは、ビジネスやサービスの在り方にも大きな影響を与えました。先ほど触れた、不具合に対する考え方もその一つでしょう。「不具合があれば、改修してアップデートを提供すればいいじゃないか」。この考えは、ハードウェアを中心に据えて生きてきた組織には、死活問題です。「運用で回避！」という皆様の職（食）を奪うからです。

さて、そろそろ誌面も尽きてまいりましたので初回はこの辺りで。第2回でお会いしましょう。