継続的インテグレーション(CI)は “賢明な選択肢” のはずです。作成したコードを本番環境にすぐさま統合するというアイデアが、却下される理由はどこにあるのでしょうか。
ひとつの事例をご紹介しましょう。時は 2020 年 8 月。ある新人エンジニアが、キャリアの初めの一歩を踏み出しました。専用のデスクとコンピューターとともに、3 か月先のリリース日が定められたプロジェクト計画書を受け取りました。彼女がコードの作成に取り掛かっていたころ、QA エンジニアはリリース候補版の公開に向け、テスト計画の作成に追われていました。
4 か月の苦闘の末、新人エンジニアはチームとともにコードを完成させて CD-ROM 工場に送り、コードを書き入れた CD-ROM が顧客へと送られました。そのソフトウェアの新バージョンは、多くの顧客が待ち焦がれていたものでした。前回の更新から 8 か月の間が空いていたからです。しかし、6 か月前に既に報告されていたバグが手つかずのまま残っていたので、顧客を悩ませる結末に終わりました。
この事例は、私がソフトウェア エンジニアリングの世界に入ったときの体験に (ほぼ) 基づいています。当時のリリース時点で、ソフトウェアの更新にかかるコストは莫大なものになってしまっていました。長期間のテスト サイクル、大掛かりなドキュメントの改訂作業。スクリーンショットはあっという間に古くなるのに、ソフトウェアがリリースされてしまえばドキュメントの更新は行なえません。
プロダクトの変更には労力が掛かり、ミスがあれば大きなコストが発生していました。
ソフトウェア開発を革新した CI/CD
今日では、事情は大きく変わりました。大きな理由は、CI/CDツール の登場です。
プロダクトの変更を完成し次第すぐに実装できる仕組みがもたらす効果は、控えめに言っても大きなものです。エンジニアと顧客とのフィードバック ループにかかる時間は大幅に短くなりました。エンジニア側からすれば、このおかげで顧客を最優先としてフィードバックに対応できるようになっています。
顧客に変更を提供するためのコストが下がったことで、リリースにエラーが含まれてしまっていたとしてもすぐにロールバックできるようになりました。また、かつて変更のリリースは大きなリスクであるととらえられることもありましたが、今では強い確信を持ってリリースできるようになっています。変更を一度に 1 つずつ反映できるので、ギリギリになって 2 つの機能をまとめて実装した結果、検出しづらいエラーが含まれてしまうということもありません。
継続的に変更を加えることでプロダクトの品質を高めることができるというのは、直感に反しているように思えるかもしれません。ところが、より良いプロダクトを開発する方法はこれしかないのです。
それでは、CI/CD に懐疑的なマネージャーを説得するにはどう言えばよいのでしょうか。ここからは、想定されるマネージャーからの質問とその回答案をご紹介します。
継続的インテグレーションとは？
「人間に可能な範囲でできる限り早くコードを本番環境に反映することです」のように、マネージャーが不安を覚えるような答えは言わないように注意してください。
こうした回答では、CI/CD の実態に反し、未完成の機能や壊れた機能を顧客に提供すると思われかねません。たとえば、次のように回答してみるとよいでしょう。「継続的インテグレーションとは、エンジニアリング作業を小さく分割してチーム メンバーそれぞれに割り当て、こまめに QA を行う手法です」
CI/CD にかかるコストは？
CI/CD への移行にかかるコストは、テストの自動化にどれだけ投資するのかによって異なります。そのため、テスト工程の自動化の現状に左右されます。テストの大部分あるいはすべてを手作業で行っている場合、E2E (エンドツーエンド) テストも含んだ包括的なテスト スイートを自動化している場合と比べ、コストは大きくなります。
テスト自動化への投資が適切であると示すのは簡単です。CI ツールでのテストの自動実行は、エンジニアに賃金を払ってテストをまかせるよりも安上がりで、しかも信頼性が高いからです。ただし、この提案は、自動化のメリットを盾にして機能単位でのデリバリーを導入するよう迫るものですので、マネージャーには決断しづらいこともあります。マネージャーからは、テストの自動化を徐々に取り入れるように求められることでしょう。場合によっては、CI/CD の導入に取り組む多くのチームで採用されているように、デプロイ前に手作業による QA 手順を組み込むよう求められるかもしれません。
プロのコツ: CI/CD の費用についてマネージャーから聞かれたときに、チームのコストとなる期間 (四半期単位) を添えて回答できれば、真剣に検討してもらえるでしょう。
CI/CD に投資することのメリットは？
マネージャーというのは (私がそうであるように) エンジニアの幸せに注力しているものです。そうは言っても、エンジニアを幸せにすることだけに膨大な時間を費やそうというマネージャーはめったにいません。たしかに、開発者の仕事が楽になるということを考えれば、CI/CD は素晴らしい投資対象です。しかし、開発者の幸せは、CI/CD の導入という大きな決断をすることで得られる副産物に過ぎません。
CI/CD には、エンジニアの幸せ以外にも、投資の強い理由となるメリットが数多くあります。
- 複数のチーム メンバーが同じ機能の開発に参加しやすくなる。
- 大規模な変更をマージするよりも、小さな変更をマージする方がコストが大幅に低い。
- Feature ブランチという頻繁に変更される対象ではなく、自動テストに合格したシステムに対するメンバーの変更を評価できるようになる。
- QA エンジニアが一貫性のあるシステムで反復的に小規模な変更を検証しやすくなり、エラーの原因特定が大幅に簡単になる。
- 新機能の早期アクセス版を顧客に提供できるようになる。これにより、開発の方向が間違っている場合でも、わずかな労力で方針転換を行える。
CI/CD の導入に賛同を得るには、リーダーの価値観を理解すべし
エンジニアにとって、CI/CD が有意義なものであることは明らかです。コードの品質を高め、機能のリリース速度を速められるからです。機能の開発から結合、デリバリーまでの間が空いていると、本番環境のコードに不安を感じてしまうものですが、CI/CD を導入すればそうした不安が自信に変わります。
しかし、こうしたメリットは、マネージャーには直感的に理解しにくいものです。CI/CD を導入するようマネージャーを説得するには、相手の価値観に即した言葉やアイデアを使わなければなりません。本記事が、みなさまにとって説得に成功するきっかけとなれば幸いです。
