アプリケーションの保守性を高めるための画期的なメトリクス
「インパクトスケール」の開発と実用化に成功

現在、IT投資額の60～70％が保守・運用費用に当てられているという。企業の活動を支える情報システムは稼動後10年、20年を経て、機能拡張や改修を重ね、最新のアプリケーションと混在し、複雑化しているため、その保守・運用費用は経営を圧迫しかねない状況だ。
この保守運用環境を見据えて、富士通研究所では画期的なメトリクス（注1）、『インパクトスケール』を開発し、実用化に成功した。これは、ソースコードを構造的に解析することによりシステムの潜在的な問題点を予見するというもので、アプリケーションを保守する際に発生するリスクを評価する技術だ。
この技術が誕生した背景と今後への可能性を富士通研究所 ソフトウェア＆ソリューション研究所 ソフトウェアイノベーション研究部の主任研究員である松尾昭彦、ならびに同研究員の小林健一に聞いた。

(注1)メトリクス：ソフトウェアにおけるメトリクスとは、ソフトウェアを計測する方法およびその尺度のこと。例えば、ソフトウェアの構成要素であるソースコードを計測し、数値化を行う。メトリクスを計測し、複雑過ぎるロジックや洗練されないパッケージ構成を見直すことで、バグが少なく保守性が高いソースコードを維持できるようになる。

インパクトスケール開発までの経緯

「富士通研究所でも以前からアプリケーション保守の研究をしており、1995年頃にはCOBOL言語を対象として西暦2000年問題の対応ツールを開発したりしていました。当時の研究テーマの中心は個々のプログラムコードがどういう問題を引き起こす可能性があるか、あるいは保守のドキュメントを自動生成するツールはできないものかなど、より現場寄りの課題でした。つまり、システム構築担当者が自分自身のために便利な支援ツールを求めていた時代といえます。」
主任研究員の松尾昭彦はインパクトスケール開発に至る経緯を語った。

今やそのニーズは大きく変化している

現状の保守・運用コストを抑制し、そのコストを新規IT投資に振り向けることが経営課題のひとつになっている。この変化を研究員の小林健一は次のように説明する。

「今、お客様は自社のシステムが全体として良いのか悪いのかという評価を求めています。具体的には、現状のシステムを維持すべきなのか、新たなシステムに乗り換える時期なのか、保守業務をアウトソーシングすべきなのかなど、システムに対する経営レベルの判断材料を必要としています。これは、情報システムの運営を技術者任せにしていた時代が去り、情報システムに対する高レベルの判断が経営層の責任だと認識されるように、時代が移り変わってきたということでしょう。そのために、IT投資の健全性を経営層が判断できるための資料が求められているのです。」

「これまで技術者はシステム全体の中で、自分が担当する一部分のプログラムを保守・メンテナンスしていれば良かったのですが、たとえば金融システムなどは何千本、何万本というプログラムで構成されていますから、これらをまとめて判断するのは個人レベルでは不可能であり、大変な労力と運用コストを必要とします。」

長年に渡り拡張、運用されてきたシステムの多くは、すでに立ち上げ当初の担当者が移籍したり、退職していて拡張履歴を把握できなかったり保守ドキュメントが残されていない。仮にドキュメントが残されていても長年のシステムの変化を反映していないため、もはや役に立たないケースが多いという。

保守のリスク判断に効果を発揮
アーキテクチャレベルの障害の潜在性を推定

「運用・保守の費用が大きくなりアウトソーシングが注目されるようになってきていますが、自分で保守するにせよアウトソーシングするにせよ、リスク判断が必要になります。
保守費用はプログラムサイズで見積るケースが一般的ですが、それがどのような構成のアプリなのか、品質が悪く予想以上に障害が発生しないか、多くの改修を必要としないか、など採算性を悪化させる要因を判断しなければなりません。しかしこれまでは予測する技法が無かったのです。」
小林は保守に伴うリスク管理に関して語った。

このような問題を解決するために、松尾、小林が開発したものが、インパクトスケールだ。これは、保守作業の複雑さをモデル化し、保守のしやすさをメトリクスとしてソースコードから計算する技術である。その仕組みを松尾は次のように解説してくれた。

「あるプログラムは別のプログラムを呼び出します。また、データはさまざまなプログラムで共通して使われますから、保守に際してはプログラムの変更が他のプログラムにどんな影響を与えるかを判断しなくてはなりません。しかし、従来はこのような影響の度合いを示すメトリクスは存在しませんでした。
インパクトスケールはプログラムに関係するプログラムとデータを辿っていき、この関係の強さを重み付けすることにより、そのプログラムの影響波及の範囲を求めます。
従来のメトリクスはプログラム単体や直接関係するプログラム間で計測するものが一般的でしたが、インパクトスケールはこれらとは異なり、広い範囲にわたる間接的な関係をも含めた影響度を計測できるのです。」

小林もこれを補足するように付け加えた。

「これまでも開発工程においては、障害発生に影響があると言われているプログラム内の複雑度などのメトリクスを調べる技法がありました。しかし従来の技法は、開発工程では有効であっても、長年に渡り保守を施したアプリケーションの品質評価には有効ではありませんでした。保守の効率化を目指す私たちは、従来の技法では発見できない障害要因を見つけることが必要でした。その目的に沿うようにインパクトスケールをデザインしたのです。
実際に、あるお客様の例ですと、インパクトスケールを測ったところ、全体の20％を見ればバグの48％がキャッチできました。これまでは、全体の20％を見ても20％しか見つけられなかったのです。」

システムはまるで生き物のよう

ユーザーニーズやビジネスのあり方、社会環境は急速に変化し、それに伴いシステムに求められる要望も変化する。もはや、情報システムは「変更することが当たり前」であり、これを管理することは時代の要請であると言える。

小林は、現状の大型システムを捉え、こう表現する。

「システムというのはまるで成長する生き物のようなものです。体調不良のときに細胞一個一個を検査しているだけでは原因は見えてきません。体温や血圧などを測ったりして診断することが必要になります。システムでも同じことが言えます。まずは、システム全体がどういう特徴を持っていて、どのような問題が潜んでいて、それはどんな原因で起きているのか、ということを見極める必要があります。インパクトスケールはそのための新しいアルゴリズムなのです。
インパクトスケールの開発にあたっては、富士通研究所が長年培ってきたプログラム解析技術に加え、生物学や薬学でよく使われる統計的なアプローチも利用しました。」

実用化で成果は着実に現れている

すでに富士通では運用・保守サービスの1つ、APM（アプリケーション・ポートフォリオ・マネジメント）サービスにおいてこの技術を採用し、一部のユーザで試行を開始している。保守の難易度推定や強化レビューに利用し、保守品質向上に成果を上げつつある。
今後は、システムのマイグレーションへの応用、事例の蓄積によるモデルの改良、Javaなど対応言語の拡大などにより、より多くのアプリケーションソフトで利用できるよう洗練化を計っていく計画だ。

「難しい課題ですが、レガシーシステムは、使い続けることが1つの解だと思います。新たに作り直すタイミングを見極めることも大切ですが、うかつに直そうとして失敗するという危険性も潜んでいます。
システムの障害要因は1つに特定することが難しいものです。ですからITを運営する人間の環境をも含めた現状認識が大切になります。保守の優先順位を決定し、TCOを高め、システムの構造的な問題を予防するうえでインパクトスケールは、経営層にとってもシステムを評価する有益なツールになり得るでしょう。今後はシステム状況をわかりやすい図にマッピングして表示することも検討しています。」
松尾は、インパクトスケールの果たす産業的価値と今後に向けた可能性、そして何よりも現場からの高い評価に手ごたえと更なる意欲を示した。

2007年10月22日 公開

---

ジャーナル最新のテーマ

---

---