政府IT予算の査定にも使われたノウハウを書籍化!見積書チェック、工数単価の妥当性検証、価格交渉のテクニックを体系的に解説したマニュアル書籍の決定版です。
ブログ「ITコスト削減と価格交渉の勘所」

運用コストの評価方法

システムの保守生産性が低い原因

 システムの保守生産性が低い原因としては、以下のようなものがあります。 ①ドキュメントの整備が不十分 開発したチームがそのまま保守する場合には顕在化しませんが、保守チームが変わったりすると、突然生産性が低下する可能性があります。普遍性の高いドキュメントの整備は必須といえるでしょう。 ②システム構造が複雑になっている 基本設計が稚拙なシステムは、規模の比してモジュール構造が複雑になりがちです。このようなシステムの場合には、1機能の修正に対して関連するモジュール数が多くなるため、保守生産性が低下します。このケースは運用側では対処の方法がありません。 ③システム開発品質が低い(残存欠陥数が多い) 何らかの原因で残存欠陥数が多いと、保守生産性は当然低下します。通常、残存欠陥数はシステムの規模(FP数)に比例し、かつ一定の範囲に収束することが知られています(開発プロセスにおけるテスト工程の比率によって変わります)。この範囲を逸脱するものについては開発クオリティが低いシステムであり、その原因を特定する必要があるでしょう。 ④メンテナンス・チームのプロセス成熟度が低い、もしくは経験値が低い 開発と同様、保守生産性もチームの能力に依存します。ただし開発と比べると状況を改善できる確率は上がります。保守体制を見直し、改善策を検討します。

開発効率/保守効率の総合分析

 システムの開発効率と保守効率を総合的に分析するには、マトリックス分析を実施します。 開発生産性のデータをマトリックスの横軸に、保守生産性を縦軸にプロットします。システムの規模(FP数もしくはStep数)はプロットした点の円の大きさで表現します。  マトリックスの右上のシステムほど、開発、保守ともに生産性が高いことを示しています。左下のシステムは今後改善する余地が大きいことを示しています。開発プロセス、保守プロセスを見直し、円ができるだけ右上に行くような改善策を検討します。  マトリックスの左下に来るシステムは開発効率も保守効率も悪いシステムということになります。システム刷新や廃止を検討する必要があります。もっとも取り扱いに困るのは、左下に位置していて、かつ円の大きさが大きいシステム(巨大なシステム)でしょう。巨大システムは基幹システムに近い位置付けであることが多く、容易に廃止できないからです。  このようなシステムが存在する場合には、最終的な決断は経営トップのマターとなります。巨大なシステムは、開発生産性も保守生産性も低下するリスクが高いといわれています。システム化構想の段階で全体のポートフォリオを念頭において計画を立てることが重要となります。

システム保守効率の考え方

 システムの保守効率は、保守生産性を使って表すことができます。 保守生産性は、開発生産性と同様、1人月あたり何FP(何Step)のシステムを保守できるのかを示す指標です。生産性の数値が大きい程、同じ規模のシステムであれば安価に保守することができます。  組織が持っているそれぞれのシステムについて、年間どの程度の規模を保守し、その業務に何人月の工数を必要としたのかを分析して、保守生産性を算出します。 得られた生産性の数値については平均値を求めます。生産性の数値が平均値から大幅に低いものは、保守のやり方やシステム品質そのものについて改善の余地が大きいことを意味しています。一般に保守生産性はシステムの規模と相関があり、大規模なシステムほど低下します。  保守費用を評価する際に注意しなければならないのは、システムが改修される分の対応です。システム改修の対象となり、機能が増加した分のFP数については、生産性の評価対象に追加する必要があります。逆に機能改修によって使わなくなった部分については、保守対象FP数から削除する必要があります。 保守生産性の評価対象となるのは、実際に使用していて、かつ保守作業の対象となっている機能のみということになります。

信頼性が高いシステムは高価なのか?③

 前回は信頼性を向上させる最大の要素はハードウェアの冗長化であるというお話をしました。コストという観点では、冗長化のために増加したハードウェアの分しかコストは増えないことになります(厳密にいうと冗長化ソフトウェアの購入費が上乗せされます)。  ではソフトウェア(アプリケーション)の部分は信頼性や可用性とは無関係なのでしょうか?そんなことはありません。 信頼性や可用性の指標であるMTBF、稼働率はソフトウェアにも関係してきます。もっとも大きな要因はソフトウェアのバグです。バグがあるとシステム障害が発生し、MTBFや稼働率が低下します。ソフトウェアに存在するバグを除去するためには、テスト工程に時間をかける必要が出てきます。 ソフトウェアに起因する障害をゼロにしたければ、数学的には無限大の時間をテスト工程にかけなければなりません。現実的にはそれは無理ですから、想定されるMTBFや稼働率に合わせて、ある水準で妥協するということになります。 またソフトウェアの品質が低くても、運用の要員を増やし、事前に故障に対処するというやり方を取れば、ソフトウェアの品質に関係なく、MTBFや稼働率を向上させることが可能です。もちろんそのためには運用要員の追加コストが必要となります。  整理すると、信頼性や可用性が高いシステムは高価であるというのは事実なのですが、結局のところ、それらを表す指標であるMTBFや稼働率の数字をいくらにするのかという問題に帰結することがわかります。  MTBFの数値を限りなく無限大にしたければ、あるいは稼働率の数値を限りなく100%にしたければ、それこそ無限大のコストがかかります。逆にある程度の水準で妥協できるのであれば、かなり安く済むわけです。  ベンダーは、想定される信頼性や可用性の数値を複数提示し、どの水準に設定するにはどのような措置を実施するのか?そのためにはどの程度、何にコストがかかるのかを明確にすべきです。発注側はそのような情報を求めていくべきでしょう。  ここでは触れていませんでしたが、一般的に信頼性といわれている概念には、データの保全性というものもあります。これは障害があった時にデータが守られるかどうかという指標です。これは信頼性や可用性と密接に関係しますが、厳密には別の概念になります。保全性を向上させるためには、別な手法とコストがかかります。 高い信頼性と可用性を求める企業の多くは、高い保全性も求めますが、あくまで別の概念であることを理解する必要があります。両者が混同された議論は避けるべきです。

Copyright © 株式会社ストック・リサーチ All Rights Reserved.
Powerd by WordPress & BizVektor Theme by Vektor,Inc. technology.