複雑系の異常

重大な製品トラブルが発生するたび、人々の最初の反応は常に驚くほど一致している。ミスをした人、あるいは故障した部品を見つけ出そうとするのだ。私たちは明確な「根本原因」を求めてやまない。それによって、この一点を直せばすべて元に戻るという幻想のコントロール感が得られるからだ。

——中国の宇宙開発でよく言われる「归零（ゼロリセット）」とは、一体どういう意味なのか？ - 知乎。

ある状況では、この単純な考え方にも間違いはない。単純さは迅速さを意味するからだ。クレーム対応を急ぎ、現場の担当者を助け出さなければならない場面では、「根本原因」を素早く特定し、「解決した」と宣言することもひとつの解決策だ。私たちは「問題を解決した」という満足感や得意げな気持ちに浸りがちだが、その「解決策」は人の問題を解決したにすぎず、システム全体の問題を解決したわけではないことを、はっきりと認識すべきだ。

エネルギーネットワーク、企業、設備、ソフトウェアシステムなどは、設計上も、実際の意味でも複雑だ。誰もそれらが現在どう動いているのかを簡単には理解できない。実際にはさまざまな小さな不具合だらけで、ただ十分な冗長設計があるおかげで正常に動いているにすぎない。

そして、ある瞬間、いくつかの小さな不具合が突然手を組み、想定していたタスクを遂行できなくなったとき、事故が発生する。私たちは事故を解決しなければならず、浅い理解に基づいて、見苦しくない程度のパッチを当て、問題を見つけた人を説得して「解決しました」と宣言する。かつて私は同級生と学校の事務長に対応したことがある。当時は同級生と一緒に「あの人は細かいことにうるさい」と悪口を言っていたが、彼女のある言葉はとても哲学的だと思った——「燕が過ぎれば跡が残る。何をしても必ず結果がついてくる」。同じように、私たちが慌てて当てたパッチは、システム全体にさらに多くの気づきにくい小さな不具合をもたらす。

品質管理の実務では、往々にして表面的な「根本原因」を探すことに固執し、本当の根本原因を見落とす。実際に仕事をしている人は、上の人に「説明」をつけなければならないからだ。その説明は通常、責任を特定の人物や物事に負わせるほうが通りやすい。しかしそれは結局、システムレベルの根本原因を覆い隠すだけに終わる。

この考え方は、品質管理の第二段階「統計的品質管理段階」の初期に位置づけられる^{[^质量管理的三个阶段]}。フォードの流れ作業による工業時代の遺産であり、分解と標準化を重視しすぎる傾向があり、因果関係を強く前提としている。第一段階「品質検査段階」と比べれば、方法論として大きな進歩であることは間違いない。しかし現代では、製品、エンジニアリング、社会、組織といったシステムの複雑さが急激に増し、多変数・非線形・リアルタイムに変化し、変数同士が影響し合う複雑系となっている。人間の力ですべての要素間の因果関係を把握するのはもはや難しい。しかし私たちの思考様式は、単純で線形な関係を原始的に、そして自然に処理する古い型に留まったままだ。そこに大きな認知ギャップが生じる。

システムに目を向ける

あるコーヒー店の品質が良くなったり悪くなったりして、ある日クレームが入ったとする。経営者の第一反応はいつも「火消し」だ。緊急会議を開き、担当だった店員をすぐ呼び出し、コーヒーマシンの調整を誤ったと叱り、罰金を科し、顧客に補償する。

これで十分だろうか。クレーム対応は確かに迅速だ。だが、なぜ同じことが繰り返し起こるのか。コーヒー店というシステム全体で見れば、店員の腕前に頼ってコーヒーを出すという本質は、何も変わっていない。

現代では、そんなコーヒー店はほとんどない。考えてみてほしい。チェーン展開しているコーヒー店なら、どこの店でも商品の味がほぼ同じではないか。もちろん、その味は十分に優れているわけではなく、たまに失敗するあの店員の味に劣るかもしれない。だが、それがチェーンコーヒー店の立ち位置だ。チェーン店はただこの品質の製品を提供しているだけで、当然、この品質に満足する客にしかサービスをしない。

デミング^{[^戴明]}は、すべての品質問題を2つに分類した。

最初のタイプは「管理可能な故障」だ。これは、あなたのパソコンが突然ブルースクリーンになり、フリーズするようなものだ。異常で突発的な妨害であり、原因は明確だ——操作ミスかもしれないし、ハードウェアの故障かもしれないし、ドライバのクラッシュかもしれない。こうした問題には、すぐに行動し、見つけ出し、修正し、再発させないようにしなければならない。これは火消しであり、即座に行う必要がある。

しかし、より一般的で、より厄介なのは二つ目のタイプだ。デミングはこれを「偶発的故障」と呼ぶ。これは、パソコン全体の動作速度が速くなったり遅くなったりするようなものに近い。単一の明確な故障が原因ではなく、システムに本来備わっている一部だ。OSが少し肥大化していたり、バックグラウンドでプログラムを起動しすぎていたり、ディスク容量が不足していたり……無数の微小でランダムな要因が重なり合い、この全体的で、うまく言葉にできない「もたつき感」を生んでいる。これがシステムの「バックグラウンドノイズ」であり、常に存在し続ける。

明らかなように、店員は人間である以上、コーヒー店の店員が引き起こす品質問題は「偶発的故障」である。チェーンコーヒー店の経営者は賢くもターゲット客層の水準を引き下げ、安定したコーヒー豆の供給体制を築き、店員の作業の複雑さを最小限に抑えることで、システムを最適化しているのだ。

デミングが示した道筋は、まず突然火が出る「管理可能な故障」をすべて消し止めることだ。後述する基準を確立し、何が本当の異常信号かを科学的に見極める。すべての「管理可能な故障」をなくせば、システムは「安定状態」に入る。その段階でも問題やゆらぎは依然としてあるが、それらはすべて正常なノイズだ。

ここから、本当に重要な改善が始まる。以降のすべての問題の根本原因は、もはや誰か特定の人や出来事ではなく、システムそのものにある。管理者はより賢く、慎重にシステムを改善し、考え、改善するプロセスを繰り返し続けなければならない。

「安定状態」に入ったかどうかの判断

いくつかの数学的手法や指標があるが、まだ理解できていない。

PDCA と PDSA

まず、デミングサイクルの考え方は、いくつかの段階を繰り返すことによってシステムの最適化を図るというものだ。

PDCAは、現在広く支持されている「デミングサイクル」だ。Plan-Do-Check-Act、すなわち計画・実行・評価・改善を指す。ただし、デミング本人はそのようなものを提唱したことは一度もないと明言しており、おそらく誤伝である。

PDSAは、原義的な「デミングサイクル」だ。Plan-Do-Study-Act、すなわち計画・実行・学習・改善を指す。

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

現代のいわゆる方法論には「大きなサイクルの中に小さなサイクルが入る」という概念もあるし、ある段階をもっともらしく拡張したものもある。たとえばCを4Cに拡張して、Check（点検）、Communicate（意思疎通）、Clean（清掃）、Control（制御）とするものだ。しかし私の考えでは、方法論は過度に細分化すべきではない。細分化しつくしたら、結局は方法論がなくなってしまうのと同じだからだ。

私は、サイクルを回すことを過度に重視すると、システムの革新性が損なわれると思う。これはシステムの特定の段階では致命的だ。同時に、この方法はシステムの上限を下げることになる。システムの目覚ましいブレークスルーや革新は、本来、多くの小さな不具合を伴うものだからだ。したがって、この種の品質最適化の手法は「安定状態」にのみ適用し、自分をただの歯車と割り切って実行するのがよいと考える。

一方、デミングは デミングの新経済観（原書第2版） | yonoのファイル という著書の中で、「方法を盲信するのではなく、状況に応じて使う」という趣旨の考えも述べている。この本はデミングの最後の著作であり、ぜひダウンロードして読んでほしい。また、この本には、業績ランキングは無意味だとか、全員でシステムの最適化に取り組むべきだとか、物質的な報酬ではなく尊重によって従業員を報いるべきだとかいった、かなり理想主義的な考え方があるが、PDCA/PDSA と同様、巨匠の思想を汲み取る程度でよい。

また、有名な デミングの14の原則 というものがある。各自で検索して学べばよいが、私たちのような下っ端にはあまり関係がない。

考え

私が最も得たものは、もう間違いを特定の一点のせいにしないことだ。問題が起きたとき、実際にはシステムの設計に穴があったのである。だから、不安になる必要も、自分を責める必要もない。それらはすべて、もっと上の人たちの問題なのだ。