1～3年目のような経験の浅い方が見積もる「レビュー」タスクの工数について思うことがあります。
レビューはある成果物…提案書や設計書、ソースコードなど…を個人/複数のメンバー…たいていはプロジェクトリーダやプロジェクトマネージャなどの上司や有識者…と行います。
成果物の内容や分量にもよりますが…例えば、(類似機能がない)新規の外部設計書…だいたい「一発合格」はなく、いくつかの指摘事項があるものです。
指摘事項は「て・に・を・は」や語尾の不統一…こういうのはセルフチェックでつぶしておきたいものです…から、設計内容自体に対するものまで色々です。
それらの指摘に対して、対応要否の判断、要であれば対応が必要になります。
例えば「語尾が不統一」と指摘されれば、見直して修正する必要があるでしょう。
また「ここのA機能は、XXモジュールから流用すると書いているけど、YYという視点では確認した？」と質問があり、自分が「YYという視点」で確認していないのであれば、調査(とその結果の報告)が必要になります。
というように考えると、レビュー後にもそれなりの工数が必要になります。また指摘事項によっては、再レビューとなり、そういう工数も必要になります。
そういう特性の「レビュー」タスクを経験の浅い方が見積もると「レビューは一発合格、あっても文字の修正ぐらい」というイメージとなっているように思います。
＃考え方として「レビューでの指摘事項はありません！」という気概で望み、目標にするのは良いことです。
私が「レビュー」タスクの見積もり工数を(作業前に)確認する場合は「どんな作業イメージしてる？」と問いかけるようにしています。
たいがいは「レビュー受けた後はちゃちゃっと修正して…」と答えが返ってきます。
そこで、過去に自分のレビューを「そんな感じ(ちゃちゃっとで済む)だった？」と思い返してもらい、その根拠や妥当性を深掘りしていきます。
その結果、なるほど～と納得できるならそれで進めてみます。
＃チームとしては多少バッファを持つようにしますが。
これらレビュー後の対応工数、タスクはスケジュールに明確には乗らないことも時々ありますので注意が必要です。
＃「レビュー」自体に紛れ込んでいたりします。
※注意：この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。
Photo credit: ivyhouse.jesse via Visualhunt / CC BY
コメント