共同研究では、大学、企業、外部ベンダー、評価機関など、複数の関係者が同じテーマに関わります。
扱う情報も、NDA、契約関連、試験データ、議事録、図面、レポート、評価結果など多岐にわたります。
メールと共有フォルダだけで進めると、どれが最新版なのか、誰がどの資料を見られるのか、どの合意が有効なのかを確認しにくくなります。
共同研究ポータルは、単なるファイル置き場ではなく、権限、版、議事録、成果物、評価データをひとつのプロジェクト単位で扱うための仕組みとして考える必要があります。
共同研究では、技術テーマそのものだけでなく、周辺の運用で確認が増えることがあります。
特に、権限、版、証跡、データの4点は最初に扱いを決めておかないと、後から整理するのが難しくなります。
NDA、契約、組織、研究室、個人単位で閲覧・編集範囲を分けます。
成果物を差し替えで済ませず、Revと状態で確認できるようにします。
議事録、合意事項、タスク、次回確認事項をプロジェクトに紐づけます。
試験条件、供試体、データセット、評価結果を後から確認できるようにします。
権限とログは後から加えるのが難しいため、最初に 権限・ログ の設計を置きます。 成果物は 版管理 の考え方で、ドラフト、レビュー中、確定版を分けて管理します。
共同研究ポータルは、情報を置くだけの場所ではなく、プロジェクトの現在地を確認するための画面です。
最低限、プロジェクト基本情報、成果物、活動ログの3系統を分けて持つと、関係者が増えても確認しやすくなります。
議事録・合意事項は、後で確認が必要になりやすい情報です。 承認フロー（承認設計）を使い、「議事録作成中」「確認依頼中」「合意済み」のように状態を分けると、合意済みの内容を判断しやすくなります。
共同研究では、レポート、図面、データセット、手順書などのドラフトが複数発生します。
ファイル名を変えながら共有フォルダへ置くだけでは、正式版、レビュー中、古い版が混在しやすくなります。
成果物は差し替えではなく、Revを持つデータとして管理します。
提出用成果物と社内検討用の草案も分けて扱うと、対外共有時に不要なメモや未検証データが混ざりにくくなります。
| 成果物 | Rev | 状態 | 閲覧範囲 | 次の対応 |
|---|---|---|---|---|
| 評価レポート | Rev.2 | レビュー中 | 企業・大学・評価機関 | 企業側レビュー後に確定 |
| 試験データセット | Rev.1 | 確定 | 企業・大学 | 提出セットへ追加済み |
| 社内検討メモ | Draft | 社内限定 | 企業側のみ | 外部共有不可 |
共同研究のデータは、あとから再現できる形で残しておくことが重要です。
測定値だけが残っていても、試験条件、供試体、ロット、測定機器、担当者、添付ファイルが分からなければ、次の検討に使いにくくなります。
評価データは、試験レコード、条件、供試体、添付ファイルの構造で管理します。 プロジェクトIDから評価結果を確認でき、評価結果から関連する成果物や議事録へ戻れるようにします。
評価データは 評価データまとめ の考え方で、試験条件と結果をセットで扱います。 試作・評価依頼をフォーム起点で扱う場合は、依頼側の案件一覧（一覧化）と紐づけると、研究側と現場側の確認がしやすくなります。
共同研究では、社内システムよりも権限設計が複雑になります。
同じプロジェクト参加者でも、すべての資料を見せてよいとは限りません。
| 資料種別 | 企業側 | 大学側 | 外部評価機関 | 注意点 |
|---|---|---|---|---|
| NDA・契約書 | 閲覧可 | 閲覧可 | 不可 | 契約担当者のみ編集可 |
| 評価データ | 閲覧可 | 閲覧可 | 閲覧可 | 生データのダウンロード権限を別管理 |
| 社内検討メモ | 閲覧可 | 不可 | 不可 | 対外共有不可として固定 |
添付ファイルを扱う場合は、保存期間やダウンロード権限も含めて設計します（添付設計）。 共同研究では、閲覧できる資料と共有してはいけない資料の境界を最初に仕様化しておくことが重要です。
共同研究ポータルをスマホで見る場面では、資料全体を細かく扱うよりも、今日確認すべき内容を絞って表示する方が使いやすくなります。
議事録の確認、成果物レビュー、データ追加依頼、未完了タスクなど、次の対応が分かる画面にします。
評価レポート Rev.2 / 企業側レビュー待ち
5/2 定例議事録 / 大学側確認待ち
供試体 S-24A-006 の外観写真が未添付です。
共同研究では、成果物レビュー、議事録確認、追加実験、契約確認などが同時に進みます。
どこが未完了なのかを状態で確認できると、次に誰が対応するのかが分かりやすくなります。
成果物、議事録、評価データ、タスクをプロジェクトに紐づけます。
レビュー担当、期限、閲覧範囲を指定して確認を依頼します。
議事録や成果物を合意済み・確定版として記録します。
誰がいつ確認し、どの版が確定したかをログに残します。
ステータスの設計は、一般の案件管理（運用ルール）と同じく、状態と遷移を決めることが重要です。 状態名だけを増やすのではなく、「誰が次に何をするか」が分かる粒度にします。
製造業の研究開発では、共同研究の成果を社内に残し、次の開発・評価・品質改善へつなげることが重要です。
業務像は 製造業向け を前提に、評価データ、技術ナレッジ、品質共有が同じプロジェクトから確認できる状態を目指します。
共同研究ポータルは、単に情報を共有するためだけのものではありません。 権限、版、証跡、再現性を保ちながら、社外関係者と研究を進めるための管理基盤として設計します。
共同研究をポータル化するなら、権限、版、証跡、再現性が重要です。
プロジェクト基本情報、成果物、活動ログ、評価データを分けて管理し、それぞれをプロジェクトIDで紐づけます。
大学、企業、評価機関、委託先ごとに、閲覧・編集・ダウンロード範囲を決めます。
成果物は差し替えではなくRevで管理し、確定版とドラフトを区別します。
評価データは、試験条件、供試体、結果、添付資料をセットで残します。
外部参加者を前提に権限を分割し、議事録や成果物の合意・確定を状態として扱うことで、研究の進行状況と根拠資料を確認しやすくなります。 メールや共有フォルダだけでは残りにくい経緯を、プロジェクト単位で残すことが共同研究ポータルの役割です。