先日、若い知人とBPMに関してミーティングをしていたところ、話題が昨今のITエンジニアのいわゆる３Ｋ化の問題になりました。
彼の廻りの同年配の知人友人達は、4〜5年前まではIT企業を辞めても、またIT関連の企業に就職することが多かったのが、最近では、全くの異業種へ転職するようになってきているそうです。
筆者は、若い頃は、「日本には日本のやり方がある」という意見に反発を感じていた方ですが、歳を取るに従い、従来のやり方に拘る年長者の気持ちも理解出来るようになってきました。しかしながら、この3K化の問題に関しては、日本の従来のやり方が間違っていると強く感じています。あえて失敗と呼んでいいとさえ考えています。
この３Ｋ化の問題は単に勤務時間が長いと言う点だけが問題なのではなく、様々な複合的な問題のようです。一々挙げるときりがありませんが、代表的な問題としては、上流工程の品質が劣悪で、その皺寄せが開発工程を直撃している、とか、IT企業がゼネコン化し、孫請けなどは当たり前で、5次受け6次受けなどもざらに存在し、中間搾取が甚だしい、あるいはエンジニアの技術レベルが低い、、等々。
そして、その多くが日本固有の状況である事を示しており、日本固有の解決策が必要です。（欧米の先進企業の部分的な模倣では決して解決しないことが、だんだんと明らかになってきました。）
そして、ここに興味深い事実が１つあります。多くの方々が、BPMが問題の解決あるいは現状の改善の糸口になる、あるいは、なって欲しいと期待していることです。
IT産業では、かつて、新しいテクノロジーの出現により、市場が激烈に変化したり、価値基準が逆転したりするような事が何度も発生してきました。日本の強固な労働慣行でさえ、強く影響を受けています。
BPMは、生産工程のテクノロジーと言うよりも、ホワイトカラーのテクノロジーと言う面が強く、人々の期待も決して根拠のないものではありません。
さて、筆者の短見では、BPMはもろ刃の剣に感じます。
この件については、今後また触れたいと思います。
配備、配備仕様の表現
前回（第106回）、ノード内に成果物を記述して、配備を表現する形式を解説しましたが（図H07 参照）、
同じことを、図H08のように、配備を示す依存関係（＜＜Deploy＞＞を使って表現することも可能です。
図H08
今週は、カナダのモントリオールに滞在しております。モントリオールは、ボストンと同じく米大陸としては古くから開けた都市で、町並みもヨーロッパ調です。また、住民の多くはフランス語を話し、地名や駅名も殆どがフランス語ですので、まるでフランスに来たような錯覚に囚われます。
ここは、ボストンに輪をかけて寒く、石造りの建物の間を縫う石畳の街路に人影はまばらで、時間が凍ってしまったような印象を受けます。たまに通り過ぎる人々も、ファッションを気にする若い女性を除くと、みんな南極探検隊のような格好をして無言で歩いています。
こんな街ですので、一人で夕暮れ時に歩いていると、不思議なエキゾチシズムの感に襲われます。こんな感覚は、海外旅行をしても、絶えて久しく感じたことがなかったのですが、あえて言うと、昔の神戸の異人館街にあったような、ある種のノスタルジーに似た感覚、自分が見知らぬ街でエトランジェ、異邦人になってしまったような感覚と言えば、多少ご理解頂けるでしょうか。
筆者は、ホテルの裏の雪の残る石畳の細い通りを歩いている時に、暗い電飾の窓越しに古いアンティークの電話機を見つけ、思わず店に飛び込みました。骨董屋とも雑貨屋ともつかない店の中は意外に広く、思わず目当ての電話機以外のものも買ってしまいました。
配備仕様
配備仕様（Deployment Specification)は、コンポーネントがノードに配備される際の実行オプションを記述したもので、例としては、実行場所や、並列処理の指定、トランザクション処理の指定などが挙げられます。
図H07は、AppServer1ノード内のShoppingCart.ear（＊）に配備されるOrdder.jarの配備仕様がOrderdesc.xmlであることを示しています。
図H07
配備は、タイプレベルもしくはインスタンスレベルで表現することが可能で、図H06は、配備仕様のタイプレベルとインスタントレベルの記法を示しています。
図H06
(＊）EARは、Enterprise Archiveの略で、Java EEアプリケーションのパッケージ形式。WAR(Web Application Archive)やEJB(Enterprise Java Beans)、Jar等を包含することが可能。
マサチューセッツ州は、伝統的にリベラリズムの影響が強く、民主党支持の州として知られています。そして、ご想像の通り、昨今のブッシュ政権に対する評価は、最大限上品に言って「糞のレベル」にあります。
昨日、リベラルアーツを形だけまねて中身が伴っていない大学教育の話をしましたが、どういう点が違うかと言うと、基本的な学習項目には、あまり差がないのですが、こちらのリベラルアーツの学校の最大の特長は、少人数教育であり、全人格的な教育が期待されていることです。
日本の形骸的なリベラルアーツの教育は、必ずしも大学や為政者の意思ではなく、60年代70年代の学生運動に示されるように、学生側の意思であった面もあり、一概に誰の責任と決めつけるのは難しい所です。
また、リベラルアーツ系にも大きな欠点があります。教育費が、べらぼうに高いことです。
アメリカの大学の学費は、中流家庭にとっても、極めて大きな負担であり、そのために奨学金制度などもありますが、十分ではありません。そして、向学心はあるがお金がない若者にとって最もポピュラーで、かつ名誉ある方法が、兵士になることです。
何年かの兵役を務めると、軍から大学の学費を得ることができます。
今現在、イラクに相当数のアメリカの若者達が行っていますが、多くは、軍からの奨学金を得るためだと言われています。
今回、筆者が訪問したオフィスに、十代の頬の赤い兵士の写真が飾っている方がおられました。聞くと、息子が来月からイラクに行くことになったと言われます。
一般に、アメリカでは、公務員は日本ほど良い職業とは見做されていませんが、幾つかの例外があり、警察官や消防士、そして兵士など、第一線で危険な公的サービスに従事する人たちは、社会から一定の敬意をもって遇されます。（それに対して、バックオフィスの公務員は、最も好意的な言い方をしても、民間に就職出来なかった気の毒な人たちと見做されます）
イラクの問題は、自分たちの子供が戦地に赴く問題であり、ブッシュ政権に対する評価は、極めて微妙です。
ノード内の配備
前回は、ノード内の配備を表す方法として、ノードのシンボル内に配備する成果物のシンボルを書き込む形式を紹介しましたが、成果物のシンボルを使わずに名前のみを書いて表現することも可能です。（テキスト表現）
図H05は、AppServer1内の成果物をテキスト表現で示しています。
図H05
今週は、BPM関係の仕事でOMGの本部を訪問しております。
OMGの本部は、ご存知の方も多いと思いますが、米国マサチューセッツ州のボストンにあり、冬の気温は氷点下になることが珍しくなく、日本の感覚で言うと、雪のないスキー場に来たような感じがします。
ボストンは、人口はたいして多くないのですが、日本でも、そして世界でも有名な街です。
日本では、高校の歴史で習う「ボストン茶会事件」や「ボストンバッグ」で有名ですが、後者のボストンバッグは日本固有の呼び方で、ボストンでは通じないと、こちらが尋ねる前に現地のアメリカ人に教えられました。（よっぽど、良く聞かれるのでしょう）
ボストンバッグは、戦後の日本へボストン大学の学生が持っている姿が紹介されて、そこから命名されたようです。
さて、ボストンやその週辺地域は、名門大学が多く、マサチューセッツ州は別名、教育州と呼ばれるほどです。
先ほど挙げたボストン大学をはじめ、ハーバード大学やマサチューセッツ工科大学(MIT)、また芸術分野ではバークレー音楽大学なども、このあたりにあります。（OMG本部のメンバーも、自然と、こう言うかしこそうな大学の卒業生が多いようです。）
アメリカの中上流家庭では、リベラルアーツの伝統を重んじる気風が残っており、幼少期から貧困を経験したことのない自分たちの子弟を、田舎の小さな街で一人暮らしさせ、文学や哲学、そして自然科学などをじっくりと学びながら、今後の人生の進路を考えさせたいと思う親が多いようです。（背景には、貧困は、人生の最善の教師という考え方があるようです）
そして、その後に、専門の職業教育（法学や医学、経営学、工学等々）を学ぶと言うコースが一般的です。
実は、こう書いていて、ふと気付いたのですが、日本の戦後の大学教育も、アメリカのリベラルアーツ重視の姿勢を模倣したものでありました。
個人的な体験を極端に一般化するようで、少し気が引けますが、筆者は、大学入学時は全員が教養学部に入り、その後、専門学部を自由選択できる仕組みの（リベラルアーツの考え方を忠実に再現したような形の）大学におりましたが、残念ながら、模倣したのは形だけで、中身は全く伴っていなかったような気がします。
これは筆者一人の感想ではなく、友人達もみな教養課程の内容に不満を感じていました。
筆者が教養課程で唯一有意義だったと思われる経験は、故廣松渉先生の哲学の講義へ出席出来たことぐらいで、他の授業は殆ど何の感銘も得ることができませんでした。
筆者は、六本木ヒルズに住み美女に囲まれた生活をしている方々に対しては、さほど羨ましいと感じたりしませんが（負け惜しみに聞こえるとは思いますが）、アメリカの片田舎にある伝統的なリベラルアーツ重視の学校（日本では知名度が低いですが）で勉学に励む方に対しては、羨望の思いを禁じえません。
教育は、形だけまねるのはすぐできますが、中身の充実には長い年月が必要なようです。マサチューセッツ州にあるいわゆる名門大学は、日本のどの大学よりも長い歴史を持っています。
日本も大学の独立性が増してきた今、カスタマー・ボイスに真剣に耳を傾けることにより、教育内容も充実したものになって行く事でしょう。
ノード
ノードは、成果物（＜＜artifact＞＞)に実行環境を提供する計算機資源のことで、ハードウエア資源やソフトウエア資源の両方を包括します。
ノードの例として、アプリケーション・サーバー（＜＜application Server ＞＞）、クライアント・ワークステーション（＜＜client workstation＞＞）、携帯機器（＜＜mobile device＞＞）、組込み機器（＜＜embedded device＞＞）等が挙げられます。
ノードは、メタモデル的にはクラスの一種ですが、図H03のAppServer1のように、箱形のシンボルを使って表現します。（当然の事ながら、分類子の四角形とステレオタイプを用いて表すことも可能です。）
また、ノードのなかに成果物などを入れて、成果物がノードに配備されていることを示すことが可能です。
図H03では、ShoppingCart.jarとOrder.jarの二つの成果物が、ノードへ配備されていることを示しています。（また、図中の依存関係は、ShoppingCart.jarがOrder.jarに対して、何らか形で依存していることを意味しています。）
図H03の配備関係は、図H04のようにステレオタイプ＜＜deploy＞＞を用いて表すことも可能です。
図H03
図H04
