# チーム開発のレビューについて

## 目的
### 受講生：全拠点で同価値のサービスを提供する
- レビュー返却の順番を全拠点で公平にする
- 全拠点、等しくレビューする

### メンター：業務の負担を減らす
- 無駄の工程をなくす
- 他拠点のレビューをフォローしやすくする
- 翌日の13時のレビュー数を削減する

</br>
</br>

## 課題
- チャンネルが拠点ごとにわかれているので、多拠点のレビューをフォローしづらい
- 前日分のレビューがかなりたまることがある
- 20時以降に提出された分
- 拠点によってレビュー返されるの早かったり、遅かったりする
- 前の設計書を合格していなくても提出するチームが多い
- 現状、「テーブル定義書はER図の初回提出が完了してから作成に着手してください。（手戻りを防ぐため）」とはありますが、提出するなとは言っていない
- もちろん、ER図が合格でなければ、当然、そのER図をもとに作った、テーブル定義書も不合格なので、メンター・受講生ともに二度手間になっている
- 提出物の形式を指定しておらず、numbersで出して、windowsユーザが見れないケースが以前よりしばしばある
- windowsでもnumbersを見ることができるが、中途半端に手間

</br>
</br>

## レビュー業務変更案
1. **レビューが届くSlackチャンネルを全拠点統一する**【[メリット](#1.-レビューが届くSlackチャンネルを全拠点統一する)｜[リスク](#1-レビューが届くSlackチャンネルを全拠点統一する1)】
2. **全拠点、21時まではレビューをする**【[メリット](#2.-全拠点、21時まではレビューをする)｜[リスク](#2.-全拠点、21時まではレビューをする1)】
- 受講生さんには引き続き、19時以降は当日に返せるとは限らないと伝える
3. **提出の形式をスプレッドシートに統一し、URLでやりとりする**【[メリット](#3.-提出の形式をスプレッドシートに統一し、URLでやりとりする)｜[リスク](#3.-提出の形式をスプレッドシートに統一し、URLでやりとりする1)】
- ER図に関しては、draw.ioを利用する
- スキルアップ研修と同じ仕組み？
4. **合格をもらうまで、次の課題の提出を禁止にする**【[メリット](#4.-合格をもらうまで、次の課題の提出を禁止にする)｜[リスク](#4.-合格をもらうまで、次の課題の提出を禁止にする1)】
- ただし、進める分には問題ない

</br>
</br>

## メリット
### 1. レビューが届くSlackチャンネルを全拠点統一する
- 手の空いているメンターを有効活用できる

</br>

### 2. 全拠点、21時まではレビューをする
- 13時のレビューの忙しいさを緩和できる

</br>

### 3. 提出の形式をスプレッドシートに統一し、URLでやりとりする
- 様々の形式の提出を抑制できるので、作業工程が減らせる
- 受講生の環境に依存せず、誰でも利用できる

</br>

### 4. 合格をもらうまで、次の課題の提出を禁止にする
- メンター、受講生とも、二度手間をなくせる
- 課題の提出量が減少することで、レビュー数を制限できる

</br>
</br>

## リスクとその解決策
### 1. レビューが届くSlackチャンネルを全拠点統一する

</br>

### 2. 全拠点、21時まではレビューをする

</br>

### 3. 提出の形式をスプレッドシートに統一し、URLでやりとりする

</br>

### 4. 合格をもらうまで、次の課題の提出を禁止にする

</br>
</br>

## 必要な作業
- チャンネルの統一
- メンターに施策の周知
- チャンネルを統一すること
- 21時まではできるだけレビューするように