Computer Weekly製品導入ガイドDevOps経験者を外部から調達してはいけない

業界の一致した見解として、DevOpsとアジャイルはデジタル戦略の鍵を握る。だが、DevOpsを強化するために人材を外部から調達するのは思いとどまった方がいい。

[Cliff Saran，Computer Weekly]

　コンサルティング会社Hackett Groupは最近のベンチマーク調査報告書「Beyond world-class service: IT’s digital capability imperative」で、デジタル革命の実現を支援する技術としてDevOpsにスポットを当てた。

Computer Weekly製品導入ガイド無料ダウンロード

本記事は、プレミアムコンテンツ「Computer Weekly製品導入ガイド」（PDF）掲載記事の抄訳版です。本記事の全文は、同プレミアムコンテンツで読むことができます。

• Computer Weekly製品導入ガイド　DevOps製品導入戦略ガイド

　「アジャイル、DevOpsおよび継続的開発モデルは、開発の加速と迅速なプロトタイプ作成、価値の増大が求められるデジタルビジネス革命に適している」。同報告書はそう指摘する。

　同様に、ITプロフェッショナル4976人を対象としたForresterの調査でも、高い性能を持つビジネス技術の「ソリューションデリバリー機構」を有する企業は、そうでない企業に比べて収益力、市場シェア、生産性目標が1.5倍に上ることが分かった。

　多くのIT部門では、各種のITインフラグループとソフトウェア開発および運用の間で役割が決まっている。そうした役割を融合させて1つのDevOpsチームにまとめることが、まさに目指すべき方向性となる。

　ClaranetがITの意思決定権を持つ幹部750人を対象に実施した最近の調査では、欧州の企業の29％が既にDevOpsのアプローチを採用し、54％は今後2年以内に採用を予定していると回答した。

　自分たちの組織にDevOpsがふさわしいと考えるITリーダーがこれほど多い理由として、より優れたアプリケーションの提供（54％）、運用効率の向上（53％）、顧客満足度の向上（45％）を挙げている。

壊れたDevOpsパイプラインの修復

　ただし多くの企業にとっては、そこに至ることが試練かもしれない。「テクノロジーをより速く、より効率的に届けるという約束は魅力的であり、DevOpsの導入を急ごうとする理由は分かる」。そう語るのは、Perforceの最高製品責任者ティム・ラッセル氏。「だが性急な行動は時として、手っ取り早い、あるいは最も簡単に解決できる道につながりがちだ。たとえプロセスの一部は改善したように見えたとしても、翻って重大な、だが意図しなかった後のコストや労力につながりかねない」

　自動車メーカーJaguar Land Rover（JLR）のソフトウェア開発マネジャー、クリス・ヒル氏は、ロンドンで開かれたDevOps Enterprise Summit（DOES 2017）の会場でComputer Weeklyのビデオインタビューに応じ、同社がDevOpsに関連して突き当たった問題について語った。「下手なソフトウェア開発ライフサイクルは必要以上に速度が遅く、障壁に阻まれ、プロダクションへの遠回りになる」

　開発者が自分たちのコードをどうやって完成させるが分かりにくかったり、進むべき道が入り組んでいたりすれば、想定したペースで機能をリリースできない確率が高まる。

　JLRの場合、自動車のような特定の業界に特有の状況として、組み込み機器の使用が多い。「ソフトウェアを車に搭載しているときに、Web開発者を採用する余裕はない」とヒル氏は言う。

　何台もの車を動かして自動化されたテストスイートを運用するのは明らかに現実的ではない。そこで同氏のチームはやむを得ず仮想化およびソフトウェアベースのインフラを使って、生産車両の運用環境を再現するコードを構築できるようにした。

　文化を変えることは技術を変えることより難しいという意見もある。だがJLRのように組み込みシステムに大きく依存する環境では、変えることのできない技術もある。

　多くの組織は、DevOpsをレガシーITに対応させる場面で大きな障壁に突き当たる。Ticketmasterの技術運用担当シニアバイスプレジデント、ジャスティン・ディーン氏が、2017年に開かれたCloud Native Computing Forumで描写したのはそんな状況だった。それでもDevOpsの原則は、レガシーソフトウェアスタックの管理者にも当てはまるとディーン氏は考える。

　Ticketmasterでは、ソフトウェア開発の担当者が運用業務も担っている。「われわれはDevOps転換の一環として、それまでソフトウェアの導入に必要な技術環境に必ずしもアクセスしていなかったチームを支援し、DevOps方式で運用させた」とディーン氏。

　レガシーITとDevOpsチームを連携させるためにTicketmasterが採用したアプローチの1つが、業務のパイプラインの概念だった。この概念ではレガシーチームによって完成させなければならない作業が提示され、その業務が終わるとDevOpsチームが導入を完了できる。

　ディーン氏は言う。「パイプラインを通してソフトウェアをコンテナで提供する場合、多大な変化を強いられる。この単独方式は、他の何よりも影響が大きく、DevOpsにぴったりだった」

DevOps文化の課題

　文化は多くのITプロジェクトを台無しにしかねない。DevOpsも例外ではない。これはソフトウェア開発とIT運用の問題のように思われがちだが、多くの場合、成功のためには全社的な姿勢の変化が求められる。

　多国籍銀行グループのBBVA（Banco Bilbao Vizcaya Argentaria）は、変革プロジェクトの一環として複数地域を横断する大規模なDevOpsを採用した。DevOpsでは、チームでビジネス製品の責任を持つ。多国籍事業において、これはどう展開するのか。

　BBVAの先端エンジニアリング、DevOps、ITプロセス責任者、ブライアン・ティメニー氏は、DOES 2017でComputer Weeklyの取材に応じ、「DevOpsを1つのチーム以上のレベルに拡張すると、より規範的になることもある」と語った。大企業では単純なメッセージから始めた方がいいと同氏は助言し、「そうすればスピードが達成され、品質も達成される」と語った。

　従業員14万人、開発者1万2000人を抱える同社にとって、変革はビジネスを巻き込む必要があったと同氏は話す。同社はまず、BBVA製品の意味を定義しようとすることから着手した。

　「DevOpsの主な信条の1つは、チームが製品に対してエンド・ツー・エンドの責任を持つことにある。チームでそれを構築し、デプロイしてモニターする。揺りかごから墓場まで、その製品をチームで保有する」（ティメニー氏）

　だが機能に応じて組織化されている同行にとって、それは難しい。概念としての製品の定義は緩い定義になったとしても、鍵を握るのは真に自己完結型の社内チームを持つことだ。

　ティメニー氏によると、同行はその後、チームを中心としてビジネス機能を配置できるようになった。「これが出発点となって、第一に最小限の現実的な方法で行うことのできる中核的な原則が定まった。時がたてば他の全てが進化する」

　このアプローチには、トップダウンのサポートが求められる。だが銀行業界にとって最大級の原動力は、金融業界が変化の必要性を認識しているという点だ。こうした背景からBBVAでは、抜本的な変革の推進をトップダウンで全面的に支持したという。

適切な人材の獲得

　IT部門からDevOpsへの橋渡しに必要なスキルの溝を埋めるため、外部の専門家と契約したい衝動に駆られることもあるかもしれない。だがForresterのアナリストは、DevOps能力の強化を図る目的で外部から人材を求めるべきではないと警告する。

続きはComputer Weekly製品導入ガイドにて

本記事は抄訳版です。全文は、以下でダウンロード（無料）できます。

• Computer Weekly製品導入ガイド　DevOps製品導入戦略ガイド

■Computer Weekly日本語版 最近のバックナンバー

Computer Weekly日本語版　1月24日号　“侵入者をだますセキュリティ”のススメ

Computer Weekly日本語版　1月10日号　“マルチクラウド”は幻想にすぎない

Computer Weekly日本語版　12月20日号　AIが人を裁いた日