近年のシステム更新に見られる特徴
１． はじめに
いうまでもなく民間企業や自治体の中で、大小さまざまな情報システムが業務に使われています。経理・財務系であれば、大企業から小企業に至るまでその規模に適した会計システムを導入している筈ですし、生産現場でも工場の中での生産の指示、工程管理や制御、実績管理、物流管理など各種の情報システムで行われています。政府機関や自治体でもそれぞれの部門の使命を果たすための、特化した情報システムが使われています。
そのようなシステムの更新に携わっていくつものトラブルを経験し、いくつかの共通な特徴に気付きました。それは、20年前のシステム更新、いや10年前のシステム更新には見られなかった共通の特徴です。ここでは、そのような近年のシステム更新に見られる特徴を論じ、ソリューションプロバイダ(システムインテグレータ)に求められていることをまとめてみました。
本来であればそのトラブルの解決策の提言にまで議論を進めるべきかも知れませんが、そこまで述べる用意がまだできていません。したがって、本稿では課題の提示に留めたいと思います。
２． どんなシステムを対象に考えているか
システム開発に携わった者の常として、自分の扱ってきたシステムには一定の領域があります。ありとあらゆる分野、対象、性能、目的を持ったシステム設計や構築に経験をお持ちのエンジニアはおられないはずです。ここで念頭においているのは、１）生産管理、操業指示/支援、設備監視、生産実績管理、品質情報管理など製造に関わる工場内の情報システム、２）企業の汎用財務/経理、営業支援システム、３）官公庁用の情報収集・業務支援システム、です。
３． システム更新に見られる共通の特徴
では、本題について順に述べて行きます。
① 単なる老朽化更新が多い
過去30年～10年前までですと、システム更新といってもそこに新たな機能を大々的に付加したり取り扱う範囲を広げたり、サプライチェーン、つまり他の関係会社、顧客、資材供給者、海外の工場などを巻き込んだり、大胆な業務改革を取り込んだシステム更新に携わっていました。ハードウェアも変革が激しかったと記憶しています。とにかくそれ以前のシステムにはなかった特徴をもってシステム更新を実施することが多かったです。
それに対して、近年の特徴は現在使われているシステムをそのまま新しいハードウェア、その上で動くソフトウェアに置き換える、単なる老朽化更新です。もちろん、ソフトウェアの老朽化という表現はありません。システムエンジニアが「ソフトが古い」などという場合はあるでしょうが、ユーザーにとって画面やロジックが老朽化することはありません。ハードウェアが補充できない、予備品がない、OSのサポートが打ち切られた、などの理由による老朽化が実態です。成熟した業務プロセス、固まった仕事のやり方の元で、革新的な効率化、システムの力を借りた大胆な業務改革の余地は少なくなっています。新しいシステムに求められるのは、元のシステムとほぼ同じ機能でしかありません。
この種の更新は、経営者にとって積極的な投資にはなりません。事業を継続するために止むを得ず更新するのです。いわば、負の投資です。計画されても先延ばしされがちです。そのような背景の下で、システムインテグレータは前と同等のシステムを作って当たり前、何よりも経済性が問われます。「レスポンスが前よりも悪くなった、遅くなった。」などと、少しでも性能が悪くなると非難を浴びるだけです。積極的な評価を受けることが難しくなって来ました。
② 前回の更新よりもシステムが持つ機能は複雑になっている
一見①と矛盾するようです。が、前回のシステム更新がなされてから今回の更新まで、システムには通常は様々な改善の手が加えられています。企業は業務プロセスを日々考えてより良いものに代えて行きます。当然、そこからシステムに新たに求められる機能が増えて行きます。法律にあわせて新たな入力制約を追加した、新たなチェック機能をビルトインした、などです。工場においても、内容は違えども状況は同じかそれ以上に複雑です。新たな製造プロセスが旧製造ラインの途中に追加された、製品の種類が増えた、品質データの検証項目が増えた、など、システムの機能は進化しています。そのように変化に対応させて手を加えられているシステムは、前回の更新時よりもさらに複雑になっています。スパゲッティ状態と呼ばれる状況も十分に起こり得ます。
③ 要件定義ができる人がいなくなっている
システムは、業務系であれ製造系であれ、日々手を加えられ変化して行きます。そこには、システム変更の要件定義をするプロモーターがいます。そして5年、7年を経て、その人は別の部署へ移り、あるいは退職し、やがてその企業においてシステム変更の経緯を知る人がいなくなります。ソリューションプロバイダ(システム構築ベンダー)にいる技術者がその役割を担っていた場合もあるでしょう。彼らも、同様にその立場を移り変わって行きます。
その後、システム更新の時期を迎え、現システムの機能を洗い直した時に、一見不要に見える機能が本当に必要か、なぜその機能が存在しているのか、誰も解らない状態が生じます。システムを作り直すとき、不要な機能なら、わざわざそのためのプログラムコードを入れたくはありません。ソースコードの整理の機会、とばかりに旧システムの見直しを始めるわけですが、要不要の判断が着かない機能が現れます。ある機能を英断をもって不要とした挙句、システムが稼動して1年後に突如、工場の製品のユーザーからのクレームがあがり、原因を調べていくと、更新時に不要と判断した機能を新システムに残さなかったために、対象製品が手を加えられずに市場に出てしまった、つまり削除した機能が必要であったことに気付くのです。
そのために、「きちんと設計内容を文書化して残しなさい。」とよくいわれはします。が、多くのシステムはその企業の業務手順そのものを反映したものであり、さまざまに工夫されたその手順を設計した人々の知識を100％文書にして残すことは、実態不可能です。必ず漏れがあります。設計者が書かずとも当然と思っていた暗黙の前提が、後継者には当然ではなく未知のことであり、そうして残すべき情報が文書から抜け落ちて行きます。単純な機能を持つシステムではこれは無いでしょうが、現実のシステム更新の現場では生じがちの事象であり、現に筆者もいくつもこの経験をしています。
④ アーキテクチャの変化
30年前のホストコンピュータやミニコンピュータの時代から、UNIXマシン、パソコン、サーバー/クライアント、ネットワーク、サーバー統合、仮想化技術、などなどシステムのベースとなるハードウェアや基本ソフト、運用ソフトの技術は鳴り物入りで変化して来ました。30年前に現代のような通信インフラを、インターネット、イントラネットを想像した人がいたでしょうか？ これからも、変化を続けていくのでしょう。
システム更新に際して、昔と同等のハードウェアを使いたいと考えても同じものが手に入りません。必然的に、従来と同等の機能を新しいアーキテクチャ上で実現させるという、使う側には全く関係ない領域でシステムインテグレータはリスクを負うことになります。従来、快適なレスポンスで使われていた機能を、新しいシステムで従来以上のレスポンスを出しつつ継続できるのでしょうか。更新するシステムが複雑になればなるほど、巨大になればなるほど、この種の冒険は増えます。新しいハードウェア、ネットワーク構成、各種サーバーなどを連ねソフトウェアも作り直して新システムを稼動させたものの、以前と同じレスポンスを新しいシステムで出せなくて一からシステム設計をやり直す例は決して少なくありません。当然、見積もられてなかった膨大なマンパワーが費やされ、システムベンダーは赤字に泣くことになります。
⑤ 予算は前回更新がベース
一方で、システム更新の際には、たいてい前回の更新時の費用を元に更新予算の検討がスタートします。システム技術者が経営者に対して、前回の更新に比べ今回これほど多くの費用がかかることを説明し切るのは容易ではありません。なぜ、どこが変わったのか、システムが前回の更新時よりも進化しているとはいえ、企業や組織の中でそのシステムの目的、果たすべき機能が大きく変わったわけではありません。ただ、以前よりもシステムさらに複雑になっているのです。そのシステムに対する意義、位置づけの変化がない中で、システム更新費用は前回をベースに予算化されざるを得ないのです。
４． ソリューションプロバイダに求められていること
① 不要な更新をさせない
例えば、工場で使われる機械設備は30年以上前の機械を大切にメンテナンスしながら使い続けることが、生産現場でごく普通に行われています。電力系受配電設備も同様です。
一方、コンピュータ関係の設備だけは5年、とは言わずとも10年、は待たずに新調する必要に追われます。OSの大幅なバージョンアップが5年ぐらいのサイクルで行われ、古くなったOSのサポートも追って打ち切られる、このようなことをしているのはIT業界だけではないでしょうか。某有名な経理/財務のパッケージでも、当然のようにソフトの大幅なバージョンアップとそれに伴う更新提案、加えて現バージョンのパッケージに対するサポートの打ち切りをユーザーに「通告」してきます。30年前には革新の激しかった技術領域も多くは成熟しつつある現代に、経理の基本的な扱いは変わらない現代に、情報システムだけは更新を続けなければならない、しかも前と同じ機能のものをわざわざ作らなければならない、このような無駄をいつまでも続けるのは奇妙に見えます。ユーザー側には積極的にシステム更新をする理由は全く無いのです。ただただハードウェアの、あるいはソフトウェアの都合だけで、ユーザーに莫大なシステム投資を発生させます。
20年持つハードウェア、あるいは同じソフトウェア環境でハードウェアのみを置き換えていけるシステム、そのようなシステムを構築するソリューションプロバイダが登場してほしいと思います。
② 基本的なシステム構成を変えない
ネットワークの仕組み、性能は技術的に成熟期に来ていると考えています。少なくとも、通常の企業の会計処理、工場用の各種システムに求められる機能を満たすために、今日、さらに革新的なIT技術をわざわざ導入する必然性は少なくなって来ています。それに対して、メモリーチップの進化に見られるように、PC単体、サーバー単体を取り上げると、個々のハードウェアの性能は上がっています。PCやサーバーをつなぐネットワークの性能は、旧ネットワークよりも落ちることは無いはずです。
このことは、以前と同じシステム構成のシステムを、個々のハードウェアには最新の機種を使って組み上げれば、理屈の上では、レスポンスの問題などが生じるリスクが少ないことになります。このやり方は、保守する側にもメリットがあります。システムトラブルの際、原因の追跡が旧システムとの相似形で行えるということです。
システム更新に乗じて、敢えて革新的なハードウェアユニット、革新的なパッケージソフトなどを導入しシステム構成を一新することは、システムのオーナーに過大な初期の費用負担、トラブル時の不要なロス、特殊な技術者を保守のために待機させる費用、などの理由で望ましくありません。
③ システムオーナーとの平易なコミュニケーション手段の選択
システムインテグレータがシステムオーナーとコミュニケーションを行う場合に、双方が直感的かつ平易に理解できるドキュメントを用いることが重要です。ITコーディネータのテキストに情報モデルの意義や問題点などが述べられていますが、抽象化したモデルでオーナーとシステム要件を確認することは誤解の元になります。ここで念頭においているのは、例えば、ジェネリック情報モデルとして書籍に登場しているものです。システムを作る側がまずそのモデルを理解し、そのルールで図書を作り、それを元にしてオーナーと協議するとして、正確に双方が中身を理解できるでしょうか。抽象化はシステム開発の効率面でメリットがあるのかもしれません。が、システムの処理の流れはかなりトリッキーになるという認識です。メンテナンスの観点からも、限られた人が何十年もメンテナンスをし続けるならともかくも、ソリューションプロバイダとして組織でシステムメンテナンスを遂行する場合に、トリッキーな構成はトラブルシューティングの妨げになります。
業務手順そのままに処理内容をプロセスで説明する、どちらかというと従来のプロセスモデルのやり方が望ましいですが、とにかく使う側、メンテナンスを行う人が理解しやすい設計図書をオーナーに示してシステムを作り、それを後のために残して欲しいと思います。更新時に、旧システムにある意味不明のソースプログラムを少なくするためにも必要です。
５． むすび
以上、限りなくシステムオーナーあるいはユーザーの視点から、筆者の言いたい事を書き綴ってきました。しかし、IT屋の常識、世間の非常識はあります。実際、民間企業で5年、6年の周期で自社のシステムを本気で更新したいと思っている経営者はいない筈です。いままでビジネス誌などで目にしたことの無い意見を敢えて述べたつもりです。共感いただける同業者がおられれば幸いに存じます。
ITコーディネータ 松下 悟
