厳格ルールで進めた新規事業DX
“金融レベル”が壁に 東京海上ディーアールが「小さな失敗」を成功につなげた方法
東京海上ディーアール(TdR)は、現場起点でDXを推進し、新規事業の立ち上げへと取り組みを拡大した。自社や業界特有のルールや新規事業の不確実性をどのように成果へつなげたのか、担当者に聞いた。
DX(デジタルトランスフォーメーション)を進めようとしても、自社のルールに阻まれて新しいシステムを導入できない。ようやく開発を始めても、新規事業なので何をどこまで作ればいいのか正解が分からないといった場合がある。
東京海上ディーアール(以下、TdR)が進めてきたDXも、こうした壁と無縁ではなかった。同社は、リスク評価・コンサルティングを担う現場部門「企業財産本部」が段階的にDXを推進。現地調査のデジタル化、クラウド活用、サーバレス化、API化を通じて、業務効率化から外部向けサービスの開発へと取り組みを広げてきた。
しかし、その道のりは一直線ではなかった。保険会社グループとして求められる重厚なシステム開発・運用ルールと、新規事業に必要なスピードをどう両立するか。仕様が定まっていないサービスに、どこまで投資するか。PoC(概念実証)が期待通りの成果を出さなかったとき、次にどう動くか――。同社では、具体的に何をしたのか、担当者に話を聞いた。
厳格なルールと新規事業のスピードをどう両立した?
TdRは2021年、「東京海上日動リスクコンサルティング」から現在の社名に変更した。「d」には「Data」(データ)、「Digital」(デジタル)、「Design」(デザイン)の3つの意味が込められている。社名変更を機に、社内ではデジタルを中心とする取り組みを積極的に進める気運が高まった。
TdR 企業財産本部 副本部長 工藤智宏氏によると、当時、全社のICT部門はセキュリティをはじめとする「守り」を主に担っていた。一方、顧客のリスクを評価する企業財産本部では、社名変更以前からデジタル技術を使った業務効率化を進めていた。
そこで同社は、顧客ニーズを最もよく把握している現場からDXを始める道を選んだ。「お客様のニーズをつかんでいるのは現場」であり、現場起点で始める方がうまくいくとの判断だったと工藤氏は語る。
現場の挑戦を後押しした仕組みもあった。会社が費用の一部を負担し、本部発のデジタル施策を支援する「チャレンジ枠」だ。この制度によって、新しい取り組みに比較的柔軟に予算を付けられる環境があった。
全社推進の取り組みだったこともあり、DXそのものへの強い反対は社内にはなかった。ところが、実際にプロジェクトを始めると別の壁が見えてきた。
立ちはだかった「金融レベル」のルール
TdRは東京海上グループの一員だ。そこで立ちはだかったのが、保険会社グループ特有の重厚なルールだ。今回のような金融とは直接的な関係のない新規事業に対しても、システム開発や運用、セキュリティなどに関して、金融機関に求められる水準を前提としたルールが存在していた。
もう1つの壁は、仕様や要件が最初から定まっていない新規事業ゆえの難しさだった。新しいサービスを始めようとすると、「これまで想定していなかったケース」が次々に出てくる。既存のルールとの兼ね合いをクリアしながら、正解の見えない新規事業をどのタイミングで、どこまで形にして前へ進めるか。その判断が、取り組みの随所で求められたのだ。
そこでTdRは、法務やICT部門などを巻き込み、必要に応じてグループ全体の仕組みにまで働き掛けながら、1つずつ問題を解消していった。
最初から全ての障害を予測できていたわけではない。工藤氏は「正直、何が起こるか分からない」という認識だったという。
だからこそ、問題が発生するたびに対応した。そして一度経験した問題は、次のプロジェクトでは事前に想定できるようになった。最初の挑戦で壁になったポイントを覚えておき、2回目以降は先回りして避ける。失敗や苦労そのものを、次の判断材料に変えていった。
業務効率化の次に「外へ売る」を選んだ
一定の業務効率化を実現した後、工藤氏らが次に見据えたのは、新たな収益源の確保だった。「新たな収益の元を探すには、外に出ていかなければならない」(工藤氏)という考えの下、TdRが保有するリスクデータをAPIで提供するサービスの開発が始まった。
同サービスについて工藤氏は、「新規事業として、既存のコンサルティングをシステムで解決する領域に広げて、そこに既存の知見を差し込んだ」と話す。災害発生時の対応など、人の力だけでは難しい領域に対象を絞り、そこに地震や水災などの評価ロジック等、従来のコンサルティングで蓄積した知見を組み合わせた。この取り組みは外部へのサービス提供だけでなく、東京海上グループ内でのデータ流通やシナジー創出にも波及しているという。
一方、問題もあった。API連携サービスの開発は、既存業務のシステム化ではなく新規事業だ。顧客が何を求めるのか、どこまで作ればサービスとして成立するのか。最初から明確な仕様書を作れる仕事ではない。
さらに、保険会社グループ特有の厳格なルールと折り合いを付けながら、アジャイルな開発のスピードを維持するかも課題となった。
最初から「本番環境」を作らない
こうした不確実な新規事業を支援したのが、DXコンサルティング企業のチェンジだった。同社取締役兼執行役員 New-IT事業部 事業部長の大出義広氏によると、同社は以前からTdRのDX戦略策定を支援してきた。複数部門へのヒアリングやロードマップ策定を通じて、社内の事情やキーパーソンとの関係を築いていたのだ。
チェンジは、単なる受託開発にとどまらず、構想段階のブレインストーミングや他社事例のベンチマーク提供、グループ内外の利害関係者の調整も担った。大出氏は、状況の変化を見ながら判断と行動を繰り返す「OODAループ」を、TdRとともに回すことが重要だったと振り返る。
結果的にTdRは、チェンジのクラウド環境を活用した「2段階アプローチ」を選択。最初からグループ標準の堅牢(けんろう)な本番環境に構築するのではなく、まずはチェンジ側の柔軟な環境下でMVP(実用最小限の製品)を構築してPoCを素早く回した。
移行時には、システム環境やデータ連携など新たな壁も現れた。それでも、「まず柔軟な環境で試す」「確かめてから堅牢な環境へ持っていく」と工程を分けることで、新規事業に必要なスピードと既存システムに必要な慎重さを両立させた。工藤氏は「最初にチェンジが作ったフレキシブルな基盤で検証してから、当社グループの堅牢な基盤に引っ越しをした。結果的によかった」と説明する。
プロジェクトマネジメントを担当した、チェンジ mirai事業部(新規事業開発部)和田 巌氏によると、「基盤移行を支援する中で現場の推進力と連携できた」という。さらに、段階的な移行がリスク低減に寄与したと語る。
失敗もあった それでも止めなかった
もちろん、PoCを繰り返せば全てが成功するわけではない。全てのPoCが想定通りに進んだわけではない。
しかしTdRとチェンジは、それを「プロジェクトの失敗」とは捉えなかった。ルールとの調整、PoC、基盤移行などで経験した問題を蓄積し、次の挑戦ではあらかじめリスクを想定する。そうすることで、判断の精度を徐々に上げていった。
TdR パートナー 企業財産本部 本部長の佐藤一郎氏は、「何もしなかったら次はできない。失敗を早くした方が絶対に成功につながる。壁が分かったことが一番の成果だ」と語る。
大出氏は、こうしたDXの進め方について「早めに小さな失敗をして、致命傷を負わないようにしながら、自分たちが正しいと思うことを選択して、顧客との関係に変化を生み出していくことが重要」だと話す。
全ての選択が正しかったわけではない。それでも、「何もしない」という選択を続ければ、次の挑戦は生まれない。
実際、取り組みを続けたことで、TdRには技術や人材が蓄積しただけでなく、当初想定していなかったグループ内でのデータ活用や関連サービスへの展開も生まれた。
一方、今も解消していない問題はある。新規サービスは何が起きるか完全には予測できないため、開発側は一定のリスクバッファーを見込む必要がある。それがコストに跳ね返る問題は残っている。
つまり、このDXは「全ての課題を解決して成功した物語」ではない。新しい壁が現れるたびに、その時点でできる判断を下し、小さく動いて結果を次の判断につなげてきたプロジェクトである。
Copyright © ITmedia, Inc. All Rights Reserved.
この記事の著者
関連記事
新着ホワイトペーパー PR
-
製品資料
[株式会社kickflow] 2社の事例に学ぶワークフロー改革:属人化解消や年数万件の申請書類削減のコツ -
製品資料
[NTTPCコミュニケーションズ株式会社] 「回線速度不足」だけが原因ではない? Web会議の遅延を解決する方法とは -
製品資料
[東京エレクトロン デバイス株式会社] 工場の可用性向上に重要な「7つの領域」と対策 OTセキュリティ強化の基礎知識 -
製品資料
[リコージャパン株式会社] 問い合わせ対応で本来の業務が進まない、総務や情シスの負担をどう減らす? -
製品資料
[リコージャパン株式会社] 自社データから高精度な回答を生成、簡単に生成AIチャットボットを構築する方法
こんなメディアも見られています
TechTargetジャパンに関連する情報をお探しであれば、こちらのメディアもお役に立てるかもしれません。
ベンダーコンテンツ PR
From Informa TechTarget
SpecialPR
アクセスランキング
-
1
全社標準Copilotに絶望? MS Copilotで問い合わせ6割減できた企業は何が違った
-
2
ITエンジニア1265人調査 生成AIを使い込むほど「人の確認」が重い理由
-
3
Microsoft製品でここまで自動化できる 情シスがやめられる手作業10選
-
4
脱VMwareの前提が崩れる BroadcomのVDDK公開停止で確認すべき点
-
5
業務影響を抑えた“小さなPoC”から始めるVPN見直し
-
6
「Copilot」はなぜ放置される? “議事録要約止まり”を脱する処方箋
-
7
「Microsoft一択」で本当にいいのか 知らぬ間にライセンス費用が膨らむ真相
-
8
APIキー奪取から3時間でクラウド掌握 Anthropicが暴いた「バイブハッキング」の現実的な防御策
-
9
「Wi-Fi 7」は何がすごい? Wi-Fi 5、Wi-Fi 6からの抜本的な進化とは
-
10
【基本情報技術者試験】「デュプレックスシステム」と「デュアルシステム」の違いは?
ホワイトペーパーランキング PR
-
1
5回聞くだけじゃ足りない? トヨタ式「なぜなぜ分析」の正しい実践方法
-
2
JR西日本ITソリューションズが「監視業務の属人化」を解消した方法とは?
-
3
生成AIで文書活用を進めるには? 効率化と安全性をどう両立する
-
4
Windows PCとMacの選択制で生産性向上 LINEヤフーが実践する運用管理方法とは
-
5
インシデント対応工数を約3割削減、東京ガスの事例に学ぶ監視体制刷新のコツ
-
6
国税庁の次世代基幹システム「KSK2」稼働開始に向けて、対応すべき変更点とは?
-
7
「スクラム」と「カンバン」の違いとは? アジャイル型開発手法を徹底比較
-
8
AI時代に成功するための「ナレッジマネジメント」ベストプラクティス
-
9
「オンプレミス回帰」せざるを得ない“合理的な理由”
-
10
Microsoft 365を安全に運用 うっかりミスやサイバー攻撃に備えるデータ保護術
TechTargetジャパン SNS
インフォメーション
注目情報をチェック
TechTargetジャパンをフォロー