CD-JSQC-Std 22-001「新製品・新サービス開発管理の指針」に対するコメント まとめと対応
No. 項番号頁、行、図表番
コメント内容（各250字以内）
号など

提案（各250字以内）

対応

1

適用対象とする新製品・新サービスの定義が大変困難です。しかしそこが新製品管理の本質であって、これを避けて通ることはできません。既存製品に対する品質管理規格を、今だけ新製品だと都合よく迂回回避適用するための規格を提供すべきではありません。
品質管理をバックグラウンドとして、メーカーで新製品新事業の前線を担ってき本規格を適用できる新製品・新サービスとは、た △：５章に示された10のマネジた立場から、この規格について申し入れいたします。新製品と既存製品の間とえば、事業体においてそれが新製品・新サー メントの活動の“重要性”は、で、品質管理の位置づけや手法、推進方法は同一にならず別にすべきである
ビスであるとの認識がオーソライズされた（どう 新製品・新サービスの新規性から規格を別途作るというご認識なのであれば、その部分は大いに賛成いたし
やって、どのレベルで、どの期間？）対象に限 や組織における位置づけにます。新しい知見としてまさにJSQCが発信する対象に将来なろうかと考えま定する、などの規格適用対象の明確化が必須 よって異なることを４．３節に明す。しかしながら、原案については、失礼ながら、相当の勇み足があるように感です。さらに、従来製品に対応する品質保証部 記しました。
じてなりません。
門が、新製品・新サービスにおいても品質保証を担当できるのかどうか、蓄積されている技術知見や顧客対応知見の量と質が圧倒的に少ない状況において、品質を確保していくための組織的な取り組み方法こそが本規格に含まれるべきと考えます。

2

この規格は、品質管理を新製品に適用する場合はこうするのが良い、という指 4.1 ＴＱＭにおける新製品・新サービス開発管針のようです。そうであるならば、右記するようにこの規格を適用する部分を明 理の役割 とある部分に規格全体を代表させ確に品質管理に限るとして修正してほしい。て、規格の題名を含めて品質管理（品質保証で×：JSQC規格であり、品質管
この規格原案は、新製品・新サービスまた新事業が品質管理に関する何某か もTQMでもよい、細かな指摘ではない）に関す理に関する規格であることはの規格によって創り出される、という誤解を招きます。本規格の顧客は本規格 る規格であることを明確にしてほしい。題名から自明と考えます。他の規格にを利用する者であると考えてもらえるならば、顧客に生じる価値とは開発とその して明記することは最低限必要に思います。
ついても同様の考え方で「品管理にあるのであって、どうやって新製品を生み出すのかアイデアとマーケッ
質管理」という用語を含めていティングに奔走していても、品質管理の優先度は(既存製品との相対比較にお 「新製品・新サービスに関わる活動を効果的かません。
いて)高くないことは容易に想像されます。本規格の顧客からみれば、品質管 つ効率的に行うためのプロセス及び／又はシス理によって新製品・新サービスが創生されるという大変思いあがった見識をテムを定め，維持向上，改善及び／又は革新し×：JSQC 00-001の定義でJSQCは主張していると感じられてしまいます。て，次の新製品・新サービスの開発に活かす一す。敢えて変更する必要はな
品質管理学会の規格だから品質管理に関するであることは当然であり記さずと 連の活動」は、新製品・新サービス開発管理活いと判断しました。
もよい、という意見には賛成しません。仮にその立場であれば、たとえば、品質 動ではなく、新製品・新サービス開発における管理教育の指針という規格は単に教育の指針でよろしい、ということになり不適 品質管理(品質保証)活動と位置付けるべき。
切でしょう。

5.2 新製品・新サービスの企画と潜在ニーズの把握～5.4、は新製品開発をこうすればうまくいくという進め方そのものを記していますが、新製品開発の成功手
×：規格にする内容について法あるいはハウツーが、学術的成果として固まったから学会としてそれを公表 5.2 新製品・新サービスの企画と潜在ニーズのは論文として採用されるべきとする、という認識は持てません。学会として、新製品開発に関する論文が盛ん 把握～5.4、は広範囲に削除すべきでしょう。ほ言うご意見には賛成できませに掲載されているという実績もありません。この章の内容はまずは論文として学 とんどすべて削除すべきと考えます。
ん。実際に活用され、効果を会に受理されるべきに思います。今の時点では、JSQCが深く研究して知見をあげている実践法（ベストプラもち、規格として定められる資質があるのかどうか僭越ながら疑わしいと思いま 今後、学術成果が整った段階を待って、学会とクティス）の共通項を規格としす。一例で申し上げれば、5.4.4 知的財産に関する戦略 はJSQC以外の知見 して内容の質を担保できる見解をまとめることがて定めるというのがJSQC規格または常識とするのが妥当であり、少なくとも、より適切な学会・機関などからの 学会のガバナンスと考えます。の基本的な考え方です。
引用であるべきで、JSQCの立場でわざわざ規格として定めることには違和感があります。

3

全体

業種業態によってばらつきの大きい新商品・新サービス開発のプロセスを包括的にまとめて、その真髄を明確にされた大変価値ある規格として敬意を表します。

5

序文

3頁↓15行目

×：「しくみを構築する」ことが目的ではなく、新製品・新組織が新製品・新サービスを、効果的・効率的 サービスの活動をより効果的・「製品・サービスの品質の向上に貢献することを目的に，」では目的として広すに開発できるしくみを構築することを目的とし効率的なものにするためでぎないか。て・・・
す。ただし、究極的には、製品・サービスの品質の向上に貢献するためです。

6

序文

3頁↓25行目

CSポートフォリオとT型マトリックスはかなり違うので、それらをまとめて数えて、「五つ」を削除
五つというのは違和感がある

○

7

4.1.4

7頁↓図3

文中にある「メソッド・ツール（帳票，詳細な基準・標準類）が明らかになっていない。

文中にあるように、図の左側にメソッド・ツール（帳票，詳細な基準・標準類）を明記する。

○

8

4.1.4

7頁↓図4

図表のタイトルにある「例」とするにはマクロ的すぎる概念図 とする△：「例（概念図）」に修正しました。

94.1.4
4.1.5

タイトル
特に7頁↑11105.1.3

16頁↑19行目 「テーラリング」は一般的な用語ではない?

4－「新商品・新サービス開発」(プロセス・体系)とは、品質保証体系の部分集合と理解すればよいかもしれないが、後者には原価管理体系、納期管理体系など 提案無し。 感想です。
を別な体系として扱うというやり方もあるかと思う。

ー

カスタマイズ、あるいは 自組織に合わせて応用で○きる△：５章に示された10のマネジ
メントの活動の“重要性”は、「新規性の高い新製品・新サービスや・・・」というように、「新」にもいろいろなレベル「新」のレベルに関する議論とそれによって、省略 新製品・新サービスの新規性がある事を示したのは良い。さらに、どこかに「新」のレベルに関する議論とそれにした開発プロセスを用いても良いことを示す。
や組織における位置づけによって、省略した開発プロセスを用いても良いことを示してもらうと尚良い。
よって異なることを４．３節に明記しました。

115.2.1

16頁↑3行目

12

5.2.1

18頁↓19行目 「競合他社・競合組織についても把握」表現

競合他社・競合他組織の動向についても把握○135.2.1

18頁↓22行目 「競合他社・競合組織」表現

145.2.1

18頁↓22行目 「紐解くように把握する」何となくわかるが具体的にわからない。

155.2.2

18頁↑1行目

SNSだけではない，SNS 等を活用して165.3.1

19頁↓14行目

プロジェクトの定義が開発プロセス中の一部だけを対象とするように誤解を与えてしまう。

独自の製品・サービス又はそのコンポーネント △：設計や技術開発が例示でを開発するために実施 される有期性の活動を あることがわかる表現に修正しプロジェクトという．
ました。

175.3.1△：同上。また、表１の「プロジェクトマネジメント」を削除しました。なお、「要求事項を効新・・・のためにプロジェクトマネジメントは有効 果的・効率的に満足させるたなマネジメント手法である。
めに」というのはプロジェクトのまたは、一般的な定義に含まれる概念プロジェクトマネジメントが設計段階だけをイメージしてしまう。11頁表1中の主「プロジェクトの要求事項を効果的・効率的に満 です（ISO 9000の定義「開始19頁↓16行目 な活動のなかでもプロジェクトマネジメントが一部のプロセスだけに限定されて足させるために」を「新製品・新サービスを効果 日及び終了日をもち，調整さしまているように見える。
的効率的に開発するために」とする。
れ，管理された一連の活動か
また、11頁表1中の主な活動から「プロジェクトマ ら成り，時間，コスト及び資源ネジメント」を削除する。の制約を含む特定の要求事項に適合する目標を達成するために実施される特有のプロセス」）。

18

5.3.2

19頁↑15行目 文書の例が新商品・新サービス全体をカバーしていない。

19

5.3.4

「5.1.3節目管理」との関係がわかりずらい。

あきらめてそのままとする。

「競合他社・競合他組織」○○：「解き明かすように把握する」に修正する。
○

文書の例は削除する。
あるいは、表1表3などと融合して全体をカバー ×：同上。
する文書として位置付ける。
－

20

5.4.1

21頁↑8行目

ボトルネック営業などのプロセスにもある。順序を入れ替える。

ボトルネック技術は，開発プロセスの全てで検討する必要があるが、特に研究開発，製品・
×：他のプロセスにもあり得るサービス設計，生産・提供準備（工程設計）のプ ことが既に記されています。
ロセスでは重視するとよい。

215.4.2

22頁 表5

表中の「品質特性」が衝撃強度などと同様に見えてしまう。

罫線・フォントを変える等○

225.4.3

22頁↑8行目「に該当するかを考え」る前に、5.4.4にあるような調査・研究が必要ではないか。

補足を加える。

○：「組織の内外の情報を調査し，」を追記する。

23頁 図7

典型的なPDPCに見えない。静的な技術的表現ではなく、プロジェクトの推進に使ったような例が欲しい。

×：技術開発におけるPDPC
PDPC作図用の記号や、楽観ルート・悲観ルー においては、手順展開型ではトなどが入ったものとする。
なく、要因展開型の方がより重要になると考えます。

235.4.3

245.5.2

25頁↑5行目

細かく・・・と大きく・・・は逆ではないか。

細かく・・・と大きく・・・は逆にする。

△：「多くの種類を用意する」「少ない種類を用意する」に修正。

255.6.1

27頁↓8行目

参加者には商品企画部門も必要では。(主催者は入れていないということか?)

商品企画・，設計，生産・提供・・・

○26

5.6.2

28頁↓17行目 多くの項目が羅列的に並んでいるので読みにくい

ブレットフォームにする。

○275.7.1

意図はわかるが事例がわかりにくい。配合1と配合2の中間は無いのかとか、1530頁↓1-10行
配合ではなく、計数的な水準の要因として、反－27度あたりという日本では春と秋のシーズンでは配合1の方が良いので目応ももっと極端にしたグラフとする。
は・・・という余計な議論が出てしまう懸念がある。

×：実例に基づいています。

30頁↑7行目

活用事例、使用事例

×：ユースケースは専門用語です（活用事例、使用事例ではありません）。ユースケースの意味は文中ですでに説明しています。

5.7.2 を省略してここに入れる。

△：5.7.2(1)は、ばらつきの調査に当たっての推奨事項であり、5.7.3(1)は調査した結果にもとづいてばらつき要因を整理する際の推奨事項です。このことがより明確になるように修文しました。

28

5.7.2

「ユースケース」は一般的ではない

295.7.3

31頁↓14行目 (1) は5.7.2と重複している

30

5.7.4

32頁↓6行目

公差設計についてはもう少し欲しい。

×：コンカレントエンジニアリン
グのねらいは部門間連携と情
コンカレントエンジニアリングは5.8 部門間連携と情報・知識の共有化 のため
コンカレントエンジニアリングを記述する場所を 報・知識の共有によるライフサの一要素ではなく、コンカレントエンジニアリングをするためには5.8 部門間連変える。
イクル全体にわたるQCDの最携と情報・知識の共有化 が必要になるのではないか。
適化です。結果として期間短縮が図れます。

31

5.8.3

34頁↓6行目

325.8.3

フロントローディングと部門間連携をするためにコンカレントエンジニアリングを34頁↓7-8行目 実施するのではないのではないか。開発期間の短縮と最新技術要素を早く取り込む目的の方が大きいのではないか。

33

5.8.3

35頁↓14行目

コンカレントエンジニアリングに関する評価尺度の例としてあげられている（BET：Break Even Time）は妥当性が疑問。

×：頑健な設計についての推奨事項を示すのが主な目的です。

×：同上。
×：実際に組織で活用され、評価尺度として役立っています。

3435

5.9.1

5.10.1△：「実施期間は，新製品・新サービスの品質及び生産効実施期間は，新製品・新サービスの品質及び生 率が一定レベルに達するまで産効率 が一定レベルに達するまでの期間とし の期間とし，目標達成までのて、例えば3か月，あるいは生産台数1,000台な 期間として，例えば3か月，あどの目標を設定する．
るいは生産台数1,000台などの目標を設定する．」に修正しました。

35頁↑12行目

期間は初期流動の目的が達成できるまでの期間であり、機械的に決めるものではない。

37頁↑5行目

組織が新××開発管理の仕組みを改善していく上では、開発プロセスの見直 いつやるのか、誰がやるのか、その結果をどのし・改善 は大変重要だと思うが、なかなか仕組みとして実施されていない。そ ように反映させるのかという仕組みと、それを実△：「実施する時期，部門，方れは、この見直しは開発の評価ができるまで十分期間が経ってから(例えば1 践するためのトップのリーダーシップの重要性法などを定めた上で，」を追記年後)でないとできないからではないだろうか。例えば、図3、表1、図5などの体 や開発管理部・品質保証部などの業務も書いしました。
系図の中でも明示的には出てきていない。これをちゃんとやろうとすると、技術 ていただけると尚良いけれども、具体的な提案的にもリソース確保の観点からも実際にはなかなか難しい。
はできません。