通信業界におけるデータ利活用の課題と解決の方向性

1. 移動通信業界、いわゆるモバイル業界では経済圏作りが活況
2. 経済圏作りに向けたデータ活用の課題
3. データ連携の要請
4. iPaaSによる課題解決
5. iPaaS導入の壁
6. 最後に

国内移動通信業界では、国の介入などにより回線系ARPU(Average Revenue Per User：平均売上金額/ユーザー)の成長率がダウントレンドであり、個社 での回線系ARPU向上も困難な状況である。
併せて、モバイル端末の累計契約数はすでに日本の全人口を超えており、端末の世帯普及率も合計100%を超えているため、回線契約数の大幅な増加も見込めない。
 
この市場飽和を前提として、モバイル業界では新規顧客獲得よりも既存顧客のロイヤルティを高めることに注力し、自社経済圏への囲い込みを志向している。
 
直近の大きなニュースにNTTドコモ社・マネックスグループの資本提携がある。この狙いは金融サービスにおける他社追いつき・サービス強化という大目的に向けた自社システムへの接続・オウンドメディアからの送客である。

モバイル各社は上記の金融サービスのほか、EC・メディア/エンタメなど多種多様なサービスを提供し、自社経済圏への取り込みを目指している。重要となる顧客満足度やリテンション向上に向けては、パーソナライズされたサービス提供やUI/UXの向上などへの注力が必要となる。
その中でも経済圏における顧客の活動から取得する決済データを始めとした多面的な情報や、外部情報の活用が肝要だろう。
一つの打ち手としてSnowflakeを代表とするData Lake/DWHの導入が挙げられる。1か所に必要なデータを集約し、データ分析ツールや各種ライブラリを活用して新たな施策を打っていく。この思想自体は近年のトレンドであり、すでに導入が進んでいる領域である。
 
一方で、取り組みが進んだことにより新たな課題も発生している。
”データをData Lake/DWHに集約していく” という思想に反し、必要なデータが複数システム・複数情報系に散在している状況のまま、データ利活用の文脈が先行しているのだ。
たとえば、ある企業では納期・コストの関係から必要なデータに絞ってData Lake/DWHに集約しているが、後から必要となったデータは個別最適・一次手当のように対応されている。別な見方をすれば、戦略的な取り組みであるData Lake/DWHが単なる情報系の一つになっていると言えてしまう。
 
なぜこのような状況に陥ってしまうのか。それは投資対効果を含めた経営上の納得感が薄いことにあるだろう。要するに「あえて莫大なコストをかけてまで（現時点で）不必要なデータをあえて集約するメリットはあるのか」という問いが拭い去れないのだ。
 
筆者はこの問いに対して、“データ利活用・データ蓄積” というより「企業内外を含めたデータ連携強化」の文脈で答えてみたい。

データ連携自体に対して何が求められているかを整理したい。
 
まず、政府が提唱するSociety5.0の世界観においては、生活者の課題ドリブンで産業構造の再形成が行われ、価値の実現に向けた自律分散競争型の構造へ転換される。ここでは個社単位でのデータ連携に加え、企業同士を含めた各ステークホルダーとの連携が欠かせない。
デジタル庁では、活用・連携・創成/収集/管理の3つのレイヤをベースとしたアーキテクチャづくりを推進しており、補助金を含めたユースケース創成に努めている。
 
一方で、経団連が2023年5月に公表した「データ連携の進展状況に関するアンケート」では、異業種とのデータ連携について46%の企業が取り組みを実施しておらず、27%の企業は実証レベルに留まり、持続的な取り組みへと移行できていない。（注1）
Society5.0に向けたデータ連携を通じたDXには、デジタル庁が提唱するように「共通化したツールによる容易な連携」・ 「利用・相互連携が容易なデータ」が肝要だ。
 
次に事業者側、特に事業部門の目線では、開発アジリティの向上・業務負荷低減が主たる要求となるだろう。
事業部門としては、自分たちがやりたいことを迅速に、安く、品質高く実施したい。SaaSやシステム導入時にシステム間連携を個別に実施したり、その必要なデータをどのシステムが保持しているかを調査したりするリードタイムや工数は、現場にとって短縮したいものの一つだろう。
また近年は、事業部門におけるデータ分析やデータを活用したアプリケーション開発が興隆している。このような状況では、データ構造が簡易で利用しやすい環境が求められるだろう。
 
最後に、IT部門としては事業・業務側が求める開発アジリティのほかに、ガバナンス面での要求があろう。
どのようなシステムが会社として活用されているか、そのリスクは何か、個人情報を含むデータがどのシステムで利用されているかを管理したい。
各システム・データがどこにあるかを管理するためにはユーザー側からの協力が不可欠だが、ガバナンスやルールを基本とした取り組みには限界があると考えられる。

上記の課題を解決する選択肢の一つにiPaaS（Integration Platform as a Service）がある。
ガートナーによれば、iPaaSとは“個人または複数の組織内でオンプレミスとクラウドベースのプロセス、サービス、アプリケーション、データの任意の組み合わせを接続する統合フローの開発、実行、ガバナンスを可能にするクラウド サービス”として定義される。（注3）
iPaaSの機能はサービス志向アーキテクチャ(以下、SOA)をベースにし、クラウド/オンプレミスで利用されるシステムやアプリケーションのデータハブとなり、その連携を管理・監視することが特徴である。
先述したデータ利活用における課題に対しても、以下のように対応できるだろう。
 
①iPaaSがデータハブとなり、社内外のデータ連携を統合することで、より柔軟で統一性のとれたサービス提供/開発が可能となる。
各サービス・システムはデータ連携先・連携元のシステムを意識することなく、多様なデータコネクタを持つiPaaSのみを接続先とすることで、迅速なデータ連携を実現できる。また、データ加工もiPaaS上におけるローコードベースの仕組みにより、手作業を排除した柔軟な対応を実現できる。
 
②データ連携基盤だけでなく、Data Lake/DWHといったデータ統合基盤、各種AI/BIツールを具備している場合もあり、一気通貫型でのデータ利活用・連携が可能となる。
 
③データが整流され、管理・監視できるようになることで、データの在処や利用エリアの特定が容易になる。

一方で、iPaaS全面導入にあたっての障壁もいくつか存在する。
 
A.全体最適の考え方
個別システム間だけでなく、全社システムの関連性や業務プロセスを把握しなければならない。場合によっては既存システムがスパゲッティ化した背景やデータ連携の意図まで把握し全体像を見ることが必要になる。
 
B.日本企業特有の制約
iPaaSはSaaSを始めとしたクラウドサービスとして立ち上がっており、API連携が主流となる。一方で、日本では急速にAPI連携が進んでいるものの、ファイル転送方式がまだ主流となっている。主な理由は、セキュリティ面やデータリカバリの容易さ、枯れた技術であることなどだ。これは日本企業におけるオンプレミス－クラウド間の連携において見逃せない論点だ。
このためAPI化の推進をしながらも、データ連携基盤としてiPaaSを活用するためにはファイル転送方式も含めた対応が必要であろう。ただし、ファイル転送基盤としてトップシェアを誇るセゾン情報システムズがiPaaSサービスを開始し、いくつかのベンダがすでに対応を開始しているため、時間経過による解決が可能だろう。
 
C. 可用性の問題
iPaaSが中継役として介在することとなり、特にオンライン連携において冗長な構成になってしまうことが否めない。例えば銀行システムにおける取引データなど、即時性が厳密に求められる取引においては、性能も含めた課題が残る。
ただし、これは限定的なケースであり、一部業界における課題と言えるだろう。

日本におけるデータ利活用は途上であるものの、大きく進展してきたと言える。その進展がゆえに生じたデータ連携という課題に対しても、注目度が高まっていると言える。
例えば経団連が2020年に発表したDXに関する提言（注2）では「データ利活用」がフォーカスされていたが、2023年には「データ利活用・連携」と並び立つまでになったことが一つの証左であろう。（注3）
また、2023年6月に公表されたガートナーの調査によれば、iPaaSは64%が導入済/1年以内の利用予定あり、と注目度が高い。（注4）
 
iPaaSはクラウドベースであるため、スモールスタートでの開始が容易い。まずはPoCとして開始することで、個社単位で柔軟かつ拡張性のあるアーキテクチャをクイックに実現できる。
iPaaSのような最新技術が日本企業に広く普及し、個社単位に留まらない連携を実現できるように、当社もコンサルティングを通して貢献し続けていきたい。