最低10年使える業務アプリケーション(後編)28歳から挑戦するITアーキテクト(12)〜実践編〜

前回「最低10年使える業務アプリケーション(前編)」は数年間アプリケーションを保持し運用し続けるためには多くの問題がある点を見てきた。今回は後編として、それらの原因と解決の方策を探り、現代のアプリケーションは長期運用に耐えるのかを考えたい。

» 2006年08月09日 12時00分 公開
[岩崎 浩文(株式会社豆蔵 BS事業部 エンタープライズチーム SMPグループ ),@IT]

動かなくなるカラクリ

 前回「最低10年使える業務アプリケーション(前編)」、数年前に構築されたJ2EEアプリケーションが新しい環境で動作せず、企業担当者が怒りと悩みで苦しんでいる例をご紹介した。筆者はそこで、意外にも多くのアプリケーションで共通に持つ悩みを垣間見ることができた。

 どういうことかというと、筆者が先の顧客に対し現象を調査したところ、当然ながら古いJDKのAPIとその挙動に依存して動作している個所、および古いJDKでしか動作しないライブラリやオープンソースが非常に多く見られ、さらに一部ではJ2EEの規約に違反していたため、新しいJDKやアプリケーションサーバに配備した時点でエラーとなっていた。

 このように複雑な例だが、図に表せば図1のようになる。日進月歩で改良が進むIT業界では数年前の技術となると、そのようなものを使っている方がどうにかしている、と錯覚しがちだが、顧客側からすると、たった数年前に大枚をはたいて構築したアプリケーションが動作しなくなる方が、どう考えても異常である。

ALT 図1 日進月歩で改良が進むIT業界

 ここでは特に意図せず筆者の経験としてJavaのアプリケーションを引き合いに出したが、これは.NETなどほかの技術であろうとも状況は同じである。結局この業務アプリケーション担当者は、既存のソフトウェアの中身が現在の業務内容とすでに異なっていることが多い点も考慮に入れ、また新たに構築し直すことを計画する羽目になってしまった。

運用からが本番、なのだが……

 このような悩ましい状況は、その多くが運用段階に入って初めて発覚するのだが、よほどの経験者でない限り、開発時にそうした事態を予測し、前もって周到に運用計画が立てられることは意外にも少ない。

 それよりも、開発時の苦労の方が「デスマーチ」などとやゆされるように、多くは注目されがちだ。それは多くの人員が徹夜に近い形で土日も出てせっせと作業するような、見た目の大変さに影響されることも多いだろう。

 何よりも、アプリケーション構築時にITアーキテクト不在でプログラマ主導にて行われた場合だが、開発言語やOSやVM、アプリケーションサーバなどの選択が、本人や開発者の嗜好(しこう)や慣れを基準に、どれだけ構築時に負担を減らせるか、という点に主眼が置かれている点も見逃せない。「作り手側の理屈」である開発時の大変さが必要以上に強調されてはいないだろうか。

 結局企業システムは連続稼働してこそ意味を成してくるわけで、開発が完了した時点ですべてが終わるわけではない。加えて、開発時のゆがみや特殊な推奨環境の塊を残されて「ハイさようなら」といわれる側の感情も、学習を始めたばかりの学生ならともかく、プロとして業務に携わるITアーキテクトであれば理解するよう努力するべきだ。これらを踏まえた水準で開発現場の暴走を食い止め、システムの命を延ばす方策を講じるべきだと筆者は考えている。

開発・運用=投資

 この場合、企業の運用側担当者の感情としてあるものは、開発側に対する無責任性を責めるものもあるのだろうが、それ以上に何よりも、構築したシステムに対して大量の人員を割いて開発時のゆがみをカバーするために運用しなければならないことにある。そして大量の人員を雇うには大量のお金が掛かる。ただでさえ運用を行う組織は『コストセンター』(つまりお金ばかり掛かる部門)と認識されることが多いのだが、そのうえ新たに手の掛かるアプリケーションを押し付けられたときの絶望感は想像に難くない。

 また、運用時の典型的な失敗例としては、ただでさえ膨れ上がった開発費用の数倍規模で運用コストが掛かってしまい、もう1度作り直した方が安い、という試算結果が出てしまうものだ。前世紀末までは億単位の業務パッケージ導入とカスタマイズで失敗した例が多く報告されていたが、近年ではJavaなどのオープン系技術で『作り散らかした』ものが多く見られるようになってきている点は、これまでの連載でも指摘したとおりだ。

 そして運用まで含めて異常にお金が掛かってしまう、という状況についてプログラマ側は多くの場合無関心だ。プロであるならばそれで食べているわけなので、その仕組みについて関心を持って当然だとは思うのだが、ほとんどの関心はプログラムコード中の世界で活躍するだけであり、発注側の声は届かない。

 業務アプリケーションの開発や運用がなぜ行われるのか。それはそのシステムを導入することで本業の収益を向上させるためだ。この場合、最小の投資で最大の結果を生み出せることが『良いこと』であることはいうまでもない。この場合の価値基準は、プログラムの出来不出来以上に、『開発コスト・運用コストを抑え、どれだけ長く使えるか』となる。

現代の業務アプリケーションは10年持つのか

 このように、業務アプリケーションの開発を取り巻く状況は近年に増して厳しい状況となってきている。さらなる短納期開発に追われる現状では、開発側にて目の前の開発完了が最優先になることも十分理解できる。

 しかし、だ。莫大な投資に対してその見返りを顧客が得るためには、長期にわたり使い続けられることが必要だ。せめて、10年程度は実用に耐え得るアプリケーションでなければならないのではないか、と以前から筆者は考えている。このため、長期運用を妨げるさまざまな外的要因や、追加開発を阻害する内的要因を事前に察知し、計画的に対策し、的確に実行する必要がある。

 これらの長期的な戦略にのっとって地道にメンテナンスされることで初めて、長期的な運用が可能となってくるのではないだろうか。そして初めて10年持つアプリケーションとなるのではないだろうか。もしこれが可能となれば、数年単位でシステム刷新という莫大な浪費よりも、低コストで使い続けることができる可能性が高い。それは、海外に対してのオフショアなどを用いて、できるだけ低コストでアプリケーションを構築するビジネスとは正反対のモデルとなるのだろう。従来の方法では投資対効果があまりにも不釣り合いなため、こうした行為を繰り返してゆけば、IT業自体が不審の目で見られる可能性もあるうえに、自らの首を絞めることになりかねない。苦労して作ったアプリケーションは、可能なだけ長期的に使い続けたい。それはコスト意識もさることながら、ソフトウェア構築に携わる技術者としての率直な願いだ。

ITアーキテクトがアーキテクチャ全体を導け

 ここで注意しなければならないのは、受注側、開発の現場、発注者側、運用の現場、それぞれにはそれぞれの言い分があり、それらはすべて妥当な理由を伴っているという点だ。前の例では開発側の勝手について例に挙げたが、当然その逆となる運用側や運用の現場側の勝手もある。ただし、ビジネスなのでお金を出す方が口を出せるという万国共通の基本原則がある、というだけの話だ。

 そして、これらの利害関係者の意見を集約し、あるべき姿へと導くことを放棄してはならないということだ。名前からすれば当然なのだが、あらためて認識させられる点としては、ITアーキテクトがアーキテクチャ、つまり全体の技術的な骨組みを描き、長期運用の戦略を立てるべきだ。それらはアプリケーションのみならず、ハードウェアの水準からも必要なことは、これまでも繰り返し述べてきたことだ。

ALT 図2 ITアーキテクトがアーキテクチャ、つまり全体の技術的な骨組みを描き、長期運用の戦略を立てるべき

 悲しいかな、感情の動物である人間は、得てして自らの関心事を最大の重要事項と錯覚する。特に信念を持って『迷走』している現場は手が付けられないこともある。それらを統率し、方針を描き、周知徹底することは、もはやIT技術とは懸け離れた領域であるため難しいことだが、逆にITを知り尽くしたITアーキテクトでない限り、それぞれの玄人である現場を納得させることなど到底無理だ。IT系と人間系の技術の両輪が必要な点も、すでに現場で活躍している方なら嫌というほど感じていることだろう。

 ここから先は個人の美意識となるので明言は避けたいが、筆者のアーキテクチャ構築時の最大関心事は『それは単純だろうか?』という問いにある。単純な構成は美しいうえに、変化にも容易に追従できる可能性を秘めている、と信じているからだ。これらについては、また別の機会とさせていただきたい。

 現代のアプリケーションは10年持つのか? その問いに対して筆者は明確に答えを出すことができない。しかし、多くの方策と戦略的な継続メンテナンスを行えば、少なくとも不可能ではないだろう。そうした健全なスタイルが根付くためには、何が合理的な選択なのか、冷静に判断できる眼が必要になる。ITアーキテクトの存在は、そうした難題に応えるために生まれてきたものなのだろう。

Copyright © ITmedia, Inc. All Rights Reserved.

注目のテーマ