JSQC標準委員会様式
2013年5月7日

CD-JSQC Std 32-001 「日常管理の指針」に対するコメントと審議委員会による判定

章節項

No1

2

3.1

3.6

2

34, 5,7など

34頁、行

4.1

5

コメント内容（各250字以内）

提案（各250字以内）

3.1 日常管理組織のそれぞれの部門において、ある目的、目組織のそれぞれの部門において、日常的に実施されなければならない分掌業務 標を維持向上するための日常的に実施されなければならない分掌業務について、その業務目的について、その業務目的を効率的に達成するために必要なすべての活動。
↓を効率的に達成するために必要なすべての活
この定義ですと「日常管理」の役割を越え「方針管理」の領域まで含まれてし 動。
まうのではないでしょうか。注記２を活かした方が誤解がないと思われます。
→ （案）組織のそれぞれの部門において、ある目的、目標を維持向上するための日常的に実施されなければならない分掌業務について、その業務目的を効率的に達成するために必要なすべての活動。
3.6 工程異常／異常工程からのアウトプットの品質が通常求めるばプロセスが管理状態にないこと。
らつき範囲と異なること。
↓注記に委ねないと理解がしにくく、漠然としすぎていると思います。
言及すべきは１．異常とは「常と異なる」ことであり、不良とはまったく別物である
２．不良になる前に手を打つという管理図法が原点であり、稀有な未然防止のツールである
随所に「プロセス」と「システム」という言葉が出てきますが、「プロセス」「システム」についての定義、言及がなく、その違いが分かりに
くい
革新：改善と維持向上が組織の内部におけるプロセス及びシステムの運用・学習を通したノウハウの向上に基づいているのに対し、組織の外部や組織内の他部門で生み出された新たなノウハウの導入・活用などによるプロセス及びシステムの不連続な変更である↓
外部（組織外部や組織内の他部門」）のノウハウ導入だけが革新ではないと思いますし、システムの不連続な変更だけが革新ではないと思います。

革新：改善と維持向上が既存の枠組み（プロセス及びシステム）で不十分なことを直すという行動修正に対し、プロセス及びシステムを生み出した規範、考え方、目的を再考し既存の枠組みそのものを打破し、より高い価値提供をすること

採否審議委員会判定

×「日常的に実施されなければならない分掌業務」は、すべての業務を含みます。
ご指摘の通り、「効率的に達成するための活動」のうち、特に、「維持向上」に特化したものが日常管理です。JSQC-Std00-001の定義を変更する必要があります。このままとし、JSQC-Std 00-001の見直しの際に修正を検討したいと思います。

×

JSQC-Std 00-001の定義を変更する必要があります（これはJISの定義をベースにしています）。異常については4.5で詳しく説明していますので、このままとし、JSQC-Std 00-001の見直しの際に修正を検討したいと思います。

○

3.13節として、「システム」の定義を追加しました。「プロセス」の定義は3.10節にあります。

×

革新をご指摘の意味で使う場合もありますが、そうすると改善と革新の切り分けが難しくなりますので、原案通り（このまま）とさせていただきます。

「図2」について（なかなか表現は難しいですが）「維持向上」は「日常管理」、「改善・革新」は「方針管理」というのは割り切りすぎにも感じます。「維持」のための「改善」、「向上」のための「改善」、・・・と「日常管理」の中にも「改善」もあります。文字数は増えますが「現状からの改善・革新」「現状の維持・改善向上」という表現もあるかもしれません
54.1
図２

5

「方針管理」と「日常管理」については記されていますが、もう一つの柱である「機能別管理」が記されていないのは、なぜなのでしょうか。 「維持向上」「改善革新」にまたがるような記述があってもいいかもしれません「品質保証（顧客価値の創造）」とありますが、「顧客価値の創造＝経営」であり、品質保証はその一部であるのでここでは「品質保証」だけの記述でよいのではないでしょうか。

図２はあくまでも相対的な位置関係を示した図であり、厳密なものではありません。このことがより明確となるように図のタイトルを修正しました。
△

品質保証、コスト管理などが機能別管理に対応しますが、ここで、機能別管理という言葉を出すとかえって混乱すると考えます。
「顧客価値の創造」を削除しました。

67894.2

4.3

4.3

4.4

7

最初に標準ありきではなく、改善の結果が標準になるので本末転倒。

7-8

日常管理の方法として、SDCAサイクルだけを説明しているが、これだと製造部門の日常管理の場合には合致している。しかし、この指針の範囲は設計・開発日常管理の方法として課題発見・課題達成型のが含まれている。それらの場合にはプロセスでも、課題の定義、課題解決技法方法も記載する。の調査、同選択、選択した技法に基づく詳細プロセスの展開（WBSに記載)し、管理する。その場合には標準化ではなく、作業指示書記載事項の遵守になる。

84.4

9114.510
11行目

134.55

P:標準通り日常管理を計画する
D:計画通り管理する
C:管理水準から外れていないかチェックする
A:外れていたら改善して標準書を改訂する

71012PPMオーダーで管理している品質レベルで管理図で工程管理しているようなプロ管理図に関する記述は一切削除セスはありません。時代錯誤も甚だしいので標準化の目的は繰り返し行われる作業について標準化の目的は繰り返し行われる作業についてアウトプットのばらつきを押さばらつきをなくし、顧客の要求に合致したアウえるのが目的。ここに書かれている内容は標準化による便益であって目的ではトプットとして製品やサービスを提供するこない。と。

×

PPMレベルになっても異常に対する標準化や管理項目の考え方は有効です。累積和
管理図や圧縮限界などの方法が活用されています。管理項目や異常の概念を理解するのに、その前提として、管理図の考え方の理解は必要と考えます。

×

日常管理では改善や革新でなく、維持向上に焦点を絞っています。その意味で、一般的なＰＤＣＡサイクルでなく、改善の結果となる標準からはじまるＳＤＣＡサイクルを解説していますので、このままとさせていただきます。

×

設計・開発部門が行う業務の中には課題達成型のアプローチが必要になるものもありますが、これは主に方針管理で管理する業務になると考えます。ここでは、設計・開発部門が行う業務のうち、日常管理で管理する業務を対象としています。

○「標準化の目的は」を「標準化の便益は」に修正します。３番目のビュレットの表現を「信頼性・安全性」だけでなく、顧客ニーズを満たすという視点の表現に修正しました。なお、標準化の目的はばらつき低減でだけでなく、平均値の向上にも役立ちます。

標準化でエラープルーフは出来ない。KYTやポカヨケが有効な手段。

７－１０行目まで削除△

標準化の一環としてエラープルーフを位置づけています。エラープルーフ化＝ポカヨケです（JSQC-Std 00-001の用語に従っています）。フールプルーフ、ポカヨケ等と同義語であることがわかるように説明を追記しました。

容認できない原因ではなく「見逃せない原因」が正しい「見逃せない原因」に訂正○「見逃せない原因」に修正しました。

○

工程能力調査や工程解析の結果に基づいて改善・革新を行う必要があることを明記しました。

○5.4.6項として「変化点への対応」を新たに設けました。また、変更管理ボードと管理図をまとめて掲示し、異常の原因追及・再発防止に役立てているところが多いことを考慮し、5.7の異常の原因追及・再発防止に説明を追記しました。

10
工程能力が不足している場合は管理図で管理すべきではない。Short Term と 工程能力調査を行い工程能力不足を改善して管下から４行 Long Termの工程能力調査を行い工程能力が十分になるまで改善を行い、管理状 理図管理を導入する。工程が管理状態になるま目態になったところで管理図を導入するのが筋。工程能力がないのは設計上の問 では暫定的に抜き取りまたは全数検査を行って題や生産設備の問題なのでまずこれを解決するのが先決。
後工程への品質を保証する。

日常管理の要素として「変更管理」についての説明が必要かと思います。

145
図７

15 5.3.1

12

14
16行目

16 5.4.3

1417 5.4.5177行目

品質方針－５．１－５．２－５．３－５．５－５．４－５．６－５．７の順番。

5.7.3
図1322×△

ＱＣ工程表は分析の手法というより結果をわかりやすく示す方法と考えています。QC工程表に関する説明を5.5.5に追記しました。

QC工程表も日本生まれのプロセスフローを分析する方法のひとつと考えられる f) QC工程表
ので、QC工程表を追加する。

教育訓練の仕方が明確になっていない

教育訓練はTWI-JIを適用する

×

指針ですので基本的な考え方のみを示しています。具体的な教育訓練の仕方まで記載するのは学会標準として適切でないと考えますので、このままとさせていただきます。

原稿：初品検査

提案：初物検査理由：品質管理用語を用いた方がよいと思われるため。

○「初物検査」に修正しました。

「QC工程表」は製造の日常管理の基準となるものと思っていますが、これについての解説があるとよいと思います。

○

5.5.5にＱＣ工程表に関する説明を追記しました。

18 5.5.5

19

左欄に同じ５．４（標準化）と５．５（管理項目の設定）については、相補的に行われるものと考えます。ただし、基本的には５．
３で満たすべき要求事項を明確にし、これに基づいて標準化を行い、最後に管理項目を設定するのが論理的な順序と考えます。５．では、５．４～５．５が反復的に行われることを明記していますので、このままとさせていただきます。
品質方針は方針管理の範疇と考え、本指針では詳細説明しておりません。

A-KOMIKのフローと比較して抜けがある

A-KOMIKのフローそのものを使う

×

本指針は基本的な判定の考え方のみを参考として示しています。ご指摘のように色んな観点からの判定フローがあると思いますが、学会標準としてはこのままとさせていただきます。

・・・重要な役割である。また、上級管理者
は、環境の変化に伴う事業の見直し・変革と日常管理との必要な整合を推進する責務を持つ。
以下のことに・・・○追記しました。

62420行目

環境の変化に合わせ、日常管理を事業計画(中長期計画を含む)に合わせ整合する役割を上級管理者の役割として追加。環境の変化に伴い事業の見直し・変革情報は最終的に上級管理者に集中しやすいので、日常管理と整合を推進する責務を上級管理者に持たせる。

217.1

26
10行目

設計・開発業務は一般的にプロジェクト型業務であり、ＷＢＳ(P13 ｂ）を用プロジェクトマネジメントの専門家が参加していて行うことが多い。課題も製造部門と異なり、割り当てらたWBS以外の業務をいるJSQC ソフトウェア部会の意見も聴取するこしばしば行うことがある。日常管理では担当業務外プロジェクト業務や、プロとを提案する。
ジェクト外業務を管理することがある。

△

ここでは技術標準に基づいて行う設計業
務を対象としています。そのことが明確となるように説明を補足しました。

227.1
表６27

デザインレビューの管理項目の例としては実務では適用できない形式的な日常管理の内容となっている。(専門家によっては異論があり得るが）×

表６はあくまでも一例として示しておりますので、このままとさせていただきます。

20同上

2324

7.2

7.2

267.3
表78.2
表928 8.4 a)

29

多品種少量生産では管理図管理は使えない

8.5
表10

オンラインの品質工学で工程を設計する製造において「材料・部品」の日常品質管理に関する記述が必要かと思います。

7.2252727

同じく製造において「設備」の日常管理に関する記述が必要ではないかと思います。

2832
33行目

33
9,10行目35以降営業の場合はパイプラインマネジメントが主流。表７は役に立たない。

パイプラインマネジメントで説明する。

TQM推進役になる管理職に対する｢日常管理の基礎となるTQMの教育内容｣が少な ・TQMの原則
いと思う。重複しても良いならば、TQMの原則と、改善の手順(問題解決法)を追 ・改善の手順(問題解決法)加する。重複を認めないならば、TQM推進実績と課題のようなものを追加する。 又は・TQM推進実績と課題を追加

原稿：改廃定提案：改廃 または （制定または改廃）
理由：改廃定は、あまり用いないため。

項目が多すぎて煩雑

クロスビーの成熟モデルのようにA4１枚にまとめる

×

7章では、5-6章の捕捉を行っています。
7.2節ではいくつかの難しいケースを取り上げ、管理図の考え方を応用する場合の注意点を述べています。このことが明確となるように７．の最初に説明を追記しました。

△

7章では、5-6章の捕捉を行っています。
したがって、特定の要素についての詳しい説明は行っていません。このことが明確となるように７．の最初に説明を追記しました。

△

7章では、5-6章の捕捉を行っています。
したがって、特定の要素についての詳しい説明は行っていません。このことが明確となるように７．の最初に説明を追記しました。

×

表7はプロセスの明確化の例です。営業プロセスの詳しい管理のやり方を示すことが目的ではありませんので、このままとさせていただきます。

○

追記しました。

○「改訂・廃止」に修正しました。

△

本文の記述と対応しています。方針管理の指針JIS Q 9023と同等のレベルとなっています。なお、ページごとに列の説明を入れるようにしました。

×「ほとんど」を削除することも考えられますが、そうすると100%でなければ該当しないと誤解される可能性があります。
この表はあくまでも一般的な例として示したものであり、個々の組織で活用される際は、もう少し厳密な記述に直していただいてよいと考えています。

△

QAネットワークのような、品質保証のシステムとして見たときの一貫性です。説
明を修正しました。

誰もが同じようにレベル評価できるように、評価基準の6箇所で使われている｢ほとんど｣と判断できる頻度を少しどこかで定義してほしい。評価対象組織の大きさ、評価期間、評価時期などで評価基準が変わるかも知れませんが。
3031

8.5
表108.5
表1035,36,37｢品質保証の視点からの論理的な一貫性が確保できている。｣はどんなことを意 プロセスにおけるPDCAなど、論理的な一貫性が図しているのでしょうか。レベル評価しやすいように、意図する説明を追加し 確保されている。
36
5.3のレベル て、この言葉を置き換えてください。PDCAのことでしょうか。
5