【シリーズ】データガバナンスがもたらすもの－第11回　金融業界とSSP（Smart Strategic Platform）の展開～スピーディーなデータ基盤構築とビジネスドリブンな運用～

データ基盤構築に求められる3つのポイント

株式会社ブレインパッド・櫻井洸平（以下、櫻井）　クイックにビジネス価値をもたらすためには、データ活用基盤を短期間に低コストで開発する必要があります。一方で性能や拡張性、セキュリティといった非機能的な要件も満たさなければなりません。従って、どのようなデータ活用基盤を構築するかはデータガバナンスにおける重要な論点の1つになります。

そこで、データ活用基盤構築について議論するにあたり、検討のためのモデル業界として金融業界を選びました。理由としては、金融業界のデータ活用には様々な課題があるため、データ活用基盤の構築の難易度が高いこと、その上セキュリティに関しては最高レベルを求められることです。つまり金融業界で通用するデータ活用基盤構築の方法論であれば他業界にも適用できることになります。

ブレインパッドではSSP（Smart Strategic Platform）というデータ活用プラットフォームをベースに、クイックかつ低コストでデータ活用基盤を構築しローンチするビジネスに取り組んでいます。このSSPが金融業界でも通用するのかをまず議論し、実際に通用することを検証したのち、SSPを活用したアジャイル開発および内製化の提言をしていくのが、今回集まってもらった主旨です。

さてデータ基盤構築において昨今求められる重要ポイントは、業界に関係なく、以下の3つだと考えられます。

• 開発スピード
• 機能および非機能の拡張性
• セキュリティ

開発スピードが求められるのは、一刻も早くデータ活用によるビジネスへの恩恵を享受したいからです。そうなるとスモールスタートが1つのセオリーになり、必然的に拡張性が大きな論点になります。またデータを安全・安心に利用できるかどうかは当然の要求と言えます。特に今回検討対象とする金融業界では格別に求められることです。

1.開発スピードの向上：TTMの短縮＆市場シェアの獲得

櫻井　1つずつ見ていきましょう。まず開発スピードです。

昨今TTM（Time To Market）ということがよく言われます。商品・サービスの企画から市場投入までの時間のことですが、これを短くすることで先行して市場シェアを獲得でき、競争優位につながることになります。そのためには一刻一秒でも早くデータ活用に取り組むことが求められ、当然ながらそれに必要なデータ活用基盤を素早く構築することが求められるわけです。

それ以外にもTTMを短くすることで、商品・サービスを早く市場に投入できる分、収益を獲得できる期間も長くなり、トータルの収益拡大につながります。また顧客ニーズの変化が早いので、商品・サービスを素早く市場に投入することで、まだニーズが高い間に提供できて顧客満足度が向上します。さらに試行錯誤を重ねながら新しいビジネスモデルを何度も改善しながら試せ、イノベーションを加速することもできます。

データ活用に至るまでには、データ活用基盤を構築し、データを蓄積するというステップを踏む必要がありますから、いかに速くデータ活用基盤を構築して、データを蓄積するフェーズに入っていけるかが、TTMを短くするための重要なポイントになります。

2.機能および非機能の拡張性：最初からデータをかき集めてはいけない

櫻井　次に拡張性です。データ活用のテーマは数多くあります。たとえば顧客理解であれば、まず顧客データや行動履歴などを分析し、顧客の解像度を上げてから過去の施策を分析し、そこから新しい施策を導きだし、また実施して分析し改善するというPDCAサイクルを回すことになります。

その際に重要なことは、最初から様々なデータをかき集めて重厚長大なデータ活用基盤を構築するのではなく、まず実施したいことを見極めて、それに必要なデータだけを収集することです。その後、PDCAサイクルを回しながら必要なデータを付け加えていくことになるので拡張性が重要になるわけです。

拡張性と一言で言ってもいくつかの観点があります。まずデータの量や種類を柔軟に増やせるか。また外部のデータや他のシステムと簡単に連携できるか。さらに、たとえば最初はBIツールとの連携などビジネスの可視化から入ったとして、その後は機械学習モデルを作成して予測や計画に使いたいといった機能面の拡張もあります。それだけでなく、データ量が増えてもレスポンスが変わらない、機能が増えても可用性・保守性が高いといった非機能の拡張性もあります。

3.セキュリティ：必須要件であり、金融業界では特に厳しい

櫻井　最後にセキュリティです。保存するデータの中には、個人情報や営業秘密など機密性の高いものも含まれています。データ漏えいを防止する必要があり、そのためにはデータの暗号化やアクセス制御等の機能が必須になってきます。もちろんサイバー攻撃にも備えないといけません。データ活用基盤においてセキュリティは必須要件です。

今回検討対象にしている金融業界では、セキュリティに関しては人一倍センシティブであり、厳しい対策が求められます。したがって金融業界で求められるセキュリティ基準に対応できれば、他の業界に対しても（特殊要件は別として）自ずと対応できると言ってよいかと思います。

検討：金融業界のシステム開発

櫻井　以上、データ活用基盤構築に求められる一般的なポイントについて述べてきました。それぞれのポイントに関して、金融業界の現状はどうなのか教えてもらえますか。

株式会社ブレインパッド・荻原伸平（以下、荻原）　はい。私は銀行出身ですので、主に銀行の話になりますが、保険も証券もクレジットカードも大きくは変わらないと思います。

1.開発スピード：一般的に遅い

荻原　まず開発スピードについてですが、これは遅くなりがちです。扱っているデータの種類が、預金、融資、為替、金利など種類が多い上に、それぞれの量も膨大だからです。これらをいろいろなシステムからかき集めてくるわけですから、データ活用基盤の要件も複雑になりがちです。

その上、データを取得してくる先のシステムがレガシーであることが多いのです。いまだにCOBOLで書かれたプログラムがたくさんあります。しかも多数のシステムが複雑に絡みあっているので、たった1つのシステムを修正するにも影響調査に時間とコストがかかります。

櫻井　解決の方向性はあるのでしょうか。

荻原　データ活用という目線で考えると、当初は活用に必要なデータだけあればよく、必ずしも大規模なデータ活用基盤を構築する必要はありません。最低限のスコープでいかに短期間でリリースするかだけにフォーカスしていけば、今挙げた問題の大半は解決し、良い方向に向かうはずです。

2.拡張性の低さ：ウォーターフォールとオンプレミスが中心

櫻井　拡張性についてはいかがでしょうか。

荻原　拡張性は低い傾向にあります。主な理由としては、今後必要となり得る全機能および非機能要件を最初から実装しようとするため、リリース後に機能・非機能を拡張することを考慮した設計になっていないことがまず挙げられます。金融システムは重厚長大なものが多く、基本的にウォーターフォール型での開発を推進してきたため、トライ＆エラーでシステムを改善・拡張していくアジャイルの発想に慣れていません。

また非機能の拡張、つまりストレージ容量や性能などの拡張にはクラウドが有効であることを金融業界の人たちもよく知っているのですが、まだ拒否感があってオンプレミスで開発することが多くなりがちです。セキュリティへの不安は以前ほどではないのですが、外部にデータを預けることに抵抗があるんですね。そうなるとデータ量が増えてストレージを追加するにもいちいち調達しないといけないので、時間も費用もかさむことになります。

櫻井　解決の方向性はありそうですか。

荻原　これも開発スピードと同じで、まずは必要な機能と非機能だけあればよいと割り切ることだと思います。そのように考えれば、設計思想も拡張性を重視するように変わりますし、クラウド活用にもっと積極的になるでしょう。

櫻井　拡張とは逆ですが、各部門で作成した中間ファイルが多く、その所有者がよくわからない、あるいは作った人が退職してしまったので削除が難しい面もありますよね。

荻原　はい。単純に削除してしまうと何に影響するかわからないですからね。このあたりは、データのライフサイクルプロセスの一環として、削除の基準と手順を明確にする、つまりデータガバナンスに関わるところですが、重要な指摘だと思います。

【関連】【シリーズ】データガバナンスがもたらすもの－第5回　データ基盤構築とデータガバナンス（前編）

3.セキュリティ：要件定義の難しさ

櫻井　セキュリティについてはどうでしょう。

荻原　顧客企業の財務データや信用データ、あるいは個人顧客の預金データや個人情報など極めてセンシティブな情報を取り扱うため、他業界以上に高いセキュリティレベルが求められます。それで非常に慎重な検討が必要となり、セキュリティに関する要件定義が難航するといった弊害が出てきます。基幹系のシステムにセンシティブなデータが多いため、そちらからデータを取得するとなると影響調査に時間がかかることになります。

櫻井　解決の方向性は？

荻原　要件定義が難航する件に関しては、毎回一から議論することを割けるために、要件のベースとなるものがあれば迅速化が期待できます。幸い金融業界のセキュリティ基準としては、FISC（公益財団法人金融情報システムセンター）の安全対策基準（略して「安対」）が、標準的なガイドラインだと認識されています。これをベースとして過不足を整理することで、効率よく要件を決めていくことができます。

金融業界の課題に有効なSSP

櫻井　今の荻原さんの話から、金融業界におけるデータ活用基盤開発の課題とその解決ポイントをまとめると次のようになるかと思います。

1. 開発スピードが遅い
   → 活用するデータをビジネスに必要なスコープに限定することで、開発スピードを向上する

2. 拡張性が低い
   → 最初からすべてを用意するのではなく、必要な部分から広げているアジャイル的な設計思想にし、機能・非機能ともに拡張しやすいクラウドをベースとした開発手法に変えていく

3. 要求されるセキュリティレベルが非常に高い
   → FISCの安対を基準にすることで効率よくセキュリティ要件をまとめていく

これらのポイントを抑えたデータ活用基盤構築を検討する上で、ブレインパッドが開発したクラウド上のデータ分析基盤プラットフォームSSPは有効な選択肢の1つと考えられます。その理由は以下の通りです。

• データ活用基盤に必要最低限の機能仕様・非機能仕様を実装済みのため、短期間でデータ分析基盤の構築が可能
• BI連携、データ収集、データマート作成、データインターフェースなど、データ基盤として必要な標準の機能を多数用意しており、レガシーな既存システムとの接続にも柔軟に対応
• 拡張性を考慮した設計となっており、初期段階ですべての要件をまとめる必要がなく、必要に応じて機能を追加することが可能（オプションメニューも多数用意）
• FISCの安対に準拠したシステム実装とドキュメントの整備

荻原　実際に使ってみた感想としては、ドキュメントがしっかりと整備されているのが、金融業界向けとして優れていると思いました。かなりかっちりとしたドキュメントが求められる業界なので、要件定義書等を作るにもレビューするにもかなりの負荷がかかるのですが、SSPであればそのあたりの負担感も大幅に減り、スピーディーに実装へと移れます。

要件定義もゼロベースではなく、定義項目が決まっているので、必要項目の認識合わせができれば、すぐにデプロイ可能です。

FISCの安対に準拠する具体的なメリット

櫻井　金融業界のデータ活用基盤構築の課題と解決の方向性、そしてその方向性を実現するのにブレインパッドが提供しているSSPが有効な選択肢になり得ることがわかりました。ではここからは実際にSSPの開発に携わったデータエンジニアリング本部 の秦さんをお呼びして、SSPがどのように使われているかを見ていきたいと思います。

まずSSPを実際に導入してみて、金融機関に求められるデータ活用基盤は他業種と比べて違いがあるかどうかについてです。いかがでしょうか。

株式会社ブレインパッド・秦健浩（以下、秦）　求められる機能は同じでも、金融機関独自の考え方があると感じます。先ほどから話題になっていますが、セキュリティ対策の要件が特に厳しいのは事実です。法規制やそれに対応する業界標準も厳しいですし、各社のセキュリティポリシーも厳しいです。

また24時間365日の可用性が求められるシステムが多いことも金融機関の特徴です。どんな業務であってもしっかり運用ルールを定めなければなりませんし、BCP（事業継続計画）もしっかりしています。ただ先ほどの議論にもありましたように「本当にそこまで必要ですか？」と思うことも多いです。システム開発に関しては「べき論」からスタートするのも特徴的かもしれません。

櫻井　セキュリティに厳しいということで、FISCの安対に準拠するメリットは大きそうに思います。

秦　金融業界に関して言えば、安対に準拠するメリットというよりは、準拠しないデメリットのほうがはるかに大きいというのが正確でしょうか。準拠しないことで何らかの事故が発生した場合、致命的な影響を被ることになりかねません。

FISC自体は、金融情報システムに関連する諸問題の国内外における現状、課題、将来のための方策などについて調査研究を行っており、金融業界だけでなく取引先である情報・通信企業が多く加盟しています。したがって安対については、他業界でも適用可能な指針となっており、多くの企業に浸透しやすいというメリットがあります。

荻原　金融機関への直接的なメリットはいかがでしょうか。

秦　荻原さんが指摘していた通り、金融機関のセキュリティ要件を一から定義していたら、必要な機能を挙げるだけでも膨大な工数と期間がかかります。SSPでは安対に基づいたデータ活用基盤に必要な機能が既に実装されているので、迅速かつ低価格で安対に準拠したシステムを提供できます。また定義項目もドキュメントとして整理されているため、検討が素早くできるのはもちろん、IT部門やリスク管理部門のチェックも容易です。

ただし安対のすべてが実装されているわけではありません。あくまでデータ活用を始めるために必要な要件です。ただ実装方法や実装していない機能の代替案についても仕様書としてまとめているので、実装されていない要件も容易にチェックでき、許容できないギャップがあればカスタマイズも可能です。

荻原　検討しないといけない部分が整理されているので、進めていく上での安心感が大きいと実感しました。

秦　非機能面については、すべて実装すると膨大なコストがかかります。あくまで業務の本丸が何かを見定めた上で、そこから外れる部分については手作業で対応してもいいわけです。コストとの見合いが重要で、単純な機能にもかかわらず非機能のために何千万円もかかるといったことは避けないといけません。そのあたりの見極めが速くできるのもSSPのメリットです。

SSP＝　✖単なるデータ活用基盤　〇ビジネス課題のソリューション

荻原　SSP導入に際して、お客様にはどのような準備や検討をしてもらう必要があるでしょうか。

秦　セキュリティ基準やクラウド利用方針、システム構成のルールなどお客様独自で定めている情報を開示していだだくことです。そうしてもらえれば、あとはSSPとして考慮すべき内容を協議させていただくだけになります。

櫻井　検討項目が定義されているので検討スピードが速くなり、導入も早期にできるということですね。

秦　ウォーターフォール型の導入と比較すると、導入までの時間が大幅に削減できるのは間違いありません。金融業ではありませんが、大手商業施設向けに在庫シミュレーション機能を提供する案件がありました。セキュリティ等まで考慮するとスクラッチ開発なら最低でも2カ月かかるところ、SSPを利用することで、1週間でインフラ構築が完了し、その後データ入力とテストを実施して、都合3週間でローンチすることができました。

最近だとChatGPTを活用するためのデータ基盤が欲しいという案件がゲリラ的に増えているのですが、そのような基盤はとにかくクイックに構築したいということで、SSPの出番が各段に増えています。

櫻井　欲しいときに欲しい環境が実現できるということですね。

荻原　TTMが競争優位性、収益性、顧客満足度の向上の視点から極めて重要であることに、SSPと関わり始めたことで改めて実感しています。

櫻井　そこがSSPの良さですね。データを早く業務に活かしたいという要望にぴったりです。それでいて、そこから機械学習モデルの作成環境へと発展させたいというニーズにもしっかり応えられます。データをビジネスに活かしていくためには、技術ドリブンではなく、ビジネスドリブンで進めることが必要ですが、そのような進め方がSSPで可能になります。

秦　SSPはあくまでプラットフォームですが、ビジネスにデータを活用させていく上での課題（スピード、拡張性、セキュリティ等）を解決するソリューションとして捉えてもらえればと常々考えています。

他システムとの連携でさらにクイックに

秦　クイックに環境構築することはTTMの短縮の必要条件ではありますが、それだけでは十分ではありません。既に存在する仕組みをSSPと連携させることで、早期実現が可能なことも数多くあります。

たとえばブレインパッドは、exQuickという、膨大なデータを直感的な操作で集計・分析・データ抽出・レポート作成できるツールを提供しています。

　

Windowsにしか対応していないプロダクトなのですが、ベン図を使って抽出ターゲットを指定できる機能を持っています。SQLだとかなり複雑になることをGUIで簡単に行え、作成したターゲットリストに対して様々な商品・サービスをレコメンドするような用途に十分活用できます。こういうことが他システムと連携することで、早く簡単にできるんですね。

ただし、今の話は技術ドリブンの域を超えていないエンジニア的思考からの発想なので、コンサルタントやセールスなどビジネスメンバーとよく意識を擦り合わせた上で、SSPと連携していく機能の選定を行うよう心がけています。

SSPで「アジャイルチーム」を実現

櫻井　SSPはすばらしい環境ではありますが、環境さえあればデータ活用が進むかといえば、また別の話ですよね。

秦　はい。環境はあくまで環境であり、その環境を使いこなしたり、改善・拡張したりする「人間」が大切です。

荻原　欲しいものを欲しいときに提供することを実現するに際して、秦さんはどのようなことが必要だと考えますか。

秦　ここまで何度も出てきた話ですが、激しいビジネス環境の変化にクイックに対応することが重要です。SSPでは、たとえばCIS Controlsに基づいたセキュリティを実装し、テスト済みの状態でコード化しているため、お客様環境に合わせた追加の設定・テストを実施後にすぐに利用可能になります。一部のテストは自動化され、初期構築、改修、運用のどのタイミングでも同じテストプロセスを組み込むことで継続的な監視が可能になります。つまりDevOpsの実現が可能になっており、SSPを中心としたサービス設計から開発までを、アジャイルに行えることが必要なことだと考えています。

荻原　アジャイルの必要性は理解されてきていますが、まだまだ実現は難しく、実現できている企業も少ないですよね。

秦　そうですね。アジャイルを実現するためには、ビジネス企画からシステム運用までをビジネスサイドとITサイドで一体となって内製する「アジャイルチーム」の組成が必要となります。ほとんどの日本企業にはそれが可能なだけの内製化人材がまだいないので、アジャイル自体がハードルの高いものになっています。ウォーターフォール型の開発に慣れてしまっている場合、すぐにシフトすることはハードルが高いため、DX推進がなかなか軌道に乗らない一因になっていると言えるでしょう。

【関連】変革プランナーにとってのDX推進の急所　第5回 DXキャンバスとその使い方

櫻井　まだまだITサイドとビジネスサイドの壁を感じますし、IT部門の内製化が進んで来ているとは言いますが、新規サービス開発ではなく、運用・保守のインソースが圧倒的に多い印象です。どうすればアジャイルが実現できるのでしょうか。

秦　そのために我々は内製に必要なすべての要素を持つアジャイルチーム組成のご支援を提案していきたいと考えています。分析と施策を実行できるメンバーと、施策をシステム要求化できるメンバー、それに基づきシステム要件を固め、開発・運用を実施するためのエンジニアが一緒に活動するアジャイルチームを立ち上げるためのサポートです。そうすることで、「施策・課題検討→要求化→システム・分析仕様確定→開発→施策実行→検証→要求化→……」のサイクルを、ビジネスサイド／ITサイドなどと区別することなく一元的に回せるようになります。

ビジネスのキーマンからの「こうしたい」という一言がエンジニアになかなか伝わらず、その結果システムに落とし込むことが困難になっています。それが解消できることになります。

櫻井　確かにこのようなチーム体制を作ることで、「今このとき」の顧客ニーズをデータから把握し、「今すぐ」ビジネスに展開できそうですね。

荻原　それが実現できるのも、クイックに導入できるSSPの良さがあってこそです。

秦　はい。従来のように施策の構想に時間をかけ過ぎず、ある程度要求化できたら実装し、施策を打ちながら結果検証するサイクルを高速で行う、つまりは施策そのものをトライアンドエラーでどんどん回していくことができるアジャイルチームと、そのために必須とも言える拡張性とセキュアな環境を提供できるプラットフォームの存在。SSPがあるからこそ実現できるご提案ではないでしょうか。

今後も進化するSSP

櫻井　改めて、SSPのメリットと、SSPを中心に据えたアジャイルチームの実現によって、ビジネスに貢献できるデータ利活用が進められることが理解できました。

荻原　分析だけできればいい、環境だけあればいい――ではなく、ビジネスにデータを活用するための体制を準備することの大切さも伝わったと思います。

秦　システム開発における正解は1つではありません。どんなにレガシーなシステムであっても、業務が適切に回り、安全・安心かつ長期的に利用できて、ビジネスが思い通りに実現できるのであれば、それは正解ということになります。

しかしながら昨今では、ビジネスモデルやビジネスプロセスが市場状況や顧客ニーズに合わせて激しく変化し、「システムは作っておしまい、あとは運用だけ」では済まなくなりました。環境変化にクイックに追随するための変更・拡張が求められます。しかも機能面だけではなく、セキュリティや可用性などを担保しながら、実施する必要があるのです。

これはアジャイルという手法が導入できても、それですべてが丸く収まるわけではありません。人間が大切なのは変わりませんが、ツールの進化も必要です。SSPがこうした課題に応えられるデータ活用プラットフォームとして、技術とデータとAIのつなぎ役としてさらにビジネス貢献にコミットできるよう進化させていきたいと考えています。

櫻井　秦さん、荻原さん、今日はありがとうございました。

荻原・秦　ありがとうございました。