厳格ルールで進めた新規事業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
-
製品資料
[株式会社うるる] 「入札市場」攻略ガイド:効率的に落札するためのポイントを徹底解説 -
製品資料
[株式会社うるる] 入札情報に特化した「販路拡大」「効率化」のためのサポートツールとは? -
市場調査・トレンド
[株式会社うるる] 公共入札に成功する企業と失敗する企業の「5つの違い」 -
製品資料
[日本ビジネスシステムズ株式会社] 専門家が教える、Microsoft 365の「テナント統合/分離」を成功に導く秘訣 -
製品資料
[rakumo株式会社] Microsoft 365での情報埋没を防ぐ、社内ナレッジを資産化する情報ポータル活用
こんなメディアも見られています
TechTargetジャパンに関連する情報をお探しであれば、こちらのメディアもお役に立てるかもしれません。
ベンダーコンテンツ PR
From Informa TechTarget
SpecialPR
アクセスランキング
-
1
半数がブルーカラー転向を視野に? ベテランエンジニアを追い込む“54歳の壁”
-
2
「Windows」の不要なファイルを安全に消して容量を空ける方法
-
3
PHP脆弱性「PHP2Shell」で2260万件に影響 情シスの緊急チェックリスト
-
4
「Microsoft 365」が乗っ取られる MFAを破る“本物の画面”の恐怖
-
5
なぜ「Gemini 4 Argon」は出遅れたのか? Googleが狙う“逆転のシナリオ”
-
6
「IT運用・情報システム業務」に関するアンケート
-
7
OpenAIやAnthropicでさえ制御不能 2026年夏「3大サイバー攻撃」の衝撃
-
8
ChatGPTは“検索しまくり”でGeminiは“淡泊”? データが明かすAIの裏側
-
9
生成AIが普及しても「技術書」を手放せないエンジニアの本音
-
10
Microsoft 365移行で露呈した標準機能の限界 地方銀行は上長承認や「脱PPAP」をどう実現?
ホワイトペーパーランキング PR
-
1
AI駆動攻撃にどう対抗する? 超速の攻撃からエンドポイントを保護する方法
-
2
最速72分でデータが流出? 最新の脅威トレンドや侵入手法から分かった防衛策
-
3
2026年のサイバーセキュリティには何が必要か? 最新データに学ぶ傾向と対策
-
4
経験豊富な即戦力人材に直接アプローチできる、「攻めの採用」への転換術
-
5
「IT史に名を残すシステム障害」8選
-
6
SASE選定は「見極め力」で大きな差――本当に必要な製品を選ぶための6つの視点
-
7
不審メールの経路や見せ方に変化? 2026年夏の3事例から見えた動向と対処方法
-
8
Microsoft 365のメールセキュリティ、3つの“死角”と追加で検討すべき対策とは
-
9
AI駆動開発のスピードと安全性を両立 「品質・セキュリティ管理」の実践ガイド
-
10
「標的型攻撃メール」事例・サンプル集
TechTargetジャパン SNS
インフォメーション
注目情報をチェック
TechTargetジャパンをフォロー