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

以前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の ような外部団体の活動までさせているのか？（この不景気なご時世に）」を次回から考えて行きたいと思います。

OCRESブログ 第19回 データ中心 出版ー購読モデルについて

昨年末、茨城県の日立市にリアルタイム系ソフトウェア工学の講習会に講師として行った際、現地の方のご自宅に招待されると言う事がありました。

訪問したお宅は、山の中の山荘と言った風で、床も柱も調度品もすべてが木製で、いかにも趣味人的なお住まいで、筆者の住む都心のマンションとはすべてが正反対の趣でした。

筆者もかつては郊外に暮らした事もあったのですが、最近の都心回帰の波に流されて現在の住処と成りましたが、元来が自然派ですので都会暮らしもだんだん疲れて来ており、この山荘風のご自宅を拝見し、筆者もそぞろどこかへ自然回帰したくなって来ました。
真っ先にあたったのが、八ヶ岳近辺の高原ですが、時刻表を調べると東京まで片道４時間ぐらいかかり、往復８時間の通勤は極めて非現実的なので諦めました。

世界的に見ても、知識集約型産業は、大都会ではなく歴史的な中小都市、観光都市の近郊に発達していますが、これは単に効率だけが産業の鍵ではない事を暗示しているようです。

筆者の転地先ですが、今は鎌倉とか逗子・葉山辺りを検討しております。

データ中心・出版ー購読モデル について

OMGの標準の一つに DDS(Data Distribution Service)があります。
この仕様は、元々は軍事アプリケーション、特に分散ハード・リアルタイム系システムのために作られたものですが、面白い事に当初予想された分野を遥かに超えて普及してゆき、民需分野でも広く使われるようになって来ました。

標準仕様も商品と同じく、これは普及すると思ったものが案外流行らなかったり、ごく一部での使用のみを想定していたのに、予想以上に受け入れられたりするものですが、このDDSは後者の代表例として挙げられるでしょう。
この標準が広く受け入れられた最大の理由として、アーキテクチャの基本として「データ中心・出版ー購読モデル」を採用した事が挙げられます。
このモデルは、ご存知の通りOCRESにも出題されています（概念モデルが出題の対象。実装モデルは出題の範囲外です）。
このモデルは、非常に解りやすく、且つ緻密に出来ており、アーキテクチャとは何か？を考える上でも非常に役立ちます。

このたび、OMGのジョン・シーゲル博士（技術移転担当VP)がこのモデルとともに現在予定されているDDSの拡張計画について書き下ろしましたので、次回の組み込みプレスに投稿いたしました。（ １４号と１５号の２回）
ご興味をお持ちの方は、ぜひご参照ください。

OCRESブログ 第18回 ソフトウェア設計のトレーニング法 4

「しなの」の語源 ２

以前、「信濃（しなの）」の語源の話をしていて、途中で終わってしまった回がありましたが、本日はその続きを書きます。

前回、「しな」と言う語が付く地名は全国的に散在し、その多くは河岸段丘の地形が見られると言う話をしました。
（このブログを書いた後にもまた、友人のS君から、「東京の品川の語源も河岸段丘じゃないか？」と言う指摘を受けました。品川は目黒川の下流域の名称ですが、周囲の開発の関係で、元の地形が確認しづらくなっておりますが、その可能性は非常に高いと思います。）

ところが、不思議なことに、「しな」地名が集中する信濃では、河岸段丘と「しな」地名はほとんど一致しません。
ここで注意しなければならないのは、その地名がいつ命名されたか、という点で、例えば、「望月の駒」で有名な望月町のそばに、かつて浅科村と言う村がありましたが、この村の周囲に河岸段丘が見られないと言っても、語源的な議論には役立ちません。
というのも、浅科村は、浅間山と蓼科山の中間にあることから昭和３０年代に命名された新地名であって、少なくとも千年以上前から存在する他の「しな」地名とは、区別する必要があります。

そこで、文献などで可能な限り古くから存在する事が確実な、「しな」地名を洗い出しましょう。
次をクリックすると、長野県内で、少なくとも平安時代から存在が明らかな「しな」地名を示した地図がポップアップします。（延喜式や三代実録などからピックアップ）

「しな」地名地図

図中で青色で示した地名が、古代から存在する事が確実な「しな｣地名で、長野県内でも特定の東西に広がる帯状の地域に集中している事が分かります。
実は、この帯状の地域には、この図で示した「しな｣地名以外にもたくさん「しな｣が付く地名や神社が集中して存在するのですが、現存の文献では時代が確認できないため割愛しています。

さて、これらの地域に共通するものは何でしょうか？
好奇心に駆られて、今から十年ほど前に、この辺りを旅行がてら調べた事があります。

（次回に、続く・・・）

リアルタイムUMLの応用講座
このコースは、前回紹介した「UML2を使用したリアルタイム・ソフトウェア設計講座の後続篇、上級版になります。

応用編のため、オブジェクト指向やUMLの基本的な使い方が前提知識として要求されます。
既に、UML設計の経験はあるが、UMLの使用法をより向上させたい設計者や、UML使用上の実践的な技法を学びたい人が対象になります。

リアルタイムUMLの応用講座 アジェンダ

システム要件の分析と定式化

ー シナリオとユースケース
ー システムスコープと、直接的・間接的アクター
ー アクター・システム間の相互作用を図的にモデリング

システムとソフトウェアの要件を定義

ー システム・ユースケース・モデル
ー システム相互作用モデル
ー システム・スコープ・モデル
ー システム動的モデル
ー ソフトウェア・ユースケース・モデル

巨大システムの設計

ー サブシステム・モデルの開発
ー パッケージとコンポーネント
ー 現実世界とのインタフェース； デバイスとソフトウェア間の相互作用

理念的なオブジェクト・モデルの開発

ー 理念的な環境下でのオブジェクトの関係、コミュニケーションと制御

仕様モデルの開発

ー 理念的モデルと実装モデルのミスマッチ
ー コンポジット構造、ポートと提供／要求インタフェース

並列処理システムとタスク・ベースの設計

ー 抽象的なソフトウェア設計の問題点
ー マルチタスキングの根本

実装モデル ー タスク・ベースの設計

ー 仕様モデルを実装モデルへマッピング
ー タスク間コミュニケーションの課題

実装モデル ー 実践的なシーケンシャル・モデル

ー シーケンシャルなコードで、オブジェクトの振舞の集まりを制御 ー 制御オブジェクト
ー アクティビティ図を用いたアルゴリズム（プロセス）の指定方法

コードの問題

ー 論理的／物理的モデル
ー ソフトウェア ー 構築と成果物
ー ソフトウェアの構造化とパッケージング
ー モデルの実装

分散／多重コンピュータのシステム

ー リアルタイムシステムのための多重コンピュータ・アーキテクチャ
ー ソフトウェアをハードウェアへマッピングする上での基準
ー 実践的な設計技法

事例研究

ー 統合アプリケーションの設計