デジタルトーク

この記事をシェア
2018.12.18

保険 保険業界が挑むアジャイル開発

保険業界で、Agile開発へのチャレンジが広まっている

 2010年前後の保険業界では、コスト低減のためのシステム基盤刷新や、ビジネスの柔軟性/拡張性を強化するためのプラットフォーム構築プロジェクトがトレンドであった。一方で近年においては、デジタル時代の到来を背景として、ビジネスモデル創出やCX向上を重視したデータアナリティクスやソーシャルメディアなどの企画・開発へとトレンドが変化しつつある。これらの開発シーンにおいては、先行する海外の影響を受けやすい外資系企業を中心に、開発手法にAgile(アジャイル)を適用しようとする例が多くなっている。

 そもそもAgile開発とはいわばリスクマネジメントの一種であり、従来のいわゆるWater Fall型の開発に比べて、ビジネス環境変化への柔軟な対応や手戻りリスク軽減といった効果が見込まれる。しかしその一方で、従来に比べてよりタイムリーで正確な情報把握、より迅速な意思決定が求められるため、当初計画通りに開発が進まず、大幅な遅延やスコープ縮小が発生してしまうケース、ひいてはプロジェクト自体が中止に至ってしまうなどの例も少なくない。それでもなお、昨今のデジタル化の影響を受けてめまぐるしく変化するビジネス環境に対応しながら競争を勝ち抜いていくためには、Agile開発を推し進めざるを得ないというのが経営層の思いであろう。

QCDのD(納期)のみ優先してQ(品質)とC(コスト)を犠牲にした超短期型Water Fall開発

 では、なぜこれほどまでにAgile開発が上手く進まないのか? “Agile開発”を彩っただけのWater Fall開発では当然うまく進まない。
 例えば以下のように。
  • 開発工程をAgileっぽくSprint分割しただけのマスタスケジュールであるため、実現性が低い(あるいは計画が検証されていない)
     
  • 業務領域毎やサブシステム毎に分割された従来のITプロジェクト向けの体制・役割の定義のため、意思決定やコミュニケーションに時間を要する
     
  • Agile開発のスピードに全然見合わない従来のガバナンスプロセスや管理標準がスケジュールを圧迫する
 一般的な保険会社のシステムにおいては、膨大な顧客情報を含む契約管理システム、複雑な商品性に対して手続不備の制御や保険料を計算するエンジン、業界共同ネットワークへのアクセスなど、大規模で複雑なレガシーシステムが多数存在する。これらの影響確認・改修・整合性確認を従来よりも短期間で対応するのだから、当然ながら品質リスクは大きくなり、障害が多発するケースが散見される。

 さらに、元々のスコープに加えて多くの障害対応をこなすためにITリソースが枯渇し、コストを投入して納期を優先することも往々にしてある。結果として、Q(品質)とC(コスト)を犠牲にD(納期)だけを優先して従来のWater Fall開発を超短期で繰り返し実行する、といったそもそも非常にリスクが大きいプロジェクト計画となっているため、上手く進まないのは当然とも言える。

 今一度思い返して欲しいが、Agile開発とは、要件が不明確もしくは未決定の状況に対するリスクマネジメント手法の1つである。にもかかわらず、経営層は「Agile開発は早くリリースできる=より早く利益(効果)を創出できる」という勘違いから非常にリスクが大きくなる判断をしているようにも見える。

Agile開発を成功させるための3つのキーポイント

(1)やみくもに全てをAgileで開発しようとしない
  • プロジェクトスコープがAgile / Water Fallのどちらの開発手法に適合するのか正しく判断する
     
  • Agile / Water Fallでスコープ分割が可能
     
  • Hybridと判断されるケースが多くなるかもしれないが、Hybridは品質を担保するためのコントロールが困難であるため、ある程度割り切って要件を分割して対応することがリスクが小さくなり望ましい
     
(2)従来のガバナンス/標準に固執しない
  • むやみに多くのステークホルダーを参画させず、ステアリングコミッティなどのマネジメントの確認・承認プロセスを重たくしない(=能力のあるリーダーに意思決定権は委ねる)
     
  • 従来の標準を無理やり適用しようとせず、例外を許容する
     
  • 従来と同等の成果物や報告を求めない
(3)QCDのコントロール方針を明確にする
  • 要件の優先度判断はユーザー部門が主体で行うが、プロジェクト目的との紐づけや効果の早期実現(=Quick-Win)を考慮してスケジュールを策定する
     
  • 要件の整合性や充足性を担保するため、確認/検証のマイルストンを設定する

PMOの活躍の場はまだ残っている

 お気づきだとは思うが、Agile開発においては従来のようなPMOのポジションは存在しない。では、今後、PMOは縮小していくのだろうか?

 Agile開発をスタンダード化するためには、Agile開発にチャレンジして得られたノウハウやナレッジにより、既存のガバナンス/標準をAgile開発向けにブラッシュアップする必要がある。さらには、ガバナンスの観点から、それらの新しくブラッシュアップした標準を遵守/活用できているかモニタリングすることも求められるようになってくるであろう。

 そこで登場するのがPMOである。彼らは、既存のプロジェクトマネジメント標準のオーナーであり、整備・展開・統制の役割を担ってきたノウハウやナレッジを有しているはずである。新たな標準が活用されるまでには十分活躍する場が残っているため、熟成された既存の標準を利用したマネジメントだけの役割からの脱却を期待したい。Agile開発が1つの手法としてスタンダード化するのはいつになるだろうか。

パートナー 井上 健

国内大手製造業のIT部門を経て、現職。
製造業・金融業を中心に、業務改革、IT改革などの大規模プロジェクトにおいて、計画・実行・マネジメントまで幅広く多数ご支援。
社内の保険業界プラクティスのコアメンバー。