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

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

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

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

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


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

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

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

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

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

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

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

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

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

Photo credit: ivyhouse.jesse via Visualhunt / CC BY

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

執筆者:


comment

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

関連記事

技術者の直感を信じてみては?

プロジェクト…特に詳細設計やプログラミングなど技術者がフル稼動する工程…において、経験豊かな技術者の直感が働くことがあるようです。 その直感とは「あ、(この仕様、実装は)このままではまずいのでは?」と …

見える化

「可視化」と「見える化」

先日「プロジェクトファシリテーションパーティ2012」に参加してきました。 #参加した皆さん、お話していただいた皆さん、スタッフの皆さん、ありがとうございました! 参加したセッション マルチセッション …

自分のテンションを維持する方法

コンピュータは基本的に調子の波がなく、いつでもいつまでも同じポテンシャルを発揮してくれます。 #CPU100%は「調子が悪くポテンシャルが低い」と表現できますが、ここではそんなことを言いたいのではなく …

コツ

最初に行う3つのプラクティスと継続していくコツ

このエントリは? このエントリは達人出版会から出版された電子書籍【開発現場に伝えたい10のこと】で私が書いた内容を許可を得て転記したものです。 2014/01/14(火)にはDevLOVE関西で書き手 …

自分憲法

#ソース元は「一生かけて取り組むべきものが分かる“自分憲法”の作り方」です。 自分のことを考えてみると「楽しく、成長しながら仕事をする」というのがそれと思っています。 #この「自分憲法」の考え方は、( …

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