研究費管理システム開発の発注/外注/依頼/委託方法について

研究費管理システムを発注・外注するなら、科研費や受託研究費を記録するだけでなく、採択・配分から執行、証憑、承認、監査、報告までを研究課題単位でつなぐ業務基盤として要件を定めることが重要です。

本記事では、研究費管理システムの発注形態の選び方、RFPと要件整理の進め方、請負・準委任などの契約形態、2026年時点の費用相場、委託先選定と見積比較のポイントを、大学・研究機関の発注担当者向けに解説します。研究者の入力負担を抑えながら、補助金と基金、複数年度、費目別ルール、監査証跡を無理なく運用へ落とし込む方法も整理します。

▼全体ガイドの記事
・研究費管理システム開発の完全ガイド

研究費管理システムを発注・外注する前の全体像

研究費管理システムは、一般的な会計ソフトよりも管理対象と承認ルールが複雑になりやすい業務システムです。発注前に対象業務を「研究課題」「資金」「執行」「証憑」「承認」「報告」の単位で切り分けると、必要な開発範囲と委託先に求める専門性が見えやすくなります。

研究費には、科研費、受託研究費、共同研究費、寄附金、学内研究費などがあります。申請・採択・交付・配分・入金・執行・残高・終了報告という流れは共通していても、使用できる費目、承認者、証憑、繰越や費目間流用の扱いは資金ごとに異なります。資金種別を単なる名称として登録するのではなく、研究課題、研究代表者、分担者、部局、年度、直接経費・間接経費、費目、会計コードを関連付けて保持することが必要です。

研究者は予算残高をすぐ確認でき、スマートフォンや学内ポータルから購入・出張・立替を申請できることを求めます。一方、事務局と経理部門は、誰がいつどの規程で承認し、どの証憑を確認し、会計へどの仕訳を渡したかを追跡できなければなりません。画面の使いやすさだけを評価せず、申請履歴、差戻し理由、承認履歴、証憑の版、出力履歴、権限変更履歴を残す設計まで発注範囲に含めます。

研究費管理システム単体で全てを置き換える必要はありません。既存の財務会計、購買、旅費、人事給与、認証基盤、文書管理を残し、研究課題と予算の管理だけを新設する構成もあります。リアルタイムAPIが必要な連携と、日次のCSV連携で足りる連携を分けると初期費用を抑えやすくなります。発注書には、システムの対象範囲だけでなく、連携元・連携先、データ項目、連携頻度、エラー時の再送方法、責任分界を記載します。

研究費管理システムの発注形態はどれを選べばよいですか？

結論として、標準化しやすい業務はクラウドSaaSや文教向けパッケージを使い、機関固有の規程や会計連携だけを設定・追加開発する方式が検討しやすいです。研究支援、財務、購買、認証を一度に刷新する必要がある場合は大規模SIを選び、独自の研究ポートフォリオや法人横断管理が競争力に直結する場合だけスクラッチの比率を高めます。

クラウドSaaSは、サーバーやOS更新、バックアップ基盤を自組織で持たずに始めやすく、部局単位の先行導入にも向いています。パッケージは、科研費の基金化や複数年度管理、支出伝票、決裁、報告書出力などの標準機能を短期間で利用しやすい点が特徴です。ただし、標準機能に業務を合わせられるか、費目や承認ルートの設定で対応できるか、追加開発が制度改正のたびに発生しないかを確認します。

研究機関では、部局別の承認経路、分担金の配分、特殊な費目、年度繰越、研究期間終了後の残務など、標準画面だけでは扱いにくい例外が存在します。これらを全て個別画面にすると、アップデートのたびに検証と改修が必要になります。まず規程と運用を見直して標準機能へ寄せられる部分を分け、そのうえで機関の説明責任や研究者の負担に直結する例外だけを追加開発する順番が安全です。

スクラッチ開発は、複数法人・複数キャンパスを横断する研究ポートフォリオや、既存ERPでは表現できない独自制度を業務に合わせやすい方式です。一方で、要件定義、テスト、データ移行、制度改正対応、保守人材の確保まで発注者の負担が増えます。研究費の予算・承認はパッケージ、研究者向けポータルやデータ分析は個別開発というハイブリッド構成も有効です。自由度ではなく、将来の変更を誰が維持できるかで比較します。

RFPと要件整理はどこまで発注者が行いますか？

RFPは「高機能なシステムを作ってください」と依頼する文書ではなく、解決したい課題、対象範囲、制約、評価方法を複数の候補会社へ同じ条件で伝える文書です。発注者が業務上の目的と優先順位を定め、ベンダーが実現方式、体制、工数、リスクを提案する役割分担にします。IPAも、要件定義では業務部門のユーザーが主体的に関与し、ユーザー企業が要件を定義する責任を負う考え方を示しています（出典: IPA「ユーザのための要件定義ガイド 第2版」、2019年公開・2026年確認）。

最初に、採択・交付・配分、物品購入、業務委託、旅費、謝金・人件費、立替、検収、支払、報告、監査対応の流れを業務フローにします。そのうえで、研究者、研究代表者、秘書、部局事務、研究推進部門、経理、監査担当の誰がどの情報を入力・確認・承認するかを整理します。科研費だけでなく受託研究費や共同研究費も並べ、資金による違いを赤字で示すと、システムの条件分岐とマスタ設計へつなげやすくなります。

業務要件には、研究課題の登録から終了報告までの業務、利用者ごとの権限、費目別のチェック、承認と差戻し、証憑の添付、報告書出力を記載します。データ要件には、課題番号、資金種別、研究者、部局、年度、費目、予算額、執行額、残高、会計コード、証憑、承認履歴を挙げ、既存データの件数・欠損・重複・表記揺れも示します。非機能要件には、同時利用者数、画面応答、バックアップ、復旧目標、認証、暗号化、監査ログ、データ所在地、契約終了時の返却・削除を含めます。

日本学術振興会は、2024年度以降に実施する科研費の新規・継続課題について、研究データの管理計画であるDMPの活用を求めています。研究開始前に計画を作り、実施中に更新し、公開した研究データのメタデータを報告する流れを踏まえると、研究費管理システムと研究データ基盤、機関リポジトリをどう連携するかを早めに確認する必要があります（出典: 日本学術振興会「科研費における研究データの管理・利活用について」、2024年度以降の運用、2026年確認）。さらにJSTは2026年度も研究セキュリティ確保の取組を実施しており、国際共同研究や技術情報を扱う機関では、アクセス制御、共有範囲、再委託先の管理、操作ログをRFPに含めます（出典: JST「研究セキュリティ確保への取組」、2026年度）。

研究費管理システム開発の契約形態はどう組み合わせますか？

研究費管理システムでは、要件が揺れやすい現行調査・業務整理と、成果物を確定しやすい設計・製造・テストを同じ契約条件にしないことが大切です。要件定義は準委任、画面や帳票などの開発は請負、移行・教育・保守は作業内容に応じた準委任または個別契約に分けると、責任範囲と変更ルールを整理しやすくなります。

準委任契約は、業務ヒアリング、現行分析、プロトタイプ、移行計画、運用設計など、作業を進めながら合意を深める工程に向いています。請負契約は、対象画面、帳票、API、テスト条件、納期、受入基準が決まった範囲に適しています。IPAの情報システム・モデル取引・契約書第二版でも、ユーザー企業とITベンダーの責務、請負・準委任、複数契約の関係が整理されています（出典: IPA「情報システム・モデル取引・契約書 第二版」、2025年4月更新）。

発注者が提供する研究課題マスタ、費目ルール、会計コード、既存データ、検証担当者、意思決定期限を前提条件として明記します。ベンダー側には、要件の不明点を質問する期限、設計書やテスト結果の提出、品質管理、脆弱性対応、再委託先の管理を求めます。どちらか一方へ責任を押し付けるのではなく、発注者の承認遅延、データの不備、制度変更、外部サービス停止が起きた場合の影響と協議手順を決めておくと、追加費用や納期変更を透明に扱えます。

研究費制度や機関規程が変わると、費目、帳票、承認ルート、報告項目の追加が発生します。契約時点で、変更要求の受付方法、影響分析、見積提出、承認者、納期の再設定、緊急対応の扱いを決めます。口頭の「この項目も入れてください」を無償対応と見なさず、標準保守に含む変更、追加開発になる変更、次期改善へ回す変更を分類します。契約終了後のソースコード、設定情報、データ辞書、運用手順書の引き渡し条件も忘れずに確認します。

研究費管理システムの費用相場と見積内訳

研究費管理システムの価格は、利用者数だけでなく、研究課題数、資金種別、複数年度管理、購買・旅費・人事との連携、証憑保管、データ移行、監査ログ、クラウド運用の範囲で大きく変わります。以下はリサーチノートで整理した公開調達例と業務システムの機能範囲をもとにした推定レンジであり、特定製品の定価や確定見積ではありません。候補会社には同じ前提を渡し、初期費用と運用費を分けて提示してもらいます。

1部局で利用者が20〜100人程度、会計連携がCSV中心のクラウド・パッケージ導入なら、初期費用は300万〜800万円程度が推定レンジです。利用者が100〜500人程度で、購買、旅費、認証、財務会計を連携する大学全体の導入では、初期費用1,000万〜3,000万円程度が一つの目安になります。複数キャンパス、研究支援、財務、購買を統合するスクラッチまたは大規模ERP連携では、3,000万〜1億円超となる可能性があります。いずれも機能・連携・移行の範囲を含む推定で、規模だけで金額を断定できません。

実例として、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やパッケージが選びやすいです。独自の資金制度、法人横断の研究ポートフォリオ、既存ERPでは扱えない特殊な承認や分析が重要なら、パッケージに追加開発を組み合わせるか、スクラッチを検討します。最初から方式を固定せず、標準機能、設定、追加開発の順で適合性を確認することが大切です。

小規模な部局導入で300万〜800万円程度、中規模の大学全体導入で1,000万〜3,000万円程度、大規模なスクラッチやERP連携で3,000万〜1億円超という推定レンジがあります。ただし、これは利用者数、対象業務、会計・購買連携、データ移行、証憑保管、研修、保守の前提を置いた相場観です。公開調達では4,653万円の事例もありますが、借入契約のため、自組織の見積と同じ契約範囲かを確認してから予算判断します。

研究費の種類と規程、業務フロー、現行画面やExcel、研究課題・費目・会計コードのマスタ、利用者と権限、承認ルート、既存システムの連携仕様、移行対象データ、希望する導入時期をそろえます。すべての仕様を発注者だけで完成させる必要はありませんが、解決したい課題、対象範囲、優先順位、必須の非機能要件は決めます。特に「残高をいつ時点で表示するか」「証憑を何年、どの形式で保存するか」「誰の承認が必要か」は見積差が出やすいため、曖昧にしないことが重要です。

候補の性格が異なる3社前後に同じRFPを渡すと、価格だけでなく、標準機能で対応する範囲、追加開発の考え方、移行・保守の体制を比較しやすくなります。研究費専用型、大学財務・ERP型、受託SI型などを混ぜる場合は、評価表に「得意な業務」「対応できない範囲」「連携方式」「契約終了時のデータ引き渡し」を入れます。提案書の見栄えより、要件への質問の質、リスクの説明、担当予定者の経験、導入後の支援体制を重視します。

まとめ

研究費管理システムの発注では、まず科研費、受託研究費、共同研究費、学内予算を研究課題・研究者・費目・年度単位で整理し、採択から監査・報告までの業務範囲を決めます。そのうえで、クラウド・パッケージ・追加開発・スクラッチの役割を分け、標準化できる部分と機関固有の部分を見極めます。

RFPには、現行業務、資金ごとのルール、研究課題と費目のマスタ、承認・差戻し、証憑と監査ログ、会計・購買・認証との連携、DMPや研究セキュリティ、移行対象、導入後の保守を含めます。契約は、要件が変わりやすい工程を準委任、成果物を確定できる工程を請負とするなど、工程の性質に合わせて分けます。見積は初期費用の総額ではなく、移行、教育、月額利用料、保守、制度改正対応まで含めたTCOで比較します。

全学導入を急ぐ前に、1部局や特定の研究費で、残高照会、購入申請、証憑添付、承認、会計連携を試す方法があります。研究者・秘書・事務局の入力時間、差戻し率、問い合わせ数、月次集計の工数を測定し、標準機能で解決できない課題を次の開発へ反映します。発注者、現場利用者、情報システム、経理、研究推進部門が同じ評価表で候補会社を比較できれば、導入後に使われ続ける研究費管理システムへ近づけます。

▼全体ガイドの記事
・研究費管理システム開発の完全ガイド

会社紹介

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

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

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

株式会社riplaの会社HPはこちら

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

執筆者プロフィール

張田谷凌央

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