定期預金システムの発注は、対象範囲を決め、要件と責任分担を整理し、契約と見積を比べて委託先を選ぶ順に進めます。この順に進めると、移行後の運用まで見通しを立てやすくなります。
▼全体ガイドの記事
・定期預金システム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
定期預金システムの発注・外注で最初に決めること
発注前に決めるべきなのは、作る機能の一覧よりも、今回のプロジェクトに含める範囲です。
既存の勘定系に商品・満期管理を接続する案件と、預金元帳を含む勘定系刷新とでは、期間、体制、金額、リスクが大きく異なります。
商品・金利・満期を管理する周辺システム
既存の勘定系や元帳は残したまま、商品・金利マスタ、受付画面、API、満期案内、事務画面を追加する形です。インターネットバンキングやアプリ向けAPIも対象に含まれます。
- 商品管理：商品・金利マスタと満期管理を新たに設ける
- 受付・接続：受付画面とアプリ向けAPIを整える
- 事務処理：満期案内と事務処理画面を用意する
元帳を新設しないぶん、新商品を早く提供したい場合やチャネルを増やしたい場合に適しています。
ただし、残高や取引結果の最終責任が既存勘定系と新システムのどちらにあるかは、明確にしておく必要があります。曖昧なままだと、二重計上や照合不一致が起きます。
預金元帳を含む勘定系刷新
預金元帳まで刷新する場合は、定期預金だけを対象にしても、実態は金融機関の基幹システムの更改です。
- 基幹機能：顧客情報、会計、決済、為替まで含める
- 日常運用：認証、監査、日次締めの運用まで定める
- 関連業務：振替、利息費用、税務帳票、AML/CFT連携の範囲を確かめる
安全対策の基準には、金融庁のサイバーセキュリティガイドラインと、FISC安全対策基準第13版があります。FISC第13版は2025年3月に公表されました（出典: 金融情報システムセンター「金融機関等コンピュータシステムの安全対策基準・解説書 第13版」、2025年）。
定期預金システムの発注形態の選び方
業務ルールが標準的で、短期の導入を優先するなら、パッケージ・サービス型が適しています。
独自の商品や複雑な接続がある場合は、個別開発型を選びます。
判断材料が不足している場合は、構想・PoCから段階を分けて発注する方法が適しています。
パッケージ・共同利用サービスを選ぶ場合
パッケージ型は、商品・金利マスタや預入、満期、自動継続などの標準機能を土台にする方式です。
- 標準機能：商品・金利、預入、満期、自動継続を使う
- 共同利用：金融機関向けのサービスやAPIを活用する
- 個別対応：標準との差分を設定や追加開発で補う
共同利用型やAPIサービスなら、全機能を単独で開発するより、初期費用や保守の負担を抑えられる可能性があります。
ただし、業務を標準機能に合わせられるかを確かめる必要があります。中途解約利率や帳票に追加費用がかからないかも、あわせて見ておきます。
NECは2025年3月、全国230を超える信用金庫が共同利用する勘定系の内部APIと連携する「NEC APIサービス for しんきん」を提供開始しました。
本体価格は税別200万円で、別途SI費用と月額保守料が必要です（出典: 日本電気株式会社プレスリリース、2025年3月28日）。
この200万円は、パッケージ本体と導入総額を分けて考えるための例です。定期預金システム全体の相場を示すものではありません。
個別開発・スクラッチを選ぶ場合
個別開発では、業務や既存システムの事情に合わせて設計できます。
- 接続先：勘定系、CIF、会計、チャネル、認証に合わせる
- 独自業務：頻繁な商品追加や、営業店・非対面の受付条件に対応する
- 既存技術：古いホストと新しいAPIを扱う
自由度が高い一方で、計算仕様と受入条件を発注側が決めないと、各社の見積の前提が変わります。そのため、金額だけでは比較できなくなります。
構想・PoC・本開発を分ける段階発注
要件が固まらない段階で、数千万円から億単位の本契約を結ぶことに不安がある場合は、工程を分けて発注します。
- 構想整理で現行商品と業務を棚卸しする
- 業務要件定義と接続検証を行う
- PoCの成果を踏まえて本開発を発注する
最初の契約では、現行商品を洗い出し、主要な計算ケース、データ連携方式、移行対象件数、概算WBSを整理します。
作業で得た結果を次のRFPに使えば、安価な提案でも移行やテストの抜けを見つけやすくなります。
RFPと要件整理で決めること
RFPは「何を作るか」だけでなく、提案と見積を同じ条件で比べるための文書です。
そのため、目的と現行業務、範囲をそろえて示します。非機能要件、移行条件、契約と見積の前提も示します。
発注側がすべての仕様を完成させておく必要はありません。
目的・対象範囲・責任境界の明文化
提案会社が範囲と費用を判断できるよう、対象と責任境界を明記します。
- 目的：商品提供の早期化や事務負担の軽減などを示す
- 対象：商品数、チャネル、取引量、利用者、外部接続を記す
- 責任境界：残高の正本、商品マスタの変更者、満期処理の失敗を検知・再処理する担当を決める
- 対象外：今回扱わない機能と次期計画を区別して示す
あわせて、稼働時間、目標稼働日、対象地域、既存システムを整理しておきます。
例として、受付APIと満期管理を対象にし、元帳刷新やAML/CFTエンジンの新設は次期計画とする場合があります。
対象外を明記しておくと、除外した範囲を含む追加要求を抑えやすくなります。
金利・利息・満期・中途解約の例示データによる定義
文章だけの要件定義は計算ミスにつながるため、入力値と期待結果の組を用意します。
- 日付・期間：商品期間、預入日、満期日、休日補正、うるう年、金利改定日を示す
- 利息計算：適用金利、単利・複利、税引前後、端数処理を定義する
- 満期処理：元利金・元金継続、普通預金への振替、手動受付を分ける
- 中途解約：権限、適用利率、再計算、差額仕訳、承認、取消方法を定める
満期日が休日の場合は前営業日か翌営業日かを決め、利息の計算期間も例にして示します。
計算者と適用ルールを監査ログに残す条件も、RFPに含めます。
移行・性能・可用性・セキュリティの数値化
「高速」「止まらない」といった言葉では解釈が分かれます。そのため、性能や復旧の条件を数値で示します。
- 性能：応答時間、満期集中日の件数、バッチ完了時刻を決める
- 可用性：稼働率、目標復旧時間・時点を定義する
- 運用：同時接続数、監視時間、バックアップ保管期間を示す
- セキュリティ：認証、特権ID、暗号化、脆弱性、ログ、委託先管理を確認する
日次締めや大量の満期処理を含む性能試験を、受入基準にします。
金融庁は2025年7月、金融分野のサイバーセキュリティガイドラインの一部改正を公表しました（出典：金融庁「金融分野におけるサイバーセキュリティ対策について」、2025年7月）。
外注する場合も、発注側は脆弱性管理、ログ監視、インシデント対応、再委託管理のリスクを把握しておく必要があります。
定期預金システムの契約形態の使い分け
契約は、工程ごとの不確実性と納める中身に応じて使い分けます。構想や業務分析は準委任、仕様と受入条件が固まった開発は請負が現実的です。
契約名だけで決めず、完了条件と変更時の扱いを明記します。
要件整理や専門家支援に向く準委任契約
準委任は、専門家の作業と善管注意義務を前提に、稼働時間や作業内容に応じて報酬を支払う契約です。業務分析やRFP作成支援などに適しています。
- 業務整理：現行業務や商品規程を洗い出す
- 発注準備：RFP作成やベンダー評価を支援する
- 専門支援：構成や移行方針を検討する
業務有識者が不足する場合は、外部の業務アナリストやPMOも活用できます。
作業時間と成果を混同しないよう、週次の報告だけでなく、納品するものも定めておきます。例として挙がるのは、業務フロー、計算ケース、課題・決定事項、RFP案、移行データ定義などです。
発注側は、レビュー期限や担当者の交代、再委託、秘密情報、アクセス権限についても、契約で決めておきます。
仕様と受入基準が固まった工程に向く請負契約
請負は、合意した仕事を完成させて、納品物を引き渡すことを目的とする契約です。仕様と受入基準を確定できる工程に適しています。
- 設計・実装：詳細設計書やプログラムを定める
- テスト：仕様書と結果を納品物に含める
- 移行・運用：移行ツールや運用手順書を定める
受入基準には、計算精度、処理性能、障害時の復旧、監査ログ、脆弱性対応まで含めます。
請負でも、発注側の確認責任は残ります。要件漏れを納品直前に見つけると、追加費用や納期の延長につながります。そのため、各工程と移行リハーサルでレビューし、承認者、影響範囲、追加工数、リリースへの影響を記録します。
契約書に入れるべき責任分担と終了条件
契約書と仕様書には、責任の所在を明記します。対象は、ライセンスや個人情報、損害賠償などです。
- 権利と情報：納品物、データ、秘密情報の扱いを定める
- 管理・監査：監査権限、再委託、障害報告を決める
- 終了・移行：データ返却と移行支援を明記する
金融庁の監督指針も、外部委託契約で役割と責任を定める考え方を示しています（出典：金融庁「中小・地域金融機関向けの総合的な監督指針」、2026年確認）。監査権限や再委託の手続き、サービス水準も、定める内容として示されています。
満期バッチが停止した場合に備えて、確定範囲、再実行する取引、二重利息や振替を防ぐ方法を決めておきます。また、ログ、ソースコード、移行ツールについて、終了後の利用可否も確かめます。
定期預金システムの費用相場と見積の内訳
公開されている価格は少ないため、以下の金額はRFP前の予算取りに使う推定レンジとして読んでください。金額は、範囲、連携先、移行、試験内容によって変わります。
- 周辺機能の追加：商品・金利・満期管理、画面、APIを含め1,000万〜3,000万円
- 預金モジュール刷新：会計・CIF・チャネル・AML連携、移行、総合テストを含め3,000万〜1億5,000万円
- 共同利用への移行：複数行対応、基盤更改、並行稼働、移行リハーサルを含め1億〜数億円
- 全面刷新：他の預金・融資・為替・元帳も含め数億〜数十億円以上
下の項目ほど定期預金単体ではなく、範囲を広げた場合の概算です。
初期費用を人件費・パッケージ・移行・テストに分けた内訳
見積が「開発一式」だけでは、何にいくらかかっているのか分かりません。
- 工程：要件定義、業務分析、管理、設計、実装、テスト、移行を分ける
- 基盤・導入：インフラ、DR、セキュリティ評価、教育、リリース支援を確認する
- 機能：金利計算、満期バッチ、API、画面、帳票で比べる
2026年の受託開発では、人月単価と工数を掛け合わせて金額を考えます。
人月単価の目安は、プログラマーが40万〜80万円、SEが60万〜100万円、PMが90万〜150万円です。この目安は、SIA株式会社・シンシア株式会社の2026年相場解説を出典としています。
単価は、金融業務の知識、24時間運用、監査対応、専門アーキテクトの有無によって変わります。そのため、総額に当てはめるのではなく、役割と期間から積み上げて考えます。
保守・クラウド・制度変更のランニング費用
稼働後の予算を見落とさないよう、継続してかかる費用を分けて確認します。
- 保守運用：監視、問い合わせ、障害訓練、脆弱性診断を見積もる
- 基盤費：クラウド、ライセンス、バックアップを確認する
- 変更対応：制度・税率・金利ルールの改定を見込む
保守費は、初期開発費の年5〜15％程度とされることがありますが、これは公開価格ではなく案件条件に基づく推定です。24時間365日の監視や高い可用性を求める場合は、人員とSLAが増えます。
クラウドについては、利用料が増減する条件を確かめます。あわせて、データ転送やログ保管、バックアップなどの費用を見ておきます。災害対策環境や環境の追加についても、費用を確認します。
2025年5月、ソニー銀行は富士通との協業でAWS上の次世代デジタルバンキングシステムを稼働させました。この事例は、商品・サービスや業務機能をマイクロサービス化したものです。
出典は、ソニー銀行「新勘定系システム 稼働開始のお知らせ」（2025年5月7日）です。
クラウドを採用しても、責任共有モデルの理解と委託先管理は欠かせません。
委託先の選定と見積比較で確認するポイント
委託先は、定期預金の業務ルール、既存基盤との接続、移行後の運用を説明できるかで評価します。知名度や単価だけで決めないようにします。
RFPは2〜3社に同じ条件で渡し、提案書や体制表、WBS、リスク一覧を比べます。見積内訳、前提条件、保守計画も、そろえて確かめます。
大規模な勘定系ベンダーと、APIや周辺開発に強い会社とでは、得意な範囲が異なります。
定期預金固有の実績と担当チームの確認
金融機関向けの実績があるかだけでなく、定期預金のどの機能を担当したかを尋ねます。
- 担当実績：満期、自動継続、中途解約、利息再計算、バッチを確認する
- 匿名情報：業態、対象機能、データ量、稼働時間、障害対応、移行回数を聞く
- 実働体制：提案者と開発・テスト・運用担当を照合する
- 再委託：担当範囲、データアクセス、管理方法を確認する
提案者と実際に作業するチームが異なる場合もあります。その場合は、業務アナリスト、アーキテクト、PMの担当者と役割を確かめます。テスト・移行責任者と運用設計者については、担当者を尋ねます。担当者の稼働率や、交代時の代替要員も尋ねます。
見積書の抜け漏れと前提条件の比較
総額を比べる前に、各社の見積に同じ作業と移行条件が含まれているかを確かめます。
- 開発・試験：要件定義、設計、各テスト、性能試験、脆弱性診断を照合する
- 移行・運用：移行設計、リハーサル、教育、障害訓練、保守引継ぎを確認する
- 移行データ：残高、預入日、満期日、金利、継続条件、顧客属性を確認する
安い見積では、受入テストが発注側の作業になっていたり、データ整備が別料金になっていたりする場合があります。監査ログや権限設計、満期集中日の試験も、見積に含まれるかを確かめます。
高い見積でも、中身が一式にまとめられていれば内訳を尋ねます。予備工数や管理費、ライセンス、クラウド、再委託費などが対象です。
見積比較会議では、各社に同じ追加質問を行い、回答を記録します。前提条件がそろうと、金額差の理由を判断しやすくなります。
最終選定での質問への回答力の評価
実業務の例外や障害時の流れを題材にして、提案の説明力を確かめます。たとえば、金利改定日の前日の預入が、うるう年をまたいで満期前に中途解約され、その後取消しされる場合を示します。
- 計算ケース：うるう年の満期や中途解約を説明してもらう
- 障害対応：中途解約後の取消し、再処理、復旧を確認する
- 連携説明：元帳、チャネル、監査ログの流れを図示してもらう
選定会議では、機能適合度から価格までの8項目を重み付けして比べます。
中心は、機能適合度、金融業務の理解、移行能力です。残りは、テスト計画、セキュリティ、運用体制、契約条件、価格です。
価格だけで判断せず、重大な計算ミスや切替失敗を防ぐ力も評価します。
候補を決めたら、契約前に、提案と見積の前提を仕様書に反映します。
口頭での説明も、合意事項にします。
よくある質問（FAQ）
定期預金システムの開発費用は最低いくらですか？
既存の勘定系に接続する商品・金利・満期管理、画面、APIに絞った場合でも、金融向けのテスト、監査、移行、運用設計を含めると、1,000万〜3,000万円程度が目安です。
これは一律の公開価格ではなく、商品数や取引量などの条件による推定です。チャネル、連携先、移行データ、可用性も金額に関わります。
パッケージ本体の価格だけでなく、SI費用と保守費も確認しておきます。
定期預金システムは開発会社へ丸ごと外注できますか？
開発、テスト、移行、運用設計は外注できますが、業務ルールと受入判定は発注側が担うことになります。
そのため、商品規程や計算の正解を開発会社に伝える体制を整えます。残高照合や監査・承認、障害時の業務判断も、発注側で担当者を決めておきます。
業務有識者を発注側の責任者に置くと、ベンダー任せによる認識のずれを減らせます。
RFPはどの程度まで作ってから見積を依頼すべきですか？
見積を依頼する前に、目的、範囲、現行システム、対象商品を整理します。業務フローや計算ケースも、依頼前にそろえておきます。外部連携、移行対象、非機能要件、希望時期も整理してから依頼します。
契約や提案の条件も示します。未確定の画面や実装方式は、未確定であることを明記します。提案会社には、確認事項と追加調査の見積を依頼し、比べられる前提をそろえます。
委託先は何社から見積を取るとよいですか？
同じRFPで2〜3社から見積を取ると、価格や工数、体制、除外範囲を比べやすくなります。
勘定系、金融向けパッケージ、APIや周辺開発など、得意領域の異なる会社を候補に含めます。
候補が多すぎると、質問への対応や評価の負担が増えます。そこで、RFPの参加条件によって候補を絞ります。
まとめ
発注前のスコープと責任境界の確定
まず、商品・金利・満期を扱う周辺システムにとどめるか、預金元帳を含む勘定系刷新とするかを決めます。さらに、対象外もRFPに書き、元帳や移行、監査、障害時の責任者を定めておきます。
見積比較で確認する移行・テスト・運用
委託先の提案は、費用と業務要件を同じ条件にそろえて比べます。
- 費用：移行リハーサル、性能試験、保守、制度変更を分けて比べる
- 提案内容：2〜3社に同じ業務ケースを示し、計算や復旧、照合、運用体制を確認する
- 発注条件：発注形態を比べ、商品規程や金利、移行、監査証跡をRFPにまとめる
発注側は業務ルールと受入基準を持ち、委託先は設計、開発、テスト、移行、運用を支援します。そのうえで、契約終了時のデータ返却や移行支援まで含めて委託先を評価します。
▼全体ガイドの記事
・定期預金システム開発の完全ガイド
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。