連載記事 飯塚悦功
第23回 問題解決(4)

7. 問題の構造、原因の構造

7.1 構造モデル

(1) 構造

この世には、様々な問題解決法が提案されています。残念なことに、それらの方法や手順を学んだとしても、すぐには真っ当な原因分析・問題解決ができるようになるとは限りません。問題には問題に固有の構造があり、原因にも固有の構造があるからです。一般的な枠組みや構造を知っているだけでは、よほど抽象化能力の高い方、すなわち一般論から具体的な可能性を想定できる能力が高くなければ、個々の問題に対して鋭い分析ができるとは限らないからです。こうしたことから、私は、問題解決とくに原因分析においては、問題や原因に関する「構造モデル」を十分に知っていることが重要と考えています。

先月、(恥を忍んで)私の問題解決手順をご紹介しました。ステップ2の原因構造解明の最後のフレーズで「もうお気づきでしょうが、上述した分析には、仮説、モデルが必要です。問題の起き方、業務システムの不備の類型をある程度知っている必要があります。第5章は、業務システムの不備の類型について、長々と説明しているともいえます」と書きました。問題に直面し、白紙の状態から現状把握をし、因果関係分析をするのではなく、分かっている情報から問題構造・原因構造に関する「仮説モデル」を持ち、それをもとに問題・原因の切り分けを行う方が、迅速・的確な分析ができると思っているからです。

この世のあらゆるものには「構造」があります。断片的でバラバラなものなどありません。システムには構造があります。出来事には構造があります。問題には構造があります。原因には構造があります。

「構造」という表現をしているときにイメージしていることは、「構成要素」と「構成要素間の関係」、すなわち、「どのようなものから構成されているのか?」ということと、「それら構成要素間の、例えば全体と部分、原因と結果、目的と手段というような関係」です。こうした関係を表すものとして、例えば図表1のような、ベン図(集合の包含関係の表現)、系統図(要素の展開・分解の“木”構造での表現)、表形式(多対多の要素間の関係表現)、連関図(バブルと矢印による要素間の関係表現)などがあります。



(2) 問題の構造

例えば、設備停止時間が問題のとき、これをどう理解しますか。私は、まずは、停止時間は、停止件数×1件当たり停止時間と分解できると考えて、以下のように問題を分解してみて、どの要素から攻めるべきか考えます。

・ 停止件数
 ・ 故障しやすい(⇒故障原因の除去、設備改善・強化)
 ・ 故障前の処置が不適切(⇒適時・適切な点検・予防保全)
 ・ 故障時の保守・修理が不適切(⇒正確な修理・保守)
・ 一件あたり停止時間
 ・ 修理開始までの待ち時間
 ・ 修理時間(診断、準備、修理、確認、やり直し)

  例えば、ヒューマンエラーによる事故発生に悩んでいるとき、事故に至る関門のどこで止めるのが合理的かを考えるということができるでしょう(図表2)。



「間接部門の生産性が低い」というような問題があって、いろいろな要因が考えらえるとき、それらの要因間の関係を図示してみて、問題構造の全貌を理解するのも有用かもしれません。もっとも、図表3の事例は架空の例ですので、問題構造の理解のために、このような方法もある、という程度に受けとめておいて下さい。



(3) 構造の一つの表現:木構造

構造の表現にはいろいろありますが、問題の構造、原因の構造を表現するために、「木構造」を選択したいと思います。この記述様式で表現できる構造は、構成要素間の、「全体−部分」、「結果−原因」、「目的−手段」などです。「全体−部分」の例としては、日本の季節は「春」「夏」「秋」「冬」の4つからなります。だから四季というのですね。国によっては、雨期と乾期とか、hot, hotter, hottest(暑い、もっと暑い、猛暑の3つからなるなどと冗談交じりで言う)と認識しているところがあるようです。因果関係、目的手段関係は、結果の原因の原因を展開していくとか、目的達成手段のそのまた達成手段に展開していくことを考えます。

木構造の表現の原則は、「要素はサブ要素から構成される」というものです。したがって、ジャンケンポン的因果関係、すなわち、結果がその原因の原因になっているような因果関係は表現しにくいものとなります。このような制約はありますが、問題の型や原因系の型などの視点で問題の切り分けを行い、それら因果構造の全貌を表現する記述様式としては分かりやすいのではないでしょうか。

カギとなるのは、どう「展開」するかです。全体を俯瞰することができて、かつ思考の焦点を絞って重要なものを見逃すことなく展開したいものです。私は2つの原則を心にとめて展開します。第一は、展開にあたっては「排他和(exclusive OR)」になるようにするということです。すなわち、「展開された下位の要素が排他的」であって重なりがないこと、「展開された下位の要素の総和が上位の要素」となるように展開するということです。人間を展開・分解するときに、例えば、日本人+男性+眼鏡をかけた人、というのは良くないということです。日本人で、男性で、眼鏡をかけている人がいますし、日本人、男性、眼鏡をかけた人の全体が人間の全体にはなりません。例えば、人間は男性+女性+その他からなる、というべきということです。

第二は、展開の「視点」の適切性に留意するということです。問題の型、問題の起こり方、原因の構造に沿った視点で展開したいと思います。いつでもどこでも通用する方法を提示できないので、展開者のセンスに賭けるしかないのが悔しいところです。

例えば、洗浄不良の原因構造の解明に当たって、展開の視点として以下の2つのうちどちらがお好みですか。

・ 洗浄不良(4M視点)
 ・ Machine洗浄設備: 超音波設備、洗浄液補給、流速、搬送、治具、……
 ・ Method洗浄方法: 物理的(超音波)条件、化学的条件、時間、……
 ・ Materialモノ: ワーク(洗浄対象物)、洗浄液、洗浄剤、……
 ・ Man作業者: 性、年齢、経験、技能レベル、……
・ 洗浄不良(洗浄メカニズム視点)
 ・ ワークの汚れの性質・程度: 汚れタイプに適した洗浄原理
 ・ ワークからの汚れの剥離: ワークから分離できているか
 ・ 汚れのトラップ(再付着防止) : 汚れ確保、ワークからの引き離し
 ・ 汚れの回収(洗浄液中の汚れ残存): 汚れを確保した液の回収

これはずいぶん前に、半導体の材料となるシリコンウェハーの洗浄プロセスでの問題解決で、私が実際に遭遇した事例です。特性要因図(Fish born diagram(「魚の骨」)、特性・結果の要因の木構造での表現を描くとき4M(Man、Machine、Material、Method;ひと、設備、モノ、方法)で展開するのが常識と考えられていて、製造工程の不良の要因を、まずはこの4つの視点で列挙し始めるのです。多くの要因を「整理」するにはよいかもしれませんが、やはり問題発生のメカニズムに沿って考えた方がよいと思うのです。

この洗浄は、シリコンの単結晶をスライス(薄切り)したあとで、研磨剤などを、洗浄液のなかで、化学反応を利用して表面をはがし、超音波で叩くという、物理的・化学的な洗浄原理に基づくものです。そうであるなら、ワークの汚れの性質・程度に適した洗浄原理か、ワークから汚れを分離できているか、ワークから引き離した汚れを確保し再付着しないようになっているか、汚れを確保した液を確実に回収し洗浄液中に汚れが残存していないか、などに問題を切り分け、どこが支配的か解明するようにした方がよいと思うのです。

ということで、以降では、問題の因果構造モデル、あるいは問題の原因の切り分けに活用するための仮説を、参考までにいくつか挙げることにします。もちろん、一つのものの見方としてであって、いろいろな切り分け方があると思いますので、あくまでも参考です。

先月、「業務システムの脆弱性分析」について考察しました。そのときの分析の視点は、まさに業務システムあるいはマネジメントシステムの問題のありかの切り分けの例になっていました。概略、以下のような視点を取り上げていました。

業務システムの脆弱性の「因果構造」
 ・ マネジメントシステム: フレームワーク、プロセス、リソース
 ・ プロセスフロー: プロセス連鎖+構造(分岐、反復、……)
 ・ 関係者分析: 関係者、関係の型
 ・ プロセス: インプット、アウトプット、管理、活動、リソース
 ・ PDCA: 目的、手段設計、実施準備、 実施、確認、……
 ・ 管理の原則: プロセス定義、良い仕事、早期発見、的確処置
 ・ 問題成長: 発生、見逃し、対応失敗
 ・ 業務要件: (固有)技術、マネジメント、ひと、組織文化・風土
その他にも、以下のような「切り分け」が示唆されていました
 ・ 品質機能: 企画、設計・開発、製造・サービス提供、調達、検証、販売・サービス
 ・ ヒューマンエラー対策: 排除、制約、軽減、支援、検知、緩和、対応
 ・ 対応策の評価: 効果、経済性、実現可能性、実施の完全性・継続性、副次的効果

7.2 業務システムの脆弱性の因果構造

それでは、業務システムの脆弱性の因果構造について、先月の検討と重複することもあるかと思いますが、さらに展開してみます。

マネジメントシステム
マネジメントシステムのどこかに問題があると思われるときの切り分けの例です。誰に(顧客)、何を(価値)提供すべきであるかは明確にされ、妥当なのでしょうか。それらの価値を提供する仕組みをフレームワーク(プロセス、リソースの運営)、プロセス(価値変換)、リソース(プロセスへの有形無形のリソース提供)で分けてみました。(図表4)



プロセスフロー
次は、上記のマネジメントシステムのうちのプロセスについての問題の切り分けです。一連のプロセスを構成するユニットプロセスの必要十分性と妥当性、それらのプロセスの流れの構造の妥当性、さらに問題が起きやすいと思われる並列プロセスの運用の妥当性を取り上げてみました。(図表5)



関係者
プロセスフローの理解の要素として、「関係者の理解」が重要な場合があります。問題が関係者との関係のあり方に起因することも多いので、それらの問題の切り分けを試みてみました。まずは、考慮すべき関係者の特定が必要です。次に、関係のタイプを挙げてみました。これらが適切に定義され、運用されているかという観点で問題のありかを探ることができるかもしれないと思いました。(図表6)



ユニットプロセス
プロセスフローを構成するある一つのプロセス(ユニットプロセス、単位プロセス)のどこかに問題があるときの切り分けです。まずは、「プロセス」を構成する5つの大きな要素で切り分けて、さらにそれを展開しようとしています。これらの要素が定義され存在しているか、それは妥当か、というような問題のとらえ方をすればよいのではないかと思います。(図表7)



PDCA
PDCAのどこにどのような問題があるかという視点での問題の切り分けも試みてみました。PDCAの各ステップで果たすべき機能を挙げ、それらを適時適切に実施したかという視点で問題の切り分けをしようとしています。(図表8)



管理の原則
私自身がかつて知的業務プロセス管理について考察した結果に基づき、以下のような要件、裏返せば問題の可能性を挙げてみました。先月ご紹介した内容と同じです。これらは数百の設計トラブルの原因の管理的側面を抽出したもので、網羅的ではないでしょうが、効率的・効果的な知的業務プロセス運営のコツのような面が見えているように思います。こうした視点で、プロセスの脆弱性を考察し、改善へのヒントを得るのも一つの方法と思います。(図表9)同様に、問題が発生するのは、そもそも問題が発生し、それが見逃され、対応に失敗して拡大していくと考えて、「トラブルの発生」、「トラブルの見逃し」、「トラブルへの対処の失敗」の3つの因果構造の仮説を考えてみました。



トラブルの発生
トラブルの発生について、上述の「管理の原則」のうちの「質の高い効率的な業務の実施」と同様の展開も考えられますが、ここでは「業務標準」の存在、妥当性、運用の視点での問題の切り分けを試みてみました。矢印(→)は、それが問題のときの対応策の概要です。(図表10)



トラブルの見逃し
「トラブルの見逃し」の展開です。上述の「管理の原則」の「失敗の早期発見」は、実はここに挙げた展開のうちの頻度の多い項目から選んでいます。「項目の抜け」と「評価特性値不適」という類似した側面を挙げたのは、「健康」をチェックしようと思うことと、それを端的に把握する特性値として定めた「体重」「体温」「血圧」などが適切かどうかを切り分けた方がよいかなと思ったからです。「サンプリング誤差」と「測定誤差」が含まれているのは、私の大学での専門が統計解析で、把握したい側面と、得られた事実・データとの乖離が気になっていたからです。(図表11)



トラブルへの対処の失敗
「トラブルへの対処の失敗」も、「管理の原則」のうちの「失敗への迅速・適切な処置」と同じ構造ですが、それより少し詳細に展開してあります。これらは実は、「問題解決の稚拙さ」にほかなりません。(図表12)



業務システムの要件
私は、優れた業務システムの要件として、技術、マネジメント、ひと、文化の4つを挙げていましたが、それに沿って少し展開してみました。業務のパフォーマンスが上がらないなどという問題に遭遇したとき、私はこの構成に沿って切り分けてみます。いや、あらゆる問題事象について、このような構造で問題を切り分けているかもしれません。(図表13)



7.3 問題構造の仮説

問題の因果構造の仮説モデルの検討の続きとして、私がこれまでに遭遇した「問題」に対処したときに頭に描いた仮説をいくつかご紹介します。言うまでもありませんが、これらはあくまでも仮説です。問題の本質をとらえたものであるとよいのですが……。

例:レビューの不備
DRなどのレビューでの指摘漏れの誘因となるレビューの不備に関わる問題のタイプ分けの例です(図表14)。展開の最初が難しいと思います。ここでは、レビューには、レビューされる対象、レビューする者、そしてその間の関係が問題となり得るという切り分けをしています。レビューの準備から実施、フォローのプロセスで何が計画され実施されるかを考えるのも、また別の切り口からなお有効な視点になり得ると思います。



例:設計変更
「設計変更」には仕方のないものもあり、すべてが「問題」とは言えませんが、防げるものもあります。後から何らかの変更を余儀なくされるというのは、やはり問題と言えるだろうと考えて、これをどのような課題と認識し、どのような対応策があるのだろうかとラフに考えたことがあります。図表15に挙げた視点は、そのまま問題・原因の構造とは言えないかもしれませんが、改善の余地について考察するきっかけに使っていました。



例:原価企画
1980年代半ば、工業製品の大衆化が奏功して日本経済が発展し成熟経済社会期になったころ、「原価企画」という用語が普及しました。原価低減ではダメだ、最初から利益を確保できる新製品の企画・開発をしなければならないと言われたのです。赤字で良いからとにかく画期的新製品を開発して、2つ目か3つ目の改良製品で利益を確保するというビジネスモデルが通用しないという認識です。この活動をどう進めるか、いろいろ検討してこんなものだろうかとまとめたのが図表16のような原則です。



例:予防保全の設計
1980〜90年代は、モノづくり企業において、かなり賢い生産設備の管理方法が確立した時期でもあります。壊れる前に壊れないようにしてしまう「予防保全」がもてはやされました。これをどのように合理的に進めるか考察をして、頭に描いていたのが図表17のような視点でした。



例:製品設計不具合
同じころ、日本のモノづくり企業の品質管理の関心は、「企画・開発・設計で品質を作り込め」という点にありました。それ以前の「品質は工程で作り込め」、すなわち最終検査ではなく、製造工程で品質を確保するという原則から、上流プロセスでの管理に軸足を移していたということです。製品設計に問題があって、市場不良が出たり、不良ではないけれど思ったほど売れないというような問題のありかを探るとき、分析の第一歩は、図表18のような、ターゲット顧客像、ニーズの把握、ニーズ実現技術、周到な設計というような枠組みで考えました。



例:信頼関係
様々な関係者間の「信頼」について考察する機会が何回かありました。図表19は、企業(の総務担当)と地域住民との間とか、異なる部門からのメンバーで構成されるチームで発生した信頼感に関わる問題の切り分けの例です。



参考:信頼・信用の条件
社会心理学の分野では、信頼・信用の条件についての研究が進んでいるようで、図表20のような視点を聞いて、なるほどと思いました。まずは、その分野についての専門性の高さがあるそうです。そうだろうな、と思います。意図や魂胆がないことも重要とのことです。魂胆があると思うと、専門性が高ければ高いほど信用しないということですが、これもなるほどと思いました。個別の課題についての意見が異なっていても、価値観(人生観、世界観など)が自分と似ていると感ずると信頼・信用するそうです。これも納得できます。4番目は運命を共有してくれる人を信頼・信用するということです。こんな実験があるそうです。放射能汚染の影響を調査する研究者が、現地から離れた場所で研究を進めようとしても信用しないが、現地に来て研究する計画を立てていると信用するそうです。興味深いのは、始め遠隔地で研究しようと考えていたが、説得されて現地で研究することにした研究者は、相変わらず信用されないとのことでした。このような知見も、問題のありかを探るときに役に立ちそうです。



例:業務負荷
働き方改革が叫ばれていますが、業務負荷が高いという問題のありかを探るという課題の相談に乗ったこともあります。(図表21)



例:リソース不足(需給ギャップ)
前項と類似していますが、リソース不足の問題の切り分けです。このときは、業務に使用するコンピュータや高度なアプリケーションソフトウェアの不足が問題となったときに、問題の性格を明確にするため、図表22のような切り分けをしてみました。



例:作業現場の安全
製造現場の安全は重要であると強調されてはいますが、いまもって事故(赤チン障害と言われるような小さな事故も含みます)は根絶できていません。図表23は、どこに作業現場の安全設計の不備があるのかを少しでも体系的に検討するための、問題の切り分けの例です。



例:安全の実現
医療プロセスに潜む、患者安全を脅かす可能性を特定し、プロセスの設計と管理計画の段階で対応策を考えておくための検討の枠組みのようなものを考えました(図表24)。少し抽象レベルが高すぎて適用が難しいかもしれませんが、私は医療安全へのアプローチの体系を整理できたような気がしました。



例:不安全行動の抑止(交通事故の防止)
安全担当にとって頭が痛いのが従業員の交通安全です。社外で起きますし、厳重な管理下に置くこともできず、対応に苦慮しています。私は、図表25のような構造で問題のありかを探ります。



例:事故・不祥事等へのリスク対応
事故や不祥事を起こした後の対応の稚拙さで、小さな問題もとてつもなく大きな問題になりかねません。多くの会社の失敗例を分析して、図表26のような問題の切り分けを考えたことがあります。



例:QMS設計
QMS、あるいは一般にMS(マネジメントシステム)の設計・構築において留意しておかなければならない事項を整理して、システム設計に不備、不足があるとはどういうことかを考察するときの思考の枠組みに使っています(図表27)。



例:プロセス改善
ある業務機能、あるいはプロセスに問題があると感じたとき、図表28のような問題の切り分けをしています。当然のことながら、これは先月(恥ずかしながら)最後に示した「私の問題解決法」に類似のものとなります。



さて、凝りもせずに長々と続けてきましたが、この連載も来月で中締めということにしたいと思います。主題は、総括、まとめの意味も込めて「持続的成功のための真・品質経営」といたします。

問題

[1] 原因分析をし、それに基づいて対応策を導いた、業務システムの改善事例を参考にして、その種の問題や原因について、想定しうる構造を、7.3節にならって表現してみて下さい。

[2] ISO 9001やISO 14001などのマネジメントシステム認証、あるいは内部監査で指摘された不適合事象について、不適合の原因のいくつかを取り上げて、その種の問題構造、因果構造の仮説モデルを表現してみて下さい。

[3] 「不適合・不良などの不具合の再発」、「コミュニケーション・ギャップ」、「重要メールの誤送信」について、想定しうる問題発生構造の仮説モデルを作成してみて下さい。