keyboard_double_arrow_up

Blog X-Tech 5エンジニアがお送りするテックブログ
SREやDevOpsをはじめ、インフラエンジニアリングの実践情報を届けします。

DevOps入門編 DevOpsとは何か?実現する方法

2021年10月26日 

DevOpsとは?いま、求められる理由

 

現代のシステムは、激しいユーザー獲得競争に晒されています。

 

直接エンドユーザーにシステムを提供する場合もさることながら、サービス・事業においても、それを支える「システムの良し悪し」が「市場での勝ち負け」に直結する時代になっています。

 

サービス・事業が激しい市場競争の中で生き残るためには、ユーザーに対して競合よりも高い価値を、継続的に提供しなければなりません。

 

Dev(Developer=システム開発者)とOps(Operator=システム運用者)は、その立場・職責から優先順位の齟齬が起きやすい関係にあります。

 

Devは機能開発などシステムの強化を志向しがちで、Opsは応答速度などシステムの安定化を志向しがちというのが、典型的な例です。 立場を分け、職責を分けることで、それぞれの役割がサイロ化し、見えない壁ができてしまいます。

 

市場で外部と競争する状態で、この内部の齟齬はいただけません。 市場=外の世界に目を向け、この見えない壁を壊すべし、という考え方(=価値観)、見えない壁を壊す活動(=文化)を表すコンセプトが、DevOpsなのです。

 


 

DevOpsが重要視される背景

 

DevOpsが注目され、重要視されるようになった一番の要因は、オンラインシステムが普及し、システム利用の重要性が高まったことです。

 

システムの重要性が高まり、市場規模が大きくなり、競合が増え、市場の変化が激しなり、生存競争が激しくなりました。

 

これが前述の、激しい市場競争の背景です。

 

DevOpsについては、写真共有サービス「Flickr」のエンジニアが2009年にO’Reily Velocity Conferenceで行った発表「10+ Deploys Per Day: Dev and Ops Cooperation at Flickr」が有名です。

 

このVelocity Conferenceを主催したO’Reilly Mediaは、DevOpsについて以下のようにまとめています。

 

Then, in 2008, O’Reilly Media ran the first Velocity conference. Velocity was founded on the same insight: that web developers and web operations teams were often in conflict, yet shared the same goals and the same language. It was an effort to gather the tribe into one room, to talk with each other and share insights. Much of the DevOps movement grew out of the early Velocity conferences, and shares the same goal: breaking down the invisible wall that separates developers from IT operations. The evolution of DevOps

 

– O’Reilly  https://www.oreilly.com/radar/the-evolution-of-devops/

 


 

DevOpsによって得られる価値観と実現方法

 

「DevOpsだけが現代において適切な価値観であり、取り込むべき文化である」とまでは言いませんが、DevOpsが現代のほとんどのシステム・組織・状況において的を射た・目指すべき姿であることが多いために、これほど注目が高まり、普及していると言えるでしょう。

 

ここからは、DevOps化することで、どのような価値観に触れることができるのかを見ていきましょう。

 

1 | 変化を肯定し歓迎する

 

DevOpsに触れると、さまざまな「今までにない」変化を促されます。

 

中には刺激的に感じられる事柄もあるかもしれませんが、負の要因を抱えたままでは生き残っていく難易度はこれからますます高くなります。

 

少しでも歩みを止めると真っ逆さま。ですから、まず変化を肯定し、歓迎しましょう。

 

とはいえ、人員を総とっかえでもしない限り、一足飛び目指す姿に至ることはできません。そのため、その変化は少しずつになります。

 

2 | 素早くたくさん検証し、素早くたくさん失敗する

 

価値観が多様で不確実な時代において、市場競争に勝つ・生き残るための正解は、とても不確かです。

 

状況の変化にタイムリーに適応していくためには、素早い変化が必要です。

 

システムには応答速度・機能の豊富さ・安定性・セキュリティなどさまざまな評価指標があり、どれかだけが重要ということはありません。しかしその中でもいまは、変化の素早さ(アジリティ)の価値が非常に高い時代になっています。

 

また状況の変化にタイムリーに適応していくためには、仮説検証も欠かせません。

 

仮説検証サイクルにおいては、成功も失敗も等しく重要な出力です。結果を計測し、失敗を肯定し、失敗からの学び、積み重ねましょう。

 

3 | 役割分担するが責任は押し付けない

 

システムとユーザー双方のために、Dev・Ops(だけでなくCS:Customer Support/Customer Success)やマーケなど)関係者一同が判断基準と優先度を同じくしてコトにあたる状態にすることで、ユーザーに対して適切な価値を、タイムリーに提供することが可能になります。

 

現代のシステムは複雑で難しいため、全てをひとりで賄うのは非現実的であり、何らかの役割分担は避けられません。

 

役割分担を行うと見えない壁が発生しがちですが、その見えない壁を壊そうというのが、DevOpsです。

 

このような抱合的な態度をInclusiveと呼びます(対義語は排他的:Exclusiveです)。

 

役割分担は期待役割をベースに行い、その期待役割を果たすことを責任として求めがちです。しかし、実際のところ期待役割を果たせるかどうかは、周囲の状況などに依存し、かなり水物です。

 

ユーザーから見れば中の誰が役割を果たそうが関係ないわけで、内部での責任範囲云々はユーザー価値には繋がりません。

 

そのため、やるべきことは他者に責任を求めることではなく、ユーザーにとってよい結果になるにはどうすればよいかを共に目指すことです。

 

4 | 銀の弾丸はない

 

DevOpsは実際のところ、とても苦しい変革と、とても泥臭い実践を続けることでのみ、成立します。

 

もちろん、CI(Continuous Integration)、CD(Continuous Delivery)といった鉄板のグッドプラクティスは存在します。

 

しかしそれらも、機材のように「買ってきて導入」できるものではありません。コンサルティングやトレーニングを受けたとしても、変化しなければならないのはとどのつまり、自分たち自身です。

 

現実に現場やシステムで実現するためには、それらを参考にしつつ、それぞれの現場やシステムにとって適切な歩幅・速さで歩んでいくしかありません。

 



まとめ

 

DevOpsとは、継続的に変化し市場競争力を獲得するための価値観・文化のこと。価値観・文化を体現するための定番プラクティスを指すこともある。

 

DevOpsの目的は、価値観・文化を踏まえて、関係者全員が同じ判断基準と優先順位を持つこと。

 

そのためには、価値観・文化の浸透とプラクティスの実践の両輪を、少しずつ回していきましょう。

 

 

>関連記事

  • DevOpsついてさらに知りたい方>DevOps実践編
  • DevOps実践の一つの形「SRE」について知りたい方>SRE入門編