Other parts of this series:
事業環境の変化スピードは年々増し、その不確実性への備えは競争戦略上なくてはならないものとなった。備えに対する処方箋の一つはアジャイルビジネス態勢に向けた全社トランスフォーメーションである。
アジャイルビジネスに重要な要素はガバナンスとシステムであり、具体的には、俊敏性をもった意思決定と執行に移せるガバナンスモデル、環境変化スピードに柔軟なシステムアーキテクチャの2点をいかに構築できるかである。
本稿では、特にアジャイルビジネスを実現するためのシステムアーキテクチャとはどうあるべきかを概説し、導入オプションの考え方を示す。なお、本稿全般にわたり、本年5月にサービスリリースをした「みんなの銀行」をモデルケース題材として取り上げている。
不確実性とアジャイルビジネス
1. 不確実性の中で求められること
デジタル化に伴う事業変化と、顧客期待の変化が、相互に加速しあうことで事業環境変化のスピードは年々上がってきている。もはや1-2年立ち止まっているといつの間にか競争環境が激変していることも珍しくない。この競争環境下において、自社事業の提供価値を顧客期待にライトタイミングで合致させ、市場勝者となることを事前に確度高く準備することはたやすくない。プランニング時点とリリース時点での時差がクリティカルなほど変化の早い業界では、それはさらに至難の業と言える。そこで求められるのがビジネスとしてのアジリティである。正解が分からないことを前提として、環境変化に柔軟に追従できるような態勢を整えることが重要、という発想だ。
2. アジャイルビジネス
変化に追従する態勢を整えるためには事業転換の俊敏性をいかに上げられるかが鍵となる。その為に、特に重要となるオペレーティングモデルの要素は ガバナンスとシステムにある（図表1）。
· ROIに頼らない実行判断と予算配賦の枠組みがあること
· 予算執行権限が市場に近い現場責任者に権限移譲され、その裁量の中で予算執行できること
· 意思決定後からリリースまでにスピーディーに開発遂行できること（いわゆるアジャイル開発）
· システムアーキテクチャ自体が俊敏な事業転換を支えられる構造になっていること
特に4点目に関しては、従来からの重厚長大な銀行システムでは実現が難しい。本稿では、銀行として変えてはいけないもの（＝ミッションクリティカル性、パフォーマンス、セキュリティ）全てを担保した上で、かつ、アジャイルビジネスを実現する柔軟性を持つバンキングシステムとはどうあるべきか、に的を絞って議論したい。題材として2021年5月末にリリースされた「みんなの銀行」を取り上げるべく、本題に入る前に簡単にご紹介させて頂く。
3. 先行事例 ～ みんなの銀行
ふくおかフィナンシャルグループの子銀行として新たに銀行業免許を取得し、設立された日本初のデジタルバンクである。新しい時代に合わせ、銀行の存在意義を問い直しその役割を再定義することを掲げた挑戦的な取組みである。非金融事業者や海外スタートアップが数多く参入している国内金融市場において、事業の「正解」を予め確実に見定めることは到底出来ない。従い、アジャイルビジネスを前提とすることが必須であり、100年以上に渡る間接金融事業に最適化された既存銀行の枠組みでは実現が非常に難しいと言わざるを得ない。難易度の高い挑戦を実行するためには、全てをゼロベースで設計し直し、銀行がデジタルサービスを展開するのではなく、デジタル企業が銀行サービスを展開するパラダイムシフトによる新しい組織設計を行った。実際には、システムの構築はグループ子会社であるゼロバンク・デザインファクトリー社が担っており、弊社との包括的なパートナーシップのもと価値共創に向けた様々な取組をご一緒させて頂いている。
次世代型バンキングシステムの要諦
あるべき次世代型バンキングシステムを検討し構築された「ゼロバンク・コア・ソリューション（ZCS）」及びそのフレームワークとしての「アクセンチュアクラウドネイティブ コアソリューション（MAINRI）」は、前述の問いに対する現時点の一つの回答であり、それらを概観することは有用といえる。
1. マイクロサービス&APIアーキテクチャ
全てのアプリケーションはマイクロサービスとして疎に細分化構築されている。また、顧客情報のマイクロサービスとビジネスロジックのマイクロサービスは分割されており、それらを厳密なメッセージキューイングで参照させることで、整合性担保とパフォーマンス・スケーラビリティの両方を実現している。それらマイクロサービス間、及びチャネルとは全てAPIで接続される。これにより、サービスの新設や廃止、外部パートナーとのエコシステム組成といったビジネスの変化に対しての柔軟性が低コストで担保されており、アジャイルビジネスの根幹を支える。
2. データのニア・リアルタイム連携
サービス開発の柔軟性だけでなく、サービスやオファーを顧客の状況に合わせて如何にダイナミックに変化させられるかも重要な観点である。ZCS/MAINRIでは、モバイルの位置情報・操作情報ログから、基幹系トランザクションの変化まで全てのデータがニア・リアルタイムでDWHに連携されるよう設計されており、そのデータを分析・アウトプットすることで、あらゆるハイパーパーソナライズの可能性を現実的に探索することができる。
3. オートスケールとDevSecOps
システムやサービスの柔軟性と同時に、ミッションクリティカル性（データ整合性・堅牢性・耐障害性）の担保も命題の一つであり、そのためにフルクラウド構築を採択している。単一障害点を可能な限り無くし、かつ、突然の負荷集中や障害時には必要な機能がオートスケールする。万が一システムが落ちた場合にはマルチリージョンからの自動復旧を行う、自発的かつ堅牢なバックアップを実現している。システム運用面では、開発から本番環境運用までオートメーション化されており、特筆すべきは、プロセスの中にセキュリティ観点のテストが組み込まれており自動で常時チェックされることが仕組み化（=DevSecOps）されていることである。
4. リアルタイム分散バッチ処理アーキテクチャ
バッチ処理でも、突発負荷への対策を組み込んでいる。バッチ処理を並列分散させると同時に、負荷に応じてオートスケールする仕組みを構築している。
以上、1～4の内容は要素分解したうえで改めて図表2に整理しておく。
アジャイルビジネスの導入
1.ヴィークルの考え方
アジャイルビジネスを支えるシステム基盤を導入するにあたっては、3つの論理的オプションがある：①既存基幹系システムを改修する、②既存基幹系システムを新しいシステムに置換する、③新しいヴィークルを作りシステムを追加導入（並走）する。
コスト及びリスクの大きさを考慮すると、ちょうどシステム更改タイミングを迎えている等の特殊事情がない限りは、③の方針が現実的である。特に、アジャイルビジネスの強みを活かし、試験的なサービスやビジネスモデル構築に取り組んでいく場合は③が最も親和性が高い。もちろん、新しいビジネスがうまくいけば、本体の事業資産を段階的に新しいヴィークルに移行させていくことも視野に入る。
2. システム導入の考え方
システム導入にあたっては、いわゆる、BUY（パッケージの導入）、BUILD（スクラッチ開発）、BORROW（SaaS型での利用）、の3オプションのうち最適解を選択することになる。
みんなの銀行では結果的にBUILDを選択したが、もちろんBUY/BORROWのオプションも天秤にかけた結果である。選択肢を決めた大きな要素は、既存パッケージやSaaSシステムで、要件水準、コスト、スケジュール、リスクを満たせるソリューションが世になかったことである。
3. ZCS/MAINRIの利用
次世代型バンキングシステムの商用化が実現した今、今後は様々な活用シーンでの活用が見込まれる。みんなの銀行・弊社では、国内外企業に対し、システム提供をベースとしたパートナーシップ探索を積極的に展開する予定である。システムは、前項で紹介した通り、事業環境変化（サービスの新設/改廃、中長期的なスケール、突発的なスケール、等）に柔軟で、かつ非機能面での優位性（可用性、セキュリティ、運用面、等）も備えた、バンキングシステムでは前例のないアーキテクチャを備えたものである。
不確実性への備えが必要な中、アジャイルビジネスへの全社トランスフォーメーションは競争戦略上なくてはならないものとなってきている。自社自行ではどうすべきか？を議論し早々にアクションに移していかれたい。
FSアーキテクトは、金融業界のトレンド、最新のIT情報、コンサルティングおよび貴重なユーザー事例を紹介するアクセンチュア日本発のビジネス季刊誌です。過去のFSアーキテクトはこちらをご覧ください。
