DevOps推進の第一歩！チームの「文化と行動」を変えるため私がまず取り組む5つのこと

この記事は「BEMA Lab Advent Calendar 2025」の16日目の記事です。
※本アドベントカレンダーの16日目の投稿となります。

はじめに 

みなさんこんにちは＾＾　
株式会社メンバーズ デブオプスリードカンパニーの小関です！

生成AI基盤チームにもいたので、チームメンバーが記事を書いているのはよく見ていたのですが、、、自分で書くのは初めてだと先ほど気付きました。
これからは少しずつ書いていこうと思います！

さて今回は、私がお客様への支援や自身のチームでDevOpsの推進をしていく中で、はじめにこの辺りの作業をしておくと後々スムーズだなと考えたことを、ご紹介していこうと思います。
IaC化、CI/CD構築などの技術的な話の前に、チームとして何から始めるべきか迷っている方の参考に。
あるいは、DevOpsを導入したものの、「なんか上手くいってない」と感じている方の振り返りポイントとしても、この記事がお役に立てれば幸いです。

DevOpsとは（個人的見解見込み）

開発（Development）と運用（Operations）の組み合わせによる造語がDevOpsです。
特定の開発手法を表す言葉ではなく、両チームが密に連携・協力して開発と運用を進めていく手法、文化のことを指します。

ここに私見を加えると、この開発に関わる開発者・運用者が各自のパフォーマンスを最大限に発揮しながら、楽しくいきいきと仕事ができるところまで含めたいと常々考えています。
それは、心理的安全性を高めつつ、それぞれが意見を出し合いながら全体最適を探っていき、エンドユーザーまで含めて価値のあるプロジェクトであること、その過程でチームも自身も成長できること。
そこまでできるといいですよね！私自身も日々目指しているところです。

私がDevOps推進時にまず取り組むこと5選

では、そのようなDevOpsを推進するにあたって、どのようなことに取り組んでいけば良いのでしょうか。
人によってプロジェクトやプロダクトの性質によって、様々な進め方があると思いますが、私の場合はこのような順で取り組んでいくと、下準備として良いのではないかと考えています。
そして、とても上手く回っているチーム・組織は、だいたいこのようなことがすでにできている状態であることが多いと感じます。

何から手を付ければいいか迷ってしまうという方は、まずはこのステップ1〜5の順に進めてみるのがおすすめです。
最初に「理想（ゴール）」を描き、次に「現在地（指標）」を把握し、その「ギャップ（課題）」を特定する……。この流れで進めることで、チーム全員が迷子にならず、納得感を持って最初の一歩を踏み出せるようになります。

ただし、これらは必ずしも「絶対の正解」ではありません。 DevOpsの本質は、チーム自らが改善し続けることにあります。すでに指標が決まっているならステップ3から始めてもいいですし、課題が明確ならステップ4のコミュニケーションから手を入れても構いません。

基本のステップを参考にしつつ、皆さんのチームの状況に合わせて、ぜひ「自分たちに最適な順番」にカスタマイズして試してみてくださいね！

ステップ1：チーム・プロジェクトの理想状態を具体的に考える
ステップ2：現在の状態を測る指標を考える
ステップ3：ボトルネックの課題を考える
ステップ4：コミュニケーションを設計する
ステップ5：良い点・改善点を言語化・見える化して共有する

ステップ1. どのような状態がこのチーム・プロジェクトにとって理想なのかを具体的に考える

まずは今後目指していく指針となる、理想状態を確認します。
実現できる範囲だけではなく、ずっと将来の話でも構いません。このチームにとって、この組織にとって、このプロジェクトにとって、どのような状態が一番良いかを具体的に考えます。

例えば、「属人化を排除する」ではまだ曖昧なので、「個々のタスクの進捗や問題点が担当者に聞かなくてもチーム全員が把握できる状態にする」「担当機能の仕様・設計について、担当者に確認しなくても資料の場所がわかる」「システムに問題が発生した時にどのような対応をとるべきかが担当者に聞かなくてもわかる」など、具体的に挙げていきましょう。
具体的な理想状態を挙げていくことで、より理想の状態がどういった状態なのか、想像しやすくなります。自ずと、これからやるべきことも見えてきます。

ひとりで考えるよりは、チーム全員の様々な視点から考えていくのが最適です。
ぜひ、理想や夢を語ってみましょう。

この際、出てきた案はそのままの文言で残しておき、後から見返せるようにしておくとベストです。
言い回しにはその人の想いが乗っています。
あとからそういう意味じゃなかったとなった際、どこで意味合いが変わってしまったのかを探るためにも使える材料になります。

ステップ2. 現在の状態を測る指標を考える

どのような組織にも、現状の評価をするための基準があると思います。
DevOpsのフレームワークで有名な「Four Keys」もその一つです。

Four Keysとは

Four Keysとは、Google社のDevOps Research and Assessment（DORA）チームが確立・発表した、開発チームのパフォーマンスを測るためのフレームワークです。(1)

以下の4つからなります。

• デプロイの頻度：組織による正常な本番環境へのリリースの頻度
• 変更のリードタイム：commit から本番環境稼働までの所要時間
• 変更障害率：デプロイが原因で本番環境で障害が発生する割合（%）
• サービス復元時間：組織が本番環境での障害から回復するのにかかる時間

DORAでは研究レポートを出しており、2024 DORA Report(2) では、これに加えて「変更時のやり直し率」を追加するなど、毎年見直しをかけながら進化しています。

（1）DevOps Four Keys：https://cloud.google.com/blog/ja/products/gcp/using-the-four-keys-to-measure-your-devops-performance（2）2024 DORA Report：https://dora.dev/research/2024/dora-report/2024-dora-accelerate-state-of-devops-report-ja.pdf

自チームにとって「本当に意味のある」指標を見つける

これらの指標は確かにパフォーマンス測定としては有益です。しかし、チームによっては合わない場合もあるでしょう。
例えばデプロイ頻度について。毎月または毎スプリントに1回本番デプロイするとリリーススケジュールが決まっている場合、デプロイの頻度は固定化されます。
その指標が変動することはルールが変わらない限りあり得ませんし、何か理由があって随時デプロイしていないのかもしれません。

このように、チームや組織、プロジェクトにより、有益で最適な指標はバラバラです。
自分たちのパフォーマンスを測る指標として適切な基準はどこにあるのか、ぜひ色々な担当職種の人たちで考えてみてください。できるだけ数値として測ることができるものが良いです。

もし思いつかなければ、考え得る最悪のケースを想像し、その際何ができていないか、何が問題になっているかの観点から考えてみることをおすすめします。
開発であれば、バグだらけでいっこうにリリースできない、リリース遅延、検証デプロイに長い時間がかかるため気軽に検証できない、等々。
運用であれば、頻繁にシステムが止まる、アプリケーションが常に重い、冗長化されていないので一部問題があって止まるとデータが損失する、等々。
考えるだけでも胃がキリキリしてきますね。。。
そこから、何ができていると嬉しいか、どこが速いと嬉しいかを考えてみると良いでしょう。

ちなみに見落とされがちなプロセスとしては、レビューがすぐ溜まってしまって遅いとか、決裁権者が忙しすぎて捕まらず、OKが出ないため始められないなど、開発でも運用でも発生するものや、チーム外の要因もあったりします。
担当外だとなかなか難しいかと思いますが、想像力を最大限に働かせて考えてみてください。

ここで考えた指標は、現在の分析にも使いますが、このあと徐々に改善していく実感を持ってもらうためにも定期的に計測していきます。
途中で項目を増減することもあるかと思いますが、スタート時の現状分析は一度しかできないので、後々使えそうな計測指標はバンバンとっていきましょう。

ステップ3. 理想状態に向かうためにボトルネックになっている課題を考える

この段階でようやく、現実と理想のギャップを考えていきます。

おそらく大半の方はこの過程で、考えながらやるべきことが山積している現実を突きつけられ、先が見えなくなっていくでしょう。
でも大丈夫です。これら全てに対して対策する必要はありません。重要なものから順に対策していくので、この段階で辛さを感じる必要はないのです。

ここで重要なのは、ギャップを機械的に挙げていくだけで、対策をわざわざしなくてもいいであろうことも漏らさずに挙げていくことです。
やる・やらないはあとで決めます。
まずは選択肢を、漏らさずになるべく網羅的に洗い出していく作業をすれば問題ありません。

この時、ステップ2で決めた指標を用いて、現在の計測結果と理想状態の予測値からギャップを分析すると、よりイメージしやすくなります。ぜひ活用してみてください。 

この作業はひとりでも可能ですが、その場合は必ず他のメンバー（できれば立場の違う複数名）のレビューを受けてみましょう。

視野の広さや視座の高さによって、出てくる内容が変わるため、偏りを減らすことにも繋がります。 
また、ステップ1で挙げた具体的な理想と同様に、ギャップもなるべく具体的に洗い出すことができると、あとの工程が楽になります。
ぜひチャレンジしてみてください。

ステップ4. コミュニケーションを設計する

コミュニケーションはとても大切です。
チーム内、チーム間のコミュニケーションがどれだけ円滑かによって、作業の進めやすさや組織の雰囲気、心理的安全性の高さ、仕事の充実度にも影響してきます。

また、一人チームだったとしても、完全に自分だけで完結する業務はほとんどないはずです。他チーム、他メンバーとの連絡・連携や、上席者への報告など、関わり方は色々とあるかと思います。

GitLab社のブログ(3) から有名になったDevOpsの4大原則とされる

• ソフトウェア開発ライフサイクルの自動化
• コラボレーションとコミュニケーション
• 継続的な改善と無駄の最小化
• 短いフィードバックループでユーザーのニーズに重点を置く

においても、コラボレーション（協力）とコミュニケーションのギャップが課題の理由の一つであり明確かつ定期的なコミュニケーションがなければチーム間のコラボレーションは実現しないとされています。
考えてみれば当たり前の話なのですが、はじめから最適なコミュニケーションを実現するのは難しいでしょう。そこで、コミュニケーションの設計が必要になってきます。

コミュニケーションを「設計する」と書くと大袈裟に見えるかもしれませんが、こういう頻度・方法・内容でコミュニケーションをとることができれば良さそうだよねという仕組みをまず考え、それを実践しながらさらに改善していきましょうというだけの話です。
ただ最初は、ある程度実行に移しやすい仕組みを考えて関係する人たちに提案し、意見を取り入れながらまずやってみるという一歩をどのように踏み出すかを工夫した方が良いと考えています。

（3）4 Must-know DevOps principles：https://about.gitlab.com/blog/4-must-know-devops-principles/

会議・雑談・ドキュメントをチームの状況に合わせて最適化する

例えば会議体。
どのような目的の会議が必要か。それは対面またはリモートの音声でやるのか、テキストコミュニケーションで足りるのか。また、どのくらいの頻度でやるのか。
そういった計画を立てていきます。

例えば、立ち上がったばかりだったり、これまで雑談などあまりしてこなかったチームの場合、お互いを知ることで話しやすい雰囲気や心理的安全性の高い環境になり、ちょっとした疑問も相談し合うことでミスを減らしていけるかもしれません。
得意・不得意がわかってそれぞれが力を発揮しやすい担当に変更できたりすることで、全体としても効率が上がり、個々のメンバーとしても満足度や充実度の高い仕事ができるかもしれません。
その場合は、それぞれを知ることができるような自己紹介タイムや最近興味のあることを話す雑談タイムを設けたり、自己紹介や自分のトリセツといったパーソナルな部分がわかるような内容を一覧にしてまとめておくなど、ちょっとした時間や工夫の積み重ねで実現できるでしょう。

話して意思疎通するだけではなく、ドキュメントはどの単位で残すのか、どのサイクルで更新するのか、情報共有の粒度をどのようにするのか、どこに情報を置くことができればメンバーが平等に目を通すことができるのかを、考えるのも重要です。

専門用語やローカル用語がわからずチーム間のコミュニケーションにミスが発生しがちなら、言葉の意味や指し示す定義の粒度を合わせるなども、効果的な方法です。

例えばバグやミスが多く生産性の悪いチームであれば、レビューの単位やサイクルを見直してみたり、発生した問題を誰もが確認できるようにみんなが見える場所に原因と対策をまとめたものとして置いておき、類似の作業を行う時に参考にするのも良いでしょう。

ステップ5. 上手くいっている点、これから改善していく点を言語化・見える化して共有する

ステップ4のコミュニケーション設計での考えに従ってコミュニケーションをとりながら、チームの様子をじっくり観察してみてください。
以前より良くなった点、変わらなかった点、やりにくい点が見えてくると思います。
小さな変化でも話しやすい雰囲気ができてきたら、改めて今後の未来の話をしていきます。

ステップ3のボトルネックになっている課題をもとに考え、改善していく点を言葉にして並べていきます。
ステップ3で具体的に挙げていれば、ここでの言語化は楽にできると思います。

そして、現在のチームで良いこと、上手くできていること、改善してきたこともここで挙げていきます。
ダメなことを改善するのも大切ですが、良いところを伸ばしたりキープしたりすることも同じくらい大切です。
コミュニケーションをとりコラボレーションができてくると、よりお互いの良い点悪い点が見えてきますので、今までよりも深く分析することができるでしょう。

その際、解決できるもしくはより良くしたりキープできると嬉しい順に並べていきます。
"嬉しい"の基準には、ステップ2で決めた指標が改善する幅が大きいものから並べてもいいですし、ステップ1で挙げた理想状態のうち叶えたい想いの強い順に並べても良いと思います。
または、ステップ3で挙げた問題点の内、困る人が多い順だったり深刻度の高い順に並べてもいいでしょう。
チームの価値観を話し合いながら、並べていきます。
ここで考える順番は、個人の想いの強さというよりは、チーム・組織の全体最適の観点から決められると、より全体的な納得度の高い取り組みに繋がります。

そして無事並べられたら、全員の見えるところで、かつすぐにアクセスできる場所で共有しておきましょう。全員が少しずつ意識しながら毎日を過ごせると、より効果的な取り組みになると思います。

その後は、リストの一番上から順に取り組みを開始していきます。
改善が必要なら解決策を検討します。
上手くいっていることであれば、キープするための仕組みが現状で良いのか検討します。
より良く伸ばしていきたいことであれば、どうすれば伸ばせるかのアイデアを出し合います。
そうして叶えていくリストは、取り組むと嬉しいことばかりが並んでいます。
日々の業務も大変だと思いますので、例えば1週間に1つ、1スプリントに1つなど、サイクルを決めながら取り組んでいくと進めやすいかと思います。
その際、取り組んだ結果、ステップ2で考えた指標がどのように変化したかを計測しながら進めていくと、実感と説得力が増し、より取り組みに前向きになっていくと思います。

定期的にリストを見直すのも効果的です。
毎日目につくところにあるリストと現実の状態を比べて、もっとこうした方がいいのではというアイデアが浮かんできたら、ステップ4で設計したコミュニケーションの仕組みの中でぜひ提案してみてください。
コミュニケーションやコラボレーションが良くなっていけばいくほど、こういった細かな改善アイデアを提案しやすくなっていき、さらに改善サイクルを進めやすくなっていきます。

おわりに 

ここまで読んでくださってありがとうございます。いかがでしたか？
私自身も、これらが全て上手く進むことはそうそうありませんが、必要なポイントだと頭に入れておくだけでも、行動は変わってくると思います。
一番良いのは、こうしたサイクルが自然と生まれて無理なく回っていくことですが、そんなチーム・組織はなかなか無いですよね。
最初の一歩を踏み出すこと、最初の一言の声かけから始めることは、今この記事を読んでいるあなたからはじめてみても良いのではないでしょうか。
これらの取り組み自体を、実現できると嬉しいことリストの先頭に置いても良いかもしれませんね。

無理をすると続けられません。
しかし、始めなければ何も実現できません。
勇気を出してちょっとずつ、お互い頑張って取り組んでいきましょう！
私も引き続き頑張ってみます＾＾