アーカイブ動画
金融の未来を技術で描くNTTデータのITプロフェッショナル集団
国内最大のSIerであるNTTデータ。現在は国内、グローバルの売上比率がおよそ半数を占めている。
国内においては金融分野の売上が最も大きく、ATM関連のシステムも含め、全国1200の金融機関をつなぐ決済システムなどを構築している。
私たちの生活に必要不可欠な金融インフラを手がけており、なくてはならない存在だと言えるだろう。
今後は金融分野に限らず、他の部門とも連携しながら、AIやクラウドといった最新技術を活用した新規ビジネスをクロスインダストリーで創出すること等を目標として掲げ、さらなる飛躍を目指している。
組織構成について金融分野はクライアントや事業内容によりいくつかの部門に分かれており、それぞれがシステム開発などを進めている。
一方、今回の登壇者が所属する技術戦略推進部は、「金融の未来を技術で描く」とのミッションを掲げ、部門を横断して各部門のシステム開発プロジェクトを技術支援する部隊。金融分野の様々な領域に携わりながら、先進的な高難度プロジェクトを支援することで、さらなる技術や知見を蓄積し続けている。
非機能の達人: 非機能における要件と現実のギャップを紐解く
株式会社NTTデータ
シニア・スペシャリスト 米山 貴丈氏
最初に登壇したのはNTTデータに入社以来、Linux技術者として様々な業界や規模の異なるオープン系システムの基盤構築に携わってきた米山貴丈氏だ。米山氏は「非機能要件」をテーマに語った。
そもそも非機能要件とは、スマートフォンで何かアクションを起こした際の応答までに要する時間。つまり性能面などを示したものであり、「期待される振る舞いをクライテリアすること」である。
具体的には「SLA（Service Level Agreement）」や「SLO（Service Level Objective）」として何かしらの指標に基づいた目標値を設定すればよいのだが、そう簡単ではない。その理由は大きく2つある、米山氏は説明を行った。
理由の1つ目は、大前提としてある程度の充足性を持った形で非機能要件を決める難易度が高いこと。2つ目は、ステークホルダーが特定・決定すべきではあるが、受託開発の場合は特にビジネス部門が決定する難易度が非常に高いからである。
「非機能要件を定義する必要がありますから、お客様やステークホルダーにヒアリングを行い、課題を引き出します。しかし、この業務はかなり難しいと捉えています」（米山氏）
例えば、スマートフォンのレスポンスは、何秒以内であればサービスレベルとして正しいのか。ビジネスとしてのバリューを生み出せるのか。事業会社が自社内で開発する際は考慮の上、そのクライテリアを決定していくが、受託開発の場合は上流レベルで決めてしまい、その設定を正解として開発を進めることとなる。
その結果、ステークホルダーが不満に感じてダメ出しをしたり、場合によってはインシデントと捉えるか否かの認識相違につながったりしてしまうこともある。このような状況、課題を解決するためにはリファレンスをしっかりと持っておくこと。ステークホルダー間で共有して確認しておくことが必要だ。
だが、先のビジネスインパクトの話に重なるが、非機能要件を正しく定義することがビジネスのインパクトにつながるとの議論がそもそもあまりされていない、と米山氏は指摘する。
「落としがちな観点ではありますが、一歩立ち止まって考える必要があると思っています。AWS Well-Architectedフレームワークにおいても、いの一番にビジネス観点でのバリューや優先度が何かを問われます」（米山氏）
どのような要素が具体的に、非機能要件として定義されないのか。米山氏はこれまでの経験から3つ紹介した。
1つは「回復性／可観測性」である。対策としては、エンジニアの裁量だけに任せず、インシデント発生時に原因の調査がしっかりと行えること自体を要件定義の項目として捉えること。以前は止まらない、トラブルのないシステム構築を目指す傾向にあった。だが、最近はトラブルが発生した際にどのように回復するのか、レジリエンスを重視する流れであり、そのような観点からも同要素を定義することは重要だと述べた。
2つ目は「流量制御」である。米山氏は待ち行列モデルを示し、流量、サービスタイム、サービス数、ならびにそれらの規定値を超過した際に、どのように振る舞うかを非機能要件としてしっかりと定義し、実装することが重要だと語った。
3つ目は「構成管理」だ。システム構成は複雑であり、機器やアプリケーション、その利用ライブラリなどのバージョンを網羅的に管理する事は非常に難しい。米山氏は未だに正解か分からないと前置きしながらも、絶対に止めてはいけない、バグを出してはいけない、と言われるような重要なシステムにおいては、要件としてしっかり定めておくことが重要だと述べた。
「このような取り組みの内容を反省点や実際のトラブル情報なども含め、ポストモーテム的にドキュメントとして残しておく。次のプロジェクト時にステークホルダーに配布したり、検討の参考にしてもらう取り組みが大事です」（米山氏）
最後に、システム開発時に品質担保のためのルールとして取り入れ運用していくことが大事だとまとめ、米山氏はセッションを締めた。
セキュリティの達人: 不正ログインのリスクに光明が！？
株式会社NTTデータ
課長 阿久沢 佑介氏
続いて登壇したのは、金融系システムのセキュリティに関する業務に従事している阿久沢佑介氏だ。脆弱性対応やインシデント対応、セキュリティビジネス拡大など、セキュリティに関する守りから攻めまで幅広く担当している。
国内における不正アクセスの現状は不正ログオンがほとんどであり、うち半分がインターネットバンキングを介した不正送金という現状から「不正ログオンのリスクに対処する必要がある」と、阿久沢氏は語る。
不正ログオンの事例も2つ解説された。1つは多くの人が知っている物語における呪文「ひらけゴマ！」だ。いかに堅牢な岩屋に宝を隠しておいても、扉を開く呪文を盗み聞きされたことで不正侵入されたケースである。
もう1つはフィッシングと呼ばれる手口だ。本物と見分けのつかない、阿久沢氏いわく「丸コピーしている」インターネットバンキングのサイトにユーザーを誘導し、ログイン情報を取得。その後、本人に成り代わりインターネットバンキングに侵入し、お金を詐取する。
どちらの事例も直接システムが攻撃されたわけではなく、人を対象とし、騙したソーシャルエンジニアリングの代表的な事例である。
「人は騙されるしパスワードは盗まれる。これは古（いにしえ）から現在に至るまで変わらないものです」（阿久沢氏）
阿久沢氏は、さらにパスワード認証の脆弱性を紹介した。まずは「リスト攻撃型」である。同じIDやパスワードを使い回しているユーザーは少なくない。そこをついた攻撃であり、漏洩したIDとパスワードをかき集めることで、他のシステムに侵入していく。
驚くのは、漏洩しているID・パスワードの数である。その数なんと約127億個。先の2事例と同じくシステムの不備が狙われるのではなく、正面から堂々と正しいIDとパスワードで突破されていくのである。
「このような背景があってもこれまで人類は、パスワードに代わる認証技術を発明できずにいました。そこで何とか苦し紛れに開発したのが多要素認証です」（阿久沢氏）
ワンタイムパスワードなどの所持認証と、従来のパスワードなどの知識認証の組み合わせである。しかし、「多要素認証もすでに突破されはじめている」と阿久沢氏は言う。
例えばワンタイムパスワードによる認証では、ワンタイムパスワードの有効時間が限られていることでセキュリティを高めるが、手口としては先のフィッシングと同じようにワンタイムパスワードを盗み、すぐさま犯行に及べばお金を盗むことができるからだ。
AiTM（Adversary in The Middle）という攻撃の手口では、フィッシングサイトがあたかもプロキシサーバーのような役割を担い、Cookie情報を窃取することで不正にアクセスする。
「フィッシングに使うツールは世の中に出回っています。スキルが高くない攻撃者でも手軽に攻撃できるのが現状で、多要素認証も限界だと言われています」（阿久沢氏）
このような流れから生まれたのが、阿久沢氏“推し”のパスワードを使わない、「FIDO（Fast IDentity Online）」。指紋や顔を使った生体認証などの「ローカル認証」と、「公開鍵認証」を組み合わせた認証方式である。
FIDOではデバイスから絶対外に出ないよう管理されている秘密鍵によって本人認証を行う。Webサービス側はFIDO登録時に生成された秘密鍵とペアになる公開鍵を保有しており、これを用いて秘密鍵の所持を確認、アクセスを許可する。
さらに、デバイスの持ち主が本人かどうかを確認するために指紋認証などのローカル認証も行っており、ローカル認証とネットワーク経由の公開鍵認証技術の組み合わせで安全性と利便性を高めている。
FIDOであれば人と異なり、騙されることもない。人が騙されるのはUIの情報で本物のサイトだと思い込むからであり、実際のドメインは異なっている。FIDOの場合は正しいドメインが鍵にラベリングされているため、偽サイトに対してFIDOは動作しない。
ただし、FIDOにも「アカウントリカバリー」という課題があるという。端末買い換え時や端末を破損したときなど、新たなデバイスで同じサービスにアクセスする際は、新しいデバイスでFIDO以外の手段を使ってログオンのうえ、改めてFIDO利用登録が必要となる。その際のログオン方法として、従来通りのパスワード認証を残しておく必要があるからだ。FIDOがどれだけ安全でも、パスワードでもログオンできる状態では、攻撃者は今まで通りパスワードを盗むことで不正ログオンできてしまう。
「我々が目指しているのはパスワードをこの世からなくすことです。そこで本当におすすめしたい技術が、FIDOの発展系であるPasskeys（パスキー）です」（阿久沢氏）
PasskeysはFIDOの秘密鍵管理に柔軟性を持たせた技術であり、デバイスが異なっていてもクラウド経由で秘密鍵を共有できる。つまり、先のアカウントリカバリー問題は解決する。
Passkeysを導入すれば、パスワードの無効化も可能となる。以前ログイン時に利用していたID・パスワードが盗まれ悪用されようとしても、不正にログインされることもない。
「古代ローマ時代から2000年ほど使われてきたパスワードに代わる認証技術が、ようやく生まれました。私たちはSIerとしてこのPasskeysを金融システムでも広く使っていくことで、安心安全なネットライフを構築し、ユーザーさんを守っていきたいと考えています」（阿久沢氏）
開発効率化の達人: LCP開発の効率向上のために押さえるべきポイント
株式会社NTTデータフィナンシャルテクノロジー
ソリューション＆テクノロジー事業部
上級プロフェショナル 藤貫 美佐氏
続いて登壇したのは、NTTデータにおいて、開発・管理・見積もりプロセス領域でキャリアを積んできた藤貫美佐氏だ。現在は、NTTグループの金融分野の中核会社であるNTTデータフィナンシャルテクノロジーで「プロジェクトの測る化」コンサルティングサービスに取り組んでおり、これまでの知見をまとめた書籍も数冊上梓している。
藤貫氏は、ソフトウェアの機能規模を測定することで、開発工数の見積もりを測定する手法「ファンクションポイント」の普及などを推進する、日本ファンクションポイントユーザ会（以下、JFPUG）の会長も務めている。
JFPUGではファンクションポイントに関する事業を中核としながらも、様々な定量データの活用方法も検討。昨今注目されているローコード開発（以下、LCP開発）のノウハウが社会全体で不足していると考え、SIGというグループを発足し、取り組みを進めている。
具体的には、JFPUGの会員からLCP開発に関する情報を収集した。すると、「見積もり」「品質管理」「開発プロセス」の3つの面で課題が生じていることが分かった。その課題に対して仮説を立て、会員に調査を実施。得た情報を分析し、成果物としてまとめ会員に再びフィードバックしている。
「開発効率化には2つの局面があると思っています。1つは、積極的に技術を活用し効果を最大限に発揮する“攻め”。もう1つは起こりがちなトラブルを事前に察知し、プラスアルファのコストがかからないようにする“守り”です」（藤貫氏）
藤貫氏は対策として、「攻め・守り」両面を考えていくことが必要だと続け、開発プロセスにおける攻め、見積もりにおける守りについて言及した。
以下スライドでは、基本設計、詳細設計、製造・UTといった赤くマーキングされた領域で多く使われていることが分かる。マッピングは成果物単位でさらに細かく可視化したものであり、同じく赤枠で囲われた成果物がLCP開発で、青枠の成果物が人の手により作られたものを示す。
「この赤枠の部分は、設計工程でLCP開発を行うことが生産性向上の源泉であり、いかにこの領域でアクセルを踏み込みドライブしていくかが重要になります」（藤貫氏）
調査で得た情報をもとに、LCP開発に関する教訓を7つのTipsとしてまとめたドキュメントも紹介された。例えば、LCP開発に頼ることで作成するドキュメントは、積極的に減らすことが、生産性向上における攻めの取り組みであることが記載されている。
一方で、データモデリング、構造設計、アルゴリズム設計が必要であること。LCP製品の仕様により制約を受けるため、「事前に把握しておくことが開発効率化も含めLCP開発を効果的に進めるためのポイント」だと、藤貫氏は語った。
続いては、見積もりにおける「守り」の開発効率化について説明された。調査に答えたある会社では、LCP製品に対する過度な期待もあり、PoCの結果をもとに開発全体の期間、工数を見積もった。ところが使えると思っていた標準機能が使えず、設計は難航する。
短納期で見積もっていたこともあり、不十分なまま実装やテスト工程に臨み、カットオーバーまで至る。しかし、本番で障害が発生し設計フェーズからやり直すという事態になる。結果、逆にコストは大きくかかってしまった。
失敗の原因はPoCでの成果をベースに全体を見積もったことは明白だが、このようなトラブルを避けるにはどうすればよいのか。
LCP開発では、限りなく手を動かさないで作っていくため製造規模は減少する傾向にある。しかし、できあがった製品の機能規模は手作業で作った場合と変わらない。つまり、両者でギャップが生まれることになる。
「規模感が見えないからこそ、機能規模として代表的なファンクションポイント数や画面帳票数などをベースに、見積もりを行うことがポイントです」（藤貫氏）
藤貫氏は「FP（ファンクションポイント）簡易推定法」という手法を用い、実際に正しい見積もりが行われるかどうかを検証。しかしファンクションポイントのデータ数が少なかったことから、画面、帳票、バッチ、テーブル、インターフェースといった要素を利用し、ファンクションポイントを推測する流れで進めていった。
その結果、「本来であればファンクションポイントを測ってもらいたい」と前置きしながらも、同手法でも精度は保たれることが分かったと結論づけた。
このファンクションポイントによる推定法と工数の関係においては、生産性が高まっていることが確認できたものの、今後は対象件数を増やすことでより確実性を高めることが課題だと述べた。
また、このようなファンクションポイントをベースとした簡易推定法は、LCP開発以外の領域でも使えると補足。次のように述べ、セッションを締めた。
「LCP製品は製品により様々な制約があるので、その制約を早目にフィット＆ギャップして、ギャップがある部分は製品に合わせるのか、機能を拡張するのかを決めること。そうした制約事項を詳細基本設計の中でお客様とも共有しながら、明確に進めていくことが成功のポイントです」（藤貫氏）
【Q＆A】参加者からの質問に登壇者が回答
セッション後は、イベント参加者からの質問に登壇者が回答した。
Q．堅牢性を高めるために非機能要件の定義で意識していることは？
米山：まずは期待される堅牢性を言語化する必要があります。例えば、ファイブナイン（99.999％）を本当に達成しなければいけないのかなどです。
我々は自社製品以外に、他社製品を扱う場合もあります。その際は、扱う製品が本当に大丈夫かどうか、ベンダーの利用歴やソースコードを直接確認することもあります。これらの取り組みにはコストがかかるため、予算とのバランスを考えながら、総合的な考えで決めることが重要なポイントです。
Q．非機能項目の優先度が高くなかった場合、どのように引き上げればよいか
米山：まずはお客様が実現したいビジネス、本質的に成し遂げたいことを確認する必要があります。その上で、非機能要件のレベルをすり合わせていきます。場合によってはこちらから提案を行い、コンサルティングに近い業務となる場合もあります。
Q．FIDOが突破される可能性はゼロか？
阿久沢：Passkeysを利用しない場合は、パスワード認証履歴が残るため、パスワードを盗まれたり、攻撃されたりする可能性があります。対してPasskeysは、公開鍵認証の仕組みを突破する方法は現状ないので、当面は大丈夫だと思います。
ただし、デバイスが盗まれピンコードを読み取られた場合は突破されます。とはいえ、パスワードを盗まれ攻撃されるケースと比較すれば、被害に合う確率はかなり低いと言えるでしょう。
Q．金融機関でのFIDOの導入率や導入予定は？
阿久沢：現状は1割以下だと捉えています。金融機関から問い合わせをいただく機会も増えていますが、大部分をカバーするまでにまだ時間がかかりそうです。
Q．Passkeysでも秘密鍵を紛失した際は、パスワード認証が必要になるのではないか？
阿久沢：まさにその点がPasskeysの大きなリスクとなります。例えばiPhoneであれば、iCloudの認証を介してPasskeysの秘密鍵を自分のデバイス内に共有できます。
ただし他の関連デバイスもすべてなくしてしまい、新しくデバイスを買ってきた際はiCloudに入る必要があり、その際の認証手段を使って攻撃されるリスクが残ります。つまり、Passkeysを突破する可能性はゼロではないと言えます。
Q．事故などにより顔のかたちが変わってしまった場合、FIDOは利用できないのか？
阿久沢：ピンコード認証が使えます。パスワードはどのデバイスでも使えますが、ピンコードは特定デバイスを解除するためのパスワードなので大きく異なります。ただし、ピンコードを盗まれるとデバイスは解除されるため注意が必要です。
Q．金融システムのセキュリティならではの難しい点、面白い点は？
阿久沢：セキュリティにおいては、認証を完璧にしたらそれで大丈夫とはならない点です。攻撃者は一番楽で弱いところを狙ってくるため、全方位で守る必要があります。一方で、特に金融システムは安定運用を求められるため、運用とセキュリティのバランスを取るところが難しいとも感じています。
面白いと思う点は社会生活に結びついている分野なので、守るべき大事なものがたくさんあること。加えて、金融ビジネスまで一歩踏み込んだ上で、セキュリティを考える必要がある点です。
Q．金融業界ならではの特徴、直近のトレンドやニーズの変化は？
米山：金融業界の特徴として、世の中で流行ったものを後からフォローしていく傾向があると思います。直近では生成AI、過去にはブロックチェーンやクラウドなどです。生成AIに関しては業態に関係なく、使えそうなユースケースはないか、ビジネスに活かせないかなど、考えているお客様が多い印象です。
Q．内製化のトレンドは金融業界でも同様か
米山：事業者のカテゴリーを分けて考える必要があります。例えば、キャッシュレス決済サービスを展開しているベンチャー企業の場合は、自社・内製製品が多いと思います。
対して、いわゆるトラディショナルな金融機関では、自社の体制にエンジニアを組み込み、内製化を進めるのは、現時点では難しい状況です。そのためデジタル子会社を設立し、その会社で内製化を進める取り組みがあります。
Q．金融分野で働くために必要なこと、親和性の高い経験は？
米山：金融分野の知識を持っていることは当然メリットではありますが、必須ではないと考えています。私自身もキャリアの半分は金融とは関係ありません。一方、親和性においては金融分野の特色になりますが、レギュレーションを手堅く進める傾向にあるので、定められたことをきちんと実行できる。このような方が向いていると思います。
他のインダストリーとクロスオーバーし、社会を変えるようなイノベーションや新しいビジネスを生み出すアントレプレナー的なマインドを持っていれば、金融分野に限らずどこでも活躍できるのではないでしょうか。
藤貫：金融分野だからといって、特別必要な技術や業務があるわけではありません。あくまでベースの技術や業務があり、そこに金融がプラスアルファで加わる文脈だと思います。
株式会社NTTデータ
https://www.nttdata.com/jp/ja/
株式会社NTTデータの採用ページ
https://www.nttdata.com/jp/ja/recruit/
関連するイベント
