研究進捗報告をGitHubでやってみた
研究室の学生さんが、各自で研究を進めているのですが、たまに些細なことで悩んでいたり（本人にとっては大きな問題なんでしょうけど）困っていることがよくあります。悩んでるなら質問や相談してよ、と思うのですが、なかなか心理的なハードルがあるのか、あるいはどうも悩んでいることに気づいていない、という場合もあるようで、下手をすると1ヶ月ぐらい、研究が止まっていることも、かつてはありました。ゼミの発表担当がだいたい月に1回なので、ゼミの時に、はじめてその状態が発覚したりするわけです。もちろん普段から研究室内、学生さんとのコミュニケーションを取るように心がけているつもりなのですが、「順調？」と聞いて「はい」と答えつつ、実は・・・ということが、割とよくありました。
それはよくないな、ということで、数年前から、「週報」という形で、週に1回、簡単な報告をしてもらうようにしていました。週報の準備に時間をかけるのは本末転倒なので、原則として
・資料（スライドなど）は作らない
・口頭でOK、短ければ数分で終わる
・進捗がなくてもOK、あくまでも現状把握が目的
という方針でやってきました。これはこれでそなりに効果はあったかな、と思います。（ただし、直近で起こっている問題があっても、週報まで待つ、というケースがたびたびあって、そういうことは週報とは関係なく随時質問・相談をするように、という心がけを周知徹底することは大切ではあります）なお口頭での週報をするタイミングは、去年までは随時（ゼミの前までには）だったのですが、今年度（特に前期）はコロナ渦下でオンラインでのやりとりがメインになったこともあり、普段から研究室のスケジュール管理に使っているGoogleカレンダーに「Appointment Slot」を設定し（だいたいゼミの前日）、そこに各自がアポイントを入れてもらうようにしました。
それでも、プログラムのバグや回路製作上の動作不良などは、口頭だけだと話がよくわからず、ソースコードや回路図を見せてもらうことが必要になり、そのたびにPCを取り出して・・・となります。また、口頭だけだと、前回どこまで話が進んでたっけ、というのを思い出すのに時間がかかったり、場合によっては、教員側、学生側の両方が、そんな話したっけ？や、どういう方針でいくことにしたんだっけ？となることもしばしばです。
そんななか、金沢工大の中沢先生が、GitHubで週報を含めた研究進捗の管理をしている、という話を伺いました。それを参考に（というかほとんどそのまま）、自分の研究室でも取り入れてみました。それと実は情報系の学科でありながあら、GitHubを授業や演習で使う機会がなく、下手をすると「GitHub？なにそれおいしいの？」という状態で卒業してしまう学生も、それなりにいてしまって、それはマズい、というのもあります。
やりかたの大枠
中沢先生のメソッドは、おおまかには以下のものです。
・GitHubに研究室のOrganizationをつくり、学生をmember(owner)に登録する（大学の研究室だとGitHub Educationを申請すれば利用できるので、プライベートリポジトリを自由につくれます）
・GitHubに進捗報告用のリポジトリをつくる（PublicでもPrivateでもいいのですが、対外公開しにくい内容を含む場合は、Privateのほうが安心かもです）
・学生ごとにブランチを切り、自分のブランチに、週報の文書と、関連するソースコード、設計データなどをコミットして蓄積していく
学生ごとにブランチを切る、というのがポイントで、これによって、学生ごとの別空間がつくられ、しかもブランチを切り替えることで相互に行き来ができます。
README.md
中沢先生のテンプレートを参考に、少し修正して、以下のようなREADME.mdをつくりました。GitHubをはじめて使う学生もいる（多い）ので、GitHubの始め方、ブランチを切るところから、週報の書き方（コミットからプッシュまで）をまてめています。
週報の文書
週報に書いてほしいことは、主に、前回からの差分（進捗）と問題点（あれば）、ですので、それらを箇条書きに書けるように、テンプレートを作っておきます。このテンプレートを、ファイル名の末尾に日付をつけて、週報としてコミット・プッシュしていきます（もちろん自分のブランチに）。
やってみて・・・
まだ運用をはじめて1ヶ月ぐらいですが、感想として「思ったよりトラブルなく使えて、けっこう便利」ということでした。
GitHubを使うのが初めての学生も多いのですが、基本的に一方的なコミット・プッシュだけなので、マージやコンフリクトといった、分散開発でありがちな（＆GitHubならでは）問題（？）はほとんど起こらず、少なくともGitHubの入口に入る、ということは、スムーズにいけたかな、という印象です。もちろん今後、彼らがGitHubを本格的に使うようになると、これらの問題に遭遇することになりますが、それはそのときに勉強してもらえばいいことですし、少なくとも基本操作と概念（の一部）はわかっているので、そのハードルは多少なりとも低くなるでしょう。
また研究の進捗管理・相談という意味では、2つのメリットがあると感じました。一つは、記録を残すことで、「あれはどういうことになってたんだっけ？」ということが格段に減りました。もう1つは、ソースコードや設計データをみながら、原因究明や方針の議論をしやすい、という点です。特にコロナ渦下でオンライン（ウチの研究室ではMS Teamsをメインで使っています）でのやりとりのときには、離れていても、同じ情報をみながら対話ができるのは、想像以上に便利です。
もちろんまだ運用をはじめて1ヶ月なので、今後続けていくと、まだまだ問題点や改善点も出てくると思いますが、それはまた追々、追記していきたいと思います。他にこういう方法をやってるよ、とか、こうやるといいんじゃ？というお話は、ぜひ感想欄でも私信でも結構ですので、お聞かせください。
この記事が気に入ったらサポートをしてみませんか？