yono

[!NOTE]

本文はまだ深く学習や考察が行われておらず、将来的には大幅に修正される可能性があります。

複雑なシステムの異常#

重大な製品の故障が発生するたびに、人々の最初の反応は驚くほど一致しています：間違えた人を見つけるか、故障した部品を見つけることです。私たちは明確な「根本原因」を急いで探し求めます。なぜなら、それが私たちに幻想的なコントロール感を与えるからです —— このポイントを修正すれば、すべてが元に戻るように思えるからです。

——中国の宇宙開発でよく言われる「リセット」とは一体何を意味するのか？ - 知乎。

ある場合には、この単純な考え方に間違いはありません。単純さは迅速さを意味します。私は、急いで「根本原因」を特定し、それを解決したと主張することが、顧客の苦情を急いで解決し、現場の作業者を急いで救う場合の解決策であると考えています。私たちはしばしば「問題を解決する」ことで満足感を得たり、自己満足に浸ったりしますが、実際にはこの「解決策」は人の問題を解決しただけであり、全体のシステムの問題ではないことを明確に認識する必要があります。

エネルギーネットワーク、企業、設備、ソフトウェアシステムなど、これらは設計上または実際の意味で複雑であり、誰もがそれらが現在どのように機能しているかを簡単に理解することはできません。実際には、さまざまな小さな問題が満ちており、十分な冗長設計があるため、正常に機能しています。

ある瞬間に、いくつかの小さな問題が突然連携し、予想されたタスクが完了できなくなり、事故が発生します。私たちは事故を解決する必要があり、浅薄な認識に基づいて、見栄えの良くないパッチを当て、問題を発見した人を説得し、問題を解決したと主張します。私はかつて、同級生と一緒に学校の行政主任とやり取りをしたことがあります。その時、私は同級生と一緒に彼女の細かいことに文句を言っていましたが、彼女が言った言葉には非常に哲学的な意味があると思いました ——「燕が過ぎ去ると痕跡が残る、あなたが何をするにも結果がある」。同様に、私たちが急いでパッチを当てることは、全体のシステムにさらに気づきにくい小さな問題をもたらすことになります。

エンジニアリング管理において、人々はしばしば浅薄な「根本原因」を探し求め、真の根本原因を見落とします。なぜなら、実際に作業を行う人は、上の人に「説明」をするために行動しているからです。この説明は通常、特定の人や事に責任を帰属させる必要があり、そうすることで説明が通りやすくなりますが、最終的にはシステム的な根本原因を隠すだけです。

この考え方は、品質管理の第二段階「統計的品質管理段階」の初期に位置しています。¹は「フォードの流れ作業」工業時代の遺産であり、分解と標準化に過度に重点を置いており、強い因果関係を持っています。第一段階「品質検査段階」と比較して、これは確かに方法論の大きな向上です。しかし、現在の時代において、製品、エンジニアリング、社会、組織など、これらのシステムの複雑さは急激に上昇し、多変数、非線形、リアルタイムの変化を形成し、変数間の相互作用がある複雑なシステムとなっています。人間はもはや各プロセスの因果関係を把握することが難しくなっていますが、私たちの思考パターンは依然として原始的で自然に単純で線形な関係を処理する古いパターンに留まっているため、大きな認知のギャップをもたらしています。

システムに目を向ける#

もしあるコーヒーショップの品質が良かったり悪かったりし、ある日顧客から苦情があった場合、管理者の最初の反応は常に「火消し」です。緊急会議を開き、当番の店員を迅速に見つけ出し、彼がコーヒーマシンを適切に調整しなかったと非難し、罰金を科し、消費者に補償します。

これで十分でしょうか？苦情処理は非常に迅速ですが、なぜ同じことが繰り返し起こるのでしょうか？コーヒーショップ全体のシステムにおいて、店員の技術に依存してコーヒーを提供する本質は変わっていません。

私たちの時代には、ほとんどそのようなコーヒーショップは存在しません。考えてみてください、チェーンブランドのコーヒーショップであれば、各店舗の製品の味はほぼ一致しているのではないでしょうか？もちろん、私たちはそのような味が十分に優れていないことを知っています。おそらく、偶然にミスをした店員よりも劣るかもしれません。しかし、これがチェーンコーヒーショップの位置付けです。私はこの品質の製品を生産するだけであり、当然この品質に満足する顧客にのみサービスを提供します。

デミング²はすべての品質問題を二種類に分類しました。

第一の種類は「制御可能な故障」と呼ばれます。これは、あなたのコンピュータが突然ブルースクリーンになったようなものです。これは異常で突然の干渉であり、その原因は明確です —— 操作ミス、ハードウェアの故障、またはドライバのクラッシュかもしれません。このような問題に対しては、すぐに行動を起こし、それを見つけて修正し、再発を防ぐ必要があります。これは火消しのように、即座に実行しなければなりません。

しかし、より一般的で厄介なのは、デミングが「偶発的な故障」と呼ぶ第二の問題です。これは、あなたのコンピュータ全体の動作速度が時々遅くなったり速くなったりするようなものです。これは単一の明確な故障によって引き起こされるものではなく、システムに固有の一部です。おそらく、あなたのオペレーティングシステムが少し重く、バックグラウンドで多くのプログラムが開かれていて、ハードディスクの空き容量が不足している…… 無数の小さなランダムな要因が共同で作用し、全体的で言葉にできない「カクカク感」を引き起こします。これがシステムの「背景ノイズ」であり、常に存在します。

明らかに、店員は人間であるため、コーヒーショップの品質問題は「偶発的な故障」であり、チェーンコーヒーショップの管理者は巧妙にターゲット顧客をダウングレードし、安定したコーヒー豆供給システムを構築し、店員の操作の複雑さを最小限に抑えることで、システムを最適化する手段としています。

デミングが示した道筋は、まず突然の火事である「制御可能な故障」をすべて消し去ることです。科学的にどれが本当の異常信号であるかを判断するための一連の基準を確立し、すべての「制御可能な故障」を排除した後、システムは「安定状態」に入ります。この時点で、問題や変動は依然として存在しますが、これらはすべて正常なノイズです。

この時点で、本当に重要な改善が始まります。その後のすべての問題の根本原因は、もはや特定の人や事ではなく、全体のシステムそのものです。管理者はシステムをより賢明かつ慎重に改善し、思考と改善のプロセスを繰り返し続ける必要があります。

システムが「安定状態」に入ったかどうかを判断する方法#

いくつかの数学的手法や指標は、まだ理解していません。

PDCA と PDSA#

まず、デミングサイクルの概念は、システムの最適化を実現するためにいくつかの段階を繰り返すことです。

PDCA は現在広く認められている「デミングサイクル」です。Plan-Do-Check-Act、計画 - 実行 - 評価 - 改善を指します。デミング本人は、これを提唱したことはないと明言していますが、誤解されている可能性があります。

PDSA は原教旨的な「デミングサイクル」です。Plan-Do-Study-Act、計画 - 実行 - 学習 - 改善を指します。

4 つの段階を繰り返すことで、システムの段階的な向上を実現します。

現代のいわゆる方法論には「大きな環が小さな環を包む」という概念が言及されており、ある段階では形式的に拡張されることもあります。たとえば、C を 4C に拡張する ——Check（チェック）、Communicate（コミュニケーション）、Clean（クリーン）、Control（コントロール）など。しかし、私の見解は、方法論を過度に細分化すべきではなく、細分化の末には方法論が存在しないのと同じです。

私は、環の駆動を過度に強調することは、システムの革新性を抹消することになり、これはシステムのある段階では致命的です。同時に、この方法はシステムの上限を下げ、システムの目を引く突破性や革新性は自然に多くの小さな問題をもたらします。したがって、私はこの品質最適化システムは「安定状態」にのみ適用され、自らを道具として実行するべきだと考えています。

また、デミングは [デミングの新経済観（原書第 2 版） | yono の文書](https://data.yono233.cn/ 书籍 / 戴明的新经济观（原书第 2 版）＝THE NEW ECONOMICS FOR INDUSTRYK,GOVERNMENT,EDUCATION SECOND EDITION_13726844.pdf) の中でも「方法を盲信せず、現地の状況に応じて適応する」という類似の見解を示しています。この本はデミングの最後の著作であり、ダウンロードして読むことを強くお勧めします。この本には、パフォーマンスランキングの無用論、全員がシステムの最適化に努めること、物質的な報酬ではなく尊重をもって従業員を扱うことなど、非常に理想主義的な見解が含まれており、PDCA/PDSA と同様にマスターの思想を理解することが重要です。

また、有名な デミングの 14 の法則 については自分で検索して学ぶことができますが、私たちのような小さな者にはあまり関係ありません。

考察#

私の最大の収穫は、誤りを特定のポイントに帰属させないことです。問題が発生したとき、実際にはシステムの設計に欠陥があるのです。したがって、焦る必要も自己責任を感じる必要もありません。これらはすべて上の人々の問題です。

この記事は Mix Space によって xLog に同期更新されました。原始リンクは https://www.yono233.cn/posts/white/25_6_24_FailSysPDSA