F5 DevOpsおよびNetOps調査レポート：デジタル格差の解消には自動化が不可欠

DevOpsとNetOpsの典型的な関係は、しばしば大きく取り上げられます。両者を隔てる壁越しに、アプリケーションと非難を互いに投げ合い、対立をあおる「こちら対あちら」という言説が絶え間なく繰り返されています。アプリケーションをより迅速かつ頻繁に提供することへのプレッシャーが高まる中、この壁は、アプリケーションエコノミーの勝者とそれ以外を分けるデジタルデバイドになりかねません。

幸い、ITの自動化とオーケストレーションにより、このデジタル格差は縮まりつつあります。NetOpsとDevOpsの各グループを個別に調査し、テクノロジーの活用状況、互いに対する認識、提供するアプリケーションについて掘り下げたところ、双方にこの隔たりを協力して解消したいという意向があることが分かりました。これは、自動化とオーケストレーションによってのみ効果的に実現できる規模とスピードを必要とするデジタルトランスフォーメーションに取り組む企業にとって、ますます明るい材料となっています。また、すでに業務負荷の高いスタッフにさらなる対応を求めるマルチクラウド環境に苦慮している組織にとっても朗報です。自動化によってオンプレミスの業務負荷を軽減すれば、クラウド関連プロジェクトに対応するためのリソースを確保できます。

2017年夏に実施したオンライン調査には、NetOpsとDevOpsの専門家884人が回答しました。アプリケーション全般と、NetOpsまたはDevOpsの相手方に対する認識について複数の質問を行ったほか、デプロイの頻度と成功率をどのように捉えているかについても質問しました。

調査結果から、両者を隔てる壁は依然として存在するものの、各コミュニティ内での議論や他の業界レポートが示唆するほど高くも不透明でもないことが明らかになりました。あらゆる規模や業種の組織において、本番環境へのデリバリーパイプラインを自動化することの重要性とその実現への意欲、さらに両者が開発とデプロイに取り組むアプリケーションのセキュリティ、パフォーマンス、信頼性に対する共通の確信という点で、多くの共通認識が見られました。

自動化は、NetOpsとDevOpsを結び付ける力となっているようです。少なくとも原則上はそう言えますが、具体的な実装の詳細については必ずしもそうではありません。

DevOpsとNetOpsの間では、セルフサービスと自動化を通じてパイプラインへのアクセスをどの程度提供すべきかについて、依然として意見が分かれています。しかし、両者ともおおむね、相手の方向性は正しいと考えています。DevOpsの82%とNetOpsの76%が、相手は「適切な事項」を優先していると回答しています。組織図上では必ずしも一致していなくても、少なくとも目標と重点領域については、デジタルの隔たりを越えた共通点があることは明らかです。

NetOps側で異論を唱えた回答者に、DevOpsが十分に優先していないものを尋ねたところ、最も多かった回答の1つがセキュリティでした。また、信頼性も、NetOps側がDevOpsに不満を感じる要因として頻繁に挙げられました。

当然ながら、NetOpsの優先順位付けに関してDevOpsからよく聞かれた不満の1つは、自動化、より正確には自動化の不足に集中していました。

この見解の相違は、次の重要な調査結果の根底にあると考えられます。その結果から、開発者とDevOpsが自動化やセルフサービスを通じて本番パイプラインにアクセスできないことが、クラウドやIT部門外のソリューションの導入に及ぼす影響が明らかになりました。

自動化がクラウド導入に与える影響

今や、その声は届いています。 ビジネス部門とDevOpsの関係者がクラウドを導入する要因の1つとして、実稼働環境へのデプロイパイプラインにセルフサービスでアクセスできず、デプロイサイクルが長期化していることが以前から指摘されてきました。あまり好ましくない点は、今回の調査でこの見方が裏付けられたことです。DevOpsの27%が、クラウドベースのソリューションを選択する判断に「大きく」影響すると回答し、38%が「ある程度」影響すると回答しています。一方、NetOpsもその影響を認識しているという好ましい結果も得られました。NetOpsの65%以上が、自動化を進め、実稼働環境へのデプロイパイプラインにセルフサービスでアクセスできるようにしたいという意向は、DevOpsによるクラウド導入の判断から「ある程度」または「大きく」影響を受けていると回答しています。

主な調査結果

自動化への強い支持。 デリバリーおよびデプロイのパイプラインを自動化する重要性について、強い合意が見られました。重要度の平均評価は5段階で、DevOpsが4.0、NetOpsが3.5でした。また全体として、本番パイプラインの自動化率が50%を超える場合、アプリケーションの信頼性、パフォーマンス、セキュリティに対する確信が高まると回答しています。さらに両グループとも、相手が「適切な事項を優先している」という点に圧倒的多数が同意しました。
自動化はクラウド導入に影響し、クラウド導入も自動化に影響する この点では意見が一致しているものの、両グループの見解には明確な相違があり、それが影響を及ぼしています。その1つが本番環境のパイプラインへのアクセスに対する見解の相違であり、F5はこれがマルチクラウドの拡大につながっていると考えています。DevOps側では、回答者の65%が、本番環境のパイプラインにアクセスできないことが、クラウドや外部ソリューションを求める判断に影響したと回答しています。一方、NetOpsの半数近く（44%）は、DevOpsがクラウドへの移行を決定したことが、そのパイプラインへのアクセスを提供しようとする意向に「ある程度」影響すると回答し、さらに21%が「大きく」影響すると認めています。
パイプラインアクセスをめぐる見解の相違社内業務の効率化と社外とのエンゲージメント向上を目的としたアプリケーション提供に重点を置くデジタルトランスフォーメーションでは、開発環境と本番環境の隔たりを乗り越える必要があります。しかし、両者を隔てる壁は依然として存在し、開発者やDevOpsに本番パイプラインへのアクセスをどの程度認めるべきかについては、意見が分かれています。DevOps回答者で最も多かったのは、本番パイプラインの75%超をセルフサービスと自動化によって利用可能にすべきだという意見でした。NetOpsはそれほど積極的ではありませんが、一般に考えられているほど両者の見解に大きな隔たりはありません。
現在のデプロイ頻度で問題なし DevOpsとNetOpsの双方が、現在のデプロイ頻度で「十分」との見解でほぼ一致しました。両グループ間には認識の隔たりがあるという一般的な見方を裏付けるように、デプロイ頻度が「高すぎる」と考える割合は、NetOpsがDevOpsの2倍に上ります。DevOps側でリリース頻度が「高すぎる」場合もあると回答したのは、わずか4%でした。

自動化への強い支持

責任のなすり合いは終わりました。 インシデント発生後、NetOpsとDevOpsが延々と責任を押し付け合うという一般的な筋書きとは異なり、実際には双方が互いをはるかに肯定的に捉えていることを示す結果が得られました。

パイプラインにアクセスできないことに不満を抱く人々がクラウドを利用する動きは、マルチクラウドの拡大と、それに伴うセキュリティおよびパフォーマンス上の課題を大きく助長しています。これは、その結果生じる「野良IT」への対応に苦慮する人々からも、たびたび指摘されています。NetOpsは、プライベートクラウドやクラウドに類似したシステムを通じて、自動化やセルフサービスによるアクセスを提供する取り組みを続けていますが、オフプレミスのクラウドソリューションにはすでに多額の投資が行われており、これを無視することは難しい状況です。そのため、組織は複数のクラウドソリューションと環境を管理、監視、保護する必要があり、デジタル経済における運用の複雑さが増しています。

今問われているのは、「本番環境のパイプラインへのセルフサービスアクセスを提供するか」ではなく、「どこまで公開するか」です。

パイプラインアクセスをめぐる認識のずれ

どの程度で十分なのでしょうか？ 自動化／セルフサービス機能を通じて、開発者やDevOpsにパイプラインへのアクセスをどの程度許可するのが適切かについて、意見に顕著な相違が見られました。DevOpsは、NetOpsが許容できる範囲を超えて、本番パイプラインへのアクセス拡大を明確に求めています。

NetOpsがDevOpsにパイプラインへのより広範なアクセスを提供することに消極的な理由については尋ねませんでしたが、その答えは、アクセスを提供するために必要なスキルの有無にあるのかもしれません。NetOpsの回答者は概して、業務に必要なスキルと、現在受けているトレーニングや保有する知識との間にギャップがあると考えています。

実際、「開発者」を自認するNetOpsとDevOpsは、同様の職責とスキルセットを前提とした場合、5年後も自分の仕事が重要であり続けると考える傾向が強く見られました。最も自信がなかったのは、両者の側で「ネットワークオペレーター」を自認する人々でした。

NetOps側の本番環境パイプライン自動化の現状には、こうしたスキルギャップの影響が表れているようです。DevOpsのデリバリーパイプラインと比べて大幅に遅れていることも、意外ではありません。本番環境パイプラインをまったく自動化していないと回答したNetOps担当者は11%だったのに対し、アプリケーションデリバリーパイプラインについて同様に回答したDevOps担当者はわずか5%でした。

パイプラインの自動化とデプロイの成功頻度には正の相関があることが調査で判明しており、パイプライン自動化の現状は注目に値します。パイプライン自動化率が高い（75%以上）と回答したNetOps担当者の86%は、非常に高い成功率（90%以上）でデプロイできる頻度も高いと回答しています。

しかし、要因はそれだけではありません。アプリケーションの変更頻度も、デプロイの成功頻度に影響を及ぼしていると考えられます。

現在のデプロイ頻度で問題なし

現状で問題ありません。おそらく、文化的な隔たりが最も大きいのは、依然としてデプロイ頻度の領域です。DevOpsの一部では、アプリを驚異的な速さで本番環境にデプロイしています（12%が1日に複数回、変更を本番環境に反映）。一方、NetOpsは、より遅くても着実なペースで変更をデプロイする方が適していると考えているようです。

全体として、回答者の相対多数が、月1回または週1回の頻度についてある程度共通の認識を持っているようです。予想どおり、DevOpsはNetOpsよりも高い頻度でのデリバリーを望んでいます。具体的には、デリバリーの頻度を高めたいと考えているDevOpsの26%のうち、28%は週1回、26%はすでに1日複数回デリバリーしています。

変更のデリバリー速度が十分かどうかについての認識は、グループによって異なります。しかし、DevOpsの70%、NetOpsの74%と、いずれも過半数が変更頻度について「自分たちにとって十分」と回答している点は注目に値します。

両者の共通点はここまでです。現在のスケジュールでは変更の頻度が「高すぎる」と回答したDevOpsはわずか4%でしたが、NetOpsではその割合が倍に上りました。一方、変更のペースを速めたいと考えている割合は、DevOpsでは4人に1人を超える26%だったのに対し、NetOpsでは5人に1人未満の18%でした。

しかし、希望ではなく結果に目を向けると、スピードと成功率のバランスを取るうえで「理想的」と考えられるデプロイ頻度が見えてきます。デプロイの成功率が90%を超えるNetOpsの65%とDevOpsの57%では、変更を「週に1回」本番環境に反映しています。

結論

アプリケーションが提供済みの状態からデプロイ済みの状態へ移行する際に越えなければならないデジタル上の隔たりは、依然として存在します。デプロイパイプラインの大部分は今なお手作業で運用されており、今後もアプリケーションのクラウド移行を促す要因となります。それに伴い、DevOpsがクラウドへの移行を選択することで、NetOpsはその移行を加速するために必要なセルフサービスアクセスをさらに提供するようになります。

自動化は、このデジタル格差を埋める鍵です。NetOpsとDevOpsが力を合わせ、より効率的に業務を進め、ビジネスニーズに応じて運用を拡張できるようになります。

調査方法

本レポートのデータは、2017年7月に実施した2つの個別のオンライン調査から集計しました。いずれの調査も、開発からデプロイまでのアプリケーションライフサイクルにおける自動化の活用状況と、関係する主要な2つのグループの認識を調べることを目的としています。両グループの回答者には、調査参加への謝礼を提供しました。

補遺：アンケート抜粋

以下に、NetOpsとDevOpsの回答者から寄せられたアンケート回答の一部を追加で掲載します。すべての回答を網羅したものではありませんが、寄せられたフィードバックの例としてご紹介します。製品名は正確性を期すために修正していますが、それ以外のコメントは、受領時の内容を編集せずに掲載しています。

NetOps

「開発チームは適切に優先順位を付けていますか？」に「いいえ」と回答した場合、どの項目の優先順位を変えてほしいですか？

- 安定性、品質、そして先を見据えた視点です。期限に間に合わせようと急ぐあまり、品質が最も大きな犠牲になることがあまりにも多くあります。また、目の前のタスクだけにとらわれると、大量の手戻りが発生し、最終的には最適とは言えないソリューションになってしまいます（粗雑に継ぎ合わせたものでも動作はするかもしれませんが、決して最適でも理想的でもありません）。

- 開発チームとシステム管理チームの連携をさらに強化する必要があります。手作業による管理からの移行が十分な速さで進んでいません。

- 開発チームには、運用の信頼性、アーキテクチャの一貫性、開発チーム間の連携をもっと重視してほしいです

- アプリ開発者はネットワークやセキュリティを考慮しておらず、セキュリティチームは開発状況をわずかに把握しているだけで、ネットワークチームが運用上の変更を知るのは開発完了後です。

理想的な環境を実現できるとしたら、開発チームと運用チームの間の連携、コミュニケーション、協働などをどのように改善しますか？

- メトリクス、監視、可視性を改善し、双方がパフォーマンスを把握できるようにします。パイプラインを自動化して、サービス提供を迅速化します。提供に時間がかからないよう、十分なキャパシティを確保します。

- より優秀な人材に置き換える

- お互いを障害と見なすのをやめ、各チームが最も価値を発揮できる領域で貢献できるようにします。自動化は優れていますが、一定の監督がなければ、機能はしても、より適切で最適な方法があるソリューションが実装されてしまうことが少なくありません。

- 開発チームと運用チームの境界をさらに取り払い、利用可能なインフラストラクチャ上で、オーバーヘッドを最小限に抑えながら、拡張性と高いパフォーマンスを確保できる方法でアプリケーションを提供するという共通の目標を持つ「1つのチーム」として捉える必要があります。

- ネクタイを締めた石のように話の通じない相手では、コミュニケーションを図っても意味がありません。

- DEVサイクルのプロセスのより早い段階からF5チームに関与してもらう。

- 開発サイクルの早い段階から運用チームを参加させる

- コードの共有とパイプラインの可視化。コードで管理できるツールは多いほど望ましいです（たとえば、F5 BIG-IPをコードで適切に管理することはできず、それがプロセス上の弱点となっています）。

DevOps

「Opsチームは適切に優先順位を付けていますか？」という質問に「いいえ」と回答した場合、どのように優先順位を見直してほしいですか？

- クラウド環境では、特定のクラウドに依存しないリソース作成の自動化を優先してほしいと考えています。ボタン1つで構築できるインフラは十分に実現可能であり、開発、QA、運用の各担当者にとって有用です。

- あらゆる業務を自動化する姿勢に適応し、失職を恐れるのをやめる必要があります

- 手作業が多すぎるうえ、自動化が進んでおらず、技術上の根本的な問題も理解されていません。開発者に権限を与える必要があります。

- 問題を資金投入で解決しようとする傾向があります。高価な機器を増やし、自動化ではなく、手作業をこなすために人員を増やします。

理想的な環境を実現できるとしたら、開発チームと運用チームの間のやり取り、コミュニケーション、コラボレーションなどをどのように改善しますか？

- Opsチームには、運用環境の詳細を抽象化するツールをさらに提供してほしい

- 私は開発者であり、インフラストラクチャのデプロイと自動化が必要です。運用担当者は、自動化の方法と関連ツールについて学ぶ必要があります。

- 運用チームを、インフラ管理を自動化するインフラサポート中心の組織へと変革します。これにより、開発者はアップグレードやサーバー管理などを運用チームに依存せず、インフラをサービスとして利用しやすくなります。また、運用チームのメンバーを連携役として他のグループに配置し、アプリケーションをより管理しやすくする取り組みを支援します。

- 運用チームを拡充し、開発とテストに直接関与させる必要があります。依頼を持ち込む窓口ではなく、現場で連携するパートナーとしての役割を強化します。