【資料公開】サイバーエージェント新卒エンジニア研修でDevOpsについて話してきました
はじめまして。CyberZでSREをしている藤井です。普段はEKSの運用やキャパシティプランニング、サービス開発などに取り組んでいます。その一環でDevOpsの推進、啓蒙などにも努めているのですが、ありがたいことに2023年度の新卒エンジニア研修でDevOpsについて話す機会をいただきました。少し時間が経ってしまいましたが、その資料を一部修正して公開いたします。この記事では、発表内容の簡単な解説をできればと思います。
スライド全文はこちら
https://speakerdeck.com/toro_ponz/xin-zu-xiang-ke-nantonakudemozhi-tuteoitehosiidevops
はじめに: ゴールについて
ひとくちにDevOpsと言ってもその扱う領域は狭くなく、業務開発経験の少ない新卒の方にいきなり触れてもらうには難しいものもあると思います。そのため今回は「なんとなくでも知っておいてほしいDevOps」と題し、DevOpsとは一体何なのか、また何ではないのか、という概要を知ってもらうことを30分の発表のゴールとしました。その上で、具体的な取り組みをいくつか挙げ、イメージを膨らませられれば万々歳かなという次第です。
よりゴールをわかりやすくするため、DevOpsをひとことで表してみます。ここでは「チームのサイロ化を取り除いたりして、素早いソフトウェア開発を行う方法論」と定めてみました。今回はこの一文が意味する内容を、なんとなくでもわかったつもりになってもらうことが目的です。
サイロ化について
では、先ほどの一文の意味を順を追って考えていきましょう。まずは「サイロ化」についてです。
一定以上の開発規模の組織では、例えばチームが分割され情報の孤立や連携の低下などが発生します。これをサイロと言い、サイロ化によって開発速度の低下などに繋がることが往々にしてあります。新卒の方に理解してもらうため、研修中にありそうなケーススタディを交えこれを解説しました。
ケーススタディとしては二つ、①雑すぎるデプロイによるデグレと、②主担当でない人の無知識かつ無鉄砲なリソース操作による障害を挙げました。研修では各チームにインフラ環境が提供され、チーム内である程度好きに操作、デプロイができる形のため、こういったこともあるだろうという推測です。
とはいえ、そんな雑なことは実際のプロダクト開発の本番環境では許されません。では実際の組織はどのようにこれらの問題を解決しているでしょうか。
ここでは、説明のためそれぞれQAチームおよび運用チームが発足し、上記の事象が発生しづらいようになったこととしました。開発組織が大きくなるにつれ、こういった再編が行われることは少なくないと思います。
再編の結果、それぞれのチームが自らの役割に集中して、品質が安定しました。
とはいえ物事には往々にして二面性があります。チーム内の業務が円滑に進んでも、チーム間連携がうまくいかなくなることがあるでしょう。それは例えば、各チームが別々の目標をおきそれに集中しているからこそ課題になったりする訳です。システムの安定性を目標にする運用チームが、頻繁なリリースを好ましく思わないことは想像に難くないでしょう。
こういった、チーム間のやりとりがうまくいかず、情報の孤立が発生することをサイロ化と言います。サイロによって開発速度が低下してしまいます。
品質とサイロはトレードオフ？
サイロ化が好ましくないことはわかりました。ただ、サイロがないに越したことはありませんが、品質を安定させるためにチームを分けたのですから、品質の担保とサイロ化は一見トレードオフのように感じられます。
しかし、実際にはそうではない場合も多いです。サイロ化が発生すると開発速度が落ちるので、「品質と開発速度はトレードオフか」という命題に置き換えて考えてみます。
例えば、みなさんご存じのGitHubでは毎日20回以上のデプロイを行っているそうです。しかし不具合が頻繁に発生したり、障害が絶えないイメージはないですよね。
参考: https://www.publickey1.jp/blog/23/github200railsrailsruby.html
（DORAの研究結果など詳細な解説は省きますが）品質と開発速度は必ずしもトレードオフの関係ではなく、両立することが可能そうです。
なぜDevOpsをする必要があるか
品質と開発速度が両立できそうなことはわかりましたが、そもそもなぜ開発速度を上げる必要があるのでしょうか？
エンジニアにとって開発速度が上がると言うことは、ただ単純に働きやすく（開発がしやすく）なる、という風に捉えられがちです。
しかし実際にはそれだけではなく、開発速度が遅い組織（ローパフォーマー）に比べて、開発速度が早い組織（ハイパフォーマー）には市場競争力、具体的には株価や市場シェアなどにおける優位性が認められるという研究結果があります。開発速度の指標には、「リードタイム」、「デプロイ頻度」、「障害復旧時間」、「変更障害率」の四つがあり、毎日何度もデプロイする（できる）組織が、高い競争力を持つことにつながる、と言った内容です。
詳しい内容については『LeanとDevOpsの科学』などの書籍に任せることとしますが、テクノロジーを扱う我々のような企業にとっては、開発速度が市場競争力に直結すると言っても過言ではありません。
ここまでのまとめです。誤解を恐れずに表現するなら、下記のようになります。DevOpsの思想は不具合や障害をゼロにするというものではないので注意してください。仮に100%の可用性が求められるような重要な基幹システムであれば、DevOpsはマッチしない考え方だと言えるでしょう。とはいえ、世の中の多くのサービスはそうではないでしょう。だからこそ注目されている、という訳です。
DevOpsをなぜ実践する必要があるかはこれでご理解いただけたかなと思います。
本題: DevOpsとは
では実際どうすれば良いでしょうか。それこそがDevOpsであり、DevOpsによって品質と開発速度を両立することができます。いえ、品質と開発速度を両立するための手法をDevOpsという名を付け括った、というほうが適切でしょうか。具体的な特定のソリューションに対して「これがDevOpsだ」というものではありません。
DevOpsと言うと、「XXXというツールを使ったモダンな開発フローを構築すること」のように捉える人も多いかもしれません。しかしDevOpsはあくまで「方法論」です。ツール（技術）を駆使するのはあくまでその実現方法の一つでしかありません。
DevOpsにおいては文化を形成することが最も大事だと言われます。この記事を通してDevOpsが何たるかを知ってもらうこともその一環です。その後、プロセス（組織での仕事の進め方）を整備します。そしてそのプロセスを円滑に進めるための技術（ツール）を採用し実現し、開発体験の向上（品質と開発速度の両立）を図る。その結果プロダクトが良くなる。そういう方法論がDevOpsなのです。手法にとらわれず、DevOpsが解決したいことに目を向ける必要があります。
具体的なDevOps的施策
ここまでで、DevOpsと言われる掴みどころのない言葉が一体何なのか、何を解決するものなのか、そして何ではないのかがなんとなくわかったと思います。
以降は一般的にDevOpsと関連して紹介されることがある、具体的かつ代表的な施策を、技術、プロセス、文化、計測のカテゴリでそれぞれ列挙します。もちろんここに挙げたこと以外にもその手法は多岐にわたります。組織の数だけそれぞれのDevOps施策があるはずです。
まずは技術についてです。一つ目はトランクベース開発です。頻繁なデプロイにより適したブランチ運用方式を採ることで、煩雑なGit運用に奪われる時間を減らすことに期待ができます。
参考: https://dora.dev/devops-capabilities/technical/trunk-based-development/
二つ目はフィーチャーフラグです。外部データソースなどによって動作を変えるように実装することで、まだ未完成のコードに処理が到達しないようにできたりします。こうすることで大きな機能でも細かく分けて開発することができたり、デプロイと機能公開のタイミングを分離することができたりするメリットが得られます。また、トランクベース開発との相性が良く、両者を合わせて採用している組織も多いと思います。
三つ目は、CI/CDです。モダンな開発に触れている人にとっては当たり前のように感じるかもしれません。しかし日に何回もデプロイすることになると、例えばリリースの動作確認を手動でしているところですら煩雑になってきます。突き詰めればどこまでもできることですが、開発、リリース、フィードバックのサイクルを素早く回すためには、自動化への飽くなき探求心が必要です。Progressive Deliveryによる自動ロールバックなどまで実現できると理想かもしれません。
最近では、Kubernetesをはじめとするコンテナ技術によるCDは知らないとは言えないレベルになってきています。頻繁なソフトウェアデリバリには、テストと同様自動化での効率化が必要不可欠です。
四つ目は、IaCやGitOpsといったコード化です。アプリケーションのデプロイのみならず、クラウドなどインフラ構成に至るまでコード化することで、安定したチェンジマネジメントを実現することができます。
五つ目はプロセス、A/Bテストです。闇雲に機能やサービスを開発するだけでは価値があるとは言えません。狙いがありそれが正しくユーザーに提供できているか計測し、また次の開発に生かすループを回すことが重要です。
六つ目はQAや運用チームの関わり方についてです。完全に分断して仕事をするのではなく、開発チームと密に連携することでより効率的に開発できると言われています。
そして七つ目、文化についてです。DevOpsについて啓蒙し、なぜする必要があるのかなどをしっかり周りに理解してもらうことが肝要です。人の協力なくして文化の醸成は成し得ません。もしみなさんの組織でDevOpsをしようと動き出したいなら、まず周りの人にその意義や目的を啓蒙していくことから始めましょう。
最後に計測です。FourKeysと言われる、開発速度（ひいては組織の市場競争力）を測る指標として挙げられる四つのメトリクスがあります。これらを計測することで、DevOps的取り組みがどれほど価値を生んでいるか、可視化できる可能性があります。
（実際にはこれをするだけでは何も意味をなさないので、FourKeysを計測することを目的とせず、可視化したデータをどう生かすかを考えることが重要です。）
上記の施策はあくまで一例です。全ての組織に合致するものでなければ、それをしなければダメだというものでもありません。組織やチームの状態にあわせて、取捨選択をして改善していくことが、DevOpsを実践していく上で最も大切なことになります。
まとめ
最初に決めたゴールの通り、DevOpsがどういったものかなんとなく理解できれば幸いです。実際には様々な取り組みがあり、その実現方法も組織によって異なります。ここで解説した理想論だけでうまくいくようなものではなく、その道のりは長く険しいですが、この記事がみなさんの一助になれば幸いです。
この記事が気に入ったらサポートをしてみませんか？