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

研究業績管理システムの発注は、まず業務とデータを整理し、RFPで要件をそろえたうえで、提案と見積を比べながら段階的に導入する流れで進めます。

この流れで進めると、利用定着につながります。全体像は研究業績管理システム開発の完全ガイドもご覧ください。

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

・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。

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

研究業績管理システムは、研究者のプロフィール、論文、著書を一元管理するWebシステムです。管理の範囲は、次の項目にも広がります。

• 学会発表・特許
• 受賞
• 競争的資金
• 共同研究
• 教育・社会貢献

登録件数が増えても、それを使う業務がなければ成果にはなりません。そこで、発注時に誰がどのデータをどの業務で使うかを、利用範囲とあわせて決めておきます。

研究者名鑑を超えたデータ基盤としての発注

研究者総覧の更新に加えて、申請書や教員評価、科研費申請へも再利用する前提で発注します。再利用の範囲は、次の項目にも広がります。

• 認証評価
• 大学公式・英語サイト
• 研究力分析
• IR

再利用を前提にすると、業務の流れと将来の接続もあわせて整理しておく必要があります。

• 業務の流れ：登録、確認、承認、公開、帳票出力、集計を一覧にして、どの段階で誰が関わるかを見えるようにします。
• 将来の接続：研究費、研究課題、機関リポジトリ、研究データ管理とのつながり

発注者側の先行的な合意形成

研究推進部門だけで仕様を決めてしまうと、他部門の要件が後から加わり、関係者の認識がずれやすくなります。

• 情報システム：認証、ログ、バックアップの扱い
• 図書館・広報：文献情報と公開画面の扱い
• 評価室・研究者代表：集計条件と入力負担の確認

また、学部事務や個人情報保護の担当者も早い段階で集め、それぞれに責任者を置きます。意思決定者とレビュー担当者をRFPに明記しておくと、委託先との認識ずれを抑えやすくなります。

発注形態の選び方（SaaS・パッケージ・スクラッチ）

発注形態は、初期費用だけでなく、機関固有の帳票、既存データ、認証、公開サイト、運用体制を見て選びます。

標準機能で業務が足りるならSaaSやクラウドパッケージを、評価・IRや学内基幹との統合が中心なら追加開発やスクラッチを比較します。そのうえで、同じ要件で複数方式の見積を取ると、価格と将来の自由度を比べられます。

標準機能で早く始めたい機関に向くSaaS

SaaSは、サーバー構築や基盤の更新を自機関で抱えにくく、標準機能を短期間で使い始めやすい方式です。

• 適合性：researchmap連携、プロフィール、業績登録、公開ページ、基本帳票の対応範囲
• 追加条件：標準外費用、API制限、データのエクスポート条件

独自の評価項目や複雑な承認、細かな外部出力が必要な機関では、追加費用や制限が要件に合うかを確かめる必要があります。

大学固有の運用を追加しやすいパッケージとクラウド

パッケージやクラウド型のシステムは、大学で繰り返し使われる機能を土台にできます。

• 標準機能：業績分類・Excel一括登録・評価・様式出力・公開設定の標準対応
• 保守範囲：製品版、researchmap仕様変更、カスタマイズ保守の扱い

標準機能と追加設定の境界が明確になりやすく、導入実績や運用ノウハウも確かめられます。ただし、実績数だけで決めず、現行製品と保守の状況も見ておきます。

統合範囲を絞った段階導入を前提とするスクラッチ

スクラッチ開発は、学内認証や研究費、研究課題などを一つの業務設計でつなぐ場合の選択肢です。さらに、機関リポジトリやBI、公開サイトまで含めてつなぐ場合も、この選択肢に入ります。

自由度は高い一方で、要件が広がるほど、移行やテストの負担に加えて、教育や保守の負担も増えます。

第1段階では業績登録から公開までと主要帳票を、第2段階では評価・IR・研究データ連携を扱うように分けると、定着を確かめながら投資できます。

RFPと要件整理で決めておく事項

RFPは、提案と見積を同じ条件で比べるための書類です。そのため、まず目的と範囲、課題、利用者を示します。

次に、データ量、連携先、非機能要件を書きます。納期と予算の考え方、回答事項もそろえます。

未確定の要件は「提案を求める項目」として示します。そのうえで、想定や前提、除外範囲を各社に書いてもらいます。

利用者別の業務フローとMUST・WANTの分類

まず利用者ごとの業務を整理し、停止できない必須要件（MUST）と、将来追加する要件（WANT）に分けます。研究者、事務・評価室、広報・図書館、情報システムは、受け持つ作業がそれぞれ異なります。

• 研究者：入力候補の確認と最小限の修正
• 事務・評価室：一括登録、差し戻し、年度別集計の実施
• 広報・図書館：承認情報の公開と文献情報の補正
• 情報システム：権限と監査ログの管理

画面の好みより先に、入力回数と確認者を決めます。差し戻し条件と出力様式も、画面より前に決めておきます。

データ辞書と正となる情報源

データ辞書には、項目と正となる情報源、本人確認の方法を書いておきます。

• 管理項目：業績種別・著者名・所属・年度・研究課題・科研費・DOI・ORCID・公開可否・承認状態・更新日
• 正となる情報源：researchmapか学内データベースか、項目別に分けるかの判断
• 本人確認：自動反映する外部データの内容を、本人が見て確かめる

researchmapには研究者情報や業績を一括で扱う機能があるほか、機関向けの取得・更新API設計書も公開されています（出典: researchmap「はじめてガイド」および「researchmap.v2 取得・更新API設計書」、2025年公開版）。

自動反映では、同姓同名や所属違いによる誤帰属が起こり得るため、本人確認の項目が欠かせません。

RFPの必須回答（連携・セキュリティ・移行）

連携先と初期データ、移行手順をRFPに記載します。セキュリティ条件も記載し、各社に対応可否と費用を回答してもらいます。その範囲は、4つの項目ごとに示します。

• 連携先：researchmap・ORCID・CiNii Articles・J-GLOBAL・PubMedとの接続範囲
• 学内接続：機関リポジトリ・学内認証・公式サイト・BIとの連携方式
• 移行：データ件数、Excel・旧システム形式、名寄せ、重複排除、リハーサルの有無
• 安全管理：公開区分、SSO・MFA、最小権限、ログ、暗号化、脆弱性対応の定め

さらに、バックアップや障害時の再処理、API変更費用を確かめます。保存場所や再委託、インシデント連絡、契約終了時の全データ返却も確認します。

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

発注後の成否は、委託先の技術力だけでなく、発注者が業務上の判断を止めずに進められるかで決まります。

工程は、要件整理と提案比較から始め、契約、設計、移行を経て、テストと研修へ進みます。また、稼働後は改善まで計画します。

各工程には、成果物と承認者を定めます。特に、大規模な機関ほど、全学に広げる前に代表部局でパイロットを行い、データ品質と入力定着を確かめます。

企画・要件定義での業務の統一

まず、重複入力や手作業を洗い出します。業績種別ごとに、どこまでを誰が担うかも整理しておきます。

• 現行資料：Excel・Word・researchmap・学内DB・公開ページ・評価帳票の収集
• 担当者：入力者・確認者・承認者・公開責任者の配置

論文では、本人が候補を確認し、図書館や事務が書誌を補正し、所属部局が公開可否を承認するなど、実情に合う流れをRFPと要件定義書に残します。

設計・開発での移行と連携の先行検証

設計では画面に加えて、データモデルや履歴、承認状態を確かめます。さらに、公開範囲や権限、連携方向、エラー時の再処理も見ておきます。

1. 項目対応表を作り、サンプルデータを変換します。
2. 名寄せと重複排除を行い、移行リハーサルに進みます。
3. 移行後の件数と内容の照合

香川大学の開発事例でも、外部・学内情報の取り込みと業績データの可視化が重要なテーマです。さらに、登録画面だけで終わらせないための参考になります（出典: 香川大学「香川大学における教員業績管理システムの開発と業績データ可視化の取り組み」、AXIES 2023）。

テスト・研修・リリースによる現場での利用準備

機能確認に加えて、実データに近いサンプルを使い、名寄せや文字種、年度を確かめます。さらに、著者順や公開可否、帳票の差分も見ておきます。

• 受入テスト：研究者・事務・評価室・広報・図書館による、合格条件と未解決事項の記録
• 稼働準備：データ移行の最終リハーサル・権限テスト・バックアップ復元・問い合わせ窓口の確認
• 研修：入力方法に加えて、候補を承認する基準の説明

契約形態の比較（請負・準委任・段階契約）

既存データや部局ごとの運用の違いが見えるまで、完成仕様を確定しにくい案件です。そのため、開発範囲の確定度と発注者の意思決定の速さに応じて契約形態を選びます。

契約書と要件定義書を一体で確かめます。さらに、仕様変更や検収条件、知的財産、データ返却、保守範囲も、その中に含めて確認します。

成果物と仕様が明確な範囲に使う請負契約

請負契約は、合意した仕様に基づくシステムや移行成果物を完成させ、検収する場合に向いています。

• 適する範囲：業績登録、基本権限、指定帳票など、合格条件を具体化できる作業
• 契約前の確認：前提、対象外機能、追加単価、納期への影響の取り決め

成果物と合格条件が明確な範囲は、予算と納期を管理しやすくなります。ただし、契約後に追加要件が出ると変更契約になりやすいため、範囲を事前に確かめておきます。

要件整理や伴走支援での準委任契約

準委任契約は、専門家の作業やプロジェクト支援に対して、時間と体制を確保する形です。

• 利用する工程：現行調査・データ辞書・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年）。

既存基盤を使う場合でも、必要なライセンスや管理者作業が別に発生しないかを確かめます。

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

委託先は、会社規模や知名度だけでなく、業務理解とデータ移行・運用の体制で選びます。

• 大学向けSaaS：researchmap連携などの標準サービス
• 業務パッケージ：研究業績と教員評価の機能
• 既存基盤・SI：Microsoft 365の活用や、大学固有業務との統合

デモだけで決めず、実際のサンプルデータと自機関の帳票を使った提案を依頼します。

導入実績での機関規模と運用の現在性の確認

導入実績は、大学への導入経験があるかだけでなく、機関規模や運用状況が自機関に近いかを見ます。

• 機関・連携：研究者数・部局数・業績件数・公開サイト・researchmap・認証・評価・IRの各条件
• 稼働・保守：導入からの年数と直近の保守体制、現在も提供される製品かどうか

可能であれば同規模の導入先に、移行負担や入力定着、問い合わせ、追加費用を聞きます。さらに、契約終了時のデータ取得も確かめておきます。

前提条件と成果物をそろえた見積比較

見積比較表は、範囲と前提条件をそろえて作ります。

• 対象：機能・対応範囲・データ件数・研究者数・移行と連携の方式
• 体制・品質：テストと研修の回数、納期、保守時間、障害対応の取り決め
• 費用：追加開発単価、初期費用、初年度総額、3年程度の運用総額

最安の提案は、移行や研修、API対応を除外している場合もあります。そのため、差が大きい項目は理由と代替案を尋ね、削る場合に失う業務価値も記録します。

避けたい提案のリスクと責任の所在

「AIで自動登録すれば確認不要」「既存データは簡単に移せる」「標準機能で全て対応できる」といった説明は、検証条件を確かめる必要があります。

• 自動取込：候補提示・本人確認・事務承認・修正履歴・再処理の設計
• 責任分界：障害復旧・API改修費・終了時のデータ形式の取り決め

外部DBの取り込みでは、誤帰属や重複が起こり得ます。そのため、提案書で対応設計を確かめ、復旧や費用負担を曖昧なままにしません。

セキュリティと稼働後の運用の発注条件

研究業績には、氏名や所属のほか、未公開業績や評価情報が含まれる場合があります。さらに、共同研究者や研究費、研究課題も扱うことがあります。

公開情報と学内情報を同じ権限で扱わないよう、項目ごとの公開可否と承認、所属・職位別の権限を分けて定めます。また、操作ログやバックアップ、暗号化も発注条件に入れます。

また、公表対象には教員数や学位、業績などが含まれます。法令上の公開義務と、個人情報や未公開情報の扱いは分けて考えます（出典: 文部科学省「大学の教育研究活動に関する情報提供」、学校教育法施行規則第172条の2）。

個人情報と研究情報の公開・学内・事務への分離

個人情報保護委員会は、学術研究機関等にも、利用目的の特定や適正な取得、データの正確性、安全管理措置などが適用されると説明しています。

学術研究であることを理由に安全管理を省略しないため、データ分類や利用目的、閲覧・編集・公開権限を整理します。保存期間や削除方法も、あわせて決めておきます。

個人情報保護委員会のガイドライン（「個人情報の保護に関する法律についてのガイドライン（通則編）」、2026年確認）も照らし合わせます。さらに、委託先による再委託や海外保管の有無も確認しておきます。

運用計画への入力定着とAPI変更対応の組み込み

年度更新や評価時期は問い合わせが増えるため、マニュアルやFAQ、説明会を用意します。また、部局窓口とデータ品質の定例確認も、あわせて設けます。

入力率だけでなく、複数の指標で見ると改善点を見つけやすくなります。見る指標と保守の範囲は、2つに分けて考えます。

• 定着指標：候補確認率、重複件数、公開日数、帳票作成時間、問い合わせの状況
• API保守：連携は作って終わりにせず、仕様変更の検知や失敗ログ、再実行、手動確認を契約に含めます。

よくある質問（FAQ）

費用や期間は、機関の規模と要件で変わります。ここに示す回答は目安として扱い、自機関のデータと業務を使った提案で確認します。

SaaSとスクラッチの選び方

標準的な業績登録やresearchmap連携、公開、帳票を早く始めたいなら、SaaSやパッケージが向いています。

一方で、既存の研究費や評価、IR、機関リポジトリまで一体で統合し、独自業務を長期で運用する場合は、追加開発やスクラッチを比較します。最初から全機能を個別に開発せず、必須業務を標準機能で始める段階導入も有力な選択肢です。

発注費用の目安

次に示す金額は、いずれも研究ノートと一般的な基幹システム相場から作成した推定です。

• 標準設定：中心の場合は100万〜500万円です。
• パッケージ：researchmap・API連携、移行、帳票、公開サイトを加える場合の500万〜1,500万円程度
• 評価・IRや複数DB連携まで含む場合：1,500万〜4,000万円程度
• スクラッチ統合：2,000万〜6,000万円超も想定します。

ライセンス・移行・研修・保守・API変更対応を含む初年度総額で比べます。

RFPを作らずに相談する場合の注意点

相談は可能ですが、複数社を比べるには簡易RFPが有効です。目的や対象者、現行データ、連携先を示します。

必須機能や公開範囲、セキュリティを記します。納期と予算、回答事項もそろえます。

作成を支援会社へ委託する場合は、成果物と、発注者が最終的に決める責任を契約に明記します。

導入期間の目安

既存SaaSの要件整理から稼働までは、標準設定で2〜4か月程度が目安です。一方で、移行や連携、帳票を加えるパッケージでは、4〜8か月程度とみてください。

複数部局の評価・IR・機関リポジトリ連携や、スクラッチ開発では、6〜12か月以上も想定します。名寄せや受入テストに時間をかけるほど、稼働後の修正を減らしやすくなります。

まとめ

発注や外注では、まず業務とデータの正を整理します。研究者や事務、評価室の業務に加えて、図書館、広報、情報システムの業務も対象にします。方式は、そのあとに比べます。

researchmapや外部DB連携、本人確認、公開区分をRFPに記載します。帳票、移行、認証、ログ、保守も加え、同じ前提で複数社から提案を受けます。

発注前に決める業務・データ・契約

推定レンジは、標準導入で100万〜500万円、連携・移行を含むパッケージで500万〜1,500万円、評価・IRを含む統合で1,500万〜4,000万円程度です。

仕様が明確な範囲は請負、要件整理や伴走は準委任、要件定義と開発を分ける段階契約として比べます。費用だけでなく、前提や成果物、保守、データ返却、変更時の責任まで確かめます。

現行データと代表部局の業務の洗い出し

Excel・Word・researchmap・学内DB・帳票を集めて、重複入力や誤帰属、承認、公開、年度更新の課題を洗い出します。代表部局で定着とデータ品質を確かめてから全学へ広げると、継続利用につながります。

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

▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック

会社紹介

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

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

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

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

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

執筆者プロフィール

張田谷凌央

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