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

前回の続きです。

デジャヴ

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

東海岸

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

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