あらためてDevOpsとは何かをまとめる④~DevOpsの導入~

こんにちは。ディベロップメントテクノロジーセンターの青山です。

DevOpsがどういうものか知らない方々へのDevOps紹介連載記事です。
これまで3回にわたってDevOpsについて紹介してきました。

今回はDevOpsを実際に導入していくにあたっての方法について紹介します。

DevOps導入のステップ

DevOpsは「プラクティス」「プロセス」「組織としての取り組み(文化)」を通して、ソフトウェアやサービスの迅速なリリースという目標を目指します。
しかし、いきなり全てを実践し目標を達成することは大変難しいです。

インターネット上には様々な事例が挙げられているため情報を入手できますが、それをそのまま実践できるかというとそうはいきません。
特に大規模・高度な事例では、そこまでの紆余曲折がありまた同時にそこに至るまでに大きな時間と投資をしてきているのが実態です。
これまでDevOpsに取り組んでこられなかった方々が、そのようなやり方をいきなり真似て良い成果を出すことは非常に困難です。

自身の組織・チームの状況に合わせて少しづつ進めていくことが必要となります。
そのため、私は以下のステップで実践することをお勧めしています。

  1. DevOpsプラットフォーム準備
  2. DevOpsの取り組みの拡張
  3. DevOpsの継続

各ステップで行うことを順番に説明していきます。

1.DevOpsプラットフォーム準備

まず始めに代表的なプラクティスである「構成管理」「CI/CD」「テスト自動化」を実施するためのDevOpsプラットフォームを準備することが必要です。(これらプラクティスの詳細については「あらためてDevOpsとは何かをまとめる②~DevOpsのプラクティス~」を参照ください)

ポイントは以下の通りです。

  • 「CI(継続的インテグレーション)」「CD(継続的デリバリー)」は課題が少なく導入が容易
  • 「CD(継続的デプロイ)」は課題が多いため導入すべきかは状況による
  • 「テスト自動化」は全てを自動化することは難しいため、最初はどこまで行うか見極めが必要
  • 可能であればDevOpsプラットフォームとして「クラウド」「コンテナ化」を活用する
  • 最初から「Infrastructure as Code」を利用してDevOpsプラットフォームを構築することが望ましい

2.DevOpsの取り組みの拡張

「構成管理」「CI/CD」「テスト自動化」以外の「プラクティス」に取り掛かり「プロセス」「文化」を変えていきます。
特にDevOpsの大事な取り組みであるチーム/組織のサイロ化解消を目指す必要があります。

ポイントは以下の通りです。

  • 「アジャイル開発」の導入は推奨
  • 「モニタリング/ロギング」を活用したチームの状態の可視化、およびそれをインプットとしたフィードバックサイクルの構築
  • 開発・運用チームのみならず、顧客・ベンダー間の情報共有および仕事の取組みを変えていく
  • 「変化を恐れない」「個人ではなくチームの成果最大化を目指す」など「文化」面での変化を軽視せず取り組んでいく

3.DevOpsの継続

先に述べました「1.DevOpsプラットフォーム準備」「2.DevOpsの取り組みの拡張」を継続していきます。

ポイントは以下の通りです。

  • 最初に導入した「プラクティス」「プロセス」をそのまま繰り返していることが継続ではない、継続している中で得られたフィードバックに基づいて「プラクティス」「プロセス」をよりよいものに改善してく必要がある
  • ビジネスの企画からリリースまでの状態の可視化、およびそれをインプットとしたフィードバックサイクルの構築

「市場にサービスをリリースする時間短縮/頻度向上」などは、この段階まで進むと実現可能となってきます。
ただ、ここまでDevOpsを進められている事例は希少だと思います。

DevOps導入事例

では実際にクレスコが関わってDevOpsを導入した事例をいくつか紹介していきたいと思います。

アジャイルとDevOpsを導入

金融系のお客様において、DX施策の一環として新しい顧客とのコミニュケーションパスを築く為の新規システムを構築した事例です。

プラットフォームとして、これまでのオンプレミスから新たにAWSを選定しました。また、開発手法としてアジャイル開発を選定し、新しい開発チームを編成しました。
AWS環境上には開発/本番環境を構築し、DevOpsプラットフォームを最初から準備しました

取り組みとしては「1.DevOpsプラットフォーム準備」「2.DevOpsの取り組みの拡張」を同時に行っています。

このような新規サービス/システムの構築時はしがらみが少ないため、DevOpsを導入しやすいので是非チャレンジ頂きたいケースです。
また、DX施策の一環としてアジャイル開発とセットで導入される事例も多いです。

一方で導入はしやすいのですが、取り組み内容が多く変化が大きいため、かなり試行錯誤することになります。
うまくいかないからと評価を下げて従来のやり方にすぐ戻さないように注意が必要です。

すぐにDevOpsの効用最大化には至りませんので「3.DevOpsの継続」を実践、根気よく評価を行いながら、フィードバックにもとづき改善して継続していくことが重要です。

DevOpsを部分的に導入

次は既に本番リリース済みの一般コンシューマ向けスマホサービスにDevOpsを導入した事例です。

本番環境と開発環境が同じAWSアカウントで構築されていたため、本番はそのままに開発環境を別AWSアカウントに切り出しその際にDevOpsの仕組みを導入しました。
開発環境で「1.DevOpsプラットフォーム準備」のみを実施しました。

既に本番リリース済みの環境を変更するのは大変なためDevOpsは導入できないかというと、そういうことはありません。
まずは、開発環境のDevOpsプラットフォーム導入でも以下の効果は得ることができます。

  • 人手を介したデプロイ・プロセス時間の改善
  • テスト自動化によるバグ早期検出率の改善

「本番リリースの仕組みを変える事がDevOpsだ」という硬直的な考え方に囚われない少しずつでも取り掛かっていくことが大事です。
ただ一方でボトムアップのアプローチであるため、よりDevOpsを深化させていくにあたっては時間がかかります。

おわりに

「CI(継続的インテグレーション)」「CD(継続的デリバリー)」などの「プラクティス」を導入してDevOpsを始めることはそれほど難しくないため、ぜひチャンスがあれば取り掛かってみてはいかがでしょうか?

ただDevOpsで「市場にサービスをリリースする時間短縮/頻度向上」まで目指すとなると実現はなかなか困難です。今回紹介しましたステップを踏んで少しづつ進めていくことが重要です。

サービス/システムやプロジェクト/組織の特性に応じてDevOpsへの取り組み方は異なりますので、一概にこれが良いとの方法論はありません。
そのため、DevOps効用最大化の状態はどういう状態か?何を目的とするか?は定義が必要です。
目的を見失わず、途中で止めず、継続していくことによりDevOpsを実践していけるかと思います。

そして、実際にDevOpsを始めてみたがいまくいかないなどお困りのことがあれば、弊社でもDevOpsの導入サポートを行っていますので是非ご相談ください。

これまで4回にわたってDevOpsについて説明してきました。
今回の記事で一旦一区切りなのですが、また何かテーマが見つかりましたら記事にしたいと考えています。
ありがとうございました!

  • このエントリーをはてなブックマークに追加