金融系プロジェクトで成功をおさめる重要な鍵（2/3）

【第2話】実例！決済系プロジェクトでのリスク管理手法

ペイメント

前回の第1話は、金融機関の情報システムの現状と、その金融情報システムの開発プロジェクトにおいてエクサが考えるプロジェクト管理についてご紹介しました。
今回の第2話では、エクサが担当した新決済スキーム導入プロジェクトを実例に、プロジェクト推進上における課題の洗い出し方法についてご紹介いたします。

3.新決済スキーム導入の背景

近年、クレジットカードを取り扱う加盟店において、不正アクセスによるクレジットカード番号等のカード情報の漏えいや磁気カードのスキミングによって偽造したカードの不正利用が増加傾向にあります。それに伴い、安心安全なクレジットカード決済を提供する環境構築のため、クレジットカードにおけるセキュリティ面の強化として、経済産業省が定める割賦販売法の一部改正の法律（以降、改正割賦販売法）を定めました。

この改正割賦販売法で定める加盟店におけるセキュリティ対策の義務化に伴い、①カード情報の漏えい対策：「クレジットカード情報の非保持化^※1」もしくは「PCIDSS準拠^※2」、②偽造カードによる不正利用対策：ICカード（EMV仕様^※3）対応の読取端末の設置を実施する必要が生じました。

※１：クレジットカード情報の非保持化
自社で保有する機器・ネットワークにクレジットカード情報を保存、処理、通過させないこと
※2：PCIDSS
加盟店・決済代行事業者が取り扱うカード会員のクレジットカード情報・取引情報を安全に守るために、JCB、アメリカンエキスプレス、Discover、マスターカード、VISAの国際ペイメントブランド5社が共同で策定したクレジット業界におけるグローバルセキュリティ基準
※3：EMV仕様
1990年代に深刻化した磁気カード不正を受けてEuropay、MasterCard、Visaの3ブランドで制定した決済用ICカードの仕様

4.グループ企業X社の課題

改正割賦販売法で定める加盟店におけるセキュリティ対策を実施するにあたり、グループ企業X社が発行するクレジットカード加盟店において、下図１に示す課題（下記①、②）への対応が必要となりました。

図1：グループ企業X社の課題

上記課題を解決するために、A社のPOS機能強化、B社の決済端末の導入、およびASPサービスや決済機能（電子マネー・QRコード決済など）の活用、C社のIC認証機能の導入、D社のカード番号のトークン化機能と関連システムへの連携機能強化など、複数社のシステムベンダと手を組みシステムを連携することにより実現する新決済スキームを導入することとなりました。（図2）。

図2：新決済スキーム（概要図）

5.プロジェクトで潜在していたリスクと課題

このように新決済スキームは複数システムの連携が必要となりましたが、グループ企業間で汎用的に利用することも求められていました（図3）。そのため、この新決済スキーム導入プロジェクトは、複数のクレジットカード加盟店と複数ベンダが関連するグループ全体のプロジェクトとして位置付けられていました。そうした中で、グループ全体に跨る横断的なプロジェクトであることから、プロジェクトの立ち上げ当初から多種多様なリスクが潜在していることが予想されていました。

そこで、プロジェクト全体を推進するにあたり、どのようなリスク対策を講じたかについてご紹介していきます。

図3：新決済スキーム導入関連システム

5-1.リスク定義をもとにしたリスクの洗い出し

当プロジェクトを統括するグループ企業のシステム部門では、プロジェクトを推進するためのリスク管理の標準および手順が必要となりました。そのため、当プロジェクトを開始するにあたり、エクサが独自に定義したリスク定義をもとにリスクの洗い出しを実施することとしました。

リスクは事前対策が重要なため、プロジェクト開始時に「リスク管理計画」と定義し、リスク特定、リスク優先度評価、リスク対応策の策定を実施しました。また、リスク管理計画の内容はリスク管理表に記載し、プロジェクト推進時に、リスク対応策の実行・モニタリングを実施することとしました（図4）。

図4：リスク管理の全体像

それでは、「リスク管理計画」をどのような手順で策定したかをご説明いたします。リスク管理計画は、プロジェクト特性をインプットとし、①「リスク特定」、②「リスク優先度評価」、③「リスク対応策（アクションプラン）策定」の3つのステップに分けて整理し、その結果をリスク管理表に記載します。（図5）。

図5：リスク管理計画

①「リスク特定」ステップでは、特定したリスクがどのカテゴリのリスクかを把握しやすくなるように、PMBOK（Project Management Body of Knowledge）が提唱する10の知識エリア（総合、スコープ、スケジュール、コスト、品質、組織、コミュニケーション、リスク、調達、ステークホルダ）にリスク要因を分類します。

②「リスク優先度評価」ステップでは、リスクを顕在化する「発生可能性」および顕在化した場合の「影響度」の2軸で評価し、両者のレベルの積をリスクサイズとして定義します（図6）。

図6：リスクサイズ定義

このリスクサイズをリスクマトリクスに照らして、「高」、「中」、「低」の3段階のリスク優先度に分類し、リスク優先度評価を行います。このリスク優先度評価を行うことにより、各リスクのリスク対策の重要度を明確になり、リスクの対応優先度を把握するが可能となります。（図7）。

図7：リスク優先度

③「リスク対応策（アクションプラン）策定」ステップでは、下記に示す通りリスク優先度別に対応方針を定義し、リスク優先度に応じてリスク対応策（軽減策・回避策）を策定していきます。

※リスク優先度別のリスク対応方針
リスク優先度「H」（High）：予防策と発生時対策を立て、監視を行なう
リスク優先度「M」（Middle）：発生時対策を立て、監視を行なう
リスク優先度「L」（Low）：特に対応策を立てずに、監視を続ける

プロジェクトでは、プロジェクト立ち上げ時に上記のリスク管理計画（リスク特定・リスク優先度評価・リスク対応策）を策定し、それに基づく実行・モニタリングに分けたリスク管理プロセスを定めてプロジェクトを推進することとしました。（図8）。

図8：リスク管理プロセス

プロジェクト全体を統括するプロジェクト事務局のみでプロジェクト全体のリスク管理計画（リスク特定・リスク優先度評価・リスク対応策（軽減策・回避策））を策定するのではなく、各システムベンダも同様にリスク管理計画を策定し、それをプロジェクト事務局が取り纏めることによって、関連各社間で共有したリスク管理を行うことができました。
また、リスクサイズとして数値化すること、リスク優先度別に対応方針を定義することによって、優先して実施すべきリスク対応策（軽減策・回避策）が明確になり、これも関連各社間で共有することによってプロジェクト全体の横断的なリスクの把握、および事前に対応策（軽減策・回避策）を策定および実施をすることができました。

5-2.プロジェクトのリスクと課題整理

このような手順で「リスク管理計画」を策定したなかで、前記したリスク定義をもとにリスク優先度「H」と分類した複数のリスク要因の中から、3つの大きなリスクとそのリスクから派生する課題について下記に示します。

【リスク①】
プロジェクトのステークホルダが多い中でプロジェクト統制役が不在である

【リスク②】
当プロジェクトを統括するシステム部門内で関連企業の担当システム別に対応すべき要件が整理されていない

【リスク③】
各グループ加盟店の要件検討や開発の進捗具合によってプロジェクト全体のマスタースケジュールや要件の変更等の外的要因による変動性リスクが高い

これは、当プロジェクトが、グループ内で汎用的に利用可能な新決済スキームを導入することから、グループ全体に跨る横断的なプロジェクトとなり、複数のステークホルダ（グループ加盟店やベンダ）の管理や業務要件／システム要件の整理が必要となるためでした。
このため、プロジェクトを統括するシステム部門内で要件を定義づけしたテーマ単位に分類できず、各要件の対応開始と対応期限が不明確なことから、プロジェクト全体のマスタースケジュールが組めない状況でありました。

このような状況下において、当プロジェクトでは、下記①、②、③がプロジェクトの大きな課題となりました。

【課題①】複数のステークホルダを統制する管理方法

【課題②】システム要件の分類とマスタースケジュール作成

【課題③】マスタースケジュールやプロジェクト費用の柔軟な変更／調整

次回第3話では、その課題に対する対策方法と効果について詳しく触れていきたいと思います。