「お願いドリブン」の開発から脱却する
CI/CDによる自動化を成功させる前提として、そもそも何が自動化できるのかを理解しておく必要がある。舟木氏は、DevOpsの開発プロセスである「プラン」「コード」「ビルド」「テスト」「リリース」「デプロイ」「運用」「監視」を、それぞれ自動化できるか否かの観点でシンプルに整理した。
プランおよびそれをコードに落とし込むフェーズでは、ツールによる効率化はできるものの、主要な作業の自動化はまだ難しい。自動化が可能なのは、ビルド、テスト、リリース、デプロイのフェーズだ。舟木氏によると、これらは言い方を変えれば「継続的であるために自動化すべき」部分でもあると言う。
デプロイ後の運用や監視については、正常時はさまざまなツールによって自動化できるポイントも多い反面、何らかの異常が発生した場合に対応が難しく、現実的には自動化できない部分とした。
なお、自動化が可能な部分のうち、ビルド、テスト、リリースが狭義の継続的インテグレーション（CI）の対象、デプロイが狭義の継続的デリバリー（CD）の対象ということになる。
「忘れてはならないのは、CI/CDの前提として、ビジネスの継続があること。ビジネスが継続しているからこそ、開発も継続していくと考えるべき」（舟木氏）
では、それをふまえたうえで、継続的な開発とはどういうことなのか。舟木氏はまず、「継続的ではない」例として、「お願いドリブン」の開発を挙げた。
ソースコードを修正したら、速やかにビルド、テスト、リリースへと進められればよいが、そこが自動化されておらず人依存になっていると、次に進むために「お願い」が必要な状況に陥りやすい。例えば、ビルドするとコンパイルエラーが出たり、テストが通らなかったりした場合、コードを修正してもう一度、ビルドやテストをお願いしなければならない。節目節目でお願いするのも勇気が必要だが、「そこは勇気の発揮のしどころではない」と舟木氏は強調する。
やり直しのお願いなどを何度も繰り返していると心理的に遠慮が生まれ、ディレイが生じ、継続性が損なわれてしまう。お願いドリブンから脱却し、遠慮なしに依頼が可能な状態、さらには依頼しなくてもビルドからテスト、リリース、デプロイへと自動的に流れる状態を作り出すことが重要だ。それが開発の継続、ひいてはビジネスの継続につながる。
