先のブログで TRIZ を紹介したので、今回は実例として TRIZ を実際に使用した DfSS（Design for Six Sigma） のグリーンベルト・プロジェクトを紹介したいと思います。先のブログでは新しい利用方法として TRIZ を事務処理の問題解決に使ってみましたが、今回の事例はオーソドックスに技術的問題解決のために TRIZ を使いました。
DfSS のプロジェクトは主に DMADOV フレームワークを使います。TRIZ は A（Analyze）フェーズで、コンセプト・エンジニアリングのツールとして使いました。
以下の事例では技術的な詳細については触れませんが、TRIZ を含め、DfSS で使うツール類がどのように繋がっているのかを中心に説明したいと思います。
プロジェクトの背景
従来客先に納入していた大型モータを制御する装置は、装置を冷却するために水冷システムを使用していました。冷却効率の高い水冷システムを採用することで、制御装置自体は小型化できたのですが、一方で液体の循環装置を外部に設置する必要があったり、またメンテナンスや廃液の処理問題があったり、環境的にも問題がありました。
そこで新たにプロジェクトを開始し、装置の出力容量と大きさは現状を維持しつつ、メンテナンスが不要の空冷システムによる新しいモータ制御装置が開発できるかどうか、検討してみることになりました。
D（Define／定義）フェーズ
Define フェーズでは以下のツールを使いました。
- プロジェクト・チャーター
- VOC（Voice of Customer)／Affinity Diagram
- SIPOC
- Thought Map
- RASCI Matrix
まず、プロジェクト・チャーターを作って、大まかにプロジェクトの概要と、スコープ（プロジェクトの範囲）、日程、コストを把握しました。プロジェクトの始めから詳細な事柄までは分からないので、プロジェクト・チャーターはプロジェクトの進行に応じて詳細な内容を付け加えていくことにしました（但しプロジェクト承認事項は変えられません）。
次に VOC として、関係者から意見や要望、従来製品の問題点などを徹底的に聞き出しました。聞き出した内容は Affinity Diagram を使って、さらに「顧客／関係者が期待するプロジェクトの成果」としてまとめました。
SIPOC はこのプロジェクトの大まかな手順（プロセス）と、主な生成物を簡潔に表現するために使いました。SIPOC は上級管理職や外部の人たちとのコミュニケーションの道具として欠かせないツールだからです。
Thought Map はプロジェクトのためのプログラムのようなものです。Thought Map を使って、どのような問題を解決するために、どのようなツールを、どのような順序で使っていくのか、前もって把握しておきました。なぜならグリーンベルト認定候補者は、まだツール類の繋がり（ツール・チェーン）がよく分かっていないので、Thought Map を作ることで、候補者はこれからやらなければならないこと、つまりプロジェクトの全体像が前もって把握できるからです。
プロジェクトの全体像を把握したあと、RASCI Matrix を使って、プロジェクトの各段階に関わる関係者をすべて洗い出しました。
M（Measure／要求仕様の評価）フェーズ
Measure フェーズでは以下のようなツールを使いました。
- AHP（Analytic Hierarchy Process）
- QFD（レベル１）
AHP を使って、先に VOC／Affinity Diagram でまとめた顧客要求項目それぞれについて、優先順位を付けました。顧客が要求する内容のすべてが等しく重要、というわけでは無いからです。優先順位をつけることで、限られた時間や資源を、より重要な項目に先に割り当てることが可能になります。
顧客要求項目と、AHP で決めた優先順位を QFD に移し、QFD を使ってさらに詳細な技術要求仕様に落とし込みました。QFD を使うことで、技術的な仕様それぞれの項目についても優先順位をつけることができました。
さらに QFD を使えば、技術要求仕様から設計仕様に落とし込むことができるのですが、その前に設計コンセプトを決定する必要が出てきました。そこでさらに QFD を使うのはやめて、まず Analyze フェーズに移り、TRIZ を使ってコンセプトを見つけることにしました。
A（Analyze／分析）フェーズ
Analyze フェーズでは以下のようなツールを使いました。
- TRIZ
- Brainstorming
- Pugh Matrix
- QFD（レベル２）
- CTQツリー
先の Measure フェーズを通じてかなり細かいところまで技術的な仕様を理解したところで、TRIZ を使って設計コンセプトをいくつか洗い出してみました。TRIZ の 39 矛盾パラメータのうち TRIZ ツールに入力した項目は、
- 17: 温度の改善
- 36: 装置の複雑度の改善
です。そして TRIZ ツールから出てきた発明原理は、
- 2: 分離原理
- 16: アバウト原理（少しだけ少なく、少しだけ多く）
- 17: 多次元移行原理
この 3 つの発明原理を基に、チームで Brainstorming を行いました。新しく開発する装置の何を切り離し（分離原理）、どこに何をどれだけ移動させれば良いのか（アバウト原理と多次元移行原理）詳細に検討し、可能性のある代替案（設計コンセプト）をいくつか導き出しました。
次に Pugh Matrix を使って、最も顧客要求を満たすであろう設計コンセプトを代替案の中から選びました。Pugh Matrix は選別のための選択基準が必要です。選択基準は、VOC／Affinity Diagram ですでに洗い出してあったものを使いました。
コンセプトが決まったので、再び QFD を使って技術要求仕様から設計仕様に落とし込み、さらに CTQ（Critical to Quality, Cost, Reliability, etc.,）を見つけ出し、それぞれの CTQ について設計目標値、上限値、下限値等を決定しました。
D/O（Design and Optimize／設計と最適化）フェーズ
Design and Optimize フェーズでは以下のツールを使いました。
- Boundary Diagram
- Cause & Effect Diagram (Fish Bone Diagram)
- Parameter Diagram (P-Diagram)
- Design FMEA
- Thermal Modeling （熱計算のための数値モデル）
- モンテカルロ・シュミレーション
このグリーンベルト・プロジェクトだけで、全ての CTQ について研究することはできないので、AHP や QFD を使って決めた優先順位に基づいて、最も重要な CTQ である温度特性に焦点を当てることにしました。そして Boundary Diagram を使って、装置のどの箇所の温度を調べるのか、研究の対象と範囲を明らかにしました。
もし予想以上の温度上昇があるとすれば、それはどのような現象として現れるのか、どのようなことが原因でその現象が起こりうるのか、Fish Bone Diagram を使って不具合の事象と根本原因を洗い出しました。さらにその不具合の事象（Failure Modes／故障モード）と根本原因（Noise Factors）を P-Diagram に移し、それらの関係付け行いました。
P-Diagram を Design FMEA に変換し、Design FMEA 上で、影響（Severity）や頻度（Occurrence）、検出可能性（Detectability）を検討しました。さらに危険優先指数（RPN: Risk Priority Number）の高い順から対応策を検討し、設計に反映させました。
顧客要求や設計仕様、設計リスク等を理解した後、やっと新しい装置の設計を行いました。
一通り設計が完了した後、その設計に基づいて、熱計算のための数値モデルを作りました。この数値モデルを使ってモンテカルロ・シュミレーションを行い、新しい装置の熱容量が、目標値にどれだけ収まっているか、Z値と PNC（Probability of Non-Compliance）という値を使って確認しました。
TRIZ が導き出した多次元移行原理をヒントに、装置内のコンポーネントの位置を調整し、Z値が最大（PNC値 が最小）となる最適なレイアウトを見つけました。そして最終的な Z値と PNC値から、 新しい装置の設計は熱的に妥当なものであると判断しました。
Verify（確認）フェーズ
Verify フェーズでは以下のツールを使いました。
- 統計分析処理
- 仮説検定
新しい装置はまだ調査のための設計段階なので、実際の装置はありませんでした。そのため「机上の数値モデル（熱計算）が信用できるのか」ということが問題となりました。
そこで現存する比較的類似した製品（装置）を使って、この数値モデルが実際に使えるものかどうか、検討してみました。行ったことは、類似製品を基に同じ方法を使って熱計算・数値モデルを作り、それと実際の測定値を比較するという統計的分析です。
許容できる測定誤差を基に、サンプルサイズの計算をして、その数の類似製品（装置）を用意しました。同じ条件で装置を運転し、温度データを測定しました。そしてその測定データと数値モデルから得た計算値を統計的に比較しました。行った統計的分析は以下の通りです。
- Normality Test
- Capability Analysis
- Equivalent Test
- Two Sample t-Test
- Linearity Test
統計的分析の結果、数値モデルと実際の測定値が違うという十分な証拠は得られず、従って数値モデルは十分実用可能と判断し、その結果を基に新しい装置の設計を進めました。(以上）
結論：DfSS を使うことで、実際に装置を作る前に、顧客要求や設計仕様を満たすことを確認できました。また設計リスクも同時に減らすことができました。もし DfSS を使っていなかったら、きっと装置を作っては不具合を発見し、手直しを繰り返す、ということをしていたと思います。DfSS を使うことでコストを削減し、開発期間を短縮し、また性能や安全性を高めることができました。