今回は当方メルマガ内の記事を転記します。
メルマガ⇒2013年向け情報処理試験プロマネ完全対策
情報システム開発の設計レビュー観点
皆様は、システム開発におけるレビュー（特に設計工程）では、どのようなポイントでチェックを行っていますでしょうか。
レビューの観点やチェックポイントというのは、しっかりと文書化されている組織もあると思いますが、それでも多くの部分は「属人化」されているような気がしています。
実際、経験や知識によって勘が働くことが重要な分野であると思っています。
多くの人は自分がレビューイの立場で、これまでに様々なレビューアから指摘された中で、繰り返し指摘されたもの、視点の高さを感じた指摘内容、納得した指摘内容などなどを、自分の引き出しとしてしまっておき、それをレビュー時に問う、といったことが多いのかと思います。
私の考える、最も重要で汎用的なレビュー時のチェックポイントは３つあります。
レビューの３つの観点
１つは、検討対象となるスコープが適切であるかどうかです。多くの場合、このスコープの認識に漏れや誤りがあるために、設計漏れなどが発生します。スコープをきちんと認識していれば、ほとんど設計漏れなどは発生しません。
なのでレビューの一番最初にこのスコープを確認します。ほとんどの場合、スコープが狭すぎて、更なる検討アイテムが増えることになります。そして、こうした指摘がレビューの指摘の半分以上を占めていると考えます。
２つ目は、検討対象になっている機能やシステム要素を漏れなく設計・調査できているのか、という網羅性を確認します。
一番いいのは検討対象となる要素をすべてマトリクスに表記し、挙動について記載することです。何かの機能を設計する場合は、その機能に何らかの形で影響する他の機能やシステムの状態、他の装置などをリストアップします。
そしてそれらのバリエーションの全ての組み合わせをマトリクスで網羅します。バリエーションが多くて網羅するのが困難な場合は、事前に事由をつけて関係のないバリエーションを削除してから網羅します。
網羅できていない資料は、その時点で手直し対象になりますが、それによって新たな設計漏れが必ず発見されています。
３つ目は、設計上の結論を導いた検討過程を証明させることです。「なぜその結論が妥当だと考えるのか、その過程を論述せよ」ということです。高度情報処理試験の小論文と同じですね。
具体的には、検討過程を資料として必ず残させるようにします。同じ結論を導くのでも、どこまで調査してその結論を導いたのかで、影響の有無もわかるからです。調査の範囲が狭いと考える場合は、調査範囲を広げさせます。
そうすることで、他への影響箇所を適切に調査した結果として導かれた結論なのかどうかが第三者にも明確になります。
そして、私はこの３つのチェックポイントに沿って設計資料を作成できるような検討プロセスや手法を文書化しています。この考えを適用してから、品質がとても向上しています。
（現在は、派生開発（母体が存在するシステム）に対する欠陥修正などのケースのみに対応しています）
１）議論する範囲を適切に定め、
（スコープの妥当性）
２）その範囲内で網羅的に検討し、
（網羅性）
３）検討結果がどのように導かれたのかが分かるようにする
（検討過程の妥当性）
という３つの対応をすることで、設計者がどのように考えて設計を行ったのかを、第三者でも明確にトレースすることができるようになります。
その結果、設計者が考慮していなかった設計漏れ、検討漏れが容易に摘出できるようになります。設計漏れがあるかないかは、設計者の頭の中を覗かないとわからないのですが、成果物＝設計者の頭の中の全て、に近くなっていれば第三者でも指摘をしやすい、ということがその根拠です。
ただこの手法のネックは、工数がかかることです。
工数を抑えて納期や予算といった制約に収まるようにするには、設計・検討するスコープを適切にコントロールすることが必要になります。
しかしスコープを初めから縮小してしまうと、設計漏れ・検討漏れが発生しやすくなるので、初めはスコープを最大に広げ、検討が必要な範囲を明確にし、その後検討が不要、もしくは検討を省略してもリスクが少ないところを関係者で協議して、意図的にスコープを縮小する方法についても言及しています。
これは、リスク管理を基礎としたスコープ・コントロールと言えると思います。
開発現場で起こるコンフリクトの１つは、「期間が短くて全ての検討が十分にできない」といったことだと思います。このとき、設計者は残業等でカバーするのでしょうが、どうしても時間が足りないと判断したところは、自分の判断で調査範囲を縮小していると思います。
しかし、その判断が合理的かつ妥当だといえないことがほとんどです。過度なプレッシャーのかかっている状況で、冷静な判断ができる人は稀です。よって、「どの検討に時間がかかるのか、その検討をしなかった場合にどのようなリスクが想定されるのか」を洗い出し、関係者間で協議し、どの検討アイテムを行わないのか、といったことを決めます。こうすれば、関係者全員で合意した結論に沿って、スコープを縮小することができます。
こうした、検討アイテムの実施有無、といったところにもスコープ・コントロールを適用することで、現時点での妥当な結論を出しながらプロジェクトを運営することができるようになると考えています。
