DevOps 文化を受け入れる
 開発チームと運用チームがコラボレーション、共同責任、所有権について同じマインドセットを持って共同作業することによって、システム設計とプロセスを継続的に向上させていくことができるようにします。 |
|---|
DevOps とは、多様な観点とスキルを持つ人々が共に 1 つのミッションに向かって進む実践共同体です。 チームは、サイロ化された学習ではなく、知識の共有による協力的な環境を育成する必要があります。 共有される機能を使用して、リソース制約の克服を目指します。
優れた DevOps 文化は、共同責任に基づいて発展します。 開発チームと運用チームそれぞれのゴールと優先事項を顧客の期待にそろえるともに、ビジネスの焦点を常に念頭に置く必要があります。 開発チームはフィードバック ループに運用チームを関与させる必要があります。これで改善がアップストリームで推進され、他のチームも同様にメリットを得られます。 逆に、運用チームには開発チームのビジネス成果を実現させるという責任があり、そのためにワークロードに関連するリソースとフィードバックを共有します。
同時に、DevOps のプラクティスでは、各チームに明確な所有権と説明責任が適用されます。 アプリケーションがどこで実行されるかにかかわらず、ワークロード チームはそのアプリケーションに対する責任を負います。
DevOps によって、運用タスクは効果的でありながら負担を抑えるように最適化されます。 DevOps のメリットを最大限に得るには、テクノロジを通じてプロセスを最適化するとともに、組織内の人々のために透明性のあるコミュニケーションを促進するプロセスを制定する必要があります。
サンプル シナリオ
Contoso の人事 (HR) 部門は、部門内で使用する新しい基幹業務 (LOB) アプリの開発プロジェクトを始めようとしています。 このアプリは現在計画段階であり、設計や実装の作業はまだ開始していません。
共同作業を効率的に行う
コミュニケーションと進捗追跡のためのコラボレーション型環境を促進できる、共通のシステムとツールを使用します。
共通のツールとプロセスにより、透過的なコミュニケーションが可能になります。 開発チームと運用チームの両方にとって、さまざまな環境、共通のサポートの問題、および全体的な課題と成功のすべてにわたって状況を認識できることは有益です。
インシデントが発生した場合でも、各チームは既存のエスカレーション パスをよく理解している状態になっています。
バックログが共有されるので、優先事項 (新機能の作業やバグの修正など) が明確になります。
Contoso の課題
- Contoso の新しいアプリの開発と保守には、開発、テスト、運用の 3 つの技術チームが関与することになっています。 現時点では、コミュニケーションとプロジェクト追跡のためにこれらのチーム全体で一貫して使用される標準的なツールはありません。
- これまでは、各チームが好みのツールを選ぶことが可能でした。 内部のメッセージングには、あるチームは Slack を使い、他のチームは Microsoft Teams を使っています。 タスクの追跡には、あるチームは Azure DevOps (ADO) を使い、他のチームは Excel を使っています。また、チームはそれぞれ別のドキュメント リポジトリを使用して知識とインシデント対応手順を共有しています。
- 過去のプロジェクトでは、この技術組織全体のコミュニケーションとコラボレーションは簡単ではありませんでしたが、それは使用されるツールがばらばらであることが原因です。 Contoso 人事部門は、今後は生産性を向上させて、過去に遭遇したようなプロジェクトの進行を遅らせる状況を回避したいと考えています。
アプローチの適用と結果
- 技術チームそれぞれのリーダーとプロジェクト スポンサーとのミーティングを行い、今後使用する標準ツールを選択します。 このグループは、ADO を使用してバックログ、コード リポジトリ、デプロイ パイプラインを管理することを選択しました。 また、Microsoft Teams をコミュニケーションとコラボレーションに使用することを選択しました。
- 共通のツール セットを使用することによって、開発、運用、テストのチームが常に、さまざまな環境の状態、共通のプロジェクトの問題、チームの実績に関する情報を把握して足並みをそろえることができます。 さらに、インシデントに備えて確立されたエスカレーション パスに関する情報に、各チームが 1 つの既知の場所からアクセスできます。
- 共有バックログも、優先事項 (新機能の開発やバグの修正など) について画一的に計画を立てて協調を保つのに役立ちます。
継続的改善を受け入れる
開発サイクル全体にわたる、継続的な学習と実験のマインドセットを構築します。 チーム横断の知識共有をサポートするとともに、ドキュメントを再利用できるように保守します。 また、非難なき分析を実施し、リリース後やインシデント後のレビューの報告を受けます。
A/B テストや概念実証の開発などの実験メカニズムを通じて、コストを低く抑えながらイノベーションを促進することができます。
コラボレーションを通して知識を共有することによって、設計アプローチ、ツール、プロセスにおけるチームの能力を高めることができます。
プロジェクトの後に振り返りを行うことは、改善が可能な領域を特定するとともに成功をたたえるのに役立ちます。
Contoso の課題
- 情報共有をさらに容易にするとともに、コラボレーションと透明性の文化を促進するために、チームはプロジェクト ドキュメントのための情報源を一元化して簡単にアクセスできるようにしたいと考えています。 これは特に、チームに新たに参加した開発者が短期間でプロジェクトの他のメンバーに追いつけるようにしたい場合に役立ちます。
- Contoso 人事部門が特に関心を寄せているのは、アプリケーションの可用性に影響を与えるインシデントからの学びを確実に捕捉して技術組織全体で共有することです。その目的は、将来のインシデントに役立てることであり、再発を可能な限り防ぐことです。
- アプリケーションのユーザー エクスペリエンス設計における過去の誤りの繰り返しを防ぐために、チームは実際のユーザー フィードバックを考慮に入れることができる、よりアジャイルなアプローチの使用も希望しています。
アプローチの適用と結果
- チームは知識共有 Wiki を ADO で構築しています。ここにすべての設計仕様が投稿され、併せてアクティブな運用手順、インシデント対応計画、振り返りの成果もすべて投稿されます。
- 非難なき振り返り (レトロスペクティブ) をインシデントの後と開発イテレーションのたびに行い、その学びを Wiki で文書化することは、プロジェクト チームが改善可能な領域を特定するとともに成功をたたえるのに役立ちます。
- チームは探索的アプローチを新しいアプリケーションのユーザー エクスペリエンス設計に取り入れています。その中では、UX コンサルタントから提案されたさまざまなバリエーションから最良のユーザー エクスペリエンスを見つけるために A/B テストが利用されており、ユーザー フィードバックを考慮してデータに基づく意思決定が行われています。
開発と運用の手順を体系化する
開発と運用の手順すべてについて標準を設定し、定期的にレビューして有効であることを確認します。 この手順に含まれるものとしては、定型的タスク、帯域外プロセス、緊急事態訓練と状況、ツールの選択、監視手順、スキル向上計画などがあり、さらには利害関係者とのコミュニケーションや顧客への情報開示も含まれます。 意図的かつ明確な意思決定を心がけます。
標準を設定しておくと、運用の予測可能性が高まるとともに、プロセスとプラクティスがスケーラブルになります。 標準が有効であることの確認は、改善点を引き出すための優れた方法です。
定期的な訓練を実施すると、緊急事態発生と復旧の状況に備えることができます。
正確に実行し、ガバナンスを可能にすることによって、リスクにつながる異常を防ぎます。
Contoso の課題
- これまで開発チームの生産性とアウトプットの質に影響を与えてきた課題の 1 つが、コードベースにおける標準化と一貫性の欠如です。 たとえば、名前付け規則が統一されていないときや、共通のソフトウェア パターンが使用されていないときは、チーム メンバーが互いのコードを理解しにくくなり、効率に影響を与えます。
- また、運用に対する共通のアプローチが適切に文書化されていない場合は、達成したい目標が同じでも運用スタッフごとに異なる方法が使用される可能性があり、このことは非効率性と混乱につながります。
- これまでに実施した DevOps における他の改善の成功が動機となって、Contoso 人事部門はこの問題に、次の開発サイクルの中で取り組むことを決定しました。
アプローチの適用と結果
- 開発チームは開発サイクルの期間中に集まって、一連の開発標準を実施することに合意します。 選択された内容を文書化して、その使用をコード レビュー時に、およびツールを通して強制します。 注目しているトピックは、次のようなものです。コードの書式設定と名前付け規則、エラー処理、バージョン管理、セキュリティ プラクティス。 チームは、ADO で生成される品質メトリックとレポートを注視して、これらの変更が品質と生産性に与える影響を定量化する予定です。その目的は、この種類の DevOps 改善の価値を経営チームに対して証明できるようにすることです。
- 同様に、運用チームはそれと同じ期間中に時間を確保して定型的な管理とトラブルシューティングの実践方法に関する既存のドキュメントを拡張し、Wiki で公開します。 今後は、この Wiki が "信頼できる唯一の情報源" となるため、情報の検索に費やされる時間とエネルギーを節約できます。