勘と経験と読経

略すとKKD。ソフトウェア開発やITプロジェクトマネジメントに関するあれこれ。

設計レビューは間違いだらけか?

書籍「間違いだらけの設計レビュー」を読んだ感想と、その後に調べたり整理したことについてのメモ。設計レビューは間違いだらけではないと思うけれども、非効率な作業になっていることが多い。専任レビューアー、専任レビューイーという役割は基本的にないはずで、誰もがレビューする側、される側のどちらにも立ちうる。であれば、すべてのソフトウェア開発従事者が読んでもいいような本だと思う。ちなみに現在Kindle版がほぼ半額のセール中。おすすめ。

目的の無い作業はすぐに無能化・形骸化する

以前から、ソフトウェア開発の中でも設計レビューは特に曖昧な部類に入ると思っていた。

  • ツール等が必要とされるわけではなく、一見すると「誰でもできる」
  • チェックリスト程度は準備されていることがあるけれども、他の支援ツールは無い
  • 作業計画上「レビューすること」はなんとなく決まっているけど、目的や細かい進め方は決まっていない
  • 事前の準備(スキル獲得)など無く、年を経るといつのまにかレビューする側になっている

本書でも指摘あるとおりだと思う。

「レビューのスキルは、ITエンジニアとして知識を得て開発経験を積み、レビューを担当していくうちに身についていく」――。この誤った考え方がはびこっているため、レビューの改善が妨げられているように思います。
なぜ重大な問題を見逃すのか?間違いだらけの設計レビュー改訂版(日経BP Next ICT選書) 第2章 準備と問題検出、より

本書では、

  • 目的を明確に … 不具合の修正コストの低減
  • 摘出する問題種別を定め … 漏れ、曖昧さ、誤り、及び個別具体的なもの

ることで、効果的な設計レビューの進め方が示されていて非常に参考となる。

シナリオを用いた設計レビュー

というわけで同書は設計レビューのTips集としても非常に役立つものだと思うが、興味深いのは開発するソフトウェア固有の不備を検出するのに「シナリオベース」のレビューを取り入れている点だ。これは非常に興味深かったので、読了後にもいろいろと調べてみた。

自分なりにまとめると、こんな感じ

  • 「シナリオベースのレビュー」とは、具体的な不具合摘出を狙って作られた「シナリオ」に基づいて行うレビューのこと
    • 「シナリオ」はレビュー観点とは異なる。汎用的なものではなく、対象のソフトウェアに即して作る
    • 見逃したら困る不具合を狙い撃ちにする
    • 簡単な問題の摘出を目的としてやるものではない
  • レビュー結果に加えて「シナリオ」がアウトプットとして残るのが特徴
    • どのような「シナリオ」でレビューが実施されたかを事後確認できる

コードに対してテストコードを用意するように、設計ドキュメントに対して準備された確認点が「シナリオ」であるというように理解している。
これはぜひ機会があれば取り組んでみたいと考えている。