研究費管理システムの発注は、現行業務の棚卸し、RFPでの要件共有、候補会社の比較の順に進めると、制度と現場に合う導入につながります。
発注形態の選び方、要件整理と契約、費用相場、委託先選定の順に、それぞれの進め方を説明します。
▼全体ガイドの記事
・研究費管理システム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
研究費管理システムを発注・外注する前の全体像
研究費管理システムは、一般的な会計ソフトに比べて管理対象と承認ルールが複雑になりやすい業務システムです。
発注する前に、対象業務を研究課題、資金、執行、証憑、承認、報告に分けておくと、必要な開発範囲と委託先に求める専門性が見えてきます。
科研費・受託研究費・学内予算の同一基盤での管理
研究費には科研費、受託研究費、共同研究費、寄附金、学内研究費などがあります。
- 共通する流れ：申請、採択、交付、配分、入金、執行、残高、終了報告。
- 資金ごとの違い：使える費目、承認者、証憑の扱い、繰越や費目間流用のルール。
- 関連付ける情報：資金種別、研究課題、研究代表者、分担者、部局、年度、直接経費・間接経費、費目、会計コード。
研究者の利便性と監査で説明できる証跡の両立
研究者と事務局では、システムに求める要件が違います。
- 研究者の利便性：予算残高の即時確認、スマートフォンや学内ポータルからの購入・出張・立替申請。
- 監査で確認すること：誰がいつどの規程で承認したか、どの証憑を確認したか、会計へ渡した仕訳。
- 残す履歴：申請、差戻し理由、承認、証憑の版、出力、権限変更。
評価では、画面の使いやすさに加えて、証跡を残す設計も発注範囲に含めます。
会計システムとの境界と連携範囲の決定
研究費管理システムで既存の全てを置き換える必要はなく、財務会計、購買、旅費、人事給与、認証基盤、文書管理は残して、研究課題と予算の管理だけを新設する構成もあります。
リアルタイムAPIが必要な連携と日次のCSV連携で足りる連携を分けて考えると、初期費用を抑えやすくなります。
発注書には対象範囲に加えて、連携元と連携先、データ項目、頻度を書きます。さらに、エラー時の再送方法と責任分界も記載します。
研究費管理システムの発注形態の選び方
標準化しやすい業務はクラウドSaaSや文教向けパッケージで進め、固有の規程や会計連携だけを設定と追加開発で補う方式が検討しやすいです。一方で、研究支援、財務、購買、認証を一度に刷新する場合は、大規模SIが候補になります。なお、独自の研究ポートフォリオや法人横断の管理が競争力に直結する場合にかぎり、スクラッチの比率を高めます。
クラウドSaaS・パッケージの向いている組織
クラウドSaaSは、サーバーやOS更新、バックアップ基盤を自組織で持たずに始められるため、部局単位の先行導入にも合っています。
パッケージは、科研費の基金化や複数年度管理を標準機能で扱えます。支出伝票、決裁、報告書出力も含めて、短期間に利用を始めやすい方式です。
確認する点は、標準機能に業務を合わせられるか、費目や承認ルートを設定できるかです。さらに、制度改正のたびに追加開発が発生しないかも検討します。
パッケージへの追加開発と例外処理の優先順位
部局別の承認経路、分担金の配分、特殊な費目は、標準画面では扱いにくい例外です。年度繰越と研究期間終了後の残務も、こうした例外に含まれます。
例外を全て個別画面にすると、更新のたびに検証と改修が必要になります。そのため、まず規程と運用を見直し、標準機能へ寄せられる部分を分けます。そのうえで、機関の説明責任や研究者の負担に直結する例外から、優先して追加開発します。
スクラッチとハイブリッドの判断基準（独自性と運用力）
スクラッチ開発は、複数法人・複数キャンパスの研究ポートフォリオや、既存ERPで表現できない独自制度に合わせやすい方式です。
一方で、要件定義、テスト、データ移行、制度改正への対応、保守人材の確保まで、発注者の負担が増えます。
予算・承認はパッケージ、研究者向けポータルやデータ分析は個別開発にする、ハイブリッド構成も有効です。比べるときは、将来の変更を誰が維持するかを見ます。
RFPと要件整理の役割分担
RFPは、課題と対象範囲、制約、評価方法を複数の候補会社へ同じ条件で伝える文書です。「高機能なシステムを作ってください」だけでは、候補会社ごとに前提が異なり、提案を比べられません。
発注者は業務の目的と優先順位を定めます。一方、ベンダーは実現方式と体制を提案し、工数やリスクも示します。
IPAも、要件定義に業務部門が主体的に関わることと、ユーザー企業が要件を定義する責任を示しています（出典: IPA「ユーザのための要件定義ガイド 第2版」、2019年公開・2026年確認）。
資金別・利用者別・年度別の現行業務の棚卸し
業務フローには、採択・交付・配分から監査対応までを記します。なかでも、購入、業務委託、旅費、謝金・人件費の支出は、検収、支払、報告まで一続きに書きます。
研究者、研究代表者、秘書の各役割について、入力・確認・承認する情報を整理します。部局事務、研究推進部門、経理についても、同じ形で整理します。監査担当も含めて役割ごとに分けて書いておくと、どの段階で誰が情報を扱うかが一目で分かります。
科研費に加えて受託研究費と共同研究費も並べると、資金による違いが明確になります。その違いが分かると、条件分岐とマスタ設計に生かせます。
RFPに入れる業務要件・データ要件・非機能要件
RFPでは、業務、データ、非機能の三つの観点から要件を具体化します。
- 業務要件：課題登録から終了報告、権限、費目確認、承認・差戻し、証憑添付、報告書出力。
- データ要件：課題番号、資金種別、研究者、部局、年度、費目、予算・執行・残高、会計コード、証憑、承認履歴。
- 非機能要件：同時利用者数、画面応答、バックアップ、復旧目標、認証、暗号化、監査ログ、データ所在地、契約終了時の返却・削除。
既存データは、件数と欠損、重複を示します。さらに表記揺れも加えて、移行範囲を見積もれる状態にします。
将来の要件としてのDMPと研究セキュリティ
日本学術振興会は、2024年度以降に実施する科研費の新規・継続課題で、研究データ管理計画であるDMPの活用を求めています（出典: 日本学術振興会「科研費における研究データの管理・利活用について」、2024年度以降の運用、2026年確認）。
- DMPの作成・更新：研究開始前の計画作成と、実施中の更新。
- データ連携：公開した研究データのメタデータを報告する流れを踏まえ、研究費管理システムと研究データ基盤、機関リポジトリの連携を早めに確かめます。
- 研究セキュリティ：国際共同研究や技術情報を扱う機関は、アクセス制御、共有範囲、再委託先管理、操作ログを要件に含めます。
JSTも、2026年度に研究セキュリティ確保の取組を実施しています（出典: JST「研究セキュリティ確保への取組」、2026年度）。
研究費管理システム開発の契約形態の組み合わせ
現行調査や業務整理は要件が揺れやすい一方で、設計・製造・テストは成果物を確定しやすい工程です。そのため、同じ契約条件にせず、工程の性質に応じて契約を分けます。
要件定義は準委任、画面や帳票の開発は請負とし、移行・教育・保守は作業内容に応じて準委任か個別契約にします。こうして分けると、責任範囲と変更ルールを明確にできます。
準委任契約（探索・伴走）と請負契約（確定した成果物）の使い分け
準委任契約は、作業を進めながら合意を深める工程に向いています。たとえば業務ヒアリングや現行分析、プロトタイプが該当します。移行計画や運用設計も含まれます。
請負契約は、対象画面や帳票、APIが決まった範囲に適しています。さらに、テスト条件、納期、受入基準まで決まっていることが前提になります。
IPAの情報システム・モデル取引・契約書第二版では、ユーザー企業とITベンダーの責務や、請負・準委任、複数契約の関係が整理されています（出典: IPA「情報システム・モデル取引・契約書 第二版」、2025年4月更新）。
契約書に書く発注者の協力事項とベンダーの責任
契約条件には、双方が準備する情報と作業を明記します。
- 発注者の協力事項：研究課題マスタ、費目ルール、会計コード、既存データ、検証担当者、意思決定期限。
- ベンダーの責任：不明点の質問期限、設計書・テスト結果の提出、品質管理、脆弱性対応、再委託先管理。
- 変更時の手順：承認遅延、データ不備、制度変更、外部サービス停止の影響と協議方法。
責任を一方に寄せないよう、追加費用や納期変更を透明に扱える条件にします。
制度改正と追加要望の変更管理票による統制
制度や機関規程が変わると、費目、帳票、承認経路の追加が発生します。報告項目の追加も生じます。そのため、変更要求の受付から見積、承認までの流れを契約時に決めておきます。
納期の再設定や緊急対応も、同じ時点で定めます。標準保守に含む変更と追加開発、次期改善へ回す変更に分けます。口頭の要望を無償対応とみなさない運用も必要です。
契約終了後は、ソースコードと設定情報の引き渡し条件を決めます。データ辞書と運用手順書の引き渡し条件も含めます。
研究費管理システム開発の費用相場と見積内訳
価格は利用者数だけでなく、研究課題数、資金種別、複数年度管理によって変わります。購買・旅費・人事との連携も価格を左右します。さらに、証憑保管やデータ移行、監査ログ、クラウド運用の範囲も影響します。
次の金額は、公開調達例と業務システムの機能範囲をもとにした推定です。特定製品の定価や確定見積ではありません。候補会社には同じ前提を渡し、初期費用と運用費を分けて見積もってもらいます。
小規模は300万〜800万円、中規模は1,000万〜3,000万円の目安
初期費用は、部局導入、大学全体導入、複数キャンパス統合の順に規模が大きくなります。
- 小規模：1部局で利用者20〜100人程度、CSV中心の会計連携を行うクラウド・パッケージ導入。
- 中規模：大学全体で利用者100〜500人程度、複数システム連携。
- 大規模：複数キャンパスで研究支援、財務、購買を統合。
小規模の初期費用は300万〜800万円程度、中規模は1,000万〜3,000万円程度が目安です。
大規模なスクラッチまたはERP連携は3,000万〜1億円超となる可能性があります。ただし、これは機能、連携、移行範囲を含む推定で、規模だけで金額を断定することはできません。
公開調達の4,653万円の事例と契約範囲の確認
JETROの政府公共調達データベースには、豊橋技術科学大学の「大学研究費管理会計システム一式」が2024年に4,653万円で落札された公示があります。
調達方法は「借入」で、株式会社ニッセイコム中部支社が最低価格で落札しました（出典: JETRO「大学研究費管理会計システム 一式」、公示日2024年6月11日）。
この金額が、他大学にもそのまま当てはまるとは限りません。そのため、契約期間、利用料、導入設定の範囲をそろえて比較します。保守や連携、機器・サービスの範囲も、同じ条件で並べて確認します。
移行・教育・保守・月額利用料を初期費用と分けた見積
初期費用と運用費を分けて、見積の内訳と対象作業を確認します。
- 初期作業：企画・要件定義、基本・詳細設計、製造、テスト、移行、教育、稼働立会い、プロジェクト管理。
- 運用費：クラウド利用料、ユーザー課金、ストレージ、バックアップ、監視、セキュリティ、問い合わせ、制度改正、機能改善。
小規模運用は月額10万〜40万円程度、中規模は月額30万〜100万円または年額360万〜1,200万円程度との推定があります。
金額は、利用者数や課題数、証憑容量、SLA、連携オプションによって変わります。
保守費を開発費の一定割合だけで計算せず、含む作業と含まない作業を確認します。
研究費管理システムの委託先選定と見積比較で見るべきポイント
価格だけで委託先を選ぶと、制度理解やデータ移行が不足しがちで、追加開発や稼働後の問い合わせが増えるおそれがあります。
まず、各社が研究費専用パッケージ、大学財務ERP、クラウド経費、受託開発、大規模SIのどの立場かを確認します。そのうえで、対象範囲との適合性を評価します。
会社名や導入社数だけでなく、実績も確認します。見るのは、科研費・基金・複数年度の実績と、購買・旅費・謝金の実績です。あわせて、会計連携、監査ログ、制度改正保守の実績も確認します。
実績の確認は業界名より業務とデータの深さで
導入実績は、大学に何件導入したかだけでは判断できません。そのため、資金、研究課題と利用者の規模、連携先を質問します。あわせて、標準機能・設定・追加開発のどこまでが範囲かも聞きます。
基金化、補助金と基金の区別、年度繰越まで説明できる会社は、初期の段階から具体的なリスクを示せます。分担金、間接経費、研究期間終了後の残処理についても、同じ水準で説明できるかを確認します。
可能であれば、画面デモに加えて、匿名化した業務フローと移行計画のサンプルを確認します。
前提条件と内訳を同じ表でそろえた見積比較
見積比較表には、要件定義、ライセンス・利用料、設定、追加開発を並べます。連携、移行、証憑保管、認証、テストも、項目ごとに分けて書きます。研修、稼働支援、保守、制度改正対応も、同じ表に入れます。
各項目について、対象範囲、数量、単価・工数を確認します。さらに、納品物や前提、除外事項、追加時の単価も見ます。
A社がデータクレンジングを含み、B社が別途請求する場合は、総額を並べても同じ条件で比べられません。そのうえで、3年程度の利用を想定し、初期費用と月額・年額を合算したTCOでも判断します。
提案書で評価する運用保守とセキュリティの体制
提案書では、運用とセキュリティの対応範囲を確認します。
- 運用：問い合わせ窓口、障害の一次対応、復旧目標、バックアップ、脆弱性対応、バージョンアップ。
- 契約・体制：制度改正の反映時期、再委託先、データセンター所在地、契約終了時のデータ返却・削除。
- アクセス管理：最小権限、職務分掌、多要素認証、操作・承認・出力ログ。
閲覧や承認の権限は、研究者、秘書、部局事務、経理で異なります。
文部科学省のガイドラインも、研究機関に公的研究費の適正な管理・監査体制を求めています（出典: 文部科学省「研究機関における公的研究費の管理・監査のガイドライン」、令和3年2月1日改正、2026年確認）。
見積には、機能だけでなく、規程と運用を維持する体制も含めます。
よくある質問（FAQ）
発注では、費用や機能に加えて、制度と現場の運用をどこまで要件に反映するかが判断の分かれ目になります。よくある質問に答えます。
研究費管理システムはパッケージとスクラッチのどちらがよいですか？
標準化できる業務が多く、早期導入と制度改正への追随を重視するなら、クラウドSaaSやパッケージが候補です。
独自制度や法人横断の研究ポートフォリオ、特殊な承認や分析が重要な場合は、追加開発やスクラッチも検討します。その際は、標準機能、設定、追加開発の順に適合性を確認します。
研究費管理システムの開発費用はどのくらいですか？
小規模な部局導入は300万〜800万円程度です。中規模の大学全体導入は1,000万〜3,000万円程度です。大規模なスクラッチやERP連携は、3,000万〜1億円超という推定の幅です。
金額は、利用者数、対象業務、会計・購買連携の前提によって変わります。移行、証憑保管、研修、保守の前提でも変わります。公開調達の4,653万円の事例も、借入契約の範囲を確認してから予算の判断に使います。
RFPを作る前に最低限そろえる資料は何ですか？
研究費の種類と規程、業務フロー、現行画面やExcelを、RFPの前にそろえます。課題・費目・会計コードのマスタ、利用者と権限、承認経路も用意します。連携仕様、移行データ、希望時期も含めます。
全仕様を発注者だけで完成させなくても構いません。ただし、課題、対象範囲、優先順位、必須の非機能要件は決めておきます。
残高の表示時点、証憑の保存年数・形式、承認者は、見積の差が出やすいため、条件を明確にします。
委託先の見積は何社から取るとよいですか？
性格の異なる3社前後へ同じRFPを渡すと、標準機能、追加開発、移行・保守体制を並べて比べられます。
研究費専用型、大学財務・ERP型、受託SI型を混ぜて依頼するときは、得意業務、対応範囲、連携方式、契約終了時のデータ引き渡しを、評価表で比べます。
提案書の見栄えより、質問の質、リスク説明、担当予定者の経験、導入後の支援体制を重視します。
まとめ
まず、科研費、受託研究費、共同研究費、学内予算を、研究課題・研究者・費目・年度の単位で整理します。そのうえで、採択から監査・報告までの業務範囲を決めます。
次に、クラウド、パッケージ、追加開発、スクラッチの役割を分け、標準化できる部分と機関固有の部分を見極めます。
RFPで具体化する制度・データ・非機能・責任分界
RFPには、現行業務、資金別ルール、課題・費目マスタを含めます。承認・差戻し、証憑・監査ログ、会計・購買・認証連携も、要件として書きます。さらに、DMP、研究セキュリティ、移行、保守も加えます。
契約は工程の性質に合わせて分けます。また、見積は移行や教育、月額利用料、保守、制度改正対応まで含めたTCOで比べます。
最初に行う現行業務の棚卸しと小さな先行導入
全学へ広げる前に小さく導入し、効果を測って次の開発に反映します。
- 1部局や特定資金で、残高照会、購入申請、証憑添付、承認、会計連携を試します。
- 研究者・秘書・事務局の入力時間、差戻し率、問い合わせ数、月次集計工数を測り、標準機能で解けない課題を次の開発へ回します。
- 発注者、利用者、情報システム、経理、研究推進部門が同じ評価表で候補会社を比べ、導入後に使われるシステムを選びます。
▼全体ガイドの記事
・研究費管理システム開発の完全ガイド
▼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を創業。