設計レビュープロセスを改善するための４つのポイント
設計レビューのプロセスは方法と参加者とチェックリストと記録について改善する
ソフトの設計品質を良くする重要な活動が設計レビューなのですが、設計レビューも正しいプロセスに従ってきっちりと実施しないと十分な効果が得られません。設計レビューのプロセスの品質を上げる事はソフトの設計品質の改善にとっても必須なのですが、どうすればソフトレビュープロセスの品質を良くする事ができるのでしょうか。
設計レビュープロセスの改善にも色々なポイントがりますが、この記事ではグータラ親父が設計レビュープロセスの改善のために注意していた、レビュー方法、レビュー参加者の選定、レビューチェックリスト、レビュー指摘事項の記録 の４つのポイントについて紹介していきます。これらポイントに注意して、現状の設計レビュープロセスで不足している所を見つけ出して改善していく事で、設計レビュープロセスの品質を改善していく事ができます。
なお、ソフト開発の場面で行われるレビューには、設計レビュー、の他にもコードレビューやテストレビューなど様々な種類のレビューがあります。これらのレビュープロセスの改善についてはまた別の記事で紹介する予定です。では、設計レビューのプロセスを改善するポイントにつて、順番に見ていきましょう。
レビューの方法は具体的に決まっているか
設計レビューには色々な方法があるので、その組織にとっての設計レビューとはどんな目的でどんなやり方で実施するのかが具体的に決まっていないと、人によって実施した内容が変わってしまいます。ソフト開発プロセスの観点から見ると、レビューの実施方法が具体的に決まっている事がまずは大切です。
また、レビューの方法によって会議形式で実施する物もあれば資料の回覧形式の物もあります。レビューの効果の面からは会議形式が望ましいのですがコストが高い（多くの人の時間を拘束する）ので、どんな場面でどの種類のレビューを実施するのか、という場面ごとのレビュー方法の選択の基準やガイドラインが決まっていると、さらに良いですね。
レビューの方法にも色々な呼び方がありますが、以下の様なレビュー方法が一般的です。
- インスペクション：複数のレビュアーが参加して設計の全ての項目についてレビューする。レビューは会議形式で行い、進行役と指摘事項の記録者が、レビューを受ける人とは別に任命される。一番厳格で体系的で公式な設計レビュー。
- チームレビュー：インスペクションの簡易版で一つの設計チーム内で重要な設計項目に対してレビューする。レビューは会議形式でレビュアーはチームリーダとあともう一人程度が参加し、進行や記録はレビューを受ける人が兼務する。コスト対効果が良いので良く使われる設計レビュー。
- ウォークスルー：設計者が主導して行われるレビューで、設計者が設計ドキュメントの内容を説明しそれに沿ってレビュアーが設計内容を確認する。レビューは会議形式で、参加者や役割分担はチームレビューと同じ。
- ピアチェック：ペアレビューとも呼ぶ。設計者とレビュアー１名で相対して実施するレビュー。多くの場合は、設計者と同じ設計チームの別の設計者がレビュアーとなり、同じ画面で設計資料や設計ドキュメントを見ながらレビューを進める。レビュアーは自分が設計した場合ならどんな設計をするか、という視点で見る事で設計に潜む問題点を見つけ出す事ができるので、必要なコストに対してレビューの効果が良い場合が多い。
- パスアラウンド：会議は行わずに、設計者が設計資料を複数のレビュアーに配布してレビュー意見を求める形式のレビュー。各レビュアーが自分の都合の良い時間にレビューを行えるので、レビューの作業効率としては良いが、設計者に直に質問ができないなどの制限があり、レビュー対象の設計資料に対する理解が深まらない事もあり、問題点が見落とされるリスクもある。
レビュー参加者の選定方法や選定基準は明確に決まっているか
設計レビューにとって実施方法の次ぎに大切なのはレビューアに誰を選ぶかです。設計ミスや勘違いや設計漏れなどの設計書に潜む潜在的な問題点を指摘してもらいこれを修正する事で設計品質を良くする事が設計レビューの目的ですので、潜在的な設計問題を見つけ出せるだけの技量と経験を持っているレビューアが参加していないと、設計レビューをやる意味がありません。
レビュアーとしてレビューに参加してもらう人は、一般的に以下の様な人から選ぶ事になりますが、どんなレビューに対してどんな人にレビュアーとしてレビューに参加してもらうのか、レビュー参加者の選定の基準やガイドラインが決まっている事も、設計レビューのプロセス品質として重要です。
- 同僚のソフト設計者：設計者と同等の技量や経験を持っている同僚の設計者は、様々なレビュー方法でレビュアーとして活躍できるオールラウンダーです。
- 設計チームリーダ：一般的に開発チームリーダはその製品のソフト全体についての知識や経験を設計者より多く持っているので、設計書の潜在的な問題を見つけ出せる能力が高く、レビュアーとしては最適です。ただし、多くのチーム員を抱えているリーダの場合は全ての設計レビューに参加する事は時間的に無理なので、重要なレビューに限定した参加になる事が多いです。
- 関連する設計者：レビュー対象のソフトと関連する部分の設計者にレビュアーとして参加して貰う事も良くあります。関連するとは、レビュー対象のソフトを使う上位側ソフトやレビュー対象のソフトから呼び出される下位側ソフトの事です。これらのソフトの設計者にレビューしてもらう事によって、インターフェース部分の潜在的な問題点が見つかる事が期待できます。
- アーキテクト：アーキテクトとは特定の技術領域に深い知見と経験を持った専門的な技術者の事です。レビュー対象のソフトが特定の技術を利用している場合には、できればその技術に関するアーキテクトをレビューアとしてレビューに参加して貰えると、設計者では気づかなかった問題点を指摘して貰える可能性が出てきます。
レビューでのチェックの視点はチェックリスト等に整理されているか
設計レビューを良くする為に重要な事の３つ目はレビューチェックリストです。実際にレビューをしてみると気づくのですが、効果的な指摘を数多く見つけられるレビュアーと殆ど指摘点を見付けられないレビュアーとに分かれます。レビュアーとしての力量や経験と言ってしまえばそれまでですが、レビューとは設計の間違いを見付ける作業なので、「設計者が間違え易い点」をどれだけ知っているのかが、レビューでの指摘に大きく影響します。
この、設計者が間違え易い点、というのがレビューでの問題点を指摘するためのノウハウに相当しますが、これを整理したのがレビューチェックリストです。レビューチェックリストはレビュー作業の技術的な側面なので、設計レビューの開発プロセスの品質という面とはちょっと違うのですが、大切な部分なのでグータラ親父は設計レビューのプロセス品質を見る時には、レビューチェックリストの有無は必ず確認していました。例えば、以下のような項目を具体化したレビューのチェックリストが整備されているかどうか、という見方ですね。
- 処理アルゴリズムは明確か：機能や性能を実現する方法が明確になっているか
- インターフェースは正確か：外部とのインタフェース方法は明確か、特にエラー処理は明確になっているか
- 性能は考慮されているか：要求に対する応答性や処理の実行に必要な時間は考慮されているか
- タイムアウトは適切か：内部で使うタイムアウトや外部に要求するタイムアウト時間は適切か
- 排他制御は網羅されているか：排他制御が必要なデータアクセスがリストアップされ適切な排他制御が使われているか
- 同期が必要なデータは明確か：同期が必要なデータがリストアップされ同期の方法や間隔は明確になっているか
- 状態遷移の設計は網羅されているか：状態遷移の設計は状態遷移表で網羅性のレビューができているか
- 初期化の時期や値は明確か：初期化の必要なデータの初期値や初期化のタイミングは明確になっているか
レビューの指摘事項を記録しトラッキングする方法は決まっているか
設計レビューの目的が設計に潜む潜在的な問題点を見付けて修正する事なので、見つけた問題点＝指摘事項を正しく記録して対策まで進めるためのトラキングの仕組みもまた、設計レビュープロセスにとってとても重要です。ここがしっかりとしたプロセスとして出来ていないと、折角設計レビューで見つけた問題点に対して、対応をし忘れて問題点のあるままソフトがリリースされてしまいます。
そんな残念な事にならないように、設計レビューの指摘事項を記録して対応が終わるまでトラッキングするプロセスが明確になっている事が、設計レビュープロセスとして重要です。指摘事項の記録とトラッキングのプロセスでは、以下の様な点が要注意ですね。
- 記録の明確性：設計書のどの箇所にどんな問題があるのか、判り易く記録を残せるような記録の仕組みやフォーマットが決まっていれば安心です。
- 指摘の分類：指摘は今回開発（リリース）で修正が必須なのか先送りできるのか、或いは指摘はされたが良く考えてみるとこのままで良かったのか、各々の指摘に対する対応の要否が明確になっている事が必要です。
- 指摘の進捗：各々の指摘が今どんな状態なのか、確認中か、対策検討中か、対策結果の確認中か、対策済みか、対応の進捗状況が判って必要なトラッキングができる事が大切です。
- 指摘の完了状況：指摘した内容の中で今回のソフト開発（リリース）で対応する必要のある項目が全て対応を終えているかどうかを簡単に調べる方法があると、なお良いです。
- 指摘の管理：上記のような指摘事項の記録とトラッキングを誰がどんなタイミングで行い誰に報告をするのか、設計レビューで見つけた指摘事項に対する管理の方法も、設計レビュープロセスとして大切です。
レビュープロセスの次ぎはコーディングプロセスです
レビュープロセスが改善されたら次はコーディングプロセスの改善です。コーディングは設計した内容をソースコードに落とし込む作業で、ソフトのプロダクト品質はソースコードの品質で殆ど決まるので、非常に縦横な開発実務プロセスです。コーディングプロセスの品質を良くするには何に注意すれば良いのか、次ぎの記事で紹介します。