DevOpsという言葉は、話す人によって指しているものが変わります。
CI/CDのパイプラインを指していることもあれば、コンテナやIaCの導入計画を指していることもある。
ツールの名前が先に立つせいで、「入れたのに何も変わらない」という結果になりやすい領域です。
もともとこの言葉が向き合っていたのは、開発と運用のあいだに立つ壁のほうでした。
筆者もいま学んでいる最中なので、一次情報にあたって輪郭から整理してみます。
DevOpsはツールの名前ではない
最初に押さえておきたいのが、DevOpsが特定の製品や工程を指す言葉ではないという点。
定義は「文化・プラクティス・ツールの組み合わせ」
AWS の公式ドキュメントは、DevOpsを文化的な考え方・プラクティス・ツールの組み合わせであり、アプリケーションやサービスを高速に提供する組織の能力を高めるもの、と説明しています。
AWS「DevOpsとは」
3つ並んでいるうち、ツールは最後。
先頭に置かれているのが文化だという順番そのものが、この考え方の要点になっています。
サイロが解けると何が変わるのか
同ドキュメントによれば、DevOpsのもとでは開発チームと運用チームがもはやサイロ化していないとのこと。
エンジニアがアプリケーションのライフサイクル全体にまたがって働き、単一の職能を超えた技能を身につけていく形。
受け渡しの回数が減れば、そのぶん認識のズレが生まれる機会も減ります。
開発と運用の壁はなぜ生まれるのか
チームを分けたこと自体が悪いわけではありません。
問題は、分けたときに評価のされ方まで分かれてしまう点にあります。
求められている成果が逆を向いている
開発側の成果は、機能を早く多く届けたかどうかで測られるのです。
運用側は、本番環境を落とさず安定させ続けることで評価される。
片方はできるだけ変更したく、もう片方はできるだけ変更したくないという構図が、そのまま組織の中に埋め込まれてしまうのです。
この状態で「もっと連携しよう」と声をかけても、双方が自分の評価を守ろうとしている限りは動きません。
情報が壁を越えないと事故になる
DORA は、組織文化を Westrum の類型で捉えています。
権力志向の病理的な組織、規則志向の官僚的な組織、そして成果志向のジェネレイティブな組織という3分類。
Westrum が着目したのは、文化が組織の中で情報の流れ方を左右するという点でした。
悪い知らせを運んだ人が責められる環境では、障害の予兆や設計上の不安が壁の向こうへ届く前に握りつぶされます。
壁の本体は部署の区切りではなく、情報が渡らないことのほう。
文化はスローガンでは変わらない
とはいえ、「文化を変えよう」と宣言して変わるものでもありません。
調査が示しているつながり
DORA は、高い信頼にもとづくジェネレイティブな文化がソフトウェアデリバリと組織のパフォーマンスを予測する、と述べています。
DORA「Generative organizational culture」
同ページでは、心理的安全性がソフトウェアデリバリのパフォーマンス・組織のパフォーマンス・生産性を予測する、という結果も示されているのです。
文化というつかみどころのない言葉が、計測できる成果と結びつけて語られているところが要点。
働き方を変えると文化が変わる
そのうえで DORA は、考え方を先に変えるのではなく働き方を変えることが文化を変えるとしています。
挙げられているのは、機能横断のチーム、非難しないポストモーテム、品質や信頼性やセキュリティを共同で持つ責任分担といった具体的な実践。
先に仕組みを変え、そこで実際に起きたことが文化として定着していくという順番です。
CI/CDやIaCといった道具は、この「働き方の変更」を支えるために置かれるもの。
道具を先に入れて文化が変わらないのは、順番が逆になっているからだと整理できます。
最後に
DevOpsは、開発と運用を分けたときに生まれる壁を、働き方の側から崩していく取り組みでした。
定義の先頭に文化が置かれ、その文化は宣言ではなく実践の変更から動くという筋道になっています。
まず自分のチームで、悪い知らせが最短で共有されているかを確かめてみる。
そこが詰まっているなら、どんなパイプラインを組んでも壁は残ったまま。
チームの現在地を軸ごとに見たいときは、CALMS という 5 つの軸に当てはめると輪郭が出ます。
以上です。
コメントを残す