第163回： 「統計の実務」23 管理図《その1： 管理図の本質》
◀前の記事へ 次の記事へ▶
≡ はじめに
前回は、「クロス集計とカイ二乗検定《その3： 独立性の検定》」について書きました。
内容は、Rコマンダーを用いてカイ二乗検定をする方法です。
カイ二乗検定は2つのカテゴリ変数が“独立か、それとも、関係性があるか”を有意差検定する手法でした。応用例としてアンケート結果の分析について書きました。
また、
実務では、問題の原因を分析している段階で使うことが多いです。
とも書きました。
さて、今回から、数回に分けて、「管理図」について書こうと思います。管理図そのものは、「管理図を作れ！」と業務指示されて作ることが多いのではないかと思います。自主的に「管理図を描くよ」という人は少ない気がします。
しかし、管理図の根底にある考え方や管理図に含まれるテクニックは、様々なところで応用が効く優れものです。
ということで、今回は管理図の根底にある考え方について、「管理図の本質」と大上段に構えたタイトルで書こうと思います。具体的には、シューハート博士のことと、プロセスの維持管理について書きます。
何故、管理図のnoteを書くかと言えば、今後ますます、その重要性が増すと思うからです。
良い商品やサービスを提供するためには、「作る」ことと「評価する」ことが欠かせません。
テスト技術が「評価する」場面から「作る」場面でも使われることが多くなってきた昨今では、いわゆるバグ出しのテストは不要になりつつあります。
つまり、一部の高信頼性が求められる商品やサービスの開発以外は「評価」（目標の品質に到達したかの確認）だけを行うように変わっていくはずです。
また、Kintoneのように、開発の知識があまりなくても業務アプリを直感的に作成できる、クラウドサービスが増えています。社内のプログラミングが好きな人が社内業務システムを作るようになるでしょう。
そうなったときに“テストの自動化”と“知的なサンプリングテスト”だけで乗り切れるのかというと、それに加えて「上手く、順調に作れているのか」という情報を、作る工程でリアルタイムに開発者にフィードバックする仕組みが必要になると思うのです。
管理図は、直接には役立たないのですが、考え方は使えると思います。だから、noteに書いておきたいなと思いました。
≡ シューハート博士
ウォルター・A・シューハート博士（Walter Andrew Shewhart）をご存じでしょうか？ テスターやQAの方でしたら名前くらいは聞いたことがあるという感じでしょうか。学校の教科書には出てこなかったと思います。1891年生まれで、1967年にお亡くなりになった人です。
世の中にはスーパースターと呼ばれる人たちがいます。例えば、サッカーのことをほとんど知らない私でさえ、クリスティアーノ・ロナウド選手の名前は聞いたことがあります。
顔は思い出せません。←ファンに謝れ！
それで、私のなかでのスーパースターと言えば、シューハート博士（米国人）です。
こんなお顔をされています。
シューハート博士を知らないテスターやQAの方でも、デミング博士（William Edwards Deming）は知っているんじゃないかと思います。
デミングの名は、“JSTQB Advanced Level テストマネージャ”のシラバスの60ページに、「数十年もの間、デミング改善サイクル（Plan、Do、Check、Act）を使用しており、テスト担当者が現在使用中のプロセスを改善する必要があるときは、現在でもこれを使用できる」という文脈で出てきます。
あー、PDCAを「デミング改善サイクル」と呼ぶのは誤解なんだけど、、、まあいいや。
※ デミング博士が日本に伝えたシューハートサイクルと呼ぶべきもの（名前は特になく、シューハート博士が考え出したもの）を日本人がアレンジして作ったものがPDCAです。
それで、シューハート博士はデミング博士の共同研究者、、、というより、シューハート博士が統計の天才研究者で、デミング博士はその教えを広めた天才教育者という関係です。親鸞聖人と蓮如の関係のようなものです。←たとえが分かりにくくて済みません。
あと、言うまでもなく、デミング博士も素晴らしい研究者です。
今回のテーマに関して言えば、「シューハート博士は管理図を考案した人」です。←ここ、テストにでます。（笑）
でもって、管理図の本質（バラツキの考え方）は田口玄一氏に影響を与えたと思っています。シューハート博士がいなかったらタグチメソッドは生まれなかったかもしれません。
シューハート博士は、「統計的品質管理の父」と呼ばれています。
彼の栄誉を記念したシューハートメダル🏅という賞があります。貰えるわけないけど、私もほしい憧れの賞です。（ちなみに日本人でシューハートメダルを受賞したのは石川馨氏（1982年）と田口玄一氏（1995）の2人です。なお、デミング博士は1955年に受賞しています。
ついでに書きますと、デミング博士が日本で講演されたときに、講義録の印税を博士が辞退されたので、それを基金としてデミング賞が創設されました。）
あー、もー、10回分くらいシューハート博士の話を書きたいけど、誰も得しないから日本語の翻訳書を紹介してシューハート博士の話は終わりにします。ただ、60年以上前の本なので、入手は困難と思います。図書館検索もしたけど見つかりませんでした。歴史のある大企業の図書室や大学の図書室に眠っているんじゃないかなあ。
≡ プロセスの維持管理
管理図というと、「キャッチイメージのような折れ線グラフを描けばいいんでしょ？」と簡単に思われる人が多数だと思います。私もそうでした。
でも、管理図の本質と言いますか、管理図で何をしたいのかについて、一度はじっくりと考えることをお勧めします。
私は、管理図でしたいことは「プロセスの維持管理」だと考えています。これだけだと分かりにくいと思いますので少し説明を加えます。
■ システム志向
管理図というと、工場の出荷検査を思い浮かべ、「商品が良品か不良品かについて効率よく調べる方法」と思われがちですが、管理図で管理しているものは、商品ではなくプロセスです。
つまり、商品を調べることで、商品を生み出しているシステム（具体的には、プロセスやリソース）を管理（マネジメント）するためのツールが管理図です。
このようなアプローチを「システム志向」といいます。
例えば、バグの管理でいえば、バグそのものについて議論するのではなく、バグを生み出したシステム（＝プロセスやリソース）について、それが「十分に良いシステム」（バグがほとんどでないよう）になったのかどうかを管理図で分析して、十分に良いシステムになったのちは、新たな悪い変化が起こっていないことを管理図で管理することで「プロセスの維持管理」をおこないます。
■ 標準プロセス
上で「十分に良いシステム」と書きました。十分に良いシステムとは、例えば、ソフトウェア開発であれば、開発したソフトウェアが利用者の問題を解決したり、利用者に喜びや感動をあたえたりするもの、一言でいえば価値ある品質が高いソフトウェアを生み出すシステムがどういうものか分かったということです。
システムは、プロセスとリソースに分解できます。
品質が高いソフトウェアを生み出すシステムとは、分解して考えれば、良い手順（プロセス）と、そのために必要な環境（リソース）のことです。
まずは、このような「十分に良いシステム」を見つけましょう。見つけるためには、本や論文を読んだり、シンポジウムなどで発表を聴いたり、誰かにアドバイスをいただくことが有効です。
自分達でPDCAを何度も繰り返して見つけても良いです。ただし、良いことをしているチームをベンチマーキングする方が早いです。
※ もっとも自分達で何もしていなければ、ベンチマーキングをして、“色々と教えてもらっても何が大切か分からない”ので、ある程度は苦労してからの方が良いですが。
そして、こうすれば良いのか！とわかったら、それを「標準プロセス」として書き留めて実行します。「標準プロセス」には、新人さんが来てもすぐに一緒に仕事ができるようにする効果もあります。
「標準化」については、どちらかというとネガティブな印象を持つ人が多いと思います。でも、「SDCAサイクル」の話で書いた通り、「それを仕組化していなければ、いつの間にか昔のやり方に戻ってしまう」ものなので、「標準化」は大切な活動です。
■ 標準プロセスを見直すタイミング
上に長々と書いた通り、標準プロセスとは、「こうすれば良い」とわかっている方法です。しかしながら、所詮は、これまでの仕事における良い方法（ベストプラクティス）に過ぎません。
したがって、未来永劫、標準プロセスが一番良いやり方であり続けるはずはありません。むしろ、「標準は制定した瞬間から陳腐化が始まる」（by 菅野文友）ことを忘れないようにすべきです。
現場に疎いスタッフはこのことを忘れがちです。
ヘボなスタッフは、書籍や高額なセミナーで入手した激重の全てが詰まったプロセスマニュアルを標準プロセスに制定し、それを何年も現場に守らせたがります。
もしも、そんなスタッフがいたら軽蔑して、「そんなことしかできないスタッフならいらない」と声をあげて猛省をうながしましょう。
環境の変化や技術の進歩によって標準について、その有効性を見直して改訂することが大切ということは、なんとなくお判りいただけたと思います。
具体的にどうやって標準プロセスが有効に機能しているかどうかを管理したらよいのかというと、「その標準プロセスの結果を常にモニタリングして異常を見つけ改善する」といったことをします。
そのためのツールが管理図です。
≡ 管理図の本質
管理図そのものの説明がないうちに、「そのためのツールが管理図」と言われても「はぁ？」って思うのが正常な反応でしょう。
詳細な管理図の描き方と使い方は次回以降にまわしますが、ここでは、管理図を使った方法の概要について説明します。
管理図は、標準プロセスが決まるまでと、標準プロセスを維持管理するためでは使い方が少し違います。
標準プロセスが決まるまでは、プロセスが安定したかどうかを中心にみます。そしてプロセスが安定したら、今度は、安定し続けているかを調べるために管理図を使います。
こちらについては、次々回の重要なテーマの一つとなるはずなので覚えておいてください。
なぜ、そのようなことができるのか？ そこがシューハート博士の研究の成果です。
シューハート博士は、バラつきには、“Chance cause”と“Assignable cause”の2種類があることを発見したのです。
ところで、「Chance cause： 偶然の原因」と「Assignable cause： 特定可能な原因」ではちょっと意味が取りにくいですよね。
そこで、（共同研究者で）教育の天才のデミング博士の登場です。
彼は、この二つを、“Common cause”（共通原因）と“Special cause”（特殊原因）に言い換えました。上手い言い換えと思います。
今日では、共通原因は「偶発的な原因」と呼び、「特殊原因」は「異常事態発生による原因」と呼ぶことが多いですが、分かりやすく変わっただけで、意味はシューハート博士のアイデアと同じです。（シューハート博士の頃は、“Assignable cause”の例として製造機械の故障などがあげられていました）
この2つのバラツキの要因について統計の理論を適用して管理する図が管理図です。
≡ おわりに
今回は、「管理図の本質」の話でした。
バラツキという用語にほのかな統計の香りがしたかもしれませんが、「これも統計なの？」という感想なんじゃないかなと思います。
実は、裏で、統計的にものすごい数式を駆使しているのですが、そのことは一切、表に出てきません。そこが管理図の良い点です。統計の式が出てこないから誰でも使えて、正しく使えばものすごい効果が得られるのです。
管理図は、元々は、地中深く埋めてしまう電話線の信号増幅機の故障を減らすことを目的に作られました。地面を掘り返して修理するのには多くのコストがかかるからです。
まさに“必要は発明の母”ですね。
さて、次回は、「管理図」の2回目として、「管理対象」について丁寧に見ていきます。
管理図には、X-R 管理図、XmR管理図、Me-R管理図、X-Rs管理図、p管理図、np管理図、c管理図、u管理図、、、などたくさんの種類がある理由は何か？ どうしたらよいのか？ について書きたいと思います。
管理図が終われば、残りは「EVM」→「確率分布」となります。
