RAMS[17]　体制と組織

RAMS[9] 監視でRAMSのプロセスは監視が需要ですと書きました。では、具体的にどんな体制にしたらよいのでしょうか？　沢山の設計者がいる企業はいいかもしれませんが、小規模の会社はどうしたらよいのでしょうか？このブログで書いてあることは、ISAによって判断が異なります。なので、ISAに確認してください。なんで同じ規格を使っているのに判断基準が変わるのか？　ということはまた別途ブログで書いてみたいと思います。

日本の業務のやり方は一部の例外企業を除いて大体が日本方式ではないでしょうか？　私が思う日本方式とは、設計者は設計し、設計検証をして、型式認定は、生産技術や検査部門が行い。実際の量産には生産部門または検査部門が検査して出荷する。設計プロセスも殆どが、設計者で進められて、設計者はなんでも自分でこなす。そして、最後の判断基準は要求を満足しているかということです。図面と試験結果を上司が照査・承認して設計は完了します。安全装置なので、レビューも行っていると思います。これは設計者以外の人を交えて行っているでしょうけど。品質に関しては設計過程に第三者が直接入り込んでくるというのは少ないのではないでしょうか？　既に設計規定があるのでしょうから、それに基づいて設計を行っているのが実態でしょう。逆にいうと、これをちゃんと行い、エビデンスを残しているのであれば、今の社内設計方法でも十分RAMSに対応できます。

これらができているとして、困るのはやはり体制ではないでしょうか？　例えば、Verfierはどうする？　 Validator は誰がやる？　Safety Manager は？　Quality Manager は？　Configuration Manager は？となるわけです。日本式の場合は多分こういう役割は用意していないのではないでしょうか？　まあ、 Verfierは 係長や課長が行えば大丈夫だと思いますが、他のはちょっと難しいですよね？　

国内製品ばかりを作っている企業で、海外製品を作ることになり、RAMSをやらなければいけないとなった時にみんな慌てます。なぜなら、慌てる人は海外製品を担当した人、もしくは部署であって、他の人は今までの通りにやっていればいいので我関せずとなります。次に起きるのが、関係者だけで何とかして、各ロールを全部自部署でやろうとします。そこで問題にいなるのが規格で書かれている独立性です。すべてを自部署で行うとなると、それなりの人が必要になります。

規格によればSIL4の開発に起業内で用意できるのは、Validatorまでで、Assesor は社外にもっていかなくてはなりません（Can be same Companyと書いてはあるけど）。PMとValidatorの関係はPMの配下にあるかですので、PMの下にもっていかなければいい。この時、問題になるのが、現在の組織との関係です。例えば上記の図で、PMを課長に担わせた場合、VALをやる人が課長配下の部下だったらどうでしょうか？　ふつうに考えれば、課長＝PM　＞係長VALなので認められないとなるケースを想定してしまいます。しかし、規格ではそこまで踏み込んではいません。あくまでもPMの配下にVALがいてはいけないと書かれているだけなので、この係長が本プロジェクトにかかわっていないなら、VALはできるはずです。また、違った見方として、この規定の本質は、PMの意向でVALの判断がゆがめられていけないという趣旨だから、課長は係長に強制力を持つのでこれは独立とは認められないという意見です。日本人の私から見ればわかりますが、欧米はJOB型であるので、こういうケースは想定していないのだろうと思います。これを言い始め得ると、社長ならなんでもできるだろ？となってしまします。このように、RAMS規格自体が文化の違いを含んでいるので、日本に定着しにくいという一面もあると思っています。じゃあ、どうすんねん？となった時には。ISAに訊くしかないです。ISAによって判断が異なるだろうと思います。私としては、規格がクライテリアなので、そのまま主張するべきと思います。そんなことどこにも書いてないよね？　と。。。　ただ、PMの意向でVALの判断がゆがめられないようにとの規格の趣旨は正しいと思っています。もし、VALが上記課長の指示で影響を及ぼすのなら、他部署に置くべきでしょう。もし、そんなことしないと係長なら今のままでよいと思います。たぶん、欧米は自己が強いので間違った圧力をはねのける文化が既にあるのでこんなことは問題にならないのでしょう。でも、日本はどうかなぁと思います。RAMS規格を知れば知るほど、文化の違いが知れて面白いです。

話を少し前に戻して、Asessorについてです。基本は企業外にお願いするのが良いとされているようです。しかし、このAsessorは規格では、下記のように書かれています。

セーフティオーソリティーの裁量によって、供給者組織か顧客組織から出す。ただし、Asessorは下位のようなものである。

• セーフティオーソリティーが認めたもの
• プロジェクトチームから独立しているもの

じゃあ、 safety authority ってなんだ？というと、

the body responsible for delivering the authorisation for the operation of the safety related system

だそうです。この実態は、各国の国家組織です。呼び方は色々ありますし、鉄道以外にも用意されています。RAMS規格全体に言えるのですが、この規格はライフサイクルで考えているので、GPやGAに適用するとそのまま読むのは難しいです。GPやGAはあくまでも製品ライフサイクルの一部にすぎません。だから、このケースの場合、GPやGAの開発にAsessorを用意するときに、いちいち safety authority にお伺いを立てたりレポートを提出するかというとしませんよね。では、どうするか、ですが、それは有名なISAにお願いするのです。規格の立て付けから言えば、GPやGAはSAから見たらブラックボックスなので、誰がAsessorをやってもいいはずですが、最終顧客に対してはGAやGPの安全性評価認証書を出すことが常だからです。この時、社内の人間や聞いたこともないISAの評価レポートだったら却下されるリスクがあります。なので、有名どころのISAにAsessorをお願いしましょう。

設計者はRAMSをやろうがやるまいが存在しているのでそこはいいでしょう。新たに追加しなくてはいけないのが、テスターです。最終出荷は当然テスターがテストをやるでしょうが、GAやGPになるとおろそかになっていないでしょうか？　結局設計確認だけで済ますことはRAMS規格には反します。検査部門に設計検証後の試験をお願いできれば良いのですが、出来ない場合はプロジェクト内でのクロス開発がいいです。つまり、設計者が二人いたら、それぞれのテストをお互いが行うということです。そんな人もいないとなれば外にテストを行う事もできます。そうすれば最小限で規格上の体制は満足できます。

次に問題になるのが、ドキュメント量の多さです。まずは、すべての活動のプランを作成しなければなりません。これがまた大変です。ここで、面倒になってRAMS担当者なるものを置くと、まず失敗します。なぜなら、設計者（プロジェクトチーム）は今までのプロセスで設計を行い。RAMS担当者になった人が一人で苦労した挙句に、設計者の活動とRAMSの活動が乖離して結局失敗に終わる。まあ、よくあることだと思います。RAMS規格を読んですべて把握しろと言われても設計者は大体はやる時間がありません。なので、RAMSをよく知った人に入ってもらうのは良いですが、彼がすることは指導・指示することで活動、活動そのものをやってはいけません。なので、規格にはありませんが、Safety ManagerとQuality Magerは用意したほうがいいです。Configuration Magerは無くても何とかなります。社内のドキュメント管理のルールをそのまま適用してください。

Safety Mangerはやることが多いのと、RAMSをよく知らないとできないので、担当者は限られてしまいます。なので、今後のことも考えると、プロジェクト横断で Safety Managerを置くのがあとあと効率がいいです。当然、だいぶ委託しても問題ありません。ただ、重要なのは Safety Manager はRAMSプロセスを知っているのはもちろんですが、設計やモノづくりの経験がないと、設計者はついてきません。ちなみに、これはISAにも言えることだと私思っていて、設計の経験がない人がISAのAsessorをやると得てしてまともな会話にはなりません。これは、また別途ISAの話でどこかで書きたいと思います。

具体的な設計の流れはどこかで書くつもりですが、基本は規格に書かれています。ただ、読むのは面倒くさいですよね。

先ほど、書きましたがRAMSはプラン系のドキュメントの作成量が膨大です。これを減らすためには、如何に共通項でプランを作るかと、如何に、社内規定に飛ばすかです。社内規定の多くはRAMS開発の多くを既に網羅しているので、社内規定を有効に使います。ただ、すべてを置き換えようとすると駄目ですよ。足りない部分はSafety Planの中でちゃんと書きましょう。