設計書レビューの実施方法 – 設計書の品質を上げるためのポイント５選

はじめに

システム構築で品質を上げるためには、設計書の精度を高めることが重要です。
設計書に残った不具合１件が、テスト工程で複数の不具合につながり、修正作業の工数が膨れ上がるためです。
そして設計書の品質を上げるためには適切にレビューを行う必要がありますが、レビューの段取りをしっかり考えないと抜け漏れが発生したり、レビュー量が膨大になり進捗遅延になります。

無理・無駄なく品質向上につながるためにはレビュー計画を策定することが必要であり、その計画で考慮すべき5つのポイントについて解説します。
このポイントを意識することで、設計書レビューで以下の改善が見込まれます。

• レビュー工数の肥大化を抑止
• レビューアによる指摘のバラつきを抑える
• レビューを進めるごとに設計書の品質が向上

レビュー計画の５つのポイント

設計書レビュー計画はプロジェクト計画の作成段階で検討します。
レビューアの選定や実施タイミングにより、WBSの担当割り当てやスケジュール調整に影響が出るためです。

レビューアの選定と確保

一般的に設計書レビューは技術や業務の有識者が担当します。
この有識者が十分にいればよいのですが、そのような恵まれたプロジェクトは少ないと思います。
むしろ有識者が誰もいないプロジェクトというのも存在します。

レビューアが不足している場合の対処方法は次のとおり。

有識者はいるが少ない場合

有識者は開発メンバが効率よく作業できるようにサポート役に徹します。
できるだけ開発などの実作業を割り当てず、レビューやメンバへの支援、レクチャーを対応します。

よく「有識者だから難しい機能を担当させる」という考えのもと、難易度の高い開発を任せながら、同時にレビューアを担当させるシーンを見かけます。
このような場合、十中八九は有識者が高負荷となりスケジュールのボトルネックとなります。
結局、時間が足りない中でレビュー実施するため要点だけチェックする形となり、細かいところまで目が届かなので抜け漏れが発生することになります。

それよりは、難易度の高い機能も他メンバを充て、有識者が支援する形にするのが望ましいです。
有識者はレビューに注力してもらうことで品質向上につながるとともに、指導を行うことでメンバのスキル向上にもつながります。

有識者が誰もいない場合

最初から有識者がいないプロジェクトの場合、有識者を育てることがポイントとなります。
有識者の育成方法は、前工程でメンバに主体となって作業をさせることが有効です。

例えば詳細設計でレビューできるメンバを揃えたい場合、その前工程である基本設計を育成したいメンバが主体で対応させます。
主体で設計しないと理解が浅くなるため、誰かにサポートしてもらいながらでも自身で基本設計を担当させます。

もし基本設計を行える有識者がいない場合は要件定義から参画させるか、クライアントや現場のユーザに教えを請いながら基本設計を進めていきます。
とても大変ですが、メンバの育成期間と考えて計画に盛り込みます。

ちなみに、上記は業務や仕様の話であり技術的なスキルの話ではありません。
Web開発なのに全員ホスト開発の経験しかない、というスキルアンマッチは別です。
これはプロジェクトの要員計画が失敗しているので、プロジェクト責任者と調整して要員計画を再検討すべきです。

レビュー形式の選択

大きく、メンバが集まって実施する対面レビューと、書面でチェックする書面レビューの２種類に分類できます。
これらのレビュー方法にはメリット／デメリットがあるため、状況により使い分けます。

対面レビュー

メンバが集まってチェックする場合に対面レビューを行います。
メンバ同士で議論したり、気になる点をすぐにレビューイへ確認することができることがメリットです。
参加人数だけレビューに要する時間が多くなるため、全てのレビューを対面で行うとレビュー工数が膨大になります。

レビューの主導がレビューイ（説明する側）の場合、説明の順番で資料を切り替えていくため、レビューアは見たい箇所に集中することができません。
逆にレビューア（チェックする側）が見ていき、気になる点をレビューイが回答する形式の場合、レビューイは質問がくるまで待っている状態で時間がもったいないです。

対面レビューで効力を発揮するのは以下の場合です。

• その工程で初めてレビューする場合、どのような観点でチェックするのか全体共有したい
• 難易度の高い機能など、複数の有識者が合同でチェックする必要がある

書面レビュー

紙印刷したり電子データでチェックする場合は書面レビューとなります。
レビューアが自分の都合がよいタイミングでチェックでき、自身のペースで内容確認できるため、チェックする箇所が明確になっている場合は効率がよいです。
ただ内容に不明点がある場合、レビュー記録表でのやり取りであったり、担当者に別途ヒアリングをかける必要があるため、チェックに時間を要する可能性があります。

これらの特徴から、次のようにレビュー形式を選択するのが効率的です。

既存システムの改修など、レビューの仕方がわかっているプロジェクトは書面レビューで行います。

新規プロジェクトなどレビュー観点に慣れていない場合は、最初の何本※か対面レビューを行います。
そこでは設計者全体を集めてレビューを行い、指摘事項の共有を行います。
その後、レビューに慣れてきたら書面レビューに切り替えます。

※最初は特殊な機能を避け、標準的な機能を選択します。

レビューの自動化

上記では対面、書面のように人がチェックする方法について述べましたが、それ以外にツールを活用したレビューもあります。
業務観点や仕様など人間が考えないと判別できない内容はチェックできませんが、機械的にチェックできる観点を自動化することで、作業工数を大幅に減らすことが可能です。
人間のように見落としがなくなることもメリットです。

またレビューの指摘事項をExcelでまとめるのではなくツールを使って作業を簡略化したり、可視化することでレビュー作業を効率化することもできます。

ツールを導入することで業務効率化することは、作業工数の低減だけでなく品質向上にもつながるので、積極的に検討しましょう。

チェックリストの作成

レビューアが個人的感覚だけでチェックを行うと抜け漏れにつながる可能性があります。
また気になる点をチェックしていくだけでは指摘事項にもバラつきが出ます。

このような問題に対処するため、レビューのチェック項目をリスト化します。
チェックリストを作るメリットは次のとおり。

• 設計者でもチェックできる内容であれば、設計者の自己チェックリストとして活用できる
• レビューア間で共有することで、レビューアの能力による指摘事項のバラつきを抑止する

このようにチェックリストの活用は有効なのですが、チェック項目の多すぎはデメリットなので注意です。
よくあるのが、会社の標準資料として用意されているチェックリストを活用する場合です。
既にあるノウハウは積極的に活用すべきですが、汎用的に作られているためチェック項目が膨大になっていることがあります。
このチェック項目が100や200あったりすると、誰もチェックする気になりません。
結果、チェックリストが形骸化されては意味がありません。

もし膨大なチェックリストがある場合は、その中からプロジェクト特性を考えて有益になりそうな項目だけピックアップします。

指摘事項の品質分析

レビューを行っていると、類似の不具合を発見することがあります。
チェック対象の機能だけではなく、「他に影響、関連する機能がないか」を意識してレビューすることが大切です。
もし横展開が必要な不具合を発見した場合、横展開の確認が漏れないように不具合管理表といった資料に記録を残します。

また設計書レビューの結果を品質分析することで、新たに設計工程の弱点を見つけることができます。
もし「業務知識が足りない」ことが原因で指摘事項が多く発生しているのであれば、メンバに業務のレクチャーを行います。
外部インターフェイスの項目に多くの指摘が出ているのであれば、連携部分のチェックを強化します。

このように指摘事項を分析することで、設計書をチェックするだけでは気づかない問題点を発見することもあります。
この分析は設計工程が完了してから行っても意味がありません。
設計工程の途中で行うことで問題の早期発見につなげることができます。
品質チェックをレビュー計画に組み込みましょう。

品質チェックについては、別記事「品質分析の意味と正しい活用方法」を参照してください。