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

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

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

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

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

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

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