最終更新日：2024年2月3日
どうも、おばんです。QCたかです。
「管理図」は使っていますか？
「管理図」は種類が豊富で使い分けが必要です。
その中でも「Xbar-R管理図」が市民権を得ており、多くのヒトが使用している印象です。
でも、「Xbar-R管理図」で満足していますか？
このデジタル時代に、まだそんな旧時代の管理図を使い続けているのですか？
今回は、このようなお話です。
最後まで見て行ってくださいね。
管理図とは
管理図は、「変化」を「折れ線グラフ」で表したものです。
- 昨日と今日で、クラスの体重は変化しているだろうか？
- 1か月後はどうだろうか？
- 変化におかしなところはあるだろうか？
どうでしょうか？
言葉だけでもすんなり入ってきますか？
みなさんがイメージしている通り、ただの折れ線グラフです。
この折れ線グラフで表す管理図は、「変化」の「対象」と「単位」によって、名称が変わります。
【計量値を扱う管理図】
- 体重の変化：X管理図
- クラスの体重の変化：Xbar管理図（Xbarとは、Xの平均という意味）
- クラスの体重の変化量：R管理図
※
計数値は、長さとか、重さとか「連続的（無限）」に変化する数値のことです。
例えば、1mと2mの間には、1.5mとか、1.555mとか、1.55555555ｍとか無数に数字が連なります。
【計数値を扱う管理図】
- ケーキを作り間違えた数：np管理図
- 今日一日で、ケーキを作り間違えた割合：p管理図
※
計数値は、個数とか、年齢とか「離散的（飛び飛び）」に変化する数値のことです。
例えば、サイコロの目は１と２の間はありませんので、飛び飛びの数字になります。
これら多くの管理図で、一番有名なものは「Ｘbar-R管理図」と言ってよいでしょう。
この「Xbar-R管理図」は「Xbar管理図（Xの平均に関する管理図）」と「R管理図（Xの範囲に関する管理図）」をドッキングしたものです。
 |
| Xber-R管理図 |
えっ！？
ドッキング！？
なんで！？
想像するところ「昔はこうした方がよかった」だけです。
今は「する必要がない」のに「教科書がアップデートしないから使っている」だけです。
なお、この管理図は「QC７つ道具」の一つで、かなりのパワーツールです。
「品質管理検定（QC検定）」でもよく出題されるカテゴリ。
教科書通り使用することが、必要となる場面もありますので、注意してくださいね。
管理図 control chart
連続した観測値若しくは群のある統計量の値を、通常は時間順又はサンプル番号順に打点した、上側管理限界線、及び/又は、下側管理限界線をもつ図。打点した値の片方の管理限界方向への傾向の検出をするために、中心線が示される。（Z8101-2）
ークォリティマネジメント用語辞典（2004年 吉澤正 日本規格協会）より引用
XbarとRがドッキングする理由
もう一度、管理図を見てみましょう。
今度はわかりやすくなるように、説明を入れました。
「Xbar-R管理図」は、上段に「Xbar管理図」、下段に「R管理図」を配置したものです。
平均（Xbar）と範囲（R）の変化を同時に見ることができます。
今このデータは、各群（グラフで言えば、横軸の項目でタテの赤四角枠）で、4つの体重データを設定しています。
その群は横軸で30です。
イメージは「毎日、クラスの4人を任意で選んで、体重を量り、1か月間データを並べた」と思ってもらえれば良いですね。
 |
| データの抜粋 |
その4人の平均値の変化を並べたものが「Xbar管理図」、最大値と最小値の差、つまり範囲の変化を並べたものが「R管理図」です。
ただ、これだけでは管理図ではないですね。
このままでは、ただの折れ線グラフです。
管理図の特徴は、ここに「中心線」と「管理限界」が追加されることです。
- 中心線（CL：Control Line）：平均値の平均値
- 管理限界（CL：Control Limit）：超えたくない値
そして管理限界は、中心線（CL）を中心に上下に配置されます。
それを、
- 上限管理限界（UCL：Upper Control Limit）：上側に超えたくない値
- 下限管理限界（LCL：Lower Control Limit）：下側に超えたくない値
と呼びます。
※
R管理図の場合、群のデータ個数により「下限管理限界（LCL）」を設定しない場合があります。
つまり「中心線を中心にし、上下に超えたくない線（管理限界）でサンドイッチする」、
これが管理図のカタチです。
さて、「この管理限界をどのように決めているのか」がキモでして、その算出方法を見ると、ドッキングをせざるを得ない理由がよくわかります。
X管理図の管理限界を求める式は、
今まで「bar」と表現していたものは記号の上に横バーが一本を付けて表現されます。
Xの上には、横バーが2本あります。
平均値（bar）の平均値（bar）なので、2本。「bar-bar」と言います。
式をもう一度見ます。
平均値の平均値（Xbar-bar）は、つまり中心線（Control Line）です。
その中心線に対し「±（プラスマイナス）」で、「A2」ってヤツと「Rbar（Rの平均）」の掛け算があります。
つまり、「A2」と「Rbar（Rの平均）」の掛け算分、中心線（Control Line）」から
- 足したところが、上側の管理限界（UCL）
- 引いたところが、下側の管理限界（LCL）
と、いうことですね。
管理限界を求める式自体は、非常に簡単ですよね。
ここで重要なことが「2つ」あります。
- Rの平均（Rbar）が計算式に含まれること
- ナゾの「A2」の存在とは？
まず「Rの平均（Rbar）」が計算式に含まれていることについてです。
式を見ての通り、「Xbar管理図」を描こうと思ったら、「Rの平均（Rbar）」を求めなければいけません。
そして「Rの平均（Rbar）」を導こうと思ったら、「R管理図」を描くしかありません。
こんな単純な理由から「Xbar管理図」と「R管理図」はドッキングして表現されることになりました。
係数「A2」は必要？？
次に「A2」について、説明していきます。
「A2」は管理図を求めるための「係数」です。
この「係数」は、過去の天才によって計算されており、それは一覧表で示されています。
このような一覧表は、なぜ必要なのでしょうか？
少し、管理図の歴史を紐解いてみましょう。
管理図は、アメリカの統計学者「シューハート」によって1920年代に考案されたものです。
当時、工場での生産は全数検査がほとんどでした。
それは、品質が悪く安定した生産ができないためです。
そこで、工程の変化点をいち早く発見するための手法として考えられたのが、管理図です。
管理図において、重要となる管理限界は、
「Xbar-bar（平均値の平均値）±3×標準偏差」
に基づいています。
これを「3σ（シグマ）法」と呼んでいて、品質管理手法においては、とても大切な考え方です。
標準偏差を計算したことがあるヒトはわかると思いますが、計算の手続きが面倒くさく、時間がかかります。
今でこそ、PCや計算機が発展していますから、標準偏差の計算に何もハードルはありませんが、1920年代頃は、計算にかなりの労力を使っていたと想像できます。
まして、目の前で不適合が頻発している状況で、ちまちま標準偏差なんて計算してられないわけです。
そこでシューハートは、標準偏差を使用しない、係数A2を代用し管理限界を求める方法を考案するに至ったわけです。
しかし、裏を返せば、現代において計算のハードルは何もありませんので、意味不明な「A2」というナゾの係数を使用しなくても、良いのではないか？
このナゾの係数を意味も分からず使用していることは、何とも気持ちが悪くないか？
という想いになります。
とは言え、計算方法を変える勇気もないし。。。
このようなジレンマを感じてしまう気持ちはよくわかります。
ボクもその一人ですが、データを見れば「どう使えばよいか」少しは見えてくるかもしれません。
係数A2と3σ法を比較してみる
下に折れ線グラフを示します。
これは、係数A2を使って、
- 群の数を2個、10個、100個の場合
- 群の大きさをn=2～50まで増やしたときの管理限界の推移
を示しました。
3σ法と比較するため、名前を「係数法」としました。
なお、ベースとなるデータは乱数を用いています。
まず、「群の大きさ」を増やすに従い、管理限界は減っていきます。
そして、「群の数」を増やしても、大きな変化はない、ということが見えます。
このことより、「管理図は、群の大きさで管理限界が大きく変わる」ということがわかります。
n=50を基準にした場合、n=2で約7.5倍、n=3で約5.5倍、n=10でも約2.5倍になります。
これは、群の大きさが小さいときは、管理限界を広くとることで、管理限界から外れるリスクを低減しよう、という思想が反映されています。
どうでしょうか？
群の大きさについての傾向は同じですが、群の数によって「管理限界のバラツキ」は大きくなりますね。
注目すべきところは、「群の数が小さいほど、ばらつきが大きい」ことです。
実は、この3σ法で計算する標準偏差は、群ごとの平均値から算出しています。
例えば「群の数：2」であれば、群の平均値が2つ。その2つの平均値から標準偏差を求めています。
「群の数：100」であれば、100群分の平均値から、標準偏差を求めます。
ですので、群の数が小さければ、計算に使うデータが少ないのですから、標準偏差が大きく暴れてしまうのですね。
ということは、3σ法を使用する場合は「群の数も多くないと管理限界が大きく暴れる」ということになります。
それでは、群の数はいくつ必要なのか？と考えたとき、次のグラフを見てみましょう。
各グラフは、それぞれ群の数を、2、3、4、・・・、10、20、30と変えています。
（上段左から、2、3、4、下段に移りまた左から、5、6、7・・・）
そして、グラフは、横軸に「群の大きさを2～10」、縦軸に「管理限界」を示しています。
青線が「係数法」、オレンジ線が「3σ法」です。
「係数法」は、終始安定していますが、「3σ法」は群の数が小さいとばらつきが大きいです。
ですが、そのばらつきも、「群の数：6」ぐらいから安定してきます。
「群の数：8」以降であれば、10、20、30と一気に増やしても大きな差はありません。
それでは、ここでいったんまとめます。
「係数法」は、各種グラフを見ると、
- 群の大きさ（n）で、管理限界は変わる。大きい方が管理限界は下がる。
- 群の数に影響を受けない
- グラフは、キレイな放物線を描く
これらの確認を行ったことで「係数」がものすごい完成度だということを思い知りました。
本当に天才すぎて神がかっています。
特に、群の大きさ（n）、数が小さい時こそ、有用性が高いと感じます。
当初の設計思想「数が少ないデータで、計算を少なくして、実態を表す」をまさに体現できているツールでした。
ただし、あまりにキレイなグラフになりすぎて、本当に実態を表しているのか、少し疑問にも思います。
「キツネにつままれる」印象は、ボクだけではないはず。
次に「3σ法」についてですが、
- 群の大きさ（n）で、管理限界は変わる（計数法と同じ）
- 群の数が少ないと、ばらつきが大きい。安定させるには、n=8程度が推奨。
- グラフはガタガタになりがち。
このように、「係数法」に比べると、あまりメリットがないように見えますが、ボク的には、このガタガタな感じがよりリアルを感じさせます。
そして、何より計算が非常にカンタンなことです。
標準偏差を求めて、3倍すればよい。
Rbarを求めて、覚えてもいない係数A2を調べて・・・
この2ステップが、絶対的にボトルネックになります。
結局は、集められるデータと管理限界の重要性を天秤にかけ、その場にあった方法を選択することになるのですが、QCたかは「3σ法」をオススメします。
「管理図の最大の弱点」
についてです。
管理図最大の弱点
管理図は、工程の変化を捉えるものでした。
工程の変化から算出する管理限界を設定し、管理限界から超えないように工程をコントロールします。
さて、管理限界は超えてもよいのでしょうか？
例えば、体重制限のあるジェットコースターに乗るとします。
100kg以上はお断り。
遊園地には、体重計がなかったとします。
体重計の代用として、ジェットコースターの入場ゲートの幅を狭くしました。
色々な体格はあるにせよ、だいたい80kg程度のヒトならスムーズに通れます。
ですが、それ以上体重の重たいヒトが通るには、どうも一苦労です。
身体の大きなヒトが現れました。
ゲートを通っています。
しかし、ゲートを通るのに大きなおなかが引っかかって、辛そうにしています。
職員はすかさず声を掛けます。
「体重はいくつですか？」
身体の大きなヒトはしぶしぶ「110kgだ」と答え、残念ながらジェットコースターには乗れませんでした。
この身体の大きなヒトは、一見、95kgかもしれないし、120kgかもしれませんが、職員が声掛けをすることで、100kg以上のヒトが乗ることを未然に阻止できました。
ゲートの幅を狭くしたことが管理限界として機能した事例です。
ですが、これは、絶対超えたくない基準（スペック）100kgが、わかっているからこそ実施できることです。
職員に基準（スペック）が伝わっていなかったら、110kgのヒトに対して
「ゲートを通るのタイヘンですよね！すみません！
でも、ジェットコースター、すっごい楽しいから頑張ってゲート通って！」
と応援してしまいます。
でも、ダメですよね。
規準（スペック）は絶対に超えてはいけないのです。
「管理限界は超えてもいいけど、規準（スペック）は絶対にダメ！！」
この思想が、管理図には盛り込まれておりません。
むしろ、規準（スペック）は、管理図に記載してはならない、と禁止までされている。
規準（スペック）を越えないために、管理限界を設定するのに、その基準（スペック）を同時に監視できないなんて、おかしくないか？ということです。
もしかすると、すでに管理限界すら基準（スペック）から外れていることもあるかもしれない。
「そんなことは、管理図を引く以前の問題だ！」
と、先生方は仰るかもしれないが、ツールを使う末端のボクたちは、当たり前の前提条件を見落としたり、理解できていないことも十分あり得ます。
だからこそ、ツールを準備する側は、理解が浅い末端に配慮した形で提案することが必要です。
「係数法」は少ないサンプル数で、安定した管理限界が算出できるようなユーザーファースト設計なのに、なぜか、一番重要な基準（スペック）に対しては、先生方ファーストになっている。
これを打破するために、今回「Xbar-Cpk管理図」を提案してみようと思います。
何も難しいことはないです。
規準（スペック）と工程能力指数Cpkを盛り込むだけの管理図です。
それではさっそく見てみましょう。
「Xbar-Cpk管理図」の提案！！
まずは、基本の「Xbar管理図」を準備します。
今回も体重のデータを準備しています。
管理図内の上下限管理限界（UCLとLCL）は「3σ法」で算出しています。
次に、規準（スペック）を追加します。
今回は、上側の基準（スペック）を100kg、下側の基準（スペック）を40kgで設定しました。
なお、
- 上側の基準（スペック）：上限基準値（USL：Upper Specification limit）
- 下側の基準（スペック）：下限基準値（LSL：Lower Specification limit）
と呼びます。
赤線を追加しました。
さて、ここから何が言えるでしょうか。
今回「Cpk管理図」と言うからには、「工程能力指数」の概念を盛り込みます。
「工程能力指数」は、規準（スペック）との関係性を指標で表したものです。
工程能力指数は、「0.67」「1.00」「1.33」・・・といった数値で表します。
数値が小さくなると不適合品が発生する確率が高くなり、大きくなると、発生確率が下がってきます。
つまり、工程能力指数は、不適合の発生確率を指標化したもので、工程の安定度合いを代用するものとして活用できます。
不適合の発生確率が下がれば、不適合品の流出も抑えられますので、極端に大きい場合を除き、工程能力指数は「大きい方がよい」と思って差し支えありません。
そして、工程能力指数は、下記の関係性が成り立ちます。
「3σ＝基準（スペック）＝Cpk1.00」
つまり、3σが基準（スペック）と同じ値のとき、Cpkは1.00です。
このときのグラフは、下記です。
次に、管理限界線が、規準（スペック）の外側にいる場合を示します。
この場合のCpkは「1.00」を下回っていますので、規準（スペック）から外れ、不適合率が上がって、不適合品が多く出てしまう状態です。
まとめると、下記です。
このように「Xbar-R管理図」ではできなかった基準（スペック）との比較ができるようになり、工程のばらつきが基準（スペック）に対して大きいのか小さいのかを可視化することができました。
しかし、このままでは基準（スペック）を追加しただけですので、まだ足りません。
Cpkは、一般的に目標値が決められています。
それは、「1.33以上1.67以下」の範囲です。
この範囲に入っていることが、理想的な工程能力指数と言われています。
そこで今回のCpk管理図には「1.50」を理想的な工程能力指数の目安として線を引きます。
線を引いたものを下記します。
※
もう一度、「1.50」の線を引く前の管理図を参考に載せますね。
はい、これが、「Xber-Cpk管理図」です。
- Xberの動きは、今までと変わらず確認できる。
- 管理限界（Xber±3σ）が基準（スペック）に対して、どの位置にいるか分かる。
- 工程能力指数Cpkを「1.50」に設定した位置を示すことで、工程の目標が確認できる。
デメリットは、
- 線が多くなりがちなので、線の説明が必要。
管理図の考え方としては「すでに管理されている工程」に対し、変化が現れないか監視するために用いられることが多いです。
しかし、これから管理を始めるパターンもあるでしょう。
現状を把握するために管理図を使用し、実態を把握することは有用です。
その時に、Xber-R管理図だけを示しても、管理図からは何も読み取れません。
そのためには、今回のような「Xber-Cpk管理図」を用いれば、管理図から読み取れる情報がグン！と多くなります。
手順はカンタン、効果はバツグン！
ぜひ、使ってみてその威力を体感してみてください。
オススメ書籍
リンク
管理図の教科書は、今も昔もコレ1冊です。
教科書の手順通り進めれば、管理図が書けるようになっています。
ソフトウェアが発展し、管理図も自動で書ける時代ですが、自分で悩みながら完成させる管理図は格別に楽しいものです。
デスクに1冊置いてあるだけで、明日からの仕事が変わります。
サイズ感もコンパクトでオススメです。
