« 2013年9月26日 | トップページ | 2013年9月28日 »

2013年9月27日

2013年9月27日 (金)

日立製作所の工作員、自分でナニ言うとるんかワカランようになってもとるやないかwww

おーおー、日立製作所の、十代男性の勃起したチンコみたいにカチンカチンのオツムのアホの自称SEが出て来よったなあwww

------
ブログ「超ブラック企業・日立製作所から個人情報保護法違反され、公益通報したにもかかわらず懲戒解雇された大西秀宜(おーにっちゃん)のブログ」のエントリー「クラウドというたとえについて、ワタシのたとえは正しいやろがよ」に新しいコメントがつきました。

http://onicchan.cocolog-nifty.com/blog/2013/09/post-7be8.html#comment-101079943

 IPアドレス:     115.30.182.166
名前:
メールアドレス:
URL:

内容:
--------
大西くん

 お久しぶり。名無しですが ?

SaaSの事を言いたいの ?

君の言う事は「単純なデータ共有」としか思えないけど ?

もう一度、私と勉強しますか ?
------


オマエSaaSってちゃんと分かってないなあ。
いやワタシも検索して勉強したんやけど。

ワタシと勉強してみよか。

------
クラウドとSaaSの位置関係を解き明かす
http://www.itmedia.co.jp/enterprise/articles/0810/27/news008.html

•SaaS
 ベンダーが所有するアプリケーションを、ユーザーがネットワーク経由で利用するというアプリケーションの提供形態。カスタマイズの実現度やユーザービリティの高さ、マルチテナント技術の応用といった観点で、従来のASP(ソフトウェアの期間貸し)とは区別される。
------


ワタシが利用しとるのは、"ベンダーが所有するアプリケーション"に限っとるんだっけ?

2chとかココログとか、インターネット上の全体やろがよ?
データを保管するには、アプリケーションの利用だけでなくサーバの利用も必要になるし。

で、概念図を見たら

------
XaaSとクラウドの概念図
http://image.itmedia.co.jp/l/im/enterprise/articles/0810/27/l_sacra-01.jpg
------

どう見ても、ワタシがやっとるのはクラウドやろが。

オマエホンマにダイジョウブか?


まあ、オマエがいろいろ詭弁を弄して、XaaSや!って言い張る分にはええけど、ワタシがクラウドじゃ!って主張するのに対して、それは違う!と言い張るだけの理由を、オマエは持っとるワケちゃう。


・・・理由言えるもんならば言ってみな?

今日も公演ちょっとだけ観てきました

毎回ちょっとだけ。
今日はこれから、アホに反論したらなアカンし、泣く泣く早めに出てきました。

鏡の中のジャンヌ・ダルクと、Two years laterだけ観ました。


鏡の中のジャンヌ・ダルクは、茂木がまたビミョーに低い気がしました。
自分ではいいと思っていると思うのですが、もう少し高めが欲しいと私は思います。

ぽんみゆは、以前声が太くなったと書いたように思ったのですが、今日は細い気がしました。
そういえば昨日、一瞬ぽんみゆに見えたメンバーがいたのですが、他メンの空似かとそのままにしていたところ、今日になって、昨日もぽんみゆ出ていたと知りました。

美月は、背の高いぽんみゆよりも、さらに背が高いですね。
ひかりは、MC面白いのですが、パフォーマンスは元気からあと一皮剥けて欲しいと思います。

ゆーりんは、今日は特に指摘ありませんが、チーム4メンバーで萌とともに他チーム公演に出るのですから、運営の評価も高いことがわかります。


Two years laterは、最初、白いフードのメンバーの、フードがアタマにかかって、お化けみたいに見えていました。
こういうハプニングは好きです。
誰かはわかりませんでしたが。


"どんな顔で・・・" あたりをはじめ、この曲はみんな音程がちょっと低めな気がします。以前も指摘した気がしますが。

ダンスのタイミングはみんなだいたい合っていて、特に悪い意味で気になるメンバーはいませんでした。

ただやはり、以前の田野なり伊達娘のように、全体を見渡した上でも目を引くようなパフォーマンスができているかといえば、そうではないと思います。
これは、全員がよくやっているからでしょうか?

今週末にでも一度、なぁちゃんあたりを軸に、公演全体を観てチェックしてみたいと思います。

クラウドというたとえについて、ワタシのたとえは正しいやろがよ

山田秋波とかがなんか書いとるけどよ。

-----
大西秀宜の行く末を生暖かく見守るスレ5
http://anago.2ch.net/test/read.cgi/tubo/1378962209/l50


587 :最低人類0号:2013/09/26(木) 17:55:18.03 ID:2FksiyjhPクラウドの使い方も全然違う。
 大西はちくり裏事情で自分は大みかの頃はITのエキスパートやった!
と書いてたけど嘘をつくなよ。

588 :山田秋波:2013/09/26(木) 18:06:23.90 ID:BRFPiTsZ0>>587

同じ事思った。全くクラウドの意味を間違えてる。
 過去発言自動検索機能くらいにしておけば良いのに使い慣れないIT用語なんて使うから。
-----


で、ホンマにワタシの言うとるのがおかしいか?

-----
いまさら聞けないデジタル入門「クラウドって何ですか?」 2012/10/12掲載
https://flets.com/customer/column/465/465cl_01.html

パソコンのソフトの代わりに、インターネットのサーバーを使って作業ができて、作成したデータもインターネット上に保存。つまり、パソコンで行っていたことを、まるごとインターネットにまかせてしまおう、という利用形態です。

データをインターネットに保管することで、場所や端末の種類(パソコン、スマホ、タブレット端末など)を問わず、同じ情報にアクセスできる利便性です。
-----

ワタシが2ch上で実現しとるのって、クラウドそのものやないんか?

書き換えるぞ?

-----
おーにっちゃんのアタマの代わりに、インターネットの2chのアンチ達を使って作業ができて、作成したデータもインターネット上に保存。つまり、おーにっちゃんで行っていたことを、まるごとインターネットにまかせてしまおう、という利用形態です。

データをインターネットに保管することで、場所や端末の種類(おーにっちゃん、アンチ、日立製作所の工作員など)を問わず、同じ情報にアクセスできる利便性です。
-----

・・・なんかおかしいか?


オマエらが勝手に、リアルなサーバとかなんとか、自分がこれまでに扱ったものだけを想像して、それに当てはまらんからって、いちいち文句を言うなよ。

もっと想像の翼を広げて、ものごとを大局的に捉えろよな。

 

また、Wikipediaを読んだら

-----
クラウドコンピューティング
http://ja.wikipedia.org/wiki/%E3%82%AF%E3%83%A9%E3%82%A6%E3%83%89%E3%82%B3%E3%83%B3%E3%83%94%E3%83%A5%E3%83%BC%E3%83%86%E3%82%A3%E3%83%B3%E3%82%B0

クラウドコンピューティングの定義には、アメリカ国立標準技術研究所 (NIST) による以下のものがある。

クラウドコンピューティングとは、ネットワーク、サーバー、ストレージ、アプリケーション、サービスなどの構成可能なコンピューティングリソースの共用プールに対して、便利かつオンデマンドにアクセスでき、最小の管理労力またはサービスプロバイダ間の相互動作によって迅速に提供され利用できるという、モデルのひとつである。このクラウドモデルは可用性を促進し、5つの基本特性と、3つのサービスモデルと、4つの配置モデルによって構成される[1]。
-----

こんなんもあるなあ。


なんか一見小難しいコトを言うとるように思えるけど、いまさら聞けないデジタル入門と同じコトを専門用語で言うとるだけやないんか?

 

なんか文句ある?

ちゃうかったらどこがちゃうのか説明してみ?

【再掲】日立製作所社員に対する "ゆすり" のご提案について

コレは一週間に一回くらいアップして、啓蒙せなアカンなあ。

ーーーーー

拝啓

日本全国におられます、一般市民の皆様へ。

はじめまして。大西秀宜(おおにしひでのぶ)と申します。

私は、日立製作所から、個人情報保護法違反に端を発するさまざまな嫌がらせを受けております。
このブログで繰り返し取り上げておりますので、ブログの記事をご覧になれば分かるでしょう。

日立製作所は、いや警察も、いや日本政府さえ、取り扱おうとはしません。
経済産業省は、私が出した公益通報を黙殺しましたし。

しかし、皆さんのネットワークを駆使すれば、きっと日本じゅうにこの件を広めることができ、問題にできると考えています。
インターネット上に日立製作所の者と思しき人間が、組織的に、何百回も執拗に書き込んでいることなど、スキャンダルに違いありません。

・・・と、私が言いましても、皆様は、

「地獄の沙汰も金次第、見ず知らずのお前に対して、どうしてトクにもならぬことをせねばならぬのか」

と仰るでしょう。

そう思いまして、では、皆様のトクになる方法を考えてみました。

たとえば、日立製作所の部長以上クラスで、ちょっとご存知の方がおられたら、その方に対して私のブログを印刷して見せ、

「五百万円もらえなければ、この事実を自分が知っている範囲にバラまくぞ!」

と言ってみてはいかがでしょうか?

その日立製作所員は、警察に相談することはできないはずで、しぶしぶ工面してくると思います。
この提案は成功する確率が高いと思います。

皆様にやっていただきたいのは、それだけです。

全国津々浦々の、一般市民の皆様が日立製作所をゆすったとしたら、いずれ日立製作所は使途不明金が溢れて、崩壊すると考えます。

とはいえ、日立製作所は、いくら揺すられていようが、警察に相談して皆様を逮捕することはできないのです。
といいますのも、私の件は明らかにJISQ15001プライバシーマーク違反であり、プライバシーマークが1年以上に渡って剥奪され、その結果、年間10兆円もの売り上げが吹っ飛ぶからです。

まんいち警察が来たとしても、事情を話せば、ハレーションが及ぶ範囲が大きすぎるとして、火中の栗を拾うのを嫌って釈放されるはずです。

いや、日立製作所も、用心棒を雇ってくるかも知れません。
しかし、皆様方がしれっと用心棒になる手だってありますし、用心棒を見つけ出してグルになって、用心棒代を釣り上げることだって不可能ではないと思います。

荒唐無稽な、と思われるかも知れませんが、どうしても金策に困られたときにでも、大西の書き込みを思い出してみてくださればと思います。

以上です。

なにとぞご検討のほど、よろしくお願いします。

敬具

2013年9月24日 大西秀宜

P.S.
このご提案は、西村京太郎「怒りの北陸本線」を読んで、着想を得ました。

【再々掲】もはや技術のない日立製作所

昨年、Yahoo!ファイナンスに書いた記事です。
一部修正しています。


日立製作所は、顧客ではなく重役の方を向いて仕事をしており、重役のための技術になっている。

技術とは本来、顧客のためにあるべき。
そしてその先には、本来あるべき最適解があるべき。

それを忘れてしまった日立製作所は、もはや技術の日立とは言えない。


一例を挙げよう。

交通カンパニーの研究予算討論において、交通カンパニーの技師長・CTOらが
一堂に会して議論していた。

その中で、台車の故障検知がやりたいので、台車に音波検知器を設けて行う方法を検討しているとのことであった。

ワタシは、ストーリーが良くないなあと引っかかった。

数日後、業界の発表会で、台車の故障検知を地上装置から行う方法を、住友金属や、東大の須田先生が研究されていると知った。
http://www.nozomi.iis.u-tokyo.ac.jp/iis2012/iis2012_SafetyRailway.pdf

瞬時に、コレだ!と思った。
地上装置であれば、一路線に数カ所の設置で済む。装置故障のチェックも容易だ。
車上装置であれば、全車両の台車2カ所ずつに取り付ける必要がある。
この台車は検知可能ですが、これは検知しません、では困るから。

もし車上装置とすると、例えば山手線であれば、52編成×11両×2台車=1,144個の装置を設置することとなり、日立製作所側の、取らぬ狸の皮算用としては素晴らしい需要であるが、顧客としてはとても採算に乗らないと感じた。

そこで、上司Y主管技師に相談したが、アホの言うことと無視した。
当時CTOの川端敦(元機械研究所長)にメールしたが、職制を飛び越して言うな!と相手にされなかった。

しかしどうしても納得行かず、技師長の岩滝雅人(元笠戸工場長)に相談したところ、リーズナブルな解として理解いただいた。
但し、住友金属殿と共同研究となると、住友金属殿が難色を示すだろう、とのコメントもいただいた。

何日かして、Y主管技師は、なんの疑問も持つことなく、相変わらず車上側からの台車の検知方法の予算取り作業を黙々とこなしていた。


求めるものを明確にイメージできれば、岩滝の解に結びついたはずである。

しかし、上司Y、それどころか、機械研究所長や交通CTOを歴任した川端敦でさえ、職制に捕らわれるばかりで、求めるものを全くイメージできていなかった。


このような者が権限を握っている日立製作所の技術、それは本当に顧客が求めているものと思うだろうか?

【再掲】プロジェクト管理(鉄道RAMS,自動車ISO26262)のエッセンス資料 (私の日立製作所での最後の成果物)

日立製作所のアホ共には、ワカランかった資料や。
たまには掘りかえしてみななあ。

ーーーーー

大前提 日本国憲法
第十二条 この憲法が国民に保障する自由及び権利は、国民の不断の努力によつて、これを保持しなければならない。又、国民は、これを濫用してはならないのであつて、常に公共の福祉のためにこれを利用する責任を負ふ。
憲法には,”自由及び権利は、国民の不断の努力によつて、これを保持しなければならない。”という一文がある。
働いていない人であっても,”不断の努力によって”保持するべきものがあるのであるから,プロジェクトを任された者においては,プロジェクトとして,”不断の努力によって”保持すべきものも必ず存在する。
日本国憲法を大前提として,プロジェクト憲法を以下のように決める。
第一条 リーダー及びメンバーが,プロジェクト内にて問題点を発見ないし申告した場合,問題点を改善することこそが目的である。
この原則に立ち返り,問題点を発見ないし申告したこと自体について叱責が生じることはない(法律違反を除く)。叱責が生じた場合,叱責を働いた人物こそが処分の対象となり得る。
第二条 リーダーは,自ら主体的に,プロジェクトに存在する問題点を発見する不断の努力を払う義務を持ち,問題点に対する全責任を持つ。
メンバーが問題点を申告しなかったことを理由に,メンバーを叱責する権限は持たない。メンバーが問題点を申告できない状態を認知できなかったこと,申告できない雰囲気を作ったことこそがリーダーの責任である。責任の所在に伴い,リーダー自身が処罰の対象となり得る。
第三条 リーダーは,メンバーの思考及び遂行について不断の努力によって尊重し,褒める義務を持ち,同時に,メンバーから学ぶ義務を持つ。メンバーは,自分の思考及び遂行について,リーダーにより認められる権利を持つ。
リーダー自身が実行可能なソリューションを,メンバーに押し付けるようなことがあってはならない。メンバーの得手不得手を理解し,メンバーに合ったソリューションを一緒に考えることのほうが先決である。
第四条 プロジェクト参加者は,最低1日1回,PDCAチェックを実施する。プロジェクトが大きい場合は,サブプロジェクトに分割することが可能である。
この場合,サブプロジェクトの全員が集まって行うPDCAチェックを実施し,プロジェクトリーダーは,最低限サブプロジェクトリーダー全員を集めたPDCAチェックを実施する。これは,プロジェクトリーダーが,末端の問題を吸い上げることを目的とする。
リーダーについてもPDCAチェックを行い,メンバーに対して手本を示す義務がある。
第五条 プロジェクト参加者は,Web上にて構築したシステムにアクセスし,成果物をアップロードする。また自分の置かれた状況に対して可能な限り記載する。リーダーは,メンバー全員の進捗において確認する義務を持つ。メンバー自身も,なるべく多くのメンバーの進捗を確認したほうが良い。
1.リーダーに関する規定
まず,リーダーは,学校における先生に相当する役割との認識を持たなければならない。
学校の先生であれば,例えば40人クラスにいれば,その40人全員の進捗を把握し,パフォーマンスを改善する義務を負う。
陥りやすい過ちとして,できるメンバーだけ伸ばせばよいのではないことに注意すべきである。リーダーが本当に考慮すべきは,できないメンバーのパフォーマンスをいかにして改善するかである。そして,できないメンバーのパフォーマンスを改善するノウハウこそが,組織全体を活性化させることはもとより,リーダーにとって次回からも生かせるノウハウとなるのである。
検討項目
・PDCAチェック(毎日実施。例えば始業前に計画をたて,退勤前に反省を行うのが良い。できれば全体で行う。)
1.メンバーの作業内容の把握。(重複部分,抜け,技量の巧拙などの把握。)
2.このメンバーであれば1日にてどこまでできるはずか,の想定と結果確認。
3.Web上にて,任意にメンバーの状況の確認。特に不調のメンバーに関して重点的な確認。
4.プロジェクト全体において,仕様書などの検討抜けのチェック。
5.不断の努力によつて,日本国憲法第十二条を守る。
6.プロジェクト憲法が守られているかの相互チェックを行う。
もし,リーダー1人では,”1日にてどこまでできるはず”という想定ができないほどにプロジェクトが大きい場合は,サブリーダーを設定してもよい。この場合,リーダーはサブリーダーを管理し,毎日のPDCAサイクルを回せるようにする。
例えば,始業直後/終業直前に,サブリーサー主催のPDCAチェックミーティングを行う場合は,リーダー主催のサブリーダー会議をそれぞれその後に行い,リーダーが全員の持つ問題点を的確に把握できるようにする。
サブリーダーの分割は,”このメンバーの力量と気力と体調ならば,1日にてどこまでできるはず”と想定できる単位になるまで,これを繰り返す。
但し,間違えてはならないのは,あくまでプロジェクトの全権者はリーダーということである。リーダーは,”このメンバーの力量と気力と体調ならば,1日にてどこまでできるはず”とまでは把握できずとも,頻繁かつ公平にメンバーと会話を行い,特に不調なメンバー及び若い/経験の浅いメンバーについて進捗/状態を把握する義務がある。この補助として,Webシステムを積極的に活用する義務を持つ。
リーダーは,プロジェクトのメンバーの進捗が把握できなくなった時点で,不断の努力によって保持すべき義務を果たしていないと看做される。
リーダーの上位上長は,やはり”不断の努力によって”リーダーと頻繁にコンタクトを取り,リーダーがメンバーの進捗が把握できなくなったと判断した時点で,リーダーに対して指導し,指導しても改善が認められない場合は,更迭を行うべきである。
メンバーが考えてきた意見に関して,違うからと怒ったり叱ったりするリーダーがいるが,絶対に叱ってはいけない。自分で考えるメンバーはなかなかいない。
それにも関わらず,メンバーは自分で考えてきたのである。その意見は尊重する義務が,リーダーには存在する。
仮にメンバーの意見がリーダーの意見と違っているとしても,リーダーの意見が100点で,メンバーの意見が0点ということは有りえない。
点数で表せば,例えば,リーダーの意見が80点で,メンバーの意見が40点なのである。
ひょっとすると,リーダーの意見が40点で,メンバーの意見が80点であり,リーダーが理解できていない可能性さえある。
リーダーは,メンバーがこの40点を取れた部分をしっかり評価した上で,どこをどう伸ばせば,自分にアイデアのある残りの40点が改善できるか,メンバーの能力や指向,得意なものなどを考慮に入れ,メンバーの気持ちに立って説明すべきである。そうすることにより,メンバーは40点の部分については自信を持ち,次回は40点以上の成果が出せる。
ここで叱ってしまえば,メンバーは0点からの出発となり,折角芽生えつつあった40点分の自信を喪失してしまう。仮にリーダーの指導により,このメンバーが今回は80点の成果を出せるとしても,このメンバーの身につき,次回に生かせるのは10点程度である。
すなわち,40点を認め伸ばすほうが,メンバーを育て,次回以降のパフォーマンスを改善することに貢献するのである。
リーダーは,メンバーを自分の意見どおりに変えようとするのではなく,メンバーの得手に合わせるよう,リーダーが主体的に”不断の努力によって”,メンバー個々に合わせたソリューションを考え出すべきである。
リーダーにしかできないソリューションを,メンバーに押し付けるようなリーダーがいるのであれば,本件はプロジェクト憲法第三条に反する。そのリーダーは,メンバーによりリーダーの上位上長に申告され,改善を要望される。改善が行われない場合,糾弾,または更迭の可能性を負う。
システムとしては,リーダーの意見に従わせることが必要なことも多いが,可能な限り,”不断の努力によって”,リーダーの意見でさえも一例として提示するにとどめ,メンバーにリーダーの案を下地として,さらに新たな案を考えられるように仕向ける方が良い。
これは,メンバーがノウハウを蓄積することにより成長を促進し,その結果,当該メンバーの急激なパフォーマンス向上が期待できるためである。
若い/経験の浅いメンバーには,リーダー自らがとりわけ気をかけるべきである。経験の浅いメンバーに教育を任せてしまう,或いは若い/経験の浅いメンバーは放っておき,自力での向上に期待するのは間違いである。これは,若い/経験の浅いメンバーを頑張って戦力にした方が,プロジェクトトータルの戦力が早急に向上し,結束力が高まるからである。また,リーダー自身が率先して若い/経験の浅いメンバーを教えることは,リーダー自身の能力,とりわけ理解力および説得力の向上に役立つことを,リーダーは認識するべきである。
そして,若いメンバーが頑張りを見せ,プロジェクトに新たな考えを吹き込むことこそが,プロジェクトを最も活性化することを,リーダーは認識するべきである。
なお,Webシステムからログを取得することにより,エビデンス資料は自動的に保管される。
以上の内容をリーダーが実行できているとすれば,鉄道版RAMSであろうが自動車版ISO26262であろうが,どこにどの資料を作成したか,どこの資料が規格の何に当たるか,監査時にはリーダー自身が説明できるはずである。
リーダー自身が説明できないのであれば,リーダーがプロジェクトを十分把握していない。
これはプロジェクト憲法第二条及び第四条に違反する。
2.メンバーに関する規定
・PDCAチェック(毎日実施。例えば始業前に計画をたて,退勤前に反省を行うのが良い。できれば全体で行う。)
1.担当範囲内における作業の実施。
2.問題点の報告と,それに併せた自分の考えの主張。
3.他のメンバーとの悩みや検討事項の共有(ノウハウの共有),改善点の検討。
4.不断の努力によつて,日本国憲法第十二条を守る。
5.プロジェクト憲法が守られているかの相互チェックを行う。
PDCAチェックにより,プロジェクト全員の成果物の進捗管理を毎日行う。
Web上のシステムにて,プロジェクト全員が任意の時間に状況を報告し,確認する。
メンバー同士が直接出会って会話をする,または電話やメールなどは補助の手段とすること,これらはもちろん推奨されるべきことではあるが,あくまで正となる情報はWebに置き,全員が任意に確認できることを基本とする。
【プロジェクト開始の前提】
計画ドキュメントを作成し,その正確性が重要との認識があるが,これは誤りである。
例えば,体重4000gで元気に生まれた子供だけがすくすくと育ち,2000gで瀕死の状態で生まれた子供の人生が一生不遇なものかといえば,全くそうではないことを考えれば明らかである。
本当に必要なのは,しっかりした計画ドキュメントなどではない。
毎日毎日不断の努力によって繰り返す,PDCAサイクルの繰り返しである。
仮に,1000人必要なプロジェクトがあったが,いいかげんに10人として見積もっていたとしよう。
10人としても,毎日毎日不断の努力によってPDCAサイクルをまわしていけば,1週間もすれば800人くらい必要な予想まではつくはずである。
PDCAサイクルを回すということは,正解に漸近していくということでもある。
これは,例えば頻繁な利用を経て,ソフトが枯れていくことや,新形式のメンテナンス手法が確立してくることなどからも容易に理解可能と思われる。
すなわち,計画は極論すればめちゃくちゃでもいいのである。
毎日毎日PDCAでチェックすることこそが大切なのである。
然るに,例えばあるプロジェクトでは,リーダーを,他プロジェクトも兼任している本部長として,PDCAのチェックポイントを1ヶ月とした。
このため,PDCAのチェックポイントにおいて,リーダーがメンバーを気遣うべきはずのところ,メンバーからリーダーへの説明の場と化してしまった。さらにリーダーがその結果に対してメンバーに対して叱責を行ったため,なんのためのPDCAチェックかが分からなくなってしまった。不要な資料の作成が増え,メンバーの不満も高まった。
これは,いまから考えれば,時間の無駄遣いである。
それが想像できなかった,リーダーこそが失格である。
本資料によれば,プロジェクト憲法第一条~第四条全条違反である。
このようなプロジェクトは今後二度とつくらないように,リーダー,メンバーともに肝に銘じなければならない。
リーダーが検討すべき事項は以下のような項目と想定される。
リーダーがプロジェクト憲法を守っていれば,特段難しいこととは思えない。
あとは,リーダーが適当にやってみて,PDCAサイクルを1ヶ月くらい回し続けて,自分から主体的に発見すること。
1.最初に決めないといけないものは,そのシステムの機能仕様である。
2.仕様が決まると,その製作に必要な機器構成,技術が決まる。
3.機器構成が決まると,仕様書の体系が決まる。
4.仕様書の体系に合わせて工程が決まる。
5.工程のパスが決まると,人員が決まる。
6.上記計画により,具体的に製作を行う。
1.の段階にて,システムに必要とされる機能,性能,全体寸法などが決まる。
2.の段階にて,システムに必要な構成に対して安全性を配分する。
→安全性の洗い出し,SILの同定
Safety Plan の作成
Systematic Fault への検討
3.の段階で,ハード,ソフトの仕様書体系が決まる。
6.が完成した段階で,Safety Case が完成
品質管理活動,安全管理活動は,一般的なもので良いと思われる。
下記よりファイル形式をダウンロードできます
https://docs.google.com/document/d/1Qc9UuJvIpkZrxv1dNfRgv9ZcOrS75pjfJp3n1ddiITA/edit?usp=sharing

« 2013年9月26日 | トップページ | 2013年9月28日 »

2017年6月
        1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30  

カテゴリー

最近のトラックバック