「デザインレビューで問題を指摘した。でも、その後どうなったか分からない」。DRは会議を開くことだけでなく、見つけた課題を対応につなげることが大切です。
デザインレビュー（DR）とは
Design Reviewの略で、設計の節目に関係者が設計内容を確認する活動です。性能や品質、安全性、作りやすさ、調達可能性、コストなどを確認し、問題を早めに見つけます。「デザイン」は見た目だけでなく、製品や設備の設計を指します。
購買担当者は何を見る？
例えば、新しい工場設備の仕様を技術・生産・品質・購買で確認する場面。購買なら、指定部品を必要な時期に買えるか、特注仕様が費用を押し上げていないか、保守部品を継続して調達できるか、といった視点を持ち込めます。
技術判断を購買だけで決めるのではなく、専門部署と一緒に確認することがポイントです。
チェックリストと課題管理表の違い
| 道具 | 主な役割 |
|---|---|
| チェックリスト | 確認すべき観点の抜けを防ぐ |
| 課題管理表 | 見つかった課題の対応を完了まで追う |
「確認漏れが多い」ならチェックリストの整備。「指摘した課題が放置される」なら担当者・期限・対応状況を管理する仕組みが必要です。議事録を残すだけでは、誰がいつまでに動くかが曖昧なままになることがあります。
やりっぱなしを防ぐ課題管理表
次は、学習用に作った記入例です。
| 項目 | 記入例 |
|---|---|
| 指摘内容 | 指定センサーの納期が設備の完成予定に間に合わない |
| 対応責任者 | 購買担当A（技術担当Bと連携） |
| 期限 | 10月15日 |
| 対応内容 | 納期短縮の確認と、代替品の検討 |
| 完了の根拠 | 納期回答書と、代替品を採用する場合の技術評価結果 |
| 完了確認 | 関係者が根拠を確認して課題を閉じる |
「対応しました」という報告だけでなく、指摘した問題が解消されたかを確認します。すぐ閉じられない課題は、影響や対応計画を明らかにして、次の判断につなげます。
覚え方は「設計を確認、宿題を閉じる」
DR＝設計をみんなで確認し、宿題を閉じる。フォローの覚え方は「誰が・いつまで・何をした・確かめた」です。
- 誰が：責任者を決める。
- いつまで：期限を決める。
- 何をした：対応内容と結果を残す。
- 確かめた：根拠を確認して完了を判断する。
学習で区別したいポイント
DRは、完成してから不良品を見つける検査とは異なり、設計段階で問題を見つける活動です。また、会議の回数を増やすだけでは、課題の放置は解消しません。設問では「確認漏れ」なのか「対応の未完了」なのか、困っている内容を先に見ましょう。
あわせて読みたい
購買ボキャブラリー｜SECIモデル：判断のコツを言葉にして、チームに共有する考え方。
参考資料
- NASA/JPL：Design Reviews
- NASA：設計レビューの指摘事項・完了根拠の管理に関する教訓（課題管理の参考。CPPの教材ではありません）
例と覚え方は理解のためのオリジナルです。CPP学習で用語を整理する際は、使用中の公式教材の表記・条件と照らし合わせてください。
コメント