企業が陥る落とし穴とは
革新的な「DevOps」を台無しにする“7つのあるある”
システムの運用者と開発者がより密接に連携することで業務の俊敏性を高める「DevOps」に失敗する企業が続出。失敗の背景にはありがちな“7つのあるある”が見られる。
「DevOps」を導入する準備はできているだろうか。だが、導入の前に少し立ち止まって考えてみてほしい。一般的な落とし穴とミスを理解しないでDevOpsの導入に突き進むことは、登山用具を持たず山に登るようなものである。
DevOpsで成功を収めるには必要なものがある。それは「将来に対する全体的なビジョン」「計画」「野望」で、革新的な考え方と視点も必要になる。DevOpsを単なる小さな変化と捉えて、大幅な投資を伴う徹底的なプロセスの再編成を行わないと、大きな問題が発生するか、導入の途中で完全な失敗に終わる可能性が高いだろう。
DevOpsには7つの大きな過ちがある。このような過ちを犯すとDevOpsと企業環境を転換するイニシアチブが暗礁に乗り上げることになる。
1.計画を怠る
明確な計画なくDevOpsによる転換を図っても、ほぼ確実に失敗に終わる。多く見られるミスは、大勢の賢い人たちがDevOpsの分野に関する情報を試しても、すぐに組織で虐げられてしまうことだ。残念ながら、このような先駆者は、組織や上層部からのコミットやサポートが得られず、仕事で苦痛を強いられることが多い。
2.出資を怠る
「予算がない戦略は夢でしかない」とクライアントから皮肉をいわれたことがある。これはDevOpsのような転換計画について特に当てはまる。DevOpsの導入が成功すれば、より低いコスト、より高いアジリティ、より高い品質など多くの利益を手に入れることができる。だが、人、プロセス、テクノロジーへの大幅な投資を行わない限り、この利益を享受することはできない。
3.革新への参加を怠る
時間とコストが掛かる既存の手動プロセスを少しずつ変えようとしても失敗に終わる。DevOpsは継続的な配信およびクラウドと密接に絡み合っている。これはコーディングから運用に至るまでの全プロセスに当てはまる。既存のツールを使用してDevOpsを運用することは実質的に不可能だ。仮にできたとしても、途方もなく困難でコストが掛かるだろう。
DevOpsで成功を収めるには、既存のプロセスやツールではなく、達成目標を中心に据えた新しい継続的なプロセスモデルの構築が不可欠である。アプリケーションチームを古いプロセスモデルから新しいプロセスモデルへ移行する必要もある。プロセスの設計と実装を先導すべきは、このチームだ。
4.開発者に主導権を与えることを怠る
DevOpsは、IT運用部門が主導で行うアプリケーション開発チームのための取り組みだと見なされることが多い。だが、この取り組みのために、アプリケーション開発チームが運用部門から相談を受けることは少ない。開発者が開発者のために記述したクラウドの方が、運用部門が構築したクラウドよりも成功率は高い。DevOpsについても同じことがいえる。DevOpsではアプリケーションとインフラを1つにするため、コードレベルでの統合が必要になることを忘れてはならない。DevOpsによる転換は、開発者が運用部門と密接な協力関係を築いた場合に、最も大きな成功を収めることができる。
5.スケールの拡大を怠る
DevOpsは、迅速なコードのリリースを実現する。毎週または毎日というサイクルも可能だ。DevOpsにおける運用管理とは、より多くの成果を得るためにプロセスのボトルネックを取り除くことである。同時に品質を継続的に向上しなければならない。毎月、毎週、毎日というサイクルでアプリケーションをリリースするには、全ての運用プロセスと同じ課題が付いて回る。ITではあまり一般的ではないスケールという視点が必要になる。
6.テストを怠る
DevOpsは複雑なシステムである。そのため、詳細かつ継続的にテストをする必要がある。プロセスが自動化されているほど、1つの小さなエラーが全ての作業を中断させる可能性が高くなる。テストには「単体テスト」「システムテスト」「カオス／サービス停止のテスト」「パフォーマンス、回復性、品質のテスト」などがある。どのテストも実施が不可欠だ。統計的工程管理やシックスシグマなど、製造／プロセス産業で一般的に使用される手法はDevOpsを導入した環境で非常に役に立つ。だが、見過ごされることが多い。
7.開発者と運用部門の足並みをそろえることを怠る
企業では、アプリケーションの各段階で異なるプロセス、ツール、担当者を採用することがあまりにも多い。例えば、開発環境、テスト環境、運用前環境、運用環境でプロセスや担当者が異なることは珍しくない。また、監視、ライセンス管理、セキュリティなど、管理スタックを構成するその他のコンポーネントも段階によって異なる。加えて運用段階では多くの手動による承認が必要になる。
このような状況ではDevOpsが機能しない。各段階で統一したアプリケーションを構築、展開、管理しなければ、現行の数カ月という開発のサイクルを数週間や数日に短縮しようとしたときに大惨事となるだろう。
Copyright © ITmedia, Inc. All Rights Reserved.
この記事の著者
関連記事
新着ホワイトペーパー PR
-
製品資料
[株式会社キーエンス] なぜRPA導入は頓挫する？ シナリオ作成の壁を乗り越える解決策とは -
製品資料
[株式会社セールスフォース・ジャパン] 「CRMは設計と無関係」は本当か？ PLMとの融合で実現する高速開発 -
事例
[日本ヒューレット・パッカード合同会社] AIエージェントの時代にどう備える？ 「新たな働き手」を支える3要素とは -
製品資料
[日本ヒューレット・パッカード合同会社] “横並びの自動化”から脱却、AI活用で生産性と競争力を高める秘訣 -
製品資料
[サイボウズ株式会社] AIが「わざわざ使うツール」になっていない？ 業務で自然に使う導線にする秘訣
こんなメディアも見られています
TechTargetジャパンに関連する情報をお探しであれば、こちらのメディアもお役に立てるかもしれません。
ベンダーコンテンツ PR
From Informa TechTarget
SpecialPR
アクセスランキング
-
1
なぜ「全社配布Copilot」は使われないのか？ 失敗に学ぶAI定着
-
2
法務と開発者で「言葉が通じない」問題 トヨタやソニーが語るOSS管理の真実
-
3
ChatGPTは“検索しまくり”でGeminiは“淡泊”？ データが明かすAIの裏側
-
4
なぜ「Gemini 4 Argon」は出遅れたのか？ Googleが狙う“逆転のシナリオ”
-
5
「中堅・中小企業のネットワーク・セキュリティ運用実態」に関するアンケート
-
6
損保ジャパンはなぜ「COBOL」を捨てなかったのか？ 脱メインフレームの真相
-
7
「Wi-Fi 7」経由でWindowsが乗っ取られる？ 最高権限奪取の恐怖
-
8
情報漏えいはなぜ繰り返されるのか 今すぐ見直すべき「境界」
-
9
情シスの約8割が転職や退職を意識 調査で分かった“辞めたくなる最大の理由”
-
10
【漫画付き】ひとり情シス協会が明かす、RAG導入でしくじる企業「2つの共通点」
ホワイトペーパーランキング PR
-
1
不審メールの経路や見せ方に変化？ 2026年夏の3事例から見えた動向と対処方法
-
2
家庭用Wi-Fiルーターの業務利用は危険？ 避けるべき理由と具体的な対策
-
3
Microsoft 365を安全に運用 うっかりミスやサイバー攻撃に備えるデータ保護術
-
4
財務部門がAIを最大限に活用する方法 無駄のない戦略的リーダーシップへの道
-
5
LLMが兵器化？ 元FBI高官が鳴らす警鐘とセキュリティツール統合のポイント
-
6
「オンプレミス回帰」せざるを得ない“合理的な理由”
-
7
なぜRPA導入は頓挫する？ シナリオ作成の壁を乗り越える解決策とは
-
8
生成AIを開発に導入しても効果が見えない？ 実証実験で分かった成果と課題
-
9
経産省DX指針から読み解く、受発注業務デジタル化ロードマップ
-
10
HDDを使わない「SSDオンリー」が無謀なのはなぜ？
TechTargetジャパン SNS
@techtarget_itmをフォロー
インフォメーション
注目情報をチェック
TechTargetジャパンをフォロー