なぜDevOpsは失敗するか、「組織の壁」を越えるための “ブループリント”とは

アジア太平洋地域 Chief Technologist
John Garratt氏
DevOps実現には連携するシステム全体を把握、管理する課題がある
2009年にFlickrの2人のエンジニアが提唱した、開発(Development)と運用(Operations)を連携させる開発手法「DevOps」。テストやビルド、デプロイといった作業を自動化して、アプリやサービスを迅速に市場投入するべく採用する企業が増えている。国内でも多くの企業が着手するDevOpsだが、現場には馴染んでいるのだろうか。マイクロフォーカスのアジア太平洋地域におけるチーフテクノロジストを務めるガレット氏は顧客と話す中で、「DevOpsに取り組む組織には大きく2つのタイプに分かれる」ことに気づいたという。
「1つは、組織の中にすでにアジャイル開発の取り組みや考え方が根づいていて、DevOpsに着手するケース。組織全体でDevOpsを導入したいという大きな視点を持っています。2つめは、エンタープライズ企業などでDevOpsに着手するケース。『開発のスピードアップとクオリティの両立』に主眼を置いて、導入領域を絞っていることが多いようです」(ガレット氏)
特に、後者の「エンタープライズのDevOpsの導入」では、試行錯誤の段階にあり、課題が多いのだそうだ。ガレット氏によると、その課題とは、エンタープライズの「システム」と「組織文化」によるものだという。ガレット氏はまずシステムについて指摘した。
「エンタープライズのシステムは扱うアプリケーション数が多い。自社で完結するアプリケーションも、外部との連携が必要なものなどさまざまです。システム同士の関連性や依存関係が複雑であり、アプリケーションの仕様に変更を加える際の影響が見通しにくいのです」(ガレット氏)
たとえば金融機関などでは、勘定系の基幹システムと連携した「モバイル向け決済アプリ」が開発されている。レガシーシステムと、新しい領域のアプリが一貫性を持つためには、全体を可視化し、モバイルの変更が基幹システムの不具合にならないように管理する必要があるのだ。
当然、「影響範囲」が広がれば、スピードは損なわれる。これは、システムの密結合による「リスク」の問題と言える。連携するアプリがどんなリスクを持つかを把握した上で、「どういう変更をどのタイミングで実行すべきか」を吟味しなければならない。
では、どのような環境を用意すれば、「システムのリスク」や、「組織文化」を超えてDevOpsを推進できるのだろうか。
・組織文化を超える「DevOpsフレームワーク」と「ブループリント」とは
・リリース期間は最大で8分の1に短縮、劇的なスピード向上を実現
・オーストラリア政府はどのようにDevOpsを推進しているか
・DevOpsはどのように進化するか
今すぐビジネス+IT会員にご登録ください。
すべて無料!ビジネスやITに役立つメリット満載!
-
ここでしか見られない
1万本超のオリジナル記事が無料で閲覧可能
-
多角的にニュース理解
各界の専門家がコメンテーターとして活躍中!
-
スグ役立つ会員特典
資料、デモ動画などを無料で閲覧可能!セミナーにご招待
-
レコメンド機能
あなたに合わせた記事表示!メールマガジンで新着通知
関連タグ