Klaverblad Insuranceにおける継続的デリバリ

継続的デリバリは，デプロイメントを自動化するためのアジャイルプロジェクトとして実施されるべきものだ。ステップの細分化によるスピードアップ，小さなデリバリによる信頼の獲得，問題の迅速な解決が必要なのだ — KlaverbladのCIOであるKim van Wilgen氏はこのように述べている。SwanseaCon 2016で氏は，継続的デリバリについての講演を行なった。このカンファレンスに関してはInfoQでもQ&Aや要約，記事などを通じて取り上げる予定である。

オランダの中堅保険会社であるKlaverbladは，以前はメインフレームを使用しており，プログラム言語はCobolだった。ビジネス上のニーズに対してサービスを提供し続けるためのソフトウェア変更が困難になったことから，すべてを刷新して新たに作り直す決断が下された。

ITシステムの新規開発は一大プロジェクトであり，適切な方法で行う必要がる，とvan Wilgen氏は言う。しかし同社の企業規模ではIT実現の予算は限られているため，ソフトウェアの開発方法に関する技術的革新が必要になった。そのために氏らは，ソフトウェア開発のアプローチの基盤としてアジャイル，DevOps，継続的デリバリ，マイクロサービスを採用することを決定した。

Klaverbladがアジャイルの採用を決めた目的は，迅速な顧客価値の提供と速やかなフィードバック獲得の手段として，デプロイを日次で実施することにある。しかしながら，手作業によるデプロイでは操作が難しく，エラーの起きる確率も高い。200を越えるマイクロサービスを個別にデプロイするのであれば，自動化が不可欠だ。これ程多くのコンポーネントは手作業では確認できない，とvan Wilgen氏は言う。同社が継続的デリバリとDevOpsを必要としたのは，そのような理由からだ。

継続的デリバリには取り組むべき十分な理由がある，とvan Wilgen氏は言う。デリバリを頻繁に実施することで，テスト範囲を狭くすることが可能になる。運用システムに対するフィードバックも速くなり，問題の早期解決にも寄与するはずだ。継続的デリバリは迅速なリカバリも可能にするので，障害発生時のダメージの抑制が可能になる。変更点が小さくなって実施が容易になると同時に，ITシステムの変更も小規模かつ直感的なものであるため，ソフトウェアユーザに対するインストラクションも不要になる。作成したソフトウェアをユーザがすぐに利用することが分かれば，チームのモチベーションも向上する。さらには，テストや品質メトリクスの完全自動化とベストプラクティスの採用によって，ソフトウェアの品質も向上するのだ。

Klaverbladをアジャイルにするには文化を変える必要があった，とvan Wilgen氏は言う。文化を変えるには新たなプラクティスの導入が必要だ。そしてプラクティスの実施にはツールが利用できる。そのために同社では，開発者やテスタに新たなツールの提供を始めた。しかしその結果は，必ずしも思わしいものではなかった。ほとんどの分岐においてテストが不完全であると同時に，モニタやログも不十分であることが分かったのだ。別のアプローチが必要だった。

継続的デリバリを開始するならば，デプロイの自動化がひとつのアジャイルプロジェクトになるはずだ，とWilgen氏はアドバイスする。機能改善を段階的なバックログとして優先順位付けを行い，最小限実行可能な製品を定義し，ソリューションの各部分を提供するステップを設定することが必要だ。

Klaverbladでは継続的デリバリ成熟度モデル(Continuous Delivery Maturity Model)を採用して，自分たちの継続的デリバリの進捗度を管理している。

この成熟度モデルは，企業が継続的デリバリを導入する上で考慮すべき主要な側面を構造化し，理解することを目的としています。

[モデルには]文化と組織，設計とアーキテクチャ，ビルドとデプロイ，テストと検証，情報と報告という５つの主要カテゴリに分類された，具体的なツールや原則，メソッド，プラクティスの採用が含まれています。継続的デリバリの実践をこれらのカテゴリに構造化し，自然な成熟度の進行を図ることで，迅速な移行と持続性のある成果を得るための強固な基盤を構築することが可能になるのです。

CIOであるvan Wilgen氏は，継続的デリバリ導入プロジェクトのプロダクトオーナとして，次に何を実施すべきかを決定する立場にある。このプロジェクトで活動するため，会社全体のチームからメンバが集まっている。チームとしての活動なのだ，と氏は言う。

継続的デリバリとはコラボレーション，すなわち共同での作業だ。継続的デリバリを実現するには多くのことを学ばなくてはならない。そのための時間が必要になる。van Wilgen氏は，同社を学習する組織にするために行なったことを説明している。氏らが行なったのは，チームをDevOpsにすること，相互学習の場としてのギルド，ハッカソン，学習イベントだ。

継続的デプロイの実施により，受け入れ試験の完了したマイクロサービスは即時デプロイ可能になる，と氏は言う。しかしながら，例えば機能が拒否されたり，マーケティング上の理由などからマイクロサービスのデプロイを延期する必要のある場合には，状況はより難しくなる。変更の実施されたマイクロサービスの一部がデプロイされ，他のマイクロサービスに対する変更が延期されることにより，結果的にビルドパイプライン上の他のステージでテストされたものとは違う構成が展開されることになるからだ。

マイクロサービスの全バージョンの組み合わせはあまりに多過ぎるので，すべてをテストすることは不可能である。そのためvan Wilgen氏は，次のようなアプローチを採用している — 即時デリバリが可能なものは機能完成時に直接デリバリを実行し，後日デリバリする必要があるものについては機能ブランチを作るか，あるいは切り替えを実施する。これにより，大部分の機能は即時デリバリ可能であることが明らかになる。van Wilgen氏は，別のソリューションを必要とする機能を“チェリーピック”して，その統合テストの実施方法を決定する，という方法を説明している。

ビジネスは継続的デリバリに対応できるのだろうか？まず無理だろう，とvan Wilgen氏は言う。望んではいても，考えてはいないのだ。彼らは物事がうまく行かなかった場合のバックアップ計画や，手作業による受け入れテスト，オペレーション説明とユーザ向け資料，変更に関するコミュニケーションを要求する。日次デリバリの妨げとなることから，ステークホルダのこのような要求に対処する必要がある。バックアップ計画は必要ない，という説明も可能だ —継続的デリバリならば問題を修正して即座にデリバリすることができるからだ，と氏は言う。変化量が小さいのでオペレーション説明は必要ない，という点も言っておくべきだ。

ステップを小さくしてスピードアップし，小規模なデリバリを重ねて信頼を獲得し，問題を早期に解決することが必要だ，とvan Wilgen氏は主張する。まずは継続的デリバリについて話すことだ。小さな実績をいくつも示して，素早く製品に反映できることのメリットを強調しよう。

品質に関する策のない継続的デリバリは無意味だ，と氏は言う。Klaverbladではコードレビューとユニットテスト，回帰テスト，統合テスト，自動および手動のユーザ受け入れテストを実施している。テストを優先順位付けして，何を今実施して何を後に回すかを決定する。重大なバグは早期に発見する必要があるので，回帰バグを見つけるためのスモークテスト(簡易的な動作確認)をまず実施する。このような小テストにより，開発者への早期のフィードバック提供が可能になる。これらテストが正常に完了すれば，変更点の完全な検査を行なうための広範かつ徹底したテストへと進むことになる。プロダクトオーナもテストに参加して，入力データの提供と自動受け入れテストの承認を行なう，とvan Wilgen氏は述べている。

継続的デリバリは技術と人が重要だ，とvan Wilgen氏は言う。作業の優先順位付けと一貫性のある機能セットを提供するためには，ITとビジネスは協働が必要なのだ。