QFDを効果的に活用できるシステムに関する

新規受注の商用車用ドラムブレーキの品質保証計画責任者として「ＱＦＤを活用した品質保証計画」を作成したしんきプロジェクト事例をご紹介しますので、参考にしていただければと思います。
１．プロジェクトの背景
イギリスの提携先の新技術をベースにした設計コンセプトが評価され、客先の開発部門が受注を決定したところ、品証部門が、部品納入実績しかない当社にとっての初の組み立て完成品が、製品として機能しない心配があるとの理由で受注反対を主張する中、顧客トップの判断は、「品証担当専務をリーダーとし、各部門の課長もしくは係長10人からなるプロジェクトチームが新製品の品質を監視する」ことを条件に受注するというものでした。
２．提出した品質保証計画の概要
「確実に機能するブレーキ」をトップ事象にしたＱＦＤにより展開した209項目の末端要因と、9種類の保証方法とのマトリックス図の中で、どの末端要因をどの保証方法で保証するのかが分かる図(Ａ３用紙を縦に使って６枚、つなげると2.2ｍ)に表紙をつけたものを提出。
３．客先の反応
各部門から、欲しい資料の見本としてファイル１冊分を事前にもらっていただけに、各部門の責任者の顔には明らかに不満の表情が読み取れ、緊張していたところ、リーダーの専務から「自分はこのような資料が欲しかった。この資料を精査して、このプロジェクトの品質保証計画のベースにするように」との発言があり、提出資料が品質保証計画として受理されたのです。
４．提出した品質保証計画の精査結果
１）客先
追加して提出した資料を品証部門のプロジェクトメンバー以外に配布したところ、過去のクレーム経験から2項目の展開漏れの指摘を受ける
２）社内
筆者が開発経験がないための展開漏れを懸念して、展開要領を説明して開発部門にＱＦＤの作成を依頼したところ、430項目を超える末端要因に展開されたので、最終的にこのＱＦＤを社内に終える品質保証計画のベースとした。
５．効果
１）客先との一体感を持った品質保証計画の遂行
9つの保証方法に、エンドユーザーを念頭に「客先保証」という項目を入れたことを専務が高く評価したことから、品質保証計画の遂行における一体感が生まれ、項目によっては客先が保証を引き受けてくれた。
２）周知を集めた品質保証計画となった
ＱＦＤと９つの保証方法とのマトリックス図により、品質保証計画の見えるかが図られ、結果として、周知を詰めることに成功し、結果として、保証項目の漏れ防止とともに、保証計画の遂行が、目的を理解した的確なものとなった。
３）ＱＦＤの品質保証体系図への組み込み
ＱＦＤは、開発の信頼性向上につながるとともに、雪渓思想を具体的な形で製造部門に伝達することができる点が評価され、品質保証体系図に組み込まれ、全客先の製品の品質保守御計画が対象となった。
４）ＱＦＤ末端要因に対する品質保証体制の漏れ防止
ＱＦＤにより展開された末端要因それぞれに、検査仕様書とＱＣ工程表のナンバーを記入する欄を設けることにより、品質保証体制の漏れを防止するとともに、保証計画の目的が明確となるため、計画遂行が的確になる。
５）開発と製造・品証の一体感を持った品質保証計画の遂行
ＱＦＤが、開発と製造・品証のコミュニケーションツールとして機能したことにより、双方からの具体的提案を交わすなど、一体感を持った品質保証計画の遂行につながり、結果として、高効率で的確な品質保証が可能になった。
６．ＱＦＤ展開要領
上記のような効果を手にするためには次の2点がポイントです。
１）展開は、逐次二項目展開
展開は、互いに独立した二項目への展開を順次行う。3項目や4項目への展開は、展開漏れが分からず、結果的に信頼性が失われるので要注意です。
２）トップ事象は、先ず、展開時干渉しない項目に分ける
トップ事象は複雑なものが多く、一時展開からの逐次二項目展開は出来ないので、先ず、展開時、相互に干渉することの無い項目に分ける必要があります。この事例の場合、９項目に分けてから、それぞれの項目をトップ事象にして、逐次二項目展開に入りました。
７．おわりに
ご質問の趣旨を取り違えているところがあるかもしれませんが、そいった点については、再質問をお受けする形でお答えしたいと思いますので、よろしくお願いいたします。

「QFDの効果を最大に引き上げる術はないか」というご質問に直接お答えするものではないので、お役に立てるかどうかは分かりませんが、私の個人的な意見を書かせていただきます。

ご質問内容から私が理解した積水化学工業様が求めておられるシステム仕様は、

1. データベース化（要求仕様、品質仕様等）
2. 分散利用が可能（各事業所、各担当者）
3. 随時再利用、更新が可能
4. コミュニケーションツールとして利用可能（会議時間や審議の短縮）
5. キーワード検索が可能
6. 追跡機能がある（Traceability）

特に、「誰がいつ、どんな仕様を追加・変更し、その追加・変更した仕様が、他のどの仕様に影響し、その影響を受ける仕様を担当しているのは誰か」、または「どの仕様を検証（テスト）していないか、その未検証の仕様は他のどの仕様に影響するのか」などが管理する、No.6の「追跡機能」がもっとも重要な要求ではないかと想像します。

「最適なツールを最適な時に最適な方法で用いる」という観点から申し上げれば、QFDは上記のシステム仕様を満たさないのではないかと思います。

もし私の理解が正しければ、QFDに代わって、「仕様書管理ソフトウェア」の方が適しているのではないかと思います。

私はIBM Rational DOORSの経験しかありませんが、仕様書管理ソフトウェアとしては定番のシステムです。そして上記のシステム仕様をすべて満たしています。

私がこれまで行ってきたことは、

1. 要求仕様からQFDのレベル階層化を使って設計特性、設計仕様、設計品質などに分解する
2. その階層化されたQFDを参考に、設計特性仕様書、設計仕様書、品質仕様書など、各仕様書をIBM Rational DOORS上に作成する（データベース化）
3. QFDを参考にIBM Rational DOORS上の各仕様書の各項目のリンクを張る（リレーショナル・データベース化による追跡機能）
4. 各仕様書の各項目ごとに担当者を割り当て、他から影響（追加・変更、リンクなど）を受けた場合の通知機能（メールなど）を持たす
5. テスト（検証）仕様書もIBM Rational DOORS上に作り、各テスト項目と仕様項目とのリンクを張り、検証された仕様、未検証の仕様などを抽出できるようにする

などです。QFDは最初に仕様項目を漏れなく抽出するために用いますが、仕様書を一旦作成してしまったあとは、IBM Rational DOORSの強力なデータベース機能、追跡機能を利用しています。

QFDの利点の一つに「優先順位付け機能」があります。IBM Rational DOORSなど仕様書管理ソフトウェアを使った場合、この「優先順位付け機能」はどうなるのか、という疑問を持たれるかもしれませんが、IBM Rational DOORSの場合、リンク数で代用しています。つまり「他の仕様書や他の仕様項目からのリンクが多ければ多い仕様項目ほど、重要な仕様である」と理解するようにしています。

少しでも参考になれば幸いです。

市場にはQFDエディタ（編集ソフトウェア）は数多くありますが、ご要望に沿うようなシステムはなかなか見当たりません。私はQuantum XLをはじめ、いくつかのソフトウェアでQFDを作っているのですが、どれもQFDエディタの域を出ません。

私も質問者様と同様の問題を以前抱えていたことがあります。私の場合はQFDに限らず、FMEAでも同じような問題がありました。つまりQFDやFMEAのファイル数が多くなり、かつネットワーク上や各PC内に分散されていたため、再利用ができなかったというものです。そのため新製品開発の際は一から作り直さなければならない、というような生産性に関わる問題がありました。

幸いにも（?）、私が携わる新製品開発は、新製品といっても、恐らく80%近くは現状の製品または既存技術の再利用で、残り20%がまったく新しい試み、というようなものです。そのためQFDやFMEAの80%も再利用できます。

そこで過去のQFDやFMEAを集めて、マスターQFDやマスターFMEAを作りました（データがすでに入っているテンプレートのようなもの、とお考えください）。これを再利用（修正）することで80%以上は網羅できます。

そして新製品開発の際は、残り20%に当たるNUD要求仕様（NUD: New、Unique、Difficult）に対してだけ、QFDやFMEAを作るようにしています。これを差分QFDとか差分FMEAと呼んでいます。

つまり新製品開発の際は、修正を加えたマスターQFDと差分QFD（修正を加えたマスターFMEAと差分FMEA）をセットで揃えることで、漏れの防止と生産性の向上を図っています。

ソフトウェア・ツールなどを用いず、あまりスマートは方法ではないかもしれませんが、新製品開発の頻度を考えれば、バランスのとれた方法だと私自身は思っています。

以上、参考になれば幸いです。

「マスター作成はどのように取り組まれましたか?」

最初のマスターの作成については、私が旗振り役になって、インターンの学生に手伝ってもらいながら作りました。目的は、

1. 皆を説得する材料として、まずは見本を作ること
2. 時間とコストの削減
3. インターンの教育

などです。また「マスターの更新を重ねることで、徐々に精度を上げていく」という前提があったので、最初のマスターには完璧なものは求めませんでした。それでも十分過ぎるくらいの利用価値はありました。

マスターはネットワーク上に置いてあるので、誰でも簡単に利用可能になっています。欲を言えば、ソフトウェアー開発で使うバージョン管理ソフトを使って、バージョンの分岐や結合なども管理しておけば良かったな、と反省しています。


「それを防ぐためには人依存度を下げたく、そこでIBM Rational DOORSがはまるのでしょうか?」

QFDをお使いになりたいということですので、DOORSは当てはまりません。先の回答で誤解を与えてしまって本当に申し訳ありませんでした。DOORSは文節や段落単位で仕様書等を関連付けることができるテキスト型のリレーショナル・データベースと思ってください。QFDのように使うこともできますが、質問者様の意図するところとは方向が違うように思います。

さらにDOORSもツールの一つなので、人的依存をそれほど下げるとは言えないと思います。


「突出した旗振役が居なくても、基本知識があれば、高い精度で個別運用できる仕組が期待されます。」

高価なソフトウェアやシステムを導入しても、それを上手く運用するためには旗振役（特に最初は）が必要になります。また運用を定着させるためにはルールやそれに従うプロセスが必要になります。

「鶏が先か、卵が先か」という議論になりますが、ソフトウェアやシステムへの投資が無駄にならないためにも、まずはソフトウェア等がなくても運用できる仕組みづくり（プロセス等）から始めることもできます。人に頼った作業になるかもしれませんが、そこからプロセスの問題点が見えてくることも多いのではないでしょうか。その仕組みが定着した後に、さらに生産性を向上させるために、最適なソフトウェア等を導入する方が確実で、かつ投資リスクを低減できる方法かとも思います。

質問者様が自ら旗振り役になることは、御社の中で質問者様のリーダーシップや存在感を積極的にアピールする良い機会になるかもしれません。

まったく新しいプロセス等を導入するときは必ずと言って良いほど、反対勢力の抵抗に会うものです。しかしジョン・コッターの8段階プロセスに従うことで、上手くいく確率が高まります。参考にために記しておきます。

段階1. 危機意識を高める
段階2. 変革推進のための連帯チームを築く
段階3. ビジョンと戦略を生み出す
段階4. 変革のためのビジョンを周知徹底する
段階5. 従業員の自発を促す
段階6. 短期的成果を実現する
段階7. 成果を活かして、さらなる変革を推進する
段階8. 新しい方法を企業文化に定着させる

話は元に戻りますが、マスター（サンプル程度でも可）を作っておくことは、段階2から4において、チームの説得材料になります。そして段階6では、まず質問者様の部署だけで新しい方法を試してみてはいかがでしょうか。そして段階7で他事業所などにも展開し、段階8が過ぎてから、さらなる飛躍のために新しいソフトウェア等を導入するということも考えられます。

少しでも参考になれば幸いです。

個々の事業所や担当者の力量のバラツキがあり、そのすり合わせのための会議時間が不足する状況が問題になっていると思います。
個々の事業所や担当者の役割が決まっていなく、詳細な審議のための効率的な会議の実施手順が行われていないと判断します。また、過去の分析評価が事業所ごとや担当者又は事案ごとの記録にまとめて、活用するために原因の把握をし、継続的の改善の為に評価され、ノウハウの蓄積が起きていたと推測します。

改善のためには、若い人材に期待をしています。若い人材は、必ずしも専門教育を受けているとは思いません。しかし、顧客の要求する品質を理解するコミュニケーションがあり、若い感性で品質特性を明確し、顧客要求事項と組織の狙いの品質項目を特定し、顧客及び組織や製品の品質目標を策定・決定してください。

ＱＣ活動などの各種の改善手順を組織の経験の中から、あるいは外部の知識を用いることを選択・活用すれことがあります。若い担当者が選んだ手順を行い、その実施をする外部知識や内部の経験をサポートすることが必要と思います。

また、顧客要求事項を満たした製品の提供を能力の実証のため、製品実施及び提供の効果的並びに契約内容の確認・評価のためのマネジメントシステムを用いることが可能です。また、有益又は有害な自然的・社会的環境への影響・変化であり、マネジメントシステムの運用効果の向上や、契約事項及び目標の達成のために運用できます。
こうした品質や環境のマネジメントシステム規格の活用も適用できます。

　さらに、「もし高校野球の女子マネージャーがドラッカーの「マネジメント」を読んだら」や、「嫌われる勇気」も活用できるものとなります。若い感性で、熱意をもって改善に富むものであれば、その経験は学ぶものになります。

竹田将文

何処でも、誰でも、抜けなく、設計・開発・研究活動を推進するシステムを推奨するとなると、品質や環境などのＩＳＯマネジメントシステム規格が該当していると思います。多くのＩＳＯ規格が該当していると考えています。
　規模、業種・業態及び性質を問わず、どのような組織にも適用できるように、ＩＳＯマネジメントシステムはよく考えられ、構築・運用が行われていると判断しています。特定の該当企業に似たシステムが構築される可能性はありません。

　基準・ベースとなる企業のシステムを研究し、違いをつくり出すこともできますが、独自のシステムを構築するとき検討項目が多くなり、結局、何も決められない場合があります。
　ＩＳＯマネジメントシステムでも、「規模や業種や業態及び性質を問わず、どのような組織にも適用できるシステム」となり、その時々の対応が必要になります。

　私は、マネジメントシステムを考える時、品質・環境・労働安全のマネジメントシステムを参照しています。また、中小企業診断士としての、経営評価項目を考慮・判断しています。指導現場では即断できないことは多いし、間違いも多く発生しています。
　その時、継続的な改善の中で、経営環境や経営状態は変化をしています。また、顧客企業の要求事項の変化により、指導先の企業の改革が求められることが多くあります。

　どこかのシステムや、経営運営の知識などの経営・研究・設計の会議手順や、文書・記録の管理方法、各種の研修や技術受講などでは、個人の力量が不足することが多くあります。特定の個人の力量でシステムを行おうとするとき、該当担当者を決定するときは難しいと思います。私は、中小企業・零細企業の指導や判断をしていることが多く適任ではありません。

　問題点や、欠点も理解しています。御社の担当者が自ら指導し、社内のメンバーの力でシステム構築を行われていると思います。
担当者又は指導者を決定できない間、システムの改善・運用の停滞は避ける必要になります。当分の間（次善の手）として、共同し集団で行うこと並びに専門家が望ましいと思います。

昔、30年ほど前にソフトウェアが始まった頃、ソフトウェア関係者から言われたことがあります。それは、機械関係者として開発などに専念して頂き、ソフト開発は任せてください。というものです。
　機械・設備・装置の高度化・高速化のため、多くの時間や資源に取り組みことができ、ソフトウェア事業者と共同して、ＩＴ関連の企業と二人三脚で進んで来たと思います。
　
　エンジニアリング・ソリューションは、コンサルティング会社やＩＴ関連会社が主に提案しているものと思います。特定のＩＴ関連企業のシステム名はわかりませんが、関連企業からの複数の提案を受け、改善のための提案を受け止めています。
　また、当該企業からの提案も出てきます。そのため、当該企業の経営の運営や生産や販売又は情報・文書・記録の管理も含めた、統合のシステム構築が必要になっていると判断します。

関連企業だけでなく当該企業と一体として、システム構築が望まれます。関連企業と当該企業の双方に、ニーズだけでなくシーズも必要になります。
　
（企業は、開発担当者の意識改革や検討教育・設計審査などの、それぞれの業務・方法の仕組の改善が行われていると思います。この、「真の仕組改革」は、「組織改革→ﾚﾋﾞｭｰｱ専任=｢専門課｣設立」であり、目標を達成するためのシステムと判断します。また、企業内部・外部に関連する、ソリューションのシステム構築のため、又はニーズ並びにシーズが必要だと思います。）