After_review.md

Workout_2019 について2019/08/09 に行った反省・感想を来年のためにまとめ

https://scrapbox.io/furukawa-lab/Workoutの反省・感想 から

Workout をスムーズに進めるための、質問しやすさはどうつくるか

課題

• 質問内容を整理しないと質問できない、と思って質問するのに時間がかかってしまったかも
• 質問しようという意識にならなかった

解決案

• パートナー的な存在がいたら聴きやすかったかも
• ステータスのインジケータみたいなの導入してみる
• 質問チャンネルをつくってみる

スキルやメニューについて

これが欲しかった、というメニューやスキルはあった？

• 理論のメニューについて勉強会のみではなく実装も欲しかったと思う
• 早い時期に、Qiita投稿をして記事の投稿に慣れる機会があると、最後の時期の負担が減るかと思う
• 理論関連もメニューでやったことをgithubで提出をmustにすべきだったと思う
  理論の方もmustになっていたが、抽象度の高い投げかけになっていて提出しづらかった可能性

線形代数のプルリクあんまり出てなかったけど…？

• やらなきゃいけないという意識はあったが、他の飛びつきやすいやつを優先して後回しにしてしまったかも
• 理論の方について、抽象度の高い投げかけ(勉強会)だったのは確かだったかなと

メニューはちょうどよかったか？

• 玄人まではあっていいと思う
• 最終的に到達できるかどうかは別として、行き先の目印としてよいかと

最低限やってほしいラインはわかったか？

• 最低限とかはあまり考えず、ただがむしゃらにたくさんやろうとしていた
• コースなどでラインがあるのはなんとなく把握してたけど、それを意識せずにあるものをやった

何をやればいいかわかった？わからなくなったときは質問できた？

• 何をやればいいか細かく書いてくれていたので、メニューに取り組む分には大丈夫だったと思う
• メニューをこなす手順には困らなかった
• 自由度は高いが、選べないからしらみつぶしにやっていた

提示されているスキルを意識して取り組めたか？

• スキルを意識していれば、勉強会での迷いがなかったかも

線形代数のスキル獲得は上手くいったか？

• 勉強会だけでは中々難しいと思う。やり方に工夫がいるかと思う。

報告会

• 報告会のIssue出すまでに身構えちゃうのはよくない。スライドを作るために何を調べるかとかを適当に投げる感じで書くby M1

Workoutの趣旨やシステムの周知について

trainee側とtrainer側で認識の相違はなかったか

• trainee 側はシラバスを読み返すことがほとんどなかった

復習会(火曜・午前)について

授業の最初から進める流れでいいのか? (最初の数回はそうならざるを得ない?)

• 本読み会みたいに進行役を決めて, 誰かが全体の流れを説明してくれたほうがいいのでは
  そうすれば、まとめがおわった残りの時間に数式追ったりできる
  それをプルリクとして出せばよいか

Githubを活用するなりして要点を絞れないだろうか

• 言い出しっぺはtrainer側なので、この辺の「自主的に運営していく」というニュアンスをどれだけ事前に伝えられるか
• 目的は「スキルの獲得」であって、そこはブレずに「やり方を自分たちで作る」ということをどうやって理解させるか

メニューとして入っていたものではあるが、取り組みにくそうだった

• 抽象度が高いので、自分で見つけて取り組めるタイプと露頭に迷うタイプに分かれていた気がする

M1同士でモチベーションを維持できるようにお互いに気を配り合うことが難しい

• trainer側ははどのようにサポートするといいだろうか

運営方法

Githubは有効だったか

重要度が2段階(3段階)に分かれてレビューできるので, 何がマストの修正か分かり易かったはず?(どう?)

• Approve, Comment, Request changesの3つ？

Githubを利用するのは研究管理の練習として、という意味もあったが、M1からするとIssuesを立てるのはかなり心理的な障壁が大きかったらしい

• テンプレをあんなかっちり作ったのがよくなかったか？
• やらなきゃ、って思いついたことをボンボン投げるぐらいの感じで良いと思う →　README.mdに書いてなかった。書いておこう
• 勉強会、最初Issue出して終わりだと思ってた、あとでミニレポートを出さなきゃいけないというのを気付いた時には溜まり過ぎてヤバかった

今回Githubを無理くり導入したが、どれだけ真面目に研究の作業を管理しなきゃいけないかはまた検討する必要がある

• Githubをmustとすることは現状ないが、、、
• 周りの人のアクティビティが見えるので、自分のモチベアップにつながる人もいる

まとめレポートのレビューのやり方

HackMDのコメント機能を活用していたが、以下のポイントがしんどかった

• 「ここ」とピンポイントに指定してコメントするのが面倒
• 自分で一旦見たとして、どこにコメントが新しく来ているのか分かりにくい
• Githubと直結していない
  当初、ATOMのmarkdown プレビューで各々見るという案もあった
  →　Githubで履歴が残るという意味ではこっちの方が良かったかもももも
  →　ATOMのセットアップのフォローは必要だが
• 無限に続く
  昨年までだと一往復で済んでいたが（紙なので）、Github, HackMD上でやるとラリーができてしまう
  [- レビュー側は、コメントに対する返答は別に欲しくない]まぁレビューしてて疲れてくる

【改善案】

• pdf出力して各々のiPadで手書きコメントする
  去年(2018年度)のM1修論と同じやり方 Githubとの連携はビミョー

全部の記事レビューするのは結構しんどいかも。

• やりとりの回数とか含めて、この辺のルールは要検討

テーマ自由にしたことについて

• 皆テーマ自由にしたのはさらっと読む分にはとても面白いが、レビューするとなると1つ1つの記事のお気持ちに想いを馳せる必要があるので、頭の切り替えが結構大変だったかも。

Reviewerの負担が一点集中！！(主にwatanabeさんに)

• Reviewerの担当は運営側があらかじめ決めた方が良いかも
• 全員が全部見るのは毎年なのでとりあえず置いといて、スケジューリングはちゃんとしたほうが良さそうだなと思った
• 早くやろうとすると全部の記事がレビュー1人目になってキツい
• 基本的には下の学年から先にレビュワーにならないと、指摘するポイントなくなっちゃう
  →　M2の指導が遅かったのは、Github慣れてないとレビューすることも慣れてなかったという要因もありそうです

誰をレビューに立てて、誰を立てないべきかの共通認識を作ってなかった

• 例えば何のコメントもなしにフロリアンをレビュワーに立てても、フロリアン困ってまうやん、って話

Re-requestは注意する必要がある、どれが終わってるのかよく分からん

広報部門のAdvent carendarとの連携について

• 先生との事前確認（エビデンスありの）を早めにして安心してやりたい！
  これに限らず、先生の「学生たちが何かを勝手にやってるのに対してちょっとザワザワしちゃう」って感じは全般的にあるので、隔週とか月一でいいのでラボ運営の報告会みたいなのしたほうがいいかもしれません
  ↑ PRもいまいちそういう場として機能できてない
• PR後にステアリングミーティングをしましょうと先生から提案がありました
• (運営側) Qiitaの公開時期は本記事の締め切り日後にすべきでした。夏休み中にM1がアップするようにずらせばよかったですね。
  夏休み前にやったこと自体は良かったと思うけどね
  来年はもっと事前に調整できるので、この時期にカレンダーすることを見越してレビュー期間を設定できるはず
• qiita記事、発表、テスト(授業)、SOMf勉強会と重いのが重なってしんどそう

「スキルを獲得できた」ことをどう評価するのか?

• Qiitaなどのミニレポートで評価
• 表などで見える形でGithub上などで表示する