サウスポーなエンジニアの独り言

サウスポーなエンジニアが日々感じた、気づいた、学んだことを徒然と書いています。

仕事のやり方 旧館より 開発プロセス

「レビュー」タスクの見積もり

投稿日:2010年8月14日 更新日:


1~3年目のような経験の浅い方が見積もる「レビュー」タスクの工数について思うことがあります。

レビューはある成果物…提案書や設計書、ソースコードなど…を個人/複数のメンバー…たいていはプロジェクトリーダやプロジェクトマネージャなどの上司や有識者…と行います。
成果物の内容や分量にもよりますが…例えば、(類似機能がない)新規の外部設計書…だいたい「一発合格」はなく、いくつかの指摘事項があるものです。
指摘事項は「て・に・を・は」や語尾の不統一…こういうのはセルフチェックでつぶしておきたいものです…から、設計内容自体に対するものまで色々です。

それらの指摘に対して、対応要否の判断、要であれば対応が必要になります。
例えば「語尾が不統一」と指摘されれば、見直して修正する必要があるでしょう。

また「ここのA機能は、XXモジュールから流用すると書いているけど、YYという視点では確認した?」と質問があり、自分が「YYという視点」で確認していないのであれば、調査(とその結果の報告)が必要になります。

というように考えると、レビュー後にもそれなりの工数が必要になります。また指摘事項によっては、再レビューとなり、そういう工数も必要になります。

そういう特性の「レビュー」タスクを経験の浅い方が見積もると「レビューは一発合格、あっても文字の修正ぐらい」というイメージとなっているように思います。
#考え方として「レビューでの指摘事項はありません!」という気概で望み、目標にするのは良いことです。

私が「レビュー」タスクの見積もり工数を(作業前に)確認する場合は「どんな作業イメージしてる?」と問いかけるようにしています。
たいがいは「レビュー受けた後はちゃちゃっと修正して…」と答えが返ってきます。
 
そこで、過去に自分のレビューを「そんな感じ(ちゃちゃっとで済む)だった?」と思い返してもらい、その根拠や妥当性を深掘りしていきます。
その結果、なるほど~と納得できるならそれで進めてみます。
#チームとしては多少バッファを持つようにしますが。

これらレビュー後の対応工数、タスクはスケジュールに明確には乗らないことも時々ありますので注意が必要です。
#「レビュー」自体に紛れ込んでいたりします。

※注意:この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。

Photo credit: ivyhouse.jesse via Visualhunt / CC BY

-仕事のやり方, 旧館より, 開発プロセス

執筆者:


comment

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

関連記事

新しいチームリーダーのことを社内SNSで知った

12月頭に全社横断的に(主に開発工程の)生産性向上をミッションとする部門に異動になりました。 で、「まずは顔合わせを…」ということになりました。 新しいチームで一緒になるチームリーダー(上司)は分かっ …

1回の会議・打ち合わせで必ず結論を出す技術[読書感想]

1回の会議・打ち合わせで必ず結論を出す技術 著者:斎藤 岳 題名の通り、会議/打合せでいかに(参加者全員が納得し、次のアクションへつながる)結論を出すかを書いています。 ◆目次 第1章 「結論を出す能 …

チケットの粒度が難しい

過去のメモを整理していたところ、2年程前のプロジェクトで悩んでいた時に書いたメモが出てきたので備忘録としてアップしておきます。 悩んでいたこと RedmineやTracなどのITS(Issue Tra …

プロジェクトにおける「割れ窓理論」

環境犯罪学上の理論に「割れ窓理論」というのがあります。 「建物の窓が壊れているのを放置すると、誰も注意を払っていないという象徴になり、やがて他の窓もまもなく全て壊される」(Wikipediaより) 有 …

テーブル設計の指針(備忘録)

最近、DB設計やデータモデリング等のDB周辺について集中して触れることがあったのでテーブル設計における指針を備忘録として書いておきます。 サロゲートキーとナチュラルキー 主キーの設定時に大きく2つの設 …

ギルドワークスの現場コーチ。
「正しいものを正しくつくる現場を増やす」ことを目指している現場コーチ。認定スクラムマスター(CSM)。
様々な規模のSIerでのシステム開発を経て今に至る。
DevLOVE関西を主催。