よく聞くけどよくわからないDevOps。DevOpsとは一体何なのでしょうか。今回は、過去に2社、DevOpsを推進する会社でそれが失敗に終わる現場を経験し、今マネージャーを務める3社目で、ようやくDevOpsの定着に成功したといってもいいかもしれないところまできた筆者が、その経験の中で確信した「なぜ日本企業にDevOpsが浸透しないのか」「どうすれば浸透させることができるのか」を紹介します。
目次
DevOpsとは？ ～日本ならではの解釈が不可欠？！～
「DevOpsとは、開発チーム（developer）と運用チーム（operator）が協力して、システム開発のライフサイクルを短縮すること」とよく言われています。しかし、「そう言われても具体的にイメージできない」というのが日本の現場の感覚ではないでしょうか？
その理由は、会社によって運用チームの役割、開発チームの役割が違う、あるいは外部へ委託するITベンダーとの関係などにより、開発チームと運用チームが一緒になるイメージが難しいからです。
一方、DevOpsが日本より浸透している米国では、自社のIT部門でシステムを開発するのが一般的です。日本のようにITベンダーに丸投げしてシステム開発することが少ない、という違いがあります。
米国企業の場合、IT部門には開発チームと運用チームがあり、開発チームがコードを書き、運用チームがコードをサーバーへデプロイするという役割が明確に分かれています。運用チームが「コードの効率が悪い」だの「セキュリティの考え方がなっていない」だの指摘して開発チームにコードを投げ返すたびに発生する喧嘩も日常茶飯事です。
そのため、米国の現場では、前述のDevOpsの説明に書かれた「開発チームと運用チームが協力して」という部分がイメージしやすいのです。
以上の理由から、会社によって組織構成がさまざまな日本の場合、DevOpsを「開発」と「運用」という言葉で考える時点で、失敗しやすいと私は考えています。この記事では、ここで改めて、この2つの言葉に執着せずにDevOpsを定義します。
DevOpsとは、ビジネスのため（営利を目的）に、システム開発を短縮する仕組みを作ろうとする文化です。
システム開発において、以前はウォーターフォール開発が主流でしたが、この手法だと要件定義からリリースまでに数ヶ月かかるのが当たり前でした。変化の激しい現代、ビジネスを考え、それをシステムに反映させようと思ってから、実際に反映されるまでに数ヶ月もかかっていたら、いつまでたってもシステムは最適化されません。
その問題を解決するために、開発スピードを上げてシステムを構築する文化を作っていくのがDevOpsと理解する。これが日本でDevOpsを成功させるための第一歩です。
DevOpsが失敗に終わる2大原因
これまでの経験から、私が考えるDevOpsが失敗に終わる原因は次の2つです。
❶ DevOpsを推進する長の理解不足
DevOpsが浸透せず失敗に終わる一番の原因は、DevOpsを推進する長の理解不足です。ここで言う長とは、社長やCTO、CIO、部長など、会社によってさまざまでしょう。
長が理解できていないので当然、「DevOpsとは何なのか」「なぜ進めるべきなのか」これを現場が納得できるだけ十分に説明されることもありません。単に「開発と運用を一緒にしてしまえばいい」といった安直な考え方で組織変更してしまい、現場が追いついていけないという最悪のケースも私は経験しました。
❷ ITベンダーに丸投げする文化
DevOpsが失敗に終わる二つ目の原因は、ITベンダーに丸投げする日本特有ともいえる文化です。実は、ITベンダーは顧客にDevOpsを求められると困ります。
日本のITベンダーは大規模案件を中心に単価の高いエンジニアが開発を行い、運用フェーズでは単価の安いエンジニアが運用することを基本としています。大規模案件の開発が終わった後は、他の大規模案件に単価の高いエンジニアをアサインさせ収益を上げていくビジネスをしているため、単価の高いエンジニアが開発も運用も行い「開発期間を短くしていく」というDevOpsの考え方にITベンダーの戦略はマッチしないのです。
つまり、顧客がDevOpsを進めてもITベンダーにとっては売上を見込むことができないわけです。そこでITベンダーが取るのが、「DevOpsツール」という高額ツールを売って、短期的に大きな売上を得た上に、保守費用を数年もらう、という戦略です。
そもそもDevOpsを浸透するためのDevOpsツールなんてものは存在しないのですが、DevOpsのことも現場のことも正しく理解できていない長は、ITベンダーの優秀な営業担当者の話す「DevOpsを進めるならこのツール」という話を鵜呑みにしてDevOpsツールなるものを購入してしまうのです。
DevOpsによくある失敗事例
ここで、実際に私が経験した失敗事例を紹介します。前述の、無知な部長が高額なDevOpsツールなるものを購入した現場の末路、よくある悲劇です。
この現場には、開発チーム、運用チームの他にDevOpsチームというものがありました。当然このチームのミッションは、DevOps文化を組織に浸透させることです。
ところが、実態は異なるものになっていたのです。そのいつの間にか歪んでしまったミッションというのが、部長の顔を立てること。部長が導入すると決めた高機能ツールを使いこなすことになってしまっていたのです。しかし、開発チームや運用チームもその高機能ツールを必要としておらず、全く浸透していきません。
手段が目的化した典型的な悪い例です。
もし部長がこの事実を知れば「こんなに高額なツールなのに、使いこなせていないなど、許されない！」と思われるでしょう。しかし、開発チームや運用チームにとっては高額ツールを使いこなすことよりも日々の業務のほうが大切なのです。
現場が望んでもいないDevOpsツールなるものを購入して、部長だけがDevOpsを進めていると錯覚している、まさに本末転倒な事例と言えます。
このように書くと笑い話に聞こえますが、DevOpsが一体何なのか理解していない長とITベンダーに丸投げする文化が原因で、DevOpsが失敗に終わっている現場は少なくないと思います。
念のため補足しますが、これは「DevOpsチームは不要」という話ではありません。「目的を正しく理解できていないために、正しい手段が取れていないことが問題」という話です。
DevOpsを実現する方法
では、DevOpsを実現するためにはどうすればよいのでしょうか。
前述のDevOpsの定義を十分理解した上で、2大原因を取り除く必要があるわけですが、どんな組織にも共通する最重要ポイントを一言でまとめると以下です。
最重要ポイント 「現場と密に連携しながら、小さい範囲から内製化していく」
私のオススメは、新規で構築する小規模のシステムを内製化して取り組むことです。2人か3人のチームで、開発・テスト・運用・監視のサイクルを回し、改善できるものから取り組んでいけば徐々にシステム開発を短縮することができます。
究極的には、インフラ構築からアプリ開発、それらの運用まで、なんでもできるフルスタックエンジニアが大勢いて完全内製化をして行くことが理想ですが、現実的には厳しいと思います。なので、まずは小さいシステムで少しずつ改善しながらPDCAを回していきます。
例えば、「システム開発を短縮するためには、バージョン管理を効率化すべきだ」という課題があれば、ベンダーに相談するのではなく、自分たちでバージョン管理ツール「Git」を小さいシステムで検証し、他のシステム開発でも横展開することを考えます。そこでうまく浸透したら、そこから更にソースコードのビルドやテストを自動で実行するCI/CDツールや、単体テスト・結合テスト・アプリケーションテストなどを自動化するテスト自動化ツールなどを導入し、改善したら横展開していくのです。こうすることで、その現場経験からメンバーがフルスタックエンジニアに育つことも期待できるでしょう。
ここで重要なのが「現場が必要だと考えたことをする」ということです。ツールを導入する際も現場と一緒に考えることが重要です。DevOpsは文化なので、現場の認識がもっとも重要です。
DevOpsを支援するツール群とその選び方
さて、DevOpsは、開発期間を短縮することが目的となるため、その推進にはツールの活用が不可欠となります。次は、ツールとその選び方についてです。
繰り返しますが、DevOps文化を簡単に浸透させることができる魔法のオールインワンツールは存在しません。「DevOpsを支援」という売り文句のツールも、開発、テスト、運用、いずれかのフェーズによくある一部の課題を解決するためのものです。
- CI/CDツール：ソースコードのビルドやテストを自動で実行する
- テスト自動化ツール：単体テスト、結合テスト、アプリケーションテストを自動化する
- 構成管理ツール：インフラの構成を管理し構築・テスト・運用を自動化する
- バージョン管理ツール：ソースコードのバージョン管理を行う
- 監視ツール：サーバーの障害監視やアプリケーション性能監視を行う
そして、ツール選びのポイントもやはり、現場主導で、自社の課題に合ったツールの導入を検討すること、です。
DevOpsで肝となる運用フェーズの「監視」
さて、最後は、私がこれまでの経験から強く感じてきた、DevOpsを推進する際に見落としがちなポイントについて、話したいと思います。
「システム開発を短縮する仕組みを作る」という観点で考えると、開発フェーズに注目する方が多いと思います。開発フェーズでCI/CDツールを導入すると開発にかかる時間が驚くほど短縮されることに気がつくでしょう。
しかし、実は「軽視すると後で痛い目を見るのが運用フェーズの監視」です。これには２つ理由があります。
① 障害が発生したら開発どころではなくなる
いくら開発フェーズでデプロイを早くしたところで、低品質のシステムで障害が頻発していては開発どころでなくなります。監視をおろそかにしては、安定稼働が見込めません。監視の仕組みはしっかり考え、障害時にはすぐに対応できることが重要です。
そしてこの時よくあるのが、アプリ担当とインフラ担当の対立です。障害の原因が可視化されない限り、罪の擦り付け合いは終わりません。これでは、開発期間を短縮することはできません。
② 営利を考えるには運用が重要
最初に定義した通り、DevOpsは「ビジネスのために、システム開発を短縮する仕組みを作る文化」です。つまり、DevOpsのゴールは、営利です。運用していく中で、課題を見つけ、どうしたらビジネスにつながるのかを考え、次の開発内容を考えるのが運用フェーズです。そのためには、このシステムのユーザー（お客様）が、どういう体験をしているのか把握するのが重要になってきます。
例えば、ECサイトで商品を買い物かごに入れる度に応答時間が遅くなっているとしたら、ユーザーはストレスを感じ、競合他社のECサイトに行ってしまいます。
肝となる「監視」を簡単に自動化できるSaaS型ツール「Site24x7」
運用フェーズの監視が重要とはいうものの、少人数のチームで進める必要があるのがDevOpsです。そうなると「監視の設定に時間をかけたくない」というのが多くのエンジニアの思いでしょう。そこで、今回は、簡単に導入できるSite24x7（サイトトゥエンティーフォーセブン）を紹介します。
私がSite24x7をおすすめする理由は次の3つです。
- 導入が簡単
- 障害発生時の原因切り分けを短時間で実現
- ビジネス判断を加速
順に説明します。
1. 導入が簡単
まず、Site24x7は導入に時間がかかりません。完全クラウドサービスになっていて、エージェントを導入するだけで自動的に監視が始まります。もちろん、監視用のサーバーを用意する必要もありません。異常時の通知設定も、画面上で誰でも簡単にできます。
無料かつ5分で始める手順（サーバー監視編）：
https://www.site24x7.jp/simple-server-monitoring.html
2. 障害発生時の原因切り分けを短時間で実現
Site24x7には、ネットワークやサーバーの監視機能だけでなく、アプリケーションパフォーマンス監視（APM）機能もあるため、障害発生時には基本的なサーバー障害やネットワーク障害だけでなく、アプリケーションの内部の障害まで、色やグラフから簡単に特定することが出来ます。
APMの設定一覧の表示した状態
各設定の時系列で応答時間の推移を確認することが可能
3. ビジネスの成長を加速
前述した通り、ECサイトで買い物かごに商品を入れる度に応答時間の遅延が発生していれば、それは顧客離れが発生し、売上を取りこぼしていることを意味します。
Site24x7を導入すると、その遅延をリアルユーザー監視（RUM）機能でリアルタイムに把握するだけでなく、APM機能でアプリケーションのプログラムコンポーネント単位で遅延の原因を特定することまでできるため、ビジネスのボトルネックとなっている問題から順に改善していくことが可能となります。
RUMの設定一覧を表示した状態
各地域で体感した応答時間のサマリを表示した画面
ユーザーの体感した応答時間を時系列で確認することが可能
指定期間にしきい値を越えたすべてのWebサイトとURLを収集するスナップショット機能でユーザー個別のレスポンスを確認することが可能
まとめ
DevOpsの始め方とツールの選び方、いかがだったでしょうか？
まずは小さな範囲で内製化し、小さなチームで実行するために必要なツールをフェーズごとに選択していきましょう。
監視ツール「Site24x7」はメールアドレスだけで無料で始めることができます。手軽に簡単に導入できるため、まずは導入し運用フェーズの要である監視の土台を固め、開発フェーズやテストフェーズの他の改善に時間をかけることをオススメします。実は、価格も驚くほど低価格、スモールスタートしやすいプラン構成も◎です。
プランと価格の詳細：
https://www.site24x7.jp/pricing.html
すべての機能を使えるFREEプランにサインアップ：
https://www.site24x7.jp/signup.html?pack=1&l=ja
免責事項：ここに記載されているすべての著作権、商標、商号は、元の所有者の所有物です。このWebページに含まれる情報は、一般的な情報提供のみを目的としており、そのような情報は、正確性、信頼性、または完全性について調査、監視、または確認されていません。 当社は、ここに含まれる情報への依存に起因する誤り、または損失に対する責任を明示的に否認します。
