金融アプリケーション開発の推進
~高信頼度ソフトウェアへの挑戦~

後藤 賢治

[Kenji Goto]

金融

アプリケーションプロフェッショナル

EXcited About The Future
後藤 ヘッダー写真

経済活動を支える金融、そしてその金融をITで支えているのが金融アプリケーションシステムです。金融機関の窓口やATM、インターネットバンキングはもちろん、ネット通販の決済や仮想通貨取引など、あらゆるところで金融アプリケーションシステムが稼働して、金融を支えています。豊富な機能を備えたアプリケーションシステムですが、複数のシステムが複雑に入り組んだ構造であり、ひとつのアプリケーションシステムの小さな障害の発生が、社会全体に大きな影響を与えてしまう大規模障害に至ることもある高い信頼性が求められるミッションクリティカルなシステムです。
こうした高い信頼性が要求されるシステムは、設計、開発段階からの品質の作りこみが重要な課題です。私のミッションは、長年の大規模金融ITシステムの開発の経験と知見を活かして、高品質で信頼性の高い金融アプリケーションシステムの開発を推進することです。

大学では電子通信工学を専攻しましたが、卒業時は不況の真っただ中で希望していた電気通信関係への就職を諦めて、これからは「金融」と確信して証券会社に就職しました。証券会社では金融知識を習得し、証券業務システムの開発をはじめ投資理論に基づいた株式ポートフォリオ管理システムや派生証券のプライシング、裁定取引などの証券アプリケーションシステムの開発を担当しました。しかし、バブル経済の崩壊で勤めていた証券会社が経営破綻してしまい、思い切って外資系コンピーター会社に転職しました。転職先では政府系金融機関の情報システムの開発や同金機関の民営化システム開発のプロジェクトマネージャーを担当しました。その後、大規模システム開発の経験を生かして複数の生命保険会社のシステム開発のPMO等を担当するなどしたのちにエクサに入社しました。エクサでは生命保険会社、カード会社のシステム開発の品質管理やPMOを担当してきています。

金融アプリケーションシステム

図1 銀行システムの全体イメージ

図1 銀行システムの全体イメージ

金融アプリケーションシステムでまず思い浮かべるのは、最も身近な金融機関である銀行のシステムだと思います。銀行は金融システムを担う重要な金融機関のひとつです。
銀行では、預金、融資、為替各業務の勘定系と統合ATMや銀行間決済、クレジットカード決済、海外決済などの他の銀行や金融機関のシステムとの接続を担う対外接続系、さらに経営管理や営業支援、リスク管理等を行う情報系、営業店や事務センターの業務を担う周辺系などのシステムからなる大規模なITシステムが運営されています。全て重要なシステムですが、特に勘定系は銀行業務の生命線であり、高い性能と信頼性が要求されるミッションクリティカルなシステムです。

高品質システムは品質目標の設定から

保険、証券、クレジット等それぞれの金融機関は、各業態の特徴を取り込んで、様々なアプリケーションシステムを構築して運用していますが、いずれも高い性能と信頼性が要求されるシステムであり、システム開発の過程から、品質を作り込んでゆくという考え方が求められます。しかし、品質を作り込むには、やみくもにテストケースを増やせば良いというわけではなく、まず、開発するアプリケーションシステムの品質目標を定めて設計、製造、テストの各段階毎で、その目標が達成できていることを確認してゆくことが必要です。そして、開発プロジェクトの品質管理の仕組みとその着実な実践があって初めて、高品質のアプリケーションシステムの開発が可能になります。
何かを始める時、まずゴールとなる「目標」の設定をします。 明確なゴールがあって初めてそこに至る道を描くことができます。ソフトウェアの品質の目標設定の観点として役立つのが、国際規格SQuaRE(Systems and software Quality Requirements and Evaluation)シリーズのソフトウェア製品品質モデルです。この品質モデルに準じて開発するアプリケーションシステムの品質目標を定めるのが、高品質システムの開発の第一歩になります。
図2 ソフトウェア品質特性図

図2 ソフトウェア品質特性図
出典:「JIS X 25010:2013 (ISO/IEC 25010:2011) システム及びソフトウェア製品の品質要求 評価(SQuaRE)ーシステム及びソフトウェア品質モデル」3.3項 製品品質モデル, 図4-製品品質モデル

次に設計書等にこれらの品質特性毎の目標を設定します。どの品質特性の目標をどの設計書に設定するかはプロジェクトの規模や特性、進め方などによって異なりますが、のちのテストで、これらの品質特性が設定した目標通りに実装されていることを確認しますので、基本的にすべての品質特性の目標をいずれかの設計書に設定することが必要です。各設計書のレビュー等でこれらの品質目標が設定されていることを確認することも重要です。
次に設定した品質が、目標通りに実装されていることをテストで確認します。各品質特性の実装をどのテストで確認するかを予めテスト計画に盛り込んで、テストケースを作成することで、品質目標の確認漏れを防ぎます。実際のテストで設計書に設定した品質目標が確実に実装できているを確認しますが、その通りになっていないことを検知した場合は「欠陥」として管理して、修正除去します。この「欠陥」の摘出数と質が、それまで作り込んできた品質評価の目安となるので、メトクスとして監視してゆきます。 計測したメトクスをIPA(独立行政法人 情報処理推進機構)が発行している「ソフトウェア開発データ白書」等のベンチマークと比較して、大きな差があれば、その理由を調べてゆくことで、設計製造で作り込んできた品質の問題点を是正するためのヒントを得ることができます。
表3 欠陥の管理基準の例

表3 欠陥の管理基準の例

コミュニケーションツールとしての品質分析

コミュニケーションは「PMBOK」のプロジェクト管理の知識体系の一つですが、プロダクト品質の最も重要な要素のひとつでもあります。ソフトウェア開発は知識集約的なものですが、開発コストの大半が人件費であり労働集約的なものでもあります。開発者、デザイナー、アーキテクト、マネージャー、コンサルタントなどの多種多様な役割を持ったステークホルダーによる共同作成物がソフトウェアなのです。したがって、品質を作り込んでゆく過程においてステークホルダー間のコミュニケーションが重要な要素のひとつになります。上意下達のコミュニケーションの仕組みはしっかりとしているが、下意上達の仕組みが貧弱で、機能の実装を担当する開発者の意見や課題が、プロジェクトマネージャーや品質管理担当者へ迅速に伝わらず、後工程になって品質問題が顕在化する例はよくある話です。
こうした問題の解決手段の一つとして品質状況をステークホルダー間で共有するツールを提供することが挙げられます。例えば、テストで摘出した欠陥の数や質から、品質問題が発生していないか、発生しているとすれば、どんな対策を講じればよいのか等、ステークホルダー間で品質に対する客観的な状況認識があることで効果的で有効なコミュニケーションが可能になります。特に設計目標の品質がそのとおりに実装されているかを確認してゆくテスト段階では、摘出欠陥の質や量を客観的な品質分析資料としてステークホルダー間で共有することが重要です。システム統合テストにおいては、ステークホルダーの人数も多いので、意思決定のためのコミュニケーションツールとしての品質分析資料の役割は重要なものになります。
図3 業務要素別の検証と欠陥摘出状況の例

図3 業務要素別の検証と欠陥摘出状況の例
テストシナリオに紐づいた業務要素毎の検証ポイント数と摘出欠陥数を対比して視覚化することで、検証密度の低い業務や弱点のありそうな業務を見つけることができる

図4 P-B曲線の例

図4 P-B曲線の例
テストの進捗状況を検証予定と検証実績、障害摘出と欠陥除去の状況を 時系列的にとらえることで、システムの信頼度の成長を推計できる

コミュニケーションツールとしての品質分析資料は、問題点をわかりやすく表現する必要があります。数字だけの表ではなくグラフ化して視覚的に問題点をとらえやすくすることで、ステークホルダー間のコミュニケーションの効率化が図れるばかりでなく、数字だけでは見えなかった問題が可視化される場合もあります。
最もよく使われる品質分析グラフの一つに、テスト消化件数と摘出欠陥数をグラフ化したもので信頼度成長曲線あるいはPB曲線と言われるものがあります。これは、テスト項目の検証の予定に対する実績と、障害摘出と欠陥除去の状況を時系列的にとらえることで、テストの対象となっているシステムの信頼度の成長とともに把握することを目的としたもので、テストによってソフトウェアに潜在している欠陥が除去されて行く様子が、視覚的に容易にとらえられるように工夫されています。 (図 PB曲線の例)
また、システム統合テストで行うシナリオテストでは、テストシナリオを構成する業務要素ごとの検証ポイント数と摘出欠陥をグラフ化することで、検証密度の低い業務や弱点のありそうな業務を見つけることができます。(図 業務要素別の検証と欠陥摘出状況の例)

「共創」の時代のアプリケーションシステム開発

自社だけでは、高い競争力を確保することが難しくなってきている中で、様々なステークホルダーとのコミュニケーションのなかから、新しいサービスや価値を創造して行く「共創」の考え方が、金融アプリケーションシステムの開発においても展開されてきています。ユーザーだけではなく、ビジネス、テクノロジー、システム開発などの各分野のステークホルダーとのコミュニケーションを通して、競争力のあるシステム要件や差別化を図れるUIをデザインしてゆきます。従来のウォーターフォール型の開発流れでは、ステークホルダーが、実際に動くシステムを見ながらコミュニケーションできるのは、開発工程の後半以降であり、要件の検討やUIデザインを見直すとなると、大きな手戻りが発生してしまいます。プロトタイピングなどの手法はありますが、適用範囲が限定的なので、「共創」にはアジャイル型の開発が適しています。しかし、アジャイル開発は、Webサイトや携帯アプリケーションなどの「SoE」(System of Engagement)領域の中小規模のシステム開発向けで、金融アプリケーションの本丸である勘定系システムなどの「SoR」(System of Record)の領域の大規模システムの開発への適用は、難しいとされてきました。

図5 ハイブリッドアジャイル開発のイメージ

図5 ハイブリッドアジャイル開発のイメージ

そこで最近は、要件定義とシステム間統合テスト以降をウォーターフォール型として、設計~開発~結合テストをアジャイル型にする、互いの良いころを組み合わせたハイブリッド型のアジャイル開発によって、「SoR」の領域を含めた「共創」型の大規模アプリケーション開発が増えてきています。
まず、競争力のあるサービスのための業務やシステムの要件を多くのステークホルダーのコミュニケーションで「共創」し、その結果を実装するストーリーポイントとして整理します。次にそれらを効果の大きい、重要度の高いものから「スプリント」として計画化して、「設計~開発~結合テスト」のイテレーションを繰り返します。イテレーション毎のスプリントレビューでステークホルダーからのフィードバックや協力を引き出して、プロダクトバックログの追加や削除、順番の入れ替え等を行って、プロジェクトの期間やコストの制約の下でプロダクトの価値の最大化を図ります。そして最終的にシステム間統合テストで非機能要件やシステム間の不整合、業務サイクルでの不具合を除去してシステム全体をリリースするというものです。

図6 バーンダウンチャートの例

図6 バーンダウンチャートの例

品質管理の基本的な考え方はアジャイル開発でも変わることはありませんが、開発スタイルがウォーターフォール型と異なり、開発途中でプロダクトバックログの追加や削除があるため、テスト密度やバグ密度などのウォーターフォール開発の統計的な品質指標の適用が難しいことがあります。イテレーション毎の要求としての「ストーリーポイント」の「受け入れ基準の充足度」等の機能適合性の確認は基本ですが、ウォーターフォール型のプロダクトに対する統計的な品質指標の代わりに、開発チームの成熟度や生産性を品質指標の代替特性として利用する考えがあります。「水準の高い管理」のもとで「技術力のあるメンバー」が、イテレーションを繰り返す中で「学習し成熟するチーム」は、プロダクト品質も高いはずという理屈です。

図7 ベロシティーチャートの例

図7 ベロシティーチャートの例

代替特性としてよく用いられるものに、バーンダウンチャートやベロシティーがあります。 スプリントバーンダウンチャートは、縦軸に「作業量」、横軸に「時間」をとり、一つのスプリントにおける残りの作業量をグラフ化したものです。一見EVMチャートをひっくり返しただけに思われますが、アジャイル開発ではウォーターフォール型開発のWBSにあたるスプリントバックログの追加や変更、削除が前提なのなので、予実管理もその観点を考慮する必要があります。イテレーションの繰り返しの中で計画の精度や開発実行能力に関するチームの成熟度の状況を見ることも大切です。
ベロシティーは、各スプリントで完了する作業量の予実を実装する要件や機能の数であるストーリーポイント数で表したものです。計画時は、全体のストーリーポイント数をチームの開発チームの平均ベロシティーで除して完成に必要なイテレーション数を導出する参考になります。イテレーションの繰り返しの中でベロシティーの予実比較や安定度を見ることで、開発チームの開発実行能力に関するチームの成熟度を確認することもできます。
しかし、バーンダウンチャートもベロシティーもプロダクト品質の代替特性であることに注意しなくてはなりません。

品質に対する洞察力

ウォーターフォール型の開発でもアジャイル開発でも、コミュニケーションツールとしての品質分析資料を見る上で注意しなくてはならないのは、グラフ化などで、一見わかりやすく表現された事象や状況の本質や真偽を見極めることです。グラフは数値を表しているだけであり、その内容は表していません。また、設計時に設定した品質目標がテスト項目として正しく設定されていなければ、多くのテストが実施されていても品質目標の実装は確認できません。さらに、検知した欠陥が、どの品質目標に対する欠陥なのかによっては、欠陥の重みが異なります。場合によっては、ステークホルダーからの厳しい指摘を回避するような数字のトリックがあるかもしれません。こうした数字の裏にある本質や真偽を見極めるためには、設計時の品質目標とテストケースとの整合性、摘出した欠陥の内容と質などを確認する必要があります。テストケース数やバグの数だけでは品質は読めないのです。
しかし、限られた時間の中で全ての設計書とテストケース、摘出欠陥の内容などを確認するのは現実的ではありません。特にアジャイル開発では、代替特性でプロダクト品質を推計しなくてはならないので、開発チームごとの特徴や癖、さらには、リーダーのマインドセットといったことを日常のプロジェクト活動のいろいろなコミュニケーションの中で把握してゆく必要があります。
品質管理というと開発チームからは敬遠されがちなところがありますが、悪いところを単に指摘するだけでなく、開発チームに寄り添って品質を改善してゆく姿勢が大切だと思っています。

プライベート

以前は海関係の趣味が多かったのですが、最近は山歩き、水泳、お酒といったところです。山歩きは、のんびり歩ける尾瀬や上高地のほか、地元の丹沢山系やちょっと足を延ばして秩父連山や八ヶ岳連峰を中心に山歩きを楽しんでいます。水泳を本格的に始めたのは数年前。ジムのインストラクターの勧めで参加したフィットネスクラブのマスターズ水泳競技会で、たまたま上位に入ったのに気をよくしてから毎週末にジムで泳ぎ込んでいます。お酒は、旅行でゆく先々で、その地のお酒を楽しんでいます。日本各地の日本酒はもちろんですが、海外旅行でのビールやワイン、ウィスキーなどその地の思い出に幅が広がります。最近は、なかなか旅行に行きづらいので、チリ産やイタリア産などの手ごろなワインで彼の地に思いを馳せています。

後藤賢治 プライベートの画像

執筆者紹介

お問い合わせ

CONTACT

Webからのお問い合わせ
エクサの最新情報と
セミナー案内を
お届けします
ソリューション・サービスに関する
お電話でのお問い合わせ

平日9:00~17:00※弊社休業日を除く