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

前回の続きです。

デジャヴ

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

東海岸

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

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

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

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

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

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

　

昨今のアーキテクト事情

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

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