過去トラをデザインレビューで引ける形にする——記録の欄と照合の手順

過去トラが「あるのに使われない」理由は、記録の単位にある

設計部門に過去のトラブル事例が蓄積されていない会社は少ない。不具合が起きれば報告書が書かれ、仕入先には是正処置の回答を求め、市場で問題が出れば対策会議の議事録が残る。それでも同じ種類の不具合が別の機種で繰り返される。この「知見が引き継がれない」という課題そのものは、過去トラブルの知見が引き継がれず同じミスが再発する設計部門の課題で扱っている。この記事は、その先の実務——記録をどういう形にしておけば、次のデザインレビューで実際に引けるか——に絞る。

最初に押さえておきたいのは、トラブルが起きた時点で書かれる書類と、次の設計で使う記録は、目的が違うという点である。不適合報告書は、見つかった物をどう隔離し、どこまでのロットを疑い、どう処置するかを決めるための紙である（書き方は不適合報告書（NCR）に何を書くか）。仕入先への是正処置要求も、原因と対策が妥当かを判断して差し戻すための書類である（仕入先に是正処置を求めるとき）。どちらも「今回の件を閉じる」ために最適化されていて、管理番号・発生日・ロット・品番で並ぶ。

次の機種を設計している人は、ロット番号では探さない。「樹脂の嵌合部」「屋外で使うシール」「電源を入れた直後の突入電流」といった、部位と機能と使われ方で探す。報告書の束をそのまま共有フォルダに置いても、この探し方には答えられない。過去トラを使えるようにする作業は、報告書を集めることではなく、設計の言葉で引ける索引を付け直すことだと考えたほうが進む。

公的な事故情報の扱いにも同じ構造が見える。製品評価技術基盤機構（NITE）は昭和 49 年から暮らしの中の製品事故の情報を集め、調査結果を「事故原因や事業者の再発防止措置を含め」定期的に公表している^[4]。公表される個別の事故情報は、事故の通知内容・事故原因・再発防止措置を別々の欄に書き、原因には記号の区分を付ける作りになっている^[3]。起きたこと、なぜ起きたか、何をしたかを混ぜずに書き、原因を決まった区分で分類しておくから、後から横断して読める。社内の過去トラも、この分け方を手本にできる。

1 件 1 枚で残す欄——引くための欄と、読むための欄

過去トラの記録は、報告書の要約ではなく新しく書き起こす 1 枚として作る。欄は大きく 2 種類に分かれる。設計者が検索するときの鍵になる「引くための欄」と、見つけた事例を読んで今回の設計に当てはめるための「読むための欄」である。

この 9 欄に加えて、元の書類へのたどり道（不適合報告書の番号、是正処置回答の保管先、試験報告書の番号）を残しておく。1 枚に全部を書き写す必要はない。過去トラの記録は索引と要点であり、詳細は元の書類を開けばよい、という役割分担にしておくと、書き起こしの負担が小さくなり、続けられる。

原因の区分は、先に決めて記号で付ける

欄の中で最も効くのが原因の区分である。区分がないと、「組立時の締め忘れ」と「締結部の設計強度不足」が同じ「緩み」の事例として並び、設計レビューの場で読む人が、自分に関係のある事例を選り分けることになる。NITE の事故原因区分表は、この分け方の実例として参考になる^[3]。

NITE の区分表には、このほか製品に起因しないもの（F1・F2）と調査中のもの（H1・H2）がある^[3]。右端の列は NITE の表ではなく、社内の過去トラに使うときの置き換えの一例である。区分記号をそのまま使う必要はないが、設計不良・製造不良・品質管理不十分・表示の不備を別の区分にしている点と、製品と使い方の両方が効いた場合を独立した区分（B）にしている点は取り入れる価値がある。社内のトラブルでも「設計は仕様どおりだが、客先の使い方が想定と違った」という事例は多く、これを設計不良か誤使用かのどちらかに押し込むと、次の設計者が読んだときに判断を誤る。

工程側で防ぐべき事例（製造不良・品質管理不十分）は、設計レビューの照合先ではなく、工程 FMEA と工程の管理計画の側に回す。その落とし方は工程 FMEA の対策を管理計画（コントロールプラン）へ落とす記事で扱う。

教訓は「注意する」ではなく、答えられる問いで書く

過去トラの記録で最もよく見かける失敗は、教訓の欄が「締結部の設計には十分注意すること」のような注意書きで終わっていることである。注意書きは、レビューの場で「注意しました」と答える以外の使い道がない。次の設計者が答えを出せる形に直すと、たとえば次のようになる。

• 注意書き：「屋外用途では樹脂の劣化に注意」→ 問い：「紫外線にさらされる外装部品について、耐候性の等級と想定使用年数を仕様書に書いたか。その根拠の試験条件は何か」
• 注意書き：「ねじの緩みに注意」→ 問い：「振動がかかる締結部について、緩み止めの方式と、締付けトルクの管理値を図面に指示したか」
• 注意書き：「仕入先の材料変更に注意」→ 問い：「この部品の材料・製法が変わったとき、仕入先から事前に連絡が来る取り決めになっているか」

問いには必ず条件（屋外用途なら、振動がかかるなら）を入れる。条件のない問いは、すべての設計に当てはまってしまい、レビューで答える項目が増え続ける原因になる。問いの数は 1 件あたり 1〜3 問に抑え、それ以上になるなら事例を分けたほうが引きやすい。

引ける形にする——鍵を設計の言葉とFMEAの言葉にそろえる

部位・機能・故障モードの 3 つを引く鍵にするのは、設計の現場がもともとこの言葉で考えているからである。故障モード・影響解析（FMEA）の規格 JIS C 5750-4-3 は、序文で FMEA を「アイテム又はプロセスを，それが故障し得る場合の故障の仕方を特定するために評価する体系的な方法」と説明している^[5]。アイテム（部位・部品）と故障の仕方（故障モード）という組み合わせは、そのまま過去トラの鍵に使える。過去トラの鍵を FMEA の行の言葉にそろえておけば、次の機種の FMEA を作るときに、同じ部位・同じ故障モードの行へ過去の事例を直接ぶら下げられる。

同じ序文は、FMEA は同一のアイテムやプロセスのライフサイクルの中で何度でも実施でき、既存の管理や推奨される処置を含めることができ、閉ループの解析であれば処置の有効性の評価が可能になると書いている^[5]。規格の目次には「FMEA の文書化」という箇条があり、参考の附属書には「電源ユニットの FMEA に関するデータベース情報システムに基づいた報告書の作成例」という表題の事例も置かれている^[5]。FMEA を一度作って終わりの書類ではなく、情報を足しながら使い続ける記録として扱う考え方である。過去トラは、この「足していく情報」の最も確かな材料になる。起きたことのある故障モードは、想定しただけの故障モードより説得力があるからだ。

FMEA に載せたあとの優先順位の付け方（重大さ・発生・検出の評価と、対策の優先度の決め方）は、RPN からアクションプライオリティへ替える記事で扱う。ここで言いたいのは、過去トラの事例は FMEA の外に別の一覧として置いておくより、FMEA の該当行から参照できる形にしておいたほうが、設計の流れの中で自然に開かれるということである。

検索できることを、仕組みの要件にする

米国航空宇宙局（NASA）は、プログラムとプロジェクトの知識に関する方針（NPD 7120.6A）で、技術とプログラム・プロジェクトの知識をすべてのセンターと部局にわたって取り込み、アクセスできるようにすることを掲げ、教訓を集めて共有するこれまでの主な仕組みとして、オンラインのデータベース（LLIS）を挙げている^[7]。同じ方針は、人の入れ替わりやプロジェクトの終了による知識の喪失の影響を和らげることも目的に挙げている^[7]。

規模も分野も違うが、要点は社内の過去トラにそのまま当てはまる。記録は、書いた人がいなくなった後に、書いた人を知らない人が見つけられて初めて役に立つ。表計算ソフトの一覧でも、社内の文書管理システムでもよい。条件は 2 つだけで、部位・機能・故障モード・原因区分の列で絞り込めることと、設計部門の全員が開ける場所に 1 つだけ置くことである。部署ごとに別の一覧があると、どれが最新かを確かめる手間が照合を止める。

デザインレビューのどこで照合するか——前・中・後の 3 か所

記録を整えても、レビューの手順に照合が組み込まれていなければ開かれない。品質管理の学会誌に載った西浦・山田の研究は、デザインレビューで多段階のチェックを行っていても実際の市場では予測し得ない不具合が発生するという実情を出発点に、過去の不具合データの分析結果をデザインレビューに反映させる一連のアプローチを提案している^[1]。過去の不具合を「読んでおく資料」ではなく、レビューの項目そのものに組み込むという発想である。実務では、次の 3 か所に照合を置く。

前：絞り込みの条件を資料に書く

レビューの前に設計者が行うのは、過去トラの一覧を全部読むことではなく、今回の設計に関係する事例を条件で絞り込むことである。絞り込みに使った条件（部位、機能、使用環境、変更した箇所）を資料に書いておくと、参加者が「その条件では、あの事例が漏れていないか」と指摘できる。何件が該当し、どれを今回の対象としたかが分かれば、照合の漏れはレビューの場で見つかる。

設計の一部を変える変更設計では、絞り込みの鍵に「変更した箇所」を加える。変更点一覧表を起点にした簡便なレビューの報告もある^[2]。その変更点一覧に「照合した過去トラの番号」の欄を足しておけば、変更点ごとにどの事例と突き合わせたかがレビュー資料に残る。変更点を起点にしたレビューの進め方と、変化点を DRBFM の議論にどうつなぐかは、変化点管理を DRBFM につなぐ記事で扱う。

中：1 件ずつ、答えと確認の方法を記録する

レビューの中では、添えた事例の一覧を上から順に扱い、事例ごとに記録した「次の設計で答える問い」に設計者が答える。答えは「対策済み」ではなく、どう手当てしたかと、それを何で確かめたかを書く。「締付けトルクの管理値を図面に指示し、振動試験で緩みがないことを確認した（試験報告書番号）」のように、確認の方法まで書かせると、問いに「はい」とだけ書いて通る形骸化を防げる。

参加者の役割は、答えの妥当性を確かめることに加えて、一覧に載っていない事例を思い出すことである。絞り込みの条件がずれていれば、関係する事例が一覧から漏れる。「この部品は屋外でも使われるのに、屋外の事例が入っていない」という指摘は、絞り込みの条件を資料に書いてあるからこそ出てくる。

後：「該当しない」の理由まで残す

照合で最も記録が抜けやすいのが、「今回は該当しない」と判断した事例である。該当しないと判断したこと自体は正しいことが多いが、理由が残っていないと、次にその設計を流用した人は、同じ事例をもう一度検討しなければならない。逆に、理由が残っていれば「前回は屋内専用だから該当しないとしたが、今回は屋外にも出すので該当する」という判断が一目でつく。理由の欄は 1 行で足りる。「屋内専用のため紫外線の条件がない」のように、事例の「効いた条件」の欄と照らして書くと、読む人が判断を追える。

過去トラの一覧を、そのままチェックリストにしない

過去トラの照合をレビューに組み込むと、次に起きやすいのが「全事例を毎回チェックする」運用への変化である。事例は年々増えるので、チェックする項目も増え、やがてレビューのたびに数百の項目に「該当なし」と付けるだけの作業になる。こうなると、本当に関係のある数件が埋もれる。

これを避けるには、2 つの出口を用意する。1 つ目は設計基準への昇格である。同じ問いが複数の事例から繰り返し出てくるなら、それは個別の事例ではなく設計の決まりとして書くべきものである。設計基準や標準の設計チェックリストに移したら、過去トラの記録には「設計基準の何番に反映済み」と書き、照合の対象からは外す。レビューでは設計基準への適合として確認されるので、同じことを二度確認しなくて済む。

2 つ目はFMEA への反映である。前の節で述べたとおり、事例を FMEA の該当行に結び付けておけば、FMEA を見直すときに事例が自動的に目に入る。過去トラの一覧は、設計基準にも FMEA にもまだ入っていない事例を置いておく「待合室」の役割にとどめる。こうすると、一覧の件数はむやみに増えず、レビューで照合する件数も、今回の設計に関係する数件に収まる。

規格との関係——書類の形は自社で決めてよい

品質マネジメントシステムの規格 JIS Q 9001 は、目次に「製品及びサービスの設計・開発」（箇条 8.3）と「不適合及び是正処置」（箇条 10.2）という箇条を置いている^[6]。過去トラの記録は、この 2 つの間をつなぐ位置にある書類だと言える。是正処置として起きたことを記録し、その学びを次の設計・開発に持ち込むためのものだからである。

ただし、規格は書類の作り方までは決めていない。同じ規格の序文は、この規格が「文書類をこの規格の箇条の構造と一致させる」必要性を示すことを意図したものではないと明記している^[6]。また序文は、リスクに基づく考え方によって、計画した結果からの乖離を引き起こす可能性のある要因を明確にし、予防的管理を実施できると説明している^[6]。過去トラの記録を設計レビューで照合するのは、この予防的な管理の具体的なやり方の 1 つであり、様式や欄の立て方は自社の設計の進め方に合わせて決めてよい。

仕入先で起きたトラブルを、設計の過去トラに入れる

購入部品や外注加工品のトラブルは、仕入先への是正処置要求と回答で閉じてしまい、設計側の過去トラに入らないことが多い。しかし、仕入先の回答に書かれた原因が「図面の公差が工程能力に対して厳しすぎた」「材料の指定があいまいで、仕入先が同等品を選んだ」というものであれば、それは設計で防げた事例である。

調達・品質保証の担当者が仕入先の是正回答を受け取ったときに、原因の区分を 1 つ確かめる習慣をつけるとよい。原因が図面・仕様書・材料指定にあるなら、設計部門の過去トラの記録に 1 枚起こす。原因が仕入先の工程にあるなら、仕入先の管理の側で扱う。この振り分けは、前に挙げた原因区分の「設計不良」と「製造不良」の区別と同じ考え方である。仕入先の工程の変更そのものを設計側でどう拾うかは、変化点管理と DRBFM の記事の範囲になる。

よくある質問

過去の報告書が大量にあります。全部を書き起こすべきですか

全部を一度に書き起こす必要はない。現実的なのは、次に始まる設計の対象部位に関係する報告書から書き起こし、レビューのたびに少しずつ増やしていくやり方である。1 回のレビューで該当しそうな報告書を 5〜10 件選び、この記事の 9 欄で起こしていけば、よく使われる部位の事例から順に揃っていく。古くて誰も開かない報告書は、該当する設計が出てきたときに起こせばよい。

原因がはっきりしない事例も記録に入れてよいですか

入れてよい。NITE の区分表にも、原因不明のもの（G1〜G3）が独立した区分としてある^[3]。原因が分からないまま記録から外すと、同じ現象が再発したときに「前にもあった」ことが分からない。メカニズムの欄に「推定」と明記し、起きたことと効いた条件だけでも残しておけば、再発したときに 2 つの事例を並べて原因に近づける。

記録は誰が書くのがよいですか

起きたことと原因は、トラブルを処理した品質保証や製造の担当者が一番よく知っている。一方、「次の設計で答える問い」は、設計者でなければ書けない。そのため、品質保証の担当者が 6・7 欄（起きたこと・メカニズム）までを下書きし、設計者が 8・9 欄（問いと確認の方法）を書いて完成させる分担が回りやすい。引く鍵になる 1〜5 欄は、設計者が自分で探すときの言葉にそろえるよう、最後に設計者が確認する。

デザインレビューの時間が足りず、事例を全部読めません

レビューの場で事例を読むのではなく、レビューの前に設計者が絞り込み、該当事例と答えを資料に書いてくるのが前提である。レビューの場では、答えに疑問のある事例と、「該当しない」とした事例の理由だけを確かめればよい。それでも時間が足りないなら、絞り込みの条件が広すぎるか、設計基準へ昇格させるべき事例が一覧に残ったままになっていることが多い。

まとめ

過去トラが使われないのは、記録が「その件を閉じるため」の形のまま置かれていて、設計者が探す言葉で引けないからである。部位・機能・故障モード・効いた条件・原因の区分を引く鍵にし、教訓を条件付きの問いで書いた 1 件 1 枚の記録に起こし直す。原因の区分は、公的な事故情報の区分のように、設計・製造・品質管理・表示・使い方・経年に、施工や輸送、原因不明までを分けて付けておく^[3]。

デザインレビューでは、前に設計者が条件で絞り込み、中で 1 件ずつ手当てと確認の方法を答え、後で「該当しない」の理由まで残す。繰り返し出てくる問いは設計基準へ、故障モードとして扱えるものは FMEA の該当行へ移し、過去トラの一覧は今回の設計に関係する数件だけが照合に上がる状態に保つ。規格は書類の形を決めていないので^[6]、この形を自社の設計の進め方に合わせて作ればよい。

出典・参考資料

1. 不具合情報に基づくデザインレビュー項目構築に関する研究（西浦友子・山田秀／品質 40 巻 4 号・日本品質管理学会／2010 年 10 月）
2. Quick DR/DRBFM による不具合不満の未然防止（大島恵・奈良敢也・吉村達彦／自動車技術会論文集 42 巻 2 号／2011 年）
3. 個別事故情報（個表）の見方及び事故原因区分表（独立行政法人製品評価技術基盤機構／令和 6 年度 第 2 四半期 事故情報収集結果の添付資料）
4. 事故情報収集制度の概要（独立行政法人製品評価技術基盤機構）
5. JIS C 5750-4-3:2021 ディペンダビリティマネジメント―第 4-3 部：システム信頼性のための解析技法―故障モード・影響解析（FMEA 及び FMECA）（無料プレビュー）（日本規格協会／2021 年 8 月 20 日改正）
6. JIS Q 9001:2015 品質マネジメントシステム―要求事項（無料プレビュー）（日本規格協会／2015 年 11 月 20 日改正。追補 JIS Q 9001:2015/AMENDMENT 1:2025 が 2025 年 3 月 21 日に発行されている）
7. NPD 7120.6A Knowledge Policy for Programs and Projects（米国航空宇宙局 NASA／2019 年 12 月 16 日発効・2024 年 7 月 10 日改訂）

WHITE PAPER

この記事の理解を深める
無料ホワイトペーパーをプレゼント

製造業の現場で使える実務資料（PDF）を無料でお届けします。"こんな資料が届きます" ↓ 下のボタンからどうぞ。

🔒 全文は無料ダウンロードで