研究業績管理システムの開発は、6フェーズで進めます。要件整理、選定、設計・開発の順に業務と製品の条件を固めていくと、二重入力や移行後の手戻りを抑えやすくなります。後半は、業務の流れを確かめてから稼働に入り、その後の定着までを見ていきます。
- テスト：実際の業務シナリオと移行データの確認
- 稼働：パイロット導入と切り戻し条件の設定
- 定着：入力負担とデータ品質の継続的な見直し
各フェーズの中身と費用の目安、見積もりの確認点は、後段で説明します。
▼全体ガイドの記事
・研究業績管理システム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
研究業績管理システム開発の全体像
研究業績管理システムは、研究者の業績を一つにまとめて管理するWebシステムです。論文、著書、特許などの業績に加え、プロフィールや所属、学会発表、受賞も扱います。また、競争的資金や共同研究、教育実績、社会貢献まで含めて、必要な業務へ再利用します。
開発では、登録できる機能の多さより、データの正と確認者、利用先を先に決めることが出発点です。
単なる研究者名鑑ではなく、研究情報の基盤という位置づけ
登録のあとの流れを書き出しておかないと、帳票や公開の範囲が後から問題になりやすくなります。要件定義では、誰が登録するかに加え、登録後にどの帳票・ページ・分析へ流すかを書き出します。情報は役割ごとに分けて、次のとおり扱いを決めます。
- 研究者：本人が業績を入力する。
- 図書館・研究推進部門：情報を補正する。
- 広報：公開する項目を受け持つ。
- 評価室：閲覧を絞った情報を扱う。
研究業績管理システムは、登録した業績を研究者総覧や大学公式サイトで公開する基盤です。そのうえで、教員評価や認証評価、科研費申請に再利用します。研究力分析や産学連携資料にも使えます。
researchmapの公式ガイドでは、論文、講演・口頭発表、書籍、産業財産権を管理・発信できる機能が案内されています。Works、社会貢献活動なども対象に含まれます（出典：researchmap「はじめてガイド」、2026年確認）。
役割を分けておくと、入力項目が増えすぎることや、権限設定の漏れを防ぎやすくなります。
管理するデータと業務範囲の切り分け
対象データと取込範囲は、先に分けて決めておきます。
- 基本情報：プロフィール、所属、職位、学位、経歴、専門分野、ORCID。
- 研究成果：論文、著書、学会発表、特許、受賞、作品。
- 研究活動：研究課題、競争的資金、共同研究、教育、社会貢献。
- 取込元：researchmap、ORCID、CiNii Articles、J-GLOBAL、PubMed、機関リポジトリ、人事・研究費。
- 取込管理：候補表示、本人確認、承認、差し戻し、再処理、操作ログ。
すべてを初期導入に含める必要はなく、将来の連携に備える項目はデータ辞書に残します。たとえば、識別子、年度、所属、公開可否などです。
自動取込では誤帰属や重複が起こり得ます。そのため、確認と修正の流れを機能として定義します。
標準機能と個別開発の境界
導入方式は、運用をどこまで任せるかと、独自の要件にどこまで合うかで比べます。
- 標準SaaS：短期間で始めやすく、サーバー運用やバックアップを任せやすい。
- パッケージ：独自項目・帳票・公開ページを追加しやすく、研究機関向けの知識も活用できる。
- スクラッチ：認証、研究費、評価、IR、機関リポジトリとの深い統合に向く。
- 比較軸：業務変更の範囲、既存接続、データ所有権、導入後の変更頻度。
- 段階導入：必須業務を標準機能で始め、品質安定後に評価・BI等へ広げる。
スクラッチ開発では、要件が膨らむことと保守の負担を、あらかじめ見込んでおく必要があります。一方で、段階導入は初期投資と現場の負担を抑えやすい進め方です。
研究業績管理システム開発の進め方・やり方
開発は6フェーズで進めます。要件整理、選定、設計・開発を先に固めると、後の工程での手戻りを減らせます。テスト、稼働、定着は、その後に続きます。フェーズごとに成果物と責任者、完了条件を決めておくと、次の段階へ進む判断がしやすくなります。
要件整理を省くと、データの正や公開範囲、帳票、移行対象が後から問題になります。その結果、費用と期間も膨らみやすくなります。
1. 要件整理：現行業務と目標の一覧
要件整理は、関係者への聞き取りと、現行業務の一覧づくりから始めます。
- 関係者：研究者、研究推進、評価室、図書館、広報、情報システム、学部事務、経営層。
- 資料・業務：紙、Excel、researchmap、旧システム、研究費、機関リポジトリ。
- MUST：業績登録、本人確認、公開、必須帳票、基本検索。
- SHOULD：外部DB取込、評価ワークフロー、英語公開。
- WANT：BI、AI候補提示、研究費・研究データ分析。
業務フローには、いつ誰が入力・確認し、どの出力に使うかを記録しておきます。研究者の入力だけで進めると、事務の名寄せや広報の公開確認、評価室の集計が抜けるおそれがあります。
この段階の成果物として、現行と将来の業務フローやデータ辞書をまとめます。そのほか、権限・帳票一覧、移行方針、KPI一覧も用意します。
2. 選定：同じ条件でのデータ連携・運用支援の比較
候補会社には、同じ業務フローと質問票を渡し、次の内容を実際に操作してもらいます。
- 登録から取込、重複確認、事務承認、公開、帳票出力までの一連の操作。
- 研究者IDやDOIによる名寄せと、誤帰属を元に戻せるかどうか。
- 差分・履歴の確認、英語公開、評価・IR、SSO・MFA、バックアップ。
比較表には、SaaS・パッケージ・個別開発の方式を並べ、researchmap・ORCID・機関リポジトリとの連携も比べます。導入実績や移行支援、研修、保守、解約時のデータ返却も、同じ条件で見ます。
見積もりに、初期設定、データクレンジング、帳票作成、API変更対応、問い合わせ窓口が含まれるかも確かめます。
3. 設計・開発：データの正と権限の実装
設計では、画面とデータ、運用ルールを具体的に決めます。すべてを一つのシステムに集めるのではなく、データごとに責任の所在を明確にします。
- 画面・業務：項目、マスター、ワークフロー、帳票、公開ページの設計。
- データの正：人事情報、researchmap、学内DBのどれを正とするかと、項目ごとの管理元と更新方向の記録。
- 公開範囲：公開、学内限定、事務限定、未公開の、項目・レコード単位での制御。
- 安全管理：最小権限、SSO、MFA、暗号化、ログ、バックアップ、削除の要件化。
入力候補の確認から公開までは、次の段階に分けて設計します。
- 外部DBから業績候補を取り込む。
- 研究者が内容を確認し、所属や著者順を補足・修正する。
- 事務承認を経て公開する。
段階を分ければ、自動取込の便利さとデータ品質を両立させられます。
扱う情報には、氏名や所属のほか、共同研究者や研究課題、競争的資金、評価情報も含まれます。さらに、公開前の論文情報も扱います。そのため、安全管理が必要になります。
個人情報保護法や学術研究機関向けの規律があっても、安全管理を省かない姿勢が大切です。
4. テスト：実際の業務シナリオと移行データの確認
機能ごとの検証が済んだら、匿名化した、または検証用のデータを使って受入シナリオを通します。
- 機能・運用：単体、結合、外部連携、権限、ログ、バックアップ。
- 業務シナリオ：登録、候補取込、本人確認、承認、総覧公開、評価帳票。
- データ例外：同姓同名、所属変更、退職、著者順、重複、CSV欠損。
- 異常系：公開停止、誤登録、API停止、認証失敗、権限外閲覧。
合格条件は、画面が開くことより、業務が最後まで完了することに置きます。エラーが起きたときの原因と対応、再処理の方法も確認します。結果には、再現条件、重要度、担当者、修正期限、再テスト結果を残します。
重大な未解決事項が残るときは、責任者の承認を得てから稼働判定へ進みます。
5. 稼働：パイロット導入と切り戻し条件の設定
いきなり全学で切り替えるより、代表部局や研究推進部門でパイロット導入を行うほうが安全です。
香川大学では、教員業績管理システムを2023年6月1日から実運用しています（出典：香川大学「香川大学における教員業績管理システムの開発と業績データ可視化の取り組み」、2023年）。
同大学では、researchmap連携や、直接入力・外部データ・学内データの取り込み、教員評価システムとの連携、業績データの可視化を組み合わせています。
香川大学の事例のように、登録だけでなく評価や可視化まで検証対象に含めます。移行と切替では、次の条件を決めておきます。
- 移行照合：研究者ID、所属、業績種別、発表年、DOI、公開可否、重複候補、過去履歴を照合。
- 移行範囲：過去データをすべて構造化するか、一定期間だけ移すか、旧システムを参照専用で残すか。
- 切替条件：本番前に移行リハーサルを行い、切戻し・開始延期の基準を合意。
重大な連携エラーやバックアップからの復旧失敗、権限の未確認、必須帳票の出力不能が見つかった場合は、切戻しか開始延期とします。
6. 定着：入力負担とデータ品質の継続的な見直し
稼働後も、研修や入力支援、利用状況の測定を続けます。
- 研修：候補確認、所属変更、公開停止、帳票出力、連携エラー報告を扱う。
- データ品質：未確認業績、重複率、本人確認にかかる期間を測る。
- 業務・支援：公開更新の遅れ、帳票作成時間、問い合わせ件数を追う。
職種別の短時間研修や場面別マニュアル、現場リーダー、問い合わせ窓口を用意します。実際の場面を使えば、研修の内容を行動に落とし込めます。
学習院大学の事例では、researchmapを使った業績公開により、二重登録を解消しました。
同じ事例では、SaaSを使って独自DBの構築・運用を不要にし、導入・運用コストの削減を図ったと紹介されています（出典：富士通「学校法人学習院 学習院大学様 導入事例」、2025年確認）。
教員に入力を求めるだけでなく、二重入力が減ったと実感できる運用にします。
研究業績管理システムの費用相場とコストの内訳
公開価格を示すベンダーは限られています。費用は、研究者数や部局数、移行量によって変わります。さらに、帳票や公開サイト、APIの範囲も費用を動かします。評価・IR、認証方式も要因になります。
ここに示すのは特定製品の定価ではなく、基幹システムの相場と機能範囲をもとにした、2026年時点の予算検討用のレンジです。正式な予算は、同じ条件のRFPで見積もりを取ってから確定します。
導入方式ごとの費用レンジ
費用と期間の目安は、導入方式と追加範囲によって変わります。
- SaaS・ライトパック：標準設定で初期100万〜500万円、月額5万〜30万円、2〜4か月。
- パッケージ：初期500万〜1,500万円、年額100万〜500万円、4〜8か月。
- 複数部局連携：初期1,500万〜4,000万円、6〜12か月。
- スクラッチ統合：初期2,000万〜6,000万円超、12か月以上の場合も。
パッケージの金額は、researchmapやAPI、帳票、公開サイト、権限設定、データ移行を加える場合の目安です。
複数部局連携は、教員評価やIR、機関リポジトリ、研究費、SSOなどを連携させる場合を指します。一方、スクラッチ統合は、学内基盤や複数のデータベースを統合する場合を指します。
ここに示す金額は、機能範囲と移行の難しさからの推定で、研究者数だけでは決まりません。
初期費用の内訳：要件・移行・連携・教育
見積書は「システム一式」とせず、初期作業ごとに区分してもらいます。
- 設計・開発：要件定義、管理、画面・データ設計、標準設定、個別開発。
- 移行・環境：API・CSV連携、クレンジング、移行、環境構築、安全設定。
- 稼働準備：テスト、操作研修、稼働支援。
作業量は、研究者マスターだけを移すのか、論文・著書・研究課題・評価履歴まで移すのかで変わります。
連携費用では、項目対応と仕様調整の中身を確認します。接続環境や認証、エラー通知・再送が含まれるかも見ます。接続試験、仕様変更対応も確かめます。
名寄せや重複排除を自動化しすぎると、誤帰属の確認負担が増えます。そのため、候補提示と本人確認も見積もりに含めておきます。
保守とランニングコストの5年間の総額
継続費用と契約条件を確かめ、5年間の総額で比べます。
- 利用・運用：利用料、ユーザー・拠点・容量の追加、保守、監視、バックアップ、問い合わせ。
- 変更対応：セキュリティパッチ、API仕様、帳票・制度の改修。
- 契約条件：無償更新、追加開発単価、復旧目標、データ返却費。
パッケージの保守は、初期費用の年5〜15％程度が目安になる場合もあります。ただし、契約によって範囲が異なります。月額が低くても、部局や研究者の追加、連携、帳票変更、出力、研修には費用がかかることがあります。
クラウドの場合は、保存場所や再委託先、バックアップ、障害通知、解約時の出力形式と期限を、RFPの段階で質問しておきます。
研究業績管理システムの見積もりを取る際のポイント
見積もりの精度は、依頼側が渡す情報がどれだけ具体的かで変わります。候補会社には、対象の機関や部局、研究者数、年間の登録件数、利用者区分、現行システムを示します。
Excelや紙の種類、連携先、公開ページを、同じ資料に記載します。移行や運用の範囲は費用と期間を左右するため、次の項目も書き添えます。
- 帳票：年度・部局・業績種別ごとの出力
- 移行対象：研究者マスターだけか、論文・著書・研究課題・評価履歴まで移すか
- 希望時期：導入方式ごとの期間の目安と照らして決める
- 運用体制：保守と問い合わせ窓口を、誰が受け持つか
- 予算上限：見積もりを比べる前に示す金額の枠
価格だけで比べると、必要な作業が抜けた安い見積もりを選んでしまうことがあります。
RFPに入れる業務・データ・連携・受入条件
RFPには、業務とデータ、連携、運用の条件を具体的に記載します。
- 業務・利用者：目的、対象・対象外、利用区分、権限、承認。
- 機能・データ：業績種別、必須項目、公開、帳票、検索、通知、保存期間。
- 連携・運用：外部連携、認証、ログ、バックアップ、障害対応。
各項目には、初期必須か、将来追加か、対象外かの優先度を付けます。
データ辞書では、項目名や型、必須か任意か、入力元、更新者、公開可否、履歴の要否を定義します。
受入条件は、担当者の感覚に頼らず、業務シナリオで書きます。
合格条件には、外部DBの論文候補の確認、重複検知、所属変更の反映を入れます。公開停止の即時反映と、年度・部局・業績種別ごとの帳票出力も含めます。さらに、権限のない人が評価情報を閲覧できないことも確かめます。
候補会社3社以上への同じ質問と比較
3社以上の候補会社に同じ質問をし、同じ評価表で比べます。
- 機能適合：標準機能、researchmap等の連携、移行、公開・英語表示、評価・IR。
- 導入実績：大学・研究所や、自機関に近い規模・部局構成の事例。
- 運用支援：保守状況と導入後の問い合わせ窓口。
契約前には、データ所有権や仕様書・連携定義書の引き渡し、解約時の返却、追加開発単価を確かめます。加えて、再委託先や保存場所、復旧目標、脆弱性対応、個人情報事故時の連絡も確かめます。
特に長期で使う場合は、5年後に別のサービスへ移れる出口条件も欠かせません。
公開と内部利用の境界
公開業務と、評価・研究費・未公開情報を扱う内部業務は、分けて設計します。
- 法令上の公開：学校教育法施行規則の情報公表規定に沿うかの確認。
- 公開設定：ページや項目単位の公開、事前承認、英語表示、検索設定。
- 内部管理：学内限定ページ、操作ログ、SSO・MFA、公開変更履歴。
- 例外対応：誤公開の停止や退職者ページの扱いを定める。
文部科学省は、学校教育法施行規則の改正について、2025年4月1日施行の情報公表に関する規定を案内しています（出典：文部科学省「学校教育法施行規則の一部を改正する省令」、2024年公布・2025年施行）。
公開前の業績や評価情報は、別の権限で守ります。また、誰がいつ設定を変えたかを追跡できる仕様にしておくと、稼働後のリスクを減らせます。
研究業績管理システム開発でよくある質問
導入前によく寄せられる質問に、順に答えます。費用や連携の可否だけでなく、研究者の入力負担や既存データ、公開範囲、導入時期も判断の材料にしてください。
researchmapを使っていても研究業績管理システムは必要ですか？
researchmapだけで研究者サイトや業績の管理・発信が完結する機関もあります。一方で、教員評価や学内承認、独自帳票が必要な場合は、別システムとの連携が有効です。次の業務が必要な場合も同じです。
- 研究費：研究費や競争的資金の情報と、業績を結びつけて扱う
- IR：研究力分析や産学連携資料に、業績データを使う
- 機関リポジトリ：論文などを取り込み、業績の候補として扱う
- 学内認証：SSO・MFAなどで、学内の利用者を確認する
researchmapと学内DBのどちらを正とするかは、項目ごとに更新元を定めて判断します。
研究業績管理システムの開発期間はどのくらいですか？
期間は導入方式によって異なり、全体の日程に影響する条件もあわせて確認します。
- 標準SaaS：設定中心なら2〜4か月。
- パッケージ：移行、API、帳票、公開サイトを加えて4〜8か月。
- 複数部局・スクラッチ：6〜12か月以上を見込む。
- 変動要因：意思決定、データ整備、接続試験、受入テスト。
過去のExcelや旧システムのデータは移行できますか？
移行はできますが、すべてのデータを同じ方法で移せるとは限りません。そのため、次の手順で範囲と確認方法を決めます。
- 利用目的に応じて移行範囲を決める。
- 研究者・所属マスターや主要業績は構造化し、古い添付資料や形式が揃わない履歴は参照用ファイルにする。
- 移行前にサンプルで名寄せ・重複排除を行う。
- 移行後、件数、研究者ID、年度、DOI、公開可否を旧データと照合する。
教員が入力してくれない場合はどうすればよいですか？
入力負担を減らし、利用を定着させるには、支援と効果測定を組み合わせます。
- 候補取込：外部DBから取り込み、研究者は確認と修正に集中する。
- 入力項目：必須・任意に分け、初期範囲は公開・評価に必要な項目へ絞る。
- 相談・測定：現場リーダーを窓口にし、入力時間、未確認数、二重入力回数を導入前後で測る。
入力の負担が減ったことを示すと、利用の定着につながりやすくなります。
まとめ
うまく進めるなら、機能一覧より先に、研究者・事務・評価室・図書館・広報の業務とデータの流れを整理します。
6フェーズごとに、成果物と完了条件を置きます。そのうえで、データの正をresearchmapと学内DBのどちらにするか、取込後の本人確認、公開情報と内部情報の区分も決めておきます。
発注前の最終確認項目
発注前には、対象業務と初期範囲、データの正・更新方向、移行対象・照合方法を確かめます。さらに、外部連携や認証、公開範囲は、発注前に定めておきます。そのうえで、稼働の判定と契約後の扱いも決めておきます。
- 受入テスト・稼働判定：業務が最後まで完了するかで合否を決める
- 保守と解約時の返却条件：データ返却費や復旧目標を、契約条件として確かめる
見積書は、要件定義と標準設定、個別開発を分けてもらいます。移行と連携、研修と保守も分けてもらい、5年間の総額で比べます。
小さく始めてデータ品質と定着を確認してから広げる進め方
必須業務から始め、品質と利用状況を見ながら広げます。
- 入力負担を減らし、データを申請、評価、情報公開、産学連携、IRへ再利用する。
- すべてを作り込まず、必須業務を標準SaaSやパッケージで稼働させる。
- パイロットで品質と利用状況を確認し、現場の声を取り入れる。
- 評価・BI・研究費・研究データ管理へ段階的に広げ、費用と運用リスクを抑える。
▼全体ガイドの記事
・研究業績管理システム開発の完全ガイド
▼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を創業。