福島第一原発事故の危険性をHAZOP／FMECAで導出する その５ ＦＭＥＣＡの後

今まで書いてきた

福島第一原発事故の危険性をHAZOP／FMECAで導出する

に、いちおう決着をつけてみたいと思います。

で、いままで、
手順としては、以下のとおり

　　　・抽象的なものが出てきた場合、まず、それらの構成要素を考える
　　　・それをインスタンス化(具体化）する
　　　・それらの具体物の問題点をHAZOPを使って考える
　　　・そこで挙がった問題点を、FMECAで評価する
　　　・その結果、問題となった事項を、どうするか、ゴールを考える
　　　・ゴール指向の図にまとめる

前回、ＦＭＥＣＡについて
　そのアイテムの機能を考え、
　その機能から起こる障害を、ガイドワードで抽出する（これがＨＡＺＯＰ）
　そして起こる影響を確認し（ＦＭＥＡ）
　発生確率を考え、致命度を計算する（ＦＭＥＣＡ）
というところまで書きました。

---

■ＦＭＥＡ、ＦＭＥＣＡの問題点

　実際のダメージは、致命度によってきまるので、致命度をもとめないといけません。
　それには、発生確率を求めないといけません。

　ところが、今回の津波のようなものは発生頻度がわかりません。
　千年に１度か、１万年に１度か・・・
　千年と、１万年では、致命度が、１０倍も違ってしまいます。

　このように、ＦＭＥＣＡの枠組みでは、頻度がわからないものは、扱いが不適当に成る
可能性があります。まあ、ＦＭＥＡで影響大なら、致命度を考えないで対応してもいいけど・・

---

■ＦＭＥＣＡ→ゴール指向まで

　あとは、致命度が高い事項をまとめて、

　　　・その結果、問題となった事項を、どうするか、ゴールを考える
　　　・ゴール指向の図にまとめる

　という形で話は進んでいきますが・・
　まとまんないかもしれません。てんでんばらばらの原因がでてきそうです。

---

■ＦＴＡとＦＭＥＡ（ＦＭＥＣＡ）両方必要

　つまり、ゴール指向は、ＦＴＡに近いわけですけど、このやり方では、トップダウン
に考えていくので、想定できない危険は、管理できない。

　一方、ＦＭＥＡは、HAZOPをガイドワードに使えば、構成部品ごとで、ある程度のリスクは
はじける。これはボトムアップの利点だけど、
　構成部品同士が複雑に絡み合うのまで抽出できるかというと。。。微妙。
　こういうのは、トップダウンが得意。

　まあ、両方必要なわけで、片一方だと、見抜けないリスクというのが出てくるってのが
現実なのかな（両方やっても見抜けないものもあるけど・・）

---

　あと、この話、工程表について書いて、おわりになる。

プロジェクトのやばさを測るのに、ＩＳＯ／ＩＥＣ２９１１０はいいかも？

前に、

小規模組織におけるシステム開発のプロセス改善 IS0/IEC29110とVSEを聞いてきた
http://blog.goo.ne.jp/xmldtp/e/278ec70ca7cec96b0da48eebc6ce9311

って言うのを書いたけど、そのＩＳＯ／ＩＥＣ２９１１０や、
ＶＳＥセンターが出しているチェックシートをどう使うのかっていう話。

そのとき（上記「聞いてきた」とき）の話では、「ＰＭＯなんかが使うのにいいんじゃない？」という話になった。

それと、プロジェクトのリポジトリにはいって、
いろいろ確認できるという話もあった。

ってことで、チェックシート片手に、リポジトリにはいって、
プロジェクトのやばさを測るのに、ＩＳＯ／ＩＥＣ２９１１０やＶＳＥはいいかも？

日立がWiMAXを使うかどうか、だと思う。スマートシティでの世界制覇は！

さっきやってたNHKスペシャルの

新エネルギー覇権争奪戦
～日本企業の闘い～
http://www.nhk.or.jp/special/onair/110821.html

まるで、日立の宣伝番組みたいでしたね！
あした（もう、今日か・・・）の日立の株価は？？

それはちょっと置いておいて、
スマートシティについてやってたけど、
みんなあ、スマートシティのことは、地震も、かんがえようよ！
ITでコントロールったって、線を使うとなったら、
地震のときは、線がきれちゃうよ！
ここはWiMAX使って、無線でコントロールでしょ！

スマートシティのメリットは、地震とか起こったとき、
地域内で電気を融通したりすることができることが
あげられる。東京電力からの電気が切れても、自治体の
太陽光発電でまかなえるとか・・・

　とすると、通信も、地域内だけでもつながる仕組みが
ほしいわけだ。そうすると、WiMAXとかWiFiとかに
なってくるんじゃないかしら。

また、山奥とか、苛酷な環境だと、有線よりも無線のほうが
楽だしね・・・

無線はやっぱ、日本が得意だろうから、
日立がWiMAXを使ったら、スマートシティでは世界制覇かなあ・・？

P.S　スマートシティの考えにある、電力会社には頼らない！という発想は、
被災地以外の日本でも大事な考えで、自治体は検討したほうがいいと思う。
　たとえば、大阪、関西電力には頼らない！と、自前で対応しておかないと、
今年は乗り切れても、来年は・・・

　・・・いや、東京電力エリアも、人事じゃないけどね。
　ことしは、もういけそうでも、来年は・・・？

　そういう意味では、日立・東芝をはじめとするスマートグリッドの会社に
商機はあるのよね・・・

Microsoft開発のTwitterドレスがとても素敵！

ここ

Mcrosoft開発のTwitterドレスがとても素敵！
http://news.livedoor.com/article/detail/5799523/

によると(以下斜体は上記サイトより引用）

ファッションxサイエンスは最近流行のトピックのようですが、このMicrosoftのドレスはピカイチ！　ペーパーTwitterドレス、ですって。コルセットキーボードとよばれるものを使い、ツイートをこの半透明な白いスカート投影することができるそうです。ちなみにこのスカート、ほとんど紙で作られています。ツイートを投影しない方がオシャレな気がするんですけど、まぁいいです。

だそうな。
Microsoftって、そんなこともやってるんだ・・・

AMラジオの周波数を合計すると、たいてい１８になる理由

ここ
http://img.pics.livedoor.com/011/3/3/33950b973b6757e15a99-1024.jpg


NHK第一　５９４＝５＋９＋４＝１８
NHK第二　６９３＝６＋９＋３＝１８
TBS　　　９５４＝９＋５＋４＝１８
文化放送１１３４＝１１＋３＋４＝１８
ニッポン放送１２４２＝１２＋４＋２＝１８
ラジオ日本　１４２２＝１４＋２＋２＝１８
いーぐる８１０　８１０＝８＋１０＝１８

---

理由

周波数を

a*100+b*10+cとおく（ここで、ｂ、ｃは、０以上９以下）
中波って、５２０KHzくらいから、１６００KHzくらいまでなので、
aは５以上１６以下。

かつ、中波の割り当ては、９KHｚづつで、９の倍数を割り当てることになっている。
ってことで、以下の式が成り立つ

a*100+b*10+c=9d
（ｄは整数）

=a*(99+1)+b(9+1)+c
=a*99+a+9b+b+c
=9(11a+b) + a + b+ c=9d

9(11a+b)はかならず、９の倍数なので、のこりの
a+b+cも、９の倍数でないと、９でわりきれない。


ここで、a+b+c=９となるケースは、５２０KHｚ以上だと、とてもすくない。
５４０、６３０、６２１、６１２、６０３、７０２、７２０、７１１、８１０、８０１くらいかな。
２７にするのもたいへん。９９９、１０９８、１１８６、・・・など、ごく少数。

なので、かなり多くの周波数は、１８で割り切れる形になる・・・

---

じつは・・・

１８にするため、ちょんぼしてる。

えーぐる８１０は、ほんとうなら、８＋１＋０で９になるはずだけど、全部１８にあわせたいので、わざと８＋１０と、他とはちがう分け方にしている。

小規模組織におけるシステム開発のプロセス改善 IS0/IEC29110とVSEを聞いてきた

昨日、小規模組織におけるシステム開発のプロセス改善の話を聞いてきた。

システム開発のプロセス改善というとＣＭＭとかＳＰＩＣＥ（ISO/IEC15504)とかあるけど、
あれらは、２５人以下の小規模零細企業？には、ちと、話がでかすぎる。

そこで、そんなあなたのために、小規模組織（大組織でも、プロジェクトはちっちゃいっていうのでもＯＫ！）のためのプロセス改善手法ってのが、IS0/IEC29110らしい。

　で、それを、日本語化したり、日本において、普及させようとしているのが、

ＶＳＥセンター
http://www.vse.jp/

のようだ。そのサイトの資料ダウンロードにいくとISO/IEC29110ガイドラインとして、「VSE標準の手引（図解）」なんていうのが、ダウンロードできたりします。そこにＩＳＯ／ＩＥＣ１２２０７との関係とかが、書いてあるみたい。

（＊ちなみに、ＩＳＯ／ＩＥＣ１２２０７（ＪＩＳＸ０１６０）と共通フレーム２００７、ISO/IEC 15288（JIS X 0170）との関係については、ここが詳しい）

　で、きのうは、ＶＳＥ標準を適用した話を、ＥｕｒｏＳＰＩで発表してきた竹内さんから、お話をきいてきた！

　あ、そうそう、プロセス改善活動っていうと、ＩＰＡのSPINA3CH（３を肩つきにしてね！すぴなっちっていうらしい。SPINACHと書くことも）とかもあり、ここ


プロセス改善活動についての新たな手法とその適用のためのツール類を公開
http://sec.ipa.go.jp/reports/20110707.html

にツールとかもあるけど、あれとのちがいは、IS0/IEC29110はモデルを考えているけど、SPINACHはそうではない？らしい。くわしくわからん。まちがってたらごめん。

　それと、ＩＰＡはSPINACH以外にも、

ソフトウェアプロセスの供給者能力判定及びアセスメントキット－IPA版(SPEAK IPA版)
http://sec.ipa.go.jp/reports/20070926.html

とかもあるけど、それとの関係は・・・（＾＾；）
説明できん・・・

8月18日(木)のつぶやき

11:47 from goo
Google Puzzle、やった？ #goo_xmldtp http://t.co/Xu0qajJ
by xmldtp on Twitter

Run Oracle Applications on Amazon EC2 Now

ここのブログ

Run Oracle Applications on Amazon EC2 Now
http://aws.typepad.com/aws/2011/08/run-more-oracle-applications-on-amazon-ec2-now.html

より。

ＡＷＳって、OracleのＥＲＰ
Oracle E-Business Suite
Oracle JD Edwards Enterprise One
や、ＣＲＭの
Oracle Siebel Industry Applications
なんかも動くんですね・・・

くわしくは

Oracle and AWS
http://aws.amazon.com/solutions/global-solution-providers/oracle/

ってことらしい・・・

Google Puzzle、やった？

ここ

Google、HTML5やCSS3など最新Web技術を使った無料パズルを公開
http://itpro.nikkeibp.co.jp/article/NEWS/20110817/365481/

に書いてある、The Google Puzzleやった？

やってない人に・・・

The Google Puzzle
http://www.thegooglepuzzle.com/

にパズルがあるけど、
・Chromeじゃないと、やりにくいかも・・・
・途中で音が出るよ！

最後が難しい・・・
ぱずるの鍵？見たいなのをつかって、「はしをかける」が出てきた後。
はしをかけるところ。
bridgeをどこにいれるのか・・・（いや、oのあいだだけど、どこのo?）

そうすると、ぽぽぽぽーんとなる。

ま、やってみてくらはい。

形式仕様の限界

　書いたっけ？ま、一応書いておく

　形式仕様には、形式仕様記述とモデル検査が大きく分けるとある。

　形式仕様記述は、自動証明とか使うと、正確さの面では、完璧に見えるかもしれない。
　たしかに、機能要件的には完璧になるかもしれないが、自動証明は、数学的に証明できないものには、効果はない。

　たとえば、足し算の性質が成り立つ、つまり１＋１＝２に必ず成ってくれるのであれば、足し算に関する証明はできるかもしれない。しかし、前提部分が成立しない、１＋１＝１に成ってしまうような、並列処理で排他制御してないような状況で、証明が成り立ったからって、かならずしも、全ての状況で正確な答えを出すとは限らない。

　また、停止性の問題がある。停止しないものは証明できない。デッドロックになったり、無限ループを起こす証明は出来ない。

　つまり、演繹的に正当性を証明する、形式仕様記述には限界がある。

---

　このような点を補完するものに、モデル検査がある。モデル検査は、しらみつぶしにケースをつぶしていく。帰納的に正当性を証明するかんじ。

　これなら、たとえば、ＳＰＩＮでデッドロックを示したりすることは出来る。排他制御などの検証もできる。ＬＴＬ式で記述できるような内容は、確かめられる。
　時間的なものは苦手だけど、それは、Uppaalだとできる。

　ということで、性能とか、非機能要件の一部は、モデル検査でできる。

---

　しかし、これらは、シミュレーションをするに過ぎない。シミュレーションは、調べたい概念について調べるのであって、想定の範囲外のものについて、調査はできない。
　それらは、実機でテストするしかない。

　ということで、形式仕様記述、モデル検査、実機テストすべて必要になる。

　

画像自体をBase64エンコードしてHTML内に埋め込み

DB自体に画像を入れてしまっているときとか、
画像をそのままHTMLに埋め込みたいときって
ありませんか？

こーやるんだあ・・・めもめも

画像自体をBase64エンコードしてHTML内に埋め込んで高速化するPHPコード例
http://phpspot.org/blog/archives/2010/11/base64htmlphp.html

PHP以外でも、参考になるとおもう。
IMGタグのSRCでの書き方・・・

Google、モトローラ・モビリティを買収へ

って、さわいでるので、なんか書かないといけないっすかね・・・
といっても、あんまり所感は、なかったりする。
いまひとつ、日本における直接的な影響が見えないせいかな・・？


更新：Google、モトローラ・モビリティを買収へ。総額125億ドル
http://japanese.engadget.com/2011/08/15/google-motorola/

中国版偽iphone5って、見た？手机QQって、何？

ところで、みなさん、中国版の偽？iPhone5って、見ました？

ここ

Fake Chinese Made iPhone 5 (4 pics)
http://izismile.com/2011/08/04/fake_chinese_made_iphone_5_4_pics.html

に写真があって（ちなみに、仕事中には不謹慎の写真もあるので、下のほうがいいかも？）

さらに、中国語なんだけど、ここに

くわしく写真が載っている。

抢先于IPHONE5 山寨版iphone5腾空出世！！！
http://www.shanzhaiji.com/newmobile/201107/28-12922.html

画面の様子まで。

ところで、最後の「手机QQ」って、何？
なにこれかわいい状態なんだけど・・・

今の最強の開発環境はGit＋Redmine＋Jenkins（旧Hudson）なの？

ここ

本当はすごい codefirst の開発環境
http://d.hatena.ne.jp/suer/20110620/codefirst_dev

(以下斜体は上記サイトより引用）


近代的なソフトウェア開発に必要なツールは3つある。

分散バージョン管理ツール
ITS
CI ツール
私はこれに AsakusaSatellite (以下AS)を加えたいと思う。




分散バージョン管理ツールは、Gitだよねえ、やっぱ。

ＩＴＳ（課題追跡システム）は、Redmineかtrac？

CIツールは、Jenkins（旧Hudson）だよねえ・・・

まあ、 AsakusaSatelliteは置いておいて（＾＾；）

マーケット戦略における統計利用（３）消費者セグメンテーション

　マーケット戦略について、前回は、製品の分類（市場の規定）について書いた。
　今回は、市場を形成する、もうひとつの因子、消費者を分類することを考える。

　消費者を分類することは、消費者セグメンテーションという（実際には、市場細分化ってこと）。

　消費者を全て等質と考えると（経済学のように）、ちょっとパイが大きすぎ、乱暴になってしまう。
　かといって、一人ひとりの個人に分け、ワンツーワンマーケティングとかいいだすと、今度は、細かくしすぎて、扱うのが大変になる。そこで、ある程度のグルーピングをすることになる。

---

■消費者特性データによるグルーピング

　マーケティングの最終目標は、お金が儲かることであって、そのためのグルーピングだから、べつに、コンピューターなんか使わなくってもかまわない。有効なグループわけが出来るのならば・・

　実際に、地域とか、性別、年齢によるマーケット分類とかはやられていて、
　視聴率でも、性別と年齢を使って、Ｆ１，Ｆ２、Ｆ３などに分かれている。

　まあ、これは、簡単に出来るけど、消費行動には、関係ないかもしれない。

---

■消費行動データによるグルーピング

　一方、消費行動データによるグルーピングもある。
　ポイントカード導入により、購買履歴が容易に入手でき、どんどんたまっていくようになった。
　このポイントカードのデータなど（ＩＤつきＰＯＳデータ）を使って購買データをもとに、グルーピングする方法がある。この場合、大量データとなるので、コンピューターを使う。

　手法はいろいろあり、たとえば、消費者を二分していくＡＩＤ分析や、
　各消費者（を行）と、商品（を列）にとり、因子分析を行い、
　（そうすると、商品がまとまって因子となる）、
　この因子得点を使って（消費者ごとに因子得点が出る）、クラスタリングを行う方法

などある。