# レビュー改善チーム用ポータル

[「各資料のURL」へ](#各資料のURL)

このプロジェクトでは「何のためにやるのか、なぜやるのか」を共有し
***ゴール【レビューの質が均一化し、PJで決定した内容にてレビューできていること】***
までの道のりを明確にできるように努力します。

---

どこでも自由に追記してください！！！！！(追記日と名前があれば神です)
> [time=Mon, Jun 29, 2020 8:18 PM, by Matsuo]
> [color=#68f27a]HackMDの機能で、こんな感じにコメントできます。by Matsuoは自分で書きたしました。

</br>

## 連絡事項(最終 7/28)
> [color=#68f27a](6/30 松尾)
> 2/29にオンライン講座のレビューが一つもされていなかった。
> 赤メンターで入ったばかりの人は、自分がレビューできる立場だと知らない人もいる。

>[color=#ff0000](6/30 日置)
>[Slackのリンク](https://infratop.slack.com/archives/GRN4J0WCF/p1593518627080600?thread_ts=1593491433.071800&cid=GRN4J0WCF)
> こちらの理由により、インデント必須化は取り下げになりました

> [color=#68f27a](7/1 松尾)
> 梶谷くんからレビューチームに提案が届いています
> 下記２つのURLを確認お願いします。
> 「レビューの割り振りについて」
> https://hackmd.io/x_oY1KieSRa4qSVosFhy4w
>
> 「チーム開発のレビューについて」
> https://hackmd.io/FX-1lajSQkuhFHpml0IzLg

>[color=#ff0000](7/2 日置)
>上記に関して、提出用の資料を工程を具体的に付け加えて作成しました。元資料の後ろにそのまま続けて記述しています。特に他提案や反対意見がなければ、川崎さんと松尾さんで最終調整を行って社員の方に提出をお願いします。チーム開発レビューに関しては、工程すら知らないかったので、かなり抜けています。青の方で練り練りしてください！

>[color=#68f27a](7/1 松尾)
>「現状」を「現状の問題点&解決方法」に変更しました。
>理由：各項目に対しての問題点を確認できる項目がなかったから
>
>また、「項目以外の問題点&解決方法」を作成しました。
>理由：「チェックポイント」「レビュー手順」などの項目に当てはまらない問題点を見つけるするため

>[color=#ff0000](7/4 日置)
>定例会で出た問題点　　
>改善案のQAリーダーの割り振りを伝達するときに、割り振られた側の把握漏れが多発する可能性があると指摘をいただきました。これについての対策も提出考える必要がありそうです。個人的には最初は、QAリーダーも質問割り振りと一緒に待機室に残って、割り振りしだい、待機室で口頭で伝えるのがいいかなと思います。質問の状況に応じて割り振ったり割り振らなったりする判断も任せるとか
>でもそれだと負担が多きすぎると思い考え中です。

>[color=#68f27a](7/6 松尾)
> チーム開発レビューのチャンネル統一について、社員に提出用のMDを作成したので、まとめ上げていきましょう！
> 好きに編集してください！
> https://hackmd.io/1EBXHsVZTLySokNkjCLOlA

>[color=#0000ff](7/11 川﨑)
> この資料はポータル化しました。今後の作業は各資料でお願いします。
> [各資料のURL](#各資料のURL)
> また、連絡事項は引き続きこの資料でお願いします。
>
> 勝手ながら、誰が追記したか分かりやすくなるようにと引用表記に色を付けました。誰が追記したかの表記は引き続きよろしくお願いします。
>>[color=#68f27a]松尾さんは最初に使っていたこの色です。
>
>>[color=#ff0000]日置さんは赤メンターということで赤です。
>
>>[color=#0000ff]それで川﨑は青です。
>
>> 篠田さんはお任せします。
>> 他の方も同様に好きな色を付けてください。

>[color=#ff0000](7/12 日置)
> ずっとテンプレートを作成していたのですが、チャレンジ項目の記述について、最初の方は、出来ていた点と出来ていなかった点を混ぜて、項目ごとに順番に記述する前提で書いていたのですが、後半は、できていた点と出来ていなかった点をそれぞれでまとめて書く事を前提として、文章を作成したため、違和感の塊だと思います。順次修正します。

>[color=#0000ff](7/12 川﨑)
> 「[チーム開発のレビューについて](https://hackmd.io/FX-1lajSQkuhFHpml0IzLg?both)」のレイアウトを大幅に変更しました。
> 「目的」「課題」「レビュー業務変更案」「メリット」「リスク」の５項目にまとめました。
> 「目的」は、特に変更ありません。
> 「課題」は、旧「現状の問題点&解決方法」で、解決方法に関しては「レビュー業務変更案」に移動しました。
> 「レビュー業務変更案」は、解決方法と提案をまとめたものです。
> 「メリット」と「リスク」は、「レビュー業務変更案」の項目ごとに検討できるように細分化しました。
> 下書きの変更に伴い、[提出用](https://hackmd.io/1EBXHsVZTLySokNkjCLOlA?both)のレイアウトも見やすくなるように修正しました。

> [color=#ff0000](7/13 日置)
> テンプレートにて
> ・「背景色の設定が出来てる」こちらのHTMLのチェックポイント、テンプレートを削除しました
> ・「横並びになっているか」をHTMLの必須項目に追加しました
> ・共通テンプレート、テンプレート具体例の項目を追加しました
> ・チェックポイントの表記を、分かりやすいように修正しました

> [color=#68f27a](7/28 松尾)
> 「２ヶ月目のテンプレート作成」「オンライン講座のわかりやすいレビュー方法を書く」項目は、今回のPJ範囲外であると隼平に確認いたしました！
> なので、このPJのゴールは、今作成中のテンプレートの落とし込みまでです！
>

> [color=#68f27a](8/4 松尾)
> オンライン講座　基礎知識学習フェーズのレビュー資料を追加しました。
>
</br>

## 目的

### チェックポイント(指摘箇所)

何　-> 受講生へのレビューを均一化するため。
　　　　レビュー箇所を明確にするため。

なぜ-> レビュー担当者の独自の判断で合否が決められている時があるため。
　　　　人によってレビューの内容が異なっているため。

### レビュー手順

何　-> レビュー担当者が迷う事なく、快適にレビューをするため。

なぜ-> 手順書を見ただけでは、理解できない箇所があるから。
      見にくくなっている箇所があるから。

### レビューのテンプレート

何　-> 受講生へのレビュー内容を均一化するため。
　　　　見やすくするため。

なぜ->レビュー担当者によって、言葉遣いや書き方が違い、見にくくなってしまうから。

### 施策の周知

何　-> PJで決めた施策を周知するため。

なぜ-> 周知をしなければ、均一化はできないから。
　　　　周知をできていないことがあるから。

</br>

## 現状の問題点・解決方法

問題点を思いつき次第、書き足してください

### 記述例
- [ ] 問題点
> 解決方法（記入者名）

</br>

### 全体
- [x] レビューが溜まって返却が遅れている
> [color=#68f27a] QAリーダーを２人にして抜け漏れをなくす[連絡事項に記載の提案より]（松尾）
>> [color=#0000ff] QAリーダーが１人の方が責任感を持って行えるのでは？（川﨑）
>
>>[color=#68f27a] こちらの項目は[QAリーダーの業務内容変更について](https://hackmd.io/x_oY1KieSRa4qSVosFhy4w)より解決できるため、チェックマークを入れておきます

</br>

### チェックポイント(指摘箇所)
- [ ] 問題点
> 解決方法（記入者名）

</br>

### レビュー手順(7/28現在不要な項目|松尾)
- [ ] オンライン講座のレビュー方法がわかりにくい、方法が書かれていない箇所がある（特にプルリクされた場所がわからない）
    > [color=#68f27a] よりわかりやすい資料を作る。動画付きの方がわかりやすい？（松尾）

</br>

### レビューのテンプレート
- [ ] 問題点
> 解決方法（記入者名）

</br>

### 施策の周知
- [ ] 全員にはできていないが、知らない人がいれば教えている感じ
> [color=#68f27a] いつでも確認できるような場所に資料を載せる（松尾）

</br>

### チーム開発レビュー(7/28現在不要な項目|松尾)
- [ ] レビューチャンネルが拠点ごとになっており、拠点ごとに返却時間の差ができてしまう
    > [color=#68f27a] レビューチャンネルの統一化[WIP]（松尾）
    > https://hackmd.io/1EBXHsVZTLySokNkjCLOlA
- [ ] 本来不合格の所が合格になっている
    > [color=#68f27a]明確なチェックポイントの作成
    > ちゃんと回答と照らし合わせてレビューを行う
    > 慣れてきたら回答を見ずにレビューをする人もいる
- [ ] 受講生から提出されたER図、設計書類が見づらく、レビューがスムーズに進まない
    > [color=#68f27a]受講生に対して、ある程度のテンプレートを用意する
    > 見本を用意するなどして、書き方を統一する。
- [ ] 前の設計書を合格していなくても提出するチームが多い。「チーム開発のレビューについて」より
    > [color=#68f27a]現状、「テーブル定義書はER図の初回提出が完了してから作成に着手してください。（手戻りを防ぐため）」とはありますが、提出するなとは言っていないため。
    > しかし、ER図合格でなければ、当然テーブル定義書もダメなので、メンター・受講生ともに二度手間になっている気がします。
→「2種類以上を同時に提出しないでください」あたりか。
- [ ] 提出物の形式を指定しておらず、numbersで出して、windowsユーザが見れないケースが以前よりしばしばある。「同上」より
    > [color=#68f27a]windowsでもnumbers見れますが、中途半端に手間です。
    > zipで送ってくる場合もなぜかあるので、draw.io(ER) / スプシ(他) / ドキュメント(コメントあれば)で統一した方が良いと思います。
- [ ] 他の担当者が書いたレビューの意味がわからない
    > [color=#68f27a]テンプレート化することで解決

</br>

## 優先度について
受講生のことを第一に考えると以下のような順位になる
（周知に関しては、最後に行うので優先度はない）

</br>

1. **チェックポイント**
- ここが間違っていると受講生の混乱を招き、最悪トラブルに繋がる

2. **テンプレート**
- レビューで正確な場所の指摘ができていればそこまで問題視する事ではなさそう
- でも、見やすさを向上させることは大切なので、改善は必要

3. **手順**
- 新メンターがレビュー返却をしやすくなり、レビューが溜まることを阻止できる

</br>

# 各資料のURL

## レビュー自体の周知
- [レビュー最優先事項](https://hackmd.io/vHIo5eO1TFCx3JBUcvwmBQ)

## QAリーダー
- [下書き用資料](https://hackmd.io/@wOcU_BAhSBCBTvQFWd9XMQ/ry0FkjZJv/edit)
- [提出用資料](https://hackmd.io/x_oY1KieSRa4qSVosFhy4w)

## チーム開発レビュー(7/28現在　不要な項目|松尾)
- [下書き用資料](https://hackmd.io/FX-1lajSQkuhFHpml0IzLg)
- [提出用資料](https://hackmd.io/1EBXHsVZTLySokNkjCLOlA)

## レビューテンプレート
- [レビューのテンプレートについて](https://hackmd.io/ePe8Mi4RRPer8gvNQrm17Q)
- [レビューテンプレート（チーム開発フェーズ）](https://hackmd.io/rmtd0LXaSzSDb8AyAn8uyA)
- [１ヶ月目テンプレートの周知](https://hackmd.io/@wOcU_BAhSBCBTvQFWd9XMQ/rySmBjMlv)

## 資料改善
- [オンライン講座基礎知識学習フェーズレビュー資料改善](https://hackmd.io/WyrS0GP7QqeN6mzLnqO2-A?both)

## テンプレート周知(最終業務)
- [チェックリスト / 周知状況報告](https://docs.google.com/spreadsheets/d/1DXXd_pPdwaBHJU1NN1bsecylHvy9vJUJICsgMtTxvmY/edit?usp=sharing

## Docbaseメモ
- [x] HTMLの画像挿入
- [x] Bookers1, 2のurl追記
- [ ] 注意書きを全てコードブロックの外に出す
- [ ] 注意書きのレイアウト整える
- [ ] 全体のレイアウト整える