DevOpsを始めるためのステップバイステップガイド
前回の記事で、なぜDevOpsがデジタルトランスフォーメーションにおける稼ぎ頭であるのかについて既に述べました。DevOpsを始めようと考えた場合、このプロジェクトに対処するための構造化されたアプローチが必要です。そしてここでは、DevOpsを始めるためのステップバイステップのガイドを提供します。
ほとんどの企業には、ソフトウェア開発ライフサイクルや、IT運用を理解している強力で経験豊富なソフトウェア開発者やシステム管理者のチームがありますが、それでも、この真新しい出発をどのように進めるかについて、アドバイスが必要です。
このガイドラインは、開発者が大規模で複雑なプロジェクトに取り組む際によく使う、問題の定義、計画、構築、解決策の確認、解決策の修正という構造化されたアプローチに基づいています。DevOpsを始めるには、計画からツールの選択、自動化、プロジェクトのテスト、そして継続的な学習機会まで、7つの重要なステップがあります。
1. DevOpsのロードマップを作成する
DevOpsを導入する最初のステップは、変革のロードマップを作成することです。この計画では、DevOpsをどのように始めるかを段階的な形式で示す必要があります。このロードマップの目的は、組織が前もって作業の準備を行えるようにすることです。
ロードマップと関連文書は、関係者やチームメンバーがコンテンツにアクセスできる一箇所に公開する。例えば、Microsoft PowerPointやGoogle Slidesをロードマップの文書化に使用することができます。これらのスライドは、後で会社のコラボレーションプラットフォームで公開することができます。
プレゼンターがいなくてもロードマップが理解できるように、十分な情報がすでに盛り込まれていることを確認してください。利害関係者は、ロードマップを閲覧し、プロジェクト提供プロセスにおける自分の役割について質問することができます。ITチームが変更を加える際、彼らは移行の次のステップを見ることができます。誰でも経路について質問し、フィードバックすることができます。守秘義務や秘密がないため、噂を鎮めることができます。
DevOps移行ロードマップは、一過性のプロジェクトではありません。ビジネスリーダーとして、ビジネスの旅が進むにつれて内容を更新する準備をする必要があります。
2. DevOpsツールチェインの選択
自動化ソフトウェアやリポジトリ管理の営業担当者が何を言っても、DevOpsは買えません。DevOpsはテクノロジーだけの問題ではありませんが、DevOpsを始めるには正しいツールチェーンを選択することが重要です。開発者の要求や要件だけでなく、統合や技術スタックを考慮したツール選定が重要です。
また、DevOpsツールチェーンの選択と構成には、ライセンスとセキュリティの演習が必要です。クラウドベースのツールチェーンの場合、組織は、すべてのクラウドサービスプロバイダとツールチェーンプロバイダにわたって、支出と通貨の分散モデルを作成する必要があります。DevOpsツールチェーンは、MitM（中間者）攻撃や類似の攻撃のベクトルになる可能性があります。新しいツールチェーンの検証・展開フェーズでセキュリティチームに参加する。
ITサービスプロバイダがDevOpsツールチェーンを選択する際に、社内チームが潜在的な専門サービス企業やツールプロバイダと協力し、トレーニングを経てデリバリー要件を満たす適切なツールを組み合わせて導入し、その後管理可能な最初のプロジェクトを実施するというパイロットプロジェクトの手法を取るべきです。
3. 文化変革ツールや戦略の導入
ある種の開発者の性格には、現状にある程度安住しているところがあります。DevOpsは、開発者が配信プロセスで力を発揮することで、一部の組織的・政治的な権力構造を壊す可能性があります。これらの課題に対処するには、最も大きな変化を経験するビジネスの分野で、文化的な変化を促すツールと戦略を展開します。
DevOps文化のためのツールを展開するために、次の5つのステップを紹介します。
- 開発、運用、セキュリティの各チーム向けに新しいDevOpsツールチェインを開設する。
- 開発チームと運用チームを対象としたDevOpsトレーニングワークショップで、新しいツールチェーンを使用するために必要なスキルについて学習させる。
- 開発者、運用、QA、およびワークフローセキュリティチーム間のコラボレーション戦略を把握し、定義する。
- IT部門以外の社員が、開発との新しい関わり方や製品開発への新しい期待を学べるように、ステークホルダーやビジネスユニットをDevOpsのコンセプトについて教育する。
- すべてのDevOpsプロセスを示す社内プロセス文書を作成する。これらの文書を中央リポジトリに公開し、簡単に更新できるようにします（Wikiが良いプラットフォームです）。
4. プロセスの自動化
一部の企業環境では、自動化の見通しを立てることが困難な場合があります。この恐怖を取り除くために、DevOpsの自動化に対する透明性のあるステップバイステップのアプローチを検討しましょう。
優先順位に基づいた自動化の目標を設定する。すべてのプロセスを一度に自動化することは、すべての組織にとって現実的ではないし、実行可能でもない。たとえば、自動テストを開始する場合、まずソフトウェアのテストに注力し、次にセキュリティテストに注力する。自動テストは人間のテスト担当者の専門知識に取って代わることはできませんが、段階的なアプローチにより、組織は自動化によって従業員の能力をどのように向上させることができるかを示すことができます。
このアプローチにより、IT管理者は、タスクの自動化による変化を実感できるチームと直接仕事をすることができます。この機会を利用して、ビジネス上の理由を説明し、自分の仕事を自動化に合わせることができます。
5. データと分析に注力する
最新のDevOpsツールは、ITチームがツールチェーンの中で実用的なデータをマイニングすることを可能にします。データのマイニングは、ITチームがステークホルダーや部門とコミュニケーションをとる方法を変えるため、DevOpsの成功に不可欠です。
プロジェクトマネージャが管理レポートを手動で作成する必要がないように、利害関係者向けにダッシュボードのレポートを設定する。ダッシュボードについて、また、取得したデータについてDevOpsチームにフィードバックを提供する方法について、利害関係者に周知する。「ダッシュボードが先、質問は後」という考え方は、特に管理職において、文化的な調整が必要かもしれません。
6. パイロットプロジェクトの実施
DevOpsのパイロットプロジェクトでは、チームやステークホルダーが新しいツールやプロセスを持ち込んで、小規模なプロジェクトから始めることができます。一般的な考え方は、クライアントが関与しない内部プロジェクトを選択することで、問題が発生した場合のリスクを最小化することです。プロジェクトに意欲的でお金を出すクライアントは、チームやプロジェクトにおける自分の割合を増やすことができる。一方、プロジェクトの一環としてクライアントとのコラボレーションを利用することで、DevOpsチームは外部の人間から客観的なフィードバックを得ることができます。
7. 学習と継続的な改善のための準備
DevOpsを開始するプロセスには、従来の最終ステップは存在しません。ソフトウェアが継続的な統合/配布プロセスに従うように、DevOpsのツールやプロセスも同様です。時間の経過とともに、チームはより良い方法についての教訓を学ぶことになります。これらの教訓は、組織戦略に立ち戻る必要があります。新入社員は、過去の雇用主やプロジェクトからの新しい視点や経験をもたらします。確かに、チームは彼らの知識と専門知識の一部をDevOpsのフレームワークに持ち込みたいと思うでしょう。
サイドノート
DevOpsは、あらゆるIT部門の効率と生産性を大幅に向上させることができるため、今すぐDevOpsプロジェクトを開始することが不可欠です。ベトナムのトップオフショアソフトウェア開発会社である当社は、新しい作業文化をもたらし、社内の作業効率を向上させることができるDevOpsコンサルティングサービスを提供しています。
