DevOpsのライブ講座や認定プログラムの準備コースでは、いつも決まって寄せられる質問があります。今日は、その質問に答えるために短い記事を書きました。「DevOpsとScrumの違いは何ですか」という質問です。「DevOpsとScrumの比較」とも言えます。
International DevOps Certification Academy™の知見
DevOpsとスクラムの主な6つの違いとは？（DevOpsとスクラムの比較）
今日は、主な違いを6つ取り上げます。さっそく見ていきましょう。
違い1 DevOpsでは、各反復（スプリント）の終わりにコードを本番環境へデプロイします。Scrumでは、各反復の終わりに出荷可能なコードを用意することを目指します。
これはScrumの主な弱点の一つで、多くの組織でScrumが失敗する、最大級の理由です。反復の終わりにコードをデプロイしないと、通常はステージングサーバーに置くか、さらに悪ければバージョン管理システム（CVS）に眠らせたままにします。ソフトウェアエンジニアリングをほとんど知らないプロジェクトディレクターが、本番に移す時期を決めるまで待つのです。6か月に一度しか本番デプロイをしない大手銀行や通信会社を知っています。冗談のようですが、本当です。 こうした一斉デプロイの代償は、本番システムでの最優先かつ最重大のインシデントの多発、従業員の士気の低下、履歴書を更新する従業員の増加です。失敗を正当化するために責任を押し付ける相手を探す、技術の知識がない人々の非難や社内政治の争いまでは、ここでは触れていません。
違い2 DevOpsでは、継続的なソフトウェアデリバリーの前提であるテスト自動化と継続的インテグレーションが、ソフトウェア開発に組み込まれています。Scrumでは、デリバリーは後から考えるものになり、開発にまったく携わらない人が計画し、運用することになります。
これもScrumの最も重大な弱点の一つです。Scrumのプロセス自体は、デリバリーの実践にほとんど、あるいはまったく貢献しません。DevOpsでは、チームがワンクリックで本番デプロイできる、デリバリーパイプライン、テスト自動化、本番アーキテクチャが欠かせません。 Scrumのソフトウェアデリバリーの考え方は1986年にさかのぼります。Hirotaka TakeuchiとIkujiro Nonakaが、Harvard Business Reviewの記事「New Product Development Game」で初めて紹介しました。Scrumの登場から30年以上が過ぎ、ソフトウェアデリバリーの進め方は大きく改善されました。 今は、Scrumが答えを出してこなかった問いに、DevOpsで答えられます。
違い3 DevOpsのプロジェクトは、組織に事業価値を生む製品とサービスを軸に進みます。Scrumは、事業成果に貢献するための成熟度を備えていません。
DevOpsでは、エンジニアリングチームを、自ら判断して仕事を完遂し、顧客に役立つ稼働中の製品やサービスを届け、組織に収益をもたらす単位と捉えます。 残念ながら、Scrumはメンバーに事業上の成熟について教えません。デイリースタンドアップを部屋で座って行ってはいけないといった、Scrumの「疑ってはいけない」儀式がよさそうに見えたとしても、 十分な訓練を受け、高い報酬を得ているエンジニアが幼稚園児のように振る舞い、スクラムマスターが幼稚園の先生のように振る舞うのは、Scrumがエンジニアにプロとして成長する方法を教えないからです。 DevOpsでは、経験や知識の水準を問わず、エンジニアリング組織の全員がプロとして事業価値を生み出します。デイリースタンドアップで座ってよいかといった、ばかげたことを無意味に議論する必要はありません。 DevOpsでは、事業の収益を伸ばすために、最善のソフトウェアソリューションを見つけ、磨くことに、チームで考える力を使います。
違い4 DevOpsでは、チームの全エンジニアがサービス品質、ソフトウェア品質、運用の水準に関心を持ちます。Scrumでは、品質保証と運用は他の人の仕事になります。
多くのScrumチームでは、ソフトウェアの品質保証は外部のテスト担当者だけが行い、デプロイと運用はシステム管理者が担当します。 Scrumチームがデリバリーの品質や、ソフトウェアが本番でたどる実際の経過と切り離されていることも、Scrumを採用した多くの組織が苦労する主な理由の一つです。 DevOpsでは、品質保証はソフトウェアエンジニアリング組織全員の責任です。優れたフルスタックエンジニアは、構想段階からライフサイクルの終わりまで、デリバリー、セキュリティ、安定性、性能、保守性、運用性、その他すべての非機能面に気を配ります。 ソフトウェアの開発、品質保証、運用に必要なスキルを一つにまとめたDevOpsチームは、成果を出せる体制を持ち、組織に優れた事業成果をもたらします。
違い5 DevOpsは、品質と継続的なデリバリーを可能にするソフトウェアアーキテクチャの設計に役立ちます。Scrumには、適切なアーキテクチャでソフトウェアを作るための支援がありません。
Scrumは、エンジニアリングチームが適切なアーキテクチャの方向性やビジョンを定めるための支援や指針を提供しません。Hirotaka TakeuchiとIkujiro NonakaがScrumを紹介してから、30年以上が経っていることを思い出してください。 DevOpsでは、アーキテクチャ内の製品、サービス、マイクロサービスAPIは疎結合にします。各チームが担当するのは、疎結合なアーキテクチャの一部分だけです。それぞれが独立してソフトウェアを設計、開発、デプロイできます。 デプロイメントパイプラインに組み込んだ早期警告の仕組みで、コードのチェックインが悪影響を及ぼす可能性を、自動ですばやくDevOpsチームに知らせます。
違い6 DevOpsは優れた事業成果を出すため、ソフトウェアエンジニアリング組織全体に焦点を当てます。Scrumが対象とするのはソフトウェア開発者だけです。
Scrumの対象は、5～9人の小規模な開発チームに限られます。Scrumの理論に聞けば、10人ではいけないと言うでしょう。理由はわかりません。 ソフトウェアエンジニアリングの範囲をこれほど狭く捉えるため、Scrumが組織に適さない場合が多くあります。 Scrumチームが価値を生み出すために、専門性のある組織の中でどのような位置を占めるべきかという課題に、Scrumは答えを示しません。 DevOpsでは、製品・サービス別チームを作ることを勧めます。独立し、職能横断的で、自律的に自己完結できる、通常は小規模なチームです。一時的なプロジェクトではなく、特定の製品やサービスを対象に、アーキテクチャの策定、設計、コーディング、テスト、実験、デプロイ、運用、保守まで、ソフトウェアエンジニアリングの全段階を担えます。そうです。ソフトウェアを作った人以上に、運用と保守をうまく行える人がいるでしょうか。もちろん、いません。 だからこそ、AmazonとNetflixで最も成功しているDevOpsチームが、リリース後も製品やサービスを手放さず、自分たちの本番システムで運用と保守を担うのは自然なことです。
これらの違いを読んで、DevOpsが次世代のアジャイルな働き方になりつつある理由が、はっきりしたはずです。
数年後には、DevOpsがScrumを包含する枠組みとして広く受け入れられるでしょう。 Google、Amazon、Facebook、Etsy、Netflixなど、多くの大規模組織がすでにDevOpsを採用しているからです。
間もなく、あらゆる場所に普及するでしょう。
International DevOps Certification Academy™が必要なものをすべて提供し、無理なくDevOpsを学び、DevOps認定試験に合格できるようにします。ご質問があれば、いつでも私とチームが対応します。
International DevOps Certification Academy™へ >>
追伸：少し率直にお話ししましょう。 今ではブログ記事を読む人が多くないことは承知しています。それでも、私たちは時間をかけて皆さんのために記事を書きます。ほんの数人でも記事を読み、一つか二つ学んでもらえたなら、世界のDevOpsコミュニティに役立つという使命を果たせたと考えるからです。
皆さんのためにこの記事を書いてお届けした私たちを、応援していただけたらうれしいです。 ここまでお読みになり、記事が役立ったと感じたら、 このページの下でレビューを投稿し、皆さんのネットワークで共有してください。
ご協力ありがとうございます！ :)
