日報および振り返りから得られた知見

よかったこと

  • 先輩の公開していた参考記事がとても分かりやすく最初の入り口にとてもよかった
    • 記事は、先輩が開発に関わり始めた当初に欲しいと思った情報をまとめている
  • 先輩から教えてもらったコマンドのおかげでできたことが色々あった
  • 開発環境はきちんとあわせられるとスムーズにはじめることができる
  • 取り組むタスクをこだわらずに、やりやすいように調整できたことがよかった
  • 先輩が取り組みやすそうなタスクを選び、タスクを二人で読んで、デバックの方向性を提示してもらうと取り組みやすい

気になったこと

  • MariaDBだけじゃなくオープンソースプロジェクトは最初のビルドが分からなかったり、うまくいかなくて続けられなくなることが多い
  • 開発環境がそろわないと大変かもしれない
    • 準備をしてあげるのもありかもしれないが、準備をしてあげると継続につながらないかもしれないというジレンマ
  • 新人にとって手ごろなタスクを探すのがオープンソースプロジェクトは結構難しい
    • 簡単すぎるわけでもなく、再現しなかったり、根が深くなかったりするものが少ない

こうすればもっとよくなるかも

  • MariaDBの公式に連携できていくといいのかもしれない
  • 新人が実践した最新の構築パターンをまとめられるとよい
  • 新人が聞いてよかったこと（資料や秘伝のコマンドなど）がまとまると、次の人たちがやりやすくなりそう
  • 先輩が、はじめてのひとにとってよいissue（やりやすい）をオープンにおすすめすると、新しい人がプロジェクトにはいりやすくなるかもしれない
    • Twitterでお知らせするとやってくれる人がいたりする

日報を書くということについて

  • Gitにpushするのが日報の更新の障壁になっている
    • 一回、issueに書いて、コメントでのやりとりで行う形をためしてみる

その他

...

進め方の方向性に関して

方向性を調整するためにすること

  • やろうとしていることと、やっていることの方向性はあっているのでこのまますすめていく

日報から得られた知見の活かし方

  • 日報のやり方をissueにコメントしてもらう方式に変更する

今回のふりかえり期間で得られた知見

よかったこと

  • 先輩が事前にissueを見てから新人に共有する方式と、一緒に初見で見てみる方式を両方試してどっちがよさそうかわかったこと

気になったこと

  • オープンソースプロジェクトの新人に手ごろなタスクを見つけるのが意外と難しいこと

こうすればもっとよくなるかも

  • 実際に取り組んでみないと新人が取り組むのに向いているかどうかのタスクレベル判断が難しいので、目安時間を決めて深追いが必要そうだったら、先輩に戻すというのをやってすすめられるタスクを探すのがよさそう
  • 新人は意外とひっかかったときにコミュニティのJIRAにもう少し書き込むのをやったほうが、コミュニティ内のプレゼンスや、やり方になれることにつながる
    • GitHubのDraft機能などの活用し先輩以外からの意見もきいてみる

その他

  • 落選した人でもやってくれるひとがいて、潜在的にやりたいと思った人に参加してもらうチャンスになった
  • 一人だけ選ぶのでなくてもいいのかも。デバックをみんなで見てもらってタスクはリストをつくって、それぞれ選んで逐次やってみるというのも考えられるかもしれない。 ...

今回のふりかえり期間で得られた知見の活かし方

  • 新人の環境構築のやりかたや教えてもらって参考になた資料は将来的にまとめて公開する
  • 次回以降、先輩に負担のない形で何人か一緒に取り組める形の検討