DevOps採用を阻む壁、壁、壁！：Computer Weekly製品導入ガイド

継続的デリバリーの動きに大企業が加わりつつある。DevOpsの採用に向けた課題について解説する。

[Caroline Donnelly，Computer Weekly]

　DevOps運動は最近まで大企業には無縁と思われていた。もっと小さく動きの速い新興企業が愛するアジャイルソフトウェア開発の慣行を、大規模で複雑で動きの重い組織がまねできると願うこと自体、考えられないという否定的な見方もあった。

　大きな組織は官僚主義やレガシー技術、ウオーターフォール方式のソフトウェア開発に引きずられ、DevOpsが普及しにくい。現状に挑戦しようとしても実を結ぶことはない――といった説もある。

　だが、そうした否定的な見方に欠落していると思われるのは、DevOpsとは相反すると考えられている特徴の多くが、実際には大企業内部で変化を求める意欲をかき立てているという点だ。自分たちが今までずっとやってきたようなやり方では、競争上不利になるという認識は浸透しつつある。

競争力を守る

　長くて制約の多いソフトウェア開発サイクルは、もはや競争力を保つ助けにはならず、変化する顧客の需要にペースを合わせる能力も維持できないということを、大企業のITリーダーは認識している。

　結果的に、既に競合企業に先を越されたソフトウェア製品、あるいは顧客の要望に合わないソフトウェア製品を打ち出すことに、ITリーダーはいら立ちを募らせる。

　さらには、競合企業がアジャイルの概念を取り入れてソフトウェアの革新ペースを加速させる様子を目の当たりにし、否定的な見解とは裏腹に、DevOpsが規模の大きな組織内でも根付くことができる様子を見せつけられている。

　その証拠として、DevOpsの動きに加わっている有名企業の名を列挙してみれば、従来ならアジャイルには向かないと思われたかもしれない、規制の厳しい業界に属している企業がいかに多いかが分かるだろう。

　「保守的なことで有名なそうした組織が、たとえIT部門内部だけでもこの波に乗れるなら、本当にそれが可能だという確証は強まる」。『The DevOps Handbook』の共著者ジーン・キム氏はそう語る。「The DevOps Handbookには、そうした組織がこの原則をどう採用したかを示す48の事例を収録した。（成功事例のうち）12例はLinkedIn、eBay、Google、Amazonといった新興の大企業だが、残りはわれわれと同じような大規模で複雑な組織が占める」

　Computer Weeklyは過去に、大企業がDevOps計画を始動させ、組織全体がアジャイル思考の恩恵を受けられるようスケールアップするために取るべき手順について、詳しく解説した。どんな組織であれ、DevOpsを追求する上で克服すべき共通の課題には、経営上層部の支持や協調的な職場環境の醸成、持続可能な永続的デリバリーパイプラインの構築などが含まれる。

　以上はどれも、小規模の（あるいは部局内の）DevOps活動を拡張して全社的な取り組みへと転換し、組織全体でそれを後押しして恩恵を受けようとする場合に重要な手順と見なされている。

　だが、DevOpsを採用する大企業がますます増える中で、全社的な採用を阻むもう1つの障壁として、業界特有の障壁、あるいは組織運営の在り方に関する障壁が浮上している。

　その1つは、DevOpsの文脈における継続的デリバリーと改善の真の意味、そしてこのアプローチが自分たちの製造するソフトウェア製品に与える恩恵について、経営上層部に評価してもらうことに関連する。

　経営上層部には、継続的デリバリーでは従来のような意味においてはソフトウェアプロジェクトがリリースのときまでに終わらないこともあり、常に反復を続ける改善の対象になると理解してもらうことが重要だ。

　そうでなければ、製品がプロダクション段階に入った時点で上層部が勘違いして完了と思い込み、DevOps実践者が取り組んでいるプロジェクトへの支援が尽きる事態になりかねない。DevOps Research and Assessment（DORA）のニコール・フォースグレンCEOはそう警鐘を鳴らす。

　問題の一因は、プロジェクトの進展を図る尺度として、翻っては予算をどう拠出すべきか判断する上で、ソフトウェア成熟モデルを使うという考え方から離れられない上層部が依然として多いことにある。

　「成熟モデルの課題として、特にそれが成文化されている場合、制度化され、壊れにくい形で固定化されている可能性がある。そこへ突如として目標を設定すれば、そのレベルに到達した時点で完了となる。プロジェクトが完了したと組織が判断すれば、そのプロジェクトを支えるリソースの流れも消滅するかもしれない」とフォースグレン氏。

　そうした思考は、継続的に開発された製品に必要とされるサポートの在り方にはそぐわないとフォースグレン氏は言い、「例えば、第1段階から第5段階まで（経営上層部からの）強力な後押しがあったとしても、業界がそのような仕組みで動いていない」と指摘した。

草の根運動

　DevOpsが大企業内で草の根運動として始まった状況では、他の事業部への拡大を促すため、さらにはその会社の新しいソフトウェア製品開発において優先される手段としてDevOpsが採用されるために、経営上層部のサポートが欠かせない。

　DevOpsを採用する大企業のサクセスストーリーは多数あり、経営上層部が主導して継続的デリバリーの採用を決定した会社の実例も浮上している。

　ドイツの金融サービス会社Allianz Deutschlandの場合、経営上層部の一行がシリコンバレーを訪問したことが、社内の各事業部門でDevOpsの採用を奨励するきっかけとなった。Allianzの上層部は帰国すると、社内の各事業部門に対し、1年以内にDevOps方式でアプリを開発するよう指示を出し、2016年8月には予定より3カ月早く成果が表れた。

　大企業のDevOps採用が経営上層部の主導で進められる場合、その会社のアジャイルの野心実現を担う担当者もこのアイデアに対して乗り気にならなければ、下層部で変化に対する抵抗が起こることもある。

　ロンドンで2017年6月に行われた「DevOps Enterprise Summit」（DOES）で、AllianzのIT責任者アンドレア・ヒルツェルイエガー氏は、Allianzでも一部で抵抗があったことを認めた。最も影響を受けたのは、セキュリティとコンプライアンスチームだったという。

　この取り組みの初期段階では、互いにどう連携するのが最善かを巡って組織内の開発チームと運用チームが争いになるなどの問題に見舞われた。ヒルツェルイエガー氏は両チームのメンバーにテーブルを囲んでもらい、どのような手順で進めるかを話し合ってもらうことで、問題の解決に当たった。

　「驚いたことに、同席して何をすべきかについて実際に話し合うと、多くの問題が消滅した。一部の問題は、担当者が実際に何をすべきかを巡る単なる誤解だった」と同氏は振り返る。

　この環境はまた、AllianzのセキュリティチームとコンプライアンスチームがDevOpsに関する懸念を伝えるきっかけにもなり、開発チームと運用チームはその懸念に直接対応することができた。「組織全体が足並みをそろえなければ、もっとずっと難しくなる」と同氏は言い添えた。

　世界35カ国に展開し、ITとサービスデリバリーを担う1万2000強のチームが全てDevOpsへの転換に加わらなければならない組織の場合は、特にそれが当てはまる。その状況に直面したのがスペインの多国籍銀行グループBBVAだった。同社の先端エンジニアリング、DevOps、エンジニアリングプロセス担当グローバル責任者ブライアン・ティメニー氏によると、BBVAは国境と言語の障壁や、文化の違いを越えたDevOpsの拡大支援に力を入れてきた。

　その一環として、それぞれの国でDevOpsの流れを主導するリーダーシップチームを組織した。「各国を横断する研究拠点を設け、国ごとにDevOpsの拡張を支援するコンピテンシーセンターを設置して、遂行に現地の事情を盛り込んで、チームで歩んでいる（という感覚を）持ってもらえるよう気を配った」。ティメニー氏はそう説明する。

　組織によっては、経営上層部が推進するのか、草の根的に台頭してきたのかを問わず、会社がDevOpsの採用に動くことに対して特に強い不満を感じたり、疎外感を感じたりする人物がいることもある。

　そうした人物は簡単に見つけられるとは限らないと指摘するニュージーランドのIT管理コンサルタント、ロブ・イングランド氏は、DOESで「DevOpsサバイバル」について講演し、このテーマに言及した。

　「社内には、新しいやり方に積極的で熱心に取り組むイノベーターや新しもの好きがいる。それを見て、組織（全体）が動いているという幻想にとらわれがちだ。だが態度がはっきりしない者や、言うべきことは言うが必ずしも乗り気ではない者も大勢いて、新しい思考を理解して採用するまでに長い時間がかかる保守派も存在する。われわれは多様な人たちを取り込まなければならない」（イングランド氏）

　もし、そうした人たちの抵抗が、DevOpsチームの他のメンバーによる前進の足を引っ張ったり、邪魔をしたりする危険がある場合、強硬なアプローチを採り、「もし人が変わらないのなら、その人を変えよ」とアドバイスする実践者もいる。

　これに対してイングランド氏は、もっとソフトなアプローチを勧める。まずそうした人物がなぜDevOpsに乗り気でないのかを把握することから始めて、この方法を採用する長期的なメリットを説く。

　同氏は言う。「特定の技術に固執すれば、キャリアパスは限られる。あらゆる技術職に同じことがいえる。われわれ全てが再発明し、成長し、前進しなければならない。だが今物事が起きているペース、特にDevOpsへの転換が組織全体に浸透しているペースは、個人に対して前進を迫る猛烈なプレッシャーを与えている」

動かない人たちの動機付け

　この文脈において、「先へ進む」必要性や緊急性が見えていないと思われる人に対処する際、そうした人たちを刺激し、自分のキャリアに何を求めているかについてちょっとした自省を促すために使える幾つかの質問がある。

　「私の目を見て次の質問に答えてほしいと語りかける。あなたの仕事は1年後にはより良くなっていますか？　あなたはより良い成果を挙げていますか？　1年後にはもっとうまくいっていますか？　もし相手が肯定できないのであれば、その相手は継続的な進歩ができていない。

　つまり、継続的進歩という原則そのものが、単純に存在しない。さらに、より良い人生や、新しいことを学んで前進するチャンスという意味で、変化が人に投げ掛ける可能性についても語るといい」とイングランド氏は助言する。

　熱心な人、はっきりしない人、保守的な人が入り交じるDevOpsチームでは、チーム全員に身に付けてほしいと思うスキルや態度を備えた模範的な人物にスポットを当てることも役に立つかもしれない。「そうした人物を採用するか、

　業績の高いチームから低いチームへ異動させて、他のメンバーに見習ってほしい振る舞いを示す一種のモデルになってもらう」（イングランド氏）

態度の変化

　人の態度を変えるには時間と忍耐を要するという上層部の理解も重要だ。動きの遅い人たちのやり方や思考が一夜にして変わることを期待してはいけない。

　イングランド氏は、「技術は即座に転換でき、転換のプロセスは相当速い。だが人や文化、態度、そして組織が変わるペースは、そうはいかない。経営上層部に理解してもらうことも課題になる」と話す。

　しかし、もしそうした人物が本当に変化への意欲が一切なく、組織のDevOps目標達成を手助けすることにも一切の関心を持たないのであれば、上層部はそうした人物が優雅に退場する手助けをしなければならない。「仕事は先へ進む。

　われわれはそれに従って人を動かす必要があり、それが課題の一部だ。それは人の退場を意味することもある。だがわれわれは、そうした人たちも安全に退場してほしと願い、出ていく人たちの面倒を見る」

　「バスに乗っているか、バスに乗っていないかのいずれかだ、という言い方もある。それで結構だが、バスの下に人がいないことは確認しなければならない」。イングランド氏はそう指摘した。

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