今さら聞けない4つの開発手法。
アジャイル/スクラム/Devops/SREとは

正確性やスピード感など、情報システムやサービスの開発に求められるものは、時代によって変化します。一つひとつ要件を固めて手戻りのない開発を進めていくというスタイルだけではなく、開発とレビューを繰り返す手法や、エンジニアだけではなく運用担当者や保守担当者まで巻き込んだ手法など、開発スタイルも一様ではなくなってきています。

そこで今回は「アジャイル」「スクラム」「DevOps」「SRE」というキーワードを軸に、さまざまな開発スタイルについて解説しましょう。

2001年ころ「アジャイル」という開発手法が知られるようになって以来、さまざまな開発の概念・手法が登場していますが、それらの新しい開発手法とよく比較されるのが「ウォーター・フォールモデル」という、伝統的かつ代表的な開発スタイルです。このウォーター・フォールモデルの特徴は、その名の通り、水が上から落ちてくるように各開発プロセスを順番に進めていくことにあります。

1970年ごろにはその手法が確立されていたともいわれているウォーター・フォールモデルは、開発フェーズを

・要件定義
・概要設計
・詳細設計
・開発
・テスト
・運用

といった各工程にわけて直線的に結合し、前の工程のドキュメント作成などを完了してから次の工程に入る、といったスタイルで運用していきます。原則的に手前の工程で決めたことを尊重して、戻り作業を発生させないという考え方です。

逆の言い方をすれば、後戻りしないということは簡単には仕様変更をしないことで、要件定義の時点でシステムの全体像を決めることにもなります。その意味では、何かあった場合に融通が効きにくい開発スタイルともいえるでしょう。

そこで、このウォーターフォール型では対応が難しい開発が増えるにつれ、注目を集め始めたのが、アジャイルをはじめとした新しい開発スタイルです。

アジャイル
アジャイルは2001年以降に登場した開発手法で、機能ごとに計画からテストまで行う「イテレーション」というサイクルを繰り返しながら、全体の開発を進めていきます。ウォーターフォールに比べて、仕様で決めた実物をいち早く確認することもできます。
頻繁に仕様変更や機能追加が発生することが考えられるプロダクトの場合は、小さな単位ごとに作り込んで機能をリリースするアジャイルのやり方が向いています。

スクラム
スクラム開発はアジャイルの一手法で、その特徴は、優先順位の高いものから短い期間での開発を繰り返すという点にあります。チームのコミュニケーションをとても重視するという意味で、チームプレイが大切なラグビーの「スクラム」という用語を当てはめています。またソフトウェア開発だけでなく、チームで仕事を進めるための汎用的な枠組みとしての意味合いも持っています。
スクラム開発のチームは、ビジネス上の責任を持つ「プロダクトオーナー」、スクラムの運用をサポートする「スクラムマスター」、そしてプロダクトオーナーの要求を実装し作るべきものを作る「チーム」からなり、実際に開発を進めるにあたりポイントとなるのが以下の2点です。

・どのようなものを作る必要があるのかという、プロダクトの要望を優先順位で並べ替えてタスクを作成する「スプリント計画」
・1～4週間に区切られた「スプリント期間」と呼ばれる開発サイクルで開発

ここで重要なのは、メンバーそれぞれの情報をチームで共有し、プロジェクト全体の透明性を高めておくことです。

そして、プロジェクト全体の透明性を高めるための秘訣が「プロダクトバックログ」「スプリントバックログ」と呼ばれるものです。
プロダクトバックログはスプリント計画時に作られるもので、開発にあたって必要なものは何か、クライアントやユーザーに提供するべき価値とは何かなど、製品に必要な要素をまとめたもので、ここで優先順位や作業コストを検討します。これが全体の作業計画になります。
スプリントバックログは、開発・まとめ・レビュー・調整で構成される、スプリントごとに実現するべきことをまとめたもので、チームのタスクリストとも言えます。

進捗を共有するために、スプリント中は日次でミーティングを行い、前日の進捗、当日の予定、そして現時点の課題を共有し、チームとして滞りなく開発作業を進めていきます。

DevOps
DevOpsは開発（Development）と運用（Operations）の頭文字を取った言葉で、開発担当者と運用担当者が密接に連携し、要求に対して迅速かつ柔軟に対応できる仕組み作りをしようという考え方です。

開発チームと運用チームの衝突は珍しいことではありません。最近のシステム開発では小さな開発サイクルを繰り返すことが多いため、開発チームは常に改善や修正を繰り返すことに目が向きます。一方、運用チームにとっての最優先課題はシステムの安定稼働なので、システムに致命的な問題さえなければ手を入れたくないと運用チームが考えるのはごく自然なこと。その結果、相反する考えを持つ両者は衝突にいたるというわけですが、これは現在のシステム開発の現場にとって、大きな損失です。

そこで、開発チームと運用チームの両者が開発に関わることで衝突を避け、新たなシステムの要求から実装に至るまでの時間を短くすることがDevOpsが目指すものです。

DevOpsでは具体的な開発手法より情報の共有ツールやテストツール、自動化の仕組みなどがフォーカスされやすいものです。それらの個々のツールが大切なのはもちろんですが、最終的にはビジネスのスピードアップに対応できる組織と仕組みを作る、ボトルネックを把握するというところを意識することが肝心でしょう。

SRE
「Site Reliability Engineering」という言葉の頭文字を取ったSREは、Googleが提唱する、システム管理およびサービス運用に関する信頼性向上の動きのことで、信頼性をシステムの重要な機能の一つと位置づけています。「開発のスピードアップを求める」という目的は、先に紹介したDevOpsもSREも同じですが、その実現の一つとして、開発もできる運用部隊という存在にフォーカスを当てたのがSREです。

インフラエンジニアの概念は企業文化によって大きく異なります。一般的にはSREではサイト・サービスの信頼性を高めるために積極的にコードを記述したり、可能な限りシステムの自動化を行う、そして属人化させないためにドキュメントを整備したり情報を共有することなどが求められます。つまり、かなり「デキる」エンジニア像が求められることになるでしょう。

クラウドサービスの充実で、インフラエンジニアがハードウェア自体の安定性を特に気にする必要性は少なくなりました。ただしその分、これまでのインフラに関する技術だけでなくアプリケーションの開発技術も求められるようになっているというのが、SREが広がりつつある背景なのでしょう。

アジャイルという考え方が誕生してから、ソフトウェア・サービスの開発および運用の体制は進化を見せました。そしてクラウドの登場で自動化やハードウェア管理の省力化に拍車がかかり、エンジニアの時間の使い方は変貌をとげています。

今回ご紹介したキーワードに共通しているのは「スピードアップ」と「省力化」です。システムの仕様や要求の変更サイクルが細かくなればなるほど、開発・テストをいかに短時間に行うかがポイントになってきます。そして人間は、本来頭を使うべき仕様の策定や実装に、可能な限りの時間を割り当てたいものです。

SREにおいても、ハードウェアやインフラの準備や管理が省力化できることから、インフラエンジニアの視野はシステム全体に広げられるというわけです。

そして、このスピードアップと省力化に大きく寄与するのがクラウドサービスです。Azureはハードウェアやネットワークの高い可用性を持ちます。またソフトウェアの面でもWindows ServerもLinuxも活用でき、さまざまなOSSをサポートしています。さらに、それらの環境構築を簡単に行えるDockerなどのコンテナ技術もサポート対象となっています。

新たな開発スタイルを試みる際には、Azureのようなクラウドの活用は、もはや不可欠と言っても過言ではないでしょう。

スピードと柔軟性を兼ね備えた開発スタイルとして注目を集めている「DevOps」。そのDevOpsが、実はAzureと相性がよいことをご存知でしょうか。このホワイトペーパーでは、DevOpsの概要やメリット、さらにAzureを活用したDevOps導入のスムーズさ、拡張性についてわかりやすくご説明します。