大学・研究所の情報基盤転職ガイド

大学・研究所の情報基盤は、キャンパスネットワークとID、研究計算（クラスタ・ストレージ）、学術情報（リポジトリ、電子ジャーナル連携）、研究室サポートが求人に現れます。公務員・公共ITは自治体・行政手続のDXが中心です。学術機関は「研究の継続と教育・事務の共存」が焦点になりやすいです。論文数やベンチマーク順位は掲載しません。

キャンパスIT

ID、ネットワーク、教室・事務システムです。自治体の住民手続基盤とは利用者が異なります。

研究計算

クラスタ、ジョブスケジューラ、共有ストレージです。一般クラウド運用とは公平性と研究データの扱いが加わります。

学術情報

リポジトリ、文献、研究業績の情報流通です。行政の公開データポータルとは目的が異なります。

研究データ

実験・観測データです。公開可否と個人情報の混在に注意し、件数や成果は創作しません。

公共・非営利でも、行政手続、大学事務、研究計算、データ基盤が混在します。このページは研究IT・学術情報に焦点を当てます。公務員・公共IT（行政DX）、Linux管理者（OS運用一般）、データエンジニア（分析基盤一般）との境界を表で整理します。

• 主な問い：大学・研究IT側は「研究と教育のITは止めずに共存できるか」。隣接側は「手続は終わるか / OSは健全か / 分析は毎日使えるか」。
• 利用者：大学・研究IT側は「学生、教員、研究室、事務」。隣接側は「住民・職員 / 社内ユーザ / アナリスト」。
• 成果物：大学・研究IT側は「IdP、クラスタ、リポジトリ」。隣接側は「電子申請 / サーバ運用 / Lake」。
• 変更：大学・研究IT側は「学期・予算・共同利用のカレンダー」。隣接側は「法令改正 / パッチ窓 / スキーマ」。
• 面談：大学・研究IT側は「研究室との権限、ジョブの公平性」。隣接側は「マイナンバー隣接 / オンコール / dbt」。
• 混同しやすい求人：大学・研究IT側は「「公共」とだけ書かれた自治体SE」。隣接側は「官公庁SIer / 一般情シスLinux」。

大学IT求人は、学術情報、HPC、IdP、SINET、Linux等のキーワードが並びます。略語より、研究室との分担、計算ジョブの公平性、個人情報と研究データの分離が通るかを読んでください。

• キャンパス／計算／学術情報のどこかを言える
• 行政DXとの違いを説明できる
• 論文数やベンチマークを書いていない
• 研究データと学生情報の分離を意識している
• 雇用形態（常勤・任期）を求人票で確認した

job tagで情報処理・運用職を対応づけます。組織のDX一般はIPAのDX資料です。学生・研究者情報は個人情報保護委員会の案内を入口にします。行政手続の電子化は関連テーマです。

大学・研究ITでは、ツール名の羅列より、自分が判断した範囲の説明が先です。秘密情報は一般化し、確認できない数字は書きません。

1. 01
   利用者とシステムを1枚描く

   学生、教員、研究室、事務の列と、IdP、ネットワーク、計算、学術情報の行で担当を色付けします。

2. 02
   障害または権限の1例

   アカウント、ジョブ、ストレージのいずれか1例を一般化します。

3. 03
   行政DXとの境界

   住民手続、庁内基幹は隣接として明記します。

4. 04
   個人情報メモ

   学生情報と研究データの置き場の違いを書き、保護委員会案内を入口にします。

大学・研究ITの応募可否は、肩書や媒体の並び順ではなく、次の順で切り分けます。

• 求人が学術機関か、行政DXか、民間情シスかを切り分ける
• キャンパス／研究計算／学術情報のどこかを一文にする
• 利用者区分と権限の説明ができるか確認する
• 論文数・ベンチマークを経歴から外す
• 任期・雇用形態を求人票で確認する
• 社内SE系と公共全般の相談先を分け、重複を防ぐ

大学ITは媒体によって社内SE、インフラ、公共に分類されます。学術機関寄りと民間SIer寄りの相談先を併用し、社内SE転職ナビ、Geekly、リクルートエージェント、明光キャリアパートナーズで重複応募を避けます。

• 学術機関の情シス

  社内SE転職ナビ、明光キャリアパートナーズで大学・研究所の社内ITを探す場合。任期と評価制度を書面で確認します。

• 基盤エンジニア

  GeeklyでLinux・クラウド求人が混ざる場合、研究クラスタか一般SaaSかを分けます。

• 公共全般との切り分け

  リクルートエージェントで公共案件が広い場合、行政手続か学術基盤かを先に伝えます。

相談先を複数使う場合は、企業名・求人ID・応募経路を一覧にして重複応募を防いでください。転職支援とスカウトでは受けられる支援が異なるため、同じ基準で単純比較せず、目的に合う窓口を選びます。

• 行政DXと同一視

  公務員・公共ITは自治体・行政が中心です。研究と教育の利用者区分を書いてください。

• 成果指標の創作

  論文数、被引用、スパコン順位はこのページでは扱いません。

• Linux運用だけを研究ITと書く

  OS運用はLinux管理者と重なります。共同利用や研究データの制約を加えてください。

応募前1週間は、利用者（学生／教員／事務）とシステムの対応1枚、行政DXとの差分、障害またはアカウントの1例、面談質問を準備します。

1. 01
   月〜火：図と実例

   利用者×システム図と障害1例を清書します。

2. 02
   水〜木：求人比較

   3件をキャンパス/HPC/行政/民間で分類します。

3. 03
   金：面談質問

   任期、オンコール、研究室分担の質問を書き出します。

4. 04
   週末：経歴と相談先

   成果数字を外し、重複応募表を作ります。

大学・研究ITの用語は、公式資料の定義と求人票の言葉がズレることがあります。次の表で、経歴に書く粒度と求人票での確認先を揃えてください。

大学・研究ITでは、媒体記事より公式資料を先に開き、分からない点だけを相談先と公式窓口に分けます。

1. 01
   厚生労働省 職業情報提供サイト（job tag）IT・通信の仕事

   情報処理職の説明を、大学IT経験の対応づけに使う 一方で、大学職員の給与や採用倍率の根拠にしない

2. 02
   IPA デジタルトランスフォーメーション（DX）

   組織のデジタル化の考え方を、キャンパスITの参照にする 一方で、研究力やDX効果の数値を転記しない

3. 03
   個人情報保護委員会

   学生・研究者情報の取り扱いを考える入口にする 一方で、個別大学の適法性や研究倫理審査の結論は断定しない

• 手順1：求人が学術機関か、行政DXか、民間情シスかを切り分ける
• 手順2：キャンパス／研究計算／学術情報のどこかを一文にする
• 手順3：利用者区分と権限の説明ができるか確認する
• 手順4：論文数・ベンチマークを経歴から外す
• 手順5：任期・雇用形態を求人票で確認する
• 手順6：社内SE系と公共全般の相談先を分け、重複を防ぐ

大学・研究所の情報基盤転職ガイドの応募準備では、「知っている」「使った」で止めず、どの入力を受け、何を判断し、どの成果物を残し、障害時にどこまで対応したかを分けます。対象領域は大学IT・研究基盤・学術情報です。公開できない固有名詞や数値は一般化し、公式資料（厚生労働省 職業情報提供サイト（job tag）IT・通信の仕事、IPA デジタルトランスフォーメーション（DX）、個人情報保護委員会）で確認した定義と、自分の担当実績を混同しないでください。

1. 01
   公式定義を一つ選ぶ

   厚生労働省 職業情報提供サイト（job tag）IT・通信の仕事、IPA デジタルトランスフォーメーション（DX）、個人情報保護委員会を開き、大学IT・研究基盤・学術情報に関係する用語を一つ選びます。版や更新日が分かる場合はメモし、求人票独自の表現と分けます。

2. 02
   担当箇所を図にする

   入力、処理、出力、依存先を四角で描き、自分が変更・レビュー・運用した場所だけに印を付けます。触れていない箇所は実績に含めません。

3. 03
   失敗例を一つ添える

   正常系だけでなく、失敗の検知、切り分け、復旧、再発防止の順に一例を整理します。秘密情報と確認できない改善率は書きません。

4. 04
   求人ごとに質問へ変える

   必須条件と歓迎条件を分け、主担当・補助利用・学習予定のどれに当たるかを記録します。回答が曖昧な項目は応募理由の主軸にしません。

• 大学・研究所の情報基盤転職ガイドで自分が決めたことを一文で説明できる
• 大学IT・研究基盤・学術情報の利用経験と設計・運用経験を分けた
• 成果物、レビュー責任、障害時の担当を確認した
• 出典のない求人数、年収、改善率を書いていない
• 求人IDと応募経路を管理し、重複応募を防いだ