ものづくり系サークルに所属する学生のために，自動車業界の国際規格IATF16949をベースとしたVDA FMEA（DFMEA）についての説明を行う
はじめに
この記事では，ものづくり系サークルに所属する学生のために，自動車業界の国際規格IATF16949をベースとしたVDA FMEA（Verband der Automobilindustrie Failure Mode and Effective Analysis）のうち、DFMEAについての説明を行う
参考文献はこれ（神の書）
↓これ以外の参考文献はここから
なお，FMEAにはスプレッドシートを用いるAIAG（ Automotive Industry Action Group: 全米自動車産業協会）の流派とStructure treeを用いるVDA（Verband der Automobilindustrie: ドイツ自動車工業会）の流派があるが，この記事ではVDA FMEAを前提として説明を行う
FMEAのメリット
FMEAとは「Failure Mode and Effects Analysis」の略で，設計の段階で製品のリスクを分析し，対策を取るための手法である
↓FMEAの概要についてはここら辺の記事を参照
≫FMEAとは（AIAG＆VDA - FMEA）
≫新しいFMEA-AIAG＆VDA(故障モード影響解析)の作成手順を徹底解説
上記を踏まえたうえで，筆者が思う「ものづくり系サークルでFMEAを導入するメリット」を紹介する
- 自分が設計したものに対して体系的かつ網羅的にリスク分析ができる
- チームでリスクを洗い出し，原因を考え，対策を取ることができる
- 製品設計・工程設計の知見をチーム内に蓄積することができる
1. 体系的かつ網羅的なリスク分析
FMEAを実施することによって，自分が設計したものに対して体系的かつ網羅的にリスク分析ができるようになる
一般的な学生が自分で何かを設計する際は，これまで勉強してきた知識や製作の経験に基づいて「ここはやばそう」と感じる箇所について対策を取っていくことになるが、この方法では必然的に「自分の経験から重要だと感じたところ」や「ここ数年で失敗したこと」のみに対策が偏ってしまい、本当に見落としなく重大なリスクの対策できているのかを確認することができない
結果、自分の検討の甘さや勘違いなどから思いもよらない箇所で故障が発生し、それの対策にてんやわんやする羽目になってしまう
今回紹介するVDA FMEAは7つのステップで構成され、そのうちの2、3、4ステップ目でそれぞれ「Structure tree」「Function tree」「Failure tree」と呼ばれるツリーを作成し、製品の構成、構成品の機能、故障モードを整理する
ツリー形式で作成するので抜け漏れがあれば一目瞭然であり、それぞれの構成品の機能や故障モードの関連性も非常に捉えやすい。FMEAで最も困難な「故障モードの列挙」という作業も、後述する「Failure Chain」の考え方を用いることである程度論理的にこなすことができるようになる
VDA FMEAを実施することで、これまでなんとなくでやって、ちゃんとできているかもよくわからなかったリスク分析/対策の作業を、網羅的かつ効率的な作業へと昇華させることができる
2. チームでの原因を分析および対策
FMEAは個人ではなくチームで行う作業だと規定されている
製品設計者あるいは工程設計者が実施したFMEAをベースとして、チームのあらゆる部門の責任者が集まってレビューを行い、FMEAを完成させていく
そんなFMEAを効果的に実施するためには様々なバックグラウンドを持ったメンバーで構成されたチーム（cross sectional team）が不可欠である
ものづくり系サークルでFMEAを実施するなら、少なくとも各セクションの代表は集まるといい
設計者以外の目線からもFMEAを実施することでリスク分析の網羅性はより盤石なものになると同時に、チーム内のステークホルダー達に製品や工程の構成、機能、故障モードを周知することができる
チームでものづくりをする上で最も重要で、かつスケジュールの都合上最もうやむやになりがちな「情報共有」という作業も、FMEAを実施することで自然と達成できることになる
また、引き継ぎも兼ねるならついでに後輩も巻き込んでしまえばいいし、設計変更や新規設計をやる場合は現役で作ったFMEAをOBに見てもらったりしてもいいかもしれない
1人では気づかないようなミスも、チームで集まり意見を交わせばどこかで防ぐことができるようになるはずである。スイスチーズモデルを有効的に活用していきたい
3. 最強の引継ぎ資料
FMEAを実施することで
- 製品/工程がどのような構成になっていて
- それぞれどのような機能を持つように意図されていて
- 故障が発生する原因と発生した際の影響が網羅されており
- それらの故障に対して定量的なリスク評価と対策の優先度が設定されており
- リスクを低減するためにどのような対策がとられたか
が、視覚的にわかりやすい形でドキュメントとして残ることになる
ものづくりを経験したことがある人なら、上記のような引き継ぎ資料を作ることがどれほど大変かが理解できると思う
FMEAはリスク分析のための優れたツールであるだけでなく、ものづくり系サークルにとって最も重要な「いまはもういない設計者の意図」を残すツールにもなる
数年でチームメンバーが全員入れ替わってしまうようなものづくり系サークルにとって、理想の引き継ぎ資料となるのではないだろうか
製品設計の引き継ぎをしたい場合はDFMEA、工程設計の引き継ぎをしたい場合はPFNEAを行えばよい
DFMEAの手順
AIAG&VDA FMEAハンドブックでは、FMEAは7つのステップで実施するよう規定されている
- Planning and Preparation
- Structure Analysis
- Function Analysis
- Failure Analysis
- Risk Analysis
- Optimization
- Results Documentation
この記事では、それぞれのSTEPについて具体的に説明していく
また，各STEPでは、筆者が設計した鳥コン滑空機であるQX-20を例にして実施手順について説明していく
↓使用したファイルのダウンロードはこちら
FMEA Tools
FMEAを実施するためには何かしらのソフトウェアがあった方がいい
スプレッドシートなどでもできなくはないが、バージョン管理や構造の把握に難があるので、今回はネットで適当に見つけた無料ツールの中からFMEA用のExcelアドインであるFMEAstudioを使うことにする
ちなみに無料版は12回までしか要素の追加ができないため、構成要素の多いFMEAを実施する場合はファイルを細かく分割する必要がある
FMEAに使えるソフトウェアは他にも種類があるし、学生であれば有料版の機能をタダで使えるものもあるかもしれないので、気にいるソフトがあるかどうか探してみて欲しい
STEP1: Planning and Preparetion
STEP1では以下のことを実施する
- BOMの作成
- DFMEAの対象の決定
BOMとは、Bill of Materialの略称で、日本語では部品表と呼ばれたりする
BOMを見れば機体を構成する全ての部品を把握できるし、これから何を作らなければならないかも認識できる
ある程度のBOMが完成したら、BOMを見ながら「どの部品に対して、どの階層でDFMEAを実施するか」を決定する
DFMEAの対象部品と階層が決まればSTEP1は完了である
例: QX-20
BOMの形式はいろいろあるが、筆者はマインドマップのツールを使ったツリー形式のBOMをおすすめする
実際にQX-20でBOMを作成してみるとこんな感じになった（クリックで拡大）
今回のBOMは全体設計の立場から作成したため階層はそこまで深くなっていないが、きちんと作成すればネジの1本まで書き下すことができる
そのレベルまで作り込まれたBOMがあるだけで、設計資料としての価値は計り知れないと思う
また、一度BOMを作りこんでしまえば、翌年以降は変更点を管理するだけでよい
この記事では例として主翼に対してDFMEAを実施することにする
MindMeister
- オンラインで使えるマインドマップツール
- PCのブラウザとスマホアプリから同時編集が可能
- 無料版は3つまでマインドマップを作成可能
- 画像出力には非対応
Xmind
- デスクトップアプリとして使える
- ファイルはローカル保存
- ファイル数に制限なし
- 無料版で画像出力に対応
今回は画像出力ができるという点からXmindを使用している
STEP2: Structure Analysis
STEP 2では，以下のことを実施する
- Structure treeの作成
Structure treeとは，システムを構成する要素を階層的に表し，構造的なつながりによる依存関係を可視化したものである
要するにSTEP1で作ったツリー形式のBOMのことだが、DFMEAのStructure Analysisでは、FMEAの対象として注目する部品（Focus element）を中心に、一つ上と一つ下の部品で構成された3階層のツリーを作成する
| Next Higher Level | 解析範囲の中で最も高いレベルの構成要素 |
| Focus Element | 注目している構成要素で、故障解析の中心となる |
| Next Lower Level | Focus Elementを構成する要素で、Charasterictic Typeも含む |
ちなみにFMEAStudioでは，1番上のレベルをProduct，2番目のレベルをSystem，3番目のレベルをComponentとよぶ
Structural treeの作成はBOMから引っ張ってくるだけなので簡単だが、どの階層に注目するかの判断はなかなか難しい
とりあえず最初は機体全体をトップにしたStructure treeに対してDFMEAを実施してみて、必要に応じて特定の部品についてどんどん掘り下げていくのがいいんじゃないかと思う
注目する部品を中心とした3つの階層からなるStructual treeが完成すればSTEP2は完了である
例: QX-20
今回の記事では例として、機体（QX-20）をトップにしたStructure treeと、そこから１つ階層を堀り下げたStructure treeを使用する
上の図を見ると、主翼をさらに主翼と中央翼に分けるようなStructural treeになっているが、滑空機なら主翼と翼胴結合部を分けているイメージ、プロペラ機なら主翼と主翼マウントを分けているイメージである
中央翼じゃない部分の主翼をどう呼ぶのかが分からなかったので、主翼-主翼という少しややこしいStructure treeになってしまった
STEP3: Function Analysis
STEP 3では以下のことを実施する
- Function treeの作成
function treeとは、前ステップで作成したStructure treeの各部品について，その部品がもつFunctionを記入したものである
Function treeを作ることで，それぞれの部品がどのような機能を意図して設計されるのかが明確になり，部品ごとの機能のつながりを把握することができるようになる
ここで、DFMEAにおけるfunctionは以下の要素で定義される
- 入力と出力の関係
- 外部とのインターフェース
また、functionの記述は動詞ベースの現在形で書くよう推奨されている（〇〇を××する）
このステップでfunction treeを作ることの目的は、それぞれの構成品の機能的な繋がりを可視化するためである
function treeで機能的な繋がりがある構成品は故障モードにおいても繋がりがあるし、逆にfunction treeで繋がっていない部品同士は故障しても影響を与えることはない（例: 尾翼のリブが曲がったとしても主翼の抗力は増加しない）
functionの繋がりを論理的に確かめるためには，以下の質問が有効である
- （トップダウン）上位の機能をどのようにして実現するのか（How？）
- （ボトムアップ）下位の機能はなぜ必要なのか（Why？）
この質問をすることで，function analysisの正しさや抜け漏れがないことを確認することができる
このような質問を駆使しつつ、できる限り抜け漏れのないfunction treeができればSTEP3は完了である
ここでの機能の抜け漏れは、このあと実施する故障モード分析の漏れに直結する（非構造部品だと思っていた部品が実は荷重の伝達経路になっていた、など）
そのため、自分でfunction treeのベースを作った後で、チームメンバーと一緒にfunction treeの抜け漏れがないかを検討する場を設けるといいと思う
例: QX-20
今回はまずQX-20のBOMを見ながら「下位の機能はなぜ必要なのか（Why？）」の質問を用いてボトムアップで機体の機能を考えた
- 主翼 → 揚力の発生、ロール安定、...
- 水平尾翼 → 縦のトリム、縦の操縦、...
- 垂直尾翼 → 方向のトリム、横・方向の操縦、...
- ...
その結果、鳥コン滑空機であるQX-20が持つべきFunctionを次のように定義した
ここをスタート地点として、今度は逆に「上位の機能をどのようにして実現するのか（How？）」という視点から主翼のFunctionについて考えていく
機体のFunctionをどのように主翼で実現するのか？を考えることで、主翼のFunctionは以下のようになった
Function treeはこんな感じ
Function Analysisを実施することで、主翼とその構成部品の持つ機能、さらにはそれらの機能的なつながりが明確になった
ここからさらに主翼の持つ５つの機能について掘り下げてみる
先ほどと同じように、「上位の機能をどのようにして実現するのか（How？）」という質問を用いて下位の部品の機能を考えてみると以下のようになった
STEP4: Failure Analysis
4つ目のステップでは以下のことを実施する
- Failure treeの作成
いよいよFMEAの軸となるFailure Modeの分析を始める
Failure Modeは、STEP3で定義した部品の機能の「機能不全」として定義される
機能不全には以下のパターンがある
- 突然機能が失われる
- 徐々に機能が悪化していく
- できたりできなかったりする
- やりすぎる
- 足りない
これを、例として主翼の「揚力を発生させる」という機能に当てはめてみると、主翼の故障モードは次のようになる
- 揚力が突然失われる
- 揚力が徐々に少なくなる
- 揚力が発生したりしなかったりする
- 揚力が大きすぎる
- 揚力が小さすぎる
「揚力が発生したりしなかったりする」を除けばだいたいイメージできるんじゃないだろうか
ちなみに、上記の主翼の揚力の例のように、故障モードは1つの機能に対して複数あるのが当たり前となっているため、チームメンバーでレビューを行うときは、設計者が行った故障モード分析に対して「他にないか？」という目線で確認してもらうといい。
このような故障モード分析を、3つのレベルの全ての機能に対して実施する
例: QX-20
主翼の「最小限の抗力を発生させる」というFunction treeについて考える
上記のFunctionに対する機能不全を考えると、例えば以下のようになる
こんな感じで、FunctionからどんどんFailar Modeを書き起こしていく
Failure chain
それぞれの機能に対して設定した故障モードは、Failure chainによって繋がっている
Failure chainとは、ある注目している故障モードに対して、1つ上の階層の故障モードは注目している故障モードによる故障の影響（Failure effect）になっており、1つ下の階層の故障モードは注目している故障モードの故障の原因（Failure cause）になっている、という考え方である
この考え方がVDA FMEAのすごいところだと思う
例えば、主翼の「抗力が大きい」という故障モードについて考えてみる
「抗力が大きい」という故障モードによって1つ上の階層の故障モードとして「全機の揚抗比が悪化する」が発生するし、「抗力が大きい」という故障モードは1つ下の階層である主翼や中央翼の故障モードによって引き起こされている
また、その主翼や中央翼の故障モードはさらに1つ下の故障モードによって引き起こされている
このようにどんどんFailure chainを掘り下げていくことで、最終的には全ての部品について「この部品はどのような原因でどのような故障をし、それによって最終製品にどのような影響が出るのか」がわかることになる
これがわかっている状態で設計するのとただ闇雲に設計するのでは製品の仕上がりに大きな違いが出るのは間違いないし、設計から製造への情報のインプットの質も大幅に向上する
もちろん1人で一発目で完璧な故障モード分析を行うことは限りなく不可能なので、他のチームメンバーに見てもらったり、後輩は引き継いで年を重ねるごとにブラッシュアップしていくのでも良い
structure treeの各部品についての故障モードを列挙し、Failure chainで繋ぐことができればSTEP4は完了である
例: QX-20
Failar Analysisが完了すれば、ツリー形式よりもデータシート形式の方が分かりやすくなる
機体を頂点としたDFMEA（クリックして拡大）
主翼を頂点としたDFMEA（クリックして拡大）
STEP5: Risk Analysis
5つ目のステップでは、以下のことを実施する。
- 評価マトリックスの作成
- Severityの評価
- Prevention Controlの調査
- Occurrenceの評価
- Detection Controlの調査
- Detectionの評価
- Action Priorityの計算
最終的には全てのFailure Modeに対してAP（Action priority）が設定されることになる
リスクの大きさを定量的に評価し、APによって対策の優先順位をつけることで、限られたリソースの中で最大限の改善効果を発揮することができるようになる
それでは順番に説明していく
評価マトリックスの作成
FMEAでは、リスクの大きさをSeverity（S）、Occurrence（O）、Detection（D）の3つの観点から、それぞれ10段階評価で定量的に評価する
Sは故障モードの深刻さ、Oは故障モードの発生頻度、Dは故障モードの検出性である
これら3つの指標を組み合わせることによって、いろいろな故障モードを表現することができるようになる
- 非常に深刻だが、ほぼ発生することはなく、発生したとしても容易に検出できる故障モード（注意しておけば問題ない）
- 深刻さは中程度だが、それなりに発生し、ほぼ検出できない故障モード（毎回流出して問題になる）
- 深刻さは低いが、高い確率で発生し、検出は容易な故障モード（やり直しが発生してスケジュールが遅れる）
リスクを10段階評価する際は、FMEA実施者によって評価がばらつかないように、評価マトリックスを作成する
VDA FMEAのハンドブックにもマトリックスは載っているが、自動車産業用なので、自分たちが作るものに対して修正する必要がある
例: QX-20
今回は鳥コン滑空機を題材にしてリスクマトリックスを作成してみた
Sのマトリックス
Sのマトリックスは、最も深刻なものから、パイロットの身に危険が及ぶ＞機体の性能の上限値が下がる＞パイロットの負担が増える＞…、となるようにした
Oのマトリックス
Oのマトリックスで評価するDFMEAの故障モードの発生頻度とは、設計ミスで意図せずして故障モードが起こってしまう確率である
わざと性能が悪くなるような設計をする設計者はいないはずので、性能が良くなるように設計したつもりだったのに性能が悪いものができてしまう確率、と言い換えることもできる
なので、このような設計ミスの発生頻度の高さとしては、前例や実績が全くない新技術を採用する設計＞類似の前例や実績がある技術を採用する設計＞ほぼ同一の前例や実機ベースの豊富な実績のある改良設計、とした
現場・現物・現実から遠いところで設計したものほど、思いもよらないトラブルに見舞われるリスクが高いということになる
Dのマトリックス
Dのマトリックスでは設計によって引き起こされる故障モードの検出性を評価する
設計ミスの検出性とは、万が一設計ミスがあったとして、その設計ミスを試験や解析などで見つけることができるかどうか、という指標である
設計ミスは本番までに見つかった方がいいし、どうせ見つかるなら早ければ早いほどいいので、Dの評価マトリックスは次の３つの要素をもとにリスクの高さを設定する
- 検出が難しい
- 見逃す確率が高い
- 見つかるのが遅い
筆者はDの評価マトリックスを「見逃す確率の高さ」（いかに本番に近い環境を模擬できるか）に重点を置き、解析＞モデル化した試験＞本番に近い試験、の順でリスクの大きさを設定した
一方で、検出の時期に注目すると、機体レベルの試験＞部品レベルの試験＞解析、の順でリスクが大きい（検出可能な時期が遅い）
このように、何を重視して評価マトリックスを作るかによって評価されるリスクの大きさは変わってくるため、評価マトリックスの作り込みも重要な要素になってくる
設計者やチームとしての色が出る部分なので、前もって作っておくといい
3つの評価マトリックスが揃ったら、いよいよリスクの評価を行っていく
Sの評価
S（Severity）の評価は、その故障モードに対するFailure effectに対して行われる
故障モードによって引き起こされる製品への影響の深刻さを、上で作成した評価マトリックスを用いて10段階で評価する
後のAP（Action priority）の項で説明するが、Sの値が大きい項目はOやDが小さい値でもAPが大きくなるように設定されている
また、故障モードがシステムへ与える影響であるSの評価は、基本的に変わることのない普遍の値である
たとえ設計を変更してフェイルセーフを組み込んだり冗長性を増したりしても、改善されるのはOの値やDの値であり、もし万が一壊れてしまった場合のFailure effectの深刻さは変わることはない（冗長系が全て故障した場合の影響度を考える）
Prevention Controlの調査/Oの評価
Oの評価を実施するために、現在実施しているprevention controlを調査する
prevention controlとは故障モードの発生確率を下げるための予防措置であり、DFMEAにおいては以下のようなものがある
- 過去の機体のデータを使う
- 類似の設計のデータを参考にする
- 試作品の試験データを参考にする
- 設計便覧や引き継ぎ資料を参考にする
- ファールセーフを盛り込む
- フールプルーフを用いる
- 安全率を高くする
ここでは「これからやろうとしていること」ではなく、「いま既にやっていること」を記述する必要がある
「これからやろうとしていること」はSTEP6で記述することになっている
調査したprevention controlに対して、評価マトリックスをもとにOの評価を実施する
Sの評価とは異なり、Oの評価はprevention controlの見直しや設計の変更によって改善することができる
Detection Controlの調査/Dの評価
Dの評価を実施するために、現在行なっているdetection controlを調査する
DFMEAにおけるdetection controlとは、製品製作後に行う各種試験やシミュレーションのことで、以下のような種類がある
- 荷重試験
- 動作試験
- 機能試験
- 飛行試験
- 構造シミュレーション
- 空力シミュレーション
- フライトシミュレーション
これらの試験やシミュレーションをすることで、万が一設計ミスがあった場合でも事前にミスを発見し、修正することができる
※設計時に行う解析や要素試験ではなく、製品完成後の実機試験やシミュレーションのことである
Action Priorityの計算
S、O、Dの評価を入力すると、AP（Action Priority）が自動的に計算される
APはSODの組み合わせで以下のように決定される
似たような指標であるRPN（Risk Priority Number）が単純なS×O×Dの掛け算であるのに対して、APはSにより重みづけをしているのが特徴である
例: QX-20
QX-20の主翼についてのSOD評価は以下のようになった
Sの評価
主翼は機体の安全性や性能に大きな影響を及ぼすため、全体的にSの値は大きくなっている
そもそも鳥人間コンテストに出場するような機体はフライトに最低限必要な装備しか搭載していないので、Sの値が小さくなるようなことはあまりないと思う
Oの評価
基本的に主翼の設計はこれまでの機体の実績を踏襲するため、そこまで設計ミスの発生確率は高くないと思われる
ただし、自作翼型の実際の性能や失速特性についてはXFLR5の解析に頼るほかなく、機体のロール安定などについてもまだまだ定量的な実績が少ないため、これらの設計を新しくする場合には設計ミスの発生確率は大きくなると見込まれる
ちなみに、QX-20は胴体構造と尾翼形状でかなり大きな変更を行った分、主翼設計はこれまでの設計を踏襲した無難なものに抑えることになったため、それがOのリスク評価にも表れているように思う
Dの評価
主桁については荷重試験を実施しているため滅多なことでは構造破壊に至ることはないが、リブやスキンなどの二次構造は試験やシミュレーション手法すら確立しておらず、万が一設計ミスなどで強度や剛性が不十分になってしまった時でも、機体が実際に破壊してしまうまで気付くことはできない
また、翼型についても、XFLR5などの解析結果から性能が良いものを選んではいるが、万が一フィルムやプランクの変形によって性能がガタ落ちしたり、失速特性が凶悪なものに変化していたとしても、本番の結果が出るまでに気付く術はない（結果が出たとしても気づかないかもしれないが）
APの評価
Sの大きさはどれも同じくらいなので、OとSが大きい以下の故障モードのAPが大きくなっている
- 二次構造
- 翼型の失速特性
ここらへんの設計が失敗しがちで要注意というのが胸に刺さる人も多いのではないだろうか
このように、故障モードの一覧とそれに対応するAPの値を示すことで、設計をこれから勉強する人や設計以外の役割の人に対しても、わかりやすく定量的に「外してはいけない設計の勘所」を伝えることができるようになる
つくづくFMEAは引継ぎ資料として有能である
これでSTEP5は完了してので、次のSTEPへと進む
STEP6: Optimization
STEP6では、以下のことを実施する
- Mitigation Actionの設定
- リスクの再評価
STEP5によって、故障モードの一覧とそのリスクの大きさおよびAPが得られたので、APの大きさに従ってリスクを低減させる対策（Mitigation Action）を設定していく
上述のとおり、Sの値はFailure effectに固有であり変わらないものなので、Mitigation ActionはOの値を下げるかDの値を下げるかのどちらかになる
また、APの低いものについてはMitigation Actionの設定の必要はないため、「対策不要」とでもコメントしておけばよい
対策を設定し、担当する人とその期限を決定したら、Mitigation Actionを実行する
Mitigation Actionの実行結果をもってODの値を再評価し、APの値が下がれば対策は完了である
QX-20
例えばQX-20では以下のようになった
今回の例では、APがHighの故障モードのみ対策を設定し、それ以下の故障モードは対策不要とした
このように、APを設定することで、順序立てて対策を検討することができるようになり、限られた時間や人員のリソースを最大限に有効活用することができる
1年間という短い期間の中で設計、製造、試験、運用を行う必要のある鳥人間のような過酷なプロジェクトにおいて、許容できるリスクと許容できないリスクを定量的に識別できるのはかなりアドバンテージになるのではないかと思う
また、引き継ぎのためにDFMEAを実施した場合は、STEP5のRisk Analysisまでを上の代が実施し、STEP6から下の代が引き継ぐというやり方もできる
STEP7: Results Documentation
STEP7では、以下のことを実施する
- DFMEAの結果の文書化
正直これは各チームのチーム運営の方法に大きく依存するので、好きなようにやればいいと思う
もちろんこれまで説明してきたProcess FlowやPFMEAのファイルだけでも十分に素晴らしい資料だと思うが、追加で以下のことくらいはまとめておいてもいいかもしれない
- PFMEAをやった目的/意義
- 対象を選んだ理由
- チームでFMEAをレビューしたときの議事録
- 実際にFMEAをやってみた感想
- 本番の結果を振り返って
以上でVDA FMEAの7つのSTEPは全て完了である
PFEMAの手順
おわりに
ものづくり系サークルに所属する学生のために，自動車業界の国際規格IATF16949をベースとしたVDA FMEA（PFMEA）についての説明を行った
DFMEAのそもそもの目的に「体系化した知識の蓄積」があるので、DFEMAという枠組みは学生モノづくりチームにとても適しているように思う
コメント