テクノロジーの普及は、顧客の期待が急激に高まることを意味する。顧客は手持ちの端末を自由に切り替えつつ、シームレスなサービスを期待する。（続きはページの末尾にあります）
広く利用されているCI/CDツールの「Jenkins」。その自由度の高さ故の運用の難しさから、他の選択肢を検討するユーザー企業もあるだろう。Jenkinsの代わりになるCI/CDツールを5つ紹介する。
メインフレーム環境でのDevOps導入は無視できない課題になりつつあるが、導入に乗り気ではないメインフレームの専門家は多い。しかし、メインフレーム向けDevOpsをサポートするツールは進化しつつある。
Microsoftは最新のツールを用意してアプリケーション開発者に手を差し伸べている。それは、DevOpsパイプラインを自動的に構成して、クラウドに接続できるようにするツールだ。
Domino's Pizzaは、アプリ開発の初期段階からセキュリティをプロセスに組み込んでいる。そこにはアプリ開発者を成長させる仕組みがあった。
継続的インテグレーション（CI）と継続的デリバリー（CD）はソフトウェア開発の高速化を約束する。だが採用に当たってはまず、成果を引き出すための基本事項を押さえておく必要がある。
英国の医療機関では、看護師が開発を主導したモバイルアプリが成果を挙げている。病棟全体の状態を簡単に確認できるようになり、臨床医の診察にも活用されているという。
CI/CDに先行して着手した企業の取り組みから、ある課題が見えてきた。その課題を解決する「第2世代のCI/CDツール」が登場している。それはどのようなものか。
企業はDXの推進、競争優位性獲得のためにクラウドネイティブやコンテナ技術の導入を進めている。だが、まだまだ十分に活用できていないのが現状だ。クラウドネイティブやコンテナ技術の恩恵を得るには、何がポイントになるのだろうか。
DevOpsはWindows環境でも実践可能だが、アプリケーションやシステムの運用方法を調整することが必要になる。Windows環境にDevOpsを組み込むことを助ける3つのツールを紹介する。
インフラやシステムの運用を対象にした「IT自動化」は、IT部門のタスクだけではなくビジネスにも影響を及ぼす存在になりつつある。それを成功させるには、幾つかの課題を乗り越える必要がある。
ソフトウェア開発の品質向上や効率化を目指すアプローチ「プラットフォームエンジニアリング」が人気となる一方で、DevOpsは終わりを迎えるとの意見も一部で出ている。それは本当なのか。
企業の間で広く普及してきたDevOpsだが、近年のシステムの変化に伴い、新しいアプローチに代替されるとの見方もある。企業はどのように考えているのか。
ソフトウェア開発の手法「リーン開発」を実施するとどのようなメリットがあるのか。実施するためにはどのような課題を解消する必要があるのか。アジャイル開発との違いは。
開発者が独自ツールを乱立させたり、開発とは関係ない業務に追われたりする課題は開発現場に付き物だ。「プラットフォームエンジニアリング」とそのための「IDP」はこの問題を解決し得る。その実現法とは。
アプリケーションを迅速に開発しつつ、セキュリティを確保して安定的に運用するには、DevOpsのアプローチが欠かせない。DevOpsチームはこの課題にどう向き合うべきなのか。SREチームとの協働のポイントとは。
SREとDevOpsの役割の理解は、両チームの連携に必要だ。一見すると同様の役割を担うように思える2つの分野は、実際には何が違い、両チームはそれぞれどのような業務を実施するのか。具体例を交えて解説する。
ITILが最後に更新されたのは、DevOpsの黎明（れいめい）期だった。ITのテクノロジーは急速に進化している中、ITIL 2018は多種多様なIT部門にとって強力かつ有用なものにならなければならない。
最近よく耳にする「DevOps」という言葉。抽象的な表現故に、調べれば調べるほど混乱するという声も多く聞く。本稿ではそんなDevOpsについて、求められる背景、そしてアジャイルとの関係を整理しながら解説する。
BroadcomのVMware買収を受け、プラットフォームエンジニアリング市場での活動を強化しているのがSUSEだ。ただしSUSEには強敵が立ちはだかっていると専門家は指摘する。SUSEの成功の鍵を握る要因とは。
BroadcomによるVMwareの買収を契機と捉えて、SUSEはプラットフォームエンジニアリング市場での競争力強化に乗り出した。オブザーバビリティベンダーStackStateの統合はどのような影響をもたらすのか。
BroadcomによるVMwareの買収は、プラットフォームエンジニアリング市場に変化をもたらしている。「Rancher」を提供するSUSEは、この状況をどう見ているのか。市場でのポジションをどう強化しようとしているのか。
アジャイル開発はソフトウェア開発の柔軟性を高め、ビジネスニーズに対応しやすくする必要性から生まれた。迅速なプロトタイプ開発、概念実証、インキュベーターなどは、前世代の機械工学的「スカンクワークスプロジェクト」（訳注）のアナログ的アプローチに対するデジタル版となっている。
（訳注）革新的な製品や技術を開発するための独立開発チームのこと。航空機メーカーLockheed Martin（ロッキード・マーチン）の先進開発計画を担った部門の通称に由来する。
だがプロトタイプを進化させるため、あるいは拡張するために「1回限りの」実験を捨てて最初からやり直さなければならない場合、労力は無駄になる。循環式のDevOpsモデルはその作業を捨ててしまうのではなく、ソフトウェア開発におけるアジャイルアプローチを基盤としてそれを運用的デプロイと組み合わせる。その目的は、計画、開発／コーディング、インテグレーション、テスト、リリース、デプロイ、運用、モニター、フィードバックで構成される閉ループのライフサイクル構築にある。
従来の段階的なアプローチと異なり、DevOpsの要素は継続的インテグレーション、継続的デリバリー、継続的デプロイを通じたライフサイクルの中で継続的に実行される。従ってツールに対しても違ったアプローチが必要になる。そのために「Chef」「Docker」「Puppet」などがDevOpsに関連して定着した。
しかしDevOpsには多くの課題や側面があり、ツールのポートフォリオは人やプロセスの変化に対応することが求められる。
DevOpsは視野を二極化させる傾向がある。リスクを招く危険で混乱に満ちたアプローチとして過度に慎重な見方をするか、ソフトウェア開発とビジネスの両方を変革する聖杯として過度に崇拝する見方のいずれかに分かれる。大抵の場合、どちらも正確には現実を反映していない。
ソフトウェア開発を変革するメリットについて主張したいと思うことは理解できる。だがDevOps採用の過程でありがちな多くの課題があることもよく知られている。
まずコミットメントだ。経営陣が本腰で支持しなければ、あるいは上級幹部が肩入れしなければ、このモデルは崩壊する。開発・運用チーム全体がDevOpsによって活気づけられていると信じなければならない。
“DevOpsとは何か”については誰もが持論を持っていて、組織内や組織間でもさまざまな意見がある。DevOpsチームが従来型のチームやサードパーティーと並行して仕事をすることもある。
共通認識を形成するためには、完全にオープンかつ透明で、完成されたコミュニケーションが欠かせない。だがほとんどの組織は、変化に対する抵抗や惰性があるのが普通だ。
失敗に対する（正当な）不安などの障壁が存在するかもしれない。それが変化を積極的に受け入れる個人さえも妨げ、あるいは思いとどまらせることもある。組織の構造や予算体系が変化を遅らせる可能性もある。完全なアジャイルDevOpsアプローチの活用に際してはそれが最大の課題になる。
プロセスを加速し、文化を変え、誰もがメッセージを理解するためには、個々のDevOpsチームを越えた経営陣の十分なバックアップがなければならない。それを基盤として、社内外の運用上の「関係」と手順に関する課題に対応する必要がある。ツールや技術への投資に関する意思決定の分野も重要だ。
摩擦が生じる分野の一つに、役割間の成熟度のミスマッチがある。アジャイルの手順や手法を既に採用している担当者は、他のチームメンバーの先を行っている。運用やテスト、品質保証の担当者は、一見すると急激で構造化されていないアプローチに対するなじみが薄く、自信が持てないこともあって、より多くのサポートを必要とする。
Pulse SecureやArxan Technologiesといった企業のツールは、セキュリティにフォーカスし続ける助けになる。最大限の恩恵を受けるために求められる水準の自動化を前提とすると、運用やテスト担当の技術者は、コーディングスキルを学んだり復習したりする必要があるかもしれない。
従来型のソフトウェア開発との統合も必要になる。ほとんどの組織にとって、真っさらな環境と人材およびリソースを使って何もない所からやり直す余裕はない。DevOpsは、担当者間の協調の仕方にも大きな変化を要求する。マルチクラウドベース開発に対応し、促進させるツールも必要だ。その推進には大手クラウドサプライヤーのAmazonやGoogle、そしてとりわけMicrosoftが力を入れている。他にもAtmoseraやMorpheusなどもDevOpsを効率的に導入する手段を提供している。
必要なスキルやリソースが全て社内にある組織はほとんど存在しないことから、外部のプロバイダーが必要になることもある。だが密接に組み合わされ、ペースが速く、実験的なスタイルのDevOpsは、従来のようなアウトソーシングのコストモデルにはうまく合わない。外部との関係には新たな基盤が必要になる。
DevOpsの「継続的」側面から生まれる大きなメリットは、プロセスの最適化と自動化に左右される。継続的サイクルをサポートしてITをビジネスニーズに近づけるためのツールは、Electric CloudやPlutoraなどが提供しており、ソフトウェアのデリバリープロセスを変革的に加速させることができるかもしれない。
初期のDevOpsは人とプロセスに重点を置く必要がある一方で、技術の採用に影響を及ぼす課題も幾つかある。それは大規模な組織や確立された組織の方が顕著に表れるが、DevOps戦略を採用するどんな企業にも影響を及ぼす。
どんな新興トレンドにもいえることだが、この流行の波に乗って「ソリューション」の提供を持ち掛ける多方面からの参入ラッシュが突如として起きる。多くのサプライヤーが、「これを導入すればDevOpsができる」と位置付けた製品やサービスを売り込む。うまくやるためには、スピードだけでなく品質においても開発者の効率性を向上させる実績を持つサプライヤーを見つける必要がある。
DevOpsツールの選定において、プロプライエタリなソリューションに固執するメリットはほとんどない。DevOpsツールに行き渡っている多くのイノベーションは、草の根的な進展とオープンソースから来ており、CloudBeesのような企業がエンタープライズ向けの「Jenkins」サポートを提供している他、Dockerコンテナ化ソフトウェアはオープンソース版と有料のエンタープライズ版の両方がある。HashiCorpは同社独自のオープンソースツールに対応した自動化ツールを開発している。
ただし、開発者に過剰な選択肢や自由を認めると別の課題が生じ、特に長期的なメンテナンスと有効性が問題になる。サードパーティーと連携する上での課題もある。利用できるツールの幅広さには価値があるものの、優れたガバナンスのための基準や枠組みを構築することが必要になる。
組織はビジネスプロセスの再編にはかなり慣れていて、技術的方向性を変えることにもなじみがある。だが文化を変えることは、よく話題にはなるものの、達成が難しい。それでもDevOpsには頻繁に繰り返されるテーマが多数ある。
第一に、何を達成するためにDevOps戦略を導入するのかを定める。目標は開発の迅速化か、品質の向上か、あるいは顧客の需要や期待に近づくことか。包括的な目標は行動の原動力になる。
上層部のサポートによって、チームを活気づけることに貢献してもらう。DevOpsでは実験が許され、これは報いのない失敗を伴う。積極的なステークホルダーを得て、チームに目標を周知させ、経営上層部からの全面的なサポートとバックアップがあることを周知させる。
真の特定可能なビジネスニーズを追求し、自己完結型かつ製品化が可能で、顧客への影響が目に見えるプロジェクトから着手する。
最も熱心でDevOpsに忠実なチームからスタートする。ただしそれを「スター」、あるいは特別チームとして位置付けるという過ちを犯してはならない。このチームは他の全員と並ぶ存在でなければならない。
DevOpsの文化を組織全体に浸透させる必要はない。だがその認識は行き渡らせる必要がある。コミュニケーションは定期的に、広く、はっきりと行う。
チーム全員を1カ所に集める。何らかのにぎわいをつくり出す。コラボレーションの緊密化は、コミュニケーションの質と関連性と即時性の向上を目標とすべきであって、その量を目標とすべきではない。
「良い危機を見落としてはいけない」。問題は修正する。だが最も困難で最も大きく、最も影響力の強いプロジェクトを選んではいけない。なぜなら失敗は、懐疑的な相手に立ち止まる口実を与えるからだ。手っ取り早い勝利を追求し、成功を幅広く宣伝する。自己満足のためではなく、再現するために。
DevOpsを広めるための基礎を築く。そのチームを利用して、学習や他の開発チームとの共有にフォーカスする。人員の入れ替えを行って、誰もが理解し、学習できるようする。ただし最初は小さなチームから始める。
共通のサービスとツールを定める。ペースの遅い、あるいは従来型の開発プロジェクトと共存するために、DevOps用のガバナンスの枠組みを構築する。サードパーティー用の関わり方の標準ルールを定める。
品質、そしてセキュリティの責任をチーム横断で共有する。品質保証に頼って最後に全てをテストするのではなく、プロセス全体を通じて品質を設計する。そうした主要な役割を担う個人は引き続き必要とされるものの、門番ではなく、権限の領域として行動する。
ITmediaはアイティメディア株式会社の登録商標です。
