TdRは2021年、「東京海上日動リスクコンサルティング」から現在の社名に変更した。「d」には「Data」（データ）、「Digital」（デジタル）、「Design」（デザイン）の3つの意味が込められている。社名変更を機に、社内ではデジタルを中心とする取り組みを積極的に進める気運が高まった。

　TdR 企業財産本部 副本部長 工藤智宏氏によると、当時、全社のICT部門はセキュリティをはじめとする「守り」を主に担っていた。一方、顧客のリスクを評価する企業財産本部では、社名変更以前からデジタル技術を使った業務効率化を進めていた。

TdRの工藤智宏氏

　そこで同社は、顧客ニーズを最もよく把握している現場から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 パートナー 企業財産本部 本部長の佐藤一郎氏は、「何もしなかったら次はできない。失敗を早くした方が絶対に成功につながる。壁が分かったことが一番の成果だ」と語る。

TdRの佐藤一郎氏

　大出氏は、こうしたDXの進め方について「早めに小さな失敗をして、致命傷を負わないようにしながら、自分たちが正しいと思うことを選択して、顧客との関係に変化を生み出していくことが重要」だと話す。

　全ての選択が正しかったわけではない。それでも、「何もしない」という選択を続ければ、次の挑戦は生まれない。

　実際、取り組みを続けたことで、TdRには技術や人材が蓄積しただけでなく、当初想定していなかったグループ内でのデータ活用や関連サービスへの展開も生まれた。

　一方、今も解消していない問題はある。新規サービスは何が起きるか完全には予測できないため、開発側は一定のリスクバッファーを見込む必要がある。それがコストに跳ね返る問題は残っている。

　つまり、このDXは「全ての課題を解決して成功した物語」ではない。新しい壁が現れるたびに、その時点でできる判断を下し、小さく動いて結果を次の判断につなげてきたプロジェクトである。