その設計で運用は救われるのか28歳から挑戦するITアーキテクト(3)

» 2005年10月19日 12時00分 公開
[岩崎浩文(株式会社 豆蔵 BS事業部 エンタープライズシステムグループ),@IT]

 人間は、自分が関与する問題を解決することこそ最も重要なことだととらえがちである。SI系の業務システムを請け負っている身からすれば、「どうやって早く構築し、人を操り、納期を守り、トラブルなく利潤を稼ぐか」という点に考えが集中してしまう。

「早く仕様を決めてください。これで大丈夫ですか? 決めないとお客さんの不利になりますよ」

「ここまではうちの責任範囲です。が、ここからは御社ですね。よろしくやってください。

ALT 図1 「ここまではうちの責任範囲です」

 筆者自身は学生時代からユーザー企業側として仕事をし、それが高じて企業向けシステム開発を中心としたIT系の業界に転身した身なのだが、転職後こうした言葉をさまざまな人が口にするのを聞いたときには正直耳を疑った。業務アプリケーションの構築に限らない話だが、作る内容はおろか、使い方を想定しない「現場の理屈」がまかり通り、現場には押し付けに近い形で業務が降ってくる。そんな状況で構築されたものが、果たして役に立つのだろうか……?

作り手側の理屈

 ITアーキテクトを目指す方の多くは、その必要とされる技術のたぐいからすでに業務でプログラミングを散々こなしたことのある方が大半を占めるのではと思う(筆者もその1人だ)。このため、ITシステムのアーキテクチャ設計においては、作り手側の理屈がどうしても(無意識に)前面に出てしまうことがある。

 特に、具体的な製品やライブラリの採用、「作り方」をめぐっては、過去の経験をベースとして、「実績のある枯れたものを」というお題目を掲げて古いものを持ち出すことがこれまで多かった。こうした選択は確かに安全なのだが、問題は依存しているプラットフォームのEOL(製品サポート終了)が目前だったり、ひどい場合はすでにEOLを迎えてしまっているにもかかわらず押し付けてきたりと、結局作り手側は、アプリケーション構築を我田引水型で安易に済ませ、EOL問題を運用に押し付けて「知らないふり」で逃げる例があった。

 当然、EOLを迎えた製品から新製品へのマイグレーション(移住)には、調査・修正・テストなど大規模なシステムであればあるほど、莫大なコストが発生する。またそれに依存しているミドルウェアも連鎖して更新が発生することが多く、運用側から見た場合、これではアプリケーション構築費用や直後の運用はそこそこで済んでも、中・長期的な視点で見た場合、全体のコストはまったく割に合わない話となることが多い。その結果、後に残された膨大な負の遺産を前にして、運用者は頭を抱え、途方に暮れることになる。こうした事例は過去多く指摘されてきたことだ。

作り手側の新たな理屈と暴走

 ところが近年、J2EEが登場したころを境として、企業システム構築においてこのような状況がガラリと一変してしまうことが起きた。プラットフォームが汎用機系からオープン系へ、通信が社内閉鎖型・特殊プロトコル型からインターネット型へ、言語がCOBOLやVisual BasicからJavaや.NETへ、ミドルウェアなど新たな製品の台頭と激変し、一気にプログラマーの世代交代が発生してしまった(筆者もそうした混乱に巻き込まれた1人だ)。

 このため、新しい技術をベースとしたシステムを構築する場合、新たな環境を知らない老練な技術者から若年層への技術移転が行われず、プロジェクト管理者までもJavaや.NETをほとんど知らないという、非常に困った事態が至るところで同時多発してしまった。

 本来ならば、こうした場合においても、技術の選択については老練なITアーキテクトが合理的な選択と設計を行わねばならなかった。しかし、まだこのITアーキテクトという概念自体が確立されていない混乱期であったため、新しい技術については「若くて生きのいい」現場プログラマ(大半はチーフプログラマ相当)が「自称ITアーキテクト」(または「嫌々ITアーキテクト」)となった。そこでは、浅く狭いプログラミング経験を基に、作り手側の理屈や趣味を最大限に押し出して、流行のUMLやXP(eXtreme Programming)手法を逆手に悪用し、ドキュメントもほとんど書かず「作り逃げする」という行為が、筆者が知るだけでも各方面で散見される異常事態となった(当然、UMLやXP自身は全く無罪であることを付け加えておく必要がある)。

 当然、こうした行為は営業もプロジェクト管理者も、新しい技術を知らないため現場に任せ切りとなる。中身を全く把握できてない管理者は、現場からの受け売りで「最新技術で作りました!!」と喜々として顧客に報告し、運用の悲劇が多発することになる。そしてその混乱はいまでも続いている、と筆者は見ている(最新技術が悪いといっているわけでもないことも念のため付け加えておく)。

顧客が本当に困っている個所

 SIを日々の業務として行っている20代の方、特にこうした「断絶層」に該当する方はあまり気付いていないのかもしれないが、実は企業内のITシステム全体を見渡した場合、最もお金が掛かり、問題となっているのは、運用なのである。残念ながら、よく話題に挙がり、自嘲気味にデスマーチと呼び、自ら(開発者)も巻き込まれることの多い、システム構築時のトラブルなどではないのだ。つまり、企業がIT系の投資を行う場合、劇的な改善効果を生む可能性が高いのは運用の改善であるといえる。

 対応ミドルウェアや適用事例が少しずつ生まれてきたSOA(サービス指向アーキテクチャ)は、多数のシステムが併存して動いているこの運用面という切り口で既存の概念を再構築するものであると筆者は考えている。要するに、それだけ運用に対する危機感というのは高くなってきているということなのだろう。ITILなど近年脚光を浴びている運用管理プロセスにしてもしかりだ。

 翻ってITアーキテクト目指す立場としては、SIの構築現場に閉じこもり、クラスライブラリの話やフレームワークについての局所的な議論に没頭してしまうのはぜひ避けたいところだ(もちろん、そのレベルを理解し構築できるのは必須だ)。顧客の身になり、現場を制御し、長期安定運用に持ち込めるのは、構築内容をコード単位で理解でき、また顧客のシステムの全容を理解し、相談される唯一の立場=ITアーキテクトをおいてほかにはいない。

誰も幸せにならない仕組み

 ここで1つ、こうした現場の暴走に関する悪い例をご紹介したい。

  長期にわたる開発側の混乱の割を食っているのは運用側である。最近の企業システムはビジネスの変化に追従して常に変化し続ける必要があるのだが、「その場のノリ」で作り逃げされてしまったシステムを修正するのは容易ではなく、腕に自信のあるプログラマでも頭を抱えてしまうほど難解かつ独善的な仕様であることが多い。

 ある大企業から「パフォーマンス劣化が激しく、(アーキテクチャが)変化するビジネス要件に追従できないほど複雑怪奇になっているため、現状を分析して新たな(アーキテクチャの)素案を描いてほしい」という要望をいただき、数カ月間調査をしたことがある。このシステムは、J2EE登場直後に作成されたJava ServletやJSPを用いて構築され、多数の常駐メンバーによって少しずつ手を入れながら運用されてきた基幹システムだった。筆者が調査を行ったところ、驚くべき事実が次々と明るみに出た。

 ドキュメントがまったくなく、ソースにコメントもなかった。これでは手の付けようがない。利用しているアプリケーションサーバがすでにEOLを迎えており、パッチも当てられておらず、乗り換えようにも非常に特殊な作りになっていて引きはがせない。単一マシン上での動作が大前提となっていたため、スケールアウト(並列にマシン台数を増やす手法)も使えない。設定ファイルとリフレクション(文字列を使った動的な呼び出し)をむやみに多用していたため、バグの発生が起きても解析までに多大な労力を払う必要があった。そして、最も驚いたのが、意味もなく途中でJavaとは違う言語のスクリプトを呼び出す構造となっていたことだ。アーキテクチャにまるで一貫性がない。パフォーマンスチューニングの設定もほとんどが誤りだった。調査を終えた筆者は、このシステムを構築した作り手への疑問と、開発当時のプロジェクトに対して憤りを感じた。

ALT 図2 アーキテクチャにまるで一貫性がない

 この困ったシステムはバッチ処理中に停止したり、頻繁にエラーを起こしたり、最悪なことには、ACID特性の不保持によるデータ破壊が頻発するため、常時十数名の要員が24時間付きっきりで保守する必要があった。経営にのしかかる保守費用と現場の疲労度は極度に高い状態となった。後で分かったことだが、このシステムを構築したあるSI会社は、あまりに汚いシステム・デザインと低い品質、パフォーマンスのために顧客の怒りを買い、出入り禁止を食らった。そのうえで、めぐりめぐって筆者のところにお鉢が回ってきた、というわけだ。

 いったい何が問題で、誰のためにシステムを開発するのか。さまざまな力学でその都度変化していく開発現場で、それを肝に銘じながら本来の目標に軌道修正していく「自浄作用」の力も、やはりアーキテクトに求められる能力ではないだろうか。

Copyright © ITmedia, Inc. All Rights Reserved.