Fin-JAWS 第5回～WHAT’S DIGITAL BANKING？～レポート #finjaws5 #finjaws #jawsug

Fin-JAWS 第5回～WHAT'S DIGITAL BANKING？～のレポートです。金融系ならではのAWSの使い方やつらみなどが共有されました。興味がある方はぜひDoorkeeperのメンバー登録をしましょう！

#イベントレポート

#JAWS-UG

#レポート

#セキュリティ

#AWS

臼田佳祐

2019.09.05

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは、臼田です。

Fin-JAWS 第5回～WHAT'S DIGITAL BANKING？～が開催されましたのでレポート致します。

Fin-JAWS 第5回～WHAT'S DIGITAL BANKING？～ - Fin-JAWS (金融とFinTechに関するJAWS支部) | Doorkeeper

ちなみに今回はリモート枠もありました！Fin-JAWS 第5回～WHAT'S DIGITAL BANKING？～【リモート枠】 - Fin-JAWS (金融とFinTechに関するJAWS支部) | Doorkeeper

レポート

#1: 株式会社みずほフィナンシャルグループ黒須義一さん『AWS Summit Tokyo 2019〜とある金融機関のかカケ足おさらい〜』

AWS Summit Tokyo 2019で4つのセッションを実施した
＜みずほ＞のAWS導入取り組み当初 2017年12月
- クラウドの評価から始めた
  - 社内では「クラウド怖いよね」みたいな話をしていた
  - いつになったらAWSが使えるのか不安だった時期
- なんとか1年半くらいでいくつかのプロジェクトが本番稼働し始めている
AWS Summitにおける＜みずほ＞セッション
- CCoE
  - 活動スキームを作る
- ガバナンス
  - ルールメイク
- 事例
  - パブリッククラウドを知る
- 基盤
  - 共通基盤を作る

＜みずほ＞によるAWSのススメ方

クラウド活用に対する考え方
- CCoE作るときにはIT部門だけで作るのは駄目
- ユーザ部門からニーズが出てくるからIT部門はそこと一緒にやったほうがいい
CCoEの目指したカタチ
- CCoEはバーチャルなカタチ
- 組織図に載っていない
- 誰もが意思決定者になれる組織を目指した
役割を設定してアサインするところからはじめて今は40-50人動いしている
- いろんなエンティティから少しずつ人を出している
- プロフェッショナルが集った
- 各々自分の立ち位置を作っている
- 自部門に持ち帰って活動できている
クラウド人材の育成
- ユーザ部門の人は昔はITについて勉強しないことが多かった
- ちゃんと勉強してIT部門と戦える知識をつけるようにした
- CCoEメンバーから育成を増やすだけではなく、全社員側(今は関係ない人たち)にも刷り込んでいく必要がある
テック人材開発コミュニティの発足
- 人事部を巻き込んでコミュニティ活動をオフィシャル化した
- 目的は？
  - 最先端のテクノロジーとビジネスの関係性を学ぶ
  - エンティティのつながりを創出
  - テックスキルを底上げして社員同士のうねりを産み出す
- 活動は2軸
  - 外部からのイベント
  - 社内知見者のイベント
- ハンズオンなども開催

金融クラウドセキュリティパネル

JCB、損保ジャパンと一緒に実施
FISCがあるのでそれには準拠していく必要がある
- AWSと膝を付け合わせてチェックしていった
- チェック後社内で通達を出してユーザ部門が始めやすいようにした

みずほ銀行のデジタル・トランスフォーメーションにおけるデータ利活用

データ分析を行っている方が登壇
係数管理に利用
今まではエクセルで分析していた
Athena/Redshift/QuickSightで分析
AWSに移行を検証したところ、AthenaのUIが少し使いづらい以外は問題なかった
分析の速度は最大40倍になった

＜みずほ＞がクラウド活用のために取り組んだこと〜デザインパターンとLanding Zone〜

責任共有モデルにおける＜みずほ＞の責任
- 誰がやる？どうやる？
- みずほではテナントとしてシステムに提供しているのでどこまでテナント側で見てもらうのかを決めた
IAMの管理も一人1IDできちんと管理するようにした
ネットワークはDXを引いた
ログ管理・監査も集約
セキュリティ対策は予防的統制と発見的統制
AWSベストプラクティス活用
自由度 vs ガバナンスをどうするか
- 最初はガバナンス重視で個別のサービス認定を行った
- だんだん新しいサービスを利用したいという声が増えてきた
- CCoEでリソースを割いて予算をとって認定するのは大変
- リスク部門/コンプラ部門に責任を負ってもらうためにすり合わせないといけない
- 将来的には発見的統制をメインにしていきたい

※こちらのセッションは下記レポートもご参照ください

【レポート】「＜みずほ＞がクラウド活用のために取り組んだこと～デザインパターンとLanding Zone～」AWS Summit Tokyo 2019 #AWSSummit

まとめ

ユーザからニーズ、活用の仕方が上がってくるので巻き込みましょう
共通で使う部分は共有する
活用をナレッジ化して仲間を増やしていきましょう
- 思いを共有することが大事

QA

CCoEがいる中でITベンダーを活用するメリットは？
- 経験値が高くて頼れる
- 請求などリソースが足りないところを変わりにおまかせすることもできる
海外のメガバンクでは内製化しているところがありますが、日本ではそういう必要性はあまりないでしょうか？
- 日本ではというより企業でいるかいらないかを考えればいいと思う
- 前職ではCCoEが少なかったのでフルアウトソースしていた
- みずほはいっぱい人がいたのでオンプレの人たちを巻き込んで内製化した

感想

みずほさんはAWS Summit Tokyo 2019で様々なセッションを実施されていてAWSの活用に非常に注力していることがとても感じられました。たくさんの部門の方がそれぞれ活躍されているとのことで非常にいい形で回っているのだと思います。今後もたくさんの情報発信を期待できますね！

#2: 住信SBIネット銀行株式会社浦輝征さん『やめたいけど　やめられない　だけどやめたい　ウォーターフォール（仮）』

ウォーターフォールがメイン
そこで感じた思いを共有したい
Fintechに早くから取り組んでいる
- トランザクションレンディング
  - 中小期限向けの最短即日融資が可能なトランザクションレンディングを2016年10月に開始
- AI審査の金融機関向け提供
  - AWSを活用している
  - PD算出をLambdaで実行している
  - API Gatewayで各種ルートからのリクエストを受けている
インフラストラクチャーの遷移
- 2007年の当初はオンプレ
- 2012年からオンプレで仮想化(部分的なクラウド利用)
  - 個人情報はクラウドに上げなかった
- 2017年全面的なクラウド移行の意思決定
  - 経営判断でクラウドシフト
- 2019年クラウドネイティブ化
  - コンテナ
  - サーバレス
  - マイクロサービス
事例1. インターネットバンキングシステムのAWS移行
- DBサーバ群をオンプレミスからAurora PostgreSQLにマイグレーション(2020/02)
- 基幹でのAurora PostgreSQL利用は日本国内では初
- DB性能比較をして商用DBより1.5倍アップ
- 可用性は同水準
- コストは約83%の削減(5年)
- 移行コストはかかるが3年以内で回収できる
事例2. コンタクトセンターのフルクラウド化
- Amazon Connectに移行を進めている
- コールセンターは人の場所などでコストがすごいかかる
- 移行することによりコストを削減できる
事例3. PrivateLinkの採用
- 銀行の書類の登録を完全自動化
- ネットワークコストは従量課金で80%を削減
- システムはパートナーの仕組みを利用していてPrivateLink提供してもらうようにした
- 専用線を引くよりかなりコスト・リードタイムを削減
「さよなら、銀行。」コンセプトを発表している
- Bank3.0の先にあるもの
  - 第一フェーズでリアル店舗からフェードアウト
  - 第二フェーズで銀行自体からのフェードアウト
  - 第三フェーズで「バンキング」と生活の一体化
    - いろんなインダストリーに溶け込む
  - Banking as a Service(BaaS)
    - APIを通じて必要な機能を提供
- 提供するバンキングサービス郡
  - 預金・決済・融資様々提供
- 非金融企業とアライアンスを組んでいる: JALと連携
ここからウォーターフォールの話
- 勘定系システムはとても大きい
- システム/ユーザの人間はかなり大変であった
- しかし開発の手綱を緩めるかというと、そんなことはない
- 一つの解としてアジャイル/マイクロサービスを活用を検討
- 大変になっていた一つの理由: オーナーシップ、当事者性
  - これがないと自分の子供が出ていない運動会につきあっているようなもの
  - ウォーターフォールではこれが薄れる事がある
  - アジャイルだと適度に見えやすくやりがいを持ちやすい
- いいか悪いかではなく、生存か死滅か。
  - 速度が早いFintech企業と付き合っていくにあたって遅いと死滅していくのではないか
まずはなんちゃってアジャイルみたいにプロトタイプを作ってユーザ部門と開発することを始めた
- 評判はいい
  - イメージが湧きやすい
- しかしクリティカルなシステムに適用していく、ということにはならなかった
広がらない理由
- 銀行は間違ってはいけないという大前提があるため簡単には適用できない
  - DevOpsやアジャイルの広がりがなかった
- もともとIT部門とっ業務側が同じ屋根の下にいて用件のブレが少ない
- そもそも開発案件が多くて外だししないと無理
同じような悩みがあったら共有してほしい
広がらなかったけど、それでもアジャイルを推進していきたい
遭難と地図
- 登山隊が雪崩にあって食料・コンパスがなくなって絶望した
- ある人のポケットから地図が出てきた
- 地図を見ると希望を持つことができて降りることができた
- しかし地図は実は全然ちがうものだった
- 教訓としては、これがあれば大丈夫と感じるものを持つことが大切であるという風に感じた
- 銀行はお客様をストレッチすることができると考えている
- 銀行は社会的な使命を持っているので、サービスへの貢献を感じられる環境が必要だと思っている
- 引き続きアジャイルに取り組んでいきたい

感想

単純にウォーターフォールが悪いわけではないと思いますが、大きいプロジェクトでは様々な課題があることがよく伝わりました。AWSを活用することにより柔軟な進め方ができると思うので、うまくアジャイルも使っていけるといいですね。

前半のどのようにAWSを活用しているかもPrivateLinkなど地味ですが重要なサービスも使われていたので参考にしたいですね！

#3 ドリンクフードスポンサーLT 株式会社QUICK 沖原久憲さん『マーケットデータ新ビジネスに対するQUICK Xignite APIsの効果』

XigniteはAWSとリンクして動いている
- 2006年からREST API提供開始している
- 2010年にNASDAQのData on Demandを展開
- 2016年にQUICKが出資
- 2017年QUICK Xignite APIsサービス開始
Xigniteの顧客は欧米を就寝に1,100社
なぜこの会社と提携したか
- スマホのアプリケーションの開発が大変なのでなんとかしたい
- 例えばマーケットデータを使ったサービスを開発したいとする
  - 昔はC言語のライブラリを提供していた
  - お客様は受信サーバから開発していた
  - pub/subやWebサーバも作って最後にスマホアプリを作る必要があった
  - 受信データは構造体で非同期
  - 考慮事項がたくさんあった
    - お客様が沢山勉強しないといけなくなる
    - 本当にやりたいことではない
- これを解決
- Xignite APIsでは端末へのデータの配信までおまかせ
- お客様はUIなどに集中できる
- 具体的にはREST APIでリアルマーケットデータを提供
  - URLに問い合わせパラメータを付けてHTTP GET
  - HTTP応答のデータ型を確認
- APIリストを提供
まとめ
- 自社サービスの価値創造にフォーカスできる
- 欲しいデータのワンストップで答えられる
- マーケットデータインフラを抱えなくていい
- スタートアップニーズに理解がある