設計・計画の不備による品質や安全に関するトラブルが後を絶たない。この理由のひとつに、トラブル情報(過去の不具合事例や、FT図、FMEA表など)^※1をうまく活用できていないことが、しばしば指摘される。

トラブル情報を、製品や製造工程の設計・計画業務に活用するために、トラブル情報データベースを持っている企業は多い。しかし、残念ながら、それらのデータベースは、実際の設計・計画時の未然防止・再発防止活動のなかで、うまく再発防止チェックリストやFMEA、FTAに有効に再利用できていない。トラブル情報が、設計時に再利用できない理由は多くあるが、例えば、以下のようなものが挙げられる。

・不具合情報の記述が不十分で、設計で使えるほどのものでない。
・他設計に再利用できる不具合情報を特定アイテムの不具合情報として整理している。
・不具合情報があちこちに存在していて、体系的に引き出せない。
・不具合情報は膨大にあるため、設計実務で使えるようにうまく検索できない。

※１：トラブル情報には、例えば、再発防止設計事例、試作問題点管理表集などの実際に市場や工程または開発段階で発生した不具合事例や、FMEA表、FT図などの不具合リスクの検討結果を記録したリスク解析情報がある。更には、設計標準などの技術基準類にも、設計の背景・根拠として不具合に関する何らかの記述(実際にある製品で発生した不具合や一般的な不具合ノウハウなど)が潜んでいることが多い。(ここでは、不具合事例、リスク解析情報、不具合の記述を含む技術基準類などを総じて、「トラブル情報」と呼ぶ。)

なぜ、先に述べた事態が生じてしまうのか？
１つには、トラブル情報自体に、設計・計画で活用できる教訓がきちんと整理されていないことが挙げられる。トラブル情報の多くは、次設計への再利用を主目的とした文書（設計開発業務へのインプット文書）ではなく、当該開発業務・不具合対応業務の結果として作成される報告書（設計開発業務からのアウトプット文書）である。そのため、トラブル情報のそのまま、設計に使えといっても、使う側のニーズに応じた知識が整理されていなければ、使いようがない。
したがって、トラブルの経験や情報を設計に活かすには、次の設計に使えそうな知識をしっかりと抽出しなければならない。
すなわち、「トラブル情報の教訓は、今後どのようなアイテムの、どのような設計・計画業務（製品設計、工程設計、購買計画、設備保全計画など）に再利用されるべきか？」という視点をもって整理される必要がある。

トラブル情報データベースがうまく使えない理由に、再利用可能な知識がうまく設計で引き出せないことが挙げられる。トラブル情報の登録件数が百件、千件･･･と増え、不具合情報が一元管理されると、社内の他の設計部署や事業所から、自分たちに使える不具合情報や全く使えない不具合情報が無差別にどんどん登録・蓄積されてくる。さらに、このような情報データベースでは、ささやかな検索キーで文書内を検索させる場合が多く、不具合情報の登録件数が増えると、無駄な検索結果が膨大になり、設計者が、自分に必要な知識を探すだけで一苦労する。結果的に事実上役に立たない情報データベースになってしまう。

トラブル予測・未然防止のためのデータベース活用において、トラブル情報を文書のまま保有し、文書検索する仕組みでは限界がある。
トラブル予測・未然防止のためのデータベース活用を成功させるには、まず、過去のトラブル経験やトラブル情報から、再利用可能な知識をしっかり抽出し、また設計ニーズに対応した検索でうまく引っ掛るように、知識を体系的に整理することが必要である。
このためには、「トラブル知識の構造化」を行うことが必要である。
トラブル知識の構造化とは、トラブル情報に含まれているトラブル発生メカニズムを把握し、各機器やその一般的属性と、それにおいて発生する不具合事象、不具合事象要因、その不具合事象に対する対策内容などを、再利用可能な一まとまりの構造とした因果モジュールを整理し、その因果モジュールを因果連鎖の流れに沿って階層的に表現することで，故障発生メカニズムの総体をまとめることである。
トラブル知識の構造化によって、以下のようなメリットを得ることができる。