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

研究業績管理システムの発注・外注は、単に論文や著書を登録する画面を買うことではなく、研究情報を申請、評価、情報公開、IRへ再利用できるデータ基盤を整えるプロジェクトです。成功しやすい進め方は、発注形態を先に決めるのではなく、研究者・事務・評価室・図書館・広報の業務とデータの正を整理し、その結果に合わせてSaaS、パッケージ、個別開発を選ぶ方法です。

本記事では、大学・短大・高専・研究所が研究業績管理システムを発注・外注・委託するときの進め方を、発注形態の選択、RFPと要件整理、契約形態、費用相場、委託先選定、見積比較、稼働後の定着まで順番に解説します。researchmap連携や公開範囲の設計など、研究業績管理ならではの論点も、発注前に確認できる形でまとめています。

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

研究業績管理システムを外注する前に知るべき全体像

研究業績管理システムは、研究者のプロフィール、論文、著書、学会発表、特許、受賞、競争的資金、共同研究、教育・社会貢献などを一元管理し、必要な業務へ展開するWebシステムです。登録件数を増やすだけでは成果にならないため、発注時には「誰が、どのデータを、どの業務で、どの範囲まで使うか」を決めることが重要です。

導入目的を「研究者総覧の更新」だけに限定すると、申請書、教員評価、認証評価、科研費申請、大学公式サイト、英語サイト、研究力分析へデータを使い回す設計が抜けやすくなります。最初の打ち合わせでは、登録、確認、承認、公開、帳票出力、集計という一連の流れを業務図にし、今後追加したい研究費・研究課題・機関リポジトリ・研究データ管理との接続も別枠で整理します。

研究推進部門だけで仕様を決めると、情報システム部門が必要とする認証・ログ・バックアップ、図書館が必要とする文献情報、広報が必要とする公開画面、評価室が必要とする集計条件が後から追加されます。責任者を置き、研究者代表、学部事務、評価・IR、図書館、広報、情報システム、個人情報保護の担当者を早期に集めます。意思決定者とレビュー担当者をRFPに明記すると、委託先との認識ずれを抑えやすくなります。

発注形態はSaaS・パッケージ・スクラッチをどう選びますか？

発注形態の選択は、初期費用の安さだけでなく、機関固有の帳票、既存データ、認証、公開サイト、運用担当者の体制で判断します。標準機能が業務に合う機関はSaaSやクラウドパッケージが向き、評価・IRや学内基幹との統合が中心なら追加開発やスクラッチを比較します。候補を一つに絞る前に、同じ要件を複数の方式で見積もると、価格と将来の自由度を比べやすくなります。

SaaSはサーバー構築や基盤のアップデートを自機関で抱えにくく、短い期間で標準機能を使い始めやすい方式です。researchmapなどの外部データ連携、プロフィール、業績登録、公開ページ、基本帳票が要件に合えば、導入の初期負担を抑えられます。一方で、独自の評価項目や複雑な承認、他システムへの細かな出力が必要な場合は、標準外の追加費用、API制限、データのエクスポート条件を確認します。

パッケージやクラウド型の業務システムは、研究業績の分類、Excel一括登録、評価モジュール、様式出力、公開・非公開設定など、大学で繰り返し使われる機能を土台にできます。標準機能と追加設定の境界が明確になりやすく、導入実績や運用ノウハウも確認しやすい点が強みです。ただし、導入実績の数だけで判断せず、現在の製品バージョン、researchmapの仕様変更への対応、カスタマイズの保守範囲を確認します。

スクラッチ開発は、学内認証、研究費、研究課題、機関リポジトリ、BI、公開サイトを一つの業務設計でつなげたい場合に選択肢となります。自由度が高い反面、要件が広がるほど移行、テスト、教育、保守の負担が増えます。最初から全機能を完成させるのではなく、業績登録・確認・公開・主要帳票を第1段階にし、評価・IR・研究データ連携を第2段階に分けると、利用定着を確認しながら投資できます。

RFPと要件整理では何を決めておきますか？

RFPは、委託先に機能一覧を渡すだけの書類ではありません。目的、対象範囲、現状の課題、利用者、データ量、連携先、非機能要件、納期、予算の考え方、提案書に求める回答をそろえ、同じ条件で提案と見積を比較するための文書です。要件が未確定な部分は「提案を求める項目」として明示し、想定・前提・除外範囲を各社に書かせます。

研究者には入力候補の確認と最小限の修正、事務には一括登録と差し戻し、評価室には年度別集計、広報には承認済み情報の公開、図書館には文献情報の補正、情報システム部門には権限と監査ログが必要です。これらを利用者別に整理し、業務停止につながるMUSTと、将来的に追加するWANTに分けます。画面の好みよりも、入力回数、確認者、差し戻し条件、出力様式を先に決めることが大切です。

業績種別、著者名、所属、年度、研究課題、科研費、DOI、ORCID、公開可否、承認状態、更新日などの項目をデータ辞書にします。特に重要なのが、researchmapを正とするのか、学内データベースを正とするのか、項目ごとに分けるのかという判断です。researchmapには研究者情報や業績を一括で扱う機能があり、機関向けの取得・更新API設計書も公開されていますが、外部データを自動で反映する場合も、同姓同名や所属違いによる誤帰属を本人が確認する工程が必要です（出典: researchmap「はじめてガイド」および「researchmap.v2 取得・更新API設計書」、2025年公開版）。

RFPには、researchmap、ORCID、CiNii Articles、J-GLOBAL、PubMed、機関リポジトリ、学内認証、大学公式サイト、BIとの接続可否を記載します。さらに、初期データの件数、Excelや旧システムの形式、名寄せと重複排除、移行リハーサル、バックアップ、障害時の再処理、API仕様変更の費用負担を質問します。セキュリティでは、公開・学内限定・事務限定の区分、SSOやMFA、最小権限、操作ログ、暗号化、脆弱性対応、保存場所、再委託先、インシデント連絡、契約終了時の全データ返却を明記します。

研究業績管理システムの発注・外注の進め方

発注後の成否は、委託先の技術力だけでなく、発注者が業務上の判断を止めずに進められるかで変わります。要件整理、提案比較、契約、設計、移行、テスト、研修、稼働後の改善を一つの計画にし、各工程の成果物と承認者を定義します。大規模な機関ほど、代表部局でのパイロットを挟み、全学展開の前にデータ品質と入力定着を確認します。

企画フェーズでは、現行のExcel、Word、researchmap、学内DB、Web公開ページ、評価用帳票を集め、重複入力と手作業の箇所を可視化します。次に、入力者、確認者、承認者、公開責任者を業績種別ごとに決めます。例えば論文は本人が候補を確認し、図書館や事務が書誌を補正し、所属部局が公開可否を承認するなど、組織の実情に合った流れをRFPと要件定義書に残します。

設計では画面だけでなく、データモデル、履歴、承認状態、公開範囲、権限、連携方向、エラー時の再処理を確認します。データ移行は、項目対応表の作成、サンプル変換、名寄せ、重複排除、移行リハーサル、件数と内容の照合という順番で進めます。香川大学の教員業績管理システム開発事例でも、外部情報や学内情報の取り込みと業績データの可視化が重要なテーマになっており、登録画面だけで発注しないことの参考になります（出典: 香川大学「香川大学における教員業績管理システムの開発と業績データ可視化の取り組み」、AXIES 2023）。

テストでは、機能が動くかだけでなく、実在データに近いサンプルで名寄せ、文字種、年度、著者順、公開可否、帳票の差分を確認します。研究者、事務、評価室、広報、図書館がそれぞれ受入テストを実施し、合格条件と未解決事項を記録します。稼働前にはデータ移行の最終リハーサル、権限テスト、バックアップからの復元確認、問い合わせ窓口の設置を行い、研修では「何を入力するか」だけでなく「どの候補を承認するか」まで説明します。

契約形態は請負・準委任・段階契約を比較します

研究業績管理システムは、既存データの品質や部局ごとの運用差が見えるまで、完成仕様を確定しにくい案件です。そのため、開発範囲の確定度と発注者側の意思決定速度を見ながら、請負、準委任、段階契約を使い分けます。契約書だけでなく、要件定義書、仕様変更の手順、検収条件、知的財産、データ返却、保守の範囲を一体で確認します。

請負契約は、合意した仕様に基づき、システムや移行成果物を完成させて検収する場合に向いています。業績登録、基本権限、指定帳票など、成果物と合格条件を具体化できる範囲では、予算と納期を管理しやすくなります。一方で、検討中の業務を契約後に追加すると変更契約になりやすいため、RFPの前提条件、対象外機能、追加開発の単価、納期への影響を契約前に確認します。

準委任契約は、専門家の作業やプロジェクト支援に対して時間・体制を確保する形です。現行調査、データ辞書作成、RFP作成支援、プロトタイプ、業務整理、ベンダー調整のように、成果の形を最初から一つに決めにくい工程で使いやすい契約です。作業時間の上限、担当者、会議体、成果物、報告方法、品質確認の責任分界を定めないと、作業したことだけが納品条件になるため注意します。

要件が固まっていない場合は、要件定義を準委任または短期の調査契約で行い、その成果をもとに開発・移行を請負で発注する段階契約が現実的です。最初の段階で業務フロー、データ辞書、優先順位、概算工数、リスク、次段階の検収条件を確定させます。発注者が契約を分ける場合も、同じ委託先に固定するのか、要件定義後に再提案を受けるのかを公平性と引き継ぎコストの両面から決めます。

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

研究業績管理システムは、大学規模、研究者数、業績データの件数と汚れ、連携先、帳票、公開サイト、評価・IR、認証、移行範囲で金額が大きく変わります。公開価格を出すベンダーが少ないため、以下はリサーチノートとNotebookLM Q&Aに整理された基幹システム相場を、研究業績管理の機能範囲に当てはめた編集部推定です。確定価格ではなく、RFPで同じ条件の見積を取るための予算検討レンジとして使います。

標準設定中心の既存SaaSやライトパックなら、初期費用はおおむね100万〜500万円が検討レンジです。研究業績パッケージにresearchmap・API連携、データ移行、帳票、公開サイトを組み合わせる場合は、500万〜1,500万円程度が一つの目安です。複数部局をまたぎ、評価・IR、機関リポジトリ、研究費連携まで含める場合は1,500万〜4,000万円程度、スクラッチで学内基盤や複数DBを統合する場合は2,000万〜6,000万円超も想定します。これらは機能範囲を前提にした推定レンジであり、研究ノート記載の基幹システム相場に基づくもので、特定ベンダーの価格を意味しません（出典: NotebookLM Q&A「ERP・経営管理」およびリサーチノート、2026年整理）。

見積比較では、要件定義、画面・権限設計、API連携、データクレンジング、移行、帳票、公開サイト、テスト、研修、プロジェクト管理を分けて確認します。エンジニア単価はNotebookLM Q&Aの一般的な基幹システム相場では月80万〜120万円程度と整理されていますが、単価だけでは品質や工数を比較できません。誰が何か月、どの成果物を作る見積かを確認し、作業項目が一式表記になっている場合は内訳の再提出を求めます。

運用費には、SaaS利用料、クラウド基盤、保守、問い合わせ、バックアップ、監視、脆弱性対応、API仕様変更、証明書、公開サイト、追加帳票、研修が含まれます。リサーチノートの目安では、標準導入のランニング費用は月5万〜30万円程度、連携や個別運用を含む場合は年100万〜500万円程度、保守は初期費用の年5〜15％程度が目安です。Microsoft 365上で稼働する教員業績管理システムの2025年発表事例のように、既存基盤を使う方式もありますが、必要なライセンスと管理者作業が別に発生しないかを確認します（出典: 株式会社メディアフュージョン「Microsoft365上で稼働するサーバーレス型教員業績管理システムをリリース」、2025年）。

委託先の選定と見積比較で見るべきポイント

委託先は、会社規模や知名度だけでなく、研究業績管理の業務理解と、データ移行・運用まで担う体制で選びます。候補には、researchmap連携を含む大学向けSaaS、研究業績・教員評価のパッケージ、Microsoft 365など既存基盤を活用するサービス、大学固有の業務を統合するSI会社があります。同じデモを見て判断するだけでなく、実際のサンプルデータと自機関の帳票を使った提案を依頼します。

導入実績を聞くときは、「大学に導入したことがあるか」だけで終わらせません。研究者数、部局数、業績件数、公開サイトの有無、researchmapや学内認証との連携、評価・IRの利用状況、稼働年数、直近の保守体制を質問します。可能であれば、同規模の導入先に、移行の負担、教員の入力定着、問い合わせ対応、追加費用、契約終了時のデータ取り出しについて確認します。過去の実績が現在も提供・保守されているかも重要です。

見積比較表には、機能、対応範囲、データ件数、研究者数、移行方法、連携方式、テスト回数、研修回数、納期、体制、保守時間、障害対応、追加開発の単価を並べます。最安の提案が、移行・研修・API対応を除外しているだけの場合もあるため、初期費用、初年度総額、3年程度の運用総額を同じ前提で確認します。費用の差が大きい項目には、理由と代替案を説明してもらい、削る場合に失われる業務価値も記録します。

「AIで自動登録すれば確認不要」「既存データは簡単に移せる」「標準機能で全て対応できる」といった説明を、検証条件なしで受け入れないようにします。外部DBの自動取込では誤帰属や重複が起こり得るため、候補提示、本人確認、事務承認、修正履歴、再処理の設計を提案書で確認します。また、障害時に誰が復旧するのか、API変更時に誰が改修費を負担するのか、契約終了時にどの形式でデータを返すのかを曖昧にしません。

セキュリティと稼働後の運用を発注条件に含めます

研究業績には、氏名や所属などの公開情報だけでなく、未公開業績、評価情報、共同研究者、研究費、研究課題が含まれる場合があります。公開する情報と学内だけで扱う情報を同じ権限で管理せず、項目単位の公開可否、承認状態、所属・職位による権限、操作ログ、バックアップ、暗号化を発注条件にします。大学が公表すべき教育研究活動には、教員数、学位、業績などが含まれますが、法令上の公開義務がある情報と、個人情報・未公開情報の取り扱いは切り分けが必要です（出典: 文部科学省「大学の教育研究活動に関する情報提供」、学校教育法施行規則第172条の2）。

個人情報保護委員会は、学術研究機関等についても、利用目的の特定、適正な取得、データ内容の正確性、安全管理措置などの規律が適用されると説明しています。学術研究を理由に安全管理を省略するのではなく、データ分類表、利用目的、閲覧・編集・公開権限、保存期間、削除方法、委託先の再委託、海外保管の有無を整理します（出典: 個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン（通則編）」、2026年確認）。

稼働後は、年度更新や評価時期に問い合わせが増えるため、操作マニュアル、FAQ、説明会、部局ごとの相談窓口、データ品質を確認する定例会を用意します。入力率だけでなく、候補の確認率、重複件数、公開までの日数、帳票作成時間、問い合わせ内容を指標にすると改善点を見つけやすくなります。API連携は一度作って終わりではないため、仕様変更の検知、失敗ログ、再実行、手動確認の手順を保守契約に含めます。

よくある質問（FAQ）

最後に、研究業績管理システムを発注する担当者から寄せられやすい質問に回答します。費用や期間は機関の規模と要件で変わるため、回答は目安として読み、自機関のデータと業務を使った提案で確認します。

標準的な業績登録、researchmap連携、公開、帳票を早く始めたいならSaaSやパッケージが向いています。既存の研究費・評価・IR・機関リポジトリまで一体で統合し、独自の業務を長期運用する必要がある場合は、追加開発やスクラッチを比較します。最初から全機能を個別開発するのではなく、必須業務を標準機能で始める段階導入も有力です。

標準設定中心なら100万〜500万円、パッケージに連携・移行・帳票・公開を加えるなら500万〜1,500万円、評価・IRや複数DB連携まで含むなら1,500万〜4,000万円程度が検討レンジです。スクラッチ統合では2,000万〜6,000万円超も想定しますが、いずれも研究ノートと一般的な基幹システム相場から作成した推定です。ライセンス、移行、研修、保守、API変更対応を含む初年度総額で比較します。

相談自体は問題ありませんが、複数社の提案と見積を比較するなら、簡易版でもRFPを作ることをおすすめします。目的、対象利用者、現行データ、連携先、必須機能、公開範囲、セキュリティ、納期、予算の考え方、提案に求める回答をそろえるだけでも、提案の前提が明確になります。要件整理を支援会社へ委託する場合は、RFP作成支援の成果物と、最終的な発注者の意思決定責任を契約に明記します。

既存SaaSを標準設定で導入する場合は、要件整理から稼働まで2〜4か月程度、パッケージに移行・連携・帳票を加える場合は4〜8か月程度が目安です。複数部局の評価・IR・機関リポジトリ連携やスクラッチ開発では6〜12か月以上も想定します。データの名寄せと受入テストに時間をかけるほど、稼働後の修正を減らしやすくなります。

まとめ

研究業績管理システムの発注・外注では、最初にSaaSかスクラッチかを決めるのではなく、研究者、事務、評価室、図書館、広報、情報システムの業務とデータの正を整理します。そのうえで、researchmapや外部DBとの連携、本人確認、公開・非公開の分離、帳票、移行、認証、ログ、保守をRFPに記載し、複数社から同じ前提の提案を受けます。

費用は、標準導入なら100万〜500万円、連携や移行を含むパッケージなら500万〜1,500万円、評価・IRまで含む統合では1,500万〜4,000万円程度が推定レンジです。契約は、仕様が明確な範囲を請負、要件整理や伴走を準委任、全体を要件定義と開発に分ける段階契約として比較します。安さだけでなく、前提条件、成果物、保守、データ返却、仕様変更の責任分界まで確認します。

次の一歩は、現在使っているExcel・Word・researchmap・学内DB・帳票を集め、重複入力、誤帰属、承認、公開、年度更新の課題を一覧化することです。代表部局で小さく検証し、入力定着とデータ品質を確認してから全学へ広げれば、研究業績管理システムを継続的に使われる情報基盤へ育てやすくなります。

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

会社紹介

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

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

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

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

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

執筆者プロフィール

張田谷凌央

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