goo blog サービス終了のお知らせ 

電気設備等の受注Know-how

長年、通信設備などのシステム受注の仕事で得たKnow-howをまとめたブログです。
何かの参考になれば幸いです。

03.設計形態による品質評価の違い

2019-04-28 22:44:32 | 12.品質

製品時の品質とシステ時の品質の差異です。

 

製品品質

システム品質


 

 

 

 

 

自社設計製品時の保証


動作振る舞いや、利用範囲の必要条件が過去からの経緯で取り込まれている場合がおおく、確実な明文化になっているとは限らないが、製品の継承(後継機種設計としての継承)により暗黙の了解で取り込まれている場合が多くある。

 製品仕様という概念があれば、設計を着手する前に、製品の姿を製品仕様書としてオーソライズし、その製品仕様書に合致する製品を設計着手することになる。よって、暗黙の了解もその製品仕様書に網羅することが機種単位で確認することができる。(アルゴリズムを作る場合でも、ライセンス契約したオブジェクトのポーティングでも、動作振る舞いが把握できるため、製品特性や利用時のユースケースへの適正判断ができることになる)。

 課題1:製品仕様は、設計フェーズの中で設計仕様の位置づけで書かれている。

設計が自ら製品使用を書くのは良いが、設計を着手する前段階にオーソライズしておかなければ、「出来たもの準拠」になってもおかしくない。この状況を作らないためにも、製品仕様は、設計を行うときのインプット文書でなければならない。

 設計部門として設計保証できる自社設計の上に、妥当性試験や製品試験がある。

品証の商品検査も同様な品質検査で行われる。


製品仕様書で定められた利用方法を超えた場合には、異常や不具合として製品が利用できない場合も出てくる。しかし、製品の制限が明確に製品仕様で表記されていることで、システムとしての構築段階で歯止めを掛けることができる。すなわちシステムとしての品質を制御することができる。

 ここで弊社の2つ目の課題は、後者(システムとしての品質)に当たる課題に直結する「システムとしての設計責任」です。

 システム設計時の設計根拠(妥当性)が不透明であることが上げられる。具体的には、システム設計保証はどこが担保しているのかがとても希薄であるということ。

 課題2:出荷してしまえば、後工程で異常が発生しても、品質保証部門の受け皿がある(間違いではないです)。しかし、不具合を受けた品質保証部門は、出荷履歴も無く、どのようなシステム構成かも分からず、設定内容なども不明な状況が多々あるなか、現場に行って確認することしかできない(現場第一は正論ですが)。異常を受けた時点では、異常が出た現象だけで判断することはできない、システムとしても検討すらできない状況は、システムを提供している会社として恥じるべきこととして至急の改善が必要。

 

 顧客の要件定義がどんなに確実に実施できたとしても、システム設計品質が不透明では、要件定義の労力も半減以下になってしまう。

 システムは、各工程の積み重ねです。量産設計も同様ですが、1品受注であるために、一つが不明書くな状態であれば、後工程は比例して不明確になり、不明確の範囲が拡大していく。よっえ何が悪いかもシステムの視点で見た場合、察知しようの無い、また、つかみようの無い異常になって出てくるため、やるべきこと(これが工程所や手順書)に準拠した仕事にすることが必須です(第三者が対応する場合には特に必要です)。


 

 

 

相手先商品に委託設計の保証


委託した仕様については外部仕様(製品の動作や振る舞いとして動作として見える仕様)として弊社が関われるが、その外部仕様から委託先で詳細設計が進められていくため、詳細設計のレビューに参画しミスや抜け、異常処理時や準正常系の漏れなどを精査する過程を作らなければ、委託部分の設計品質は把握できない。したがって、第一の品質評価フェーズは、レビューの場が1次評価になる。

そして、エンジニアリングサンプル(ES品)が出来上がった状態では、自社設計と同様な妥当性試験や製品試験では、製品が持つばらつきの状態や、処理パフォーマンスなどの処理能力の判断はできない。したがって、設計委託維持の製品試験や設計妥当性試験は、環境試験を始め試験のパラメータの上限値と下限値を網羅した試験にしなければ品質の判断ができない。


システムとして運用する動作振る舞いや環境に適合できていることを選定時に評価する。ここで誤った選定をした場合、システム運用時の障害や異常の原因にも繋がっていく。そして、要件に対して満足できる仕様(スペック)であることがその次の必要条件になる。

システム上の運用や設置環境そしてスペックが適正な場合選定となる。

システム評価では、可能な限り客先と同じ環境で擬似試験を行うことが必要になる。出荷としての受注会社の責務であり、受注コストの金額で決めるものではない。

システム試験は、自社設計製品の保証と同等に行うことができるが、注意しなければならないことが一つある。

耐久性など、経年変化による劣化によるシステム品質の悪化は、システム保証段階では、見抜けない場合が多い。この経年変化によるシステム保証は、製品品質(製品保証)として行うことになる。

 


 

 

相手先製品時の保証


弊社が利用するしじょうでの運用を想定した環境試験を始めとする、動作パラメータの閾値試験、そして、製品仕様に記載されているスペック試験を実施して、製品のばらつきを鑑みた判断を行う必要がある。

仕様を想定している市場要求は容赦ないです。選定してから市場の環境ではどうかと言う思想では駄目。

適用する市場や運用する環境や使われ方などから製品を定めていくことが重要になり、その手順で外部仕様評価として品質を判断おしていく。


上記と同じ


02.出図(図面(仕様書)の品質)とは

2019-04-25 11:43:27 | 12.品質

図面(仕様書)の品質

出図(しゅつず)とは、何でしょうか。

   図面を出すこと。

ですが、どんな図面をどのように出すのでしょうか。

JIS Z 8114:1999 製図-製図用語
Technical product documentation−Terms relating to technical drawings

2.1 製図一般に関する用語

  番号:1002
  用語:図面
  定義:情報媒体,規則に従って図又は線図(4109 参照)で表した,
     そして多くの場合には尺度に従って描いた技術情報。
  備考:この用語を複合語として用いる場合は,省略形で単に“∼図”とすることが多い。

2.5 図面管理に関する用語

  番号:5001
  用語:図面管理
  定義:図面に関する業務の管理。
  備考:図面(仕様書などを含む。)に関する業務の内容を大別すると次のようになる。
     a)原図の登録,保管,出納,廃却。
     b)複写図の作成,編集,配布,回収,廃却。
     c)図面の変更の手続き。
     d)第二原図,マイクロフイルム。

  番号:5015
  用語:出図
  定義:登録した図面を発行する行為。
  備考:-


図面の作成:図面(仕様書を含む系統図、姿図、取付図 などの線図)を作成し、
図面の精査:作成内容の複数の目でレビューし、記載漏れや誤記、解釈の違いなどを取り除き、
図番の付与:図面に適合する案件などとの関連付けのための図番を付与し、
図面の登録:図面の登録を行う。図番により適用案件や、改訂図面を含め最新であることが容易に管理できる。
出図      :登録した図面に対して、組織(会社)として正式な書面として外部に提出することが出来る。


01.品質の定義(製品品質とシステム品質)

2019-04-22 21:18:35 | 12.品質

製品(システムに用いる自社量産製品、特型(顧客に合わせて設計した自社製品(無形物も含む))
やシステム全体(自社量産製品、他社購入品(確定手配品)、接続ケーブルなど全て)の品質は、そ
れぞれ異なって品質の定義がある。
全社を製品品質、後者をシステム品質と定める。

1)製品品質
 製品品質の定義
  標準品として自社生産する製品の品質は、工場や生産拠点等で定めた出荷品質に従った製品評価
    を行われたものを指し、工場や生産拠点で出荷品質を品質保証部が委託し製品品質を保証する。
 
  特型製品の場合は、顧客に特化した仕様で作りこまれた製品(ソフトウェア等を含む)となり、
    設計のインプット、アウトプットから生成された試験成績書(試験方法の書面)に合わせて、管
    轄する品質保証部門が設計品質評価を行い特型単品として品質を担保する。

 製品品質の消滅
  製品品質は、工場や生産拠点で提供される品質のため、製品を開梱した場合には、出荷品質は消
    滅する。従って、品質保証部の指定する品質確保を行わない限り製品品質の保証して出荷するこ
    とができない。

 製品品質の再確保
  製品品質の再度保証を復活させるためには、指定されたプロセスで品質検査を行うか、品質保証
    部は指示する場所において品質検査を行うことが必要となる。

2)システム品質
 システム品質の定義
  システム受注で契約したシステムの範囲を保証する。
   動作振る舞い及び機能等、システム連携としての要求事項など
   システム保証では、自社品、他社品問わず、システムとして弊社がシステムを実現する構成要
   素として必要な機材として保証しなければならない。
   また、システム内で用いる機材が、システム機能以外で不具合が発生した場合でも、機器とし
   ての影響が無い不具合であれば、システム不具合としては扱わない。(顧客の運用では発覚す
   ることがない)
  
   すなわちシステム品質は、顧客の要件が必須としている品質を担保することになる。また、こ
   のシステム品質の基準となるものは、納入仕様書で規定した動作、機能等として定義すること
   になる。

 システム品質の担保
  納入物(納入システム)の納入仕様書による定義が一般的となり、この書面で客先承認された諸
  元でシステム品質を定義することが出来る。このように、システム受注の業務では、納入仕様書
  及び納入仕様書の客先承認はシステム品質の起点となるいために必須書面となる。

  納入するシステムが、顧客に提供する機能(要件定義所や納入仕様等の客先承認された仕様書)
  を網羅し、逸脱無い動作振る舞い稼動や、必要処理が行われることを試験成績書に則り品質を担
  保する。
  システム試験は、擬似稼働試験により実施することとなるため、客先環境とは異なった条件にな
  ることも考慮してリスクを回避できる手段を選択すること(場合によっては、客先の設備を借用
  することも考えられます)。

  自社製品や他社製品を用いてシステムが構築荒れている場合であっても、システムとして全ての
  構成要素の品質を、顧客と定めた要求仕様に対して保証する(他社品の主機能を用いたシステム
  であっても、システムとして弊社が選定した機材としてシステム保守御と明言することがシステ
  ム事業の鉄則です)。

確定手配品の品質
  確定手配品の品質は、個別受注で用いる数量を購入するのみとなるため、品質協定書などの締結
  は取り交わすことはしない。
  ただし、サーバやPCなど、購入先メーカが保証する契約を持っている場合には、その契約内で
  弊社対購入先メーカ契約として確保することも一つの方策。しかし、納入したシステム品質とし
  ては、お客様対弊社になる。
    
顧客立会検査
  出荷品質を経たシステム品は、顧客の立会検査を受けることができる。顧客の立会検査を受ける
  場合、出荷検査の試験項目の同期をとる必要が有る。したがって、顧客立会時の試験項目は、事
  前に顧客、品質保証部、当該の受注担当営業、技術を含め協議した内容を確定しておく。

確定手配品の安全規格
  電安法に該当する製品は、少なくとも電案法に準拠した機材として安全性を担保しなければなら
  ない。
  電安法等は、市場の事故等の発生を抑えるため、改訂が行われる。従って、最新を必ず確認して
  いただく必要がある。また、その上で、納入仕様書に適用製品のトレース情報(型番、低角、1
  次電圧仕様、2次電圧仕様など)を記録しておく。

工事品質
  工事計画書により取り付けるシステム機材の注意点を明記し、通電時のシステム品質を維持する
  工事として実施する。また、電気通信設備、建築工事(電気設備工事)仕様書に従った標準作業
  で進めること。
  顧客の立会検査前に、取りつけた機材の通電及び基本動作確認を行い、顧客立会検収に入る。


3)必要性の高い品質保証手段

 定型的なシステム品のシステム品質
  定型的なシステム提供品は、定型とされる構成要素や利用する機材等を予め定型システムとして
  品質評価を受けたシステム構成を指す。また、定見的なシステムでは、最大構成要素を満足する
  範囲であれば、品質保証部が指定するシステム品質を実施することなく出荷することができる。

  ただし、出荷履歴は、受注履歴と一体管理し、出荷した顧客に対してトレーサビリティを確保し
  なければならない。

 書面審査によるシステム品質の確保
  書面審査を受けるシステムは、顧客が指定する要件(動作振舞や稼働状態)を試験成績書として
  作成し、その試験項目の判断基準を列挙し品質保証部の承認を得ておく。
  承認を得た試験成績書に従って試験を行う。また、試験の結果は、試験成績書に結果を記載し品
  質保証部の承認印を得て品質を担保することができる。試験成績書に記載する結果は、〇×だけ
  でなく、具体的な値(数値)や表現(***の動作を満足した。など)を用いること。