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

新緑の鶴岡八幡宮

（前回の続きです）
原子力発電所の安全性を示す重要な指標として絶対に挙げる必要があるものの一つとして、原子力発電所がその任務を開始し、３０年後、どの程度の確度を持って無事にその使命が重大な事故なく終了できるかを示す確率が考えられます。
ここで言う重大な事故とは、端的に言って、原子炉内の放射性物質がメルトダウン等の事由により炉外へ放出される事態の事を主に指しています。
もちろん１００％が望ましいのですが、神ならぬ我々はいかに１００に近づけるかが問題となり、99.9・・％と言う風に何個９が続くかが問題となります。
９の数が多ければ多いほど良いわけですが、 問題は簡単ではありません。
というのも、容易に想像が付くと思いますが、９の数を増やすには莫大な対策コストが発生するからです。
前回のブログで３％のリスクが、巨大な数字であると言ったのは、この意味です。
３％のリスク事象のオミットが、これまでに費やされた莫大な対策コストを無意味にしてしまいます。
 海外では、１０００年に一度ではなく１万年に一度の災害にも堪える設計をする事を義務づけている国もあります（というか、これが国際標準です）。

個人的な感想を言えば、これぐらいやって、初めて、「想定外」と言う言葉を口に出来る資格が得られると感じます。

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

平家池のつつじ

筆者は大学でSysMLなんかを教えたりしてる関係からか、時々、今回の原発事故に関する意見を、若い人から聞かれる事があります。
 従来は、あまり批判的な事を言っても、いたずらに若い人を不安にするだけだと思い、あまり語りませんでしたが、事故後１年以上経ちすべての原子炉が停止した今、私見を述べてみたいと思います。

最初に筆者の立ち位置を明確にしておいた方が良いと思いますので、それを先に述べたいと思います。
筆者は原子力技術は人類が獲得すべきすばらしいテクノロジーだと考えます。そして、当面のエネルギー政策として原子力発電は今の日本に必要だと考える人間です。
しかしながら、同時に、今の日本の現体制ままで発電が再開する事には断固反対する者です。
 理由は大きく別けて、技術的側面（システム工学）と人間系側面からなりますが、本日は技術的側面について述べたいと思います。

システム工学の視点からみた今回の事故

巷間、今回の地震は１０００年に一度の大地震であり、全く想定外の出来事だっと言われています。
マスコミが言う事ですから、鵜呑みにする事は出来ませんが、事故の経緯や対応を見ても明らかに準備がされていなかった事は事実でしょう。
しかしながら、 システム工学的な立場から言うと、今回のような天災は絶対に想定すべき出来事です。
簡単な確率の計算をしてみましょう。
原子炉の稼働期間は３０年で設計されています。そして、その稼働期間中に１０００年に一度の天災に遭う確率は、３０÷１０００　＝　３％　です。
これは、事故の影響を考えると途方もなく巨大な数字です。
この数字は原子炉一基当りであり、日本中にあるすべての原子炉の数を考えると、日本のいずれかの稼働中の原子炉が、１０００年に一度の大災害に遭う確率は、下手をすると１０％を超えてしまいます。（かなり控えめに計算しています。）

これを、別のシステム・プロジェクトと比べてみましょう。
宇宙開発は極めて危険を伴うプロジェクトとして知られていますが、人類が最初に月に降り立ったアポロ計画では、宇宙飛行士が（月に着陸できるかどうかは別として）生きて地球に戻って来れる確率、設計目標を99.9999999％として設定していました（いわゆる９が９個でナインナイン）。
これは生きて地球に戻って来れない確率（設計目標）が、１０億分の１以下である事を意味します。
 それに対し、すべての日本の原発が安全に稼働する確率（設計時点での見積もり）は最大でも９０〜９７％程度であり、３〜１０％の確率で予測不能の状態に陥る可能性がある事を示しています。

向井千秋さんは、日本人初の女性宇宙飛行士として、その業績、勇気は高く賞賛され、日本人の誇りとするところですが、設計目標のみの観点から言えば、彼女よりも我々日本に住む普通の日本人の方が、実は遥かにチャレンジャーだったと言うのは、笑うに笑えません。

（続く）

IPAブースでのミニ・セミナー

春の鋸山の頂上から三浦半島を望む

私事で恐縮ですが（と言うか、このブログそのものが私事ですが）、来る５月９日および１０日に、ESEC(第15回組込みシステム開発技術展　）内のIPAブース 　にて、

システム工学とソフトウェア工学の接点
～システム工学とエンタープライズ・アーキテクチャの融合 ミッション・クリティカルな海外事例をベース～

と言う 表題で、２０分ほどしゃべります。
 このブログでやってるBPMとは異なる分野ですが（モデリングと言う観点からは同じ分野です）、もしESECに足を運ばれる予定がございましたら、御立ちよりください。

時間が２０分と短い事と、ESECと言う場所柄ソフトウェア系の人が多いと想定されますので、SysML の登場がソフトウェア技術者へ与えた影響を中心に、「米国国防総省におけるテストできないシステム・ソフトウェアの品質保証」の変遷を簡単に概説したいと思います。

OCEB講座 第１５回 BMM

筆者は直接経験した事はないのですが、知り合いの教師をやっている人などによると、最近の学生や生徒の名前に風変わりなものが増えて来て、いったい何と読むのか見当もつかず、名乗られて初めて「ああ、なるほど！」と思わず唸らせる判じ物のような名前、いわゆるキラキラ名にしょっちゅう遭遇するようになって来たそうです。
筆者はこのような話題になると、「慣れの問題だよ、慣れ。そのうち世の中そんな名前だらけになって、反って平凡な名前になるよ。」と言って、無理矢理話題を変えようとします。

筆者がなぜこの話題を避けようとするか？その訳は、すでに感づかれた方もおられるかもしれませんが、次に説明します。

OCEB講座 第１４回 組織設計

鎌倉　源氏池

９０年代、筆者はシリコンバレーのIT系のいわゆるベンチャー企業で働いていた事がありますが、立ち上がり期で小規模なため、一人でいくつものロールをこなさなければならないため、営業サポートや営業そのものもやったりしていました（本職の営業から見ればまねごとレベルですが）。
ご存知の通り、アメリカの会社は一部の企業を除くと、みな田舎町にばらばらに点在し、訪問するだけでかなりの時間とコスト（飛行機代や宿泊費）がかかり、一見すると、かなり非効率的な社会構造です。
しかしながら、いくつかの工夫があり、距離の遠さをカバーしてあまりあるものも存在しました。
その中の一つが本日お話しするコーポレート・タイトルです。
CEOとか、CFOなどのいわゆるCタイトルは、最近では日本でもかなり普及してきていますが、当時は少数派でした。
このCタイトルは、外部の人間から見ると、サービスの外部への共通のインタフェースを宣言しているようなもので、誰がどの分野にリスポンシブル（実行責任）でアカウンタブル（説明責任）かを表明している一種の識別子と見なす事が出来ます。
ベンチャー企業にとって営業と言うのは往々にして最大の弱点であり、技術力はあるが営業戦力は極めて限られている、と言う方がむしろ通例です。
製品の性質によって取る営業戦略は異なりますが、コンシューマ製品の分野では、初期はチャネルセールス（代理店販売）しかしない、と言うのが当時最もオーソドックスなアプローチでした。
しかしながら、当時筆者が勤めていた会社が作っていた製品は、ある程度以上の規模の企業や組織でしか使わないようなものでしたので、直販のアプローチを取っていました。
これには別の理由もあり、当時、開発費が枯渇しかかっており、顧客だけでなく出資者も必要としていたからです。
この場合、営業担当は販売先となりうる企業や組織を選びCIOやCTOにコンタクトを取ります。
CIOやCTOは、当然現行システムやサービスにも責任を持ちますが、日常的には、将来の拡張計画が主な活動となり、常に技術や業界の新しい情報を必要としています。
従って、興味分野が合えば、本人もしくは代理人や関係部署の代表などに対して会合を開くチャンスを持つ事は比較的容易でした。
また、CIOやCTOも往々にして新しいサービスの提供に対して強いプレッシャーを受けており（経営者にせっかちな人間が多いのは、洋の東西を問いません）、また有力なテクノロジーを持つ投資先を探している場合もあります。
（ベンチャー企業の顧客が、同時に出資者でもあると言うのは珍しくありません。）

このように、Cタイトルと言うのは、設計と言う観点から見ると、仕様（外部宣言）と実装（内部構造）を分離するコンポーネント指向設計の組織版と見る事が出来ます。

また、２０００年代に入り、OMGにビジネス・ユーザー系の会員が急増したのも、このCIOの責任範囲の拡大に対応した事が大きな原因です。
２０００年以前は、OMGの会員は圧倒的にメーカー系でビジネス・ユーザー系企業はほとんどいませんでしたが、現在はビジネス・ユーザーが過半数を占めています。
これは、２０００年以前には、単なるコストセンターと見なされがちだったIT部門が、最近では戦略部門と見なされ、 企業戦略の重要な担い手となり、またCIOオフィスの責任範囲が拡大して来た状況と一致します。
ビジネス・ユーザー系会員の目的は、標準化に積極的に参画する事よりも、技術動向の調査（OMGのアウトプットは、要素技術ではなく、方式設計（アーキテクチャ）や設計方法論に強い影響を与えます）と、メーカー系への情報調査と影響力の行使です（２０００年以降は、IT部門は従来のメーカー系の提案を待つ、「待ち」の姿勢から、積極的に「攻め」の姿勢に変わって来ています）。

OCEB講座 第１３回 組織構造と戦略／ビジョンの一致

逗子の岩殿寺　泉鏡花ゆかりのこの寺は桜も開花中

鎌倉は暖かいか？とよく聞かれますが、都内とさほど変わりません、と言うのが大方の感想ではないでしょうか。
しかしながら、鎌倉の隣の三浦半島に一歩足を踏み入れると随分暖かい事が実感されます。
梅の開花やうぐいすの初音もずっと早く、農作物の作成りも良いようです。
しかし良い事ばかりではなく、杉花粉の発生も早いのは困った事です。

縦の権力と横の権力

前回は、縦型の力、責任と権限の関係のお話をしましたが、本日は横型の力について議論したいと思います。
縦型組織の問題点は日本の役所なんかを想定すれば、学生さんであっても理解は容易だと思います。
主な問題点として、

• 下部組織ごとにお山の大将を作りやすく、西洋流に言えば財務省帝国、文部科学省帝国などが発生し（欧米ではお山の事を〇〇帝国と命名する事が多い）、職員は全体ではなく自分の所属する下部組織のためにのみ働くようになります。
• 一つの問題に対し、各下部組織の責任が断片化し、それでなくとも責任回避型に走りがちなのに、ますます責任の所在が不明となる。

などが挙げられます。　これは日本の役人が特殊だからではなく、万国共通に見られる症状であり、言わば縦型組織の自然現象です。

この問題を打破する一つの手法としては、部門横断的に権力の行使が出来る横型の力ですが、外交や軍事などの大きな問題ではよく使われますが、問題によってはポリティカル・ゲームが発生しやすく、強い権力（ハードパワー）よりもソフトな力の行使が望ましい分野も多く（特に恒常的、自発的な改善が望まれる分野）、プロセス志向型組織が欧米で増えて来ているのは、BPMのこういう特徴を踏まえた結果と言えるでしょう。
一般にプロセス志向型組織では、横型の権力はソフトパワーを用います。代表的な横型権力の源泉は問題解決のための予算を握ることです。それ以外は硬軟様々な力の行使を行ない一つのゴールを目指して行きます。
また、縦型組織の最大の関心事である昇進経路ですが、基本的に横向きの力を発揮できる人、チームプレーヤーを第一に昇進させます。これは、組織文化の大きな変革であり、自部門至上主義、ナローマネジメント（旧帝国の再建を狙う勢力）は真っ先に排除の対象になります。

北米では、米国政府だけでなく州政府でもBPMに着手しています。と言うよりも、むしろ民間よりも、BPMのケース・スタディの宝庫の観があります。
アメリカ人は役人の官僚主義化に厳しい見方をするケースが多く、取り組みが遅いと見る向きもありますが（ちなみに日本政府の官僚主義は、もはやこの世のものとは思えない、信じられないレベルだそうです）、日本人の感覚から言えば、非常に積極的にやっているように見えます。

OCEB講座 第１２回 組織構造と戦略／ビジョンの一致

自宅からちょっと歩いた所に竹林で有名な禅寺があり、観光客の少なそうな時期を見計らって時々散歩がてら立ち寄ります。

竹林に入ると柔らかな緑の光に包まれ、SF風に言うと異次元空間に迷い込んだ感があります。

裏手は鎌倉石の断崖が巡り、かつて鎌倉が海の底であった太古の昔を彷彿とさせます。
庭の中にはお茶席があり、抹茶や菓子のサービスが受けられます。

組織設計とBPM

前回の講座で組織構造とビジョン/戦略の不一致の話をしましたので、ビジネス＿モチベーション・モデル（今後はBMMと略す）の話を一旦それて、組織構造の話をしたいと思います。

ビジョンや戦略に組織構造やプロセスを合わせる問題は、OCEBでは組織の設計と言うテーマで出題されます。
とは言っても、BPMをやっている人が皆んな組織の設計に従事するわけではないので、主に、OCEB上級（アドバンスト）レベルで出題され、本講座の対象であるファンダメンタルでは、組織に関するごく簡単な問題のみが出題されます。
例を挙げれば、財務部(Financial Dept.)の責務は？とか、マーケティング戦略の基本は？と言った他愛の無い問題などです。

• （恐らく、組織に属していてBPMをやらなければならない人にとっては半分以上（つまり合格基準点以上）は既知の内容だと思うのと、ブログのネタになりにくいので割愛します。　学生さんなどは書店に並んでいるMBA入門の様な書籍を参照する事をお勧めします。参考までに英語版のタイトルが面白い書籍例へのリンクを張っておきます。） 

従って ここでは、組織設計の基礎知識に付いて触れたいと思います。

工学分野に限らず、どんな分野であろうと、設計、デザインと名のつくものはセンスと理論の混合体です。
建築を例に取ると、どんな家も物理法則からは逃れられず、物理法則を無視した建築物は崩壊してしまいます。しかし、逆に物理学の知識に富んだ人が好い家を設計できるかと言うとこれも真ではありません。
 組織設計も同様で、OCEBでは基本的な組織の力学が出題されますが、これは設計する上での必要知識であって、十分条件では無い事に注意してください。

組織の内外には、宗教、政治、経済等様々な力が渦巻きますが、組織設計の最もベーシックな力学は責任と権限の関係です。
組織はその目的の遂行のために特定の人間（マネジメント）に何らかの任務・責任を負わせますが、同時に権限を与えます。
 責任と権限は出来るだけ一致する事が望ましいのですが、現実的には完全に一致させる事は難しい事です。
ピータードラッカー氏の書籍にも挙げられていますが、極端な場合では責任と権限が完全に乖離し、責任は無いが権限だけがある部門が発生したり、逆に権限は無いのに責任だけ取らされる部門が 出来たりします。
また、自部門の責務を果たすために、他部門の協力や同意が絶対に必要であると言った場合も多く発生するために、責任と権限と言ったいわば縦の正式な権力とともに、横型の非公式な力、影響力を行使しなければなりません。
さらに、マネジメントの気質として責任範囲を広く解釈するタイプと、狭く解釈し自部門だけが良ければそれで良しと言うタイプ（いわゆるナローマネジメント）があります。

昔の組織は、この責任と権限と言った縦の力関係ですべて処理しようとしていましたが、業務が複雑になるにつれ横型の力の重要性がどんどん増してきました。
しかし、縦の力は組織が組織であるための基本的な力です。組織設計の上では必ず考慮する必要があります。

（続く）