【製造業の経営】#13：問題解決のフレームワーク 

・m-SHELL分析（人的ミス） 

・FTA（装置など） 

・DMAIC（品質・仕組みの問題） 

製造業で発生する問題の多くは、人的ミス・装置の故障・品質や製造方法などの異常に集約される。私が、35年の製造業で経験したこれらの問題に対して、最も有効だと感じた問題解決のフレームワークを紹介します。 

これら３つのフレームワーク以外にも素晴らしいツールはありますので、参考に本文の後に記載しておきます。 

• m-SHELL分析 

学術的系譜と歴史的背景 

　m-SHELL（エム・シェル）モデルは、人間とシステムを取り巻く多様な要因との相互作用を可視化し、ヒューマンエラーによる事故の発生機序を組織的・構造的に解明するための安全管理フレームワークである。 

1. 1972年にエルウィン・エドワーズ（Elwyn Edwards）が提唱した「SHELモデル」に遡る。 

2. その後、1984年にKLMオランダ航空のフランク・ホーキンス（Frank H. Hawkins）機長が、航空安全の文脈で「SHELLモデル」として発展・発表した。 

3. 日本におけるヒューマンファクター研究の第一人者である河野龍太郎（自治医科大学名誉教授、当時は東京電力所属）は、事故の多くが個人のミスだけに起因するのではなく、背後にある組織の管理体制（マネジメント）の不備に強く影響されている点に着目した。河野は1999年、従来のモデルに組織管理を示す「m（managing / management）」を加えた「m-SHEL（のちにm-SHELL）モデル」を提唱し、医療、鉄道、エネルギーなど、高い安全性が求められる日本の社会インフラ産業に広く普及させた。 

構成要素とシステムの相互作用 

　m-SHELLモデルは、その構成要素の頭文字から名付けられており、当事者である人間（作業者本人）を中心に据え、それを取り巻く5つの要素との「境界（インターフェース）」に潜む不整合を分析する。 

L（Liveware：中心）: 分析の核となる作業者本人を指し、その身体的特性、認知能力、疲労度、心理状態などが評価対象となる。 

S（Software）: 規則、手順、業務マニュアル、運用のための各種情報システムを包含する。 

H（Hardware）: 装置、設備、治具、システムインターフェース、操作盤などの物理的ハードウェアである。 

E（Environment）: 物理的な作業環境（騒音、照度、温度、空間的配置）や、組織を取り巻く社会的状況を指す。 

L（Liveware：周辺）: 同僚、チームメンバー、関係部署の人員など、当事者を取り巻く直接的な人間関係である。 

m（management）: 管理者・監督者の指導、組織の安全管理システム、人員の教育訓練体制、企業文化を表す。 

　河野の設計思想において、管理者を示す「m」のみが小文字で表記されている点は極めて重要である。これは、管理者（m）が前面に強く出すぎて権威的な支配を行うと、作業者（L）の自律的な思考ややる気（モチベーション）が阻害され、かえって現場のパフォーマンス低下やミスの隠蔽を招くという懸念に基づいている。したがって、管理者は目立ちすぎず、作業者を中心に配した他の要素（S、H、E、L）の隙間を埋め、調和的にサポートする立ち位置に徹すべきであるという思想がこの表記に込められている。 

なぜなぜ分析との対比と構造的欠陥の克服 

　産業界で広く用いられている「なぜなぜ分析」は、問題事象に対して「なぜ」を段階的かつ直線的に繰り返すことで原因を明らかにし、具体的な再発防止策を導く優れた手法である。しかし、実務におけるなぜなぜ分析は、使い方を誤ると「個人攻撃（犯人探し）」に変質しやすいという構造的欠陥を抱えている。 

　ミスの発生時に「なぜ、手順を怠ったのか？」「なぜ、もっと注意しなかったのか？」と当事者に問いかけると、分析の矢印は必然的に個人に向けられ、気合や根性、注意喚起といった精神論レベルの表面的対策にとどまりやすい。さらに、個人への責任追及が常態化すると、組織内には自己防衛の文化が根付き、将来的なミスの隠蔽や過小評価が横行する致命的なリスクが生じる。最悪の場合、執拗な個人追及が原因で、スタッフが精神的に追い詰められ、鬱（うつ）の状態に至るなどの深刻なパワハラ問題に発展することすらある。 

　こうしたなぜなぜ分析の限界を克服するために、m-SHELLモデルおよびその運用思想は極めて有効である。m-SHELLでは、「人間は間違えるもの（ヒューマンエラーは不可避）」という前提に立ち、人を責めずに「仕組みや関係性の不備」に焦点を当てる。例えば、作業者が手順を誤った場合、当事者の注意力を問うのではなく、「なぜ手順書（S）の表記が理解しづらかったのか」「なぜ機器の操作画面（H）に誤認を招く配置があったのか」というように、L（人間）と各要素間のインターフェースの隙間を精査する。 

　なお、実務的になぜなぜ分析を行う場合は、問題を起こした本人ではなく、第三者や上司が主体となって実施することが推奨される。本人が分析を行うと、自己防衛のために分析が浅くなったり、重大な精神的プレッシャーを感じたりするためである。上司が主体となり、m-SHELLの視点を取り入れて、個人ではなく「仕組みの不備」にたどり着くまで問いを掘り下げることで、組織的な改善策への昇華が可能となる。 

• FTA 

学術的系譜と歴史的背景 

　FTA（Fault Tree Analysis：故障の木解析）は、システムにおいて発生が好ましくない重大な障害（頂上事象）を起点とし、その原因を論理ゲート（AND・OR）を用いてツリー状に段階的に展開するトップダウン（演繹的）な解析手法である。 

　FTAは1962年、米国ベル研究所のH. A. ワトソン（H. A. Watson）が、ミニットマン大陸間弾道ミサイル（ICBM）の発射管制システムの安全性および信頼性評価のために開発したのが最初である。その後、航空宇宙産業、原子力発電所の安全解析、大規模化学プラントなどの高度安全管理を必要とする分野で急速に発展し、現在では自動車や精密電子機器などの製造業における設計検証の標準的ツールとして定着している。 

　最近では、JAXAのH３ロケットの打ち上げ失敗の調査でも使用されました。 

FTAの作成ステップと運用実務 

　FTAは、一般的に以下の4つのステップに従って関係部署がチームを形成し、合意を形成しながら段階的に作成を進める。 

ステップ1： 

　頂上事象（Top Event）の設定 分析の出発点となる、最も発生してはならない重大な事象（例：「電気自動車の走行中の突然停止」など）を定義する。頂上事象は、「具体性（状態の明確な定義）」、「測定可能性（客観的な判定が可能）」、「スコープの明確さ」の3つの条件を満たさなければならない。 

ステップ2： 

　直接原因の特定と論理ゲートの選択 「なぜその頂上事象が起きるのか？」を問い、直接原因（中間事象）を抽出する。その際、複数の原因が同時に発生しなければ頂上事象に至らない場合は「ANDゲート」、いずれか1つでも発生すれば至る場合は「ORゲート」を用いて接続する。この展開には、製品の設計仕様書、過去のトラブル記録、実験データなどを参照しながら、学際的な議論を行うことが不可欠である。 

ステップ3： 

　中間事象の展開と深度の決定 中間事象に対してさらに下位の要因を抽出し、展開を繰り返す。この展開は、これ以上分解する意味がない、または直接対処・管理が可能な「基本事象」に到達するまで行われる。実用的な展開の深さは、一般に3〜5階層程度が標準とされる。 

ステップ4： 

　基本事象の特定と確率データの入力（任意） 末端の基本事象を特定する。定量的に解析を進める場合は、信頼性データベースや過去の故障率データから各基本事象の発生確率を入力し、全体の発生確率を評価する。 

最小カットセット（ミニマルカットセット）の数学的定義 

　定性的FTAの最大の目的は、どの原因経路が最も重大であるかを特定するために「ミニマルカットセット」を抽出することにある。 

　カットセットとは、集合内のすべての事象が発生した場合に頂上事象を引き起こす事象の組み合わせを指す。そして、ミニマルカットセット（Minimal Cut Set：最小カット集合）とは、頂上事象を発生させるために必要最小限の基本事象から構成される集合であり、その中の基本事象のうち一つでも発生しないものがあれば、頂上事象は発生しない。 

数理モデルと演算 

　基本事象 E_1, E_2, ... E_n がそれぞれ独立していると仮定した場合の、頂上事象 T の発　生確率 P(T) の代表的な論理ゲート計算モデルを以下に示す。 

ORゲート（いずれか一方が発生した場合） 

頂上事象が基本事象のいずれかで引き起こされる場合、発生確率P(Tor) は余事象の確率を用いて算出される。 

ANDゲート（すべてが同時に発生した場合） 

すべての基本事象が同時に発生しなければ頂上事象が引き起こされない多重安全設計の場合、その発生確率P(Tand) は各基本事象の単純積となる。 

　この数学的な解析により、設計者は「どの基本事象の発生確率を下げれば、最も効率的に全体の不具合発生率を抑えられるか」という感度分析を行い、限られたリソースを最適に配分することが可能になる。 

FMEAとFTAの比較：ボトムアップとトップダウンの相補性 

信頼性設計やリスク評価においては、FMEA（Failure Mode and Effects Analysis：故障モード影響解析）とFTAの使い分けが極めて重要である。 

FMEAは、システムを構成する最小単位の部品や個別工程からスタートし、それぞれの故障モードがシステム全体にどのような影響を与えるかを下から順に予測・評価していく「ボトムアップ型」の手法である。製品設計時の潜在的リスク（未知の不具合）の網羅的な洗い出しに強みを発揮し、各故障モードの影響度、発生頻度、検出難易度を点数化して掛け合わせた「リスク優先度（RPN: Risk Priority Number）」を用いて対策順位を決定する。 

これに対し、FTAは、既に発生したか、あるいは絶対に防ぐべき特定の重大トラブルから下位へとブレイクダウンしていく「トップダウン型」の手法である。 

• DMAIC 

学術的系譜と歴史的背景 

　DMAIC（ディーマイク）は、組織の業務プロセスのばらつきを抑制し、品質を極限まで安定させる全社的プロセス改善手法「シックスシグマ」の中核をなす5フェーズのアプローチである。 

　シックスシグマは、1980年代に米国の通信機器メーカーであるモトローラ社（Motorola）のビル・スミスらによって、日本のQC（品質管理）活動や統計的品質管理手法（SQC）をヒントに開発された。その後、1995年にゼネラル・エレクトリック社（GE）の最高経営責任者であったジャック・ウェルチが全社的な経営変革プログラムとしてシックスシグマを採用し、年間数億ドルもの画期的なコスト削減・財務効果を生み出したことで、世界的ムーブメントへと発展した。 

　当初は改善実行プロセスとして「MAIC（Measure、Analyze、Improve、Control）」が提唱されていたが、そもそもどのような課題に取り組むべきかという目的地の明確化が重要視され、のちに「D（Define：定義）」が追加されて現在の「DMAIC」の形となった。1990年代後半には日本にも紹介され、1999年に東芝がGEの手法をベースに独自の「DFSS/DMADV」手法（Define, Focus, Analyze, Create, Evaluateという東芝・スタンフォード大学共同開発のプロセス等）として全社適用したほか、ソニーなど多くの日本の先進製造業でも導入・カスタマイズが行われた。 

DMAICの各フェーズ詳細と実践ツール・財務・運用指標 

　DMAICは、主観や「経験、勘、度胸（KKD）」を排し、すべてデータと統計手法に基づく徹底した検証を通じてプロジェクトを推進する。各フェーズの具体的な実務展開、活用される代表的な分析ツール、および設定される重要指標について解説する。 

1. Define（定義）フェーズ 

　プロジェクトのスコープ（適用範囲）、目標、およびビジネス上の財務・品質目標を明確にするフェーズである。改善の出発点は必ず「顧客の声（VOC: Voice of Customer）」であり、顧客満足度や継続率に致命的な影響を与える重要な品質特性（CTQ: Critical To Quality）を定義する。 

主な実務: プロジェクト憲章（チャーター）の策定、現状の「高レベルプロセスマップ（SIPOC）」の記述、ステークホルダー分析、財務インパクトの予測。 

代表的なツール: SIPOC（Suppliers, Inputs, Process, Outputs, Customers）分析、CTQツリー、バリューストリームマッピング（VSM）。 

設定される指標: 顧客不満足度（VOCデータ）、期待されるROI（投資収益率）、プロジェクト期間。 

2. Measure（測定）フェーズ 

　対象プロセスの現在の実力値（ベースライン）を客観的データとして正確に測定し、収集データの信頼性を担保するフェーズである。 

主な実務: 測定プロファイルの策定、データ収集計画の実行、測定器や人間による判定の誤差・バイアスを評価する「測定システム検証（Gage R&R）」の実施、現在のプロセス実力（シグマレベルおよびプロセス能力指数 C_p, Cpk）の算出。 

代表的なツール: チェックシート、プロセスフロー図、管理図、Gage R&R（ゲージ再現性・繰り返し性分析）。 

設定される指標: 現在の欠陥率（DPMO: 100万機会あたりの欠陥数）、現行プロセスのシグマレベル（例：3.2sigma）。 

3. Analyze（分析）フェーズ 

　測定したデータを多角的に統計解析し、品質のばらつきや不具合を引き起こしている根本的な影響要因（ボトルネック要因 $X$）を特定するフェーズである。 

　主な実務: 欠陥や失敗によって発生している無駄なコスト「COPQ（Cost of Poor Quality：低品質コスト）」の算出と項目別並び替え、ボトルネック工程の特定、統計的仮説検定を用いた「真に結果（Y）に影響を与えている要因（X）」の実証。 

代表的なツール: パレート図、フィッシュボーン図、散布図、相関分析、単・重回帰分析、分散分析（ANOVA）、カイ二乗検定。 

設定される指標: 各要因の寄与率（R^2）、統計的有意確率（p値 < 0.05）、COPQの金額的評価。 

4. Improve（改善）フェーズ 

　分析フェーズで統計的に立証された根本原因（要因 $X$）を排除、最適化するための解決策を策定し、実施するフェーズである。 

主な実務: 実験計画法（DOE）を用いた最適条件（複数パラメータの交互作用）の抽出、リスク低減のためのFMEAの再実施、パイロットプロジェクトの設計と試行導入による解決策の効果確認。 

代表的なツール: 実験計画法（DOE）、タグチメソッド（品質工学）、5S活動、セル生産方式、バリューストリームマップの再設計。 

設定される指標: 改善前後のプロセスタイム（サイクルタイム・リードタイム）削減率、不良品削減率。 

5. Control（管理）フェーズ 

　改善フェーズで達成したパフォーマンスを持続的に維持し、元に戻らないようにプロセス管理（標準化）を行うフェーズである。 

主な実務: 標準作業手順書（SOP）の改訂、プロセス監視用管理図（SPC）の設計、オペレーターに対する教育訓練、異常検知時の自動アラート基準の設定。 

代表的なツール: 統計的プロセス管理（SPC：管理図）、チェックリスト、ポカヨケ（フールプルーフ）設計、監査プラン。 

設定される指標: 改善後のシグマレベル（目標：6sigma、または実質的に不良発生を 3.4DPMO 以下にするレベル）、累積コスト削減額、ROI実績値。 

現代における進化とトレンド 

　デジタル技術の革新に伴い、現代のDMAICプロジェクトは、人間の手による限定的なデータ収集から、AI（人工知能）やデータサイエンスを活用したインテリジェントなアプローチへと進化を遂げている。 センサーデータを活用した「リアルタイム監視と異常の自動アラート」、プロセスマイニング技術による「自動根本原因分析」や「ボトルネックの可視化」、さらには機械学習モデルを用いた「予測品質モデル（製造時に不良発生を予兆検知するシステム）」の構築など、データ駆動型アプローチとしてのDMAICはさらなる効率化と高度化を遂げつつある。 

その他のフレームワーク例 

• なぜなぜ分析（トヨタ方式ではこちら） 

• QC７つ道具 

• 新QC７つ道具 

• FMEA 

• PM分析 

• DMADV (新規設計) 

• 8D（Eight Disciplines） 

• KT法（Kepner-Tregoe Method） 

• TRIZ（トリーズ）（発明問題解決理論 

• デザイン思考（Design Thinking）