DX(デジタルトランスフォーメーション)推進コンサルティング 株式会社アイ・ティ・イノベーション

ご訪問ありがとうございます！　　　　　　　　　　＜　前回　｜　目次　｜　次回　＞

前回は、レビューを効果的に進めるためには、設計書の見た目を良くする工夫が必要だということを考察しました。逆に言うと、レビュー対象の設計書が「レビュアから見てレビューに耐えられる状態」になっていなければ、レビューが非効率になるということです。

最近は、効果的なレビュー運営を行うために、「レビューチェックリスト」の活用を進める組織も多くなってきたと思います。。。（※１）

【　設計工程における品質管理活動　】

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～
ウォーターフォールモデル開発における設計工程では、主にレビューを通じて品質管理活動を行います。設計工程における品質管理活動は、だいたい次のような流れになります。

（計画＝Ｐ）
工程開始前に、どんな観点で、どのようにレビューを行い、その結果を受けてどのような品質分析を行うかなどの計画を立案し、ＷＢＳを組み立てます。

（実行＝Ｄ）
ＷＢＳに従って、機能などの成果物の固まりごとに、設計書の作成とレビューを繰り返します。開発ベンダー（受注側）の中でレビューを行ったあと、発注側とのレビューを行うことが一般的だと思います。レビューの指摘事項は、レビュー記録として残します。

（チェック＝Ｃ）
レビュー記録をもとにレビュー指摘の量と質を分析することで、品質評価を行います。どんな感じで品質評価を行うかは、前回　【第６０回】設計書の品質は見た目が９割？　を参照してください。

（アクション＝Ａ）
品質評価の結果、その工程内の後続機能の設計手順やレビューのプロセスなどに改善が必要だと判断した場合には、改善を実施します。

このＰＤＣＡサイクルが効果的に回るように、レビューは工程完了間際にまとめて行うのではなく、少なくとも２～３機能は、工程内の早い段階で実施するように計画する必要があります。工程開始前に、パイロットとして先行して設計、レビューを数機能だけ実施するというやり方もあります。（※２）

工程完了時の品質評価で改善点が見つかった場合、次工程のスタートを遅らせて品質改善のための対策を行うか、次工程と並行して行わざるをえないため、ただでさえ、きつきつの後続工程のスケジュールがさらに圧迫されてしまいます。ウォーターフォールの場合は、その工程内で所定の品質を確保してから次の工程に進むことが前提なので、品質評価（Ｃ）とその結果のフィードバック（Ａ）のためのスケジュールや工数をどれくらい確保しておくかを十分に検討して計画に反映しておく必要があるのです。

【　レビュー観点の抽出とレビューチェックリスト　】

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～
大規模なシステム開発の場合、設計書のページ数は膨大（数百～数千ページ）となり、複数のレビュアで分担して設計レビューを行う必要があります。そのような場合には、複数のレビュアによるレビューの均質化とレビュー観点漏れを防止するために、事前にレビュー観点を抽出し、それをチェックリスト化します。

ウォーターフォールモデルの場合、要件定義、外部設計、内部設計と、設計工程も何段階かに分かれます。それぞれの設計工程でレビューを行うため、できるだけ工程間でのレビュー観点の重複は避けた方が効率的です。というか、それぞれの設計工程で作りこむべき品質特性は異なるはずなので、それぞれの設計工程でレビューすべき品質特性も異なると考える必要があります。

どの設計工程で、どの品質特性を作りこみレビューするか、品質管理の全体像を品質マネジメント計画の中で整理し、プロジェクトメンバーに共有しておくことで、プロジェクト全体の品質管理のベクトルが統一されるはずです。

それぞれの設計工程開始時には、その工程でカバーすべきとした品質特性を中心に、レビュー観点をブレークダウンしていくことで、多面性のある品質に対し、全ての設計工程を通じて品質の作りこみとレビューの観点漏れの防止を効率的に行うことが可能になるはずです。

レビューチェックリストのチェック観点は、あまり抽象的な表現（「××が正しいこと」など）では、レビュアにより解釈が異なる可能性もあるので、なるべく具体的な表現とすべきです。できれば、そのチェックを行う目的やチェックが漏れた場合の影響なども併記しておくと良いと思います。レビューの初期段階で、多く指摘されたものと同じ指摘をその工程内で混入しつづけないように、チェック項目を追記してレビュアだけでなく設計担当者に周知するなど、品質管理活動のＰＤＣＡサイクルを通してレビューチェックリストをブラッシュアップしていくと効果的です。

設計工程におけるレビュー観点漏れは、後続工程への影響が大きく、テスト工程での仕様変更多発につながり、大きな手戻りが発生するリスクとなります。レビューチェックリストを組織としての標準として整備しておき、プロジェクトごとにカスタマイズして利用するなどして、組織全体としての品質管理強化の活動につなげている組織も多いと思います。

設計工程におけるレビュー観点の抽出には、ＩＰＡのホームページで公開されている『機能要件の合意形成ガイド』（【旧】発注者ビューガイドライン）なども活用すると良いでしょう。（※３）

【　レビューチェックリスト地獄からの脱出大作戦！　】

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～
全てのレビュアが、全てのレビュー対象成果物について、レビューチェックリストに挙げられたチェック観点をチェックしていくという使い方が多いと思います。しかし、レビューチェックリストを組織として標準化していると、さまざまなプロジェクトの本番障害事例の教訓などから、「これは設計工程でつぶしておくべき」という理由で、どんどんチェック項目が増えていくことがあります。

我々がご支援させていただいているプロジェクトでも、チェック項目が１００を超えるような、ものすごいチェックリストを何度も見てきました。本番障害の発生を防止するためには、全てのチェック項目をチェックするべきという気持ちはわかります。しかし、それだけ項目数が多いチェックリストを、全てのレビュー対象成果物に対してチェックしていくのは、相当時間がかかり、あまり効率的ではありません。比較的小規模の機能では、レビュー対象となる設計書の情報量よりも、チェックリストの情報量の方が多くなってしまうなんてこともおきてしまいます

かといって、過去の本番障害事例などをもとに作られた、有益なナレッジ満載のチェックリストからチェック項目を間引くのは、なかなか勇気のいることです。もし、そのチェックをしなかったことで、同じような本番障害を起こしてしまったら、経営層から何を言われるかわかりません！かくして、レビューチェックリストは肥大化する一方となり、レビュー効率の悪化とレビューの形骸化という悪循環（レビューチェックリスト地獄）に陥ってしまうのです！

もし、そんな場面に遭遇したら、チェックリストのトリアージをお薦めします。トリアージ後の目標はチェック項目数２０程度。印刷したらＡ４のシート１枚に収まる程度の情報量にします。そして、できれば、新たな本番障害が発生するなどして、チェック項目を追加せざるをえない場合は、必ずもとのチェック項目のどれかを削ったうえで追加するというルールを設けます。（※４）

もちろん、本番障害などのナレッジ情報は、レビューチェックリストとは別にナレッジＤＢに蓄積しておく必要があります。このナレッジＤＢを活用して、定期的に本番障害の発生状況の変化などを分析して、組織全体の品質改善活動に結び付けるべきです。

レビューチェックリストは、あくまでも個々のプロジェクトにおいてレビューを効率化するための道具でしかなく、ナレッジＤＢとの連携はもちろん必要ではありますが、ナレッジＤＢそのものでは無いということをしっかりと認識するべきです。レビューチェックリストに、完全性（網羅性）を求めるのではなく、担当者が有効だと感じて、使い続けることが苦にならないような、実用性の方が重要だと私は考えます。

プロジェクトに与えられた、限られたコストとスケジュールを効果的に活用するために、レビューチェックリストも「選択と集中」が必要だと思います！

「レビューチェックリストの形骸化を防ぐためには、チェック項目の『選択と集中』が必要だ！」

とはいえ、「言うは易く行うは難し」ということは重々承知しています。ここも、最終的にはプロジェクトマネージャーの判断が重要ということになります。結果的にプロジェクトを成功に導くことができれば、途中経過はそれほどとやかく言われることは無いと思います。成功させる自信が無いプロジェクトマネージャーたちは、いつまでも効率の悪いチェックリストをトリアージできずに、ますます成功の可能性が低くなっていくという悪循環（地獄）から抜け出せないことでしょう。。。

それでは次回もお楽しみに！　　　　　　　　　　＜　前回　｜　目次　｜　次回　＞

工藤武久

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～
応援してくださる方は、クリックよろしくお願いします！
◆　人気ブログランキング
◆　にほんブログ村
～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～

※１　IPA/SECから発行されている品質に関する文献では、設計レビューの３つの基本要素のうちのひとつとして、「チェックリスト」（レビューに必要な観点を可能な限り網羅し、列挙したもの）が挙げられています。その他の要素は「インプット」と「レビューア」とされています。
・独立行政法人情報処理推進機構（IPA）、ソフトウェア・エンジニアリング・センター（SEC）（2011）『続 定量的品質予測のススメ～ITシステム開発における定量的品質管理の導入ノウハウと上流工程へのアプローチ～』http://www.ipa.go.jp/sec/publish/tn10-004.html

※２　パイロット開発については、当ブログの以下の回も参照してください。
・【第３１回】禁断の裏マスタースケジュール
・【第４４回】パイロット開発の落とし穴～瞬間風速とトータル生産性

※３　『機能要件の合意形成ガイド』（【旧】発注者ビューガイドライン）については、以下を参照してください。
・http://www.ipa.go.jp/sec/softwareengineering/reports/20100331.html

※４　「トリアージ」については、当ブログの以下の回も参照してください。
・【第３９回】トリアージでデスマーチを脱却せよ！
・【第４０回】膨張するプロジェクトとトリアージ依存症