「お願いドリブン」の開発から脱却する
CI/CDによる自動化を成功させる前提として、そもそも何が自動化できるのかを理解しておく必要がある。舟木氏は、DevOpsの開発プロセスである「プラン」「コード」「ビルド」「テスト」「リリース」「デプロイ」「運用」「監視」を、それぞれ自動化できるか否かの観点でシンプルに整理した。
プランおよびそれをコードに落とし込むフェーズでは、ツールによる効率化はできるものの、主要な作業の自動化はまだ難しい。自動化が可能なのは、ビルド、テスト、リリース、デプロイのフェーズだ。舟木氏によると、これらは言い方を変えれば「継続的であるために自動化すべき」部分でもあると言う。
デプロイ後の運用や監視については、正常時はさまざまなツールによって自動化できるポイントも多い反面、何らかの異常が発生した場合に対応が難しく、現実的には自動化できない部分とした。
なお、自動化が可能な部分のうち、ビルド、テスト、リリースが狭義の継続的インテグレーション（CI）の対象、デプロイが狭義の継続的デリバリー（CD）の対象ということになる。
「忘れてはならないのは、CI/CDの前提として、ビジネスの継続があること。ビジネスが継続しているからこそ、開発も継続していくと考えるべき」（舟木氏）
では、それをふまえたうえで、継続的な開発とはどういうことなのか。舟木氏はまず、「継続的ではない」例として、「お願いドリブン」の開発を挙げた。
ソースコードを修正したら、速やかにビルド、テスト、リリースへと進められればよいが、そこが自動化されておらず人依存になっていると、次に進むために「お願い」が必要な状況に陥りやすい。例えば、ビルドするとコンパイルエラーが出たり、テストが通らなかったりした場合、コードを修正してもう一度、ビルドやテストをお願いしなければならない。節目節目でお願いするのも勇気が必要だが、「そこは勇気の発揮のしどころではない」と舟木氏は強調する。
やり直しのお願いなどを何度も繰り返していると心理的に遠慮が生まれ、ディレイが生じ、継続性が損なわれてしまう。お願いドリブンから脱却し、遠慮なしに依頼が可能な状態、さらには依頼しなくてもビルドからテスト、リリース、デプロイへと自動的に流れる状態を作り出すことが重要だ。それが開発の継続、ひいてはビジネスの継続につながる。
大人はなぜ幼稚園児に負けたのか？ マシュマロチャレンジに学ぶ
CI/CDの導入は、開発プロセスやツールを変える取り組みであり、根源的なところで、開発に対する考え方や文化を変えることにもつながる。そこで求められるのが、CI/CDに対する共感・理解を周囲に広げる勇気だ。エンジニア同士など「横」の関係に共感・理解を広げるだけではなく、「縦」の関係にあるビジネスオーナーなどの責任ある人を説得することも必要だ。
「縦の関係にある人に対しては、CI/CDの本質的なメリットを伝える。それはひと言で言えば "Fail Fast, Succeed Faster"で、『早く何度も失敗できる』機会や環境・仕組み・文化を作ることで、ソフトウェアの品質を高められる、ビジネスの継続性に貢献できる、それがビジネスの成功への近道となるということ。これを頭で理解してもらうだけでなく、腹に落ち、肌感覚として実感してもらえるような取り組みや説明の仕方が求められる」（舟木氏）
続いて舟木氏は、早い段階での失敗が成功につながることや、先延ばしが継続性を阻害することなどを示す事例として、「マシュマロチャレンジ」を紹介した。
2010年のTEDでトム・ウージェック氏が研究成果を発表し、世界中に広まったマシュマロチャレンジは、乾燥パスタ20本に、ひもとテープ、はさみを使い、複数人のチームで18分の制限時間内に自立可能なパスタのタワーを作り、その高さを競うゲーム。タワーの頂上には、マシュマロを載せる（刺す）というルールがある。
トム・ウージェック氏の研究結果で有名なのは、大人のチームよりも幼稚園児のチームのほうが成績がよかったことだ。両者はタワーを作るアプローチが明確に異なっていた。
大人たちは制限時間のほとんどを計画（プラン）と構築（ビルド）に使い、最後にタワーの頂上にマシュマロを刺したところ、倒れてしまった。これに対して、子どもたちはすぐに低いタワーを作り始めて、そのまま頂上にマシュマロを刺した。自立する低いタワーができたら次はタワーを少し高くし、もし倒れてしまったら直前まで立っていた高さに戻して作り直すことを繰り返したそうだ。
舟木氏自身も、これまで150社以上の顧客を対象にマシュマロチャレンジを実施してきたが、やはりプランとビルドにほとんどの時間を費やす人が多かった。
「大人チームの失敗の要因は、最後にマシュマロを載せたこと。いわば、テスト、リリース、デプロイの作業を『後からでもできる簡単なこと』とみなして、最後まで手をつけなかった。マシュマロはとても軽く見えるが、こうしたゲームで一般的に使われるマシュマロは7グラム程度で、実は500円玉と同じくらいの重さがある。それをもっと早いタイミングで認識できれば、先延ばしにせずにマシュマロを載せていたはず」（舟木氏）
これからやるべきことは簡単なのか、難しいのか。事前に把握できないことであれば、まず取り組んで、失敗するなら早期に失敗してリカバリーしたほうがよい。例えば、自分がこのマシュマロチャレンジの大人チームのような状況にある場合には、「早く取りかかるべき」「先延ばしにするのはおかしい」といった声を上げる勇気も必要だと舟木氏は指摘した。
自動化における4つの評価ポイント
CircleCIでは、ソフトウェアデリバリーに関する現状調査として、「The 2020 State of Software Delivery」というレポートを発表している。同レポートの調査期間は2020年8月1日〜30日の30日間、調査対象はCircleCIユーザーの約4万4000組織で、約16万プロジェクト、1日あたり約200万ジョブが含まれる。
その中で特に自動化（CI/CD）における評価ポイントとしているのは、スループット、実行時間、平均復旧時間、成功率の4つ。舟木氏はそれぞれについて、CircleCIユーザーの中央値およびベンチマーク目標値を提示しながら説明した。
スループット
ここでのスループットとは、ワークフロー（ビルド、テスト、デプロイなど複数のジョブを組み合わせて構築するCI/CDパイプラインの全体）が1日に何回実行されているかを表す。CircleCIユーザーの中央値は0.7回。CircleCIのベンチマーク目標値は、数値ではなく、「プルリクエストのマージごとにいつでもビルド可能」とされている。これは、「書いたコードは常にビルド、テスト、リリースできる」状態を目指すということだ。
「他の評価ポイントも同様に、現時点での自社の数値を把握したうえで、Circleユーザーの中央値を『近い目標』としてまずはそこに追いつき、ベンチマーク目標値を『あるべき姿』として目指していただきたい」（舟木氏）
実行時間
2つめの評価ポイントは、ワークフローの平均実行時間。中央値が4分以内であるのに対して、ベンチマーク目標値は5分〜10分で、中央値よりも大きい数字となっている。これについて、舟木氏は次のように補足。
「実行時間はもちろん短いほうがよいが、短すぎるのは『まだ自動化しきれていない要素』が残っていることでもある。自動化可能なことは、すべてツールに任せたうえで、目標値のレベルを目指していただきたい」（舟木氏）
平均復旧時間
平均復旧時間は、いったんワークフローが失敗してから成功するまでにかかった時間の平均値を表す。中央値は56分以内、目標値もほぼ同様の60分以内とされている。なお、復旧時間はエンジニアの数によっても変わり、200人まではエンジニア数が増えるにしたがって短時間で復旧できる傾向にあった。
成功率
成功率は、ワークフローの成功数を実行数で割った数。中央値はデフォルトブランチで80％。目標値は同90％以上とされている。
CircleCIの管理機能である「インサイトダッシュボード」を利用すれば、自分の関わる個々のプロジェクトや組織内で進行中のプロジェクトに関して、こうした評価ポイントの数値などもグラフなどの視覚情報を交えてスムーズに把握できる。
最後に舟木氏は「CI/CDを使って我々が開発する『ソフトウェア』とは何か、あらためて考えてみた」として、以下の通りにまとめた。
- ソフトウェアは、継続でき、変化でき、支持を得続けられる「資産」。
- 支持を得続けるためには、変化していかなければならない。
- ソフトウェアを構成する機能の一部が拡張したり、縮小したり、別の新たな機能が追加されることもある。
- 最適な機能のバランスは時とともに変わる（投資信託などのポートフォリオと同様）。
- 内製・外注・パッケージ使用・OSS使用などの開発方法の判断も重要。
- 開発者の数やスキル、予算、タイミング、時間、技術の成熟度といったさまざまな制約条件もある。
- 開発者はそれらをふまえて考え、勇気を持って議論し、支持を得続けられる資産を生み出していただきたい。
CI/CDのリーディングカンパニー CircleCIのウェビナーに参加しませんか？
CI/CD ツールのリーダーとして時代を走り続けている CircleCI は、毎月、無料
オンラインセミナーや、ユーザー様同士のコミュニティミートアップを開催して
います。リモートファーストな今だからこそ、全国の方と一緒にCI/CDについて
もっと学べるチャンスです。
近日開催予定のイベントはこちら
