勘定系システム開発の発注/外注/依頼/委託方法について

勘定系システムの発注は、準備から検収まで段階を追って進めるのが基本です。銀行や信用金庫、保険会社では、勘定系システムが業務の中枢を担うため、どの段階も慎重に進める必要があります。

  • 準備:業務・技術・規制対応の要件の整理
  • 選定:RFIとRFPによる候補ベンダーの評価
  • 契約:範囲、SLA、リスク対応の明文化
  • 管理と検収:PMOとUATによる稼働条件の確認

金融規制、ベンダーリスク、SLAは、どの段階でも外せない論点です。

▼全体ガイドの記事
・勘定系システム開発の完全ガイド

発注前の準備と要件整理

現行業務、現行システム、刷新後の目標、システムリスク管理を整理する4つのカード図。
現状の把握から刷新後の目標まで、要件整理の対象が並びます。

勘定系システムの発注で最も重要なのは、発注前の準備です。業務・技術・規制対応の要件が曖昧なまま発注を進めると、後から仕様変更が重なり、コストも超過しやすくなります。

現行業務の整理と課題の明確化

まず、現行業務のフローと現行システムの機能、課題を整理します。現状の問題を把握しておかないと、刷新で何を解決すべきかがぼやけてしまいます。技術的負債や保守コスト、性能の問題、規制対応の難しさも、ここで確認しておきます。

刷新後に実現したいことも、はっきりさせておきます。その中身は、処理能力の向上とコスト削減、新商品への対応とクラウド化です。仕様書がないブラックボックス化の部分には、調査・分析フェーズを設けて対応します。

金融庁・日本銀行などが求めるシステムリスク管理、BCP、情報セキュリティの要件も整理します。

RFP(提案依頼書)の作成

要件整理の結果をもとに、詳細なRFPを作成します。記載内容は、いくつかに分けて整理すると進めやすくなります。さらに、技術要件には、セキュリティや移行方式に加えて、インターフェースも含めます。

ポイント

業務・技術・規制対応の要件を先に固めておくかどうかで、後の仕様変更やコスト超過の起きやすさが大きく変わります。迷ったときは、要件が曖昧なまま発注を進めていないかを見直すとよいです。

ベンダー選定と評価プロセス

ベンダー選定で確認する開発・移行実績、財務健全性、技術力、セキュリティ・コンプライアンス対応、プロジェクトマネジメント能力のチェックリスト。
各社の提案を比べる際に見る観点をそろえています。

ベンダー選定は、数十億円〜数百億円規模の大型投資を伴うため、慎重に進める必要があります。適切な選定の手順を踏むことで、長期的なパートナーシップを築ける最適なベンダーを選びやすくなります。

ベンダーショートリスト作成

まずはRFI(情報提供依頼)を広く発信し、10〜20社程度のベンダーから回答を集めます。次に、回答内容(実績・技術力・財務健全性・体制)をもとに、5〜7社程度に絞り込み、「ショートリスト」を作成します。

ショートリストの選定では、勘定系システムの開発・移行実績(同規模・同業種での実績)を重視します。財務健全性(大規模・長期プロジェクトを完遂できる財務基盤があるか)と技術力(モダナイゼーション・クラウド対応の能力)も、重要な評価項目です。このほか、セキュリティ・コンプライアンス対応の実績とプロジェクトマネジメント能力も、評価の対象です。

ショートリストが決まったら、各社とNDA(秘密保持契約)を締結します。そのうえで、より詳細な情報をRFPに反映し、詳細な提案を依頼します。

総合評価と最終選定

最終選定では、技術提案や体制、実績を総合的に評価し、価格やリスク評価も加えて判断します。評価の観点は、技術的妥当性(提案されたアーキテクチャ・移行方式の妥当性)、プロジェクト管理計画の具体性、体制の充実度(PM・アーキテクト・ドメインエキスパートの確保状況)などです。

既存ベンダーとの連携計画(マルチベンダー環境の調整能力)や、価格の透明性と根拠の明確さも確認します。また、提案内容を比べるだけでなく、候補ベンダーと深く対話(コンサルテーション)して、本プロジェクトへの理解度やコミットメントを見極めることが求められます。

最終的には、技術力と価格のバランスに加えて、長期的なパートナーシップを築けるかどうかという信頼関係も、選定の大切な基準になります。

ポイント

ベンダーは、実績や技術力、財務健全性で比べて候補を絞り、そのうえで提案内容を詳しく比べます。価格だけでなく、長期的に組める相手かどうかも判断の基準になります。

契約締結の注意点

勘定系システムの開発契約は、一般的なシステム開発契約より複雑で金額も大きくなります。そのため、契約内容を一つずつ精査することが欠かせません。

契約書に盛り込むべき重要事項

まず、勘定系システム開発の契約書には、必ず盛り込む事項として開発範囲を定めます。開発する機能、移行対象のデータ、接続先のシステムまで詳しく決めておくと、後から解釈がずれるのを防げます。マイルストーン対価では、各フェーズの完了条件と支払いタイミングを明確にします。

知的財産権では、ソースコードや設計書の権利を誰に帰属させるかを定めます。原則として、金融機関側に帰属させます。秘密保持では、顧客情報やシステム仕様などの機密情報の管理を規定します。

瑕疵担保責任・保証期間では、納品後の不具合対応の責任範囲と期間を明記します(金融系は2年以上が望ましい)。SLA(サービスレベル合意)では、可用性や応答時間、障害対応時間などの数値基準を定め、合意したSLAが未達の場合の対応はペナルティ条項で規定します。移行完了・撤退条件では、万が一プロジェクトが中断した場合の対応方針も、事前に定めておくことが大切です。

ベンダーリスク管理

金融機関には、金融庁の「金融機関のITガバナンスに関するガイダンス」に基づき、外部委託先(ベンダー)のリスク管理が求められています。そのなかでも重要なのは、再委託の範囲と承認です。ベンダーが下請けに再委託する場合は、事前の承認が必要になります。

ほかにも、ベンダーの財務健全性を継続的にモニタリングし、重要業務の委託先の集中リスクを管理します。また、ベンダーの障害に備えて、代替手段(コンティンジェンシープラン)を確保し、定期的な監査・視察も行います。

特に勘定系システムのような重要システムの委託先には、年次での現地監査、四半期ごとのリスク評価、インシデント報告体制の確立が必要です。

ポイント

契約書では、開発範囲や支払いタイミング、保証期間、SLAとペナルティを曖昧にせず書き込むことが肝心です。金融機関として必要な条項が抜けていないかも、契約前に確かめてください。

プロジェクト管理と受け入れ検収

本番稼働を中央に置き、正確性テスト、パフォーマンステスト、セキュリティテスト、BCP・DR訓練を注釈線で結んだ図。
稼働承認の前に複数の観点を確認する構成です。

勘定系システムの開発期間中は、金融機関側も積極的にプロジェクトへ関わることが成功の鍵になります。発注者と受注者という関係にとどまらず、共同でプロジェクトを進める「協働型」の関係が求められます。

開発期間中のプロジェクト管理

開発期間中は、経営レベルの進捗管理会議(ステアリングコミッティ)を週次か隔週で、現場レベルの進捗会議を日次か週次で開く2層構造で管理するのが一般的です。そのうえで、スケジュールとコストに加えて、品質とリスクの観点からも状況を定期的に評価し、課題やリスクには早い段階で対処します。

仕様変更管理(変更要求管理)は厳格に行います。変更内容と影響(コスト、スケジュール、品質)を評価し、変更委員会(CCB:Change Control Board)が承認する仕組みを設けておきます。

金融機関は、ベンダーとは独立したプロジェクト管理オフィス(PMO)を置き、プロジェクトの品質と進捗を監視することをおすすめします。

受け入れ検収とUAT(ユーザー受け入れテスト)

勘定系システムの受け入れ検収は、本番稼働に向けた最後の関門です。UAT(ユーザー受け入れテスト)では、業務担当者が実際の業務シナリオに沿ってシステムを操作し、要件どおりに動くかを確かめます。

金融系システムでは、次の観点のテストが特に欠かせず、正確性テストでは、金融計算、利息計算、為替計算が正確かを確認します。パフォーマンステストでは、ピーク時の取引量に耐えられるかを見ます。たとえば銀行では、月末や給与日に1秒間で数百〜数千件の処理が必要になる場合があります。

セキュリティテストでは、ペネトレーションテストと脆弱性診断を行います。BCP・DR訓練では、障害時にバックアップシステムへ切り替えられるかを確かめ、データ移行検証では、旧システムからの移行結果が正確かを見ます。これらすべてに合格してから本番稼働を承認する、厳格なゲート管理が必要です。

ポイント

開発期間中は、金融機関側が共同でプロジェクトを進める体制になっているかを、まず見ておきます。本番稼働の承認は、すべてのテストに合格してからにします。

まとめ

勘定系システム開発の発注を成功させるには、十分な準備と適切なベンダー選定が必要です。そのうえで、厳格な契約と協働型のプロジェクト管理も欠かせません。

発注前には、現行業務を整理し、詳細なRFPを作ったうえで、複数のベンダーから競争提案を集めて総合的に評価します。契約書には、開発範囲、SLA、ペナルティ条項を明記し、マイルストーンや知的財産権も定めます。

加えて、ベンダーリスク管理の仕組みも、金融機関には必要です。プロジェクト期間中は、金融機関側も積極的に関わり、PMOが独立した立場で品質と進捗を管理します。

受け入れ検収では、正確性と性能の検証を徹底し、セキュリティとBCPの観点も確かめます。すべての関門を通過してから本番稼働を承認する点が、とくに大切です。

▼全体ガイドの記事
・勘定系システム開発の完全ガイド

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール
張田谷凌央
張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。