Character

Character

Takao Ramuh

Masamune [Mana]

You have no connection with this character.

Follower Requests

Before this character can be followed, you must first submit a follower request.
Do you wish to proceed?

  • 0

【FF14】ゲームのQA(4) 設備・システム クオリフィケーション・バリデーション 問題なく動く?

Public
ほんと、設備・システムは、まともに動かない

設置して最初からスムーズに動いたためしがない

最初からまともに動かす方法はないの?




 今回は、設備・システムの検証方法とQAの関わり方について書きました。

 まあ、普通で、メモです。


システム設備の稼働を検証する作業に、クオリフィケーション・バリデーションがあります。

QAはそれら検証作業の計画・結果を確認・承認し、問題なければ設備・システムの稼働を可とします。


設備・システムを新規作成もしくは改良する際、それらが適切に稼働することをそれぞれのステップ毎に検証する、がクオリフィケーション・バリデーションです。


これも最初聞いて理解するまでに大変時間がかかって、、、、こんなんやるのとか、、



「 結果的にうまく動けば問題ないじゃない、めんどくさいこと言わずにスピード感出していこうよ 」というのが従来、というか大昔の考え方です。

先人の方々は、「 いちかばちかで、うまくいけばいいじゃない 」という考えで進めて、山ほど手痛い目にあってきて、、今もなお、、


そこで、開発中や稼働中に、ステップ毎に検証して、問題ないことを確認して作業を進める、

こうすると、設備システムがうまく動いていることを確認できて、良い製品を作れるよね、

また、開発生産の途中で悪いとこがわかれば、それをいち早く改善できて、

不具合に気付かずに完成させてしまった設備や製品がすべて無駄にならないよね、

ということを学んで、医薬品開発製造関連では、この検証作業を必須として、導入しました。


開発時、製造時、リタイアメント時といった、ライフサイクルに合わせて検証し、
設備システムをずっと問題なく稼働させて、
良い製品を継続的に作り続けよう、
といった考え方がバリデーションです。

もうなんでもそうなのですが、検証の項目や対象設備・システムの選定は、品質は何かに立ち返って、それへの影響を考慮したリスクベースで決めています。

複合の設備・システムの開発では、
・当該設備システムが図面等でどこまでの範囲を言っているのか、
・他のシステムとの取り合いの検証はどっちのシステムで実施するのか、
・システム全体の稼働の検証をどこで実施するのか、特に負荷テストとか、
が超複雑となり丁寧に行う必要があります。最初に図で確認すべきかと。



 もちろん、めんどくさいですし、時間かかりますし、問題があると振り出しに戻されるし、モノづくりの人にはまったく好まれませんw
おいおいなにさせてくてるんだい、そんなことしなくてもいいもん作れるんだよ、といった感じです。


 医薬品業界の場合は、万が一にも品質に影響のある製品が市場に流通すると、患者さんの生死にかかわるという事情もあり、
クオリフィケーション・バリデーションのシステムが適切に導入されている事業所のみが医薬品の製造の許可を受けられます。


クオリフィケーション・バリデーションの流れは以下の通りです。

・開発時
マスターバリデーションプラン(MVP)の作成

 本バリデーションにおける目的を明確にして、DQ~PVまで、どのような検証作業を実施するかを計画し、すべての対応が問題なく完了したことを確認して、製品の使用を可能にするというプランを設定する。

 デザインフェーズ(Design Phase)
  ↓URS(ユーザー要求仕様書)
  ↓DQ(デザインクオリフィケーション)
  ↓DI(データインティグリィティー)
 開発フェーズ(Development Phase)
  ↓IQ(Instllation Qualification,据付時適格性評価)
  ↓OQ(Operating Qualification,運転時適格性評価)
  ↓PQ(Performance Qualification,性能適格性評価)
  ↓PV(Process Validation,プロセスバリデーション,予測的バリデーション)
  ↓CV(Cleaning Validation,クリーニングバリデーション)
  ↓Maintenance,Caliblation(メインテナンス計画、キャリブレーション計画)
  ↓SOP(手順書の整備)

マスターバリデーションレポート(MVR)の作成



QAは、それぞれのフェーズの検証作業において、重要な個所に、クライテリアが設けられ、問題ない結果が得られたことを確認・承認し、次フェーズへの移行を可とします。


・設備システムの通常の稼働時
 開発時に設定された検証項目に基づき、重要と考えられる確認項目及びクライテリアを設定する、
ステップ毎もしくはリアルタイムで確認し、問題なく動いている、品質の問題のない製品が出来ている、ことを確認する。
 QAはその計画報告が問題ないことを確認・承認して、設備システムの稼働の継続を可とします。
 必要であれば、変更時のバリデーション、再バリデーションを指示する。

・リタイアメント時
 設備をリタイアメントしても他のシステムの稼働や製品製造に問題ないことを確認し、設備に蓄積した情報等の流出がないことを確認して、設備・システムの停止・廃棄を行います。
 QAはその計画報告が問題ないことを確認・承認して、設備システムが適切に停止、廃棄を可とします。

 一部変更管理の作業とも重なっていますが、QAはそれぞれの検証作業に問題ないことをを計画報告書で確認承認して、次作業への移行、設備稼働開始、設備システムの廃棄は可であることを決定します。


 以上が、設備・システムが問題なく稼働するための検証作業、クオリフィケーション・バリデーションとなります。

 かなり端折っていますw

 詳細は参考を見て頂ければっと。


 
 まあ、ご存じな方はご存じで、

これやれば確実にうまく動くのと言われれば、???なのですが、

事前に予測されるリスクは排除出来て、

トラブル数を減らして、

仕方なく発生したトラブルに対処できる時間を稼げる、、、、w

少なくともこのくらいはやる、、、w




 次回は、コンピュータシステムのクオリフィケーション・バリデーションとなります。

ゲームのQAを考える事に辿り着くまで遠く、、、


参考:バリデーションの考え方と実施例
Comments (0)
Post a Comment

Community Wall

Recent Activity

Filter which items are to be displayed below.
* Notifications for standings updates are shared across all Worlds.
* Notifications for PvP team formations are shared for all languages.
* Notifications for free company formations are shared for all languages.

Sort by
Data Center / Home World
Primary language
Displaying