WEBマガジン

「ソフトウェア維持管理の現場改善（１）」

2015.10.14 株式会社オージス総研　　山海　一剛

・	情報システムの半世紀オンラインシステムの幕開けと言われる旧国鉄の座席予約システムが稼動したのが1965年なので、日本の企業が本格的に情報システムを適用し始めて、今年でちょうど50年ということになります。当初は膨大な情報量を処理するための労務費削減という目的が主で、会計や人事という領域で使われていたコンピュータシステムは、経営情報の分析やＢ２Ｃなどより広い分野へと適用範囲を広げてきました。比較的最近までは「古くなったら作り変えればいい」という発想で構築されていましたが、適用領域の拡大が進むにつれ、既存システムの更改ではなく新しい領域への投資が優先されることで、結果的に当初の想定以上に情報システムが長寿化することになりました。もう15年も前になってしまいましたが、「2000年問題」の背景も、当初想定（西暦2000年以前にはリプレースされるであろうというような）よりも長く使われ続けたという「誤算」があったわけです。最近では「古くなったら作り変えればいい」という発想は弱まったものの、新規開発の時点から維持管理のコストまでを意識して開発する例は、まだまだ少ないのではないでしょうか。その結果として、企業のIT部門として維持管理すべき情報システムの数よりも維持管理コスト方が、より早いペースで増えているように思います。
・	維持管理組織の現状私は以前から、アーキテクチャ構築や新しい方法論をお客様にお勧めする仕事をしていました。そういうかたちでお客様と接していたので、新規システムが話題の中心でした。しかし最近は、社内外のいろいろな現場のサポートをする役割も増えました。そうすると、新規開発よりも維持管理の現場の方が大きな問題なのではないか、それは現場だけではなく経営レベルでの問題なのではないかと感じることが多いのです。維持管理業務についての状況と課題の説明のため、ケーススタディ的にひとつ例を挙げてみると、下記のようになります。少し長くなりますが、読んでみてください。
	維持管理組織は、実務部門の業務分野毎にチーム分けされている。ひとつのチームは５人～10人程度で、ひとつの業務分野のシステムの維持管理を行っている 1チームあたり５つから7つ程度の業務システムを担当している。リリース時期はバラバラで、10年以上前にリリースされたものも珍しくない担当するシステムのそれぞれに、機能追加変更の作業や、実務部門からの問合せ対応を行っている。さらには機能追加変更のアイデアがあれば、そのコストや期間について見積もったり、見積もりのための調査や仕様の具体化なども重要な役割である。もちろん障害が発生すれば、待った無しで対応しなければならないこれらの作業を行うためには、業務知識やシステム仕様についての知識が必要なのはもちろんのこと、さらには開発言語、ミドルウェア、フレームワークなど開発基盤の知識も必要である。しかしそれは必ずしも統一されているわけではない（社内の標準はあるものの、開発時期が大きく異なるため、開発基盤が全く同じであることはかえって珍しい）。
	図1　維持管理組織の負のスパイラルとその加速
	このような状況なので、多くの場合、以下のような課題を抱えています。
	新しいシステムがリリースされたのち開発チームが解散すると、維持管理チームはそのシステムを「引き取る」ことになる。社内のIT予算削減などもあり、一時的に増えることがあっても、長い目で見れば要員が追加されることは少ない。業務や仕様に対する知識や開発基盤のスキルが多様であり、もともと人数にゆとりが無いため個人商店化（属人化）が進んでしまう。一度、個人商店化してしまうと、他組織へのローテーションが困難になり要員の固定化が起こる。新しい技術や業務に携わって成長するような機会が無いため、メンバーのモラルの低下を招く。また、あえて無理なローテーションを行った場合、業務やシステム仕様の理解が浅いメンバーが残ることになる。調査や検討にかける工数が増えて、問合せや機能改修のリードタイムが伸びることになる。また思わぬ障害を発生させることもある。数週間から数カ月単位の機能改修作業を進めている間にも、日々電話やメールで問い合わせや相談が飛び込んでくる。内容によっては回答するために調査も必要となる。つまり作業の粒度や性質のバラツキが大きく、日々の予定や負荷が予測困難になり、個人単位ですら仕事をコントロールが出来ない。結果として「帰りたくても帰れない」、「休みたくても休めない」現場となり、慢性的な高負荷が続く。にもかかわらず、実務部門の要求は溜まる一方である。結果的に、問合せから障害対応まで一番詳しいメンバーに丸投げせざるを得なくなり、個人商店化がさらに進んでしまう。責任もリスクも組織ではなく個にゆだねられる構造になってしまうため、メンバーは精神的に孤立化してしまう。
	そして、これはさらに次のような「負のスパイラル」とでも言うべき悪循環を招きます。
	大型プロジェクトが立ち上がったりするとメンバーが引き抜かれてしまう。しかし業務や仕様に詳しいメンバーは異動させにくいため、結果としてさらに要員の固定化が進む。同じ組織に10年以上在籍する要員も珍しくない。機能変更などの際に潜在バグを"踏んでしまう"こともありうる。その反動（ミスゼロ活動推進など）により詳細な（石橋をたたくような）調査やレビューを行うようになる。実務部門から見れば「些細な変更にも時間と工数がかかる」と見えてしまい、どんどん積み残される要求事項とともに不満も積みあがっていく実務部門からの開発期間短縮の要請、情報システム保守予算の削減などの時代の流れが、これらのスパイラルをさらに加速させる
	いかがでしょうか。「さすがにここまで極端な例は・・・」と、おっしゃる方も多いでしょうけれど、中には「まさにこのとおり」と思っておられる方もいらっしゃるのではないでしょうか。これは自社のIT部門が直接ＩＴ運用の業務をしておられる例ですが、情報子会社に委託している、あるいは外部のベンダーに委託している場合でも、直接業務を担当しているチームをクローズアップすれば、ほとんど相似形のような様相になっています。

・	銀の弾丸はあるのか？正直言って、このような状態から抜け出すのは簡単ではありません。また私がこれまでお客様に提唱してきた手法だけでは解決できないことにも気が付きました。
・	アジャイルは解決策なのか例えば、代表的なアジャイル開発手法であるスクラムを取り上げてみましょう。スクラムはシンプルで優れたな手法ですが、開発チームは全員ひとつのプロジェクトに従事していること、要求事項は一人のプロダクトオーナーによって優先順が与えられていること（絶対に一人である必要は無いが、一元的に優先度が決定される必要はある）、などを前提にしています。スクラムは新規開発だけでなく、維持管理にも適用することは可能ですが、維持管理チームが上述のような体制なのであれば適用をお奨めできません。まず、ひとつのチームが複数の実務部門、複数のシステムを維持管理しており、随時問い合せや障害に対応する必要があるのであれば、要求事項の優先順を一元的に管理することは出来ません。またスクラムには「反復期間中は要求事項の追加変更は出来ない」というルールがあります。反復ごとにチームの生産性や品質を把握してコントロールできるという効果があるのですが、このルールを適用することも難しいでしょう。もちろん「そのままでは」解決策にならないという意味であって、スクラムの原理・原則をしっかり理解した指導者さえいれば、（応用形という意味で）チームを良い方向に導いてくれると思います。しかしそのような人を見つけるのは簡単ではありません。
・	アーキテクチャ構築は解決策なのかまた私は、企業の情報システムのアーキテクチャをより良いものにすることで、変更対応力のある柔軟な構造にしましょうという提案もしてきました。エンタープライズ・アーキテクチャ（ＥＡ）であり、サービス指向アーキテクチャ（ＳＯＡ）です。これらの考え方は非常に良いものですし、また時間をかけてこの考え方を適用してきた企業は、まさにその恩恵を受けています。しかしＥＡやＳＯＡを目指して既存システムを統合しようとした場合、その維持管理に携わるメンバーの知識とスキルに頼らざるを得ない部分は大きく、慢性的高負荷に苦しむ彼らの体力をどう捻出させるかが課題になってしまいます。維持管理とは別の体制を作って既存システムを統合する、あるいは将来の老朽化による更改を待って、徐々に統合していく等の方法も考えられるものの、時間やコスト、あるいはその両方を費やして進めるのは、経営層のよほどの英断が無い限り難しいでしょう。やはりまず現場から変わり始めることが必要なのです。
・	負のスパイラルを抜け出すためにはここまで否定的なことばかりを書いてきました。しかし策が無いわけではありません。現場のメンバーが腹をくくって取り組む意思を固めさえすれば、打てる手はたくさんありまるのです。紙面を次回に譲って、そのお話しをしたいと思います。