42Tokyoにて、前半の山場である1stサークルを突破しました。
（後半は2ndサークルと呼ばれています。）

入学してからいままで、4回ほどチーム課題に取り組みました。

その4回を振り返ると、うまくいったことや、あまりうまくいかかったことがあります。

それらを整理し、チームでのベストプラクティスとして5つにまとめてみました。

1. 徹底的にスケジュールにこだわる

振り返ってみると、一番おおきな失敗は「おわり」を明確にしなかったことです。

あるプロジェクトでは、最初に「いつまでに終わらせるか？」を決めていなかったためにだらだらとしてしまいました。

それゆえに、たったひとつの課題に4か月もかかってしまうということに...

また、スケジュールを明確にするには、ある程度の予想が必要です。

そんな時に役にたつのが過去の実績。

過去におなじ課題に取り組んだ他の学生に聞き込みをすれば、一体どれぐらいの時間がかかるかが大体わかります。

学生の力量や、社会人学生もいるので、課題についやせる時間のちがいがありますが、ある程度の信ぴょう性のある「課題をクリアするのに必要な時間」が割り出すことができます。

大きなゴールを決めたあとに必要なのが、それにいたるまでの小さなゴールを設定すること。

小さなゴール設定をしないと、優先順位があいまいとなってしまいます。

すると自分の興味にしたがい、課題とはあまり関係のないような調べものや作業に時間をつかってしまいます。

2. 一週間に一回はあつまる

一週間に一回は現実世界で集まり、情報の共有やすりあわせを行うことで、一気に課題をすすめることができます。

ほとんどの課題で、Discordをつうじて毎週一回、進捗確認をおこなっていました。

しかし、Discordは話すときに相手との呼吸の間合いをとらなければならなかったり、聞き耳をたてるのにも疲れます。

それにくらべ、リアルで集まると、チームメイトへの質問も簡単であり、まわりが作業しているならば、自分も頑張ろうとやる気をおこさせてくれます。

また、パソコンの画面をじかにチームメイトに見せ、困っていることを相談することができます。

チームメイトが解決策を知っていることが多く、すぐに困っていることへの糸口がみつかります。

（対面であうことにより、いままで知らなかったlazygitやGitHubの使い方をチームメイトから学び、作業スピードが加速しました。）

プログラマーとして駆け出しのときは、まずは会社につとめ、まわりのプログラマーに教えを乞える環境が大切、とどこかで読んだことがあるのですが、まさにその通りだと思いました。

あつまって一気に課題に取り組むことにより、チームメンバー全員が課題に取り組む時間を確保でき、困っていることもすぐに解決できる可能性が高いため、一気に課題をすすめることができます。

この「一気にすすめる」というのが意外と大事で、一度新しく学んだことは、使わないとどんどん忘れていくので、時間をかければかけるほど、最初に学んだことからどんどんと忘れてしまい、思い出すのに時間をつかわなければなりません。

3. 同じ釜の飯を食べてチームビルディング

現実であつまるということとつながってきますが、一緒にご飯をたべることで、チームメイトの人となりがわかり、チームビルディングを行うことができます。

チームビルディングを行うことで、気軽に質問しあえる雰囲気をつくることができ、コミュニケーションがはかどります。

また、一度でも対面であったことのある人には、その人へすなおに仕事を頼みやすくなります。

逆に一度も会ったことがない人へは、その人が担当の仕事だとわかっていても、仕事を頼むのに勇気がいります。

4. リーダーを決める

チームをひっぱるリーダーの存在が不可欠となります。

リーダーのおもな役割は以下となります。

・スケジュールの管理（期限に絶対に責任をもつ）
・Issueは誰がいつまでに取り組むのかを決める（担当者自身に決めさせる）
・メンバーのモチベーション管理（チーム内のいろいろな問題の解決）

じつはいままでチーム課題にリーダーが必要だとはいままで考えたことがなかったのですが、リーダーがいたほうが明らかに課題のすすみ具合がちがうと実感し、考えをあらためました。

5. PR(プルリクエスト)のマージのルールが必要

チームメンバーが二人であれば、一人がPRを出したら、もう一人がPRのレビューをおこなえばいいのですが、人数が3人以上だとPRをどうするかルールが必要です。

ルールがなければ、どんどんとPRがたまってしまい、作業が停滞してしまうことにもつながります。

マージのルールは、基本的には以下の2つかと思っています。

・コンパイルエラーがなく意図したとおりに動いており、mainとのコンフリクトがなければ、PR作成者がPR作成直後にmainにマージ
・一番経験がある人がコードレビューを担当する

前者はどんどんとmainがアップデートされていくので、作業がすすんでいる感があります。

あとでまとめてバグを修正していくスタイルです。

後者は時間がかかりますが、バグの発生をより少なくおさえることができます。

基本は前者で、マージ前にだれかからの確認を受けたいときだけ後者と、両方を組み合わせることもできます。

おわりに

今回は、チームで課題に取り組むときに必要な5つのことをまとめました。

42の2ndサークルでもチーム課題はあるので、折を見て今回の学びを見かえし、活用していきたいと思います。