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

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

[Cliff Saran，Computer Weekly]

　コンサルティング会社Hackett Groupは最近のベンチマーク調査報告書「Beyond world-class service: IT’s digital capability imperative」で、デジタル革命の実現を支援する技術として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能力の強化を図る目的で外部から人材を求めるべきではないと警告する。同社の報告書「Organize and staff I&O pros for successful DevOps practices」によれば、DevOps関連職の欠員は2015年12月から2016年12月の間に15％増えた。給与も上昇しているが、一部の求職者はDevOpsの専門家のように見せるため、履歴書の「DevOpsウオッシング（誇張）」を行っている感がある。

　「統合された製品チームの成功は、成功するデジタルソリューションの構築に必要な全てのリソースからノウハウを引き出す能力に懸かっている」。Forresterの主席アナリスト、エイミー・ディマーティン氏は報告書でそう指摘する。

　「従って、アプリケーション開発とITおよび運用専門家のリソースは、セキュリティ専門家やカスタマーエクスペリエンス（CX）専門家、品質保証（QAまたはテストとも呼ばれる）、エンタープライズアーキテクチャ（EA）、ビジネスアーキテクチャ（BA）の専門家のノウハウを必要とする。そうしたチームの成功は、カスタマーエクスペリエンス目標の達成によって測定される」

　ITVの共通プラットフォーム責任者でDevOpsに詳しいトム・クラーク氏によると、適切な人材の採用は大きな頭痛の種になるかもしれない。DOES 2017でComputer Weeklyの取材に応えて同氏はこう語った。

　「技術の進展に伴い、必要とされるスキルも前進する。だがITVではそれを、スマートで親切という2つの性格に絞り込んだ。他は全て付加価値にすぎない」

　ITVにおける「スマート」とは、変化に順応できる能力を意味する。今日使っている技術があしたも使われるとは限らない。「親切（kind）」の方は、新人がチームに溶け込める能力を意味する。「嫌なヤツではなく、いい人でいてくれればいい」（クラーク氏）

緩い組み合わせの進展

　Computer Weeklyが取材した専門家の話から浮き彫りになった1つのテーマは、最新報告書「State of DevOps」にまとめられている。「緩い組み合わせのアーキテクチャでは、個々のコンポーネントやサービスの変更または入れ替えが簡単にでき、それに依存する関連のサービスやコンポーネントに手を加える必要はない。組織的な観点では、チームが他のチームに依存することなく作業を完了できるのであれば、緩い組み合わせのチームと形容できる」

　JLRは、車両に搭載された組み込みシステムへのデプロイを待たなくても、ソフトウェアを仮想環境でテストできるソフトウェア定義インフラの開発を進めている。BBVAのティメニー氏は、自己完結型のチームの必要性を指摘した。Ticketmasterのようにそれが不可能な場合は、DevOpsとレガシーITの間でクリーンな受け渡しができるパイプラインが必要になる。

DevOpsに必要な人材の確保

　統合製品チームのインフラおよび運用担当者の採用といえば、決まって社外に目を向けるのが共通の反応だ。だが、ふさわしいDevOps経験者の獲得が難しいこともある。

　現代的なサービスデリバリー手段を採用する企業が増える中、資格と経験を持ったプロフェッショナルに対する需要は増大している。例えば米国では、DevOpsに分類される職種の数は、2014年12月から2015年12月にかけて15％増えた。間に入って統合チームを支援できる人材は最も給与が高い。2013年10月から2014年7月の間に、DevOpsに分類される人材の給与は米国で約30％増加した。この給与負担を、社内の人材を選んで育成するコストと比較する必要がある。

　たとえ給与を支払える範囲で採用できる求職者を見つけられたとしても、給与に見合うだけの経験を持っていないこともある。求職者はできるだけ給与が高い職に就くために、たとえ統合製品チームで働いた経験がなくても、履歴書にDevOpsの経験を記入する。「面接ではDevOpsエンジニアの経験があると話す求職者が、実は現在の勤務先で『Puppet』や『Chef』を短期間試しただけということもある」。DevOps Guysの共同創業者スティーブン・テア氏はそう指摘した。

本稿はForresterの「Organize and staff I&O pros for successful DevOps practices」より抜粋。

TechTargetジャパントップシステム開発