Qiita Teams that are logged in
You are not logged in to any team

Log in to Qiita Team
Community
OrganizationAdvent CalendarQiitadon (β)
Service
Qiita JobsQiita ZineQiita Blog
161
Help us understand the problem. What is going on with this article?
@kaizen_nagoya

プログラマにも読んでほしい「QC検定にも役立つ!QCべからず集」

QC検定にも役立つ! QCべからず集

すごく内容がよい。
プログラマの方にも読んで欲しいと思い、筆をとりました。

入手が困難そうで、復刊.comに登録しました。
https://www.fukkan.com/fk/VoteDetail?no=71164

清き一票をお願いします。

公共図書館で、国会図書館以外で所蔵しているのは、
山口県立、岡山県立、大阪市、滋賀県守山市、金沢市、
名古屋市、安城市、豊橋市、横浜市、品川区。

おお、愛知県だけ3箇所にある。

カーリル(都道府県を順に探した)
https://calil.jp/local/search?csid=aichi&q=QCべからず集

べからず集だと積極的になれないかもしれない方のために、
べからずを、前向きに変換した記述を作成してみようかと努力中。

確率と統計という概念をすべての事象に適用し、
ありとあらゆる科学分野を、確率と統計に基づいて理解する。
あるいは、あるとあらゆる活動を記録し、統計として、確率を予測して行動する。負帰還(feedback)だけでなく正帰還(feedworward)でもよいかもしれない。

言語と数値のデータをうまく組み合わせるものが
経験と勘として人間の知能に蓄積していく。
プログラミングしたり、計算機の機械学習として体系化していけるはずだ。プログラマが統計的 品質管理(QC:quality control)の最先端に立てることを自覚したい。

プログラマがQC検定を受けることの意味・価値・課題
https://qiita.com/kaizen_nagoya/items/b03216eb6ab09eacc957

プログラマ以外の方にもわかるような四分類を付与し、逆も真である可能性を一覧に示した記事はこちら。

「QC検定にも役立つ!QCべからず集」四分類と逆が真な事例
https://qiita.com/kaizen_nagoya/items/fb920fedc445e7fd1eb8

背景

QC検定1級では筆記試験がある。

解答を作成するためには、自分の見解だけでなく、社会的に認知度が高い見解との比較で記述するとよい。

参考にするとよい書籍を探していて、この本に出会った。

QC検定は製造業が対象である。
採点者にプログラマはいないかもしれない。
そこで1級の問題のプログラマの回答案を作ってみた。

プログラマがQC検定を受けることの意味・価値・課題
https://qiita.com/kaizen_nagoya/items/b03216eb6ab09eacc957

8.5.3 カンや経験を活用せずにデータ解析をするべからず

カンや経験は、人間が生物的にまたは精神的に統計処理した結果です。
経験や勘が、機械学習の結果を判定するのにとても役立ちます。
データ解析に、既知の統計処理を生かすのが人間の仕事ですし、
機械学習で役立つことですね。

KKD(経験と勘と度胸)は、一見、主観的な事実に思えるかもしれません。実は、確率・統計の成果で、他の主観的な事実と付き合わせてみると、経験と勘と度胸が深ければ深いほど、客観性が高くなるという、同じ方向性ということが分かるかもしれません。

Aさんの経験と勘と度胸、Bさんの経験と勘と度胸、

経験と度胸と感が分布と確率に裏打ち可能な証拠能力が一番高いという仮説。
https://qiita.com/kaizen_nagoya/items/f5ec32472774d17e46ec

4.1.2 データの素性をおろそかにするべからず

いつ、どこで、誰が、どんな方法でデータをとったのか履歴を残すことはデータ収集の基本です。測定方法が、対象に影響を与える方法を取ったかどうかは大事です。「統計の嘘」の始まりになるかもしれません。

測定機器の型番号、備品番号などが書いてあるとよい。校正日時などは追跡できるのであれば、必ずしも必須ではないかもしれません。
録画したのか、録音したのかの記載があれば、それらの生データも活用するとよいかもしれません。

物理科学のデータなのか、生命科学のデータなのか、社会科学のデータなのかで、扱う統計、確率の技法が違うかも。

仮説・検証(93) 科学三分類・四分類・五分類と算譜(program)
https://qiita.com/kaizen_nagoya/items/a2f2b9cc3a51b6af7603

1.1.5 データをとらずに理屈だけで問題解決するべからず

プログラミング、ソフトウェア利用では、必ずデータを取る仕組みを組み込むことが可能です。データを取らずに、問題解決することはありえません。

論理的な理屈は、なにか魅力的に感じる方もおみえになるかもしれません。
論理体系が正しいことを保証することができない以上、品質保証に論理を持ち込む必要がないのかもしれません。

1.1.4 目的・目標をはっきりさせずに仕事をするべからず

自動車用のソフトウェアは、ホンダ自動車の排ガス規制を電子制御で達成したことが大きな転換点でした。しかし、自動車安全の方が、排ガス規制達成より大事だということをはっきりさせずに仕事をしていると、安全なシステムになりません。その2つの機能に邪魔をしないような、物理的に調停する通信規約がCAN(controller area network)です。そして、排ガス規制のための電子角速度制御の邪魔をせずに、かつ、CAN通信を円滑にする仕組みがOSEKという自動車用のOSです。

エンジン・電動機(motor)制御と、CAN、OSEKのすべてを自動生成で達成しようというのがAUTOSARの目指しているところのはずです。
これらの、目的・目標をはっきりさせずに仕事をすると、あとになって性能が出ないソフトウェアで悩むことになるかもしれません。

1.1.2 顧客は勝手なことを言うと思うべからず。

顧客は勝手なことを言ってもいいのです。「買って」くれてれば。
言われた、勝手なことを、いかに新製品に生かすかが設計者の腕です。

プログラムも一緒。
オープンソースがなぜ発展してきたかというと、
多くのプログラマが勝手なことをいい、
ありとあらゆる方向の可能性を書いて試してみて、
それに対して、また顧客が勝手なことを言ってくれるから良くなってきたのですから。

4.3.1 まったくランダムにサンプルを採取しなければならないと思うべからず

自分が無作為(random)だと思っていても、特定の傾向を持っている場合もしばしば。ありとあらゆる観測項目に対して無作為ということは不可能だと思った方がましかもしれません。

たくさんの測定機器のどれを使うかを無作為に決めるのは不可能かもしれません。

むしろ、何に偏りがある可能性があるかを記載するとよい。

測定機器の種類、測定時間、やり直し回数など、いつ、どこで、誰の役にたつかわかりません。

4.3.7 サンプルが多ければ良いと思うべからず

全数検査でなければ、多いことが価値になるとは限りません。

工場で自動化して全数検査できるのに、抜き取り検査している場合に出くわすことがあります。抜き取り(sampling)する手間より全数検査の手間の方が少なくできないかを考えて見てください。

8.8.3 決めた標準に固執するべからず

標準は、ある条件でのあるやり方を示すものだと理解していれば、
条件が変われば、やり方も変えるものだとわかります。

現地現物を見ていれば、標準に固執する人っているんでしょうか。

いるから困っている人がいるんですね。

8.6.2 対策には排反事象(副作用)を忘れるべからず

対策に限らず、測定も同じです。

測定には副作用が生じます。

量子の測定で、位置とエネルギーを特定できないことはご存知ですね。

測定行為が、測定対象を変えるのは、人間も同じです。

何かを測ることが、行動を変えているのだから、よい行動をしやすいように測定に労力がいるのは、改悪になるかもという配慮があるといいですね。

仮説・検証(67)「プロセス改善」が改悪へと突き進む
https://qiita.com/kaizen_nagoya/items/0f3a1174f81935bb6d85

1.1.1 品質第一はコストアップにつながると思うべからず

と関係があるかも。

5.3.1 データが取れないとあきらめるべからず

データというと、客観的でないといけないという思い込みがないですか。
主観的な記録でも、統計的にすごく意味があることがあります。

人間が使ったり、利用したりするものであれば、利用者は主観的です。
主観的なデータを取ったら怒られるとしたら、その怒っている人が主観的なだけだと思ってください。

どんな客観的なデータも、すべて主観的なデータの立場の違いだけだと気がつくかもしれません。客観的という立場の一つは、主観的かもしれません。ありとあらゆる立場を同時に満たすことはできないのかもしれないのですから。

2.1.1 会社方針だからといって上司の指示事項だけを実施するべからず。

よくいますよね。上の言うことだけ聞いて、下に押し付けてくる人。
会社の3%くらいまでなら必要な人材だと思います。10%を超えたら、その組織は危険だと思ってくださると幸いです。

2.2.6 リーダの言うことのみに従うメンバになるべからず

も同じ文脈ですね。

2.2.3 同じ考え方の人だけで活動するべからず

昔は、「煙草部屋の弊害」と言っていたらしいですね。
考え方だけでなく、同じ行動をとる人だけで議論していては、どんどん狭くなっていくことに気がつきません。

麻雀とか、ゴルフでもそうかもしれません。
同じ数人だけで行動していては、発想がどんどん狭くなってしまいます。

HAZOPという分析手法では、一定時間ごとに人を入れ替える方法を採用するように勧めています。

仮説・検証(187)効率的なHAZOPの進め方
https://qiita.com/kaizen_nagoya/items/2b8eae196945b7976446

5.5.3 飛び離れたプロットを無視するべからず

飛び離れた値は、平均を計算するときに除外することがあります。
誤差の大きい測定の場合に、しばしば取る可能性がある処理です。

しかし、無条件に除外していいわけではありません。
飛び離れている理由を調べるか、除外する根拠が思い当たるのならいいかもしれません。

異常な点が、再現する可能性があるのかどうか。
逆手にとって、何かの解決に役立たないか。

いろいろな取り組みが可能かもしれません。

たかたか分析
https://qiita.com/kaizen_nagoya/items/1c848e8c71edb34c2f3f

6.7.1 想定外の事態発生はあきらめるしかないと思うべからず

想定外を洗い出すのがHAZOP手法。

ちょけねこ たんじょうびのおくりもの https://qiita.com/kaizen_nagoya/items/fc9675686c229f7a155e

2.2.9 解決が見えている問題をQCストーリーで取り組むべからず

改善方法がわかっている問題も同じかも。

効率的なやり方がわかっていたら、そのまま突き進めばよい。

わざわざ別の書式に書き込むのが無駄だと気がつくとよい。

集計するための仕組みに載せる方法はいくらでもあるはず。

3.1.1 ねらいの品質とできばえの品質を混同するべからず

ねらいの品質は設計品質。
できばえの品質は製造品質。

最近まで「ねらい」、「できばえ」の言葉を使っていませんでした。

プログラムは初めからできばえをねらって書きます。
動く設計書。ねらいとできばえは一体化していて、同じものの場合は、混同ではなく、同一。
プログラマがプログラマのために書くプログラムは、検証と妥当性確認が一体なのと一緒かも。

小学校では、「ねらい」と「めあて」という言葉を使い分けてるらしい。

狙い通り
https://researchmap.jp/blogs/blog_entries/view/98149/85bf5fecbbae6c12050eccfbc125a8a2?frame_id=403660

4.6.1 パソコンにデータ入力をしても生データは廃棄するべからず

計算機が設置していないところで得たデータには、染みや、垢や、訂正したりした記録があるかもしれない。計数値にして、捨ててしまうのはもったいないという趣旨は理解できる。

しかし、今時、生データは直接画像で保存するので、破棄しない。
また、パソコンで生データを収集することが大事。
一次情報を直接コンピュータに入れるのではなく、計算機と別の場所でデータを作ってからコンピュータに入れるのは、計測として失格。

カメラにしろ、マイクにしろ、センサにしろ、直接生データをコンピュータに入れるのだから、生データはコンピュータの中で生きている。

4.6.2 統計量、統計解析の計算に時間を費やすべからず

Data Robotというソフトをご存知だろうか。
統計解析の数十の手法を同時に計算し、比較して、役に立ちそうな計算を示すソフト。
現代制御理論に基づいて制御していたのより、よいパラメータを提示して改善に役立ったという事例を聞いたことがある。

今時、統計解析の計算に時間を費やす人はいない。
35年前、下記プログラムを評価するために四倍精度で計算しようとして3日たった時点で進捗を見たら、3年かかることがわかった。同じ計算を、今のパソコンは1日で計算可能。10分、1時間、1日とか、時間を区切って計算するのは、プログラマなら当たり前のこと。

半分の時間にする処理系やハードウェアを探すのも仕事のうちだし。

連立微分方程式のPade近似解法 Fortran手による最適化とコンパイラの最適化、誤差の評価
https://qiita.com/kaizen_nagoya/items/c55d29f0d7e9ebd07a31

5.3.2 計測器などで得られるもののみをデータと思うべからず

逆も真ですね。人が書き込んだものをデータだと思う人がいます。
人手が要るようなものをデータと思わないようにすることも大切です。

5.3.1 データが取れないとあきらめるべからず
と関連していますね。計測器で取れない主観的なデータも役立ちますし、
主観的なデータを計測器によるデータと関連性を探すことも大事ですね。

5.4.1 生データばかり眺めるな

逆も真ですね。

生データを見ずに、統計データばかり眺めていては、大事なことを見落とすことがよくあります。最低でも1割の時間は生データを眺めてみてください。できている統計に抜け漏れがすくみつかるようならデータサイエンティストとして一人前かも。

生データ見たら、処理したい方法がつぎつぎ思い当たります。生データばかり眺めることはありえません。生データをながめながら、つぎつぎ統計処理をうごかしていくので、人間はずっと生データを見続けるかもしれません。生データ10分ながめて統計処理を思いつかなければ、統計と確率の勉強をし直すか、データ処理の訓練を受けてみてはいかがでしょうか。

確率論及統計論輪講 精度より成果
https://www.slideshare.net/kaizenjapan/ss-70572076

6.1.1 一件の言語データは簡単な単語で表現するべからず

簡単な単語にしたら、その時点で情報量が大幅に減ってしまうかもしれません。

できるだけ具体的に素直に表現することが重要です。

日報、週報の書き方も同様ですね。日報、週報がついた月報で、簡素な言語に変換することは意味があります。元データのない要約は危険だと思うようになればもうけもの。

7.1.1. プロセスと業務は異なると考えるべからず

逆も真かもです。
プロセスと業務は同じと考えても、異なると考えてもどちらでもかまわないのです。

二つの視点で捉えれば、異なるという仮説をたてて測定すればよく、
同じだと捉えれば、同じという仮説をたてて測定すればよい。

同じか、異なるかはどちらでもよく、品質を改善できれる方法が見つかればいいだけです。

8.2.7 いつまでも簡単な問題に取り組むべからず

改善は、最初は簡単な問題を解決して、はずみをつけるのが定石。
しかし、簡単な問題だけを取り組んでいたら競争相手に、いつか抜かされる。

ごめんなさい。私のことです。

8.5.1 「なぜなぜ分析」をせずに原因究明するべからず

逆も真かも。「なぜなぜ分析」をしたら原因究明できると思うべからず。

原因はわからなくても対策を立てなくてはならないことはたくさんある。
原因を探ることに熱心で、対策がありきたりでは意味がない。

原因追求より対策探求が大事かも。

たかたか分析
https://qiita.com/kaizen_nagoya/items/1c848e8c71edb34c2f3f

HAZOPという空間と時間の質と量、上限と下限という8方向を検討する道具があります。
HAZOPを使ったら、原因究明したと思うのも危険です。
対象の本質に迫らない分析はいくらでもできるからです。

HAZOPは、TRIZと組み合わせることにより、対策探求にも役立ちます。

「ワークショップ「ソフトウェア開発におけるHAZOP入門」の結果」の分類
https://qiita.com/kaizen_nagoya/items/e62e91cb019c6275d6c1

8.5.5 要因解析は特性要因図づくりに終始するべからず

改善も一緒ですね。改善が、改善書類づくりに終始する人っていますよね。

目的と手段が逆転する人たち。

上から言われれば、やむをえないこともあります。
顧客から言われれば、やらざるをえないこともあります。
それらが半分の時間を超えたら、日報か、週報か、月報で警告を出してみましょう。

仮説・検証(73)プログラマの「日報、週報、月報、年報」考
https://qiita.com/kaizen_nagoya/items/97ad8ac9217c12c3bb69

1.1.1 品質第一はコストアップにつながると思うべからず

品質を良くすることによって、無駄をなくし、費用削減につながることがあることを紹介しています。

いつでも、費用が増加するとか、いつでも費用削減になるとかという発想は、統計的ではないし、確率論に基づいていません。

費用が増加する方法にはどういう方法があるか、
費用を削減する方法にはどういう方法があるか、
両方を考えてみればよいかもしれません。

プログラムを自分で組めば、すごく安く自動化できるかもしれません。だいたい、業者に見積もりを取った時の10分の1から100分の1が内製費用というのが目安でしょう。

なぜかっていうと、作るべきものの中身の分析は済んでいて、仕様も明確になっていて、あとはプログラミング言語で記述するか、仕様記述言語で記述すれば、すぐに動くものが作れる可能性があるからかもしれません。

発注するほど費用を見込めない場合は、内製することを検討してみてはいかがでしょうか。

p.s.
システムの設計の際に、有効な道具にHAZOPというものがあるかもです。

目次

本の内容に対する優先順位を「見出し」という項目に書きました。

Qiita記事の優先順位はアンケートを現在作成中。今しばらくお待ちください。

見出し優先順位 見出し 見出し優先順位 Qiita記事 偏差 偏差自乗
1 8.5.3 カンや経験を活用せずにデータ解析をするべからず 7 -6 36
2 4.1.2 データの素性をおろそかにするべからず 4 -2 4
3 1.1.5 データをとらずに理屈だけで問題解決するべからず 3 0 0
4 1.1.4 目的・目標をはっきりさせずに仕事をするべからず 2 2 4
5 1.1.2 顧客は勝手なことを言うと思うべからず。 1 4 16
6 4.3.1 まったくランダムにサンプルを採取しなければならないと思うべからず 5 1 1
7 4.3.7 サンプルが多ければ良いと思うべからず 6 1 1
8 8.8.3 決めた標準に固執するべからず 9 -1 1
9 8.6.2 対策には排反事象(副作用)を忘れるべからず 8 1 1
10 5.3.1 データが取れないとあきらめるべからず 14 -4 16
11 1.1.1 品質第一はコストアップにつながると思うべからず 10 1 1
12 2.2.3 同じ考え方の人だけで活動するべからず 11 1 1
13 2.1.1 会社方針だからといって上司の指示事項だけを実施するべからず。 13 0 0
14 6.1.1 一件の言語データは簡単な単語で表現するべからず 18 -4 16
15 5.3.2 計測器などで得られるもののみをデータと思うべからず 15 0 0
16 5.5.3 飛び離れたプロットを無視するべからず
17 6.7.1 想定外の事態発生はあきらめるしかないと思うべからず
18 2.2.9 解決が見えている問題をQCストーリーで取り組むべからず 16 0 0
19 8.5.5 要因解析は特性要因図づくりに終始するべからず 19 -2 4
20 4.6.2 統計量、統計解析の計算に時間を費やすべからず 12 6 36
21 4.6.1 パソコンにデータ入力をしても生データは廃棄するべからず 17 2 4
22 7.1.1. プロセスと業務は異なると考えるべからず 21 -1 1
23 8.2.7 いつまでも簡単な問題に取り組むべからず 20 1 1
24 3.1.1 ねらいの品質とできばえの品質を混同するべからず 23 -1 1
25 8.5.1 「なぜなぜ分析」をせずに原因究明するべからず 22 1 1
26 5.4.1 生データばかり眺めるな 24 0 0
0 146

参考資料(reference)

プロセス改善に関して、個人的に有益な情報
https://qiita.com/kazuo_reve/items/2c9a2d13bd57282bec1f#_reference-c91e4090b6e13daa37a2

ワークショップ「ソフトウェア開発におけるHAZOP入門」の結果
https://qiita.com/kazuo_reve/items/c1c1d32baed5d60d55c7

自己参照(self reference)

QC検定1級 答え合わせ
https://qiita.com/kaizen_nagoya/items/51741ffa7b1422d9be50

kazuo_revのQiita記事の分析
https://qiita.com/kaizen_nagoya/items/81e3519e3740fa766d6a

views が12000になりました。ありがとうございます。

qc.png

画像が大きすぎた。下の記事を参考にwidth="400"にして、小さくしてみた。

Qiita(28)画像の大きさ調整
https://qiita.com/kaizen_nagoya/items/cef6ae1fcbdbec9e7be2

文書履歴(document history)

ver. 0.01 初稿。4項目 20210304 2000
ver. 0.02 8項目 20210304 2100 いいね1つ
ver. 0.03 12項目 20210304 2200 いいね2つ
ver. 0.04 16項目 20210304 2300 いいね3つ
ver. 0.05 20項目 20210305 0000 いいね4つ
いいねが増えるたびに4項目増やす予定。
ver. 0.06 項目数を増やすのは、3/21 QC検定が終わってからにさせてください。ごめんなさい。今のところ、1級も2級も落ちそうです。 20210307
ver. 0.07 24項目 20210308 いいねが100超えたのを機に、4項目追加。目次作成。
ver. 0.08 いいねが増えたら項目追加しようと思ったら、いいねが増えすぎて全項目書かざるをえなくなり、著作権者に引用許可を申請する文面を検討中。背景追記。優先順位順に並べ替え。20210404
ver. 0.09 views 12000記念 20210419
ver. 0.10 5.5.3 飛び離れたプロットを無視するべからず 追記 20210420
ver. 0.11 参考資料追記、画像を小さくしてみた。 20210424
ver. 0.12 たかたか分析追記 20210426
ver. 0.13 入手が困難そうで、復刊.comに登録しました。清き一票をお願いします。20210502 昼
ver. 0.14 カーリルで図書館の所蔵を調べた。国会図書館以外は10公共図書館。愛知県は三箇所。名古屋、安城、豊橋。20210502 夕
ver. 0.15 「QC検定にも役立つ!QCべからず集」四分類と逆が真な事例 URL追記 20210502 夜

161
Help us understand the problem. What is going on with this article?
Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
kaizen_nagoya
I'm a network designer.I work on TOPPERS SmallestSetProfile Kernel,MISRA-C, STARC RTL Design StyleGuide (Verilog-HDL),HAZOP,ISO/IEC15504(AutomotiveSPICE),ISO26262. I was an editor on ISO/IEC 15504.

Comments

No comments
Sign up for free and join this conversation.
Sign Up
If you already have a Qiita account Login
161
Help us understand the problem. What is going on with this article?