読者です 読者をやめる 読者になる 読者になる

品質を上げたいなら、「レビュー」よりも「検討会」に力を入れよ

以前に、以下の記事を書きました。

これは、今までのやり方を少し変えるだけで、プロジェクトマネジメントの効果を向上させられる良い例でしょう。

ソフトウェア開発プロセスの中では、同様のことが言えるケースがたくさんあると思っていますが、私がこれまでに気付いたノウハウをまとめてみたいと思います。


今回は、まず、レビューについて。

レビューは、大抵のベンダー/SIerでは実施されていると思います。
レビューの目的は、上流工程における不具合の除去、要件の明確化などだと思いますが、なかなか効果が上がらないと感じている人は多いのではないでしょうか?

レビューのやり方については、議論されることも多いですが、そもそもレビューだけで問題を解決しようというのに、無理があると感じています。


そのため、私は、設計工程の最初で「設計検討会」を行うようにしています。

これは、

  • 要件は十分に仕様化されているか?
  • どのようなアーキテクチャにすべきか?
  • 設計上のリスクは、どのようなところにあるか?
  • 制限事項は何になるか?

など、設計書を書き上げる前に、システムに対するイメージを具体化する作業です。


設計検討会を実施することによるメリットは、以下の点があります。

  • 既に記述された設計書へのレビューではないため、書かれた内容に閉じた思考にならず、オープンな思考で議論できる(人は、書かれたモノがあると、それに閉じた視点でレビューをしがちである)
  • 誤字・脱字の指摘といった、本来、設計品質に影響が低い指摘で、無駄に時間が取られることがない
  • レビューの修正による手戻りを避けることできるため、時間が無くなって品質を疎かにしたり、無駄な記述をしたりすることがない
  • スキルがまだ不十分な人が設計をする場合には、教育にもなる


「ドキュメント(設計書)を書く」=「設計」と捉えられがちですが、本来、設計とは、その前段階にある思考を整理することだと思っています。
その段階で、十分にシステムのイメージを練ることをすれば、大きく方向がずれたり、仕様を見落としたり、ということが少なくなります。

私の場合、基本設計(もしくは、外部設計)では、検討会を2〜3度実施しながら設計書をまとめていきます。

  検討会 → ドキュメント記述 → 検討会 → ドキュメント記述 ・・・ → レビュー

といった感じ。

#ウチのプロセスはウォーターフォールベースですが、上記を考えると、アジャイル的な要素が入っているかなぁ。

短納期化/低予算化/複雑化のため、最近の開発では、レビューを十分に行えるだけの期間・工数を確保するのが困難になっていると思います。
そのような状況においても、上流設計での品質を上げたいと思うなら、レビューよりも前に、検討会を実施する方が効果的です。