NotebookOrigin

システム開発では、設計書やコードを作成すると「レビューをお願いします」と依頼する場面が頻繁にあります。 ところが、レビューを実施しているにもかかわらず、後工程になって重大な問題が見つかることがあります。 レビューの指摘が誤字脱字に偏っていたり、人によって確認するポイントが違ったり、レビュー会議の途中から修正方法の議論が始まって時間だけが過ぎたり……。 こうした状態では、せっかく時間をかけてレビューしても、本来期待している品質向上につながりません。 レビューは単なる「間違い探し」ではありません。 大切なのは、何を確認するためのレビューなのかを明確にし、適切な観点から問題を早い段階で発見することです。 以前受講した「システム開発におけるレビュー技法」の内容を振り返りながら、現在のシステム開発でも活用できるレビューの考え方を整理します。 そもそもレビューは何のために行うのか レビューの大きな目的は、成果物やプロジェクトの状態を「見える化」し、問題を早い段階で発見することです。 もちろん、作成者自身が成果物を確認するセルフレビューも重要です。しかし、自分だけで確認することには限界があります。 作成者にとって「当然」と思っている前提が、別の担当者から見ると曖昧かもしれません。技術的には正しくても、運用担当者から見ると実際の運用が難しい設計になっていることもあります。 そこで、異なる知識や経験を持つメンバーが成果物を確認します。 レビューには、不具合を見つけること以外にも、次のような役割があります。 認識のずれを発見する 暗黙の前提を明らかにする 設計の妥当性を確認する 知識や設計意図をチーム内で共有する 後工程への問題流出を防ぐ レビューは「詳しい人に間違いを探してもらう作業」ではなく、チームとして品質を作り込むためのプロセスと考えた方がよいでしょう。 「プロセス」と「プロダクト」の両方を見る レビューというと、設計書やソースコードなどの成果物をチェックすることを想像しがちです。 しかし、見るべきものは成果物だけではありません。 大きく分けると、「プロセス」と「プロダクト」という2つの視点があります。 種類 確認するもの 例 プロセスレビュー 開発の進め方や状態 進捗、課題、リスク、品質状況 プロダクトレビュー 作成した成果物 要件定義書、設計書、コード、テスト仕様書 例えば...