目次

あなたが「リリース」という言葉を聞いた時、どのような感情が呼び起こされるだろうか？安堵？高揚感？あるいは初めての達成感だろうか？もしあなたのチームがまだ、リリース準備に手作業でのテストや、手作業によるデプロイ、またはスクリプトに部分的にしか頼らないデプロイをしていたとしたら、あなたの感情はむしろ「不安」や「猛烈な怒り」により近いかもしれない。

図：手作業デリバリにおける感情のジェットコースター

そのため、ソフトウェア開発は「継続性」に向かって進んでいるのである。最近、継続的なインテグレーション、ビルトインテスト、常時監視、分析フィードバックが重要視されているのは、すべてソフトウェア産業全体の傾向、つまり対応 (React) 力を高めようという動きを表している。企業が、こうした変化の意味を模索していくと、必ず継続的デリバリ（一般にCDとして知られる）にたどり着く。

誤解してもらっては困るのだが、CDは「ユニコーン」企業¹や人気の技術系企業に限ったことではない。つつましい設立間もない企業から古風な企業まで、あらゆる組織における全てのチームが、この継続的デリバリを実践できる。いや、実践すべきだ。この記事では、継続的デリバリに切り替える上でのビジネスケースを挙げ、この先やるべきことや、継続的デリバリがもたらすメリットについて話すつもりだ。また、CDの手段を用いたソフトウェア出荷に必要な決断や妥協点（代償）についても説明していこうと思う。

継続的デリバリが企業にもたらす４つのメリット

反応がより速くなる

CDがもたらす最も顕著なメリットは、社内外の変化に対して素早く反応できるようになることだ。例えば市場状況や経営構造の急な変化、または自社の主力商品の評判が突如下がってしまった時など、極めて重大な変化に素早く対応できるようになる。それを望まない企業なんてあるのだろうか？

リスクが軽減される

多くの組織において、リリース間近のお祭り騒ぎは多かれ少なかれあるだろう。では、なぜ騒ぐべきではないのか？新機能がやっと顧客に届く。バグが修正される。みんなハッピーではないか。リリース出荷には、QAチームとビルド・リリースチームの多大な努力を要するということは、多くの組織で隠されている。継続的デリバリモデルでは、ソフトウェアは常に「リリースされる」ものである（顧客にとっては必ずしも必要というわけではないが）。したがって、リリースにまつわるお祭り騒ぎとリスクが減るというわけだ。常にリリース用インフラを頼っていれば、数週間、または数ヶ月に一度しか工程を経ない場合よりもずっと早く不備に気づき、解消できるだろう。

不備やコストが目に見える

最新のWebサービスであれ、昔ながらのISOイメージであれ、どのようなソフトウェア企業も、細々とした費用を負担している。しかし、多くの場合、こうした経費は会社に完全にオープンになっていない。リリースするのに本当はいくらかかるのかを覆い隠す何らかの力が働いているのかもしれない。継続的デリバリは、この過程を会社そのものに対してだけでなく、意思決定者に対しても見えるようにしてくれる。パイプラインを作るとき、人が関わるのはどの部分か、ボトルネックとなるのは何か、摘み取っておくべき小さな問題は何なのかが明確になる。そして一度作られたパイプラインは、好循環を起こしていく。今や、堅実にソフトウェアをデリバリできる仕組みがあるのだ。リリースにどのくらいの期間やコストがかかるか分からないという不満はなくなるだろう。

リリース時の選択肢がより柔軟になる

継続的デリバリモデルへ移行するには、運用の中身とソフトウェアアーキテクチャの中身の両方において、インフラの構築をする必要がある。しかし、一度構築を終えてしまえば、機能追加や修正のやり方に柔軟性をもたらしてくれる。特定の機能を特定の顧客にリリースできるかもしれないし、もしくは、それらが設計通りに機能してスケールすることを保証するために、一部の顧客に向けてリリースできるかもしれない。せっかくテストして開発したものの、次のバージョンアップリリースを待って製品で眠っている機能もあるかもしれない。会社のマーケティング部が業界の年次コンベンションで「ウケる」製品を望んでいるって？継続的デリバリなら、こうしたリクエストに簡単に応えることができる。

継続的デリバリはユニコーン企業だけのものではない

これまで述べてきた企業へのメリットを考えると、継続的デリバリは魔法のように思えるかもしれないが、そうではない。

これは単に、ソフトウェアの設計、開発、納品の仕方における考え方を変えただけにすぎない。そして、この変化に続き、実施に向けた取り組みへの集中的な投資が必要となる。多くの組織がCD移行の最初の段階、つまり、CDの投資の価値を定め、実行に移す部分で行き詰まってしまう。

というのも、CDへの移行には、技術的なプロセス、運用における風土、組織の考え方に対する全面的な見直しが必要とされるため、始めるにあたって大きな障害があるように思われやすい。かなり大幅な変更をしたり、何年も放っておかれていたソフトウェアデリバリのインフラ構築をしたりしなければならないため、企業にとってはいっそう腰が重くなるかもしれない。以上が、悪い点だ。良い点としては、私たち人間には、ことのほか順応性があるということだ。特に、地獄のようなソフトウェアのリリース工程がマシになると聞けば、なおさらやる気になるだろう。

他にも良い点がある。会社の様々な場面でCDへの準備を整えておくことで、他の形でも良い影響が出る。たとえ、CD移行に関して会社の全面的な支持を得られなくても、あなたが出来る範囲で変えていこうとすれば、その中で価値は十分に出てくる。

最も大きな初期投資は、CDへの移行が企業目標として意義があるという合意を周りから得ることだ。この合意は、全員が参加しなければ達成できないものであり、移行期間中は真剣な（だが最終的に有益となる）妥協を要する重要なものだ。

「これから数ヶ月、自動テストや自動ビルド・リリースのインフラに取り組んで、アプリケーションがどう書かれているか見直そう。自社の機能開発は後回しだ」こんなことを言うプロダクトマネージャは今まで見たことがない。絶え間なく変わる市場に対応しなければならない責任と、競合他社に打ち勝たなければならないプレッシャーを考えると、 そうしたプロジェクトマネージャーたちの見解にはうなずける。

プロダクトマネージャとビジネス利害関係者を参画させる方法は、一度CDへの投資が実を結び始めたら、新機能のリリースがいかに早くなるかを彼らに証明してみせることだ。PMがアイデアを頭に思い浮かべたらすぐに、イベント分析を搭載した超軽量バージョンの機能を出荷することができる世界を想像してみてほしい。その分析からは、ユーザがその機能を使う上での採択や能力に関するデータが送られ、PMは今後の機能改善のために、そのデータを使用できる。この過程はCDなしでは1ヶ月かかるが、CDを使えば、そのイテレーションサイクルは数日～数週間になり得る。

しかし、これはCDが稼働するまで、すべての機能開発を中止すべきだと言っているのではない。むしろ、プロダクトマネージメント、エンジニアリング、エンジニアリングサポート（QA、運用、ビルド・リリース）といった企業のあらゆる部門で、CDのもたらす長期的なメリットが受け入れられるべきだ。この部分は難しいことではない。だが、CD移行に向けて必ず守らなければならない事は、構想が停滞して結局頓挫してしまうことがないよう、常に気をつけることだ。

そして、現実的になろう。継続的デリバリへの投資を必要とする部門が他にもある。そして、この時点では、CDはきっかけに過ぎないかもしれないが、CDによる変化は他のメリットをも生み出す。

自動テスト

これは、単体テストだけに焦点を当てているわけではなく、結合テストやシステムテストも含まれている。これらはBambooのようなシステムを使って自動化されるべきだ。私の協業した企業が行った最大の投資の一つでは、特に重要なソフトウェアコンポーネントにおいて、全バグ（バグ全部！）に関連する単体テスト（そして意味をなしたのは統合の時）が必要だった。CD実施のどの段階にいるかに関わらず、こうしたテストは再発バグをすぐに特定するのに役立つ上、直ちにリリースサイクルを短くし、ストレスを減らしてくれる。同じことをゼロから始めたとしたら、6～18ヶ月はかかるだろう。

アプリケーションアーキテクチャの変化

サービス指向アーキテクチャに移行していくことは必須だ。あなたのソフトウェアがSaaSでないのなら、コンポーネントを個別に出荷できるよう、必要なバージョニングとリリースエンジニアリングとともにコンポーネントアーキテクチャに向けて押し進める必要がある。この時、いわゆる「機能フラギング」と「カナリアリリース」は、こうしたコンポーネント化されたサービスやモジュールで利用できる。これは、こうした複雑なシステムを分離することにより、それぞれのインターフェースがよりよく理解され、チームがコンポーネントを自分たちのサイクルでリリースできるようになることで元が取れる。その上、あなたはCDの準備を整えることができる。ほとんどのチームは、リリースサイクルを4～8回ほどまわせば移行できる。

ビルド／テストファーム

Firefoxウェブブラウザへの機能追加は、毎度かなりのテストを走らせることになる。CPU計算時間で200時間以上も要するため、ビルドにかかる時間は言うまでもない。それぞれのコミットでこれらを実行するためには、相当なハードウェア（そして、場合によってはクラウド）への投資が必要となる。現在のビルド／テストファームには、CDをサポートするための十分なキャパシティを用意しなければならない。そうすることで、開発者のフィードバックループが強化され、様々なオペレーションシステムやブラウザでのテストが容易になる。テストファームのキャパシティ調整は時間がかかるプロセスだが、アマゾン・ウェブ・サービスなどのクラウド・プロバイダがこれに一役買ってくれるだろう。

カルチャーの重視

CDの実施には根本的に、ある程度のカルチャー改革が必要となる。なぜなら、CDのコア構造はフローを変える「デリバリーパイプライン」であり、人に管理される「ゲート」ではないからだ。まさにこの構造の性質が、組織のサイロ思考²を少しずつ崩していくための助けとなるかもしれない。そのため、CD移行を応援する人は、こうしたサイロ思考の人々にCD実施の心構えをさせるよう配慮しなければならない。そうしなければ、危機を感じたサイロ思考の人々が拒絶してくるかもしれない（そして実際、彼らはCD実施を避けるためなら何でもするだろう！）これもまた長期間かかるプロセスだが、集中的に続くのは2～6ヶ月だ。

集中的なスタッフ配備

CD移行への牽引力を得るために、CD移行に必要なインフラ整備に絞ってエンジニアやコンサルタントを採用する必要があるかもしれない。だが、それはチームに新たな専門知識を集めるための格好の口実となる。目立った変化を起こすことで、既存のエンジニアが気を悪くすることはない。チームに新しい人を雇うことは、組織を前進させてくれる。また、一丸となって取り組む中で、チームを素晴らしいCDの新世界へと導いてくれるだろう。臨時のコンサルタントでも、組織のカルチャーを変えやすくする空気を作ってくれるため、ベストな契約期間はやはり2～6ヶ月だ。

CDへの旅を始めよう

継続的デリバリの実施には、組織全体のチームが変化を起こす必要がある。インフラ、ハードウェア、人材への重点的な投資が必要となる。これら全てを行うには時間を要するが、全て可能なことだ。

最初のステップとして、まず認識しておくべきことがある。それは、「安く」、誰かの「20％の時間で」、そして「開発とリリースの合間のちょっとした時間で」継続的デリバリへ移行しようとするのは、わざわざ時間（とその分のお金）をかけて失敗するようなものだということだ。だがこれを、変化し続けるソフトウェア業界に「リアルタイムに」対応できる企業にしてくれる投資として捉えたらどうだろうか。CDは、将来的に利益を生み、結果としてバランスシートの投資分を相殺してくれるはずだ。そして、「夜遅くまで」の残業を物ともしない社員や、全体を見ずに自分の目先にある問題だけに勤しむ人への対応を考えると、その価値は一目瞭然だ。

¹企業としての評価額が10億ドル(約1250億円)以上で、非上場のベンチャー企業のこと ²組織の中で、他の部門や組織全体よりも、自分の部門だけを考える傾向のこと

原文：https://www.atlassian.com/continuous-delivery/business-case-for-continuous-delivery (2016-1-27) ※元記事の筆者には直接翻訳の許可を頂いて、翻訳・公開しております。