課題を力に未来を切り開く！SBI生命のDXに向けた内製化への挑戦

1. なぜシステムの内製化なのか　

1-1. 時代の変化に追随する ー
　　 DXを進めるには「スピード」と「柔軟性」が重要。内製化はその手段

SBI生命は1990年に創業し、信頼と実績を積み重ねてきた生命保険会社です。2015年2月にSBIホールディングスの資本を受け同年5月に現社名に変更し、2016年2月には新商品での営業を開始しました。以後、個人向け保険ではインターネットで完結できる定期保険のほか、医療保険、就業不能保険など、時代のニーズに応える商品やサービスを中心に提供しています。また、2017年からは住宅ローンを組まれる際に加入される団体信用生命保険、団体信用就業不能保障保険を金融機関に提供しております。

SBI生命のシステムでは内製化を積極的に進めています。この理由には時代の変化があります。DXという言葉をよく聞くようになる前と今では、システム開発の目的が変化していると私は捉えています。

かつてのデジタル化やIT化は、必要性または業務効率化や業務改善が中心でした。我々もそうでしたが、システム部門はこういうものを作ってねと言われて対応する。要件を定め一定の時間をかけて作るシステムは、我々のような事業会社から協力会社やベンダーへ、ある意味一括発注でも問題が無かったように思います。

これに対し、今のシステムはビジネス変化に素早く追従することが求められます。DXを進める、つまりDX化をはかり、新しい価値を提供して、競争上の優位性を確立することが必要と考える企業は多いと思います。この目的を達成するためには、DXを推し進めるスピードと柔軟性が必要なのではないかと考えております。これを実現する手段として、社内にノウハウを持つ内製化が最適だと我々は考え、内製化を進めてまいりました。

1-2. SBI生命におけるDX事例 ー DX、クラウド、そして内製化

SBI生命の本格的なDXは「声」に着目した施策から始まり、これがクラウド化にもつながっています。

お客様との接点には色々ありますが、我々は声を中心にタッチポイントを増やしていきたいという施策があります。声を使ったシステムには、やはりクラウドが必要だろうということで、Amazon echoを使ったお問い合わせ機能、通知機能、そして見積もり機能の開発に着手し、2019年から順次提供を進めました。最初は試行錯誤だったクラウドでしたが、利用しながらノウハウを溜め、現在は企業方針としてAWS（アマゾン ウェブ サービス）を中心としたクラウドへのシステム全面移行を進めております。

今はAI活用にも着手しています。昨年2023年には、検索エンジン（Amazon Kendra）と生成AI（GPT-4）を用いたコールセンターのオペレーター向けセルフボットを開発しました。オペレーターが質問を入力するとAmazon S3から約定やパンフレット、FAQ、規定などを検索し、対象文書や要約をボットが返す仕組みです。経験が少ないオペレーターの対応品質向上、スピード化を支援し、オペレーターレベルの平準化を狙った施策です。

声のサービスでのAI活用にも取り組んでいます。いきなりお客様向けの利用は大変ということで、昨年は社内サービスデスク業務のAIオペレーター対応を試みました。メインは、社内問い合わせが最も多い、Windowsアカウントロック解除の電話対応です。Amazon Connect VoiceIDにより、声紋での本人確認や監査上必要なリクエストチケット起票までの一連のプロセスを完全自動化しました。また、アカウントロックに限らず、問い合わせ数上位のものは、電話を人につなげる前にFAQを音声で回答する機能も作成しています。

これらのDX事例はいずれも内製化での開発です。内製化のメリットは、システムの継続的なブラッシュアップ時にスピードと柔軟な対応がとれる点にもあります。

先般、コールセンター向けセルフボットで用いていたGPT-4をGPT-4oにバージョンアップしました。また、サービスデスクAIオペレーターのFAQで採用したClaude InstantをClaude3 Haiku へバージョンアップしました。これにより、 これまで以上にスピーディな対応を実現していますが、いずれもわずか約2週間での導入です。これらの短期間での対応は、内製化のメリットが非常にあったなと感じるところです。

2. SBI生命は開発の内製化をどのように進めたのか

2-1. SBI生命における内製化の歴史 ー DXに向けた三つのステップ

内製化をしようと決めても、いきなり何もかもを対象にするのは難しいことです。チャレンジしてもうまくいかなかったり、どのように進めて良いか分からないということもあるかもしれません。ご紹介したDX事例も、内製化したからすぐに出来たと言うわけではありません。ここでは皆さんの参考にもなるように、どのような進め方をしたのかをご紹介したいと思います。

SBI生命では、ステップを三つに分けるように内製化を進めてきました。

最初の取り組みは、SBIグループの一員となった当時までさかのぼります。この時点から内製化を意識していました。SBI生命には団体信用生命保険（団信）領域と個人保険領域がありますが、それぞれでアプローチを変えています。
団信領域は、ゼロベースからでしたので、開発・運用共に協力会社の支援を受けながらの内製化としました。基幹システムを含めて全てスクラッチ開発です。
個人保険領域は、既存のシステム資産も多々ありましたので、ここは既存を活かし、社内周辺システムや、請求支払システムなどを内製も交えながら進めることにしました。無理はせず、できる範囲でやるという進め方です。

内製化開発の形ができ始めたら、次は今後のプロジェクトへの内製化適用方針を立てる必要があると考えました。検討の結果、やはり全てのプロジェクトを内製化するのは難しい。そこで我々は、上流工程である要件定義や設計フェーズのプロジェクトコントロールは内製化実施を譲らない事項としました。プログラム開発やテストは、適宜に協力会社やベンダーにお願いする形です。この上流工程と下流工程を、うまくバランスを取りながら進めることをプロジェクトの方針としたわけです。

プロジェクト方針が決まったら、いよいよDXの推進です。我々は現在AI活用や全面クラウド化にも邁進しております。これらの新規構築では、導入する最新技術の更新もかなり必要になります。そこでこれらについては最新技術の導入方針、システムアーキテクチャ設計、開発・テストを含め、全て内製化を基本として対応しています。こうすることによって、先ほどの事例も含め、短納期で柔軟性を持ちながら機敏性のあるシステムリリースができるようになりました。

2-2. 内製化を阻む障壁 ー 乗り越えるべき三つの課題

実際に内製化を進めるにあたっては色々な課題があり、それらと向き合い解決策を模索しながら進める必要がありました。当初は現場からのネガティブな声がかなり上がりました。これは社内だけでなく協力会社やベンダーからもです。また進めていく中で出てきた課題もあり、今も試行錯誤を続けています。これらの課題を整理すると三つに分けられます。

一つ目は「ナレッジ」です。プロジェクト推進や開発に関する知見やノウハウが溜まっていない。ナレッジが溜まっていないので、つい外部に頼ってしまう。内製化と言われても、やり方が分からない。というような課題です。

二つ目は「人的リソース」です。これは、内部のリソースだけでは不十分ということです。対応できる人が限られることから、特定の人に業務が集中してしまったり、結局、既存システムを作成した協力会社に依頼してしまうなどの課題がありました。

そして三つ目は「システム」です。システムがブラックボックス化していて最適化されていないことに起因する課題です。例えば、既存システムは煩雑で影響範囲が不明という理由から、良くないと分かりつつも別の機能を追加で開発し、さらに複雑化させているものがありました。また、類似機能を作るのに複製を繰り返したことでシステムを肥大化させ保守性を低くしているケースもありました。システム影響範囲の調査にはプロジェクトの都度に時間がかかり、スピード感を持った開発ができないという課題は根本から見直す必要がありました。

2-3. 課題を力に ー 課題解決に向けた三つの動き

我々は色々な取り組みをしていますが、内製化の課題解決に向けた動きを三つに集約してご紹介します。

一つは「DXに向けたプロジェクト進行方針の決定」です。やり方が分からないという迷いから脱却するためにも、スピードを意識したシステム開発方針の確立が必要だと考えました。
次いで「システム開発体制の再構築」です。これは保守・運用を含みますが、特定の人や特定の協力会社に依存しない、ノウハウが共有できる開発体制の構築が必要と考えたわけです。
そして「既存システムの見直しと改善」です。保守性の向上やクラウド化、コスト削減を意識したシステム構築です。

これらの動きが、内製化をさらに進め、スピードと柔軟性を持ったシステム提供を実現すると私は考えております。そこで、それぞれの動きの中でも特に重視している「アジャイル開発」「マルチベンダー化」「マイクロサービス化」について、具体的なところを少し説明させていただこうと思います。

3. DXへ向けた内製化を推進する三つの取り組み

3-1. DXへ向けたプロジェクト進行方針の決定 ー アジャイル開発、アジャイル的な発想

DXに向けたプロジェクトの進行ではスピードと柔軟性が必要なことから、開発方針として我々は「アジャイル開発」が必要だと結論付けました。アジャイル開発はトライ＆エラーに対応でき、ローンチ時期を柔軟に決定できるのが魅力です。いきなりアジャイル開発と言われると迷いもあると思いますので、我々の適用ポイントをご紹介します。

まずは、今までの開発概念の払拭が必要です。端的に言うとウォーターフォール開発からの脱却です。これは否定ではなく、開発は「ウォーターフォールだけではない」という理解とスピード開発の意識が必要ということです。開発はアジャイル技法に固執するものではなく、私はウォーターフォールとアジャイルの良いところを取って進めていければ良いと考えております。

次は、新しいことへチャレンジする「やってみよう」の実践です。誰かがやってみるのを横目で見ながら待っているメンバーが結構いましたので、失敗しても良いからまずはやってみようという声をかけあいました。また、スモールスタートを意識しました。スモールスタートであれば失敗は軽微になりますし、成功体験がすぐに積み上がってきます。失敗もより小さな成功と失敗に分けて見ていくようにしました。

アジャイル開発の感覚をつかんだら、アジャイル発想の理解を深める必要があります。特にアジャイルの開発サイクルとなるスプリント定義の決定方法は重要です。この理解が、アジャイル的な発想でのウォーターフォール的な開発にもつながります。

2年ほど前にAWS上に作成した次世代DWHとBI展開はアジャイル的発想で進めた例の一つです。ユーザー自身での分析や業務効率化を目的にBIツールの全社展開を行いましたが、全部門が対象ですのでウォーターフォール的に一斉公開とするとUAT（受け入れテスト）が大変ですし、失敗や戻りのリスクも上がります。そこで、全10ヵ月のプロジェクトを2ヵ月サイクルの5th スプリントとし、2ndスプリント以後は2ヵ月ごとにユーザーへ提供する計画としました。各スプリントの2ヵ月間はウォーターフォール的な進め方です。ただガチガチではなく、7週目までに開発とUATが終わっていれば良いという柔軟性を持たせました。スプリントの進捗を確認しながら、常に新しいものを適用して柔軟に修正するアジャイル的発想で進めたこのプロジェクトは、とてもスムーズに進みました。ぜひ、このやり方は皆さんにも参考にしていただければと思います。

3-2. システム開発体制（運用・保守）の再構築 ー
　　 主体を内製においたマルチベンダー化へのチャレンジ

運用・保守を含むシステム開発体制の再構築について。こちらは、内製化すると言っても、外部企業の協力がどうしても必要です。そこで1社に頼らない、マルチベンダー化に取り組みました。マルチベンダー化であれば状況に応じた体制の構築ができますし、色々なアイデアの創出もでき、スピードと柔軟性を持てると考えました。ただ、これは非常に難しいことです。

新しいことに取り組むにあたって、我々も協力会社も同じような状況でしたので、我々も伸びて、協力会社も伸びたいというような発想を持ちました。このため、1社への依存はリスクがあります。協力会社には、そこも理解していただくために、「内製化は失注ではないよ、失注リスクの軽減だよ」と私からもですがメンバーからも言い続けました。こうして、一括発注から内製開発へのシフトを段階的に進めていきました。

これが定着すると、バランスの取れた開発の体制を求めやすくなります。ただし、ベンダー間の役割範囲の線引きのようなものがどうしても出てきてしまいます。このセクショナリズムの排除は諦めずに言い続けていることです。ベンダーロックオンからのマインドチェンジにより1社に偏らないシステム開発体制を構築できるはずだと考えています。

とはいえ、大規模システムでは一括発注を是としました。以前と違うのは先ほどお話ししましたとおり、システム要件定義、アーキテクチャ設計は内製で行いノウハウは自社に残すということです。全部内製ではなくて、メリハリをつけた体制での開発です。このメリハリに、マルチベンダー化による柔軟性やリスクヘッジのメリットが組み入れられると良いと思っておりますが、やはり大変なことでして、ここは関係者と一緒に考えていきたいテーマにもなっています。

3-3. 既存システムの見直しと改善 ー マイクロサービス化の推進

我々は、既存システムの見直しと改善にあたり、マイクロサービス化を進めています。マイクロサービスは柔軟性が高くスピーディな開発ができます。影響や修正範囲を軽減し、コストも削減します。また、様々なAPIのサービスやSaaSとも容易に連携できるようになります。

当初、対応しやすいシステムから着手するとしましたが、どこが対応しやすいのかが分からない。そこで、既存システムの調査をまず実施しました。これは、すごく大変でした。ドキュメントだけでの理解は難しく、地味ですが一つずつソースを見ていきました。使用しているデータベースのテーブルの把握も行いました。

調査を行うと色々なことが見えてくるのですが、何と無駄な処理が結構あるんです。この頃には既に中身が分かっていますので、保守性をあげるためにも無駄を排除して処理をしやすいように既存システムを修正することにしました。また、この対応を進める中でマイクロサービス化をした方が良いシステムや処理を選定していきました。

将来へ負債を残さないためにも、オンプレミスからクラウドへ移行し、マイクロサービスをAPIで連携する、つまりレガシー脱却を意識しました。そして、コストを意識した再設計・再構築でのマイクロサービス化です。具体例を二つご紹介します。

一つは内製で開発した団体信用生命保険の基幹システムである団信システムです。これをマイクロサービス化し、業務機能単位にモジュール化しました。これにより、それぞれの機能単位に修正ができ、それぞれは密結合ではなく疎結合ですので、そこ単体だけでテストできる、非常に効率的な形になりました。

もう一つはバッチ処理のマイクロサービス化です。バッチ処理のシェルは、まず1本作ってそれをコピーして作る形が一般的だと思います。我々もそうでして、この手のバッチが大量にありました。そこで、これらは共通部品を作りAPIで呼び出す形にしました。するともうシェルの開発は不要で開発は共通部品だけ。あとは、パラメーターと機能フローのコントロールだけでバッチ処理ができてしまう。これは非常にシンプルで保守性も高く、コスト削減のメリットも得られてお勧めです。

4. 開発の内製化に取り組む皆さんにお伝えしたいこと

経験を中心にお話をしてまいりましたが、皆さんがシステム開発の内製化を進める参考として最後に少しまとめです。
つらいけど現状把握です。お話ししましたとおり地道にでもやる必要があります。
システムは、アジャイルの発想で取り組む。アジャイル的な発想でも良いですね。ウォーターフォールだけではなく柔軟に進める良さをお伝えさせていただきました。
組織作りでは、やはりベンダーロックをしない体制の構築が大切ということを改めてお伝えいたします。
そして実際の着手はスモールスタートです。最終的にはスケジュール、コストを意識したプロジェクトの推進が必要と私は考えております。

DXを進める上で内製化は意味のある取り組みです。とはいえ皆さんが内製化に取り組まれ、うまく回り始めるまでには、色々と大変なことがあるだろうなとも思っております。これを乗り越えるには勇気、根気、努力の三つの気持ち。勇気を持って着手して、根気よくチャレンジして、そして努力をしながら最終的には内製化開発とDX化を進めていく。この前に進もうとする強い気持ちが非常に大事だということも最後にお伝えさせていただきます。