研究ソフトウェアエンジニアリングとは何ですか?

リサーチ ソフトウェア エンジニアリング (RSE) は、専門的なソフトウェア エンジニアリングの実践 (バージョン管理、テスト、コード レビュー、継続的統合、文書化、長期保守) を科学研究を支えるコードに適用する分野です。 1 人のポスドクのラップトップ上でのみ実行される分子動力学解析スクリプトのデバッグに 3 週間を費やしたことがある場合、または文書化されていない Python の tarball から公開された結果を再現しようとした場合は、研究ソフトウェア エンジニアリングが解決するために存在する問題にすでに遭遇していることになります。この記事では、RSE とは何か、隣接する役割との違い、リサーチ ソフトウェア エンジニアが実際に日常的に行っていること、グループに RSE が必要かどうかを判断する方法について説明します。

短い定義と、それが議論されている理由

「リサーチ ソフトウェア エンジニア」という用語は、主に Software Sustainability Institute の活動を通じて 2012 年頃に英国で造られ、従来の研究者でも IT サポート スタッフでもない、増え続ける人々に名前を与えました。彼らは研究に不可欠なコードを書きましたが、キャリアの進歩、役職、評価はどちらの枠にも当てはまりませんでした。

一般的に引用される実用的な定義は、リサーチ ソフトウェア エンジニアは次の要素を兼ね備えている人であるということです。

1. ソフトウェア エンジニアリングに関する専門的な理解 - 設計、テスト、バージョン管理、展開、メンテナンス。
2. 研究における積極的な役割 — 単に誰かから伝えられた仕様を実装するだけでなく、研究課題、出版物、助成金申請に貢献すること。
3. 少なくとも 1 つの研究ドメインへの深い関与 — 科学、データ、制約を理解するのに十分です。

議論の分かれる点は、その境界線です。広く使用されている R パッケージを管理するバイオインフォマティシャンは RSE ですか?自分の論文のシミュレーション コードを書く物理学者は RSE ですか? Python をたくさん書く研究グループの「データ管理者」は RSE ですか?ライセンス発行機関や世界的に合意された認証がないため、ラベルは実用的に適用されます。実際、際立った特徴は方向性です。RSEはソフトウェアを単一の論文の使い捨て手段としてではなく、第一級の研究成果および長寿命の成果物として扱います。

RSE と隣接するロール: 比較

RSE を理解する最も簡単な方法は、よく混同される役割と比較して RSE がどの位置にあるかを確認することです。以下の表は分類法ではなくヒューリスティックです。実際の人々はこれらの境界線を常に曖昧にしています。

比較項目	リサーチソフトウェアエンジニア	伝統的な研究者 (コードを書く人)	IT / 研究用コンピューティングのサポート	データサイエンティスト/アナリスト
主な成果物	保守可能で再利用可能なソフトウェア	出版物と調査結果	実用的なインフラストラクチャとサービス	モデル、分析、決定
コードの寿命	数年から数十年。バージョン付きリリース	多くの場合、1つのプロジェクトや論文に紐付く	多くの場合、プロジェクト限定的
代表的なスキル	ソフトウェア設計、テスト、CI/CD、HPC、ドメイン サイエンス	ドメインサイエンス、手法、統計	システム管理者、ネットワーキング、スケジューラー、セキュリティ	統計、ML、ドメインデータ
リサーチクエスチョンとの関係	共同定義し、形を整える	所有しています	間接的に提供します	提起された質問によく答えます
成功指標	ソフトウェアの採用、再現性、引用、持続可能性	出版物、助成金、影響	稼働時間、ユーザー満足度、コスト	ビジネス/研究の洞察
キャリアトラック	多くの場合、ハイブリッド。時々常駐の科学者	教員/ポスドクのキャリアパス	IT職のキャリアパス	業界または学術

重要な洞察: RSE は「たまたまコードが得意な研究者」でも、「Python を支援する IT 担当者」でもありません。その役割は、科学に組み込まれたままで 研究製品としてソフトウェアを所有することによって定義されます。

関連: Dataquest — ガイド付きターミナルと実際のデータセットを使用したプロジェクトベースのデータ サイエンス パス.

研究用ソフトウェア エンジニアが実際に行うこと

仕事の内容は非常に多様ですが、仕事は認識可能なカテゴリに分類されます。現実的な週では、これらのうち 4 つまたは 5 つに触れる可能性があります。

1. 研究ソフトウェアの構築と保守

これが核心です。これには、シミュレーション コード用の API の設計、モノリシック分析スクリプトのテスト済みライブラリへのリファクタリング、PyPI または conda-forge で配布するためのツールのパッケージ化、依存関係が壊れないようにすることが含まれます。分子動力学グループの場合、これは、GROMACS または LAMMPS 解析ツールキットを保守すること、または RAM にテラバイトをロードせずに軌跡データをストリーミングする NumPy/HDF5 パイプラインを作成することを意味する場合があります。

2. 研究を再現可能にする

RSE は、「environment.yml」、「pyproject.toml」、コンテナ イメージ (Docker、Singularity/Apptainer)、およびワークフロー マネージャー (Snakemake、Nextflow、共通ワークフロー言語) をラボに導入する人であることがよくあります。目標は、2 年後に別の人が別のマシンで結果を再生成できるようにすることです。これは、RSE が再現性運動および FAIR データ原則と大きく重なる部分です。

一見の価値があります: Coursera Plus — 大学が支援する Python およびデータサイエンス証明書の 1 つのサブスクリプション.

3. パフォーマンスとスケーリング

科学コードは、多くの場合、より高速に、またはより大規模に実行する必要があります。 RSE は、コードのプロファイル、NumPy 操作のベクトル化、MPI または OpenMP による並列化、ホット ループの C/C++/Fortran への移植、または Numba/Cython の使用、および I/O の調整を行います。たとえば、HDF5 のチャンキングと圧縮の選択は、軌跡分析のランタイムに影響を与える可能性があります。また、グループが HPC クラスターと GPU を効果的に使用するのにも役立ちます。

4. コンサルティングとトレーニング

多くの RSE は、オフィス アワー、コード レビュー、ワークショップ (Software Carpentry、HPC Carpentry、ドメイン固有のトレーニング) を実施しています。彼らの影響の大部分は、研究者に代わってすべてを行うのではなく、より良いコードを自分たちで書くように教えることによってもたらされます。

5. 助成金と出版物への貢献

資金提供者がソフトウェアの持続可能性と管理計画を期待しているため、RSE は共著者として、また助成金の指名担当者として登場することが増えています。その計画を作成し、労力を見積もり、メンテナンスに取り組むことが RSE アクティビティです。

RSE が組織的に位置する場所

一般的なモデルは 3 つあり、それぞれにトレードオフがあります。

• 集中型 RSE グループ (大学全体または研究所全体のチーム)。利点: 専門知識の共有、RSE のキャリア パス、複数のプロジェクトにスタッフを配置する能力。短所: 単一の研究課題からかけ離れたものになる可能性があります。チャージバックや優先順位の政治。
• 研究グループまたは研究室への組み込み型。利点: 深いドメイン コンテキスト、高速な反復、強力な関係。短所: 孤立、ピア RSE コミュニティがない、RSE が一般的な「コンピューターを修理する」リソースになるリスクがあります。
• ハイブリッド/マトリックス。プロジェクト出向者を中心とするグループ。ますます一般的になってきています。明確なライン管理と時間配分の合意が必要です。

英国には特に顕著な RSE コミュニティがあり、毎年開催される RSE カンファレンスや地域ネットワークが存在します。同様のコミュニティがドイツ (de-RSE)、オランダ、米国、オーストラリアにも存在します。 Society of Research Software Engineering (Society of RSE) は専門団体として英国に設立されました。

RSE と再現性およびオープン サイエンスとの関係

計算科学における再現性の危機は主にソフトウェアの問題です。分析は、特定のライブラリ バージョン、文書化されていない前処理手順、およびリリースされていないコードに依存します。 RSE プラクティスはこれに直接対処します。

関連: O'Reilly Learning Platform — 科学技術コンピューティング関連の書籍、ビデオ、ライブ トレーニングの詳細な技術ライブラリ.

• バージョン管理とタグ付きリリースにより、使用されているソフトウェアの正確なバージョンを引用することができます。
• テストは、もっともらしいが間違った結果を生み出す、サイレント数値バグを検出します。
• 継続的統合 により、依存関係の更新後もコードが動作することが保証されます。
• Zenodo または Software Heritage でコードを アーカイブすると、DOI と永続的なホームが与えられます。
• ドキュメント により、他の人 (将来のあなたを含む) が理解し、再利用できるようになります。

Research Data Alliance によって開発されたリサーチ ソフトウェアの FAIR 原則は、FAIR データ ガイドラインをソフトウェアに明示的に拡張します。ジャーナルではコードの可用性に関するステートメントがますます求められており、出版の一環としてコードレビューが必要なジャーナルもあります。

RSE が必要かどうかを判断する方法

すべてのグループに専用の RSE が必要なわけではありません。次の基準を大まかなフィルターとして使用します。

おそらく次の場合に必要になります。

ショッピングの場合: DataCamp — ブラウザーで直接コーディングするインタラクティブな Python およびデータ サイエンス コース.

• ソフトウェアは研究成果の中心であり、グループを超えた人々によって使用されます。
• 複数の助成金や年にわたってコードを保守しているのに、コードが壊れ続けます。
• 他の人がすでに解決しているのと同じインフラストラクチャ (I/O、並列処理、パッケージ化) を繰り返し再構築しています。
• 査読者、共同研究者、または資金提供者がソフトウェアの持続可能性について質問しますが、適切な答えがありません。
• あなたのグループは、出版物では目に見えない ソフトウェア メンテナンス にかなりの時間を費やしています。

次の場合は (まだ) 必要ない可能性があります。

• あなたのコードは本当に使い捨てであり、単一の図（figure）のための使い捨ての分析です。
• ニーズはよく管理されたコミュニティ ツールによって満たされ、グルー スクリプトを作成するだけです。
• あなたには、心から楽しんで、これが得意で、時間があるグループのメンバーがいます。

中間点: パートタイムの CSR を雇用するか、コア グループに参加するか、既存の研究者がベスト プラクティスを採用できるようにするためのトレーニングに投資します。最悪の結果は、CSR を雇用し、その人たちを臨時の IT サポートとして使用することです。

キャリアパスと RSE になる方法

CSRのキャリアは実に多様です。エントリ ポイントには次のものが含まれます。

• 計算分野 (物理学、化学、生物情報学) の博士号を取得し、ソフトウェア側に引き寄せられた人。
• 産業界のソフトウェア エンジニアで、科学的な問題に取り組みたいと考えています。
• ソフトウェアの役割を正式に定める 研究スタッフ。

最も重要なスキルを、おおよそ出現頻度の高い順に並べると、次のようになります。

1. Python (パフォーマンスが重要なコードの場合は C++、Fortran、または Julia も含む) の知識。
2. ブランチおよびコード レビュー ワークフローを含む、Git によるバージョン管理。
3. テスト フレームワーク (Pytest、GoogleTest) および CI (GitHub Actions、GitLab CI)。
4. パッケージングおよび環境管理 (Conda、Pip、Container)。
5. HPC および並列プログラミング (MPI、OpenMP、CUDA、Slurm などのジョブ スケジューラ)。
6. 当該分野における科学的能力: 研究者と同僚として話すのに十分な能力。
7. コミュニケーションと教育スキル。

キャリアパスは、学術界や産業界ほど標準化されていません。一部の RSE は常勤スタッフの科学者になります。研究コンピューティングのリーダーシップに移行する人もいます。教員に戻る人もいます。産業界に進む人もいます。明確なはしごの欠如は、コミュニティで頻繁に議論される現実的な問題であり、専門機関や中央グループが重要である理由の 1 つです。

よくある誤解

• 「RSE は科学者のための単なる IT サポートです。」 いいえ — RSE は研究課題と独自のソフトウェア製品を形成します。 IT サポートはインフラストラクチャを維持します。
• 「優秀なプログラマーなら誰でも RSE として活躍できます。」 ドメイン コンテキストは非常に重要です。優秀な Web 開発者は、浮動小数点の合計順序によって結果が変わる理由を知らないかもしれません。
• 「RSE はコードを書くだけです。」 仕事の大部分は、コンサルティング、トレーニング、設計に関するディスカッションです。
• 「RSE は、『本当の』学術的な仕事への足がかりです。」 そうである人もいます。多くの人にとって、それは正当な永続的なキャリアです。
• 「コンピューター サイエンスの学位が必要です。」 ほとんどの RSE は、CS ではなく、科学分野の出身です。

重要なポイント

• 研究ソフトウェア エンジニアリングは、専門的なソフトウェア プラクティスを研究コードに適用し、ソフトウェアを第一級の長期にわたる研究成果として扱います。
• RSE は、特定の役職や資格によってではなく、ソフトウェア エンジニアリングのスキル、積極的な研究への関与、および分野の専門知識を組み合わせることによって定義されます。
• RSE は、主に製品としてのソフトウェアの所有権とその複数年の寿命において、IT サポート、データ サイエンス、および「コーディングを行う研究者」とは異なります。
• 主な活動には、コードの構築と保守、再現性の実現、パフォーマンスの調整、コンサルティング、トレーニング、助成金や出版物への貢献などが含まれます。
• RSE は集中型、組み込み型、またはハイブリッド型にすることができます。各モデルには、コンテキスト、キャリアパス、優先順位付けにおいて実際のトレードオフがあります。
• RSE が必要かどうかは、グループの規模だけではなく、ソフトウェアが中心的であるか、再利用されるか、存続期間が長いかどうかによって決まります。

出典と詳細情報

• リサーチ ソフトウェア エンジニアリング — Wikipedia: リサーチ ソフトウェア エンジニアリングは、ソフトウェア エンジニアリングの実践、方法、および技術をリサーチ ソフトウェア (つまり、…のために作られたソフトウェア) に応用することです。
• ソフトウェア エンジニアリング — Wikipedia: ソフトウェア エンジニアリングは、ソフトウェア アプリケーションの設計、開発、テスト、保守に重点を置いたコンピューター サイエンスとエンジニアリングの両方の分野です。それには…

よくある質問

研究ソフトウェアエンジニアリングとは簡単に言うと何ですか?

研究ソフトウェア エンジニアリングとは、商用ソフトウェア チームが使用するのと同じ専門標準 (テスト、バージョン管理、文書化、メンテナンス) を使用して、科学者が依存するソフトウェアを構築および保守する実践です。研究用ソフトウェア エンジニアは、ソフトウェア開発と科学分野の交差点で働いているため、コードとそれが提供する科学の両方を理解しています。目標は、正確で再利用可能で、何年たっても動作するソフトウェアです。

研究用ソフトウェア エンジニアはソフトウェア エンジニアとどう違うのですか?

従来のソフトウェア開発者は通常、ユーザーまたは顧客向けに製品を作成し、要件は製品チームによって決定されることがよくあります。研究用ソフトウェア開発者は、科学的知識を生成またはサポートすることを目的としたソフトウェアに取り組んでいますが、その場合、要件は本質的に探索的なものであることが多く、「正しい」結果が事前にわからない場合があります。 RSE は通常、コードが実行されるかどうかだけでなく、数値結果が物理的に妥当かどうかを判断するのに十分な実際のドメイン知識も必要とします。

研究用ソフトウェア エンジニアになるには博士号が必要ですか?

いいえ、しかし、専門分野の知識は不可欠であり、博士号を取得するのが一般的な方法の 1 つです。 RSE の多くは、物理学、化学、生物情報学、または関連分野で博士号を取得し、ソフトウェア側の仕事に取り組んでいます。業界のソフトウェア エンジニアリング出身で、仕事を通じてその分野を学ぶ人もいます。重要なのは、資格そのものではなく、研究者と科学について同僚として関わることができるかどうかです。

研究用ソフトウェア エンジニアはどのようなプログラミング言語を使用しますか?

Python は、特に分析、スクリプト作成、およびグルーコードの分野で主流であり、多くの場合、NumPy、pandas、HDF5 ベースの I/O と並んでいます。パフォーマンスが重要なコンポーネントは C++、Fortran、または C で記述されることが多く、Julia と Rust が普及しています。 R は統計と生物情報学において引き続き重要であり、シェル スクリプト、Make、および Snakemake や Nextflow などのワークフロー言語が広く普及しています。言語は、その周りの実践ほど重要ではありません。

研究ソフトウェア エンジニアリングは良いキャリアですか?

科学とソフトウェアの両方を楽しむ人にとって、それは強い需要、さまざまな問題、そして目に見える影響を伴う素晴らしいキャリアとなる可能性があります。主な注意点は、キャリア構造が学界や産業界ほど標準化されていないため、昇進は教育機関と中央の RSE グループが存在するかどうかに大きく依存することです。多くの RSE は、ポスドクの職よりも仕事が安定しており、給与も高いと感じていますが、普遍的なキャリアパスの欠如は問題として認識されています。

研究ソフトウェア エンジニアリングは再現性をどのようにサポートしますか?

RSE プラクティスでは、正確なソフトウェア バージョンを固定し、ビルドとテストを自動化し、依存関係を文書化し、DOI を使用してコードをアーカイブして引用および検索できるようにすることで、結果の再現性を高めます。これらの実践がなければ、解析は文書化されていない手順や、後から再構築することが不可能な特定のライブラリ バージョンに依存することがよくあります。 RSE は、コードだけでなくコンピューティング環境全体をキャプチャするコンテナーとワークフロー マネージャーも導入します。

さらに詳しい情報と信頼できる情報源

• 研究ソフトウェア エンジニアリングに関するウィキペディアの記事には、この用語の広範な概要と歴史が記載されています。
• Software Sustainability Institute (software.ac.uk) は、RSE の定義、キャリア、コミュニティ調査について幅広く発行しています。
• Society of Research Software Engineering (society-rse.org) は、この分野の英国の専門団体です。
• Research Data Alliance の FAIR Principles for Research Software は、特にソフトウェアに FAIR データ ガイドラインを拡張します。
• Journal of Open Source Software (joss.theoj.org) および Journal of Open Research Software は、査読済みの研究ソフトウェアを公開しています。