もうすぐ産休をいただく志賀です 
今回は、「設計ができるようになる！」という目標のもと取り組んでいる「todoレビュー」についてお伝えします。
当たり前のような内容ですが、何かお役に立てばと思います！
1. issueにアサインされる
（例）issue名「お問い合わせフォームの作成」
※開発部では、GitHubを使って開発をしています。
細かい仕様もコメントで共有してもらいます。わからないことがあれば随時issue上で確認をします。
2. todoを考え、書き出す
（例）
todo
- FormTypeの作成
- Twigテンプレートの作成
- Controllerの作成
- サービス定義
- 動作検証
（PHPチームではSymfonyを使用しているためこんな感じになります。）
私はこの時、既存コードやテストを見たりしたりして追加するコードを整理しています。
似た機能が既にあれば、それを参考に考えることが多いです 
3. todoレビュー依頼を出す
todoをレビュアーにレビューしてもらいます。
ここで、助言や意見があればコメントをもらいます。
4. 実装
okをもらったtodoに沿って、実際にコードを書いていきます。
todoリストのリスト単位（FormTypeの作成・テンプレートの作成…）でプルリクを出すと大きなプルリクになりにくいです。
メリット 
- 設計(todo)と実装をきっちり分けることで、それぞれをじっくり考えて取り組める。
- 設計(todo)を言語化する機会が生まれるので、必然的に頭の中を整理ができる。
- あとで見返せて、振り返りができる。
- 答え合わせ感覚で設計(todo)の確認ができるので、モチベーションがあがる。
- 予想外の事が起こらない限りレビュー済みのtodo通りにコードを書いていくので、コードレビューでの手戻りは少なくなる。
- todoとして書き出すことで、設計だけでなくリリースまでに必要な作業系のやるべきことも明確にできる。
- todoを考える時に、どう設計したらいいかわからないなどの相談がしやすい。
デメリット 
- レビューが2回(todoとコード)となるので、レビュアーの負担が大きくなる。
さいごに
上に挙げた通りレビュアーの負担が増えますが、確認が細かくできるのでコードレビュー時点での手戻りが減ったりとレビュアー・レビュイー双方のメリットが多いのでとってもいいと思います！！！