研究室運営におけるGitHub活用ロードマップ
筆者の所属研究室でGitHubの導入を進めた事例をモデルにしてボトムアップ型とトップダウン型の2種類の活用ロードマップを策定しました.
研究室でGitHubを使おう！
GitHubは2008年に正式にサービス開始し, 2018年にMicrosoft買収, 2019年にGitHub Actionsのサービスが開始しました. 今ではITエンジニアにとって必要不可欠な道具になっており, 研究の用途においても使えないと足手まといになってしまう状況重要な役割を果たします. GitHubは共同研究だけでなく, 再現性のある研究を行うために効果的なプラットフォームであると評価されています.
研究に使うプログラムだけでなく, 研究室ホームページなどの管理においてもGitHubは有効です. 以下では, 研究室運営においてGitHubの導入・活用を進めるための2種類のロードマップを提案します.
ボトムアップ型
まずは, 学生や若手教員がリーダーシップを取って活用の幅を拡げていくボトムアップ型のロードマップを策定しました. 筆者の所属する研究室ではこのシナリオで導入を進めています. ここで, 若手リーダーは学生やポスドクなど導入の中心となる人物, PIは教授や准教授などを指します.
| 段階 | マイルストーン |
|---|---|
| 01 | 若手リーダーがGitHubの個人アカウントを作る. |
| 02 | 若手リーダーがPIの許可を取り研究室のorganizationを作成する. |
| 03 | 若手リーダーが研究で使うコードや研究室ホームページのリポジトリを作成, 共有する. |
| 04 | 他の学生・若手教員のための勉強会を開き, その場で全員がGitHubアカウントを作る. 若手リーダーが他のメンバーをorganizationに追加, ファイル閲覧まで可能にする. プルリクを出すところまでは勉強会の中で扱った方がよい. |
| 05 | 他の学生・若手教員が若手リーダーのIssueに従ってプルリクを出し, コードレビューを受ける. |
| 06 | 他の学生・若手教員が若手リーダーの指導の下で問題の切り分けを適切に行い, Issueを出せるようになる. |
| 07 | 他の学生・若手教員が若手リーダー抜きでIssue消化, プルリク, コードレビューを行う習慣をつける. |
| 08 | 若手リーダーがマイルストーン管理の手本を示し, 他の学生・若手教員が必要に応じて導入する. |
| 09 | PIが自らGitHubアカウントを作り, 若手リーダーがorganizationに追加する. |
| 10 | PIが自らIssueを出せるようになり, 学生・若手教員が消化する. |
| 11 | PIが自らマイルストーンを設定し, 学生・若手教員の進捗を管理する. |
このロードマップではPIがGitHub上でプロジェクトマネージャー的な役割を果たせるようになることをゴールとしています. したがって, PIが自らコードを書いてPull Request（プルリク）を出せるようになったり, コードレビューで具体的な指導を行うことはゴール後に余裕があればやることとして, ひとまずIssueやマイルストーン管理など上流工程側の習得を優先します.
トップダウン型
次に, 教授や准教授などの研究室の主宰者（PI）からトップダウン型で導入を進めるロードマップを策定しました. 実際に経験がある先生がいればご意見を伺いたいです.
| 段階 | マイルストーン |
|---|---|
| 01 | PIがGitHubの個人アカウントを作る. |
| 02 | PIが研究室のorganizationを作成する. |
| 03 | GitHubアカウントを持っている若手がいればorganizationに追加, 必要に応じてorganizationの管理権限を与える. |
| 04 | PIや若手リーダーが研究で使うコードや研究室ホームページのリポジトリを作成, 共有する. |
| 05 | PIや若手リーダーが他の学生・若手教員のための勉強会を開き, その場で全員がGitHubアカウントを作る. PIまたは若手リーダーが他のメンバーをorganizationに追加, ファイル閲覧まで可能にする. プルリクを出すところまでは勉強会の中で扱った方がよい. |
| 06 | PIのIssueに従って学生・若手教員がプルリクを出し, コードレビューを受ける. |
| 07 | PIがマイルストーンを設定し, 学生・若手教員の進捗を管理する. |
| 08 | 学生・若手教員がIssueを出せるようになる. |
| 09 | PIがプルリクを出し, 学生・若手教員を補助する. |
| 10 | 学生・若手教員らでIssue消化, プルリク, コードレビューを行う習慣をつける. |
| 11 | 学生・若手教員らでマイルストーン管理, 研究を遂行する. |
その他のロードマップ
他に考えられるパターンを挙げておきます.
- 教授がコードをオープンソースとして公開したがっているが, どうしてもGit/GitHubが使えない
→ 若手が代理でアカウントを取得し, IDやパスワード等を教授に通知, 初回コミットのみ教授のアカウントで行い, 以降は自身のアカウントをCollaboratorsに追加して代理で運用. - etc.
注意点
- GitHubの規約からアカウントは1人1つまでなので必ず個人用のものを作りましょう(参考：全社的に会社用GitHubアカウントを廃止した件). エンジニアの匿名文化と研究者の実名文化で若干の相性の悪さを感じますが, いずれにせよ同僚や現実の友達に見られても恥ずかしくないハンドルネームをおすすめします. 私は研究者として生きていくことを腹に決めているので実名で作りました.
- リポジトリは必ずしもオープンにする必要はなく, 論文のLaTeXファイルなどはむしろクローズドにするべきでしょう. クローズドでもバックアップや共有の用途で意味があることは説明していきましょう. バージョン管理の意味はだいたい伝わらないので, それ以外の価値を伝えていくことをおすすめします.
- よく「個人で研究するだけならいらない」という人がいますが, 一度Git/GitHubを完全に習得した人は一人でもGit/GitHubを使います. 「最初からGitHubを使っておけばよかった」と後悔する前に習慣をつけることをおすすめします.
- 基本的には計算プログラムなどを管理し, 計算結果など重いデータは.gitignoreファイルに追加して, コミットしないようにします.
→ Git Large File Storageというものがあり, 重いデータも一緒に管理することは可能とのことです. - ソースコードだけでなく, Makefileやビルド方法をまとめたREADME.mdを内包しましょう.
- オープンソースでなくても, ドキュメントを書きましょう. 誰かに渡すことになるかもしれませんし, 次に見る頃には忘れて自分で書いたのに他人が書いたコードになっているかもしれません.
- Xで悪口を言われる前にテストを書きましょう.
- コードレビューも導入しましょう.
- 遺言としてライセンスを付与しましょう. MITライセンスがおすすめです.
- ホームページに関しては, FTP接続でアップロードできる状態になっていればGitHub Actionsで自動デプロイできます. ただしVPNは突破できないので, 事情によっては別の方法を考える必要があります.
まとめ
所属研でGitHubの導入を進めるにあたって, ボトムアップ型とトップダウン型の2種類の活用ロードマップを提案しました. 活用のノウハウがあればご紹介ください.
関連記事
執筆段階で参考にしたわけではありませんが, Git導入のために研修を開いたり上司を説得する手順が書いてあります. 義務教育でプログラミングを学んだ世代は間違いなく自分よりITリテラシーの低い先輩や上司を説得して新技術の導入を進めていくことになるので, 数年後に役立つと思います.
Discussion