研究業績管理システム開発の進め方/やり方/流れや方法/手法/工程/手順

研究業績管理システム開発は、論文や学会発表を登録する画面を作るだけでなく、研究情報を申請・評価・公開・IRに再利用できるデータ基盤へ整える取り組みです。要件整理から選定、設計開発、テスト、稼働、定着までを6つのフェーズに分けて進めると、二重入力や移行後の手戻りを抑えられます。

本記事では、大学・短大・高専・研究所の研究推進部門、情報システム部門、評価室、図書館、広報担当者に向けて、研究業績管理システムの開発の進め方を実務目線で解説します。researchmapやORCIDなどの外部情報、学内データベース、研究者総覧、教員評価、機関リポジトリをどのようにつなぐか、費用相場や見積もりで確認すべき項目、導入後に教員が使い続けるためのチェックポイントまで整理します。

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

研究業績管理システム開発の全体像

研究業績管理システムは、研究者のプロフィール、所属、論文、著書、学会発表、特許、受賞、競争的資金、共同研究、教育実績、社会貢献などを一元管理し、必要な業務へ再利用するWebシステムです。最初から「登録機能の多さ」で比較するのではなく、どのデータを正とし、誰が確認し、どの業務へ渡すかを定義することが開発の出発点です。

研究業績管理システムの価値は、入力した業績を一度だけ使うことではありません。研究者総覧や大学公式サイトへの公開、教員評価、認証評価、科研費申請、学内の研究力分析、産学連携の紹介資料などへ同じデータを再利用できる点にあります。researchmapの公式ガイドでも、論文、講演・口頭発表、書籍、産業財産権、Works、社会貢献活動などを管理・発信できる機能が案内されています（出典：researchmap「はじめてガイド」、2026年確認）。

したがって、要件定義では「誰が登録するか」だけでなく、「登録後にどの帳票・ページ・分析へ流すか」を書き出します。研究者本人が入力する業績、図書館や研究推進部門が補正する情報、広報が公開する項目、評価室だけが閲覧する情報を分けると、過剰な入力項目や権限設定の漏れを防ぎやすくなります。

対象データには、研究者プロフィール、所属・職位・学位・経歴・専門分野・ORCIDなどの基本情報に加え、論文、著書、学会発表、特許、受賞、研究課題、競争的資金、共同研究、教育活動、社会貢献、作品などがあります。すべてを初期導入に含める必要はありませんが、将来連携するデータの識別子や年度、所属、公開可否は、後から拡張できるようにデータ辞書へ残します。

業務範囲は、研究者の直接入力だけでなく、researchmap、ORCID、CiNii Articles、J-GLOBAL、PubMed、機関リポジトリ、学内の人事・研究費データからの取込も含めて整理します。自動取込には誤帰属や重複が起こる可能性があるため、候補表示、本人確認、事務承認、差し戻し、再処理、操作ログを一連の機能として定義します。

標準SaaSは、短期間で始めやすく、サーバー運用やバックアップ、外部サービスの仕様変更対応を任せやすい選択肢です。パッケージやクラウドサービスは、大学独自の項目・帳票・公開ページを追加しやすく、研究機関向けの運用知識を活用しやすい点が特徴です。スクラッチ開発は、既存の認証、研究費、評価、IR、機関リポジトリまで深く統合したい場合に向きますが、要件膨張と保守負担を見込む必要があります。

判断の軸は、機能数ではなく、業務を変える範囲、既存システムとの接続、データの所有権、導入後の変更頻度です。必須業務を標準機能で稼働させ、データ品質と運用を安定させてから評価・BI・研究データ管理へ拡張する段階導入は、初期投資と現場負担を抑えやすい進め方です。

研究業績管理システム開発の進め方・やり方は？

研究業績管理システムは、(1)要件整理、(2)製品・開発会社の選定、(3)設計・開発、(4)テスト、(5)稼働、(6)定着の6フェーズで進めます。各フェーズに成果物、責任者、完了条件を置くことが重要です。特に要件整理を省いて製品デモや開発へ進むと、データの正、公開範囲、帳票、移行対象が後から問題になり、費用と期間が膨らみやすくなります。

最初に、研究者、研究推進部門、評価室、図書館、広報、情報システム、学部事務、経営層からヒアリングします。紙やExcel、researchmap、旧システム、研究費管理、機関リポジトリを集め、「いつ、誰が、どのデータを入力し、誰が確認し、どの出力へ使うか」を業務フローにします。研究者本人の入力だけを見ていると、事務担当の名寄せや広報の公開確認、評価室の集計作業が要件から抜けるためです。

次に、MUST、SHOULD、WANTの3段階で要件を分けます。MUSTには業績登録、本人確認、公開・非公開、必須帳票、基本的な検索を置き、SHOULDには外部DB取込、評価ワークフロー、英語公開を置きます。WANTにはBI、AIによる登録候補提示、研究費や研究データの分析を置くと、初期開発の範囲を決めやすくなります。成果物は、現行業務フロー、将来業務フロー、データ辞書、権限一覧、帳票一覧、移行方針、KPI一覧です。

候補会社へは、同じ業務フローと質問票を渡し、研究者本人による業績登録、外部データの取込、重複候補の確認、事務承認、公開ページ生成、評価帳票の出力までをデモしてもらいます。単に画面が見やすいかではなく、研究者IDやDOIなどで名寄せできるか、誤帰属をどう戻すか、差分や履歴を確認できるかを操作で確かめます。

選定表には、SaaS・パッケージ・個別開発の方式、researchmap・ORCID・機関リポジトリとの連携、英語公開、評価・IR、SSO・MFA、バックアップ、導入実績、移行支援、研修、保守、解約時のデータ返却を並べます。価格だけを比較せず、初期設定、データクレンジング、帳票作成、API変更対応、問い合わせ窓口が見積もりに含まれるかを確認することが重要です。

設計では、画面、データ項目、マスター、ワークフロー、帳票、公開ページ、権限、監査ログ、バックアップ、障害時の運用を具体化します。研究者プロフィールや所属は人事情報を正とするのか、業績はresearchmapを正とするのか、学内DBを正とするのかを決め、項目ごとに管理元と更新方向を記録します。すべての情報を一つのシステムへ集めるのではなく、データの責任所在を明確にする設計が必要です。

公開情報、学内限定情報、事務限定情報、未公開業績を分類し、項目単位またはレコード単位で公開可否を制御します。氏名や所属だけでなく、共同研究者、研究課題、評価情報、競争的資金、公開前の論文情報も扱うため、最小権限、SSO、MFA、暗号化、操作ログ、バックアップ、削除手順を要件へ含めます。個人情報保護法や学術研究機関向けの規律があることを理由に安全管理を省略しない姿勢が大切です。

画面設計では、入力を一度に完了させようとせず、候補取込、本人確認、補足入力、承認、公開の段階に分けます。外部DBから取得した論文候補を研究者が確認し、所属や著者順を修正してから公開する流れにすると、自動取込の便利さとデータ品質を両立しやすくなります。

テストは、単体テスト、結合テスト、外部連携テスト、権限・ログ・バックアップのテスト、現場による受入テストに分けます。受入テストでは、匿名化または検証用のデータを使い、「研究者の新規登録、業績候補の取込、本人確認、事務承認、研究者総覧への公開、評価帳票の出力」までを一つのシナリオとして確認します。画面が開くことではなく、業務が最後まで完了することを合格条件にします。

必ず試すべき例は、同姓同名、所属変更、退職者、著者順の修正、重複業績、公開停止、誤登録の訂正、外部APIの停止、CSVの欠損、認証失敗、権限外の閲覧です。エラー発生時に、担当者が原因・対応・再処理方法を理解できるかも確認します。テスト結果には、再現条件、重要度、担当者、修正期限、再テスト結果を残し、重大な未解決事項は責任者が承認してから稼働判定へ進みます。

稼働時は、全学部・全研究者を一度に切り替えるより、代表部局や研究推進部門でパイロットを行う方法が安全です。香川大学は教員業績管理システムを2023年6月1日から実運用し、researchmap連携、直接入力・外部データ・学内データの取込、教員評価システム連携、業績データの可視化を組み合わせています（出典：香川大学「香川大学における教員業績管理システムの開発と業績データ可視化の取り組み」、2023年）。この事例のように、登録だけでなく評価や可視化までを検証対象にします。

移行では、研究者ID、所属、業績種別、発表年、DOI、公開可否、重複候補、過去履歴を照合します。過去データをすべて構造化するのか、一定期間だけ移すのか、旧システムを参照専用で残すのかを決め、移行リハーサルを最低でも本番前に行います。重大な連携エラー、バックアップからの復旧失敗、権限未確認、必須帳票の出力不能がある場合は、切り戻しまたは開始延期とする基準を合意します。

稼働後は、職種ごとの短時間研修、場面別マニュアル、現場リーダー、問い合わせ窓口を用意します。全機能を説明する研修よりも、「業績候補を確認する」「所属を変更する」「公開を止める」「帳票を出す」「連携エラーを報告する」といった実際の場面を使う方が、研究者と事務担当者の行動へ落とし込みやすくなります。

定着度はログイン数だけでなく、未確認業績の件数、重複率、本人確認にかかる期間、公開ページの更新遅れ、評価帳票の作成時間、問い合わせ件数などで測定します。学習院大学の導入事例では、researchmapを活用した研究業績公開によって二重登録を解消し、SaaSにより独自データベースの構築・運用を不要にして導入・運用コストの削減を図ったと紹介されています（出典：富士通「学校法人学習院 学習院大学様 導入事例」、2025年確認）。教員に入力を求めるだけでなく、二重入力を減らす効果を実感できる運用にします。

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

研究業績管理システムは、公開価格を提示するベンダーが限られており、研究者数、部局数、移行データ量、帳票、公開サイト、外部API、評価・IR、認証方式で費用が大きく変わります。以下の金額は特定製品の定価ではなく、リサーチノートにある基幹システム相場と研究業績管理の機能範囲をもとにした2026年時点の予算検討用レンジです。正式な予算は、同一条件のRFPで見積もりを取得して確定します。

既存SaaSやライトパックを標準設定で導入する場合は、初期100万〜500万円、月額5万〜30万円程度が一つの参考レンジです。要件整理から稼働までは2〜4か月程度を見込みます。研究業績パッケージへresearchmapやAPI、帳票、公開サイト、権限設定、データ移行を加える場合は、初期500万〜1,500万円、年額100万〜500万円程度、期間4〜8か月程度が目安です。

複数部局を対象にし、教員評価、IR、機関リポジトリ、研究費、SSOなどを連携する場合は、初期1,500万〜4,000万円、期間6〜12か月程度を検討します。スクラッチ開発で学内基盤や複数データベースを統合する場合は、初期2,000万〜6,000万円超、12か月以上になる可能性があります。これは機能範囲と移行難易度から算出した推定であり、研究者数だけで金額が決まるものではありません。

初期費用の見積書は、「システム一式」ではなく、要件定義・プロジェクト管理、画面とデータの設計、標準設定・個別開発、APIやCSVの連携、データクレンジング、移行、環境構築、セキュリティ設定、テスト、操作研修、稼働支援に分けてもらいます。特に移行は、研究者マスターだけを移すのか、過去の論文・著書・研究課題・評価履歴まで移すのかで作業量が変わります。

連携費用には、項目マッピング、相手システムとの仕様調整、接続環境、認証、エラー通知、再送、接続試験、仕様変更対応が含まれるかを確認します。研究業績データの取込では、名寄せや重複排除を自動化しすぎると誤帰属の確認負担が増えるため、候補の提示と本人確認を含む運用設計を見積もりへ反映します。

ランニングコストには、クラウド利用料、ユーザー・拠点・容量の追加料金、保守、監視、バックアップ、問い合わせ対応、セキュリティパッチ、API仕様変更への対応、帳票や制度変更の改修が含まれます。パッケージでは初期費用の年5〜15％程度を保守の目安に置く場合がありますが、契約によって対象範囲が異なります。無償アップデートの範囲、追加開発の単価、障害時の復旧目標、データ返却費用を確認します。

初期費用と月額だけでなく、5年間の総額で比較すると判断しやすくなります。たとえば、月額が低くても、部局追加、研究者追加、外部連携、帳票変更、データエクスポート、研修のたびに費用が発生する場合があります。クラウドを選ぶ場合は、保存場所、再委託先、バックアップ、障害通知、解約時のエクスポート形式と期限をRFPの段階から質問します。

研究業績管理システムの見積もりを取る際のポイント

見積もりの精度は、依頼側が渡す情報の具体性で変わります。候補会社へは、対象機関・部局・研究者数、年間の業績登録件数、利用者区分、現行システム、Excelや紙の種類、連携先、公開ページ、帳票、移行対象、希望時期、運用体制、予算上限を同じ資料で提示します。価格だけを比較すると、安い見積もりに必要な作業が含まれていない可能性があります。

RFPには、背景と目的、対象業務、対象外の業務、利用者区分、権限、業績種別、必須項目、公開範囲、承認フロー、帳票、検索、通知、保存期間、外部連携、認証、監査ログ、バックアップ、障害対応を記載します。各項目には、初期必須、将来追加、対象外の優先度を付けます。データ辞書には項目名、型、必須・任意、入力元、更新者、公開可否、履歴の要否を定義します。

受入条件は、感覚ではなく業務シナリオで書きます。たとえば、研究者が外部DBから取得した論文候補を確認できること、同一業績の重複を検知できること、事務担当が所属変更を反映できること、公開停止を即時に反映できること、指定した年度・部局・業績種別で帳票を出せること、権限外の評価情報を閲覧できないことを合格条件にします。

相見積もりでは、標準機能の適合度、大学・研究所での導入実績、researchmapや外部DBの連携方法、データ移行の実績、公開サイトや英語表示、評価・IR機能、サポート体制を同じ評価表で比較します。導入実績の件数だけでなく、自機関と近い研究者数・部局構成での事例、現在も保守されている製品か、導入後の問い合わせ窓口が誰かまで確認します。

契約前には、データの所有権、仕様書や連携定義書の引き渡し、解約時のデータ返却、再委託先、保存場所、障害時の復旧目標、脆弱性対応、個人情報事故時の連絡、追加開発の見積単価を確認します。研究業績データを長期的に蓄積するシステムでは、導入時の便利さだけでなく、5年後に別サービスへ移れるかという出口条件が重要です。

大学には、研究成果を社会へ発信する公開業務と、評価・研究費・未公開情報を内部で扱う業務があります。文部科学省は学校教育法施行規則の改正について、2025年4月1日施行の情報公表に関する規定を案内しています（出典：文部科学省「学校教育法施行規則の一部を改正する省令」、2024年公布・2025年施行）。法令上の公開項目を確認しつつ、公開前の業績や評価情報は別の権限で守る設計が必要です。

見積もりには、公開ページのテンプレート、項目単位の公開・非公開、公開前承認、英語ページ、検索エンジン向けの設定、学内限定ページ、操作ログ、SSO・MFAを含めるかを記載します。機能の有無だけでなく、公開設定を誰がいつ変更したか追跡できるか、誤公開時に停止できるか、退職者のページをどう扱うかまで確認すると、稼働後のリスクを減らせます。

研究業績管理システム開発でよくある質問

ここでは、研究業績管理システムの導入前に多く寄せられる質問へ回答します。費用や連携の可否だけでなく、研究者の入力負担、既存データ、公開範囲、導入時期を判断する材料としてご覧ください。

researchmapだけで研究者サイトの作成や業績の管理・発信が完結する機関もありますが、教員評価、学内の承認、独自帳票、研究費、IR、機関リポジトリ、学内認証まで必要なら、別の業務システムを連携させる価値があります。researchmapを正とするのか、学内DBを正とするのか、項目ごとに更新元を定めてから判断します。

標準SaaSの設定中心なら要件整理から稼働まで2〜4か月、パッケージにデータ移行・API・帳票・公開サイトを加えるなら4〜8か月程度が一つの目安です。複数部局の評価・IR・研究費・機関リポジトリ連携やスクラッチ開発を含める場合は、6〜12か月以上を見込みます。期間は開発だけでなく、意思決定、データクレンジング、相手システムとの接続試験、現場の受入テストに左右されます。

移行できますが、すべてのデータを同じ方法で移すとは限りません。研究者・所属マスターや主要業績は構造化して移し、古い添付資料や形式が揃わない履歴は参照用ファイルとして保管するなど、利用目的に応じて分けます。移行前にサンプルで名寄せ・重複排除を行い、移行後に件数、研究者ID、年度、DOI、公開可否を旧データと照合します。

入力を依頼するだけでなく、外部DBから候補を取り込み、研究者は確認と修正に集中できる運用にします。入力項目を必須・任意に分け、初期導入では公開や評価に必要な項目へ絞り、部局の現場リーダーを相談窓口に置きます。導入前後で入力時間、未確認件数、二重入力回数を測定し、負担が減ったことを示すと、利用の定着につながりやすくなります。

まとめ

研究業績管理システム開発を成功させるには、機能一覧から始めず、研究者・事務・評価室・図書館・広報が関わる業務フローとデータの流れを先に整理します。要件整理、選定、設計開発、テスト、稼働、定着の6フェーズごとに成果物と完了条件を置き、researchmapや学内DBのどちらを正とするか、取込後の本人確認をどうするか、公開情報と内部情報をどう分けるかを決めます。

発注前は、(1)対象業務と初期範囲、(2)データの正と更新方向、(3)移行対象と照合方法、(4)外部連携・認証・公開範囲、(5)受入テストと稼働判定、(6)保守・解約時のデータ返却を確認します。見積書には、要件定義、標準設定、個別開発、移行、連携、研修、保守を分けて記載してもらい、初期費用だけでなく5年間の総額で比較します。

研究者の入力負担を減らしながら、申請、評価、情報公開、産学連携、IRへデータを再利用するには、最初からすべてを作り込むより、必須業務を標準SaaSやパッケージで稼働させる方法が現実的です。パイロットでデータ品質と利用状況を確認し、現場の声を反映しながら評価・BI・研究費・研究データ管理へ段階的に広げると、費用と運用リスクを抑えやすくなります。

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

会社紹介

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

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

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

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

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

執筆者プロフィール

張田谷凌央

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