はじめに
設計工程のレビューが完了し、品質指標も社内基準の範囲内でした。
普通に考えれば、そのまま次工程へ進めそうです。
しかし、このプロジェクトではすぐには進めませんでした。
理由は、全体の数値には現れにくい「偏り」があったからです。数値が基準内でも、特定機能への指摘集中や、逆に不自然なほど指摘が少ない成果物が隠れていることがあります。
本記事では、実際のプロジェクトで行った品質評価をベースに、そうした違和感をどう見つけ、原因を追い、次工程へ進める根拠をどう作ったかを紹介します。
まずは、レビュー指摘件数をどう見るかから始めます。
1. レビュー指摘件数だけでは、設計品質は判断できない
あるプロジェクトで、複数機能を合わせた設計書115ページに対し、レビュー指摘が36件出ました。
この36件という数字だけを見て、
「36件もある。品質が悪い」
あるいは逆に、
「社内基準の範囲内だから問題ない」
と判断してよいのでしょうか。
どちらも早すぎます。
36件が多いか少ないかは、対象範囲によって意味が変わります。
1機能の小さな設計書で36件なら多く見えるかもしれません。一方、大規模なサブシステム全体で36件なら、むしろ少なく見えることもあります。
だから最初に確認するのは、指摘件数そのものではありません。
成果物の規模と、指摘がどこに偏っているかです。
実際に担当したあるプロジェクトでも、全体の指摘件数だけを見ると、社内で設定していた品質水準から大きく外れた状態ではありませんでした。
ところが機能別に分解すると、ある認証系機能に指摘が集中していました。
全36件のうち17件。全体の約47％です。
認証機能だけ、何か違う。
この違和感をそのままにせず、原因を確認するところから品質評価が始まります。
2. まず全体値を見る。ただし、ここでは結論を出さない
設計レビューが終わったら、まず全体の数字を確認します。
次のような結果でした。
| 項目 | 実績 |
|---|---|
| 設計書規模 | 115ページ |
| レビュー指摘 | 36件 |
| エラー摘出密度 | 約31件／100ページ |
| レビュー時間 | 約650分 |
| レビュー密度 | 約5.7分／ページ |
当時のプロジェクトでは、こうした値を社内標準の品質基準と比較していました。
ここでいうエラー摘出密度は、100ページ当たりの指摘件数です。
基準値との比較は必要です。大きく外れていれば、その時点で何らかの問題がある可能性があります。
ただし、ここで「基準内だから品質に問題なし」と結論は出しません。
逆に多少基準を外れていても、それだけで品質不良とは見ません。
私にとって品質指標は、結論を出す数字ではなく、次にどこを見るかを決める入口です。
例えば、レビュー指摘が多くても、その大部分が誤字や表現修正なら、設計そのものの品質が悪いとは限りません。
一方、指摘件数が少なくても、その中に重大な設計漏れが含まれていれば話は別です。
30件の軽微な記述修正と、1件の重大な設計漏れでは意味が違います。
だから、全体値を確認した次は、その数字を分解して見ます。
今回のケースで行った流れを整理すると、次のようになります。
図：設計工程における品質評価の流れ。基準値の確認だけで終わらず、偏り・重要度・原因を確認し、必要に応じて設計へ戻す
この流れの中で、最初に重要になるのが「偏り」です。全体平均だけでは見えない違和感を、機能別に分解して確認します。
3. 設計工程の品質評価では「平均」より違和感を見る
先ほど示した36件を機能別に分けると、内訳は次のようになります。
| 機能 | 指摘件数 |
|---|---|
| 認証系 | 17 |
| マスタ連携系 | 7 |
| バッチ系 | 5 |
| その他 | 7 |
認証系だけで全体の約半数を占めており、偏りがはっきり見えます。
ここで見るべきなのは、
なぜ、この機能だけ突出したのか
です。
品質評価では、こうした偏りをかなり重視します。
特定機能に指摘が集中している、特定種類の指摘だけ突出している、規模の割に指摘が多い。こうした数字には、何らかの理由があります。
今回の認証系機能でも、17件のうち大半が「説明不足」「記述上の不備」でした。
一見すると、
設計者の文章力の問題ではないか
と思うかもしれません。
しかし、実際に原因を追っていくと、問題はもっと上流にありました。
この点は後ほど詳しく説明します。
指摘が「0件」の成果物も確認する
逆方向の偏りもあります。
指摘が少なすぎるケースです。
ある程度の規模や複雑さがある成果物でレビュー指摘が0件だった場合、私は「品質が高かった」とすぐには受け取りません。
むしろ、一度確認します。
もちろん、小規模な定型機能なら0件でも不思議ではありません。
しかし、ある程度の規模があり、新規設計や条件分岐、外部連携などを含むのに0件であれば、
本当に十分なレビューが行われたのか？
を疑います。
実際のプロジェクトでも、指摘が多い機能だけを確認していたわけではありません。規模の割に指摘が少ない機能や、指摘が0件だった機能も確認対象にしていました。
0件には、
- 本当に完成度が高かった
- レビュアーが十分に内容を理解できていなかった
- レビュー観点が不足していた
- 表面的な確認だけで終わっていた
といった、まったく異なるケースが混在するからです。
品質評価で探すのは、単純な「悪い数字」ではありません。
説明しにくい数字、違和感のある数字です。
多すぎる場合も見る。少なすぎる場合も見る。
全体平均の中に埋もれた違和感を拾うことが、品質評価の最初の重要な作業です。
4. 指摘件数より「何を指摘されたか」を見る
レビュー結果を見るときは、指摘件数だけでなく、その指摘がどの程度の影響を持つものかを確認します。
例えば、同じ10件でも、
- 誤字脱字や表現の修正が10件
- 処理条件の漏れや設計誤りが10件
では、品質上の意味はまったく違います。
私が品質評価をするときは、指摘内容を重要度で分けて見ます。
| 重要度 | 考え方 |
|---|---|
| 大 | 設計漏れ、設計誤りなど、そのまま後工程へ流すと機能不良や大きな手戻りにつながるもの |
| 中 | 修正が必要な設計上の問題。ただし「大」ほど致命的ではないもの |
| 小 | 誤字脱字、言い換え、分かりにくい表現、誤解を招く記述など |
この分類で重要なのは、件数の多寡だけで工程完了を判断しないことです。
軽微な指摘だけであれば、修正を確認できた時点で問題にしません。
一方で、重要度「大」に相当する設計漏れや設計誤りが残っているなら、たとえ指摘件数が1件でも、そのまま工程完了とはしません。
重要度の高い指摘が見つかった時点で、同じ原因による漏れが他機能にもないか、横展開の確認も必要になります。
つまり、
「何件あったか」より、「何が残っているか」の方が重要です。
先ほどの認証系機能でも、指摘の大半は説明不足や記述上の不備で、重要度としては「小」〜「中」が中心でした。
認証方式そのものを大量に間違えていたわけではありません。
それでも、同じ種類の指摘が一つの機能に集中している以上、
なぜ、この機能だけ設計内容を明確に書けなかったのか
は確認する必要があります。
次章では、この認証系機能について、実際にどこを疑い、原因をどう絞っていったのかを見ていきます。
5. 認証系だけ指摘が多い。まず何を疑ったか
認証系機能では、他の機能より指摘が明らかに多く出ていました。
こういうとき、私はいきなり
担当者のスキルが足りない
とは考えません。
まず機能単体で見える構造を確認し、次に人を見て、それでも説明できなければ機能の外側にある構造へ視野を広げます。
この順で見る理由は、個人を疑う前に、担当者を替えても同じ問題が起こる要因がないかを確認したいからです。
機能そのものの難易度
まず、その機能が他より難しくないかを見ます。
認証や外部連携のように、複数システムをまたぎ、条件分岐も多い機能は、単純な機能より設計上の確認事項が増えます。
当時のプロジェクトでも、認証まわりは経験者が限られており、他機能より確認すべき前提が多い領域でした。
要件が十分に固まっているか
次に見るのが要件です。
設計者が正しく理解していても、要件そのものに不足があれば、設計書に明確に落とし込むことはできません。
ここでは、要件定義書や過去の打ち合わせ内容を見直し、
そもそも設計者が判断できるだけの情報が揃っていたか
を確認します。
担当者の理解・経験
ここで初めて、担当者側を見ます。
機能の前提は理解できているか。過去の設計や類似機能を把握しているか。
ただし、指摘が多いことだけを理由に担当者の力量が低いとは見ません。
レビュアー側の知識
設計者だけでなく、レビューする側も確認します。
レビュアーがその機能の前提や過去の経緯を知らなければ、レビュー回数を増やしても重要な観点を拾えないことがあります。
機能の外側まで視野を広げる
個人や単一機能だけでは説明できない場合は、認証基盤側と個別機能側の責任分界も確認します。
認証や外部連携では、
どこまでを認証基盤側で決め、どこからを個別機能側で決めるのか
が曖昧だと、誰も設計しない領域が生まれます。
この観点は、単純な設計書レビューだけでは見落としやすい部分です。
ここまで確認して初めて、
指摘が多かった理由は何だったのか
を絞り込めます。
今回の認証系機能でも、表面的には「説明不足が多い」という現象でしたが、その原因は設計書の書き方だけでは説明できませんでした。
次章で、実際にどこが不足していたのかを見ていきます。
6. 原因は「書き方」ではなく、要件と責任分界にあった
認証系機能では、「説明不足」「記述上の不備」が多く出ていました。
表面だけを見ると、
設計者が分かりやすく書けていない
という問題に見えます。
しかし、設計内容を追っていくと、原因はそれだけではありませんでした。
当時の要件では、外部の認証基盤から利用者IDを受け取り、そのIDが認証用のテーブルに存在する利用者だけをシステムへ通す、というところまでは決まっていました。
ところが、その先が十分に詰められていませんでした。
例えば、
- その利用者は参照だけできるのか
- 更新もできるのか
- 管理者権限を持つのか
- 担当業務だけを利用できるのか
- こうした権限情報をどこで管理するのか
といった点です。
つまり、「誰であるか」を確認する認証までは決まっていても、「何をしてよいか」を決める権限側の要件が十分ではなかったのです。
さらに、認証基盤側と個別機能側のどちらが、どこまで責任を持って設計するのかも曖昧でした。
例えば、認証基盤側は利用者IDが正しいことまでを保証し、その利用者に「参照のみ」「更新可能」「管理者」といった権限を与えるのは個別機能側なのか。それとも権限情報そのものを認証基盤側で管理するのか。
この境界が十分に決まっていませんでした。
この状態では、設計者が設計書を明確に書こうとしても限界があります。
要件として決まっていない内容を、設計者の判断だけで確定させることはできないからです。
結果として、
「この場合はどうするのか」
「この権限はどこで判断するのか」
「この条件では認証エラーなのか、権限エラーなのか」
といった部分が設計書上で曖昧になっていました。
この関係は、次のように整理できます。
要件が不足している
↓
認証基盤側と個別機能側の責任分界が曖昧になる
↓
設計者が一意に仕様を決められない
↓
設計書の記述が曖昧になる
↓
レビューで説明不足として表面化する
ここで重要なのは、レビューで見えた「説明不足」をそのまま原因だと考えないことです。
説明不足は原因ではなく、上流の問題が設計書に現れた結果だったわけです。
もしここで、
設計書をもっと分かりやすく書くこと
だけを対策にしていたら、根本的な問題は残ったままです。
今回のケースでは、この原因を確認した時点で、次工程へそのまま流すのではなく、設計の前提を見直す必要があると判断しました。
7. 基準内でも、原因が見つかれば設計へ戻す
認証系機能で指摘が多かった原因を追うと、設計書の書き方だけでなく、要件不足と責任分界の曖昧さがあることが分かりました。
この状態でそのまま製造へ渡せば、実装者ごとに仕様の解釈が分かれ、後から設計変更や製造修正が発生する可能性があります。
そのため、全体として品質基準の範囲内であっても、そのまま次工程へ進む判断はしませんでした。
不足していた仕様を確認する
最初に行ったのは、曖昧だった仕様の再確認です。
認証そのものだけでなく、
- 利用者にどの権限を与えるのか
- どこまでを認証基盤側で持つのか
- どこからを個別機能側で判断するのか
といった、設計の前提を整理し直しました。
私の現場では、こうした仕様不足を見つけたとき、
今ここで決めずに後工程へ送ると、設計変更や製造修正として追加工数が発生するか
も判断材料にします。
今回の内容は、後工程へ持ち越せば手戻りにつながる可能性が高いため、この工程で確認すべき事項と判断しました。
プロジェクトの経緯と運用を知る有識者にも確認する
次に、有識者を加えて確認しました。
ここでいう有識者は、単に認証技術に詳しい人ではありません。
重視したのは、
そのプロジェクトで、なぜ現在の設計になったのかを知り、既存システムが実際にどう運用されているかも理解している人
です。
技術力が高くても、途中から参加した人では、過去にどのような議論があり、なぜその方式を採用し、他機能とどこを揃える必要があるのかまでは分からないことがあります。
さらに、要件定義書には明示されていなくても、既存システムを長く使ってきた中で当然視されている運用要件が存在することもあります。
横並びで品質を見るときは、技術知識だけでなく、プロジェクト固有の設計経緯と運用実態を知っていることも重要です。
他機能へ横展開する
認証系機能で問題が見つかったからといって、その機能だけを修正して終わりにはしません。
まず、要件不足やシステム間の責任分界という観点で、同じ問題が他機能にもないかを確認しました。
例えば、
- 設計者が判断できない未確定条件が残っていないか
- 他システムとの責任分界が曖昧になっていないか
といった観点です。
加えて、横展開を進める中では、認証系とは別の種類の不足も見つかりました。
例えばポータル画面です。
プロジェクトの経緯と既存システムの運用を知る有識者から、
- 本日・今月のバッチ処理の終了予定時刻
- バッチ処理の実施結果
- 処理件数
- 利用者への連絡事項
といった情報も、共通的に表示する必要があるという指摘がありました。
こうした内容は、要件定義書に書かれた項目だけを追っていても拾いにくいものでした。
そのシステムが実際にどう使われてきたかを知る人だからこそ見つけられた設計上の不足です。
この不足は設計へ反映し、修正後に再確認しました。
横展開は、同じ不備を他機能から探すだけの作業ではありません。
プロジェクト固有の設計経緯や運用知識まで含めて、設計に抜けがないかを確認する作業です。
そして、今回見つかった問題はその場限りで終わらせず、次回以降のレビューでも使えるよう、
- 未確定条件が残っていないか
- 他システムとの責任分界が明確か
といった形でチェック観点として残しました。
最初から完璧なチェックリストを作る必要はありません。実際に発生した問題を確認観点へ戻していくことで、そのプロジェクトに合ったチェックリストになっていきます。
ただし、それを第三者でも同じように使える形に整理することは、また別の作業です。
修正後の再確認では、今回問題となった観点について追加の修正指摘は出ませんでした。
重大な設計漏れや未解決事項も残っていないことを確認しました。
仕様を再確認する → プロジェクト経験者を含む有識者で確認する → 他機能へ横展開する。
ここまで実施して、次工程へ進めました。
基準の確認は必要ですが、それだけでは足りません。
数字の偏りから原因が見つかったのであれば、基準内かどうかより、その原因を放置しないことを優先します。
8. 数字の良し悪しの前に、「何を計った数字か」を確認する
品質評価では、レビュー密度や生産性といった数字も確認します。
ただし、数字が基準より高い、低いというだけでは評価しません。
代表的なのがレビュー密度です。
当時のプロジェクトでは、レビュー密度が社内標準より低く見える場面がありました。
数字だけを見れば、
レビュー時間が不足していたのではないか
と考えたくなります。
しかし実態を確認すると、設計書レビューだけでなく、事前の横並び確認や整理にもかなり時間を使っていました。一方、それらの時間すべてが管理ツール上のレビュー時間として計上されていたわけではありません。
つまり、
レビューが少なかった
のではなく、
数字に含まれている作業範囲が、実際に行った品質確認の全量ではなかった
ということです。
ここで確認すべきなのは、実績値が正しいかどうかではありません。
その数字が、何をどこまで計測したものなのかです。
レビュー密度が低くても、横並び確認や有識者レビューまで含めて十分な確認をしているのであれば、その実態も合わせて評価します。
時間の多寡と、レビュー観点の質は別の問題です。
成果物ごとの指摘件数も同じです。先ほど触れたように、規模や難易度に対して極端な値になっていれば、その理由を確認します。
生産性についても、高く見えていても、工数の計上範囲や外部支援の有無によって意味が変わります。
数字が良いか悪いかではなく、その数字が実態を正しく表しているかを見る。
これが重要です。
場合によっては、こうした理由から指標を「参考値」として扱うこともあります。
ただし、参考値とすることは、評価しなくてよいという意味ではありません。
なぜその数字をそのまま評価に使えないのかに加え、何を代わりの品質確認の根拠としたのかも説明できる必要があります。
例えば、横並び確認、有識者レビュー、修正後の再確認などです。
「参考値」は逃げ道ではなく、別の根拠で補完することを前提にした扱いです。
9. 品質評価の目的は「次工程へ進める根拠」を作ること
設計工程の品質評価は、
基準値に入ったから合格
という判定ではありません。
偏りを見つけ、原因を追い、必要なら設計へ戻し、横並びや有識者の確認を重ねる。
その結果として、重大な問題が残っていないことを説明できて初めて、次工程へ進めます。
品質評価の目的は、品質指標を計算することではありません。
「なぜ、この設計成果物を次工程へ渡してよいのか」を説明できる状態にすることです。
今回のケースを口頭で説明するなら、骨子はこうなります。
全体の品質指標は基準範囲内だったが、認証系機能への指摘集中が見つかった。原因を確認すると、要件と責任分界に不足があったため設計へ戻した。さらに有識者を交えて他機能も確認し、必要な修正と再確認を行ったうえで、次工程へ進める状態になった。
実務では、この判断を口頭で説明して終わりにはできません。
顧客やプロジェクトマネージャー、PMOなど、第三者が後から見ても、
- どの数字に着目したのか
- なぜ追加確認が必要と判断したのか
- どんな品質強化を行ったのか
- 何を根拠に次工程へ進めると判断したのか
を追える形にしておく必要があります。
第8章で触れたように、レビュー密度などを「参考値」とした場合も同じです。
なぜその数字をそのまま評価に使えないのか。
その代わりに何を確認し、品質を担保したのか。
ここまでを整理して初めて、第三者にも品質判断の根拠を説明できる状態になります。
ここから先は、「品質をどう判断するか」ではなく、その判断をどう資料にするかの話です。
実務編では、実際の品質評価で使用してきた考え方をベースに、架空プロジェクトのデータを使って、
- レビュー実施状況表
- エラー分析表
- 横展開用チェックリスト
- 品質・生産性報告書
をどのように作るか、具体的に整理します。
本記事が「何を見て、どう判断するか」なら、実務編は「その判断を第三者に説明できる成果物へどう落とすか」です。
※実務編は近日公開予定です。
関連記事
設計工程の品質評価では、レビュー結果だけを見るのではなく、要件が十分に具体化されているか、設計した内容を後工程でどう確認するかまでつなげて考える必要があります。
今回の記事で扱った「要件不足」「責任分界」「次工程へ進める根拠」と関係する内容は、以下の記事でも詳しく整理しています。
要件定義とは？RFP・見積前提から認識差を潰す実務を解説
要件定義書に書かれた要求をそのまま設計へ渡すのではなく、設計・構築・テストできる粒度まで具体化する考え方を、責任分界や実際の手戻り事例とともに整理しています。
Vモデルは古くない｜設計とテストをつなぐ品質保証の考え方
要件や設計で決めた内容を、どのテスト工程で確認するのか。設計成果物とテストを対応づけて、後工程まで含めて品質を作り込む考え方を解説しています。
機能要件と非機能要件の違い｜「機能が動く」と「本番で使える」は違う
機能が正しく動くだけでは、本番で使えるシステムとは限りません。性能・可用性・運用性・セキュリティなど、設計時に見落としやすい非機能要件の考え方を整理しています。
コメント