LayerXの福島です。本日はこの記事に関連して寄稿しようとおもいます。

今回は、金融とDXについてお話できればと思います。Fintechという言葉がバズワード化してから、長らくの時が経ちました。最近ではEmbedded Finance, 金融のアンバンドリング, 金融のモジュール化などの言葉がでてきてますが基本的には「Fintech」の焼き直しあるいは細分化であり同じことを言っています。

ではこれだけ重要だと叫ばれながら、なぜ金融機関のDXは進まないのでしょうか?何が難しいのでしょうか?難しい中でもどこからどうやってすすめていけばいいのでしょうか?

これについて考えてみたいと思います。 

DXのフレームワーク

そもそもDXとはどう捉えるべきでしょう。DXという言葉は様々な形で世に言われています。

アプリを作り集客することがDXでしょうか?

ECサイトを作り、オンラインで製品を販売することがDXでしょうか?

クラウド会計や電子署名ソフト、請求書処理ソフトなどSaaSをいれて業務効率化することがDXでしょうか?

BIツールを入れて経営の意思決定に役立てることがDXでしょうか?

マシーンラーニングで顧客へのレコメンドを自動化することがDXでしょうか?...etc

これらはすべて、DXですが、「点」で捉えては意味がありません。DXを包括的に捉えるのは難しいですが、DXの目的は、「デジタル化」ではなく「会社の業務をデジタルに変革することで競争優位を作ること」です。

なので、DXのフレームワークも、「会社の業務」を軸に整理すると意思決定で迷わなくなります。

上記は筆者が、DX迷子になったときによく使うDXの全体像、フレームワークです。

多くの会社の業務はこのように「フロント-ミドル-バック」で定義できます。(業務によってはフロントとミドルの領域が曖昧、ミドルとバックの領域が曖昧というものはありますが、厳密な議論はここでは避けます)

DXのパターンは4つしかありません。

① [フロントのDX] デジタルチャネルを導入
② [バックのDX] ノンコア業務にSaaS導入
③ [ミドルのDX] データドリブンな意思決定と自動化
④ [基幹業務DX] 基幹業務をデジタルスクラッチで作り直す

①~④の並び順にも意味があり、基本的に①→④にいくにつれて、DXの難易度・移行の難易度が高いのです。

(金融機関のDXが難しいのは「④基幹業務をデジタルスクラッチで作り直す」に挑戦せざるを得ないからです)

以下それぞれパータン毎にどんな例があるかを示します。

金融機関(あるいは伝統的大企業)はどうDXと向き合うべきか

金融機関(あるいは伝統的大企業)のDXで目指すべき姿は「④基幹業務をデジタルスクラッチで作り直す」の状態です。

これにより、根本的なビジネスモデル・プロセスの転換をし、デジタル時代での競争優位を獲得することが重要です。

そして金融機関(あるいは伝統的大企業)のDXの難易度が高いのは、「DX=基幹業務のDX」であるケースが多いからです。

金融機関(あるいは伝統的大企業)の能力が低い、Fintechスタートアップの能力が低いのではなく、純粋に難しいことに挑戦しているから、時間がかかるし、成果を上げづらいのです。

基幹業務の置き換えの難しさは「フロント-ミドル-バック」が相互に密に依存していることです。ですので、新しいデジタルチャネル(アプリ、EC、デジタル窓口)を作ろうは解決策になりません。SaaSを導入しようも解決策になりません。部分を変えても全体に依存するため効率化できないからです。

基幹業務のDXに一足飛びでいくのは困難です。なので前述のフレームワークを頭に入れることで、どう意思決定していけばいいかも自ずと見えてきます。

まずスタートにあるのは、「業務フローの整理」です。ここを絶対他人任せにしてはいけません。自社のコアは自社の業務フローに必ずあります。

一方いきなり整理と言われても困ります。おすすめなのは、SaaSの会社に問い合わせることです。SaaSの会社は「業務フロー整理する部隊」をもっています(しかも大抵の会社はここを無料で提供しています)。商談を進めながら、自社の業務フローを整理できて、かつ効率化もできてしまう。おすすめの方法です。

そうこうしながら業務が独立に分解可能か/相互に依存していてパーツで置き換えることが不可能かを判断していきます。こういった業務を回していくと自社にもノウハウが溜まっていきます。

DXのクイックウィン

業務が独立に分解可能な場合は、どんどんSaaSをいれていきましょう。おすすめは「フロント」「バック」の業務から入れていくことです。

フロントやバックの業務は、「売上改善やコスト改善・業務効率化」に直につながります。BCPの観点でも重要です。業務が独立に分解しやすく、効果が得やすいので「DXのクイックウィン・成功体験」を組織で得やすいのです。

ミドル業務は意思決定のデジタル化であり、データドリブンな会社文化への改造・醸成が必要で、効果が出るまで時間がかかります。またフロント・バックがアナログなままミドルをデジタル化しても効果が薄いので、一番最初にやることはおすすめしません。

もちろんミドルの中でもフロントに近い業務、ミドルの中でもバックに近い業務があり、そういったものは優先度高く取り掛かるのも悪くないでしょう。

デジタル化・DXでは「クイックウィン」が重要です。予算ウン億円用意したPJが頓挫するという例もたくさん見てきました。そういった失敗例のほとんどは、大きな山をすぐ動かしに行き過ぎています。デジタル知識に対する自信がないまま、DXにおけるフレームワークや地図がないまま迷子になってしまったケースが多いです。

組織のモメンタムを作るためにもまずは「クイックウィン」しやすい独立した分解しやすい業務のデジタル化からやっていくことを強くおすすめします。

弊社(LayerX)ではこういった会社のクイックウィンを助けるための請求書処理のSaaS事業も展開しています。請求書処理に限らず独立分解な業務を助けるSaaSの会社は、市場では増える傾向にあります。今後ますますノンコア業務システムを内製化していく意味は薄れていくでしょう。

基幹業務のDX

続いて本丸の基幹業務のDXです。小さな業務でクイックウィンを積んだ後は本丸の業務にとりかかりましょう。

本丸の基幹業務は「フロント-ミドル-バック」などきれいに分けられず、相互に依存していて、独自の仕様が必要な物が多いです。

こういった業務を一気通貫して、デジタルに再設計し直すということの達成は、パーツパーツのSaaS導入だけでは実現できません。縦に、一貫した業務を作り込む必要があります。

これをやるには「デジタルの深い知識」と「業務フローの深い理解」が必要です。大抵の会社は、自社業務は理解しているが、「デジタルの深い知識」が足りないケースがほとんどだと思います。

またこういった基幹業務は従来型の「受注-発注」という関係性ではうまくいかないケースが多いです。それよりも1個1個の細かい改善や全体最適の行動が、お互いの利益に直結するような「共同事業, 合弁会社」のような関係性を築くことが大切です。長期的に、健全なインセンティブ構造で継続改善がつづけられる座組にしていくことが重要なのです。

そして今後増えていくのは、「デジタルの深い知識」をもつスタートアップとの共同戦線です。具体的には共同事業や合弁会社です。

弊社(LayerX)では、アセットマネジメント領域で三井物産様、SMBC日興証券様、三井住友信託銀行様と合弁会社を作っています。この合弁会社の目的はまさにアセットマネジメント業務の基幹システムをデジタルに作り直すことです。そうすることで、圧倒的に効率の良いアセットマネジメント会社を作るという取り組みです。

こういった動きは特殊な動きではなく、たとえば海外ではチャレンジャーバンクが大手金融機関と組み銀行のDXをすすめています。中国では平安保険が、各種保険会社に基幹システムを提供しています。またテンセントは大手金融機関とWeBankを、アントフィナンシャルも大手金融機関とくみMyBankを設立し、金融DXをすすめています。

まとめ

- DXのフレームワークは業務を軸に「フロント-ミドル-バック」で考える

-「フロント-ミドル-バック」のフレームに収まらない、一気通貫した基幹業務のDXが最も難易度が高い

- 金融機関(あるいは伝統的大企業)のDXの難しさは、デジタル知識のなさではなく構造的問題。(基幹業務のDXの難しさ, 受発注関係によるインセンティブの歪み)

- DXにも「クイックウィン」が重要。まずは業務の分解が容易なところのSaaS導入から

- 本丸の基幹業務のDXには、「受注-発注」の関係性ではうまくいかない。セイムボートで長期的に継続改善していくインセンティブがお互い持てる「共同事業、合弁会社」の座組が向いている

- 世界的にも、基幹業務のDXは「共同事業、合弁会社」の座組がふえている

以上でした。DXというバズワードに惑わされず、適切な地図の中で正しい判断をする会社が増えていくことが、日本・世界の社会を豊かにしていくと信じています。少しでもこの記事がその一助になれば幸いです。