生命保険業界におけるアジャイル・DevOps活用の意味と課題

記事をシェアする:

生命保険は他業種に比して超長期のライフ・サイクルを特徴とする保険商品を、契約期間を通じて支払不備等を発生させる事なく安全、高品質なサービスとして提供する事が求められます。このためIT組織の変革や、新しい手法への取り組みにおいても極めて慎重に対応する事が要求されます。一方、下図に示すように、販売チャネルの多様化や、新規参入による競争の激化（ライバルの変化）、デジタル・ネイティブ世代への対応といった諸課題に対応する必要があります。

保険業界を取りまく諸要素

IT業界全体におけるクラウド・シフトという大きな流れの中で、デジタル変革 (DX)の推進や顧客体験 (CX)の向上により競争優位性を獲得するためには迅速、かつ柔軟性を持ったIT組織に変革する取り組みが重要であり、これにはアジャイル開発やDevOpsといった開発手法, アーキテクチャにおけるマイクロサービスやMVVM (Model/View/View Model)、開発標準におけるHTML Living Standard等、多くの先進的要素を組み合わせて活用する事が必要となります。今回はアジャイル開発、DevOpsにフォーカスし、これらをうまく活用して効率的な組織、プロセスの構築を実現するためのポイントや課題について考えてみたいと思います。

1.アジャイル開発

メインフレーム開発の時代から、一般的なエンタープライズ・システムの開発にはウォーターフォール型（局面化）開発手法が採用され、ミッション・クリティカルなシステム開発の現場で継続活用されています。ウォーターフォール型開発手法が採用される最も大きな理由は、各局面ごとの完了基準を設ける事で、局面を跨った手戻りを防ぎ、大規模プロジェクト開発における「品質 (Quality)」「コスト (Cost)」「スケジュール(Schedule)」、いわゆるQCDを確保する事にあります。加えて各局面ごとに契約を区切り、より精緻なコスト見積もりに基づいて開発を進めることも可能であり、現時点においてもその重要性は低下していません。

一方ウォーターフォール型開発は、多くの開発者間で完了基準を確認する目的も含めてドキュメントが重視される開発スタイルであり、膨大なドキュメントの作成が要求されます。また、局面化による品質・スケジュールの確保のためにも、変更要求は厳密に管理されるため、長期の開発途中で発生する変更要求に柔軟に対応する事も難しいといったデメリットがあります。これは大量に生成された各種ドキュメントの変更も必要であり、膨大なワークロードをかけて成果物の保守を実施する必要があります。またドキュメントの保守を怠る事で、ソース・コードと設計書の仕様乖離の発生といった問題も多く発生しやすい仕組みとなっています。

こうしたウォーターフォール型開発の硬直性に対し、エクストリーム・プログラミング (XP) や、テスト駆動開発等でも有名なKent Beck¹氏らがアジャイル・ソフトウェア開発宣言 (Agile Manifest)²を起案しました。

1. プロセスやツールよりも個人と対話を、
2. 包括的なドキュメントよりも動くソフトウェアを、
3. 契約交渉よりも顧客との協調を、
4. 計画に従うことよりも変化への対応を、

このアジャイルの精神に則った開発プロセスとして、有名なものにスクラム（Scrum）があります。スクラムでは、5人から9人のチームをスクラム・マスターがプロセスへの準拠を管理・保証し、顧客側の要件を取りまとめるプロダクト・オーナーと一丸となって開発を進めるスタイルをとります。またスクラムではテスト駆動開発をベースとした繰り返しによる機能の拡充を特徴とし、この繰り返し開発の単位をスプリントと呼んで管理します。このように、アジャイル開発は、ドキュメントよりも動くソフトウェア（ソースコード）を重視し、スプリントの反復開発によって変更要件を柔軟に取り込む仕組みを提供し、特に変更・新規要件の多い、コンシューマー向け開発等に適した開発プロセスとして人気を博しています。

では、旧来型のプロジェクトも全てアジャイル開発で置き換えることは可能でしょうか？　これは非常に困難であり、特に金融における大規模開発では難しい課題をクリアする必要があると考えます。まず、アジャイル開発では小規模な開発チームに単位を分割する必要がありますが、月あたり200人以上の開発者が参加するような大規模開発では、スクラム・マスターは20人、顧客要件に責任を持つプロダクト・オーナーも20人と必要になります。やはり大規模開発案件では、従来型ウォーターフォールで開発を進め、サービス・イン後の保守開発案件においてアジャイル開発にアプローチする、といったやり方が一般的です。アジャイル開発は、非ドキュメント志向や小規模チーム開発といった特徴の他に、テスト駆動開発、継続的インテグレーション/デリバリー (CI/CD) といった特徴を合わせ持ちます。これらはウォーターフォール開発においても適用可能であり、大きな力を発揮します。

ウォーターフォール型開発 vs アジャイル開発

2.DevOps、CI/CD (Continuous Integration/Continuous Delivery) ツール

加速するシステム化要求に迅速、かつ柔軟な応答を行うために、これまで行われて来た開発チーム、運用チームといった縦割り型のIT組織を見直し、統合的なシステム開発・運用を実現するDevOps と呼ばれる開発手法が重要な位置付けを持っています。DevOpsとは、開発 (Development) と運用 (Operations) を掛け合わせて作られた言葉であり、開発・運用の一連の流れを自動化によって効率化する手法の事です。そして、DevOpsにおいて一連の自動化を実現するためのツール群を継続的インテグレーション・デリバリー (CI/CD) ツールと呼び、ソース・リポジトリのGit³や、ビルドからモジュール配備までの一連のパイプラインをスクリプト化するJenkins⁴やTekton⁵, テスト自動化ツールであるJunitやSelenium等がこれに該当します。

これらDevOps, CI/CDはアジャイル開発と共に育ち、相性の良い開発プロセス、ツール群ですが、アジャイルに特化したものではなく、旧来型の大規模エンタープライズ開発にも適用する事が可能です。ウォーターフォール型開発の局面化によって、要件定義からマクロ・マイクロ設計レベルまでを従来型の手法でこなし、開発からテストまでの実装フェーズにこれらの考え方を取り入れて、いくつかの反復（イテレーション）フェーズを設けて品質を確保する方法は、全てをアジャイル開発で実施する事に比べ、エンタープライズ開発との相性も高いといえます。この実装フェーズには、CI/CDツールをうまく活用する事により、開発効率の向上を期待する事が出来ます。

実装フェーズにおけるDevOps, CI/CDツールの採用

3.おわりに

冒頭に説明した通り、大きな変化の波と、新しいチャネルでの競争を余儀なくされる生命保険業界では、アジャイル開発との親和性が高いDevOps、これを支えるCI・CDツールの有効活用により、従来からの開発プロセスを改善し、コスト効率改善と品質の維持を実現する事が必要です。こうした取り組みによって、IBMのGlobal CEO Study 2021⁶で指摘される以下の最重要課題への対応にもつながります。

• 明確な目的を持ったアジリティーの推進
• テクノロジーの更なる重要性
• 新たな法規制への対応

今回はプロセス改善への取り組みにフォーカスして説明しました。次の機会では、新しいアーキテクチャの採用と、HTML Living Standard等の業界標準への準拠、及びデファクト・スタンダードとなっているフレームワークの採用基準といった点についてお話したいと思います。

 
¹https://ja.wikipedia.org/wiki/%E3%82%B1%E3%83%B3%E3%83%88%E3%83%BB%E3%83%99%E3%83%83%E3%82%AF
²https://agilemanifesto.org/iso/ja/manifesto.html
³https://git-scm.com/
⁴https://www.jenkins.io/
⁵https://www.ibm.com/jp-ja/cloud/tekton
⁶https://www.ibm.com/thought-leadership/jp-ja/institute-business-value/c-suite-study/ceo/