OCEB講座 第１７回 BMM

  前回話題に出たM君が青春時代を過ごした「知が好き市」（仮名）へ行ってきました。
そのついでに温泉にも浸かって来ました。

左の写真は旧相模川にかかっていた旧馬入橋の橋脚で、源頼朝公が無くなる直前にその橋の落成式に訪れたと記録されています。
これらの橋脚は大正時代の関東大震災のおりに水田の中から突如地表に現れ出て来たそうです。

この場所は、数百年の間に流路が変わってしまい現在では川ではなく陸地となってしまい、相模川の本流とは１〜２キロ離れています。（写真の水風景はプールで、橋そのものはこのプールの真下に水中保存されており、地上に出ている橋脚はレプリカです。）

しかし面白いことに、遺構は現在の国道１号線　ー　昔の東海道　ー　のすぐ脇にあり、鎌倉から西へ向かう湘南の街道筋は当時から（川筋が大きく変わってしまったにもかかわらず）ほとんど変わっていないことを暗示しています。
つまり、古代から、川筋は変わって行ってもこの辺りの旧東海道の道筋はほとんど変わらず、橋や渡渉地点が変わるだけと言うこの街道の性質を密かに示しているように思われます。

　話はちょっと変わりますが、筆者の母方の祖父は今から４０年ほど前 ー筆者が子供だった頃ー に亡くなりましたが、最近になって彼が晩年に書いた回顧録がまとめられ 製本されて親戚や知人に送られて来ました。
死後４０年経ってようやく日の目を見たわけですが、これは長い間彼の回顧録の所在がわからなくなってしまっていたためで、なんでも、伯父夫婦が家の改築をするために片付けをしていたところ使っていない古いピアノの中からその原稿が出て来たそうです。
祖父は明治２１年に九州の山村に生まれそこで一生の大半を過ごしましたが、その土地を知る者にとっては彼の回顧録はたいへん興味深いものです。
明治になって数十年経っても田舎はほとんど江戸時代のままの生活で、電灯が引かれたのはかなり後の時代です。
 回顧録の一節に彼の親の世代から伝え聞いた江戸時代の道に関する記述があります。
江戸時代の山村の暮らしは不便きわまりなく、どこに行くにも川を渡ったり峠を越えたりする必要があり、街灯など当然なく提灯や松明を持って、すべて徒歩で行き来していたそうです。
また峠をいくつか越えた先に温泉があるのですが、藩が異なり通貨が違うために藩境の手前にある村の庄屋の所へ立ち寄って両替をしなければなりませんでした。
特に大変なのが川で、川を超えて隣の村に行って帰って来るだけで一日仕事でした。
川には渡し舟がありましたが、不定期でいつ舟が現れるか分からず、また舟が来て乗り込んだ所で乗客が十分揃うまで出発せず、随分とのんびりしたものでした。
今だと車で１０分もかからぬ程度の距離ですから、今昔の隔たりは想像以上です。
また山村では、江戸時代の主な道筋は今の幹線と随分と異なる部分があり、山中の峠越えの道が中心で、大名行列も山道を進んでいました。
これは渡渉の煩いを厭い、川沿いの狭く崩れやすい道を避けた結果と言えます。
かつて大名行列が歩いた山中の街道は今ではほとんど誰も歩かず、知る人ぞ知ると言うような存在になってしまいました。
 明治になって川に橋が架かったとき、村中がお祭り騒ぎだったと言うのも不思議ではありません。

鎌倉時代に相模川に橋が架けられたとき、 当時の鎌倉の人々の喜びが大変なものであった事は想像に難くありません。
頼朝公がわざわざ落成式に赴いた事も、当時橋の完成がいかに重大な出来事であったかを物語っています。

BMM

今までBMMの概念図を何度も表示して来ましたが、再度掲示します。「End」が目的概念

BMM図

で、「Means」は手段の概念です。
そして、「Vision」に対して「Mission」、「Goal」にたいして「Strategy」、「Objective」に対して「Tactics」がそれぞれ対応する事はご理解されていると思います。
今回は、この絵をより正確に理解するために、次に「End」のUML図を示します。
下の「End図」を参照してください。

End図

本日は、「ビジョン」と他の二つの目的概念「ゴールとオブジェクティブ」が別々のカテゴリーに分けられている事に着目してみましょう。

一つの企業にとってビジョンはトップのレベルにあるものが唯一ですが、ゴールとオブジェクティブは階層的、あるいは部門別にいくつも存在します。
左図の「Desired_Result」の再帰関連（composed_ofとpart_ofの関連端名が付けられた自分自身に戻る関連）　が、その事を示しています。

より具体的に言うと、企業のビジョンはトップの経営者しか決める事が出来ない専権項目なのに対し、ゴールとオブジェクティブは、開発部門あるいは 営業部門と言った個々の部門別、あるいは階層別に決めて行くが出来ます（あるいは決める必要があります。）

このことは対応する手段側にも同様に言えて、企業レベルの戦略から部門レベルの戦略まで詳細化、細分化する事になります。

OCEB講座 第１６回 BMM

高徳院

この夏はどこにも遠出せず近場を廻るだけで終始してしまいました。
旅行は嫌いな方ではなかったのですが、旅行の定義が筆者の中で大きく変わって来た結果と言えます。
格好よく言えば、空間的旅行から時間的旅行への変化、ー　つまり鎌倉時代を旅するようになってしまいました。

鎌倉生まれのM君によると、鎌倉には昔から鎌倉七不思議と言うものがあるそうですが、その内容は人によってかなり違います。
 ちなみに、彼自身の七不思議の筆頭は、「鎌倉の大仏は誰が建てたか？ 」と言うものだそうです。

 そして、筆者にとっての鎌倉の最大の謎は？と言うと、何と言っても「源頼朝公の死因」を挙げたいと思います。
彼の死の前後数年の公的記録がほとんどなく、暗殺説もささやかれています。
しかしながら、これはM君にとっては謎でも何でもなく、こんな事を云々するのは、君子らしからぬ”下種の詮索”であると断じます。


過日、その頼朝公が死の数日前に落馬したと言う伝説のある鎌倉近郊の某市へM君を誘ったことがありました。
何でも、落馬したと伝えられる旧相模川の橋のそばには温泉もあると聞きました。
M君は大の温泉好きであり場所もさほど遠くないので、当然行くだろうと思って誘ったのですが、意外にも断固とした態度で断ってきました。

M君は鎌倉で生まれ、鎌倉市内最古の小学校、中学を経て、鎌倉の名門、鎌倉高校へ入学しましたが、高校の１年生のとき、彼の家は、その敬愛してやまない鎌倉から（彼いわく格下の）その某市へ引っ越してしまったそうです。
 そのショックはあまりにも大きく、M君はヤンキーになってしまいました。
（注：　アメリカ人になったわけではありません。 ）
それ以来、その某市　ー　ここでは「血が好き市」と仮名で表示　ー　は、彼にとっては暗黒時代を思い出させる嫌な場所になってしまい、「血が好き」と言う地名を聞いただけで、思わず拒絶反応が出てしまい、普段温厚な彼も血が頭にのぼってしまうそうです。

筆者は、とんだ所で、M君の禁忌肢を踏んでしまったようです。

BMM

BMM(ビジネス・モチベーション・モデル）の特徴の一つは、目的（What)と手段（How)を完全に分離している事です。

ビジネスを考える上で、ー　どのように考えるかは人の勝手と言えば勝手ですが　ー、往々にして目的の話をしているつもりが手段の話になったり、あるいはその逆の状況、いわゆる目的と手段の混同、が間々起こります。

この混同は、組織が大きくなればなるほどその弊害が大きい事が知られています。
また、上位のレベルでは単なる手段であったものが、下位の組織レベルでは、その手段そのものが目的となる現象もよく起こります。

BMMでは、目的概念に属するものを総称して”End"と言い、手段の概念に属するものの総称を”Means”と呼びます。

このブログでは、OCEBの試験範囲を超えてしまいますが、モデリングの観点からこの概念を解説して行きたいと思います（ 注：　OCEBでは、UML図は直接は出題されませんのでご安心ください。説明のための背景情報として解説したいと思います。）

OCSMP受験コース 開始！

OCSMP受験対策コース　開始！

OCSMP

　システムモデリングの入門レベルであるOCSMPモデルユーザー資格試験の受験対策講座を開始します。

年内の２コースに関しましては、特別価格３万円（消費税別。２日間の講義、E-ラーニングへのアクセス権を含む。）でご提供致します。


期日：　①　１０月２９〜３０日　　②　１２月６〜７日
　　　　（①１０月２９日開始の部は、定員到達のため、募集終了となりました。②のみ募集中です。９月２８日　事務局。）

内容：　２日間の講義（グループ演習を含む）およびE-ラーニング（模擬試験形式）
価格：　特別価格　３万円（消費税別）

申込み方法等、詳しい内容につきましては、こちらをご参照ください。


参照：　OCSMP資格試験とは？

トレーニング事務局

OCSMP システム・モデリング資格試験の発表

　OMGでは、INCOSEと共同で OCSMP（OMG Certified Systems Modeling Professional）の資格試験を開発し、既に北米、欧州では実施しておりますが、日本やアジア地区では諸般の事情から未発表でした。

このたび、ようやく条件が整いOCSMPをリリースすべく、その準備に当たっております。
詳細については、来る８月２４日のIPA主催セミナーで説明する予定です。

IPAセミナー 　http://sec.ipa.go.jp/seminar/2012/20120824_2.html

（プレス関係の方は、UTIの試験事務局に直接お問い合わせください）

昨今は、英語でのエンジニアリング・ワークが求められる事が多く、また個人的に、若い人に対し、例え勤め先が国内企業であっても、ある日突然外資系になるかもしれず（そう人は、筆者の知人にも結構います）、英語での技術コミュニケーションが必須である事をことあるごとに言っております。
また、モデリング言語でのコミュニケーションの重要度も年々上昇しています。

ご興味ある方は、ぜひご参加ください。

モデリングとシステム工学

１９８０年のころ筆者が初めてアメリカに行った時は、「やけに老人が多い社会だな」 と思いましたが、最近の日本は全人口中の老人の比率でアメリカを抜いたそうです（アメリカの老人比率は、当時から今に至るまでほぼ横ばいです）。
 ２０歳の頃の筆者が今の日本に現れたら当時と同じく「やけに老人が多い社会だな」と思ったに違いありません。
これと似たようなデジャヴ（既視感）を、筆者はごく最近、体験しました。
昨年、鎌倉に越して来たのですが、老人の比率がやけに高いのです。
住民の老人比率が全国平均を大きく上回る上に、観光客の年齢層が輪を掛けて全体に高いため、老人の渦巻く日中の鎌倉市街では、筆者などはまだまだ若者の部類です。
日本が突入するであろう２〜３０年後の老齢化社会に、一足早く踏み入れている状況と言えます。
鎌倉生まれのM君によると、この鎌倉の老人の多さは今に始まった話ではなく、彼が知る範囲で相当大昔からこのような状態だったそうです。
老人と言っても、しかしながら、気が若く元気な人が多い点は、鎌倉の美点と言っていいでしょう。
こちらに越して来て間もない頃、駅裏のスーパーの駐車場でぼーっとしていた所、真っ赤なスーツ姿の老婆があふれんばかりの白髪を振り乱しながら真っ赤なツーシーター（２人乗りのスポーツカー）から現れた時は正直驚きました。
てっきり、鎌倉山に棲むと言う伝説の山姥が里に下りて来たのだと思いました(　(;ﾟДﾟ)　)。

---

デジャヴ

筆者は、学校その他でSysMLを人に教え、そしてシステム・モデリングの演習中によく出くわす光景があります。
システムのモデル図をツールを使って描こうとする時、SysMLの特性から、一カ所を変更しようとすると関連する他の図まですべて自動的に変更されてしまうため、初学者の人は、なかなか思い描く通りの図が描けず四苦八苦してしまいます。
 こちらを直せば、あちらがおかしくなる、と言う具合に悪戦苦闘する姿は、システム・モデリングの通過儀礼、バンジージャンプのようなものと言えます。

• SysMLと言っても、言語的にはUML図を書いているので、この分野で活躍したいと考える若い方には、UMLも勉強する事をお勧めします。けっして、遠回りにはならないと思います。上級のモデリングには、OCUPインターミディエート程度の知識は必須です。また、システムが大規模化、複雑化するにつれて、ソフトウェアへの依存度が急速に高まって来る事が多く、ソフトウェア畑出身でないシステム設計者にとってもソフトウェア工学の知識は重要です。

 これだけであれば大した問題ではないのですが、本当の問題はその次です：　こうして苦労して描き上げたモデル図群を見て、システム・エンジニアリングした気になってしまう事です。
実は、システム・エンジニアリングしているどころか、始まりもしていません。
MBSEは、モデル・ベースのシステム・エンジニアリングの略であり、 モデル図をもとにシステム・エンジニアリングを行なう事であって、モデリングはその前提技術です。

表題にデジャヴと大きく掲げたのはこの問題で、UMLを使ったソフトウェアのモデリングでも、そっくり同じ現象が発生します。
つまり、モデリングした時点でソフトウェア・エンジニアリングをした気になってしまうのです。
モデリングを元にソフトウェア・エンジニアリングの観点から分析を行なう事が主題のはずが、それを飛ばしていきなり実装に移ってしまいます。

これは、時々友人にも話すのですが、MDA（モデル駆動型アーキテクチャ）という言葉自身にも原因の一端があるのではないかと思います（特に実装志向の強い日本の環境下では。　歴史的には、モデリングは実装ではなく、問題の分析、ソリューションの設計のために発達して来た技術です。）

むしろ、MBSEと同じように、モデル・ベースのアーキテクチャあるいはモデル・ベースのソフトウェア・エンジニアリングと言った方が誤解がないと思います。
モデル・ベースのアーキテクチャがあれば、モデル・ベースでないアーキテクチャもあるわけで、どちらを選ぶべきかは、良し悪しの問題ではなく、向き不向きの問題です。

原発事故に対するシステム工学の視点 ９

京都風の庭

筆者の友人のM君は、鎌倉生まれ、鎌倉育ちの人です。
先祖も鎌倉に古くから住んでいたそうで、彼の母方の家の方は有名な鎌倉権五郎景政の一族のようです。
そのM君に、「鎌倉にも京風の庭を持つ寺がありますよ」と聞いて訪れたのが左の写真の長寿寺です。
なんでも、「足利尊氏さんの屋敷跡」だそうです。

---

前回、日本のアプローチが分析的、分解的だと書きました。
これは、日米のシステム設計のやりかたを見れば、違いは一目瞭然です。
ATM（自動預金支払機）の例で見てみたいと思います。
今は少し変わりましたが、アメリカの空港や銀行では、故障中と表示されたATMがかなり多く並んでる時がありました。
そして、故障したATMは、修理もせず何日も放置されています。
知人の日本人技術者は、その光景を見て、「アメリカのATMの開発者たちは、こんな光景を恥ずかしいと感じないんだろうか？」と首をひねっていましたが、当のアメリカ人たちは、使えるATMがあるうちは気にしていないようです。
アメリカのアプローチは、ATMユーザーの使用頻度、ATMの故障発生率、修理に廻る技術者の可用性やコストなどを勘案して、必要なATMの台数を計算し、各拠点に配備するやり方です。
一方日本は、高品質高性能なATMを少数配備するやり方です。
筆者も時々経験する事ですが、日本ではかなり昔から、時々、銀行のATMを待つ人の列が延々続く事があり、待ちきれずに引き落としを断念する事もあります。
アメリカ人から見れば、「こんな低品質なサービスを放置し続けて、銀行の経営者たちは恥ずかしいと思わないんだろうか？」となるかも知れません。

これは、国民性の違いや制度上の問題もあって、一概にどちらが良いとは簡単には言えない問題ですが、アプローチの違いは明解です。

また製品開発においても同様で、品質の問題を分解的に解決しようとする傾向が強く、その結果、日本製の部品は、ソフトウェアを除けば世界で最も優れた品質にある事は間違いないでしょう。（ソフトウェアの品質は、その定義をどこまで拡げるかによって変わってきますので、一概には言えません。）

これは、組織のマネジメントにも同様な傾向が見られます。

筆者は昔、２０代の頃アメリカのIBMの研究所に勤務していた時期がありますが、その時の同僚にDさんと言う人がおりました。
同僚と言ってもDさんは当時６０歳前後で、筆者とは親子以上に年齢が離れておりましたが、非常に親切な方で色々と大変お世話になりました。
そのDさんは、会社でもかなりの変わり者に分類されていました。
まず、大変な大金持ちで、会社をいくつも持ち、広大な敷地の大学も所有しながら、IBMでずっとSE(システムズ・エンジニア）をやっていました。
SEとしてもかなり優秀な方で（社内での格付けも最高になってたと思います）、多くの社内論文を書き、若い技術者からも尊敬の目で見られ人望も高い方でしたが、会社からのライン・マネージャー（管理職）にならないか？と言う打診に対しては常に断り続けて来ました。

ここで社内論文と書きましたが、一般にシステムズ・エンジニアリング（システム工学）関係の論文は、機密区分が高く、社外秘になる場合がよくあります。
こういった扱いは、別にIBMに限った事ではなく、システムズ・エンジニアリング関係の会社にはよく見られるパターンですが、IBMの場合はそう言った機密区分の高い論文や報告書を集めた専門の社内論文誌や社内書籍も発行されていました。

彼は、大金持ちでしたが、別に親の遺産があったわけではなく、若い頃はかなり貧しい暮らしをしていたそうです。
小さな頃からアルバイトをして生計を助け、高校時代はバーテンダーの仕事で学費を稼いでいたそうです。
一度彼の豪邸でカクテルをご馳走になった事があり、シェイカーさばきもなかなか美事なものでしたが、ご本人は、しかしながらアルコールをほとんど口にしなかった事が印象に残っています（敬虔なクリスチャンでした）。
Dさんは通常よりも長く兵役に就き、そして除隊後に軍から得た奨学金で大学を卒業しました。

そんな彼に、２０代の筆者は、なぜラインマネージャーにならなかったのか訊いてみた事があります。
彼は、「自分にはマネジメントの能力がない」と答えました。
「では、なぜ、マネジメント能力がないのに、会社や大学の経営が出来るのか？」とさらに訊いてみると、彼は「自分は経営にほとんど関わっていない。自分に何か少しでも才能があるとすると、それはマネジメントの才能を発見する事かも知れない。」と静かに答えました。

彼は、良いマネジメントについてこう解説して（聡して）くれました。
１００人の人間を集めて１００人分の仕事をさせるのは凡庸なマネジメントであり、単なる搾取者である。
１００人の人間を集めて１５０人分、２００人分、場合によっては５００人分の価値を生み出すのが真のマネジメントであり、逆に８０人分のアウトプットしか出せないのは無能なマネジメントである、と。

低品質なATM機を使いながらハイ・アベラビリティ・サービスを提供したり、平均故障間隔の短い構成要素を使いながら、巧みな組み合わせや定期的な部品の交換、保守作業、事後対策などを工夫する事により、高い安全性を達成するのがシステムズ・エンジニアリングの醍醐味と言えます。

さて、優秀な人材を抱え、優れた技術、潤沢な資産を持ちながら８０パーセントの結果しか出せない経営者は、まだご愛嬌の部類です。
自覚と才能があれば、今後の発展の可能性があります。

最悪なマネジメントは、全体感や統合感のないタイプで、IT分野でもたまにいますが、安全や品質のための多重化や多段化の冗長性が無駄の宝庫に映り、コスト削減の格好の狩猟場にしてしまい、己のわずかな手柄のために、安全性や品質を劇的に劣化させてしまう範疇です。
管見では、このタイプは類は友を呼びやすく、集団でかかってきますのでタチが悪いことこの上なしです。

---

Dさんに、当時のIBMの経営陣はどう思うか訊いた事があります。
彼の反応は先見性に富み大変興味深いものでしたが、今となっては言わぬが花でしょう。

原発事故に対するシステム工学の視点 ８

定泉寺の紫陽花

紫陽花の季節がやってきました。
紫陽花と言うと、筆者がすぐに思い出す和歌があります。
小野小町の、
花の色は　移りにけりな　いたずらに
我が身よにふる　ながめせしまに

と言う古今集の歌ですが、百人一首にも含まれ、読者の方々にも馴染み深い歌だと思います。
この歌は、教科書的には、花は桜を意味し、花を自分の容姿にたとえ、「ぼーっとむなしく物思いに耽っているうちに、すっかりおばさんになってしまったわ。」という女性の嘆き風に解釈されています。

 筆者は高校時代よりこの解釈が気に入らず、今から２０年以上前に、わざわざ自説を述べるために「小野小町研究」というサイトを立ち上げたほどです。
当時はまだインターネットの黎明期でネットワーク機器は大変高価でしたが、幸い筆者はシリコンバレーのネットワーク・ベンチャーに勤務していたので、機器をそろえることだけは簡単に（廉価に）出来ました。
まだグーグルなどの検索サービスもなく、仲間内だけが見に来るサイトでしたが、なかなか結構好評でした（自己満足です）。

さてこの歌の意味ですが、筆者は花を桜ではなく紫陽花と解釈します。
そして、「花の色が移る」ことで、相手の心変わりを暗示し、「私がむなしく物思いに沈んでいる間に、あなたは簡単に心変わりしたのね」と相手を軽く批難する意味になります。
つまり、相手が調子に乗らないように、わざとネガティブなフィードバックを行なって（負帰還をかけて）、「僕のどこがいけなかったんだろう？」と反省を促し、相手の心をコントロールているわけです。

論拠としては、植物や気象の性質、そして美学上の問題があります。
まず、桜と言う花は、色が移る（衰える）よりも前に散ってしまう花、最も美しい盛りに散ってしまう花であり、おばさんを喩えるには不向きです。
また、「ながめ」は「眺む（物思いに耽る）」と「長雨」を掛けた言葉と解釈されますが、桜の花の季節は天候が荒れやすく、長雨というおとなしい降り方ではなく嵐になりやすいことは皆様よくご存知だと思います。
長雨は桜に似合いません。合うとすれば梅雨の紫陽花の方でしょう。
 さらに、古来、女性の美しさは、よく花に喩えられますが、自分で喩えてしまっては（強い女性を好む一部の男を除き）興ざめです。
これは平安時代の女性たちが持っていた’女の美学’にも反します。
そしてまた、筆者の解釈の方が「いたずらに」という言葉がより生きてきます。
「いたずらに」は前半の相手の簡単な心変わりをなじるユーモラスな意味と、後半のむなしい無常観の表現の両方にかかっています。

恐らく、小町の花を桜と誤って解釈した背景には、古今集編纂の頃のフォーマリズム（形式主義）を尊ぶ気風があったと思います（今に続く、花を条件反射的に桜に分類してしまう習性）。

心を花に喩える類例は、小町の他の歌にもあります。

色見えで うつろふものは 世の中の 人の心の 花にぞありける

---

前回は、抽象思考、システム思考の問題の話をしましたが、その続きです。

原発事故から一年以上経った今、原子力発電所システムそのもののチェックだけは行い、メルトダウン等の重大事故後の社会システム的な体制づくりは行なっていないようですが、これはある意味、非常に日本的な対応と言えます。
一言で言えば、アプローチが非常に分析的、分解的です。
「今回の事故の原因は、原子力発電所の脆弱性にあった。従って、発電所の堅牢性を上げよう。」と言うアプローチです。
このアプローチは、規模の小さいもの、安全性に対する影響が小さいものに対しては有効ですが、複雑度が高い、あるいは影響度が巨大なシステムに対しては不十分です。

簡単な例をあげて考えてみましょう。
平均故障間隔（MTBF)あるいは平均故障時間（MTTF)と言う言葉があります。
これは、どのぐらいの間隔で故障が発生するかを示す指標で、仮に平均故障間隔が１００年と言うと、１００年に一回の割で故障が発生する事を意味します。
一般的に言って、構造が簡単で熱や力の作用を受けないもの、例えば半導体回路などでは、長期の平均故障間隔、例えば１００年以上、を達成する事は比較的容易ですが、モーターなどのように動きがあったり、ソフトウェアのように構造が複雑なものは、平均故障間隔をのばす事は極めて困難になって来ます。
一般的に言って、平均故障間隔 １００年の機械を、単体で１０００年にのばすには多大なコストと時間がかかります。
しかし、これを二重化すると 話はがらっと変わってきます。
平均故障間隔１００年の２つの装置が同時に壊れない限り安全とし、壊れた装置の取り替えに１日を要するシステムを考えます。
すると、１年間で２つの装置が同時に壊れる確率は、

となり、平均故障間隔はこの逆数ですから３６５万年　ー　つまり３６５万年に一度だけ２つ同時に壊れる事となります（簡略化のために他の因子を無視しています）。
実際のシステムは、もっと複雑なのでこれほど単純には伸びませんが、多重化、多段化の威力はお分かりになったかと思います。

設計時の平均故障間隔と言う観点で見れば、日本の原発は１０００年に満たない短いものであった事は、このブログの１回目に指摘したとおりですが、その上、後段つまり事故発生後の対策が全く準備されていないと言うものでした。

巨大システムでは、品質や安全は分析的手法では不十分で、統合的、つまり品質や安全を作り上げて行く手法が必要となって行きます。

先に、原発問題のアプローチは、非常に日本的であると述べましたが、これに関しては次回触れたいと思います。

（続く）