企業が陥る落とし穴とは
革新的な「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
-
技術文書・技術解説
[Jamf Japan 合同会社] MDMだけでモバイルセキュリティは十分？ 不足する対策を16項目でチェック -
事例
[Wrike Japan 株式会社] 世界的な家電メーカーが実践する「クリエイティブプロセス効率化」の方法とは？ -
事例
[Wrike Japan 株式会社] 世界的テクノロジー企業に学ぶ、プロセス標準化とプロジェクト納品自動化の秘訣 -
事例
[Wrike Japan 株式会社] ソニー・ピクチャーズ テレビジョンに学ぶ、次世代サービスデリバリーのヒント -
事例
[Wrike Japan 株式会社] ソミック石川に学ぶ、ICT浸透後に直面した「工数管理」の課題と解決策
こんなメディアも見られています
TechTargetジャパンに関連する情報をお探しであれば、こちらのメディアもお役に立てるかもしれません。
ベンダーコンテンツ PR
From Informa TechTarget
SpecialPR
アクセスランキング
-
1
「Copilot」はなぜ放置される？ “議事録要約止まり”を脱する処方箋
-
2
脱VMwareの前提が崩れる BroadcomのVDDK公開停止で確認すべき点
-
3
「Microsoft一択」で本当にいいのか 知らぬ間にライセンス費用が膨らむ真相
-
4
Oracle巨大ITプロジェクトはなぜつまずいたのか 8年で導入1割、追加で170億ドル
-
5
ANAが専用回線から移行した「NaaS」の全貌 ネットワーク準備が数カ月から数週間に
-
6
「データストレージの活用方法」に関するアンケート
-
7
なぜOpenAIやAnthropicのAIは「脱走」したのか 情シスが迫られるエージェント統制
-
8
AI全部入り「Microsoft 365 E7」に企業が二の足を踏む訳 移行意向はわずか4％
-
9
VBAマクロ“原則ブロック”後に「Office」でマクロを実行する方法
-
10
Qlik Senseを使った教育機関の予測分析は現場に何をもたらしたか
ホワイトペーパーランキング PR
-
1
マンガで解説：「ゼロトラスト」「SASE」の必要性とメリット
-
2
5回聞くだけじゃ足りない？ トヨタ式「なぜなぜ分析」の正しい実践方法
-
3
インシデント対応工数を約3割削減、東京ガスの事例に学ぶ監視体制刷新のコツ
-
4
AIエージェントで多様な日常業務を効率化するための入門ガイド
-
5
JR西日本ITソリューションズが「監視業務の属人化」を解消した方法とは？
-
6
国税庁の次世代基幹システム「KSK2」稼働開始に向けて、対応すべき変更点とは？
-
7
5分で分かる「セキュア大容量ファイル転送サービス」の機能とメリット
-
8
ドラマで分かる、標的型攻撃メールの被害を受ける企業と回避できる企業の分岐点
-
9
「脱Excel」か「Excel快適化」か？ 現場にやさしい業務改善の進め方
-
10
少額減価償却資産が40万円未満へ拡大、令和8年度税制改正で押さえるべき変更点
TechTargetジャパン SNS
@techtarget_itmをフォロー
インフォメーション
注目情報をチェック
TechTargetジャパンをフォロー