目次


導入を推し進め、変化に対する抵抗を克服する

Comments

DevOps への転換を推進するのは難しいことですが、見返りの大きい取り組みです。この取り組みを成功に導くためには、DevOps のビジネス推進力に注目し、正しい焦点を特定するために、既存のベストプラクティスを評価して DevOps の成果を実証するのに最適なパイロット・プロジェクトを選択しなければなりません。最終的には、ソフトウェアとシステムのライフサイクルの全体像を見据えることが必要となります。この全 8 回からなるシリーズの第 8 回では、企業でどのように DevOps を推進し始めるべきかを学びます。

私は DevOps エバンジェリストとして活動する中で、周りの同僚たちが、DevOps さえあればあらゆる IT 関連の問題を解決できると思い込んでいるように感じ始めています。DevOps が重要な要素であるという考えは誤りではありません。DevOps がなぜそれほどまでに効果的であるのかは次第に明白になってきていますが、DevOps は現状を脅かすものでもあります。他社で働いている同僚の多くは、企業の組織に DevOps ベスト・プラクティスの導入を説得する際に、私に助けを求めてくることがよくあります。

業界全体にわたり、IT 管理者たちは DevOps の原則と手法を取り入れることに力を入れていますが、それでもまだ、DevOps が何であるのか、どのようにすれば DevOps のベスト・プラクティスを効果的に実装できるかについては曖昧なままです。多くの取り組みが失敗している理由は、既存の利害関係者たちが変化を快く受け入れないことにあります。また、彼らは DevOps を、これまで担当してきた職務やグループに対する自分の管理権限を奪うものとして捉えています。実際、運用グループが自分たちの存在自体を脅かすと感じて、DevOps に抵抗した事例もありました。けれどもその抵抗は、DevOps が自分たちにいかに大きなメリットをもたらすかを認識するようになれば収まります。そのメリットを認識するためには、まず、DevOps の目標と成功の尺度を理解する必要があります。

目標および成功の評価

DevOps で重点的に取り組むのは、組織がアプリケーションを更新する方法を改善し、それによって、より頻繁にコードをデプロイし、システムの信頼性を向上できるようにすることです。DevOps への転換を成功させるための手段としては、完全に自動化されたデプロイメント・パイプラインが最もよく使われています。自動デプロイメント・パイプラインによって、ビジネスの達成目標をサポートするのに必要となるバグの緊急フィックスを含め、アプリケーションの変更を必要に応じて何度でも配信できるようにするという仕組みです。DevOps は、システム・セキュリティーも大幅に強化します。それは、正しいコードがデプロイされていること、そして人間のエラーや不正な目的によって許可されていない変更が行われていないことを、決定論的手法を使用して確認できるようになるからです。DevOps の価値を本当の意味で理解するには、この手法を採用する必然性の根拠となる、ビジネスの推進力について考える必要があります。

私たちは、厳しく、動的なビジネス環境にいます。企業は常に、要求が厳しく技術に精通した顧客ベースが期待する以上の機能を提供し続けなければなりません。ビジネス機能を迅速かつ確実に提供できるようにすることによってアジリティーを向上させる DevOps は、企業に競争上の優位性をもたらします。成熟した DevOps 機能を持つ企業は、ビジネスのプレッシャーに効果的に対応できるだけでなく、遥かに信頼性と安全性に優れたシステム・インフラストラクチャーを享受できます。それでもなお、多くの企業は DevOps が一体どういうものであるのか理解しようと苦労していて、誤った情報が DevOps 導入を成功させる大きな妨げになっています。DevOps とは何であるか、そして DevOps がどのようにビジネスの成功に役立つのかを伝えなければ、変化に対する抵抗を克服して、DevOps 導入を成功に導くことはできません。

DevOps とは何か

DevOps とは、開発チームと運用チームを含め、チーム間の効率的なコミュニケーションとコラボレーションを促すための一連の原則と手法を緩やかに定義したものです。効果的な DevOps 手法は、開発および運用テクノロジーの専門家の知識と技能を結集した、ハイパフォーマンスの機能横断型チームを結成することです。さまざまなグループからの優秀な人材を参加させることで、相乗効果を生む、極めて効果的な作業グループになります。このようなグループであれば、ほぼあらゆる問題にポジティブな態度で取り組むことができます。DevOps はその名の通り、開発チームと運用チームの両方を表します。開発チームは、最新のテクノロジーを使用した新しい機能の開発に取り組みます。運用チームは、システムの信頼性を確保することを任務とします。この 2 つの重要な視点を考え合わせることで、驚くべき結果が生まれます。けれども DevOps は開発 (Dev) と運用 (Ops) だけを意味するのではありません。DevOps にはサイロ化しがちな以下のような部門からの利害関係者も含める必要があります。

  • 製品管理
  • QA
  • テスト
  • 情報セキュリティー

適切な利害関係者のすべてを含めることが不可欠です。それと同時に、DevOps のメッセージを全員にわかりやすく正確に伝えることも欠かせません。けれども、専門家が DevOps という業界用語を曖昧で誤解を招くような形で使っている例があまりにも多すぎます。

誤った情報

DevOps に関して伝えられている情報の中には、誤っているものがあります。(多くの場合、連邦法や業界のベスト・プラクティスで要件とされる) 運用および IT の管理を迂回するために DevOps を使用するなど、独自のアジェンダを進めようとしている人々にまでも、誤った情報が伝えられています。多くの大手銀行は DevOps の実装に素晴らしい力を発揮しますが、だからといって、個々の開発者が職務の分離に関する連邦法の要件を迂回して自分のコードを本番環境にプッシュできるというわけではありません。DevOps が有効に導入されると、2002 年に発布されたサーベンス・オクスリー法のセクション 404 で規定されている要件をはじめ、規制上の要件や一般的な IT 監査の管理へのコンプライアンスを実証しやすくなります。

重要なのは、DevOps のベスト・プラクティスの価値とメリットを伝える明確なメッセージを策定するだけでなく、それを実証するのに適切なプロジェクトを選択することです。DevOps をどのように実装するかを判断するには、まずは、現在のベスト・プラクティスを評価するところから始めることが最適です。

DevOps 評価を実施して、抵抗を克服する

私はプロセス改善イニシアチブを実装するテクノロジー・グループと協力する際は最初にいつも、何が上手くいっていて、何に改善の余地があるのかについて質問します。(少なくとも完全には) 変更すべきではない既存の手法と優先的に対処すべき痛点に関する洞察を提供するのに最適な立場にいるのは、通常、改善対象とする実際の作業に最も関与している人々です。そのために、私は開発管理者からテスターまでのさまざまな利害関係者と会って、上手く行っている点と改善の余地がある点を尋ねるようにしています。DevOps を評価すると、組織でまさしく改善が必要な手法について、貴重な洞察を得ることができます。ここで重要な点は、グループから挙げられるプロセス改善の提案のほうが、外部から挙がってくるアイデアよりも受け入れられやすいということです。したがって、変化への抵抗を克服するためには、組織内で最初に着手するのに適切な、一部の利害関係者からすでに支持を得ているイニシアチブを特定する必要があります。私が DevOps を評価するときには、プロセス改善イニシアチブを特定できるよう、既存の手法を業界の標準 (ISO/IEEE など) およびフレームワーク (ITIL v3、ISACA COBIT) と比較しています。

企業で DevOps を導入する際は、DevOps のベスト・プラクティスを企業全体に広げるための戦略を策定しなければなりません。私がそのために通常取っている方法は、各グループがそれぞれの作業内容を理解するのに役立つ、共通の基準を確立することです。理想的には、自分の組織に関連する重要な基準を含めた独自のプロセス成熟度フレームワークを作成して、それを利用します。私はまず、ハイパフォーマンスの機能横断型チームを結成して、チームが効率的にコミュニケーションをとり、協力し合えるようにします。次に、各チームの構成管理のベスト・プラクティスを検討します。また、自動アプリケーション・テストも必ず検討するようにしています。その上で、まずは簡単に達成できるような小さい目標を立てて、プロセスの早期に成果を上げることに重点を置きます。

最初は、成果を上げる最大の機会を提供する小規模から中規模のプロジェクトを必ず選ぶことにしています。チームが実際に物事を改善できることを確認すれば、より自信がつき、難しい課題に取り組む心構えができるからです。難しいプロジェクトや実装するのに時間がかかるプロジェクトを選ぶと、成果があることを実証する前に、チームの勢いがなくなってしまうというリスクがあります。例えば、チームが選択したバージョン管理システムが強力さに欠けていると思ったとしても、すぐに成果が表れるよう、デプロイメントに使用するスクリプトを修正することを選びます。長期にわたって成功を収めるためには、正しいパイロット・プロジェクトを選ぶことが重要なのです。さらに、DevOps イニシアチブを計画する際は、大局的な見方も必要です。

DevOps は開発と運用だけに関するものではありません。DevOps イニシアチブを計画する際は、アプリケーションのライフサイクル全体を考慮して、すべての利害関係者を関与させる必要があります。製品マネージャーか新たな視点を示してくれたことで、最も重要な目標に目を向けられるようになったことは度々あります。時には、ヘルプ・デスクや他のサポート業務から最良のアイデアを得ることもあります。DevOps を実装するということは、組織内のさまざまなサイロ間でのコミュニンケーションを促し、サイト間のコミュニケーションとコラボレーションを効率化することを意味します。

ほとんどの場合、私にとって第一の優先事項となるのは、信頼性です。

信頼性

初めから非現実的な目標に取り組もうとする DevOps イニシアチブが、あまりにも数多く見られます。例えば、ワンクリックでのデプロイメントや、継続的デプロイメントのように、DevOps 導入の最初の段階では必要のないような目標です。私の第一の優先事項は、オペレーターの介入を必要とせずにボタンのワンクリックで完了するというところまでデプロイメントが自動化されていないとしても、完全に信頼できるデプロイメントにすることです。つまり、信頼性という最も重要な目標が達成されている限り、誰かがスクリプトを実行して Enter キーを何度かクリックしなければならないとしても、最初の段階では受け入れられるということです。デプロイメント・プロセス中の問題を仕方がないとして諦めている関係者に会ったことがあります。このような人々は、開発者がすべてのデプロイメントを金曜日の夜間に行って、何か問題が発生した場合は週末を通して (当然、週末中はシステムを停止できるという前提で) 問題を修正するものだとしばしば思い込んでいたりします。私がとっている方法では、まず始めにデプロイメント・プロセスを複数のサブプロセスに分割し、それらのサブプロセスを平日の 1 日または 2 日で行うようにスケジューリングします。この方法には、利害関係者のすべてに、完全に信頼できるデプロイメントは実現可能であるだけでなく、必須であることを納得させる文化的変化が必要となります。そのために私が利害関係者に説明する際にいつも引用しているのは、生命維持装置や原子力発電所です。これらのシステムでは必ず更新が必要となるソフトウェアが使用されているため、明らかに、完全に信頼できるデプロイメントを目標としなければなりません。デプロイメントが完全に信頼できるものになれば、継続的デリバリーと継続的デプロイメントを保証することができます。

セキュリティー

次に考慮事項となるのは、DevOps を利用して、セキュアなデプロイメントを確実にするという点です。この点に関して DevOps とデータ・セキュリティー関係者が手を組めば、飛躍的な成果を上げることができます。この考慮事項に対する私の取り組みは、正しいファイルのすべてがデプロイされていることを確認して、人間の間違いや不正な目的による許可されていない変更を検出できるようにすることです。

次の考慮事項は、QA およびテスト機能が、DevOps の急速な自動デプロイメントのペースと同じペースを保てるようにすることです。QA およびテストを対象とした DevOps は、堅牢で包括的に自動化されたテストなしでは存続できません。自動化するテストには、単体テストと機能リグレッション・テストだけでなく、より完全な API およびサービス仮想化テストも含める必要があります。DevOps への転換に常に伴う急速なデプロイメント・ペースに自動テストが追いついていけなれば、DevOps は失敗の危険にさらされます。

クラウド内の DevOps

クラウド・ベースのインフラストラクチャーを DevOps のベスト・プラクティスを使用せずに管理することを想像するのは、ほぼ不可能です。クラウドは、インフラストラクチャーでコードとして使用する DevOps 手法から大きなメリットを受けて、実証可能な飛躍的成果をもたらします。

まとめ

DevOps は、コミュニケーションとコラボレーションの改善に役立つ、堅牢な原則と手法一式を提供します。DevOps の導入を推進し、変化に対する抵抗を克服するためには、組織にもたらされる価値を実証し、DevOps ベスト・プラクティスを企業全体に広げる際の支持を得るのに効果的なイニシアチブを理解する必要があります。


ダウンロード可能なリソース


関連トピック


コメント

コメントを登録するにはサインインあるいは登録してください。

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=DevOps
ArticleID=1039667
ArticleTitle=導入を推し進め、変化に対する抵抗を克服する
publish-date=11172016