後進の方に不具合対応の方法をよくヒアリングされますので、備忘録として記載します。
（ GD3とFPAによる不具合解析手法の思想をもとにした私なりの意見です。
現場の温度感と設計開発の流れがありますので、少々読みにくい内容になっております）

不具合対応を行うときの考え方の
『物事のストーリーは「原因」ではなく、「現象の連鎖」であらわされる』について、
実は、設計開発を行うときの考え方の
『設計者はロジカルな根拠をもって、机上理論の数字で表す』ことも、
結局のところ本質は同じような事を言っているように私は感じています。

①ロジカルな根拠とは
→新規で製品設計をする時には、
　実際に起こりうることを想定（推定、一種の妄想）をすることで、
　「こういう考えの元、こんなことはやっていいよね」
　「こういう考えの元、こんなことはやってはいけないよね」を
　考え・理論的に物事を組み立てる（設計思想や倫理等）
→その思想が「現象の連鎖」の大元に繋がる

②数字で表すとは
→やっていい事・悪い事を定量的に判断することにより
　皆が同一基準で判断出来る様に行う。
→その判断が「原因」の大元に繋がる

そのため、不具合対応をする時には、逆に「実際に起きた現象」を、
実機試験やスワップ確認で「事実」を確認し、
一つ一つ整理する事（FTA,FPA等のツールを適切に使用）で、
早く不具合解決対応が可能になると考えます。

これこそが「現象の連鎖」の確認であり、後進の方が不具合対応をする際にも、
今まで行ってきた”ロジカルな根拠”のストーリーに自分たちが
「見落とし」や「気付いていない所はないのか」の精査確認を頭を真っ白にして、
改めて行う事に繋がります。
「原因」を確認する際には、机上論等に見落としが無いのかを精査確認を私は行います。

闇雲に不具合対応は取り組むのではなく、頭を整理するためのツールとして、

FPA:現象の連鎖・現因の確認
FTA:原因・（現因）の確認

を使っているだけだと私は思います。

あくまで、設計ツール（DRBFM,FMEA,FTA,なぜなぜ解析 等）の
各種ツールは使いこなしてこそ、その真価を発揮します。
（現因:何かを行った「差」の確認）
GD3の本質をきちんと学ぶと本当に製品設計現場では、沢山の事に気づかせて頂けます。

…上記の内容は、後進の方に設計伝承している時の様子の備忘録になります。
「発見・気付き」について、様々な事に興味を持って生活をしているつもりですが、
なかなか色々な方の思想に触れるたびに自分とは違う価値観を学ばせて頂き、
日々考えさせられる事ばかりです。
色々な方の自分自身とは違った、知恵・工夫・思想がまた、面白くもあり、
今後も様々なご意見をお聞きしていきたいと考えております。