QCストーリー
この記事は、
TEFに投稿したけど無反応で寂しいぴょん
— きょん＠うさみみモード (@kyon_mm) 2017年3月2日
という書き込みを昨晩見かけて、「何を投稿したんだろう？」って思って、Gmailを開いたら「QCストーリー」についての投稿でして、これなら答えられるかもしれないと思って返信したものです。
きょんさんのメールには、
QCストーリーをやっている、やっていた。 という方がいらっしゃれば、参考情報や、QCストーリーでなかなか改善できなかった実情みたいなものを聞けたらうれしいです。
と書かれていました。
そうかー。『QCストーリー』なんて知っているのは、私の世代（1960年代生まれ）までかもしれないし（90年代にQC活動自体が大きく衰退したので）。
それじゃあ、本の紹介でもしようかなと思って軽い気持ちで石川馨の『品質管理入門』を開いたのでした。
確かに『QCストーリー』は載っていました。でも、本に書かれていたのはステップ名だけだったのです。
きょんさんがもとめていらっしゃるのは「実情」です。また、読書家の彼に今更イシカワ本を紹介しても「知ってるよー」と思われるに違いありません。
さて、「どうしよう？」と15秒ほど悩み、『そうだ、コンサルの場で使っているメモ（システム手帳に手書きしたメモ）を紹介するのがいいかも』と思いまして、鞄からシステム手帳を取り出しメモを見ました。
でも、それは、ものすごくいい加減なメモで、使い物にならなかったので書き下ろしました。スマホだったこともあり、誤記もあるので、それらを直しつつ、補足も加えてブログ化したのがこの記事です。
- はじめに知ってほしいこと
- QCストーリーって何？
QCストーリー - Wikipediaにあるように、「問題解決活動、または発表の手順」です。
その「問題改善活動の進め方」がQCストーリーなのですが、Wikipediaにあるとおり「発表の手順」でもあります。
でも、それは表向きの話です。QCサークルという小集団活動がありました（今も細々とありますが往時は全社を挙げての活動でした）。QCサークルでは、身近な職場の問題を自分たちの力で改善するのです。
「発表の手順」、、、違和感を感じてください。往々にして、こういう変な言葉のほうに真実が隠れています。そう。QCストーリーは「発表の手順」なのです。なお、課題解決型QCストーリーなど、いくつか派生型もありますが、ここでは触れません。QCストーリーと言えば問題解決型がほとんどだからです。 - 発表の手順ってどういうこと？
この2つのツイートは、TEFにメールした翌日に私がツイートしたものです。@kyon_mm では何故ストーリーがあるのかというと、QCサークル発表大会や上司への報告の時にわかりやすく、カイゼン活動に問題があったらそれを指摘しやすいからです。
— akiyama924 (@akiyama924) 2017年3月2日
メールに書いた「ポイント」について守られていなかったら「そこは直した方がよい」と言います。ぶっちゃけ上司用です。
要するに「好き勝手な発表をされても講評者（先生）は困るし、講評者から良いコメントも引き出せない」ということです。
だから、『QCストーリー』という定型化された作法に則って改善活動を報告しようと、そういうものです。
- QCストーリーの10ステップ
先の石川馨の本にQCストーリーの10ステップが載っていましたので、それにそって活動すべき内容を説明します。なお、世の中的には10ではなく8ステップが主流と思います。たいして変わらないのですが、気になる人はググってみてください。
- テーマ
テーマ選定を行いテーマ名を「xx におけるyyのzz」という文にまとめます。
ここで、
・ xx はwhereです。改善するスコープ（範囲）、背景、理由です。
・ yyはwhatです。狙い目や改善したいことの管理特性です。
・ zzはyyをどうするのかの、howです。活動目標などです。
例をいくつか書きます。
・ 新サービスにおけるリリース後の不具合の半減
・ コンポーネントテストにおける自動化率の倍増
・ OSSにおける信頼性の測定 - 取り上げた理由・根拠（パレートの原則）
このテーマを選んだ理由をパレート図を描いて説明します。
改善したということは改善前に問題があったわけです。問題は一つに限りません。たくさんあったはずです。多数の問題の中から「何故このテーマ」を選定したのか。
選択したテーマの価値が高いのことについて二・八の法則（パレートの法則）で説明します。 - 現状の把握（事実とその層別）
このステップのポイントは、事実をありのままに表現することです。
この段階でしてはいけないことはデータの加工です。平均値や分散を計算してその値で現状を把握してはなりません。
まずは、素直な目で素データに向かい合い、データの声に耳を傾けます。
具体的には、散布図を描いてバラツキを把握します。
描き方ですが、先に結果系となる縦軸を決めます。（結果系は、テーマのyyなので決まっているようにみえますが、QCストーリーは説明のためのストーリーですので、テーマ名は最後に決まります。この段階では漠然とした問題意識があるだけです）
さて、yy は漠然と感じている問題から持ってくるので簡単そうにみえますが、案外データを取ってみると意外な結果となることが多いものです。
たとえば「テスト時間が長いなあ」と思ってデータを取ると一日3時間しかテストしていなかったり。
良い感じにデータがばらけているyyを見つけたら次は横軸探しです。
横軸は原因にあたります。原因が分からないので困っているわけですから、思いつく原因候補を横軸にとって縦軸は同じにして、何枚も散布図を描きます。
縦軸（結果）を従属変数といい、横軸（原因）を独立変数と呼びます。
独立変数は自由に選べますが、従属変数は自由に選んだ独立変数により決まります。 y = f(x) の関数のyが従属変数、xが独立変数です。
さて、散布図を描いてどうするかというと、層別します。
散布図の中に固まりが見えるものがあればラッキーです。固まりは因果関係がある証拠ですので、原因が見つかったも同然です。
あとは、外れ値を捨てて絞り込みます。 - 結果および工程の解析（要因の追求）
3の後半で実施した散布図を何枚も描いて層別する作業のことです。 - 対策・実施
ここでは、対策の中身もさることながら、改善目標を立ててから対策を実施することが大切です。小集団活動なのだから目標を決めずに果敢にアタックしたほうが良いと言う意見もあります。失敗を許容しようと言う考えです。
ただ、効果確認をするためにも私は目標は立てたほうが良いと思います。無理しなくても達成できるものにして達成感を味わうほうが良いと思うからです。
改善目標は、「何を」、「どれだけ」、「いつまでに」を決める（計画を立てる）ことです。実施は計画に従って進めます。 - 対策の確認
書籍には、「対策の確認」と書いてあるのですが、一般的には「効果の確認」と呼ぶほうが多い思います。
対策をして、効果が出なかったときには因果関係の判断ミスがあったということです。そのときは、3に戻って、横軸探しをやり直します。
特性要因図という図があります。マインドマップと同じようなものです。それらを作って要因候補を見つけます。
簡単ですぐに効果確認出来る場合はすぐに実施すれば良いのですが、そうでない場合は実施が無駄にならないように先に因果関係のありなしを測る予備実験をします。
いわゆる実験計画法を使います。分散分析をして少数の実験で因果関係を確認してからステップ5の実施に戻ると無駄な実施を減らすことが出来ます。 - 標準化(歯止め）、再発防止
PDCA のAct/Actionです。KPTのKと言ってもよいでしょう。上手くいったことを次のプロジェクトや周りのチームでも使えるように、マニュアル（標準書という場合もあります）にまとめます。 - 管理の定着
一般的な論文では、ステップ8以降はありません。
QC ストーリーは結果が良ければ全てよしではなく、仕事のしかたを重視しますのでステップ8以降も大切です。
標準化したものが守られているか？
と言うよりも、きちんと標準化したものが改訂されてみんなが使っているかをみます。 - 反省と残された問題点
改善に終わりはありません。同じ仕事をしているようでも時代が変わりますし技術も進化するからです。だから残課題の整理は重要です。 - 今後の計画
9で残課題の整理ができたらステップ3に戻ってスパイラルアップです。
PDCA を回すってやつです。
QC ストーリーの進め方は以上です。
この結果をA3・1枚にまとめて上司を含め他人に理解してもらうまでがQC活動のワン・ターンです。
