タグアーカイブ: 設計開発

再び設計開発について | 平林良人の『つなげるツボ』

■□■　平林良人の『つなげるツボ』Vol.110　■□■　　　
＊＊＊　再び設計開発について　＊＊＊
—————————————————–

■□■　設計は図面というイメージが強い　■□■

設計というと「図面を書くというイメージ」が強いが、ISO9001でいう設計・開
発はそれだけではありません。

サービス業における活動においては、図面は書かなくても計画を立てるこ
とはよくあります。それらの計画の内容が新商品、新製品に関するもので
あれば、その計画行為はISO9001が定義する設計開発にあたります。

ISO9000:2015には設計・開発に関して次のようにあります。

「対象に対する要求事項を、その対象に対するより詳細な要求事項に変換
する一連のプロセス」

■□■　くい打ち工事には設計がある　■□■

先日、超ISO起業研究会で飯塚東大名誉教授との懇談会が開かれました
。そこでは設計・開発について「くい打ち工事」を例にしてざっくばらんな議
論がなされました。
専門家も加わり自由闊達に意見交換が行われましたが、いろいろな切り
口が出ました。

設計プロセスは無いという意見。

Ａ．くい打ち工事は国交省の認定工法であり、施工のやり方は決まってい
るので施工者には設計をする余地はない。

設計プロセスは有るという意見。

Ｂ．くち打ち工事の実施の仕方については、詳細なことになると決めておか
なければならないことが多くあり、それを決めることは設計にあたる。

なお、ここで議論をくい打ち工事を対象にしている意図は、たまたま社会的
な問題になったことで、事例として取り上げることで多くに人に理解しても
らえると思ったからです。

■□■　Ａ（設計は不要）の意見　■□■

今回のくい打ち工事は、大臣認定を取得した「ダイナウィング工法」で施工
していたと聞くが、大臣認定工法はやり方が決められているので、やり方
を守らなかったという問題はあるかもしれないが、施工者が工事のやり方
を設計するという余地はない。

ちなみに、大臣認定されたダイナウィング工法の作業フローは次のとおり
である。

　１．掘削作業
　　　－掘削ロッドの鉛直度を確認・調整
　　　－掘削液をビットの先端から吐出
　　　－地盤に適した速度に調整

　２．支持層の確認
　　　－ボーリング調査結果の確認
　　　－試験杭時、試掘削にて土砂を採取し土質標本と照合
　　　－オーガ※モータ電流値の変化傾向による支持層の推定

※建設機械の1つでスクリュー等を回転させて地中に穴を掘っていく機械

　３．根固め部の築造
　　　－セメントミル注入
　　　－流量計で注入量を計測・記録

　４．オーガ引上げ
　　　－拡大掘削径による引上げ

　５．杭埋設
　　　－杭の建込及び埋設
　　　－杭の定着

■□■　Ｂ（設計は必要）の意見　■□■

一般論として、施工をする場合には、今回のくい打ち工事に代表されるよう
に手順が決められていたとしても、さらに詳細な要求事項への変換が必要
ではないか。施工仕事が達成しなければならない品質を確保する上で、「
対象に対する要求事項を，その対象に対するより詳細な要求事項に変換
する一連のプロセス」（ISO9000:2015箇条3.4.8）が必要である。

今回のくい打ち工事の事例を見ても、大臣が指定した作業フローだけでは
品質確保されないと思う。

たとえば、２．支持層の確認には「オーガモータ電流値の変化傾向による
支持層の推定」とあるが、より詳細な要求事項に変換が必要であろう。

同様なことは１～５の各要求事項でも言えるのではないか。
　　　
■□■　一般に施工にも設計・開発プロセスはある　■□■

ＡとＢのグループに分かれて自由な議論を交わした結果、飯塚先生を含め
て次のような結論になりました。

何事もそうであるが、従事する人にはそれなりの力量が必要とされます。
したがって、施工者の技能が重要になりますが、同時に従事する人が多
数いても、同じ工事品質が得られる工夫も必要であり、大臣認定の要求事
項はさらに詳細化する必要があります。

たとえば、くい打ち工事では次のような詳細化された要求事項が必要では
ないでしょうか。

１．掘削ロッドの鉛直度はどのように調整するのか。
２．地盤に適した速度はどのように調整するのか。
３．ボーリング調査結果を確認して何を行うのか。
４． 試掘削で土砂を採取し土質標本と照合する場合の基準は何か。　　　
５．オーガモータ電流値による支持層の推定にはどんなやり方が必要か。
　　例えば、雨に濡れないようにするとかの注意事項が必要。
６．セメントミル注入時の注意事項は何か。
７．オーガ引上げ時の注意事項は何か。
８．杭の長さが足りなかった場合、どのような対応をしなければならないの
か、など

次回の懇談テーマを検討した結果、「リスクの特定と品質目標」
となりました（箇条6.1.2と6.2.2の関係）。

■□■　箇条6.1.2　リスクへの取組み　■□■

リスク及び機会は次のような取組み計画を作る必要があります。

a) 決定したリスク及び機会への取組み
b) 次の事項を行う方法

1) その取組みの品質マネジメントシステムプロセスへの統合及び実施
（4.4 参照）
2) その取組みの有効性の評価

リスク及び機会への取組みは，製品及びサービスの適合への潜在的な影
響と見合ったものでなければならない。

■□■　箇条6.2.2　品質目標の達成計画　■□■

品質目標にはa)からe)に実行計画の規定があります。

a) 　実施事項を決定する。
b)　 必要な資源を決定する。
c)　 責任者を決定する。
d)　 実施事項の完了時期を決定する。
e)　 結果の評価方法を決定する。

ISO9001における設計・開発 | 平林良人の『つなげるツボ』

■□■　平林良人の『つなげるツボ』Vol.109　■□■　　　
＊＊＊　ISO9001における設計・開発　＊＊＊
—————————————————–

■□■　再び設計・開発　■□■
横浜のマンションに関連して、杭打ち工事の報道が止みません。毎日の報道に接し
「杭を打つという仕事の設計、あるいは手順はどうあるべきか」考えさせられます。

■□■　ISO9001における設計・開発の定義　■□■
ISO9001:2015改正においては、設計・開発の定義が以下のように変更になりました。

「対象に対する要求事項を，その対象に対するより詳細な要求事項に変換する一連の
プロセス」（ISO9000:2015箇条3.4.8）

ここでいう対象は杭打ち工事になります。そうすると、要求事項をより詳細な要求事
項に変換するとは何を意味するのでしょうか？

※　ちなみに、2008年版では「要求事項を，製品，プロセス又はシステムの，規定さ
れた特性又は仕様書に変換する一連のプロセス」（ISO9000:20108箇条3.4.4）となっ
ていた。

ISOの定義はとかく難解で評判がよくないのですが、設計・開発については、2015年
版の定義は2008年版より理解しやすい定義になったのではないでしょうか。

■□■　より詳細な要求事項？　■□■
上記設計・開発の定義の中に出てくる要求事項は、「明示されている，通常暗黙のう
ちに了解されている又は義務として要求されている，ニーズ又は期待」
（ISO9000:2015箇条3.6.4）です。

今回の事件でいえば、「杭を打つという仕事のニーズと期待」が要求事項になりま
す。その要求事項は明示されている場合もありますが、通常暗黙のうちに了解されて
いる又は義務として要求されているものを含みます、というのがISOの定義です。

設計・開発は「要求事項をより詳細にする活動（プロセス）」だとISOでは言ってい
る（定義している）のですが、より詳細のレベルは組織の持つ固有技術、技能などに
よってさまざまであろうと思います。

■□■　設計・開発の注記　■□■
今回のISO9001:2015の定義は、附属書SL※の規定により、注記は定義の一部を成す
（NOTE　○○ to entry）とされましたので、注記の３つを調べてみたいと思いま
す。

注記１
「設計・開発へのインプットとなる要求事項は，調査・研究の結果であることが多
く，また，設計・開発からのアウトプットとなる要求事項よりも広範で，一般的な意
味で表現されることがある。要求事項は，通常，特性を用いて定義される。プロジェ
クトには，複数の設計・開発段階が存在することがある。」

ここでのポイントは「要求事項は，通常，特性を用いて定義される。」でしょう。
杭打ち工事においては、どんな特性が要求されていたのでしょうか。

■□■　注記の２　■□■
注記１につづいて注記の２には、設計という用語と開発という用語について触れてい
ます。通常、開発というと「研究開発」を思い浮かべ、設計より前の段階であると思
う人もいるかもしれませんが、開発は設計と同じ段階であるとして、ISOでは以下の
ように定義しています。

注記２
「注記2 “設計”，“開発”及び“設計・開発”という言葉は，あるときは同じ意味
で使われ，あるときには設計・開発全体の異なる段階を定義するために使われる。」

■□■　注記の３　■□■
設計・開発の注記３には、いろいろな設計・開発があるとして次のように定義されて
います。

注記3
「設計・開発されるものの性格を示すために，修飾語が用いられることがある［例　
製品の設計・開発，サービスの設計・開発又はプロセスの設計・開発］」

杭打ち工事を考えると、注記３でいう「プロセスの設計・開発」が該当するものと思
われます。

今回の事件は、施工における設計・開発を考えるよい機会になると思います。

建設施工における設計・開発 | 平林良人の『つなげるツボ』

■□■　平林良人の『つなげるツボ』Vol.108　■□■　　　
＊＊＊　建設施工における設計・開発　＊＊＊
—————————————————–

■□■　くい打ち工事の品質管理　■□■

連日、横浜のマンションの報道が各種メディアでなされています。
起きたこと、経過はまだすべてが明らかではありませんが、なぜそのようなことに
なったのか考えさせられます。今後、事実が明らかになっていくものと思います。

■□■　外注の品質管理　■□■

今回の事件でクローズアップしているのが外部委託の品質管理です。先週の日経新聞
でも大きく取り上げられていました。建設業界の重層構造に切り込む記事でした。

ISO9001:2015改正においては、箇条8.4「外部から提供されるプロセス、製品及び
サービスの管理」において、アウトソースの管理を要求されています。

このこと、すなわち外注の品質管理が今回そのままずばりの事象として社会問題化し
ました。

■□■　ISO9001:2015を見てみよう　■□■

改めてISO9001:2015を見てみましょう。8.4.1には次のようにあります。

「組織は，外部から提供されるプロセス，製品及びサービスが，要求事項に適合して
いることを確実にしなければならない。
組織は，次の事項に該当する場合には，外部から提供されるプロセス，製品及びサー
ビスに適用する管理を決定しなければならない。

a)外部提供者からの製品及びサービスが，組織自身の製品及びサービスに組み込む
ことを意図したものである場合

b)製品及びサービスが，組織に代わって，外部提供者から直接顧客に提供される場合

c)プロセス又はプロセスの一部が，組織の決定の結果として，外部提供者から提供さ
れる場合

組織は，要求事項に従ってプロセス又は製品・サービスを提供する外部提供者の能力
に基づいて，外部提供者の評価，選択，パフォーマンスの監視，及び再評価を行うた
めの基準を決定し，適用しなければならない。

組織は，これらの活動及びその評価によって生じる必要な処置について，文書化した
情報を保持しなければならない。」

■□■　組織とは誰か　■□■

8.4.1の一番最後には次のようにあります。

「組織は・・・外部提供者の評価，選択，パフォーマンスの監視，及び再評価を行う
ための基準を決定し，適用しなければならない。組織は，これらの活動及びその評価
によって生じる必要な処置について，文書化した情報を保持しなければならない。」

ここでいう組織は、いうまでもないことですが、外注にプロセスを発注する組織のこ
とです。

■□■　管理の方式及び程度　■□■

8.4.2においては「管理の方式及び程度」を決めなければならないとされています。

「管理の方式及び程度」を決めるのは組織です。
例えば、施工業者にはISO9001でいう「設計・開発」はシステムとしてないという説
がありますが、発注する側から見るとそれで大丈夫なのでしょうか。

「設計・開発」を考えるときには、施工における製品とは何であるかを考える必要が
あると思います。

ISO9001のmapping4 | 平林良人の『つなげるツボ』

■□■　平林良人の『つなげるツボ』Vol.101　■□■
＊＊＊　ISO9001のmapping4　＊＊＊

■□■　箇条8.3の細分箇条　■□■

前々回に続き、下記の細分箇条をどこへmappingするのが適切かの話をいたします。

8.3.4　設計・開発の管理
8.3.6　設計・開発の変更

■□■　細分箇条　8.3.4　設計・開発の管理　■□■

設計・開発の細分箇条8.3.4　設計・開発の管理を貴社の「QMSに必要なプロセス」に
mappingしてみましょう。

前回と同様、mappingの手順に沿って説明をしていきます。

1.規格の要求事項を理解する。
2.箇条4.4で要求されている「QMSに必要なプロセス」のinput、outputなどにmapping
する。
3.mappingした内容を貴社の具体的内容に置き換える。

■□■　手順１．規格の要求事項を理解する　■□■

細分箇条8.3.4　設計・開発の管理には、次のような要求があります。
「設計・開発プロセスに適用される管理は，次の事項を確実にしなければならない。

a)設計・開発活動によって達成される結果が明確にされている。

b)設計・開発のレビューが計画どおりに行われている。

c)設計・開発からのアウトプットが、設計・開発へのインプットの要求事項を満たして
いることを確実にするために、 検証が行われている。

d)結果として得られる製品及びサービスが、指定された用途又は意図された用途
（既知の場合）に応じた要求事項 を満たし得ることを確実にするために、妥当性確認
が行われている。」

8.3.2で要求されている「考慮しなければならない」事項に対して、8.3.4ではその後へ
の要求として「管理する」ことを規定しています。

8.3.2で考慮した結果、実施することになった事項について具体的管理の内容をここ
で明確にします。

■□■　手順２．箇条4.4で要求されている「QMSに必要なプロセス」のinput、output
などにmappingする　■□■

設計プロセスの箇条4.4c）判断基準、方法（測定を含む）にmappingすることがよいと
考えます。

いままで、mappingする先は「～と考えます」というだけで、mappingする先を決める
ルールを示してきませんでしたが、そのルールは次の通りです。

1.下記の７つ（bは除く）の中から、明らかに該当しないものを選ぶ。

a) input、output
b)省略
c)判断基準、方法（測定を含む）
d)資源
e)責任権限
f)リスク、機会
g)監視、測定
h)改善

2.残ったものを一つに絞る。

3.該当するプロセスを実施しようとしたとき、残ったmapping先が意味あるものである
か確認する。

■□■　手順３．mappingした内容を貴社の具体的内容に置き換える　■□■

前回と同様貴社が家電メーカーであるとして、事例を紹介します。「規格要求事項→
事例」のスタイルで紹介します。

a)　設計・開発活動によって達成される結果が明確にされている。
　　→　当社設計基準○○による。

b)　設計・開発のレビューが計画どおりに行われている。
　　→　当社設計レビュー基準○○による。

c)　設計・開発からのアウトプットが、設計・開発へのインプットの要求事項を満たし
ていることを確実にするために、検証が行われている。
　　→　当社設計検証基準○○による。

d)　結果として得られる製品及びサービスが、指定された用途又は意図された用途（
既知の場合）に応じた要求事項を満たし得ることを確実にするために、妥当性確認
が行われている。
　→　当社設計妥当性基準○○による。

というように、貴社の基準の名称、文書番号などを明確にすればよいでしょう。

■□■　細分箇条　8.3.6　設計・開発の変更　■□■

箇条8.3の最後の細分箇条になります。規格の要求は次の通りです。

「組織は，製品及びサービスの設計・開発の期間中に、又はそれ以降において、設
計へのインプット及び設計からのアウトプットに対し、要求事項への適合に一切悪影
響が出ない範囲で行われた変更をレビューし、管理し、識別しなければならない。
設計・開発の変更についての、文書化した情報を保持しなければならない。」

この要求はどこへmappingすればよいかを考えてみましょう。

■□■　手順１．規格の要求事項を理解する　■□■

8.3.6の要求事項の理解は容易であると思います。設計が行う変更は管理された状
態でおこなわれなければならないことを要求していると理解すればよいでしょう。

■□■　手順２．箇条4.4で要求されている「QMSに必要なプロセス」のinput、output
などにmappingする　■□■

この要求事項は、c)判断基準、方法（測定を含む）にmappingすることがよいと考えま
す。

■□■　手順３．mappingした内容を貴社の具体的内容に置き換える　■□■

―　組織は，製品及びサービスの設計・開発の期間中に、又はそれ以降において、
設計へのインプット及び設計からのアウトプットに対し、要求事項への適合に一切悪
影響が出ない範囲で行われた変更をレビューし、管理し、識別しなければならない。

―　設計・開発の変更についての、文書化した情報を保持しなければならない。

上記要求事項２つとも、　→　当社設計変更基準○○による。
という形での貴社の具体的内容への置き換えが考えられます。

ISO9001のmapping3 | 平林良人の『つなげるツボ』

■□■　平林良人の『つなげるツボ』Vol.99　■□■

＊＊＊　ISO9001のmapping3　＊＊＊

—————————————————–

■□■　箇条8.3の細分箇条　■□■

前回に続き、下記の細分箇条をどこへmappingするのが適切かの話をいたします。

8.3.1　一般
8.3.2　設計・開発の計画

■□■　細分箇条　8.3.1　一般　■□■

「組織の製品及びサービスの詳細な要求事項が確立されていない場合、またはそれら
がそれ以降の製品若しくはサービスの提供に十分であることが顧客若しくはその他の
利害関係者によって明確にされていない場合には、組織は，設計・開発プロセスを確
立し、実施し、維持しなければならない。」

前回のmappingの手順に沿って説明します。

１．規格の要求事項を理解する

この箇条は2015年版の特徴である「サービス業への配慮」の一つであると言われてい
ます。

2008年版では設計・開発の要求は前提なくすべての組織への要求でした。そのうえ
で、組織に設計という実務がなければ「除外」することが認められていました。

2015年版では、もしも組織が「組織の製品及びサービスの詳細な要求事項を確立して
いる，または，それらがそれ以降の製品若しくはサービスの提供に十分であることが顧
客若しくはその他の利害関係者によって明確にされている」場合は、設計・開発のプ
ロセスは存在しなくてよい、というのがここでの規格の理解です。

２．箇条4.4で要求されている「QMSに必要なプロセス」のinput、outputなどに
mappingする

次は手順の2になりますが、さてこの設計・開発に関する要求は次のどこへmapping
するのが適切でしょうか？

a) input、output
b)省略
c)判断基準、方法（測定を含む）
d)資源
e)責任権限
f)リスク、機会
g)監視、測定
h)改善

そもそも組織に設計実務がない場合には、「QMSに必要なプロセス」として設計プロ
セスが特定されてきません（この場合は、適用不可能ということになる・・・箇条4.
3を参照すること）。ここでの要求は、設計・開発プロセスを確立する場合に、それ
を実施し、管理することを要求事項していますので、mappingする先は、設計プロセ
スのinputが適切であると考えます。

３．mappingした内容を貴社の具体的内容に置き換える

貴社の具体的内容に置き換えるという手順ですが、設計プロセスを実施し、管理する
ことの具体的な内容があれば置き換えをしてください。とくに具体的内容がない場合
は無理に置き換えすることはありません。

■□■　細分箇条　8.3.2　設計・開発の計画　■□■

次の事例に行きます。設計・開発の細分箇条8.3.2です。
「設計・開発の段階及び管理を決定する際に，組織は、次の事項を考慮しなければな
らない。

a)設計・開発活動の性質，期間及び複雑さ

b)適用される設計・開発のレビューを含め、特定のプロセス段階を規定する要求事項

c)要求される設計・開発の検証及び妥当性確認

d)設計・開発プロセスに関する責任及び権限

e)設計・開発プロセスに関与する個人及び関係者間のインタフェースの管理の
必要性

f)設計・開発プロセスへの顧客及びユーザーグループの関与の必要性

g)設計・開発要求事項が満たされていることを確認するために必要な文書化
した情報

今までと同様、mappingの手順に沿って説明します。

１．規格の要求事項を理解する

設計プロセスでポイントとなることをa)～g)まで7項目にわたって考慮事項として要
求しています。ここで、ISOにおける「考慮：consider」という用語は「考慮した結
果実施しないこともあり得る」という解釈になっております。

２．箇条4.4で要求されている「QMSに必要なプロセス」のinput、outputなどに
mappingする

内容からいって、設計プロセスの「c.判断基準、方法」にmappingすることが適切
であると考えます。

３．mappingした内容を貴社の具体的内容に置き換える

貴社が、もし家電メーカーであるとしたならば、どのような具体的内容がありえる
か具体例を考えてみます。

a)　設計・開発活動の性質、期間及び複雑さ

→　貴社の「設計の段階」（原文はstagesとあり設計のステージを意味いっている）を明確にする。設計の管理について具体的なことがあれば明確にする。

b)　適用される設計・開発のレビューを含め、C特定のプロセス段階を規定する要求事項

→　設計レビューを実施するのであればその旨を明確にする。もし実施しないのであれば、そのことを明確にする。

c)　要求される設計・開発の検証及び妥当性確認

→　設計検証を実施するのであればその旨を明確にする。もし実施しないのであれば、そのことを明確にする。設計の妥当性確認も同様である。

d)　設計・開発プロセスに関する責任及び権限

→　責任者を明確にする。

e)　設計・開発プロセスに関与する個人及び関係者間のインタフェースの管理の必要性

→　設計部署のコミュニケーションについて明確にする。

f)　設計・開発プロセスへの顧客及びユーザーグループの関与の必要性

→　顧客及びユーザーグループの設計への関与について必要性の有無について明確にする。

g)　設計・開発要求事項が満たされていることを確認するために必要な文書化した情報

→　文書名、文書番号を明確にする。

以上はあくまでも例ですので、このようなイメージで規格要求事項を貴社の具体的事項に
置き換えてください。

以上