デザインレビューとは?「DRを効率化するチェックシートやシステム活用術」

2021.12.08

デザインレビューとは?「DRを効率化するチェックシートやシステム活用術」

デザインレビューとは?「DRを効率化するチェックシートやシステム活用術」

このコラムでは、製造業におけるデザインレビュー(DR)を効率よく進めるチェックシート・リスト「課題管理マトリックス」と、DRの効率化を支援するITシステムについて解説します。

デザインレビューとは、開発の手戻りを未然防止するために実施する設計審議会のことです。フェーズを分けて繰り返し実施し、商品コンセプトと採用技術の整合性、設計方針・設計根拠の妥当性、重要部品の課題対応策・検証法の妥当性、設計検証モデルによる設計品質獲得を段階的に確認します。十分な準備をしてレビューを実施し、技術の議論を尽くしてフェーズ移行可否を判断します。

デザインレビューとは?に関するさらに詳しい内容は、下記のコラムで詳細を解説しています。デザインレビューの目的や狙い、必要性、種類、進め方のコツなどをご紹介しています。

デザインレビューとは?「目的や効率的な進め方のコツ、種類やフェーズ」について

デザインレビューでは、設計者が設計項目と達成レベルを報告し、第三者を交えてあらかじめ設定した判断基準を満足することを点検・審議し、次のフェーズに進んでも良いことを判断します。限られた審議時間で適切な判断を下すには、議論が必要な項目とその解決状況をコンパクトにまとめて一覧できるチェックシート「課題管理マトリックス」が有効です。

課題管理マトリックス

議論の流れを作る・議論を統括する

「課題管理マトリックス」は、①解決の進捗と②問題の影響度を2軸とするマトリックスで表示し、抽出した問題点を該当するセグメントに記載します。どのセグメントに記載があるかがビジュアルに表現されるので、全体状況が共通認識されます。

レビューでの使い方として、例えば冒頭に「課題管理マトリックス」を示すと議論の流れを作ることできます。順調な場合は個々の課題対応の妥当性を確認する、難しい問題を抱えている場合は、次のフェーズに進めるか否かを意識して問題解決策を議論します。

参加者の視点を揃え、議論を収束に向かわせます。一方、レビューの終盤に「課題管理マトリックス」を示す場合は、報告・議論した結果全体を振り返って総括できます。レビューの冒頭で課題対応の全体を俯瞰して効率的な議論を実施し、議論の結果をマトリックスに反映してデザインレビューのアウトプットの一つとすることも有効です。

横軸「解決の進捗」の定義を曖昧にしない

「課題管理マトリックス」は、状況をひとめで理解できますが、セグメントの定義が曖昧であると置く位置を間違えて解決が遅れるなど、視認性の良さが本末転倒の結果を招きます。横軸には、手順を踏んで一段階進むごとに確実に解決に向かうステップを定義し、関係者で十分に認識合わせをします。地道な改善で右に寄せていくと確実に問題が解決する業務プロセスをマトリックスに埋め込みましょう。

リソースを効率よく活用する優先度考慮

設計課題はできるだけ早く解決することが望まれますが、限られたリソースで対応する場合、優先度を考慮する必要があります。優先度を考えるうえで必要な視点が課題の影響度です。対応の選択によっては周辺設計や上位システムの設計変更に繋がるものや法規に関わるものは「致命的」に分類して最優先で対応します。「重要」に分類するものは、担当設計エリアで解決できるが、品質やコストに影響するため早期に解決策を決定する必要あるものなどが該当します。「普通」は影響度は大きくないが、解決すべき問題が該当します。

優先度の高い箇所に注視する

デザインレビューで重点的に議論すべき項目は、下記「課題管理マトリックス」の 赤いセグメントになります。「致命的」は影響度が大きい問題なので評価部門確認済まで進める必要があるのは当然ですが、問題抽出ステップにある問題は影響度に寄らず注意が必要です。指摘されたばかりの項目は懸念と問題が区別されていない、表層の問題と捉えられることなどがあるからです。原因究明まで進むと問題の構造が見えてくるので、影響度の層別も誤るリスクは軽減されます。「普通」だからと後回しにした問題が実は「致命的」だったとなると、デザインレビューが不合格になり納期遅延を起こしかねません。

課題管理マトリックス

後戻り無く設計品質を作り込むためには、デザインレビューの前段で第三者による設計品質点検を段階的に実施して問題点や懸念点を抽出し、指摘事項への対応策を入れ込みながら設計を詳細化することが有効です。

具体的には、3D CADで作成したモデルを使って設計者が設計意図と構成を説明し、生産、保守、法規・安全、操作性等の専門エンジニアが問題点を指摘します。点検者は指摘するだけでなく、設計者と一緒に解決案について検討します。

デザインレビューと点検の関係図

品質点検における指摘事項は、もれなく記録し、確実にクローズしなければなりません。記録漏れやフォロー漏れが起きるとせっかくの議論が無駄になってしまいます。また、指摘事項に人による認識のずれがあると、修正箇所が再度指摘されて設計のやり直しになることがありますので、認識を揃えた記録が重要です。
また、設計者は複数の指摘事項への対応を同時に検討し、ひとつの設計に解決策を盛り込む対応に追われるため、付帯的な作業を軽減して設計に集中できる環境を用意することも必要です。

指摘事項の記録と設計者へのインプットは、品質点検で毎回行う共通作業であるため、手順を標準化してシステムを活用すれば、記録漏れや認識のずれを減らして業務を効率化できます。

それでは、業務の標準化とシステム活用による効率化の事例を説明します。

品質点検の標準化1:指摘された問題点を、漏れなく、正確に記録する

必要な項目を定義する 例:指摘者、指摘事項、指摘理由、分類、重要度、設計者、改善案、改善納期
記載事項を簡潔にする 不要な長文は指摘のポイントを曖昧にするため、指摘記述欄は短文で明快に記述します。

ツールの活用事例1:DocuWorksの付箋を使った定型情報入力

点検者は3Dビューワーを使って、品質点検で指摘した問題点を分かりやすいアングルと切り出し範囲で表示し、DocuWorks Desk上にビューワーの印刷機能によりスクリーンショット画像を作成します。

続いて、DocuWorks上で項目名を設定した付箋に指摘事項を記入し、3D図と紐づけます。設計者は付箋付き3D図により指摘事項を正しく理解し、設計変更を検討します。

※:オプショナルな拡張機能を使っています。

DocuWorksの付箋機能を使った設計問題点指摘

品質点検の標準化2:複数の指摘事項を一元化リストにまとめる

設計チームリーダは、担当エリアに対する全ての指摘事項を把握し、優先順位とリソースを勘案して必要な設計変更計画を組み、納期内に解決しなければなりません。そのためにはチームメンバーが受けた全ての指摘事項をリスト化し、問題の大きさと仕事量を把握する必要があります。

ツールの活用事例2:DocuWorks「複数の付箋からの情報抽出と一覧表へのインポート」

DocuWorksは、付箋に記載された情報をCSV形式で抜き出し、Excel上に作成した一元化リストにインポートできます 。データは、付箋の項目名と一致する列に入力されます。1つの付箋を1行にインポートする作業を複数の付箋に対して1クリックで行い、チーム担当エリアへの指摘事項を一元化した管理リストを作成します。設計チームリーダは、一元化リストを重要度や納期でソートして状況を把握し、優先順位を考慮した設計変更計画を作り、メンバーに指示します。

DocuWorksの付箋から情報抽出した一元化リスト

品質点検の標準化3:指摘事項への対応の進捗管理

DocuWorksの機能を使うことで品質点検会の指摘事項を抜け漏れなくリスト化できますが、全ての指摘事項を納期内にクローズしきることは意外に骨が折れます。どうしても重要問題に引っ張られて改善活動の思わぬ停滞を招くことがありますが、進捗を見える化し、ひとめで全体を把握できるようにすれば、忙しくて見落としたという状況を回避できます。

ツールの活用事例3:Kintoneによる 問題解決の進捗見える化

設計者は指摘事項を受けて、問題分析→対策立案→対策絞り込み→効果確認と対応を進め、点検者の確認を受けるとクローズとなります。この進捗管理はExcelのファイルを共有することでも実施可能ですが、Kintoneを使うことで、アクセス権を管理したうえでリアルタイムの情報共有が可能、グラフ・表機能を活用して進捗をシンプルに見える化できるなどのメリットがあります。まず、指摘事項の一元化リストをKintone上に取り込み、設計者が対応方針や進捗状況を記入します。

Kintoneに取り込んだ一元化リスト

リストでも進捗を確認できますが、グラフや表を使うことで状況がひとめで把握できるので見落としを防ぎ、タイムリーな対応が可能となります。

指摘事項の重要度が反映されたステータス

このグラフでは、評価部門確認済まで進んだ項目が多いなかで問題抽出に留まっている「致命的」な問題があり、内容と解決の見通しを丁寧に確認する必要があります。遅延案件の中には、問題が複雑で活動量が改善に結びつかない、他部門が関わり譲り合いになっているなど設計者だけでは解決できないものも含まれます。設計リーダはこれらを見つけ出して、適切に支援することも重要な役割です。

重要度とSTATUSの一覧表

重要度と進捗によるマトリックス表示は、優先順位の議論に適しています。例えば、この事例ではリソースを集中投入すべきは表の赤い部分(影響度が大きい、まだ解決の見通しが得られていない)になります。デザインレビューでは、赤や黄色の部分に問題が残っていないことをフェーズ移行の条件とします。

Kintoneを使ってデータを蓄積していくと、月度の進捗確認、計画とのギャップの確認はもちろんのこと、開発終了後に開発を振り返ったレビューを実施することも容易になります。競争を勝ち抜いていくには、常にデータに基づいた分析的な議論できる環境があり、対応を即断即決できることが必要です。

ここまで、3Dモデルを使ったデザインレビューの効率化と品質点検について、指摘事項の記録から解決フォローまでの流れを説明してきました。品質点検を実施すれば必ず指摘事項は挙がり、解決せねばなりません。この地味で粘り強さが求められる活動を標準化してツールを取り入れることで、ミスコミュニケーションが減り、設計者が設計に没頭できるようになり開発の生産性向上が期待できます。