概要
開発を行う上で、レビューへの取り組み方が人それぞれであったので、
レビューの立ち位置と、うまく使うために留意すべきことをまとめています
レビューはなぜおこなうのか？
- 大前提として承認を得るためではない
- よりよいプロダクトを迅速に開発するため
よりよいプロダクト開発のために
- 第三者の目を通すことで、多角的な視点を取り入れた開発が可能となる
- 自身のみの観点で素晴らしいものづくりをするのは非常に難しい
- よりよいプロダクトへの改善は他人から得られる気付きであることが多い
- 有識者の目を通すことで、より洗練された開発が可能となる
- ドメイン知識を深い有識者の意見を取り入れることで、よりユーザーに価値を提供できるプロダクトを開発ができる
- 技術的に知識の深い有識者の意見を取り入れることで、より体験性の高いプロダクト開発ができる
迅速な開発を行うために
- 第三者の目を通すことで、単純な抜け漏れを防ぐことが可能となる
- 自身だけでは気づけないミスや観点、ユースケースの漏れなどはどうしても発生する
- できるだけ早期に気づくことで、後段での手戻りを防ぐことができる
- 有識者の目を通すことで、不具合の発生を事前に防ぐことが可能となる
- そもそも不具合を完全に防ぐことはできないが、多くは知識不足や観点不足に起因する
- 有識者を使って事前にチェックしておくことで、不具合の発生を防ぐことができる
- リリース後に発覚した不具合の対応コストは、設計時点で発覚した場合と比較し、40倍~200倍に及ぶ
- 有識者の目を通すことで、最速でユーザーに価値提供することが可能となる
- 特定の機能をユーザーに提供するための方法は複数存在する
- 優先順位を適切に定め、価値提供のために必要な要素に注力することで、より低コスト早くユーザーに価値提供することができる
レビューの役割
- よりよいプロダクトを迅速に開発するためのツール
レビューを有効活用するために
(つまりは、よりよいプロダクトを迅速に開発できるようにするために)
- レビューしてほしいポイントは事前にまとめたうえで共有する
- より効率的に有用な指摘をもらうことができる
- ポイントがない場合、レビューアーは全体をまんべんなく確認する必要があり、結果的に議論すべきポイントに注力しきれない
- ポイントを事前に整理する過程で、改善の方法や確認すべき観点に気づくこともある
- 背景 / 前提を含めたうえで自分の考えを説明する、必要に応じて図やホワイトボード等も用いる
- 背景 / 前提、意図を伝えられていない状態で、有用な指摘をもらうことは不可能
- 筋違いな指摘をもらい、その指摘が筋違いだと説明しなくてはならない
- 背景 / 前提、 意図を伝えて始めて建設的な議論をすることができる
- 事前にレビューを受ける日時を計画しておく
- 成果物が完成後にレビューを受けるようにしていると、遠回りをすることが多い
- 時間かけて対応がレビューの結果、不要な対応だと判明することもある
- レビューの日時と目的を事前に決めておくと、不確定要素排除のための最短距離を駆け抜けることができる
- レビューアーの予定も事前に抑えておくと、依頼からレビュー完了までのリードタイムもなくすことができる
- 最後は必ず自分で納得したうえでどうするか決める
- 成果物に責任をもつのはレビューアーではなく開発者自身
- よい成果物に対して讃えられるべきは開発者自身
- レビューを有効活用し、よい成果物にするのも開発者の必要な能力
チームとしての生産性
- レビューのための準備は丁寧に
- 多くの場合においてレビューアー時間は貴重で有ることが多い
- 短いレビュー時間で有用な指摘事項をうけることは、チームの生産性向上に大きく寄与する
- レビューのための準備は、レビューのためだけのコストだけでなく、自身の成果物を見直し改善するためのきっかけとなることも多い
- ラフな状態でレビューしてもらう選択肢も頭にいれておく
- 時と場合によっては、成果物の完成度が低くレビューの準備もままならない状態でもレビューを実施したほうが良い場合もある
- 期限が迫っている場合や、どこから手をつけてよいか検討もつかない場合など
- その場合には状況を説明し、今レビューをうけることがチームとして生産性が高くなることを伝えた上でレビューをうける
- すべてはチームの生産性を最大化するために
- あくまで生産性向上のためのツールの一つ
- レビューアーのレビューコストもチームの生産性向上のために必要なもの
- レビューアー / レビューイーのコストも勘案して全体の生産性を最大化することを全メンバーが意識する必要がある