CI/CDは誰のものか

この記事はCI/CD Advent Calendar 2019の16日目の記事です。

こんにちは、16日目のアドベントカレンダーを担当させて頂きます。

はじめに

早速ですが、CI/CDと聞いて皆さんが最初に思い浮かべることは何でしょうか？
おそらく自動テストの実装やデプロイの自動化など、自動化技術のことを思い浮かべる方が多いのではないでしょうか。
弊社でもこのような自動化には取り組んでおり、Bitbucket PipelinesやJenkins等を利用したりしていますが、タイトルの通りこれから書くのはCI/CDの技術的側面についてではありません。
技術的な内容については他のアドベントカレンダーの記事に期待してます。皆さん、応援してます！
なお、この投稿は個人の意見にもとづくものであり、所属する組織を代表するものではありません。
異論などもあるかと思いますが、こんな考え方もあるんだなくらいで参考にして頂ければと思います。

CI/CDとは

おそらくこの記事をご覧の方はCI/CD = Continuous Integration／Continuous DeliveryあるいはContinuous deployment(日本語では継続的インテグレーション／継続的デリバリーあるいは継続的デプロイ)という言葉の略だということはすでにご存知ではないでしょうか。
この言葉に向きあってみると、本質的には技術的な何かを指すのではなく、習慣のことを指すのだということに気づいてきます。
実際にWikipediaにも以下のように記載されています。

継続的インテグレーション、CI（英: continuous integration）とは、主にプログラマーのアプリケーション作成時の品質改善や納期の短縮のための習慣のことである。

常に一定以上の品質のテストができるようにする(もしくは繰り返す、継続する)ことで変更しやすくする、
一定のデプロイ手順を定義し繰り返す、継続することでリリースに対する心理的負担を軽減する、
その習慣そのものがCI/CDであり、習慣を継続しやすくするための手法として注目されているのが自動テストやデプロイ自動化のような技術なのだと思います。

自動化がないときテスト/デプロイは誰がするのか

少し話が横にそれますが、ある程度プロジェクトやプロダクトが大きくなると、おそらく技術要素によって役割分担されたチームが出来上がることが多いと思います。
弊社も漏れなくそんな感じです。全員がフルスタックにはなれません。
フロントエンド開発をする役割・バックエンド開発をする役割・インフラ構築をする役割などになると思いますが、
すべての役割で共通して発生する業務がテストとデプロイ(リリース)です。
もちろんテストエンジニアのようなその部分に特化した役割があることもあると思いますが、その手前で多かれ少なかれ何かしらの確認はすると思います。
つまり、テスト/デプロイは中身は違っても全員がする作業なのです。

CI/CDは誰のものか

ここでタイトルに戻ります。
皆さんの開発現場では、自動化職人が生まれてしまっていませんか？
特定の技術領域の人に自動化の実装・保守が偏ってしまっていることはありませんか？
前述の通り、テスト/デプロイは全員に必要な作業です。
自分が作った成果物がどのような(どのように)テストを経ているのか知らない、どのような手順を踏んでビルドされデプロイされているのか知らない、ということはありませんか？
そんなときにチームが使っている自動化環境が壊れてしまったらどうしますか？
そのようなことを考えると、人任せにしていていい気がしなくなってきませんか？
CI/CDという習慣は、誰か特定の役割の人たちのものではなく全員のものではないでしょうか。
全員がオーナーシップを持って育てていくものだと思います。

最後に

CI/CDは習慣であり、みんなのものです。
だからといって自動化難しそうだなと敬遠している人は大勢いると思います。
でも、取り組み始めると面白いですし、最初から壮大なことをする必要はありません。
できることから一緒に楽しんで取り組んでみんなで育てましょう。