SysML 中級講座： 第７回 日本のモデリング事情

日本のIT業界が、他国と異質な面が有る事は有名ですが、モデリング事情も少し異なっています。
今回は、その点を数字で示してみたいと思います。

筆者はここ数年OMGの試験委員をやっている関係で、OMG関連の開発ツールを作っている会社の人と話す機会がありますが、日本のモデリング事情と照らし合わせてみて、時々違和感を感じる事があります。

下の図は、UML系モデリング・ツール（SysMLやSoaMLなどの派生系を含みます）の地域別の市場規模の推計値です。
これらの数字は、ツール・ベンダーから聞いた数字や公表資料をもとに筆者自身が推計したものであり、OMGが発表しているものでは無い事をあらかじめお断りしておきます（従って出典を弊社名としております）。
とは言え、各ベンダーの示す数字は概ね同じような傾向を示していますので、大きな誤差は無いと思います。

２０１０年　出典　ストラタジーナム社

ここで言うUML系ツールとは、SoaMLやSysMLのツールを含みますが、BPM系のツールは含みません。
主要ベンダーのツールは、SoaMLやSysMLがUMLと連動するよう作ってあります。
また、実際問題として、SoaMLやSysMLの市場は出来たばっかりで、市場規模はUMLに比べると小さく、この図をUMLツールの市場 シェアと見ても、大差ないと思われます。
北米が５０％を占めていますが、そのうち大半がUS（合衆国）です。
欧州市場は４０％を占めていますが、その４０％のうちの７割ぐらい（全体比で３０％程度）は英独仏の３カ国で占められています。
そして、残りの１０％は、日本を含むその他すべての国を意味します。
この図で、日本のモデリング市場の特徴を見る事が出来ます。
一般のソフトウェア市場で見た場合、日本の市場規模はアメリカに次いで２番目に大きく、国別ではヨーロッパのどの国よりも大きいのが通例です。
しかしながら、モデリング・ツールの市場で見た場合、アジア市場は非常に小さく、また日本は、そのアジア市場でも必ずしも多数派ではなく、インドやオーストラリアなどと横並び状態です。
日本は決してソフトウェア投資、IT投資をしてない訳ではなく、GDP比で見ても、投資額で見ても、先進国の中では中の上くらいに位置しますが、 モデリング・ツールをあまり使わないと言う点で、相対的に異質です。
 欧米の専門家は、ツールを用いないモデリングは実用性に欠けると考える人が圧倒的であり、筆者自身の経験から言っても、欧米で、ツールを使わないでモデル・ベース開発を行なっている現場を見た事がありません。

また、このポイントは、IPAのモデリング部会（筆者もOMG代表として出ております）の日本企業に対するアンケート結果に示される「モデリングの実用性に不満を持つ層が多い」と言う事実と符合します。

日本は、モデリングそのものに関する知見は高いものの、実用のための知見に乏しいと言っても良いのではないか、と言うのが率直な感想です。
もちろんツールだけ知ってても何も出来ませんが、逆にUMLやSysMLだけ知ってても実用的でない、と言えます。
システム・エンジニアリング分野が、日本のITと同じ轍を踏まないためにも、ツールは無視出来ない存在です。

OMG イベントのお知らせ

筆者が関係する団体であるOMGが、来年１月２０、２１日と東京地区でイベント（フォーラム）を開催する事になりましたので、ご案内いたします。

SysMLセミナー
主催：　IPA        共催　： OMG
日時：１月２０日　１４：００〜１７：３０　　
場所：IPA クラスルーム
申込先 :　　　http://sec.ipa.go.jp/seminar/2011/20110120_pre.html

BPM/SOA/クラウド　フォーラム
主催：　OMG    　企画運営： UTI    後援：　IPA、東海大学
日時：　１月２１日　１３：００〜１７：００
場所：　東海大学高輪キャンパス
申込先：　http://www.umlcert.org/news/20110121.html


OMG会長のリチャード・ソーリー博士とOMGボードメンバーであるギャリー・ダンカンソンさんの来日が決まり、現在準備中です。
ソーリー博士は、OMGの顔として昔から何回か来日していますので、皆様ご存知の方も多いと思いますが、IPAとの共催イベントは今回が初めてです。

 ギャリー・ダンカンソンさんは、USのNo Magic社の社長さんです。
彼の会社のMagicDrawと言うソフトウェアは北米やヨーロッパでは有名ですが、日本では殆ど無名です。
テクニカル・ミーティングで会うたびに、日本でも本格的にやったらどうか？と勧めてきたのですが、筆者の言葉に促されたのか、あるいは無関係なのか分かりませんが、今回来日する事になりました。
筆者は、モデル・ベース指向開発の浸透にはツールの使用は必要不可欠と考えておりますので、日本のモデル・ベース開発のいい意味での起爆剤になれば、と期待しております。

西麻布から

筆者は、 日頃テレビをあまり見ないので芸能ニュースにはとんと疎いのですが、事件の現場が知人の自宅の近所だったので見学に行ってきました。
過日、麻布に住む知人のオフィス兼自宅に行った際、歌舞伎役者の市川海老蔵氏が巻き込まれた傷害事件のあったビルがその近所にあると聞いて、帰り道に立ち寄って来ました。

バルビゾン２７（海老蔵ビル）

左のビルが通称「海老蔵ビル」と呼ばれるバルビゾン２７　ビルです。
筆者がビルの前に立っていたのは１０分程度でしたが、その間、３組のグループが同じように記念写真を撮っていて、今や麻布の新名所の観があります。
また写真を撮っていたのは、筆者をのぞくと全員ご婦人で、中には祖母、母、娘の三世代合同の７〜８人の女性ばかりの大家族づれと言う集団もあり（ちなみに、このご家族の記念写真のシャッターを押したのは、筆者です）、海老蔵氏の人気の高さがうかがわれます。

明るいエントランス（バルビゾン２７）

東京で奈良時代を

紅葉のシーズンです。
筆者も紅葉を見に行ってきました。
学生時代、筆者は三鷹とか武蔵野に住んでいた事があったのですが、その頃の散歩コースであった深大寺に久しぶりに行ってきました。たしか、学校を卒業して以来初めての訪問になるかと思いますが、調布の町並みはやはり変わっていました。

深大寺は東京では浅草寺に次いで2番目に古いお寺で、天平五年（奈良時代、聖武天皇の頃）創建 と伝えられています。
境内を、タモリ倶楽部で有名になった国分寺崖線が横切り、武蔵野台地からの湧き水が豊富で蕎麦の名所としても名高い所です。
また、白鳳時代の作では無いかと言われる釈迦如来倚像（いぞう）が明治時代にお堂の壇の下から見つかりましたが、いかなる経緯で武蔵野まで運ばれ、また、なぜ、1000年以上も隠されていたのか、謎のままです。

このあたりは、調布という名前に象徴される様に奈良時代から開けた場所であり、
東京では数少ない白鳳ｰ天平の雰囲気を味わえる場所です。
と言うわけで、筆者も和歌を一句：

秋の夕　
紅（くれない）猛（たけ）き
白鳳の
ほとけの笑みも　
ほのかに朱（あか）し

SysMLフォーラム準備中

久しくSysMLの話題から遠ざかっていましたが、別にSysMLに関心が無くなったわけではなく、逆にSysML三昧の日々をおくってたので、ブログでわざわざ触れる気になれなかったと言うのが実情です。

まず、OCSMP（OMG認定システム・モデリング・プロフェッショナル）の試験がいよいよ始まり、弊社でもモデルユーザーのトレーニング・クラスを始めました。

また、ある研究会にOMG代表として参加して欲しい旨の依頼があった件も、SysMLがらみと言えます。

この夏に慶應義塾大学で開催されたSysMLフォーラムの後続である第3回目SysMLフォーラムを鋭意準備中で、近々発表を行う予定です。

と言うわけで、SysMLがらみの案件が多く、ブログ上で現実逃避を計っています。

逃避中

神田山の謎

筆者は時折用事があって、神田の街を歩き回ります。
 聞くところによると、昔このあたりには神田山という山があったそうですが、江戸時代の初め頃、江戸城の前の入り江を埋め立てるために切り崩してしまったそうです。
ビルだらけの町並みを眺めているだけでは神田山がどのあたりにあったのか中々見当がつかなかったのですが、前回取りあげた地形ソフトで見ると山の痕跡は確かに残っています。

神田山　跡

 上の図の北から中央付近にかけて半島状に伸びて来ているのが本郷台と呼ばれる武蔵野台地の一部ですが、その南端部分の等高線に削り取られた痕跡があります。
面白い事に、東西に直線的に走る靖国通りもこの部分だけは、南側に山裾を縫うように迂回しています。
現地に立って見ると分かりますが、この部分はわざわざ迂回が必要なほどの傾斜地では無いのですが、恐らく道筋が神田山がまだあった時代の名残のままなんでしょう。

神田の町は今でも老舗が残っており、筆者もここで和菓子屋に入ったりしています。

神田山の麓にある「ささま」で買い求めた秋の和菓子とラジオ

地形ソフト

最近本屋に行くと地形に関する本が良く並んでいます。
筆者も、マニアと言うほどではありませんが地図、特に地形図を見るのが好きでよく見ます。（時間があれば、一日中見ていたいのですが、なかなか、そうはいきません。）
また最近は、オンライン上でも地形図が手に入り易くなりたいへん重宝しています。
特に気に入っているのがGoogle Earth のアドインで、東京の武蔵野台地の構造が色つきで一目で分かるようになっているものです。
都内に住んでいると、大小のビルが建て込んでいて元の地形が非常に分かりづらくなって来ているのですが、このソフトだと一目瞭然です。

一例を挙げてみましょう。
筆者の自宅のそばに四谷という街があります。
四谷と言う地名は家康入国以前からある事が知られていますが、語源ははっきりしません。
江戸時代に書かれた書物「御府内備考」には、『甲州街道筋に４軒の旧家、梅屋、木屋、茶屋、布屋があって「四家」と呼ばれていたが、いつの頃からか「四谷」と書くようになった』とありますが、これは明らかにおかしく、これらの４軒の家は、家康入府以後、江戸時代になって移住してきたものであり、時代が合いません。

恐らく、四谷も他の千駄ヶ谷や市ヶ谷などの「○○谷」地名と同じく、谷地形から取られたものでしょう。
地形図でそれを確認してみましょう。
下の図は、四谷を中心とした地形図で、中央の窪んだ谷地形が四谷の地名の発祥地域です。

この図から、四谷も他の東京の古い町筋と同様、谷地（やち）に発達した集落であった事が分かります。
また、一説には、四谷は４つの谷と言う意味だと言われていますが、谷の形状を見ると、その説もなかなか説得力があります。（北から南に走る谷に、西から３本の谷が入っていて、合計４つの谷から出来ているように見えます。）
図中の４１４号線を示す六角形の記号の右手（東側）の三角形の地所は迎賓館です。
この地図上は、現在は、赤坂御所（赤坂御苑）以外の部分はすべて大小のビルで覆われていますので、元の地形は想像する事が非常に難しくなってきています。

こういった場所を散策するには、このソフトは手放せません。

漱石と姥子温泉

忙中閑ありで、午後暇が出来たので箱根にぶらりとやって来ました。

夏目漱石の「吾輩は猫である」で美学者迷亭が、昔二週間ほど逗留したと語る姥子温泉です。

残念ながら漱石自身が姥子温泉に来たと言う確実な証拠は残っていません。
従って文学者の書く年表には、漱石の姥子行きの事蹟は記入されてないものが多いようですが、しかしながら、

• 子規に宛てた手紙に、大学入学前後に箱根に旅行に行くと語っている事
• 「吾輩は猫である」中で、迷亭の湯治の場として登場。文中ではその様子を登山と表現しており、ある程度高所にある温泉場を想像させるが、姥子温泉は標高８５０メートルあり、当時の箱根では最も高所にある温泉場だった
• 漱石は若い頃トラホームを患い、長い間目医者通いをしており、姥子は全国でもめずらしく眼病に良く効く温泉場であった

等の事から、姥子温泉に逗留した事は、温泉ファンの間では確実視されているようです。

ここは、箱根で唯一と言っていいほど、最後まで湯治場の雰囲気を残している宿です。

あいにくの雨でしたが、それが反って、湯治場らしい雰囲気を醸し出してくれます。

漱石が姥子に来たのは１００年以上前の事ですが、昨日まで湯治に来ていたと言われても、違和感が無いほど、落ち着いた感じの建物です。

裏庭には、鎌倉時代の石仏も並んでいて、百年前ぐらいだと、ついこの間と言う気分にさせられます。

極めて透明感のあるお湯で、右の写真の注連縄の張ってある奥の湯船で、顔をつけ目をぱちくりさせれば目に良いらしいので、筆者もやってみました。

気のせいか、このブログを書いている今でも、目が良くなったような気がします。

天空からの視点

先ほど、Macをいじっていたら、先日の大阪出張の際撮った大仙陵古墳（通称　仁徳天皇陵）の写真が出てきました。
歴史の教科書で航空写真を見た事はあるのですが、実地で肉眼で見たのは初めてです。
面積比で世界最大の古墳と言われるだけあって、近くから見ても遠くから見ても、ただの平たい山に見え、航空写真で見るような鍵穴のような形には見えません。
近くに古墳全体を見下ろすような高い山は無く、古代人はいったい誰に見せるためにこのような巨大なモニュメントを作ったのでしょうか？

ナスカの遺跡と言い、この大仙陵と言い、古代人は明らかに天からの視点を意識したようなモニュメントを作り、その後、時代が進むにつれ天からの視点を意識しなくなって、人間に見せるためのモニュメントばかりになって行きます。

古代は謎だらけですので、様々な仮説を立てる余地が広大にあり、実証も反駁も出来ない事が殆どですので、筆者もここで反証が難しい珍説を開陳したいと思います。

多くの人がそうだと思いますが、筆者も子供の頃は空を飛ぶ夢をよく見ました。
夢の中では、小学校の校舎や自宅の近所の町並みが上空からパノラマのように見えたりします。実にリアルな映像でした。
ところが大人になると、空を飛ぶ夢は滅多に見なくなります。
筆者の仮説は、古代人は、子供と同じように、地上から見た様々な角度の風景を頭の中で組み立てて鳥瞰視する能力が長けていたのではないか？と言うものです。

大仙陵を作っていた古代人は空から見たパノラマが見えていた。
しかしその後、そのような能力は発揮する場面がなくなり、子供時代の夢の中だけに生き残っている、というのは文字通り夢のある説だと思いませんか？

バブルの遺跡

筆者がまだ子供の頃「戦争を知らない子供たち」という軽薄な、いかにも団塊世代狙いのタイトルの歌が流行った事があります。
 最近は、それに対抗して、日本経済のバブル崩壊後に生まれそだった「バブルを知らない子供たち」と言う言葉があるそうです。
バブルと言う現象は、いくつかの経済的条件がそろった時に見られる現象だそうで、歴史的には日本以外でもあったそうですが、そんなに長くは続かないと言う点で各国共通です。
筆者はバブル全盛の頃は２０代で、ほとんど恩恵を被ることが無かったのですが、それでも何度か銀座の高級クラブで取引先の接待を受けた事があります。
当時は、値段の高いものから順に売れて行った時代ですので、質実はともかく接待費は相当かかったと思います。

時代は変わり、銀座の高級クラブはかなり消えたそうですが、しかしながら、さほど残念と言う気持ちにはなれません。
高級クラブで美女にお酌されるよりも、可愛い女の子と水族館に行ったり、お好み焼き屋で彼女とお好み焼きを分け合って食べてる方が、百万倍も楽しい事は間違いありません。

筆者は仕事上、フランス系の人間とつきあう事が多いのですが、先月フランス系カナダ人と電話で話をしている時に（ちなみにスカイプを使用）、夏休みの話になってお互いのプランを紹介し合いました。
彼は、夏休みは家族を連れてイタリアの○×△▼湖畔（聞き取れず）へ行くと言います。
なんでもローマ時代からの保養地で、ローマ時代以前の遺跡もごろごろしているそうです。
もっともバブルが崩壊してここ数百年は寂れてきているが、そこが良いともいいます。
筆者も一度、ローマ時代のバブルが崩壊した保養地でフランス式のバカンスをやってみたいものです。

文学散歩 ー 高等遊民の住処

筆者は運動不足解消のため、時折自転車で小石川にあるフィットネスクラブまで通っています。
筆者の通る市ヶ谷、牛込、小日向、小石川と言った辺りは、明治の文豪夏目漱石の生活圏とかなりオーバーラップしており、漱石の小説の読者の方はご存知だと思いますが、彼の小説の舞台や登場人物もこの界隈に数多く取り上げられています。
文壇デビュー作である「我が輩は猫である」の直接の舞台はここから谷一つ隔てた本郷台地であるものの、登場する謎の高等遊民、美学者、迷亭の住処はどうやら神楽坂近辺のようです。
夏目漱石の生活史は、数多くの研究者により研究されており、ウェブ上でも取り上げられていますが、それでも、迷亭のモデルには定説は無いようです。
鏡子夫人は、「漱石の思いで」の中で、”たいていの登場人物のモデルは見当がつくが、迷亭だけは思い当たる人物がいない、漱石自身の一側面を人格化した人物では”と言った趣旨の事を述べられています。

「我が輩は猫である」を読むと、迷亭は郵便を入れながら牛込見附（今の飯田橋駅西口あたり、神楽坂を下りきったところ）近辺を散歩すると言う表現に出くわします。
また、迷亭の発言から、「自宅の近所に南蔵院と言う寺がある」ことが判ります。
これらの点から、この界隈を知っているものなら、おおよそ思い当たる場所が浮かび上がって来ます。

南蔵院

地蔵坂、旧名ワラダナ

左は、牛込にある南蔵院の写真です。

また、左下は神楽坂から南蔵院方面に登る地蔵坂、別名ワラダナと呼ばれる坂の写真です（ちょうど秋祭りだったので、法被を着ている人が写りました）。

そして、ここまで来ると、迷亭のイメージは、漱石の別の小説「それから」の主人公、長井代助と重なって来ます。

代助は裕福な資産家の次男坊で、帝国大学を卒業後も仕事には就かず、親に一軒家を建ててもらい悠々自適の生活を送っています。

そんな高等遊民、代助の住処として漱石が選んだ場所は、地蔵坂、ワラダナを登り切った高台、南蔵院にもほど近い袋町の光照寺付近です。

光照寺付近は、中世の牛込城の跡と言い伝えられ、この付近では一番の高所であり、高等遊民が住むにはいかにもふさわしい場所と言わねばなりません。

袋町の家並み

光照寺　入り口付近

神楽坂周辺は、第二次大戦中に空襲に遭い焼け野原になっていますので、古い建造物は残っていませんが、主な道筋は戦前のものとほぼ一致します。

昔は、光照寺の境内から東京湾に出入りする舟の姿が眺められたと言います。

市街を見下ろすこの辺り一番の高台に住む高等遊民の迷亭や長井代助は、漱石の一側面の性格を持ちながらも、ある意味憧れの生活を送る人物像だったのではないでしょうか。

光照寺付近の地図

より大きな地図で 無題 を表示

法善寺横町

織田作之助作「夫婦善哉」は名前だけはかすかに聞いた事はあるものの、藤島桓夫氏が歌う「月の法善寺横町」とイメージがごっちゃになり、おまけに、食べ物の「ぜんざい」と何の関係があるのか分からず、長い間謎の状態でしたが、今回、法善寺と言う実在する寺がある事を発見し、積年の疑問が解決しました。

法善寺横町の入り口。（写真左）
夫婦善哉の店も、法善寺の隣にあります。

もともとは、明治の頃、1人前のぜんざいを、量を多く見せるために2つのお椀にわけて出していたのが評判になり、店を切り盛りしていた母娘が、それを夫婦ぜんざいと呼んで説明し始めたのが発端で、その後、法善寺の近所に生まれ育った織田作之助が、法善寺横町を部隊に、自分の姉夫婦をモデルに小説を書き、 それが森重久弥主演で映画化されて有名になり、また作詞した「月の法善寺横町」も大ヒットしたと言うのが、法善寺が全国区にのし上がったストーリーのようです。

現在は、法善寺境内の水掛不動尊は、縁結びの神様、商売の神様として信仰されています。
筆者も、あやかろうと、水掛不動尊に水をたっぷりかけ、お祈りしてきました。


（写真右）観光客とおぼしき外人さんも一人歩きしている法善寺のこいさん通り。

日本の恒河

プロ野球ファンの聖地、道頓堀川に行ってきました。
通りすがりの人間にとっては単なるどぶ川ですが、プロ野球ファンにとっては聖なる河、
日本のガンジス川のようなものでしょうか。
数十年に一度、沐浴する人で河は溢れるとか・・・

ちなみに、数の単位の恒河沙（　＝10⁵⁶）は、ガンジス川（　＝　恒河）の砂の数というのが原義だそうです。

大阪なんば

今週は、大阪に出張に来ております。
宿は南海なんば駅の真上のホテルですが、目の下に通天閣があるのには驚きました。
筆者は関西生まれなのですが、恥ずかしながらあまりこちらの方に来た事がなく、通天閣も写真でしか見た事がありません。
さっそく、通天閣のそばで噂に聞く「きつねうどん」を食そうと、 適当に歩き回ったのですが、様々な小路が迷宮のように入り乱れて錯綜し、まるで異次元トンネルに入り込んだようにたどり付けず、元の場所に戻って仕舞いました。
しかし、薄暗い路地にほの明るい灯火を掲げるお店はどこも謎めいて魅惑的です。

また、プロ野球ファンの聖地、道頓堀川も近くにあるそうで、滞在中にぜひ訪れてみたいものです。

SysMLフォーラム やOCSMPの開始など

前回触れましたSysML関係のイベントが決定しました。
場所は慶應義塾大学の日吉キャンパスです。
参加費は無料ですので、SysMLにご興味のある方は是非ご参加ください。
左の「SysMLフォーラム開催！（８／３１慶應義塾大学にて）」のリンクをクリックするとSysMLフォーラムの案内へ飛びます。

また、本日、OCSMPが、来月8日（2010年9月8日(水)）から開始される旨の発表がありました。

と言うわけで、筆者もかなり最近は"SysML"に忙殺され、かつPM関係の仕事も重なり、貧乏暇なしの状態に陥っております。

ここしばらくは山手線の外側にすら出ない生活が続いていたのですが、先日暇を見つけて自宅そばの新宿御苑に行ってきました。

魔法瓶に冷たく冷やした麦茶を詰め、途中、近所の伊勢丹の地下食料品売り場で夏目漱石の「吾輩は猫である」や「三四郎」にもでで来る芋坂の名物、羽二重団子（写真参照）を購入。

そして 、新宿御苑にのりこみます。

筆者の自宅は、この公園の比較的近所なのですが（自転車で10~15分程度）、今まで一度も入った事が無く、なかなか新鮮でした。

夏目漱石ゆかりの羽二重団子を食べながら、明治時代に出来たこの公園の池の畔を眺めておりますと、明治と言う時代の特異性が彷彿としてきます。
「坂の上の雲」にも登場する漱石の友人で俳人の正岡子規も好物だったという団子の味が、今、完全に別世代の人間達にも賞味されていると言う事は、ひょっとしたら驚嘆に値する事なのかも知れないな、などと考えながら（あまり雑事を思い出したくないため、現実と無関係な事を考える習慣がいつの間にかついてしまいました）、園内の森や池をめぐりました。

SysML関係のイベントを準備中

筆者は旅行が比較的好きな方ですが、そういつもいつも出歩いていられないので、遠くへ行きたい気持ちを抑えて、普段は散歩程度に押さえています。

先日、ネットで調べ物をしていた折、自宅の近所に俳聖ー松尾芭蕉の墓（？）があるのを発見し、さっそく出かけてきました。
松尾芭蕉は、俳句の宗匠として一本立ちする前、桃青と名乗っていた頃に、神田上水のメンテナンスの仕事を何年かやっていたようで、その頃の彼の庵跡が、筆者の家から夏目坂を降って行った先、早稲田大学のそばにあります。
旧跡は関口芭蕉庵と言い、神田川の畔にあって誰でも見学が出来ます。

庭園内には、武蔵野台地からの湧き水を利用した池があり、傍らに「古池や、蛙飛び込む水の音」と書かれた立て札があります。

先に進むと「静けさや、岩にしみいる蝉の声」と言う立て札があり、静かな場所で、都会の喧噪から離れ、とても早稲田大学の隣にいるとは思えません。


百日紅の花が満開で、芭蕉の木（バナナの木に似ているが、バナナそのものではないそうです）も植えてあり、ちゃんと芭蕉の墓もありました。

iPadを矢立に、天空にそそり立つ積乱雲の峰を見上げて一句：

夏雲の上なる雲の頂きの風

筆者

芭蕉の木

さるすべりの花

＜＜お知らせ＞＞

SysML関連のイベントを大学関係者と共同で現在準備中です。
2〜3日中に、発表されますので、ご都合の付く方は、ぜひご出席ください。

SysML 中級講座： 第6回 要求図（１）

都会の涼の取り方

梅雨明け以降、全国的に猛暑が続いているようです。
こう暑いと何もやる気がせず、動作も緩慢になって来ます（普段から、そうだと言われそうですが）。
以前車を持ってた頃は、時間があると信州あたりにさっと行けたのですが、今の場所に越して来て以降、全く乗らなくなり手放してしまったので、こういう時は不便です。

今回は、筆者が時々やっている都会の涼の取り方を紹介したいと思います。
自宅の近所を走る都営新宿線は京王線と乗り入れしており、そのまま乗っていると、調布とか府中とか言う奈良時代を彷彿とさせるような地名の場所に連れて行ってくれます。
さらに乗っていくと、「高尾山」と言う京都にありそうな名前の山の麓まで行きます。

ケーブル地上駅前

このあたりは京都の高雄と同じく紅葉の名所です。
さらに、高尾山周辺は、京都風の地名が多い事でも有名です。
筆者は、時間がない時は山に登らず、名物の蕎麦だけ食べて帰る事もあります。
ここまで来ると空気は山の涼気を含み、普段なら十分に涼しいのですが、孟夏の今週は、ここでさえ暑く感じますので、さらに足を伸ばして、ケーブルかリフトに乗って高度を上げます。

高尾山リフト

ケーブルカーの方が速度は速いのですが、リフトは山の風を切って走り、爽快感が違いますので、今回はリフトに乗ります。

ケーブルの頂上駅付近

麓の駅との標高差270メートルで、頂上の駅を降りると、木陰は結構涼しげな風が吹いています。
昨年、ミシュランの三つ星（最高ランク）に登録されてからは、外国人の姿も結構見かけます。

参道をぶらぶら歩いて、薬王院まで散策しても良いですし、サル園野草園もあります。
また、夏の夕方限定ですがビヤガーデンも営業中です。





要求図　（１）
SysMLには、UMLにはなかった図がいくつか登場しますが、要求図はその1つです。
しかし、全く新しい図ではなく、言語的にはクラス図の一種となります。
UMLのプロファイリングの機能を用い、新しいステレオタイプ　≪requirement≫　等を追加して図を構成します。

プロファイリングを用いて言語拡張を行う事に賛否両論がありますが、現状は賛成派が多数派を占めているようです。
何と言っても、便利なのは、何の断りをする必要なく、同じクラス図の系統を引く他の図、例えばブロック図、との混在・併用が可能になる点です（広い意味で、要求であろうが、ブロックであろうが、クラス図です）。
これは、オブジェクト指向言語（プログラミング言語の方）の性質と似たようなものですが、複雑な設計を行う時には大変便利です。

不思議なもので、人間の脳は具体的なものほど理解は進みますが、具体的なままでは複雑な操作に耐えられなくなります。
喩えて言うと、コンピュータの動作原理を理解する上では二進法表記は役立ちますが、複雑なシステム設計では二進法表記は具体的すぎて人間の脳では耐えられなくなります。
対象が複雑になればなるほど、抽象化しないと議論が出来なくなります。

神戸旅行

三連休は母校の同窓会があったので、故里の神戸へ帰りました。
ちなみに、神戸生まれの人間は神戸に帰る事を”帰神”と略します。また、東京へ行く事を上京とは言わず、江戸へくだると言います（冗談です）。

友人が、どこか案内してくれるというので、ブログ用の写真が撮れる神戸旅行らしい場所と所望したところ、次の3つの候補地を挙げてくれました。

1. 「北野工房のまち」→「北野の異人館」→「布引ハーブ園」を回る。
2. ハーバーランド〜モザイク方面に移動し、神戸の港の風景を見物（ポートタワーに上る？）
3. 変わったところでは、ポートアインランドにある神戸花鳥園に行ってみる

 筆者は、3番目の花鳥園が初耳でしたので、迷わずそこを選びました。

帰神の当日、神戸花鳥園の前で、友人と、友人の知り合いの美女の2名にお出迎え頂き、美女の案内で花鳥園を巡りました。
彼女は、花鳥園のファンだそうで、あちらこちらに我々を引率してくれました。
この花鳥園は予想以上と言うよりも、むしろ最高の場所でした。半分を廻らないうちにカメラのメモリーが無くなってしまいました。

さて、約束通り、写真をブログに貼ります。
かなりの枚数を撮り、もちろん美女の写真も撮りましたが、代表してフクロウの写真をアップロードします。
まるで縫いぐるみのようですが、本物のフクロウです。
フクロウは頭が良く、飛行ショーでも活躍してますし、カメラを向けるとこのようにちゃんとポーズも撮ってくれます。

花鳥園のあと、3人で三宮神社の近くのレストランで和食を食べ、そのあとジャズのライブ演奏の店に行き、最後は手打ち蕎麦が食べられる和風バーへ行き、神戸の夜を堪能しました。
すべて、友人がこの日のために事前に予約を入れて置いてくれた店ばかりでした。
有り難うございました。

SysML 中級講座： 第５回 MBSEの利点 その３

筆者も最近はiPadを手に入れ、会社のメール・システムも社内サーバーからグーグルに換えて、一応世の中の流れを実感しようと言う努力を続けています。

iPad+Googleの使用感は噂通りやはり良く、今までは外出時は重いMacを鞄に入れて運んでたのですが、最近ではたいていの場合、iPadだけで済むケースが多くなってきています。

筆者のような人間でさえこんな状態ですから、最近のビジネスマンが高機能な携帯や小型の情報端末を持つ理由は非常によく分かります。

 一言で言うと遊び感覚で、いつもオンラインにアクセス出来る所でしょうか、メリットは。

さて、前回、前々回に引き続き、MBSEのメリットについて議論します。

3. 設計品質の向上が図れる

3-1 　設計をモデル表現する事により、エラーと曖昧さの低減が期待できます。

3-2    モデル図を組み合わせる事により、より一貫性のある設計が行えます。

４．早い段階から継続的にベリフィケーションとバリデーションを行う事が出来、リスクの低減が図れる

ベリフィケーションとバリデーションと言う言葉は、日本語に直訳すると共に検査ぐらいの意味になってしまいますが、システム工学に限らず、品質に関連する分野では、このベリフィケーションとバリデーションと言う2つの言葉は厳密に使い分けられています。

一言で言うと、ベリフィケーションはHowに焦点を当て、バリデーションはWhatに焦点を当てた検査と言ったあたりでしょうか。

言い換えると、ベリフィケーションは正しく作られたかをチェックし、バリデーションは正しいもの、つまり顧客が真に望んでいるもの、を作ったかをチェックします。

例を挙げると、顧客はiPadのようなものを欲しがっていたが、設計部隊は高品質のクッション付き眼帯を作って仕舞ったとすると、ベリフィケーションは通るかも知れませんが、バリデーション・テストは不合格です。

５．ライフサイクルを通して価値を提供

モデル図は、単に設計製造の時に使うだけではありません。

FCS後のメンテナンスや、トレーニング、改造、廃棄の際にも有用です。

６．知識の獲得を容易にする

洋の東西を問わず設計スキルを身につける事は時間のかかる事です。

モデル図により、情報の明確化が計れ、知識の習得をある程度容易にします。

SysML 中級講座： 第４回 MBSEの利点 その２

あちらこちらで雨の被害のニュースを聞きますが、皆様のお住まいの地域はいかがでしょうか？

前回に引き続きMBSEの利点について議論します。

２．複雑なシステム設計過程の管理を容易にする

2-1  統合モデルを様々な視点で捉え関心の分離が行える。　

モデリングというのは情報の抽象化を伴います。

そして、モデラーが最も留意しなければならない所は、この抽象化の過程で大部分の情報が捨てられてしまっている点です。

モデルは通常、ある一定の視点から描かれますが、複雑なシステムであればあるほど異なる複数の視点でモデリングを行います。

例えば、自動車と言う1つの対象をとってみても、機械屋の視点から見たモデルと、電気屋の視点、ソフト屋の視点とでは全く異なった絵になります。

そして、各々の分野の専門家が独立して行える部分と、他分野の専門家と協調しなければならない分野があり、統合モデルは、その分離と管理を容易にします。

２−２　階層的なシステムモデルを用いてトレーサビリティをサポートする。

筆者が前回のOMG技術会議に出席した際、NASAの安全品質担当の一人の博士が、要件のトレーサビリティが機械的にツールで行える事の重要性を訴えていた事が印象に残っています。

上位の概念設計のレベルから、下位の実装設計のレベルに行くに従って、情報はどんどん変形して行きます。

セマンティックなアプローチでは、対象のシステムの大きくなるにつれ、複雑さが人間の注意力を完全に超えてしまいます。

情報のトーレスが機械的に行えるような言語とツールが必要になってきます。

３−３　要件や設計の変更の影響分析を容易にする

要件が変わったり、設計変更を行ったりする事は、良いか悪いかの問題ではなく、そもそも人生がそうなっているのであり誰にも止められない問題です。モデリングにより、変化の影響分析が容易に行えます。

3−4　インクリメンタルな開発にも、進化論的獲得（革新的進化）にも役立つ

今日の設計の現場は、いわゆるウォーターフォール型ではなくインクリメンタルな開発が主流です。モデリングはもともと、そう言った開発論と共に発展して来た方法です。

また、同時に、抽象化したモデルから、革新的なアイディアが生まれる事も良く報告されています。

（次回に続く）

SysML 中級講座： 第３回 MBSEの利点 その１

最近は太りすぎで血圧が高めなので、一念発起して、一日最低５００メートルの水泳を自分自身に義務付けています。
また、食事も暴飲暴食はやめ意識的に軽く済ますように心がけた結果、始めてから一週間で3キロ痩せました。
この分で行くと3ヶ月もしないうちにベストの状態に行けるんじゃないかと思いますが、毎日泳ぎに行くのは結構辛い・・・

MBSE モデル・ベースト・システムズ・エンジニアリングの利点 　その１

システム工学の歴史は古く、コンピュータ発明以前から存在していた事は先に述べたとおりです。
またシステム工学とモデリングの親和性はむしろ本質的です。
しかしながら、システム工学用のモデリング言語はソフトウェア系に比べるとかなり後発でした。
これは、いくら好条件がそろった商品でも需要がなければ全く売れないのと同じで、いくらモデリングと親和性の高い分野だと行っても、モデリングのニーズやメリットがなければ誰もモデリングなんてしないのは理の当然でしょう。

ところが2007年のSysML1.0の登場以来（わずか3年前）、システムズ・エンジニアリング分野はモデル・ベースのものに急速にシフトしていっています。
この普及の急速さは、UMLの時とは比べものにならないくらいです。
もちろんUMLの時と比べ環境的な条件が遥かに整っている事は事実ですが、何かメリットがあるはずです。
今回はMBSE(Model Based Systems Engineering)の利点を見て行きましょう。

1. 要件や設計の共通理解が容易
      モデルではなく従来の文書によるシステムズエンジニアリングの欠点の1つは、表現の曖昧さでした。曖昧な表現のままコミュニケーションを行うわけですから、時には大きな誤解を生み出します。　その結果様々な問題が発生します。

1-1 　文書ベースでは、要件そのものを間違えやすい、あるいは正しい事を検証できない（バリデーションの問題）のに対し、モデル・ベースでは検証が容易になる。

1−2　昨今のシステムの開発では、要件の分析と設計は一体となって行われる事が多いが、
モデルはその分析設計の共通基盤を提供してくれる。

1-3   モデル分析により、リスクの発見が容易になる。

まずは文書ベースのアプローチに比べMBSEは以上のような基本的なメリットがあります。

（次回に続く）

SysML 中級講座： 第２回 システム工学とSysML

SysML言語の詳細に入る前に、システム工学とモデリング、そしてSysMLの関係を概観しましょう。

まず、システム工学ですが、これ はコンピュータが発明される以前から存在する学問分野で、最初は人間系が主な対象でしたが、機械系、電気系システムの発展とともに対象が広がり、かなり広 範囲な学際的特徴をもつ分野です。
近年、コンピュータの登場とともにますます対象エリアは広がり、かつ非常に複雑なシステムを扱うようになってき ました。

システムズ・エンジニアと言うと日本ではITシステムを設計する技術者、特にソフトウェア技術者を指す言葉として定着しています が、これは日本固有の現象で、欧米ではシステムズ・エンジニアと言うと、第一義的に船舶とか航空機、ロケットなんかを思い浮かべる人が多いようです。
こ れは、システムズ・エンジニアと言う言葉が、それぞれの国で、どのような対象とともに登場して来たかを暗示しているのではないかと思います。
おそ らく日本では、IT系のシステムズ・エンジニアの登場以前には、システムズ・エンジニアと言う言葉が一般には馴染みのないものだったのではないかと想像し ています。

MBSE モデルベースト・システムズ・エンジニアリング

そして、モデリングとシステム工学も古くて新しい話題です。
そもそ も、システム工学にはモデリングというコンセプトを始めから包含していたとも言えます（例えば、数学モデル）。
また、モデリングと言う概念も拡張 しようと思えばいくらでも拡張できる訳で、例えばニュートン力学なんかは、自然対象を非常に高い精度で近似できる数学モデルという見方も可能です（もちろ んニュートン卿は、けっして近似モデルを発明発見したとは思ってなかったと思いますが）。

さて、現代的な意味でのモデリングはここ十数年 の間に急速に発達してきました。

始めは組込みソフトウェアの現場から

UMLは最初はソフトウェア開発、なかんずく上流行程で発生する様々な問題に対処するために誕生し ました。
しかしながら、組込み系ではいわゆるIT系のUMLでは事足らず、ソフトウェアを取り巻くシステム環境がモデリング出来ないと分析設計そ のものが不十分であるという壁にぶつかり、９０年代後半あたりから独自の拡張をUMLに付け加えるようになってきました（当時、OMG内には、そう言った 問題に対処するSIGも誕生しました）。
このような「システム」を記述するためのUMLの拡張は、その後、UML2.0に取り入れられた形で発展 して行きます。
恐らく、IT系のみを担当するソフトウェア技術者の中には、UML2.0とともに登場した図の中に、何のためにあるのか分からない 表記法の存在に当惑した経験をお持ちの方が少なからずいらっしゃると思いますが、その多くは「システム」を記述するための（UML2.0の）拡張部分で す。

INCOSEとOMGの協同体制の発足

この様に、最初は組込み系システムの現場から誕生したシステムのモデリングと言う概念は、 ２０００年代に入ると、より大きな問題、より広範なシステムに対処するべくOMGという組織の枠を超えて広がって行きます。そして、システム工学の本家、 INCOSEとOMGの共同作業が始まります。
次の表はINCOSEとOMGの協同体制の発足からSysMLの誕生までの年譜を示しています。

• 2001年 INCOSEとOMG間で協議開始
• 2002年 RFI 発行 ー 市場から広く情報を集める
• 2003年 RFP発行 ー 市場に提案を求める
• 2007年 SysML 1.0
• 2008年 SysML 1.1
• 2010年 SysML 1.2

初期の段階では、システムをモデリングするための言語としてUML以外のものも検討されましたが、様々な理由、例えば、組込み系がUMLを使っ てシステム・モデリングを先行させている、既にUMLは学校等で教授されていて市場に馴染みがある、ソフトウェア設計との親和性、UML以外の言語でメタ モデル構造が標準化されている言語が無かった、等々の理由で、比較的すんなりとUMLをベースに言語を開発する事については合意されました。
しか しながら、その後のSysMLの詳細を詰める過程では議論は大もめにもめ、対立するグループが二派に別れて、それぞれが別々の言語仕様を作ると言った事態 にまで陥り、一元化するまでの間、半年以上の日月を空費するような事もありました。
SysML 1.0の誕生までに発足から約６年かかりましたが、関係者の努力の賜物と言えるでしょう。


誕生の経緯からお分かりの通り、 SysMLはモデルベースのシステム工学のための言語、道具です。目的か手段かと問われると、あくまでもMBSEを行うための手段です。
本講座で は、SysMLの言語的特性に焦点を当てて議論を進めますが、あくまでも道具である事を忘れないようにしていきたいと思います。

次回は、 システム工学をモデルベースで行う事に、どんなメリットが有るのかについて議論します。

SysML 中級講座： 第１回 開始！

本日から、SysML中級講座を始めます。
最初に、何をもって中級と名付けたかについて触れておきたいと思います。

SysMLとOCSMP

現在、INCOSE(International Council Of Systems Engineering)とOMGの協業でOCSMPと言う資格試験の開発が進んでいます。
このOCSMPですが、OMG Certified Systems Modeling Professional と言う名称が示すようにシステムをモデリングする専門家のための認定試験です。
従っ てSysML言語そのもののテストではなく、システムのモデリングに関する知識を問う設問が中心となっています。
しかしながら、モデリングとモデ リング言語は極めて密接な関係があり、喩えて言うと日本文学と日本語の関係、あるいは数学と数式の関係のようなものであり、言語を理解せずに文学を学ぶ事 が実際不可能なように、モデリング言語を知らずにモデリングを実践することは殆ど不可能です（少なくとも、他人が書いたモデル図を読む事は不可能）。

OCSMP は全部で４つのレベルから構成されていますが、試験体系の設計に関しては、このモデリングとモデリング言語の関係、及び、個人の学習に関する成熟度が強く 意識された形になっています。
下の図は、OCSMPの４つのレベルを示しています。

 OCSMPには２つのグループがあり、１つはモデルユーザー、もう一方はモデルビルダーと名付けられていて、モデルビルダーはその名前の通りモデルを構築 する人、つまりシステムを設計する人間を対象とした区分であるのに対し、モデルユーザーは、システム設計者に対し情報を提供したり、あるいは逆に情報をも らったりする人たちです。

実際の現場でもこの区分は良く当てはまり、システム設計を行う人間・グループを中心として、その周辺にはハード ウェア設計者（例：筐体や電子回路）やソフトウェア設計者、そして各々の分野の専門家、例えば社会学者や原子力科学者、物理工学者等々、が取り巻 いています。

そして、モデリングの学習は、他人が書いたモデル図を正確に、過不足なく読み取る事から始まります。

実際、 OCSMPのエントリーレベルであるモデルユーザーの試験は、モデル図を読む能力に主眼が置かれ、モデル図を読み取る上で必要なスキル、知識が試されま す。

言い換えると、エントリー・レベルでは言語の解釈能力を問う問題が中心的です。

一方モデルビルダーは、モデル図を描く人を想 定した出題群からなります。

モデルビルダー初級は、モデル図を描く上で必要な基礎知識が試され、中級、上級になるとモデリングを行う上で必要とな る知識・スキルが試される傾向にあります。

また、中級、上級となるにつれ言語に関する問題も高度化していく傾向がありますが、モデル図を描く上で 必要な知識に限定され、決して単純な文法問題になってしまわないよう配慮されています。

本講座では、モデルビルダー中級程度で必要となる ようなSysMLの知識を想定して進めて行きたいと考えています。

これは、モデルビルダー中級は、一般のシステム製品の設計者を想定した試験区分 である事、そして上級はSystem of Systemsと言うような巨大もしくは複雑なシステム設計者を想定した出題でありMBSE(モデル・ベースト・システムズ・エンジニアリング）中心の出 題になる事が予想され、言語色が薄れる事、等を勘案して設定しました。

また、前提としてUML初級（ファンダメンタル）程度の知識を読者 に想定しています（SysML言語は、UMLを拡張した言語であり、一種のUMLとも言える。）

UMLの入門的な知識に関して知りたい人 は、各種書籍や iStudyシリーズの「iStudy for OCUPファンダメンタル」などのE-ラーニング教材などをお奨めします。

アーキテクチャー：メタモデルのすすめ ⑥

９０年代以降、アーキテクトは、その方向性を大きくモデリングの方へ舵を切って行き、またそのモデリングも具体的なものから抽象的なものへとシフトして来 ています。
また、アーキテクトの基礎知識として、モデリング技術は当然として求められますが、最近ではメタモデリングの知識も必須項目となって来 ています。

恐らく、このブログを読んでいる人にメタモデルの重要性を訴える事は、釈迦に説法だと思いますので、ほどほどにしたいと思いま すが、そもそも、何で日本ではアーキテクチャーとかメタモデリングが発達しないのかは、筆者にとっても最大の関心事ですので（あるいは、日本にとっても非 常に重要な問題だとも思いますので）、少し触れてみたいと思います。

先日、友人と寿司屋に行った際にもこの事が議論になりました。
ど うも今の日本のカルチャーの中では、無形なものに価値を見いだす事が難しい、と言うよりも、さらに悪い事に、無形なものに対して、ニュートラルではなく負 の評価を行う傾向があるんじゃないか、と言う命題が議論の中心でした。

概念的、あるいは抽象化した議論は、ややもすると言葉遊び的に捉え られ、具体性がないとか、（具体的な）結論を先に言え、と言うような否定的な評価につながり易い傾向があるのは、ITに限った事ではなく、殆ど日本のすべ ての分野で見られる傾向です。
筆者も海外で仕事をする前までは、具体性を好む人間の一人でしたので他の日本人を批判する資格は全くありません。

し かしながら、海外での仕事を通じて、考え方の違いや仕事のアプローチの違いを見るにつけ、日本のやり方が必ずしもベストではない事、結果を生み出さない事 を痛感するようになって来ました。

よく言われる事ですが、哲学（西洋哲学）は欧米では、結構身近な話題です。存在論メタモデルなんて言う話題は、ビジネスマンでも好んで口にします。（余談 ですが、哲学用語は、使うと話が高級そうに聞こえるため営業トークでも頻出しますが、これはやり過ぎでしょうね。）

もっとも欧米人と言っ ても、人によりますので、具体的な話しか好まない人も多くいます。ただ全体的に言って、抽象的な議論に対してネガティブな見方をしない、概念的な作業に価 値を見いだしている傾向があります。
それに対して、日本では「もの」が価値の中心であり、サービスは「もの」に付随する「おまけ」的な見方が相変 わらず続いています。

しかしながら、昨今、日本企業の経営陣の世代交代が進みつつあり、それにつれて考え方も少しずつですが、変わって 行ってる事を実感しています。

貴重な時間を割いて、このアーキテクチャーやメタモデルに関するブログを読んで頂いている方達ー世代が、今 後の新しい時代を作る、と期待しています。


次回からは、OCSMPの資格試験も近々始まる事から、SysMLに関してシリーズで 書いて行きたいと思います。

アーキテクチャー：メタモデルのすすめ ⑤

以前OMGはアーキテクトの集まりだと書きましたが、もう少し正確に言うと、昔からそうだったわけではなく、また全員が必ずしもアーキテクトと言うわけで はありません。

OMGはもともとはCORBAに代表される分散処理技術者の集まりでした。人的、歴史的には、80年代に流行った人工知能 (AI)をやってた人が流れて来たパターンが多いようです。
では、いつ頃からアーキテクトが集まりだしたかというと、90年代の半ばにUMLの標 準化が始まりだした頃からです。
その頃から上流工程に従事するエンジニアがモデリングに興味を示し始め、アーキテクトの割合が増加してきました。
2000 年前後になるとITソフトウェアだけではなく、ハードウェア設計にもUMLを使う動きが顕著になってきて（ハードウェア設計と言っても上流設計、概念設計 です。念のため）、UMLバージョン１のソフトウェア中心の表記法では用が足らず、より論理的な構造を持つモデリング言語（メタ言語構造を持つ言語）とし てUML2.0が誕生しました。
2001年には、INCOSE(International Council of Systems Engineering：直訳すると国際システム工学学会ぐらいか？）と共同で現在のSysMLのひな形を作る作業が開始されました。
ちなみに SysMLは、UMLの自己拡張機能、プロファイリング機能を用いて作られていますので、厳密に言うとUMLの一種です。
また、話がそれますが （ブログなので流れのまま書いてます）、現在、プロファイリング以外の言語拡張の手法が検討され始めており、今後違った動きも見られると思いますが、恐ら くここ１０年はプロファイリング中心のやり方になるでしょう。（SysMLのひな形誕生から普及まで（つまりツール・ベンダーによってツール化されるま で）に7〜８年かかっていますので。）
2000年ぐらいには上流側の分科会（プラットフォームに対してドメイン側で、ファイナンス・タスクフォー ス等のように産業別に作られ始めました）が徐々に活発になり、BPMI(ビジネス・プロセス・マネジメント・イニシアティブ）との合併はドメイン側へのシ フトを決定づけました。
また世の中のお金の流れもプラットフォームからドメイン側に代わり、IT産業の主役もプラットフォームを作っているメー カーから、先進的な利用を行っているユーザー側にシフトし始めます。
そして、従来のアーキテクト中心のメンバー構成にビジネス・アナリストの集団 が融合し始めます。
ビジネス・アナリストの参入はOMGにとって業務構造へのより深い興味をかき立てました。
また、ビジネス・アナリスト は当初UMLに抵抗示す人もいたのですが、急速にモデリングの有用性に興味を示し始めました。

また余談ですが、ビジネス・アナリストの中 には、当初、BPMはBPMNを用いて書かれた業務フローをBPELを通してWebアプリケーション化すれば、それでOKだと言う（楽観的な）人もいたの ですが、融合の結果、それでは済まない問題が膨大にある事が、アーキテクト側もビジネス・アナリスト側にも共通の認識として拡がってきました。
恐 らく、基幹業務系はBPM/SOAが、そしてエンド・ユーザー系にはWeb技術に代表される廉価で高速なクイック・ソリューションがクラウド市場の中心を 占めていくと思います。

アーキテクチャー：メタモデルのすすめ ④

要件分析・概念設計の日本固有の現象

創造性の軽視

前回は上流設計の重要性を書きましたが、仕事柄、筆者は開発プロジェクトに関与する事が度々ありますが、最近はつくづく、 その違いを考えさせられます。
最近は日本でもUMLの使用率がかなり上がって来ていますが、大半が実装設計以降での下流工程での使用が中心的で す。

最近はオフショア開発の条件として要件仕様をUMLで書く事が条件になるケースも多いのですが、現地のエンジニアからは、日本の UMLは要件を本当に分析したのか？とか、分析した形跡がまったく見あたらない、と言う意見を聞きます。
「要件仕様をUMLで書いてくれ」と言う リクエストは、国際的には「要件をオブジェクト指向分析設計してくれ」とほぼ同義語ですが、日本人は文字通り、単に表記法としてUMLで書く、と言う意味 で捉えられてる形跡があります。

巷間、日本の携帯電話がなぜ海外で売れないかが一時話題になりましたが、多くの人は、実装技術ではなく要 件分析等の上流工程の品質の問題を指摘していました。
本来、要件設計や概念設計は製品やサービスの価値を決める最もクリエイティブなフェーズであ り、モデリング技術も本来そのために発展して来たものですが、全体に日本のエンジニアは実装設計には熱心ですが、上流工程にモデリングを持ち込む事が苦手 なようです。

アーキテクチャーも同様な傾向が見られ、上流工程のアーキテクチャーよりも実装のアーキテクチャーにのみ関心が集中する傾向 があります。

アーキテクチャー：メタモデルのすすめ ③

前回、筆者が80年代にアメリカにいた頃の話を書きましたが、その当時は、たまに日本に帰ってくると、時間を見つけては日本の港町に旅行に行きました。
 羽田空港からそのときの気分のまま適当に切符を買い、着いた地方空港でレンタカーを借りて、気の向くままドライブしましたが、どういう訳かよく海の方、港 の方へ足が向きました。
そんなある日の事、筆者は、半日のドライブの後たどり着いた小さな漁港に面した居酒屋兼旅館と言った風情の店が気に入り、 ふらりと暖簾をくぐりました。
海の上に大きく赤く腫れぼったい天空の目のような満月が上り、そこは井伏鱒二氏の描くような浪漫的な夕暮れの港町でした。
こんな町で暮らす事が出来たら、どんなに素晴らしい人生だらうか、と若かった筆者はこの静かな美しい港町の生活を想像しながら宿を請うと、奥からごく若い 愛想の良い女将さんが宿帳を持って現れました。
女将さんは、筆者のペン先を見ながら、筆者が「神奈川県」とか「横浜市」と言った当時の住所を書いていくたびに、「はぁ〜」と深いため息をつき、「○○ 区」とか「××町」と進み、所番地あたりを書くあたりになると彼女の感嘆は最高潮に達しました。
彼女の不思議な反応が気になり、筆者は書く手を止めて顔を上げて彼女の顔を見ました。
女将さんは、「昔住んでいた町のすぐそばの所番地だったので、懐かしさのあまり声を上げて仕舞いました」、と訳を話し非礼を詫びました。
彼女は数 年前にこの港町にお嫁に来て、以来一度も横浜には帰っていなかったそうです。
そして、時たま何の目的も持たずふらりと風のようにやって来て、また 風のように去って行く旅の人が現れるが、心底羨ましいと語りました。

人間は、お互いに、自分のないものを羨むもののようです。

上流行程の重要性とその限界

ソフトウェア工学によると、ソフトウェアの品質に最も影響を与えるのは設計フェーズの品質であり、その設計 に決定的な影響力を持つのが要件フェーズです。
オブジェクト指向分析設計も歴史をひも解くと、元々は要件の分析と概念設計の為にモデリング言語が 開発されました。
従って、UMLは本来要件フェーズで最も活用されるべきツールです。
しかしながら、日本での使い方は圧倒的に実装フェー ズで実装設計のツールとしてのみ使われる事が多いようです。
本来、要件を記述するための言語であったUMLがむしろ実装設計にのみ用いられる状況 は、恐らく日本固有の現象のようです。

これは、実装のアーキテクチャーにのみ興味があり、上流部分（ドメイン側）のアーキテクチャーに無 関心な現況とも一致する現象です。

全体に東アジア圏の国々（日本、韓国、中国等）は、実装技術に強い関心を示す反面、ドメイン側に対する 興味は非情に薄いと言われていますが（興味が薄いのではなく、アーキテクチャーやモデリング技術を上流行程に持ち込む発想が薄いだけだと思いますが）、日 本はその傾向が顕著なようです。
理由はともあれ、日本は結果的に上流行程のアウトプット品質が非常に悪いと言う定評を得つつあるのは残念です。
特 徴的なのは、UMLを使わないから悪いのではなく、UMLを用い て書いた要件仕様でも、分析を行なった形跡がなく、単なる表記法としてのみ用いられていて品質の向上が見られないと言うのが平均的な現況の ようです。

昨今のこの状況に対し、日本でも要求フェーズの品質を高める事が脚光を浴び始めて来ました。
しかしながら、水をさすよ うですが、要求フェーズの品質向上だけでは、大した改善は期待出来ない、と言うのが歴史的事実です。

アーキテクチャー：メタモデルのすすめ ②

前回の続きです。

デジャヴ

知人から聞いた携帯電話のソフトウェア開発の現場の話です。
過去の仕様変更の嵐と度重なるスパゲッティ・プログラミン グ、そして一貫性のないパッチワークの積み重ねの結果、もはやソフトウェアが時限爆弾化してしまい、下手に中に手を加えると大爆発を起こす恐れがあり、今 では、出来るだけそ～っとしておき、何か環境が変わると中ではなく外側にソフトウェアをかぶせるようにコーディングし、その場を凌ぐような事態が常態化し てしまったそうです。
彼曰く、日本の携帯はガラパゴス的な仕様の為に死ぬのではなく、ソフトウェア開発の行き止まりによって滅ぶ、ー つまり外敵が来なくても環境変化だけで死ぬ運命にある、と言切っています。
これほど大袈裟な話ではなくても、日本のソフトウェア開発現場ではしば しば聞く話です。
果たして、これは日本固有の話でしょうか？
ー 決してそうではありません。筆者も若い頃ソフトウェア開発現場にいたのですが、アメリカでもフランスでも同じような光景を見た、と断言出来ます。

東海岸

1980年代、筆者はある北米にある通信制御装置（ルーター）の開発部門におりましたが、状況は似たようなものでした。
度 重なる要求の追加、仕様変更の嵐で、コードはどんどん荒れて行きました。
当時勤務していた会社は既にネットワーク・アーキテクチャを標榜しており ましたが、それが事情をさらに悪化させていました。
と言うのも、当時のソフトウェア・アーキテクチャの技術が未熟な上に、市場は非アーキテク チャーの古いプロトコルが大勢を占めており、その非効率なコードがメモリー上に混在し、なおかつ当時の貧弱なプロセッサ・パワーを独占しておりました。
そ の結果、コードの品質が機能の追加更新に耐えられず、頻繁に新しい版を起こし、要求仕様から始めて新しく作り直していました。
（古い版は、最小限 のバグ・フィックスに留め、そ〜っと枯れ死ぬのを待っていました。）
良く誤解されるのですが、このコードの荒れ方は、必ずしも開発規模や機能の数 に比例しません。
通信制御装置よりもさらに膨大な変更の嵐を被っているメインフレーム上のコードよりも、ハードウェア制約の厳しい（つまりハード ウェア資源の貧弱な）通信制御装置上の小さなソフトウェアの方が、早く行き詰まってしまうのです。
メインフレーム上の通信ソフトがたった１回しか 版を変えてない間に（つまり、一回しか要求仕様からの作り直しをしていないのに）、通信制御装置は４回以上版を変えていて、メインフレーム系のエンジニア から怪訝な面持ちで質問された事が度々ありました。（彼らから見ると、たいした機能追加もしてないのに何故そんなに頻繁に版を改めるんだ？と言う気持ち だったでしょう。）

昨今、日本の携帯電話はガラパゴスと呼ばれ揶揄されておりますが、日夜頑張っておられる現場のプログラマーの方々には 同情いたします。
おそらく限られたハードウェア環境が、状況をさらに悪化させていると思います。
適切な方法論がないとコード品質が落ちる のは、プログラマーの能力の問題ではなく、文化国籍の問題でもなく、いわば自然現象なのです。

アーキテクチャー：メタモデルのすすめ ①

先日、学生時代の友人と一緒に高尾山へ行ってきました。
下山後、蕎麦屋で雑談をしているうちに、話題が筆者も多少関与しているグローバル・ス タンダードの話になってゆきました。
彼は、IT部門にいた事はないのですが、ユーザー部門、経営企画部門にいた事もあって、ITにまったく無縁と 言う わけではなく、標準化団体としてOMGの名前だけは聞いた事があったようです。

旧知の気楽さからか、彼はぽんぽんと非常に基本的な 事を盛 んに聞いてきました。
筆者が、「OMGはおもにアーキテクチャーを扱う団体で、最近では会員はITメーカーよりもユーザー企業の方が多 い。」と言 うと、彼は怪訝な顔をして「メーカーのエンジニアがOMGに参加するのは分かるが、ユーザー企業は何のために参加しているのか？」と言う素朴な疑問をぶつ けてきました。
彼にとっては単純な質問だったのかも知れませんが、筆者にとっては、この質問は、ある意味、日本のIT産業を象徴しているように 感 じて少しぎょっとしました。
と言うもの、OMGの参加状況において日本だけ特異なパターンを示す一つの原因に出くわした気がしたからです。
OMG は、欧米を中心に世 界のおもだった企業、組織が参加しており、先に述べた通り、ITベンダーよりもユーザー組織の方が多いのですが、日本だけは面白いことにベンダーが圧倒的 で、ユーザー企業が殆ど参加していません。

従って、世界のユーザー 企業が何故アーキテクチャーの標準化団体に参加するのかを彼だけに説明するよりも、ネットに掲載する方が多少とも世のため人のためになるのではないかと思 い、久しぶりにこのブログを立ち上げました。
（彼にも、このブログを読むよう指示しました。）

　

昨今のアーキテクト事情

９０年代半ば頃より前は、ユーザー企業にアーキテクトを置く事は殆どなかったのですが、最近ではある程度のIT規模を持つ欧米の企業の殆どは、アーキテク ト のグループを内部に置いており、かつ中心的な役割を演じるようになってきました。
名称や社内の位置づけは様々ですが（CIOの直下が多いよう です）、エンタープライズ・アーキテクチャーを扱ったり社内標準を扱ったり、場合によってはBPM/SOAを扱う部署と同居したしております。
OMG の中心的な活動に参画するのも、こう言ったアーキテクト達です。

メーカーのアーキテクトとユー ザー企業のアーキテクトの観点はちょっと違いますが、友人の素朴で根本的な疑問である「何故、ユーザー企業が高い金を出してアーキテクトを雇い、なおかつ OMGの ような外部団体の活動までさせているのか？（この不景気なご時世に）」を次回から考えて行きたいと思います。