DevOps(デブオプス)って何だ？Dev(開発)とOps(運用)以外の人たちは何をする？

DevOpsは、「開発」と「運用」に限った話ではない。ビジネス部門やテスト、QA(品質保証)、サポート、インフラなど多くの組織や人びとが関わりあってビジネスが成り立っている。ビジネスに関わるすべての組織、すべての人たちが一丸となることが、DevOps実現の第1歩である。

▼あわせて読みたい▼
＞＞DevOpsとは？アジャイル開発との違い、導入するメリット・デメリットについて解説のページへ

【注】DevSecOps、DevQAOps、BizOps、AIOpsなど多くの言葉が派生しさまざまな文脈で使用されているが、その本質は上記の通りビジネスを成功に導くことである。本稿では、それらをまとめて「DevOps」と呼ぶこととする。

DevOpsという言葉は、2009年に開催された「Velocity 2009」カンファレンスにおいて「10+ Deploys Per Day: Dev and Ops Cooperation at Flickr(開発と運用とが協力することで、1日に10回以上のリリースが可能になる)」というプレゼンテーションのなかではじめて使われた。

もともと、開発と運用は同じプロダクトやサービスを扱っていながら独立した組織体であり、各メンバーの活動は「組織の目的や目標を達成するため」のものである。目標が違うということは、チームを評価する指標も次のように異なることがわかるだろう。

プロジェクトの成功＝QCDの達成であり、標準開発プロセスやガイドラインを定め、それらを遵守することが正しいとされてきた。それ自体を否定するつもりはないが、多くのドキュメントを作成し、その妥当性を証明するためにレビューを行い、工程を通過するには承認行為(Exitクライテリアやリリース判定など)が必要であり、多くの時間を要するものである。また、環境構築やリリースなど組織間のスケジュールや要員調整のためにもさらなる時間が必要だ。
それはすなわち、ユーザーへの迅速な価値提供ができない、という問題をはらんでいることになる。

下の図は、某社のシステム維持保守プロジェクトにおいて、5機能程度の改修を行ってリリースするまでに要した時間を表したものである。

リリースまでに要するトータル時間(リードタイム)が376時間(約2週間)であるのに対し、実際に価値を生み出す作業に要した時間はわずか39時間(業務時間1日8時間で5日)であった。この差分、つまり全体の約90％が待ち時間なのである。

このように、プロセスを可視化する(バリューストリームマッピングという)ことで各プロセスやプロセス間の受け渡しにかかる時間が明らかになり、リードタイムを短縮するための改善ポイントが見えてくる。レビュー待ち・承認待ちという待ち時間を減らすこと、手戻り(＝ムダな時間)を減らすこと、ツールや自動化によって効率化すること(同時に人的ミスも削減＝品質向上)などがあるだろう。

世の中の変化が激しく不確実性が高まるなかで、特にITやビジネスの世界においてアジャイルやリーン思考が広がっている。それとともに、組織の個々の目標を達成するのではなく、ビジネスを成功させる(ユーザーにとってよりよいプロダクトやサービスを早く確実に提供する)という共通の目標を達成するために、何をすべきかという視点へと変化していった。

歴史ある老舗企業、有名大手企業も新興企業の登場によって撤退、倒産した例も少なくない。それがリーン、アジャイル、そしてDevOpsの思想へとつながっていったのである。

以下に、DevOpsの概念を示す。自動化というと、CI(継続的インテグレーション)やCD(継続的デリバリー、継続的デプロイメント)を思い浮かべる方もいらっしゃるかもしれない。CI/CDとDevOpsを同列に扱うのも気が引けるが、開発プロセスにおいてそれぞれがカバーする範囲も併記した。

この図を見ると、多くの自動化されたツールチェーンでつながっていて、自動化＝DevOpsと捉える方もいらっしゃるかもしれない。 自動化はDevOpsを実現する手段であることを改めて申しあげる。

私たちは、「DevOpsとは何か」と聞かれると以下のように答えている。

ここでいいたいことは、DevOpsの目的はビジネスの成功を支援することであり、そのためには個々の組織やプロセスを最適化するのではなくパイプライン全体を最適化するということである。

参考までに、実際にDevOpsを実践しようとしたものの、うまくいかなかった例をいくつかあげてみたい。

経営層やマネジメント層の誤った認識によるもの

DevOpsはスタートアップ企業やネット企業のためのものであり、当社には関係ない。

頻繁にリリースするプロダウトは当社にはない。だからDevOpsは不要だ。

業界の慣習で監査や規制が非常に厳しい。だからDevOps導入は無理である。

当社には開発と運用の間に壁はない。DevOpsを実践している。

開発と運用はすべてベンダーに任せているからDevOpsは導入できない。

現場層の誤った認識によるもの

ツールを導入することが目的になっており、一つのプロセス(例えばテスト)の時間短縮のみに目が向いている。

他のチームと協力せず、結局調整に時間がかかる。

改善目標を定義しない。ツールを導入してそのまま使用している。

これらは共通して、企業として ビジネスを成功させるという本来の目的・目標を忘れてしまっていることが原因と考えられる。

経営層やマネジメント層のなかには、従来のやり方にこだわっていたり、現状に満足してしまっている、 あるいは変化の必要性を感じていても多大な労力とコストが必要であることを知っているので踏み出せないという方もいる。
開発現場においては、全体最適ではなく個別最適に走ってしまったり、利用者目線ではなく開発者目線で物ごとを捉えてしまっていることも少なくない。

DevOpsの導入については、他の記事にゆだねることとする。
The DevOps Handbook(2015年 Gene Kim, Jez Humble, John Willis, Patrick Debois著　邦題：The DevOpsハンドブック 理論・原則・実践のすべて)は体系的にまとまっており、まさにハンドブックと呼ぶにふさわしい1冊である。ぜひ、一読していただきたい。

アジャイル開発というと、スクラムを思い浮かべる方が多いのではないだろうか。
スクラムは、アジャイルという思想を実践するフレームワーク・プラクティス群の一つであり、最も多く採用されているフレームワークである。
スクラムガイド(2020年版 https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf )では、スクラムチームを以下のように定義している。

スクラムチームは、スクラムマスター1 ⼈、プロダクトオーナー1 ⼈、複数⼈の開発者で構成される。
スクラムチームは機能横断型で、各スプリントで価値を⽣み出すために必要なすべてのスキルを備えている。
スクラムチームは、ステークホルダーとのコラボレーション、検証、保守、運⽤、実験、研究開発など、プロダクトに関して必要となり得るすべての活動に責任を持つ。
スクラムチームは、⾃分たちで作業を管理できるように組織によって構成され、その権限が与えられている。

出典: スクラムガイド2020年版

機能横断型で何でもできるスクラムチームを編成するため、ビジネスに関わる人たちを一つのスクラムチームの一員としてアサインすればよいのだろうか。

スクラムガイドでは、スクラムチームは1チーム10名程度と定義している。このスクラムチームにさまざまな組織のメンバーをアサインすると、実際に開発(設計、コーディング、テスト)できる人が少なくなってしまうかもしれない。結果、スループットが落ちるという結果にもなりかねないのである。
何でもできるオールラウンダーが望ましいのだろうが、オールラウンダーは非常にレアな存在で調達も育成もむずかしい。もちろん、すべてのことができるチームを構成できるなら、それは素晴らしいことだ。

なぜなら、スクラムは開発(インクリメントをつくる)のフレームワークであり、その後の受入テストや総合テスト、リリース、運用までをカバーしたものではない。逆に、DevOpsはそれらすべてを対象としているのである。
つまり、スクラムチーム単体で見るのではなく、ビジネスを行う一つのDevOpsチームと捉え、そのなかに開発チームや運用チーム、QAチームなどがある、と考えるのが現実的ではないだろうか。

元来、それぞれの組織はサイロ化しており、組織間のコミュニケーションには時間と手間がかかる。物理的なロケーションの違いがタイムラグを大きくいていることさえある。
DevOpsは、この組織間の距離(構造的にも物理的にも)を縮め、開発や運用をはじめとするあらゆる組織が一丸となるように企業や組織の文化・マインド、そしてプロセスをシフトしていかなければならないのである。

では、具体的にどのように各組織・役割をもつチームのマインドを変え、プロセスを変えていけばよいのだろうか。

開発における品質保証と、運用を含めた品質保証という観点では、後者の方が圧倒的に視野が広くなる。

開発における品質保証は、プロダクトの要求を満たしているかどうかを測る「プロダクト品質」とプロダクト品質を確保するための「プロセス品質」に重点を置く。ユーザーが利用する段階となった瞬間から、ユーザーの要求や満足度を満たしているかを測る「サービス品質」にも目を光らせなければならない。
このサービスの品質が悪いと、全く利用されなくなってしまう。みなさんも、スマートフォンのアプリをダウンロードしても期待通りのモノでなかったら使わなかったり削除したりしていないだろうか。

サービス品質の評価についてはさまざまなモデルが提唱されているが、以下のような観点で計測、評価・分析、フィードバック、改善を繰り返すことが重要である。

提供者観点でのサービス品質

開発品質(プロセス) - サービス開発・運用プロセスを正しく実行しているか

開発品質(結果) - サービスを提供するための準備が予め決められた基準値以上であること(ヒト・プロセス・モノ・データ・サプライヤー／パートナーの視点)

提供品質 - サービス提供者のバックオフィスも含めた提供のプロセスと提供した結果の品質を総合して評価する

利用者観点でのサービス品質

期待品質 - ユーザーの期待品質を正確に把握し、計測・評価

知覚品質 - ユーザーがサービスを利用した際に実際に知覚した品質、顧客や利用者の主観(ヒアリング、アンケート調査で把握)

利用者視点で評価することは、ユーザーのニーズや顧客満足度を知るうえで欠かせないファクトである。提供者視点のみに着目していたら、結局は提供側の自己満足で終わり、それが顧客満足の低下につながることは明らかだ。

例えば、サポートへの問い合わせやクレーム、「いいね」の数やレビューコメントなどは、直接のユーザーの声である。会員数の増減、リピート率、無料会員から有料会員への移行数などは、このサービスが魅力的か(ユーザーにとって価値があるか)どうかを示す。Webサイトからの離脱(どこからどのページに移動してどこで離れたか)、入力ミスや操作ミスなどは、UI/UXデザインにまでさかのぼる気づきを与えてくれる。

何を指標として測定し、評価・分析するかは提供するプロダクトやサービスによって異なる。しかし、サービス品質を評価するメトリクスと目標値を定め、それらを収集する手段を構築し、可能な限りツール化・自動化して状況の可視化と評価・分析、フィードバック、改善のサイクルを早めるのがDevOpsにおけるQAの役割である。

品質保証はQAチーム単独で行うのではなく、仕組みづくりならインフラチーム、問い合わせやクレームならCSチーム、会員なら営業やマーケティングチーム、デザインならUI/UXチームとの協力・コミュニケーションが必要なことはいうまでもない。

サポートチームは、ユーザーからの問い合わせやクレームへの対応や、開発チームや運用チームに改善や対策を依頼するのが一般的である。さらに、そうしたユーザーからの問い合わせやクレーム内容を記録、蓄積しナレッジ化すること、そしてそれらをビジネスや開発側にフィードバックすることも彼らの役割だ。

このフィードバックのスピードが圧倒的に変化するのがDevOpsならではである。
開発チームやユーザーとやりとりを行い、リアルタイムにユーザーの声をDevに届けるためには、サポートチームにはプロダクトのナレッジも必要となるだろう。ユーザーからの情報を一元的に管理し、プロダクトバックログを積むための一つの受け皿となるのである。
窓口の対応そのものだけではなく、ユーザーの声をいち早くフィードバックし、実現に向かわせることも顧客満足につながるのではないだろうか。カスタマーサポートは、そのための重要な役割を担うことになる。

ここでいうインフラチームは、アプリ基盤やネットワーク、いわゆる「プラットフォーム」を構築するチームを指す。
従来、開発環境やテスト環境の構築は、開発(アプリ)チームのオーダーをトリガーにインフラ設計・構築・テストをして開発チームに引き渡すことが多かった。しかし、開発チーム自身がテスト・検証などの際に必要に応じてインフラを構築(複製)し、不要となったら廃棄できるようにしておくことで、待ち時間を短縮することができる。
また、本番環境においても、アクセス負荷増減による自動拡張・縮退、障害発生時の自動切り換えなどにも備えておくことで、不意のサービス停止を免れる。
インフラ構築をコードで実現する IaC：Infrastructure as Code や、構築だけではなく運用管理まで行うさまざまなオーケストレーションツールも広がりを見せており、これらを自動化ツールチェーンに組み込む(人手による作業を廃止する)ことで時間短縮と品質向上を実現することが可能だ 。

DevOpsは、ビジネスを成功させるために存在する。
従来の機能型(職能型)組織のサイロを取り壊し、ビジネスに関係するあらゆる組織の人たちが一丸となる企業文化・組織文化そのものである。ユーザーに早く、そして確実に価値を届けためには、アジャイルとリーンの原理原則が根底にあることも忘れないでいてほしい。
【注】機能型組織のサイロを取り壊すとは、物理的に組織構造を変えるのではなく機能横断な仮想的な組織(DevOpsチーム)を編成するということである。ユーザーに価値が届くまでの時間(リードタイム)を短くするには、個々の作業の時間(プロセスタイム)の短縮はもとより、ハンドオフ(手渡し)と手戻りの排除、すなわち自動化が必然となる。情報共有やコミュニケーションの仕方も、組織サイロを越えてスピーディに行わなければならない。
【注】リードタイムやプロセスタイムについては、ぜひ「バリューストリームマッピング」というプラクティスを参考にしてほしい。

ビジネスの価値を高めるには、迅速なフィードバックが欠かせない。迅速なフィードバックがイノベーションを引き起こし、ビジネスの競争優位性を維持する。
フィードバックとは、ユーザーの声・ステークホルダーの声だけではない。ユーザーの行動(Webサイトの閲覧・離脱、入力ミスなど)やアプリケーションの稼働状況(個々のトランザクションの処理時間や待ち時間、エラー率)などリアルタイムに監視・計測・評価する仕組みは、プロダクトやプロセス、サービスの改善に欠かせない情報源となるであろう。

ビジネスを推進するうえで、DevとOps以外のメンバー(QA、サポート、インフラなど)もDevOpsの一員である。個々のケーパビリティを存分に発揮して、チーム一丸となってビジネス成功のために自らの責任を果たしていかなければならない。

●テスト、QA(品質保証)： プロダクト品質、プロセス品質、そしてサービス品質にも目を向ける。ユーザー視点でサービス品質を測定、評価・分析、フィードバックしてプロダクトやサービスの品質向上をリードする。
●CS(カスタマーサポート)： 単なる窓口業務にとどまらず、ユーザーと開発・運用の架け橋として、ユーザーからの情報をいち早くフィードバックする。
●インフラ： 効率よく迅速に、そして確実に価値を提供し続けることができるプラットフォームを構築し、それを維持しつづける。

最後に、本稿はITに特化した内容となっているが、さまざまな分野でこの考え方を取り入れることでビジネスの俊敏性(ビジネスアジリティという)を得ることができることをつけ加えておきたい。