市場系システム選定のポイント 後編

市場系システム選定のポイント 後編

市場系システムの選定をどのように進めるか、悩む担当者の方も多いのではないでしょうか。本稿ではシステム要件以外の観点から選定のポイントについて解説していきます。

実績に関する確認ポイント

カタログ上の機能が優れていても、実際のシステムが自社で利用できるかどうかは気になるところです。他のユーザの導入実績に関する情報を集めておけば、選定の際の安心材料の1つになります。

  • どれくらいの会社が導入しているか?

導入社数は最も分かりやすいため、最初に確認しておきたい指標です。導入社数が多いほどユーザからのニーズがパッケージ機能に織り込み済であったり、バグも少なかったりとシステム品質も安定している傾向があります。ベンダとしてのプロジェクト経験も多いため、プロジェクトにおける課題解決のノウハウも蓄積されていると考えられます。一方で導入社数が少ない場合でも採用数が伸びているのであれば、今後のパッケージの成長に期待が持てます。また1社あたりのサポートも手厚くなるため、要望機能をパッケージに組み込みやすいというメリットもあります。単純に導入社数の多い少ないだけでは判断は出来ません。

次に業態別の導入社数も合わせて確認しておきましょう。前編の記事でパッケージは歴史的な背景からセルサイドやバイサイド等特定業種に特化している場合があることを挙げました。全体導入社数が多いパッケージでも自社と同業態での実績が少ない場合、ユーザの求める業務機能とパッケージ機能とのギャップ部分が大きいことがあります。業界同士のつながり等あれば、他社にパッケージの使い勝手等ヒアリングをしてみるのも手です。

  • 類似のプロジェクト実績はあるか?

実績を確認する際には、過去どのようなプロジェクトを行ってきたか確認できるとよいでしょう。特に類似のプロジェクト実績があるかどうかは大きなポイントです。ベンダにとっては過去のプロジェクトにおける知見や開発済のプログラムを活用することが出来るため、実績をベースにパッケージのマスタ設定やカスタマイズ内容を定義していくことが出来ます。これによりユーザ側とベンダ側のコミュニケーションをスムーズに行うことが出来ます。

既存システムのリプレースの場合は新システムへのデータ移行が必要となります。例えば、取引先情報でもシステムによって保持している項目・タイトル・並び順等が異なるため、移行データの変換(データマッピング)が必要です。移行元のベンダも巻き込んでこの作業を1から行うのか、過去の実績を活かすかでユーザとベンダにかかる負担は変わることは明らかです。

データ連携に関することについても同様です。特定の基幹系システムや情報系システム(例:ALMシステム)とのデータ連携要件がある場合、通常は連携するデータの項目、レイアウト、ファイル入出力方式等を定義していく必要があります。過去のプロジェクトで対象システムとの連携実績があれば、過去の実績をベースに開発を行っていくことが出来るため、設計・開発に関する負担やプロジェクト期間およびコストを抑えられるメリットがあります。

  • どのくらいの期間サービス提供を続けているか?

パッケージの初期開発から現在に至るまでどれくらいの期間サービス提供を続けているでしょうか。システム本番稼働後にパッケージベンダがサービスを提供し続けていくためには、金融及びITスキルに長けた人材を確保しながらサポート体制を維持していく必要があります。特に市場取引の分野は慣行や規制の変化も激しいため、パッケージ機能の維持管理やアップデートも継続して行っていく必要があります。

実際のところ、利用ユーザの減少やシステム要員の確保が難しいこと等からここ数年でサポート停止に至ったパッケージもあるのも事実です。システム導入する場合、問題なく運用出来れば5年以上は同じシステムを利用することとなります。長期的な利用を見据えて、過去のサービス提供実績を確認しておくことは重要と言えるでしょう。

スケジュール・体制面に関する確認ポイント

システムの導入プロジェクトから本番稼働後の運用はユーザとベンダの協力がなければ成しえません。信頼できるパートナーとしてベンダ側のプロジェクト体制が整っているか検証していきます。

  • 実現可能なスケジュールとなっているか?

スケジュールに関しては現行システムの保守期限や新規ビジネスの開始タイミング等、まずユーザとしてシステム利用希望時期を提示することが多いと思われます。ベンダはその内容を受けて対応可能なプロジェクトスケジュールを回答しますが、この時提出されたスケジュールがユーザにとって許容出来る内容になっているかの検証が必要です。

例えば、要件定義や基本設計等プロジェクトの上流工程では機能要件・非機能要件含め様々な観点で打ち合わせが行われます。打ち合わせの内容、頻度、1回あたりの所要時間、準備作業のボリューム、成果物のレビューに関すること等ユーザとしての負担感を把握しておきましょう。これらを踏まえユーザにとって厳しいスケジュールになっていないか確認をします。

ユーザ受け入れ試験(UAT)フェーズでは、実際の業務に即した形でシステムの動作検証を行っていきます。システムを本番稼働させても良いか判断するためにユーザにとって最も重要かつ負担のかかる作業と言えます。システム要件が複雑になればなるほど検証しなければいけないテストパターンも増えますので、UAT作業期間がきちんと確保されているかは確認しておきたいポイントです。

システム導入を短期間で出来るほうが良いと考えてしまうかもしれませんが、ユーザに過度な負担を強いるようなスケジュールを敢行した場合、プロジェクトが破綻してしまうリスクもあります。システム導入はユーザにとって現行業務と並行作業となることが多いです。期末の決算処理等の事務とシステム導入に関する成果物レビューやUAT等の負担のかかる作業が可能な限り重ならないようにスケジュールを組むことをお勧めいたします。

  • 導入プロジェクトにおける体制は整備されているか?

プロジェクトを円滑に推進する体制が整備されているでしょうか。プロジェクトマネージャ、アプリケーション担当、インフラ担当品質管理担当等、役割に応じた要員が適切な人数でアサインされるでしょうか。また市場系システムは一般的なシステムとは異なり、導入にあたってITスキルはもちろん高度な業務知識が要求されます。ユーザとのコミュニケーションを円滑に進めていくためには実際の業務経験あるいはユーザ業務を理解できる人材がアサインされることが望ましいと言えます。特に時価評価などの計算モデルにするやりとりもあるため、数理統計に強いクオンツエンジニアが体制に組み込まれているかは重要です。

市場系システムはその業務の複雑性から、時に現場サイドで解決できない問題が発生することも多々あります。その際に両社のマネジメントレベルにて進捗・課題等の対応状況を確認、意思決定を実施する会議体(ステアリングコミッティ)を整備されていることが望ましいと言えます。

  • 保守フェーズにおける体制とサービスレベルはどうなっているか?

システムの本番稼働後の保守体制についてもいくつか確認しておきます。問い合わせ先については、共通のコールセンターとなるか、専任の担当者がアサインされるかの大きく2つのパターンがあります。担当者制の場合でも導入プロジェクトの担当者がそのまま保守業務を引き継ぐこともあれば、運用開始後に専門のサポート部門が対応にあたることもあります。

サービスレベル感もベンダによってばらつきがあることが多いです。問い合わせ時間については、受付可能時間と対応時間、夜間・休日の受付の有無を整理しておきます。また基本的な問い合わせ方法や不具合発生時の対応フローや復旧までの想定時間なども確認しておきましょう。ベンダによってはオプションサービスとして、定期的なパッケージのメンテナンス、OSの修正パッチの適用、カレンダーメンテナンス、監査対応等のメニューを用意している場合があります。自社のニーズにどこまで対応できるか聞いておきましょう。

コスト面に関する確認ポイント

コストは数字として明確に評価が出来ますので、意思決定の際の指標として最も分かりやすいものと言えるでしょう。単に高い・安いという判断ではなく、要求するものに対して正しくコストが算出できているかが大事になってきます。

  • パッケージライセンスの考え方はどうなっているか?

一般的な市場系システムのパッケージ製品では利用にあたってライセンス費用が発生することが多くなっています。費用発生のタイミングがいつか、一時費用で終わるのか、月単位・年単位での継続費用なのか等様々なパターンがあります。また海外製のパッケージによくあるケースとして、システムのバージョンアップ時にバージョンアップライセンスを追加で請求されることもあるため注意が必要です。

ライセンス費用の積算方法もベンダによって様々です。どういった仕組みで計算されるか事前に確認しておくことがよいでしょう。ユーザ数だけ見ても、クライアント端末数、システム上の登録ユーザ数、同時アクセス数といったようにパッケージにより考え方異なります。また導入対象の金融商品やそのトランザクション件数、特定の業務機能のありなしで変動する場合もあります。最近ではシステムを複数の組織(例:部門・会社)で共同利用するようなケースもありますので、利用目的に応じたライセンス体系が用意されているか確認しておきましょう。

  • 提示した要件に対して、作業内容が正しく見積されているか?

システムの導入において、一番大きな割合を占めるのがベンダによる作業費用(人件費)となります。前編で解説した業務要件・非機能要件の観点から、作業費用に何が含まれていて、何が含まれていないのか検証が必要となります。見積依頼は複数社にお願いするケースが多いかと思いますが、横並びで比較した時に極端にコストが低い場合は、必要な機能が盛り込まれていないことが考えられます。システム導入の目的が達成できるのかという観点で見積内容を検証する方が良いでしょう。

さて、システム検討時には要件定義・設計・開発・テスト・本番移行・稼働後のランニングコストの総額で予算申請をするケースが多いかと思います。要件定義の内容次第で全体コスト感は変わるとは言っても、予算取得時から大きく上振れすることは簡単には許容されないでしょう。パッケージ機能の範囲であればベンダへ誤った要件を伝えていない限り変動要素は少ないかと思われますが、他システム連携等のカスタマイズ機能の見積についてはベンダ側の想定に基づく見積となっている場合があります。そのため、プロジェクト開始後の要件定義の結果、開発規模が当初想定よりも膨らんでしまいコストが上振れしてしまうことも考えられます。こうしたコストの上振れを減らすためには、システム検討時から要求仕様を明確化した上でベンダへ見積依頼をかけるのが望ましいと言えます。例えば他システム連携の場合であれば「連携先システム、連携目的」といった基本的な情報だけなく、「項目名、項目数、ファイル数、連携方法」等の粒度のレベルで開示できると見積の精度は高めることが出来るでしょう。

  • システム導入ベンダ以外に発生するコストを把握できているか?

市場系システムのパッケージ導入においては、アプリケーション本体の導入以外に様々なコストが発生します。代表的なものが有価証券の時価、金利、為替、オプションのボラティリティ等を含むマーケット情報です。市場系システムにとってマーケット情報は必須要件の1つであり、当該情報をシステムで利用するためには情報ベンダへのライセンスフィーが発生することがほとんどです。システム上の管理対象商品、通貨、年限等、業務要件と密接に絡んでくるため、追加コストが発生するかどうか事前に確認をしておくことが必要です。

その他システム連携のカスタマイズ機能が要件に含まれる場合、連携対象のシステム側の開発・テスト費用を見積しておく必要があります。データ移行に関しては、現行システムからのリプレースの場合ユーザにて移行データの抽出が困難な場合、現行システムのベンダによる作業支援コストを見ておく必要があります。システム基盤について、システム稼働に必要なハードウェア・ソフトウェア・ネットワークの構築、手配を自社で行う場合それらに関するコストも個別に見積しなくてはなりません。ベンダによっては一部が見積に含まれていることもあるので、自社とベンダでの手配範囲を明確にしておきましょう。

まとめ:選定の軸をしっかり決める

本稿では実績、体制、コスト等のシステム要件以外の選定ポイントについて解説させていただきました。システム要件に関するポイントについては、以下の記事でご紹介しておりますのでそちらもご参照ください。

市場系システム選定のポイント 前編

今回ご紹介したポイントは一例に過ぎません。パッケージシステムは国内製品・海外製品様々あり、機能レベルやサービス内容、コスト構造にそれぞれ特徴を持っています。システム選定の判断に迷った場合は、自社におけるシステム導入の目的が何か、基本に立ち返りましょう。その上で選定における軸を定めて、目的にあったシステムを選定していきましょう。

弊社パッケージ「Prélude Enterprise(プレリュード エンタープライズ)」のシステム構築事例、実績等については以下に資料をまとめておりますので、フォームに必要事項を記入の上ダウンロードいただけます。

金融市場系システム Prélude Enterpriseのご紹介


参考:市場系パッケージ選定のための知識と実務(2016年9月28日 株式会社きんざい)