文書を作成した後、見直しをしていると思います。作成した文書に間違いがないことと必要な情報が不足していないことをチェックする作業がレビューです。
文書は、内容が正確であるだけでなく、読み手が理解しやすく記述されていなければなりません。設計書を例にすると、設計内容は正しくても、日本語としてのミスがあり文章として読みづらい場合は、設計そのものにもミスがあるのではと疑われてしまうかもしれません。
レビューには、日本語の文法を含め、文書の形式として問題ないかという点と、文書の目的に合致し正しい内容で記述されているかという点の、2つの視点からのチェックが必要です。
また、作成された文書はプロジェクトとしての成果物であるため、文書作成者個人の責任ではなく、プロジェクト全体の責任と位置づけて文書を作成することになります。
そこで、レビューも個人で行なう自己レビューだけでなく、プロジェクトのメンバーが相互にレビューを行なってプロジェクト全体として文書の品質を高めていかなければなりません。
レビュー手順
文書のレビューは2段階あり、まず最初は作成者自身が自己レビューを行なって問題なしと判断したら、プロジェクトメンバーに公開してレビューを受けるプロジェクトレビューを実施します。
自己レビュー
文書を作成した直後に実行するレビューが、作成者自らが行なう自己レビューです。
【形式的チェック】
まず最初に、誤字脱字の有無と日本語の文法や文書の様式といった形式的なチェックをします。
日本語の文法として注意すべき点としては、文章はなるべく短文にし、主語と述語の関係が明確になるようにします。また、修飾語と被修飾語の関連も単純化してください。
| 例：「全てのテスト結果を確認していない」 |
| 『全てのテスト結果』を確認していないのであれば、「テスト結果を一つも確認していない」ということになりますが、「テスト結果を全て確認していない」というとらえ方もでき、その場合はテスト結果を一部分は確認しているということになります。 |
何を伝えたいのか、ということを読み手の立場で考えてみる必要があります。
文書の様式とは、見出しに応じた内容記述になっているかとか、箇条書きの文章スタイルが統一されているかなどといった点をチェックします。例えば項目転送指示の表組で「条件」列に条件だけでなく処理内容まで記述していたり、「出力結果」列の記述が「単価×納品数」「単価に返品数を掛ける」「単価がゼロならエラーにする」などといったバラバラな記述をしていたり、というケースが見受けられます。
【記述内容チェック】
形式的なチェックを終えた後、記述内容のレビューをします。
基本(外部)設計書であれば、基本設計として定義すべき内容が正しく記述されているかを確認します。基本設計書にシステムの内部的な設計内容が記述されていてはいけませんし、プロジェクト内部の情報(例えば、プログラム製作を外注する際の注文金額など)も記述不要です。
文書の目的に合致しているかをレビューする上での基準としてください。
自己レビューで検出した問題点を修正した後、プロジェクトメンバーに向けて文書を提示してレビューを依頼します。
プロジェクトレビュー
プロジェクトメンバーによるレビューは、参加者が多くなることから多種多様な指摘を受けることができるため、文書品質の向上に大きく寄与するものですが、作業工数も大きくなるので、目的を明確にし計画立てて実行すべきものといえます。
レビュア(指摘者)が各自気付いた点を思い思いに指摘してしまうと、重複する部分と見逃されてしまう部分が生じてしまい、品質がバラついてしまう可能性があります。
そこで、レビューする観点と範囲を明示しレビュー網羅度を上げて効率的に作業が進むようにレビュー計画を立案し、実作業が開始したらレビュー実施率や指摘数を把握し進捗とレビュー品質を管理する必要があります。
レビューの観点
レビュー観点としては、次のようなものが挙げられます。
| 網羅性 | 記述すべき内容が網羅されているか |
| 正確性 | 記述されている内容は正しいか |
| 明快性 | 理解しやすい表現になっているか |
| 整合性 | 文書内および他の文書との間で整合がとれているか |
| 統一性 | 文書内および他の文書との間で表記が統一されているか |
| 標準化 | 文書作成ルールに合致しているか |
| 影響度 | 他文書の記述変更による影響の有無を確認しているか |
レビューの種類
レビューにはいくつか種類があるので、目的や参加メンバーにより使い分けをしてください。
| ペアレビュー | 二人で行なうレビュー。上級者が指導の目的で行なうことが多いが、同レベルで実施すると視点の違いから見逃しを防止できる。 |
| ウォークスルー | 作成者自身が文書の記述内容を説明し、レビュアから指摘を受けるスタイル。 |
| インスペクション | モデレータという文書作成者以外のメンバーに進行役を依頼し、レビュアに役割を与え、その役割に応じた指摘をしてもらう。 |
| パスアラウンド | メールやグループウェアを用いて文書をレビュアに配布し、指摘事項をレビューシート等に記述してもらうスタイル。 |
コードレビュー
レビュー対象は文書だけでなく、プログラムソースに対しても行ないます。プログラムソースもプログラム言語で記述された文書とみることができます。
レビューの観点は文書レビューと同等となりますが、プログラムソースは文書以上に可読性を求められるものですので、特にコーディング規約の順守は重視すべきものです。
コードレビューを行なう前提でのプログラミングは、人に見せることを意識づけるため、可読性の向上を期待できます。
また、コーディング規約や共通仕様など、メンバーが共通して理解すべき情報に対する認識の差異を確認することもできるため、プログラム品質の底上げが可能となります。
レビュー指摘の反映
指摘された箇所に対する修正はもちろんですが、レビューで指摘を受けなかったから問題なしといった判断はせず、指摘箇所と同じような記述をしている部分や影響を受ける部分に対する再チェックを作成者自身が行なってください。
レビューでの指摘は、作成者自身が自己レビューで気付けなかったミスに対するものですが、レビュアも気付けなかったミスが残存している可能性もあります。
レビューで指摘を受けた場合は、必ず横展開をして、類似のミスが存在していないか確認しましょう。
