20250719_JAWS_kobe

Transcript

1. 1 © 2025 Japan Digital Design, Inc. Takuya Yo nezawa 2025.07.19 仮）誰のためのレジリエンス？ JAWS-UG 神戸 #7
2. 2 © 2025 Japan Digital Design, Inc. FIS体験の後ホクホクしているところに失礼します
3. 3 © 2025 Japan Digital Design, Inc. 米澤 拓也 前職ではCCoE、現職ではSoftware Engineer フロント/バックエンドの実装からインフラ構築など何でもやってます 奈良 大阪の2拠点生活。先日田植えを終えた 実は社会人キャリアの大半が金融ドメイン（証券：3年、銀行：2年） AWSパートナー企業→エンドユーザー企業 プロフィール Software Engineer Technology & Development Div. and Corporate Culture室
4. 4 © 2025 Japan Digital Design, Inc. 先月re:Inforceに参加しました （Noteも書きました） https://note.com/japan_d2/n/n9255fa3d5230
5. 5 © 2025 Japan Digital Design, Inc. オペレジ NYCオフィスで”オペレーショナル レジリエンス”のセッション スピーカーは Principal Compliance SpecealistのRussell Lewis氏 Amazon NYCオフィスから見えた エンパイアステートビル
6. 6 © 2025 Japan Digital Design, Inc. https://www.fsa.go.jp/news/r4/ginkou/20230427/03.pdf オペレジ 金融庁からもディスカッション ペーパーが公開された （2023/03） 金融庁報告事案を経験した会社は、 二度と金融庁報告事案を起こさない と話題
7. 7 © 2025 Japan Digital Design, Inc. オペレジ 金融庁からもディスカッション ペーパーが公開された （2023/03） 金融庁報告事案を経験した会社は、 二度と金融庁報告事案を起こさない と話題 https://ja.wikipedia.org/wiki/バーゼル銀行監督委員会
8. 8 © 2025 Japan Digital Design, Inc. オペレジ 金融庁からもディスカッション ペーパーが公開された （2023/03） 金融庁報告事案を経験した会社は、 二度と金融庁報告事案を起こさない と話題 https://d2908q01vomqb2.cloudfront.net/ b3f0c7f6bb763af1be91d9e74eabfeb199dc1f1f/2023/07/17/1_Resiliency_Trend.pdf
9. 9 © 2025 Japan Digital Design, Inc. こんな感じで36p続く オペレジ 金融庁からもディスカッション ペーパーが公開された （2023/03） 金融庁報告事案を経験した会社は、 二度と金融庁報告事案を起こさない と話題 https://www.fsa.go.jp/news/r4/ginkou/20230427/02.pdf
10. 10 © 2025 Japan Digital Design, Inc. こんな感じで36p続く オペレジ 金融庁からもディスカッション ペーパーが公開された （2023/03） 金融庁報告事案を経験した会社は、 二度と金融庁報告事案を起こさない と話題 https://www.fsa.go.jp/news/r4/ginkou/20230427/02.pdf
11. 11 © 2025 Japan Digital Design, Inc. 障害は起こるもの ~Everything fails, all the time~ ITシステムの依存性、企業間連携など相互依存により、複雑化する一方。 社外のサードパーティ、フォースパーティ（3rdの再委託先）が絡む中、 特定部分の障害や不具合がどの部分に波及するかを把握・管理することは国際的に も重要な課題と認識されている。 業務中断が起こることを前提に、利用者目線に立ち、 代替手段を通じた早期復旧や影響範囲の特定を担保する枠組みが重要。 事前にリスク事象を想定して対応策をまとめるような BCP的アプローチでは不十分かもしれない
12. 12 © 2025 Japan Digital Design, Inc. Operetional Resilience システム障害、テロやサイバー攻撃、感染症、自然災害等 の事象が発生しても、金融機関が重 要な業務を、最低限維持すべき水準（耐性 度）において、提供し続ける能力と定義する。 Operational Risk 金融機関の業務の過程、役職員の活動若しくはシステムが不適切であること、 機能しないこと又は外生的な事象により損失が生じるリスクをいう。 Operational Risk Management 主要な商品や業務プロセス、システムに内在するオペリスクを特定し、 評価し、把握し、管理 し、かつ、削減・移転するための戦略を策定することをいう。 〜 Example 〜 自社 ATM の故障により現金の受払ができなくなった場合には、システムの早期復旧自体も当 然に重要であるものの、利用者目線では、迅速にウェブサイト、アプリ、SNS 上で障害状況や 代替手段（他社 ATM やオンラインバンキング）が案内される広報もまた重要である。 オペレジの観点からは、利用者目線で、サービスの提供途絶の影響を極力一定の範囲内に収め ることが重要である。 障害は起こるもの ~Everything fails, all the time~
13. 13 © 2025 Japan Digital Design, Inc. オペレジの基本動作 重要な業務 の特定 耐性度 の設定 ・相互連関性のマッピング ・必要な経営資源の確保 ・適切性の検証 ・追加対応
14. 14 © 2025 Japan Digital Design, Inc. Step1. 重要な業務の特定 重要な業務（Critical Operations） その中断が金融システムの安定や利用者の日常生活に著しい悪影響を生じさせるおそれのある 金融サービスのこと 資金決済だけでな く、融資、市場シェアの著しく高いサービスなども、金融システムや利用者 に与 える影響が大きいことから、危機時においても業務継続の対象として選定され ていること が多い
15. 15 © 2025 Japan Digital Design, Inc. Step2. 耐性度の設定 耐性度（Tolerance for disruption） 金融機関は、業務中断が必 ず生じることを前提に最低限維持すべき水準を「耐性度」 として設 定する必要がある。 耐性度は、典型的には BCP において設定する業務中断時の目標復旧時間 （RTO）と重なるが、 それ以外にも、金融システムへ の影響や利用者目線で生活への影響を一定の範囲内に収める観 点から、業務中断が生じる範囲、影響を受ける取引数、取引額及び利用者数（例えば、業務中 断時の利用者からの苦情数）なども考慮要素となりうる。 なお、金融システムや利用者の生活への影響を軽減することは、必ずしも自 社のシステム復旧 だけにこだわることを意味しない。システムの早期復旧自体 も当然に重要であるものの、利用 者目線では、迅速な代替手段の案内や広報もまた重要である。 例えば、可用性 99.99％を 99.999％にしたときにコストが 10 倍になるとしたら、利用者はそ のコストを負担してまで高い可用性を本当に望むのか、それとも多少はダ ウンタイム（停止時 間）があったとしてもそれが許容できる範囲内なのであれば、むしろ低価格を選好するのか、 あるいはアクセスの容易性などの別の利便性を重視するのか、というのがここでの論点である。
16. 16 © 2025 Japan Digital Design, Inc. Step3. ・相互連関性のマッピング ・必要な経営資源の確保 重要な業務の耐性度での提供に必要な社内外の経営資源（ヒ ト・モノ・カネ）を端から端まで （end to end の業務プロセス全体で）特定し、それ らの相互連関性や相互依存度をマッピング する必要がある。その上で、必要な スキル・専門性を持った役職員を採用・配置し、適切な施 設、システム、サード パーティ等を調達・確保し、保守・改善のための十分な投資を行う必要 がある。 サードパーティがどの程度までサービスのレベル（定義、範囲、内容、品質、ダウンタイムな ど）を保証するかを明示した SLA（Service Level Agreement）を締結し、耐性度との整合性を 図ることが重要である。例えば、クラウド事業者の SLA 上の可用性が 99.99％である場合には、 当該イン フラの上に乗る金融サービスの可用性はそれ以下にならざるを得ない。 利用者目線 で、どこまでの可用性が求められているのか、コストとの見合いでバランスを図る 必要がある。 大手クラウド事業者は、市場における寡占度や、勘定 系システムのインフラとして採用された 場合の重要な業務に与える影響が重大であ ることから、重要なサードパーティとして見なされ ることが多い。
17. 17 © 2025 Japan Digital Design, Inc. Step3. ・相互連関性のマッピング ・必要な経営資源の確保 他方で、システムのオープン化やクラウドシフトに伴うリスクよりも、オープン化せず、クラ ウドを使わないことにより、外部環境の変化に取り残され、システムが劣化し 続けるリスクに ついて留意すべきとの声も聞かれている。すなわち、金融機関がソフ トウェアを活用して業務 を行うにあたっては、技術や人材などの外部環境の変化に 応じて定期的にシステムを更改し、 品質の悪化を防ぐ必要がある。一般的な仕様や公開された技術を用いたオープン系システムや シェアの高い大手クラウド事業者の運営するクラウドサービスは、汎用性や可搬性が高く、外 部環境の変化に適 応しやすいと評価する声も聞かれている。 IT システム開発について自前で判断できる体制（コントローラビリティ）を確保することが重 要である。具体的には、そもそも何を作るのか、ソフトウェアの設計をどうするか、どの技術 を使うか、どのサービス構成とするか、誰に開発（コーディン グ）してもらうかを金融機関が 主体的に決定し、IT ベンダーから納品されたコードを見てその品質を判断・管理する必要があ る。IT ベンダーに言われるがまま開発する というよりは、IT ベンダーに対しても対等にコ ミュニケーションができる状況になって 初めて、自社のシステムをコントロールしたと言える。 エンジニアの調達のしやすさという観点でシステムを採用することや、優秀なエンジニアを採 用できる賃金体系・人事制度を用意することは、DXやイノベーション推進の文脈 だけでなく、 オペレジの実効性確保という文脈でも喫緊の課題である、との声も聞か れている。
18. 18 © 2025 Japan Digital Design, Inc. Step4. ・適切性の検証 ・追加対応 経営陣のコミットメントの下、起こり得るシナリオを想定した分析や訓練等を通じて、リスク 選好度、重要な業務、耐性度、必要な経営資源に関する設定及び配分が適切であるかを定期的 かつ組織横断的に検証し、必要に応じて見直しや追加的措置を講じる必要がある。 典型的には、定期的な検証により特定した脆弱性に対して、ヒト・モノ・カネの 追加投資を行 うことが想定される。外部環境の変化に応じて、一度特定した重 要な業務や耐性度も増減させ る見直しもありうる。このほか、採用育成制度を含めた人事制度や企業文化の見直しも追加的 措置に含まれ得る。 オペレジの実効性確保のためには、システムの開発・運用から、オペレーショ ン、広報、代替 手段の確保に至るまで、利用者目線で組織が部署間の縦割りを超えて協力し、社外のサード パーティとも連携し、早期復旧に向けた態勢整備と経営資源の配分の PDCA を回し続ける必要 がある。こうした調整や協業を円滑に行うためには、異なる価値観・専門性・バックグラウン ドを持つ人員・組織同士が、お互いの違い（多様性）を認め合い、相互理解を深めていく自由 闊達な対話が不可欠である。
19. 19 © 2025 Japan Digital Design, Inc. Step4. ・適切性の検証 ・追加対応 心理的安全性の醸成 ヒューマンエラーをインシデントの原因として捉え、関与した特定の個人にペナル ティ（減 給・停職・再教育・告訴）を課す減点主義では、かえって現場の懸念や違和感 などの潜在的な リスクに関する情報共有を委縮させ、危機時の初動対応も遅れかね ない。 オペリスク原則で規定される「リスク管理文化の醸成」（原則１）は、 被害拡大につながりう る懸念材料や不具合を放置することなく、迅速に経営トッ プ・関連部署に報告（Bad News First）し、率直に意見交換して利用者目線で柔 軟に危機対応する上で不可欠な要素である。例 えば、「縦割りで、部署間や階層間の連携が悪い」、「ケアレスミスが頻発する」、「退職 者・休職者が毎月のよ うに出る」、「部下が育たず、上司がプレイング・マネージャー化す る」、「経営企 画部門は奮闘して毎年のように改革や組織再編はするも、現場は何も変わらな い」、「結論ありきで大方針が決まるため、現場は忖度した情報しか上げてこない」といった 風通しの悪い企業風土を放置していては、いくら追加的措置を講じ ても形骸化してしまい、オ ペレジの実効性確保につながらないおそれがある。 危機時においては、原因や利用者への影響を完全に把握 できているわけではない不確実性のも とで、たとえ間違っていたとしても積極的・自発的に行動し、組織の縦割りを超えて声を上げ、 利用者目線で連携して被害の拡大 を防ぐ行為が褒められる企業文化やインセンティブ設計があ るべきである。
20. 20 © 2025 Japan Digital Design, Inc. 所感 何度も登場する「利用者目線」 システム屋やっていると、方法論（カオスエンジニアリング？マルチクラウド？マルチリージ ョン？ etc…）で白熱しがち。 「誰のためのレジリエンスなのか？」とふと立ち止まらせてくれる システムを作るから壊れるわけで。。 システム化だけが全てではない。 業務プロセスの見直しで負が解決するならそれで良い。 働きたくない人の脳内 （Akiさん） プロダクトは作った瞬間に負債になる。世の中は絶えず変化・進化していくので、作った瞬間 から陳腐化が始まる。それを防ぐために継続的なメンテナンスや改善が求められる。 そりゃSLAとかはビジネス目線では高いほうが良いが。。 多大なコストを掛けて実現するSLA、本当にシステム利用者に必要とされてますか？ 住信SBIネット銀行のCTO木村氏 「止まらないシステムよりも、すぐに復旧するシステム」 「たまに止まることがあるかも知れないけど、すぐに復旧させるから許してね」
21. 21 © 2025 Japan Digital Design, Inc. References. オペレーショナル・レジリエンス（オペレジ）の概要 https://www.fsa.go.jp/news/r4/ginkou/20230427/03.pdf オペレーショナル・レジリエンス確保に向けた 基本的な考え方 https://www.fsa.go.jp/news/r4/ginkou/20230427/02.pdf 金融におけるレジリエンシー 最新動向と金融機関に求められる取組み https://d2908q01vomqb2.cloudfront.net/ b3f0c7f6bb763af1be91d9e74eabfeb199dc1f1f/2023/07/17/1_Resiliency_Trend.pdf Amazon Web Services' Approach to Operational Resilience in the Financial Sector & Beyond https://docs.aws.amazon.com/whitepapers/ latest/aws-operational-resilience/aws-operational-resilience.html
22. Thank you. 22 © 2025 Japan Digital Design, Inc.