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

１９８０年のころ筆者が初めてアメリカに行った時は、「やけに老人が多い社会だな」 と思いましたが、最近の日本は全人口中の老人の比率でアメリカを抜いたそうです（アメリカの老人比率は、当時から今に至るまでほぼ横ばいです）。
 ２０歳の頃の筆者が今の日本に現れたら当時と同じく「やけに老人が多い社会だな」と思ったに違いありません。
これと似たようなデジャヴ（既視感）を、筆者はごく最近、体験しました。
昨年、鎌倉に越して来たのですが、老人の比率がやけに高いのです。
住民の老人比率が全国平均を大きく上回る上に、観光客の年齢層が輪を掛けて全体に高いため、老人の渦巻く日中の鎌倉市街では、筆者などはまだまだ若者の部類です。
日本が突入するであろう２〜３０年後の老齢化社会に、一足早く踏み入れている状況と言えます。
鎌倉生まれの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)と言う言葉があります。
これは、どのぐらいの間隔で故障が発生するかを示す指標で、仮に平均故障間隔が１００年と言うと、１００年に一回の割で故障が発生する事を意味します。
一般的に言って、構造が簡単で熱や力の作用を受けないもの、例えば半導体回路などでは、長期の平均故障間隔、例えば１００年以上、を達成する事は比較的容易ですが、モーターなどのように動きがあったり、ソフトウェアのように構造が複雑なものは、平均故障間隔をのばす事は極めて困難になって来ます。
一般的に言って、平均故障間隔 １００年の機械を、単体で１０００年にのばすには多大なコストと時間がかかります。
しかし、これを二重化すると 話はがらっと変わってきます。
平均故障間隔１００年の２つの装置が同時に壊れない限り安全とし、壊れた装置の取り替えに１日を要するシステムを考えます。
すると、１年間で２つの装置が同時に壊れる確率は、

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

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

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

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

（続く）