DevOpsのテキスト研修

組織でDevOpsをどう始めるか

組織でDevOpsをどう始めるかが、取り組みの成功を左右します。最初の機会が唯一の機会かもしれません。最大限に生かしましょう。

一斉導入を避け、小さく始める

現状を一度に変え、初日から組織全体のDevOps変革を宣言することはできません。まず、何度も問題に対処しているのに、目標を達成できていないチームを見つけます。改善が必要だとはっきり認識し、新しい働き方の検討に最も前向きなチームです。そして、組織と顧客に力を尽くす意思があるチームを選びます。

早期に成果を示す

あなたの使命は、DevOpsの取り組みで早期に成果を出し、懐疑的な人や反対する人にも、DevOpsが解決する課題と生み出す価値を実証することです。その後、組織の他の領域でも同様の改善を一つずつ進めます。

ドイツの大手ERP、CRM、SaaSメーカーも、このようにDevOpsを始めました。保守チームが成果物を届けるのは年に一度だけでした。その結果、リリースされていないコードが、インシデント別の複数のブランチに急速に蓄積しました。コードをマージし、十分にテストした信頼性の高い保守リリースを行うのは極めて困難でした。

まず、保守開発チームを、保守デリバリーの計画、品質保証、運用環境の管理を担うチームと統合しました。調整とコミュニケーションを簡素にするため、タスクとチケットの共通管理システムも使い始めました。その後、月1回のリリースを開始し、ほどなく2週間に1回にしました。

保守部門がこの実践を始めて最初の1年で、前年の6倍のインシデントを解決できました。同じくらい重要なのは、再オープンしたインシデントと、それに伴う手戻りの割合が39%から4%へ下がったことです。

この大きな改善と、数値で示せる実績により、小さなDevOpsの取り組みは組織内で強い支持と信頼を得ました。他の製品やサービスのチームへ展開するため、経営陣の支援も得られました。

グリーンフィールドかブラウンフィールドか、適切な製品やサービスを選ぶ

DevOpsを始める際には、グリーンフィールドとブラウンフィールドのどちらの製品やサービスを選ぶかも検討します。

グリーンフィールドとは、組織にとって新しい製品やサービスです。とくに立ち上げ時は、既存チームから切り離して活動できる新しいチームを作るのが得策です。既存のやり方を変え、枠にとらわれず考える余地が増えます。以前の担当業務で中断される頻度も下がることが期待できます。売上の増加、顧客との関わりの改善、デリバリー時間の短縮など、具体的なITや事業の指標と成果を新しいDevOpsチームに託します。グリーンフィールドの取り組みはレガシーコードや既存の依存関係に頼らないため、あなたとチームがDevOpsを成功させるうえでリスクが低くなります。一方、DevOpsが組織の既存の課題を解決できるか、他の領域でも同じ成果を出せるかまでは実証できないため、成功が組織に与えるインパクトは小さくなります。

ブラウンフィールドの製品やサービスからDevOpsを始めることもできます。その多くはすでに本番システムで稼働し、事業と顧客を支えています。私たちと同じ地球で仕事をしているなら、既存のソフトウェアにはかなりの技術的負債があり、信頼できるテスト自動化も十分ではない可能性が高いでしょう。こうした性質のため、ブラウンフィールドから始めるほうが難しいこともありますが、成果が出たときは報われることも多く、組織への説得力と影響も大きくなります。

DevOpsは稼働中のレガシーシステムを多数抱える大企業にも役立つ

DevOpsはブラウンフィールドの製品やサービスに適さないと思い込む人が多く、スタートアップ専用だと考える人もいます。実際には、数え切れないほどの事業に不可欠なレガシーシステムと数千人の従業員を抱える、巨大で成熟したIT組織を持つ企業から、最も模範的な取り組みのいくつかが始まりました。Amazon、Easy、Facebookなどが例です。前述のSaaSメーカーの事例のように、既存の組織がブラウンフィールドの製品やサービスからDevOpsを始めることもできます。多くのブラウンフィールド製品やサービスは、実際に達成している処理能力と顧客の期待に大きな隔たりがあるため、通常はDevOps変革の恩恵を最も受けやすい対象です。まずは時間を取って技術的負債を解消、または少なくとも減らし、既存の製品の機能と便益に対して足りていない自動テストを作りましょう。そうしなければ、ブラウンフィールドの製品やサービスを、より短いサイクルで安定して本番デプロイできるようにはなりません。

適切な記録管理システムまたは顧客接点システムを選ぶ

最初のDevOpsの取り組みでは、記録管理システム（SoR）と顧客接点システム（SoE）のどちらも選べます。記録管理システムは、組織で信頼できる情報源を一元管理する集中型のシステムです。顧客、取引、セキュリティ、プライバシーなどのデータ管理に強みがあります。顧客接点システムは主に分散型のアプリケーションで、オムニチャネルに対応したレスポンシブなポータルや、モバイル、タブレット、デスクトップ向けアプリを通じて、顧客やユーザーが組織とやり取りできるようにし、その利用を促します。

記録管理システムを選ぶ利点は、コンプライアンス、セキュリティ、プライバシーといった、時間がかかり手続きが複雑な作業をDevOpsチームが的確に扱えると示せることです。製品やサービスの開発・運用ライフサイクル全体で科学的かつ具体的な証拠を作り、テスト自動化とテレメトリを利用します。たとえば、地理的に分散しているオンプレミスのデータベースサーバーからクラウドにデータを移行しつつ、単一の信頼できる情報源が、法令、業界基準、地域および国際的な規則に引き続き準拠していることを確かめる取り組みです。

顧客接点システムを選ぶと、短いデリバリーサイクルで、どれほど速く確実に革新を生み出せるかを示せます。今日、事業の成功につながる目に見える革新の多くは、顧客接点システムから生まれています。たとえば、ECサイトの購入手続きをより直感的でシンプルにして、売上を25%伸ばすケースです。達成すれば、経営陣はDevOpsだけでなく、あなた自身も高く評価してくれるでしょう。

DevOps変革を成功に導く進め方

DevOpsを始めるときは、保守的なチームを説得することに時間を費やさず、DevOpsの方法論と原則が必要だと考えるチームの中から、最も革新的で、新しい考えに柔軟で、人脈が広く、影響力のあるチームを見つけます。1～2チームで小さく始めます。ここまでの助言を参考に、最も適切なグリーンフィールドまたはブラウンフィールドの製品やサービスと、記録管理システムまたは顧客接点システムを選びます。

最初の成功事例ができると、参加したチームがDevOpsを組織全体に広げる最大の支援者になります。協力の輪を他のグループに広げ、成功事例を増やしましょう。こうした実績が、DevOpsの取り組みに対する周囲の納得感と信頼を高めます。測定できる効果が見えてくれば、経営陣からも、より多くの支持、後援、関心が得られます。

最後の段階では、影響力を使って取り組みを妨げる人や、強く反対する人（Curmudgeons）を見極めます。リスクや不安を周囲に伝えるという、彼ら自身の手法で対抗できるかもしれません。DevOpsを学び、使うことを拒めば、そのチームと製品がどれだけ見劣りし、組織で最後に残る弱点になるかを説明します。

まとめ

組織のIT変革を進めることは簡単ではありません。DevOpsも同じです。ただし、小さく始めれば、大きなリスクは避けられます。経験の浅いリーダーでもベテランでも、事業の成果を高めるためにチームを動機づけ、行動に導くこと、そして仕事で最も大きな充実感を得るために、見通しを立てたうえでリスクを取ることは、最も重要な務めの一つです。