組織がビジネス機能の継続的な開発とデリバリー、統合のためにDevOpsに目を向ける中で、慎重なコントロールが不可欠とされる。
従来のウオーターフォール方式やカスケード方式のソフトウェア開発では、定められた期間にコードを開発し、システムやアプリケーション管理と組み合わされていた。だが、組織はそうした方式からよりアジャイルなアプローチへと移行しつつある。継続的インテグレーションと継続的な開発、継続的なデリバリーを通じた迅速な機能プロビジョニングの必要性の高まりに伴い、多くの企業が“DevOps”の採用に目を向けている。
DevOpsでは開発とテストと運用のチームが結束し、この3分野を通じたコードとアプリの動きのスリム化を図る。ただしこのプロセスでは大規模なコントロールを行って適切なフィードバックを繰り返し、全てが円滑に運ぶ態勢を徹底させ、悪影響を最低限に抑えながらビジネスにとって最も望ましい成果を出さなければならない。
組織にとっての問題は、DevOpsの成長が急であり、トップダウンでの管理ではなくボトムアップの成長である点だ。DevOpsツールの多くはオープンソースソフトウェアだ。組織内の個人が、自分にとって魅力のあるツールをダウンロードして使い始めることに、何の障害もない。
多くの開発あるいは運用担当者にとって、このチャンスに背を向けるのはあまりに惜しい。開発者は、今ある統合開発環境（IDE）と連携できるダウンストリームシステムを求めてきた。それは「IBM Rational Software Architect」や「Microsoft Visual Studio」のような商用製品だったり、「Eclipse」や「Anjuta」のようなオープンソースだったり、「Atlassian Jira Software」や「CA Project Portfolio Management」のようなソフトウェアプロジェクト管理ソフトウェアだったりすることもある。
それは開発や運用スタッフによる「Jenkins」「Chef」「Puppet」のようなツールの利用増大につながった。Jenkinsはソフトウェアのバージョン管理プロセスを自動化できる。また、「Perforce」「CVS」「Subversion」「Git」「AccuRev」といった既存のバージョン管理ツールと連携できるプラグインや、継続的なデリバリーのためのスリム化されたプロセスを備える。ChefとPuppetは、DevOpsの「Ops」側に重点を置いてスタートしたツールで、構成管理定義を使って作成した機能パッケージを自動的に運用環境にプロビジョニングできる。
こうしたツールの機能は、初めて市場に登場したPuppet（2005年）、Chef（2009年）、Jenkins（2011年）以来、大幅に進歩した。
それぞれの機能は互いに交差する部分が増え、完全なDevOps環境を構築するために別のポイントツールを導入する必要性は以前に比べると薄れている。
チームワークとフィードバックループに対するサポートが強化されたことで、当初は個人のためのポイントツールだったものがグループに完全対応するようになり、業務委託先やコンサルタントといった会社を横断して、分散した拠点間で連携するグループにも対応できるようになった。
この3大ツールの他にも、各種オープンソースライセンス下で利用できる同じ分野のツールとして「Ansible」や「Salt」などがある。「Docker」や「Kubernetes」のコンテナソフトウェア管理システムのようなツールもある。「Ubuntu」を統合したエンタープライズサポート型のアプローチ向けには、Canonicalが「Juju」を通じて独自のKubernetesディストリビューションを提供している。コンテナオーケストレーションの分野において、Kubernetesは急速に新しい勢力になりつつある。Kubernetesを支援するCloud Native Computing Foundation（CNCF）には、Amazon Web Services（AWS）、Google、Microsoft、IBM、Intel、Twitterなどがメンバーとして名を連ねる。
もう1つのオープンソースシステムである「Cloud Foundry」も、前述した他のほとんどのオープンソースツールと同様に、やはり有償サポート付きのシステムが提供されている。Cloud FoundryはDevOpsにうまく合った一連の自動化機能を提供し、他のアップストリームおよびダウンストリームシステムに高いレベルのサポートを提供できる。Cloud FoundryもCNCFのメンバーで、ある程度Kubernetesと重複する部分はあるものの、コンテナ化された環境を超えた到達度でははるかに先を行く。Cloud Foundry内の別のプロジェクトである「KuBo（Kubernetes on BOSH）」は、アプリケーションコードや仮想マシン、コンテナが混在する環境向けにCloud FoundryとKubernetesの統合スタックを提供している。
個々の開発者やシステム管理者が独自の道を行く状況は、IT環境全体にさまざまなツールが混在する状況につながり、組織にとっては問題になりかねない。この状況には以下の2つのいずれかのやり方で対応できる。
1．規範を定める
利用するツールを1つのセットに決めて徹底させる。開発者とシステム管理者全員が同じツールのセットを使わなければならない。残念ながら、このやり方は失敗に終わる確率が大きい。何しろ相手は開発者とシステム管理者だ。デスクの一番上の引き出しには、役立つと思った無許可のソフトウェアを収録したCD-ROMやUSBメモリが幾つも入っている。ツールを統一する必要性に同意しているように見えても、見られていないところで独自のやり方を続けている可能性はかなり大きい。
ここで組織は正しさという概念に陥りがちだ。言われたことを守るよう全員に指示しておけば、それが守られると思い込む。そして何か問題が起き、事後調査の結果、問題が発覚する。まとまりのない機能が点在する状況に、単一の監視は行き届かない。
2．現実を受け入れる
既に手遅れだという現実を受け入れ、個人がバラバラのツールを使用している混乱状態を、よりエンタープライズに対応した状況へと変える手段を見つけ出す。
オープンソースツールの多くは、プラグインやオープンなAPIの使用を通じて、それなりのレベルから高いレベルで他のオープンソースツールと連携させることができる。
さらに高いレベルのコントロールとエンタープライズレベルのサポートが求められる場合、オープンソースソフトウェアのディストリビューション（例えばJenkinsや追加のコンポーネント層をサポートした「CloudBees」など）を完全サポート込みでサブスクリプション契約すれば、組織が求める「エンタープライズ性」が提供される。
これに加えて、既存のツールにかなりの程度のオープン性を導入できる商用システムも存在する。具体例の1つとして、「CA Automic」はDevOpsプロセス合理化へ優れた自動化のアプローチを提供しながら、各種の基盤ツールをオープン方式で受け入れている。
そうしたシステムでは、さまざまな基盤ツールを入れ替えられる点が重要だ。5年前にはChefやPuppetが話題になることはあまりなく、Kubernetesがリリースされたのはわずか3年前だった。5年後の市場はどんな様相になっているのか。もし、過度に行き渡った包括システムが閉ざされたシステムで、決められたツールにしか接続できないのであれば、いずれは取り残されかねない。もしそれがオープンソースツールで、機能のプラグインやプラグアウトが可能であれば、新しく登場するツールを取り込むことができる。
DevOpsの分野に参入している企業は他にも数多い。例えばHashiCorpは複数のツールを提供しており、このうち「Terraform」や「Vagrant」は、DevOps環境をよりシンプルに運用する助けになる。Perforceは中核事業のバージョン管理から始め、幅広いDevOps機能を提供するツールのポートフォリオ「Helix」を立ち上げた。
旧式のシステム構成管理ソフトウェアの世界も進化している。BMCは自動化スイート「BladeLogic」を提供する。クラウドやコンテナを取り入れて現代化した「BladeLogic Server Automation」は、「Atrium Orchestrator」「Control-M Automation」「TrueSight」のような他のBMC製品と組み合わせてDevOps機能を提供できる。
HPEのインフラは、ハードウェアとソフトウェアの溝を橋渡しして論理プラットフォームを簡単に構成し、「OneView」を通じて物理／仮想あるいはコンテナ化されたソフトウェアをプロビジョニングできる。
当然ながら、インザクラウドのDevOpsという選択肢もある。IBMは「Bluemix」で幅広い機能を提供している。AWS、Google、Microsoftはそれぞれのプラットフォームで直接的にツールを提供し、これまでに紹介したツールの多くも、こうした各社のクラウドでセルフサービスモードを介して実装できるようになっている。
DevOpsは、企業が求め必要としているもの、すなわち必要に応じて迅速に提供できる新機能の継続的な開発を実現する中心的な手段になりつつある。なお、そうしたニーズや欲求は、開発者ではなくビジネスによって決定されるべきものであり、本来は「BusDevOps」と呼ぶ方がふさわしい。
そうしたBusDevOps環境を最大限に活用するためには適切なツールが必要だが、規範や禁止を定めたルールを通してそれが入手できる公算は低い。現実を受け入れ、現状の混乱に秩序をもたらし、開発者やシステム管理者が自分たちにとって理にかなったやり方で作業できる包括的なシステムを提供する必要がある。
本稿筆者のクライブ・ロングボトム氏は調査会社Quocircaの創業者。
Copyright © ITmedia, Inc. All Rights Reserved.
基幹システム運用の課題を解消すべく、ノーコード開発ツールを導入する動きが加速している。数あるツールの中からどのようにツール選定を進めたらよいのか、またどのような課題を解決できるのか、具体的なツールも含めて解説する。
老朽化したシステムの刷新に向けノーコード開発ツールを導入した「東亜建設工業」。その活用により、ベンダーに依存することなく柔軟性と持続可能性の高いシステムの構築を推進できる体制を実現している。同社の取り組みを詳しく紹介する。
社内業務の徹底的な効率化を目指す「八千代工業」。最初に導入したRPAでは、紙に依存した業務への対応は難しかったが、これらをデジタル化するためにノーコード開発ツールを使ってアプリを開発し、大きな成果を挙げている。
IT技術の重要性が高まる一方、IT人材不足が加速している。その不足を埋めるため、自社の業務システムをノーコードで開発する動きが広がっているが、ノーコード開発を導入する際には、将来的な全社DXを考慮してツールを選ぶ必要がある。
業務効率化に有効なシステム化だが、プロコードやローコードによる開発では場合によって複雑なコーディングが必要となり、かえって新たな課題を生みかねない。そこで登場したのが、スキル不要で使えるノーコード開発ソリューションだ。
お知らせ
米国TechTarget Inc.とInforma Techデジタル事業が業務提携したことが発表されました。TechTargetジャパンは従来どおり、アイティメディア（株）が運営を継続します。これからも日本企業のIT選定に役立つ情報を提供してまいります。
「パーソナライゼーション」＆「A／Bテスト」ツール売れ筋TOP5（2025年4月）
今週は、パーソナライゼーション製品と「A／Bテスト」ツールの国内売れ筋各TOP5を紹介し...
Cookieを超える「マルチリターゲティング」 広告効果に及ぼす影響は？
Cookieレスの課題解決の鍵となる「マルチリターゲティング」を題材に、AI技術によるROI向...
「マーケティングオートメーション」 国内売れ筋TOP10（2025年4月）
今週は、マーケティングオートメーション（MA）ツールの売れ筋TOP10を紹介します。
ITmediaはアイティメディア株式会社の登録商標です。
