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

2012年12月

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

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

システムの開発生産性が低い原因

 システムの開発生産性が低い原因としては、以下のようなものが考えられます。 ①システム要件が曖昧で変更が多い システム要件があいまいだったり、途中での変更が重なると、開発作業での手戻りが多くなり、生産性を大幅に低下させてしまいます。また開発途中での仕様変更が多いシステムはコードが汚くなり、構造化のレベルも下がってしまいます。結果として開発生産性だけでなく、改修や保守の生産性も低くなります。開発生産性と保守生産性には多くの場合、相関が見られます。利用者側で改善できる部分も多いですから、発注体制を見直すことは重要な対策といえるでしょう。 ②開発期間に制約がある 開発期間が極端に短いと、作業を平行分割する必要が出てきます。そうなるとチームごとの情報伝達でのミスが重なり、バグの発生確率が高くなります。結果として修正工数が増え、生産性を低下させます。適正な開発期間を確保することが重要です。 ③開発するシステムのデータ構造が最適化されていない データの構造が最適化されていないと、同じ機能を実装するのに記述しなければならないコードの量が増え、生産性を低下させます。当然改修や保守の生産性にも影響してきます。データ構造を最適化できると、データベースのテーブルに対するアクセスを特定の機能グループに集中させることができます。そうなれば動作も軽快になり、保守や改修の際の手間やミスを軽減させることが可能となります。データ構造の最適化レベルはCRUD図などを作成すると分析することができます。 ④開発チームのプロセス成熟度が低い、もしくは経験値が低い 開発生産性は開発ベンダーのチームの能力に依存します。チームの能力が低いと、ユーザー側では対処のしようがありません。チームの能力は要件定義の段階でかなり明らかになります。 ユーザーのニーズをうまく具現化できないチームの場合には、発注を再検討した方がよいでしょう。基本設計の段階でうまくいっていれば、プログラミングが多少下手でも、大きな問題には発展しません。

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

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

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

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

システム開発効率の考え方

 システムの開発効率は、開発生産性で評価することができます。 開発生産性は、1人月あたり何FP(何Step)のシステムを開発できるのかを示す指標です。生産性の数値が大きい程、同じ規模のシステムであれば安価に開発することができます。 .  組織が持っているそれぞれのシステムについて、年間どの程度の規模を開発し、その業務に何人月の工数を必要としたのかを分析し、開発生産性を算出します。得られた生産性の数値については平均値を求めます。生産性の数値が平均値から大幅に低いものは、開発プロセスについて改善の余地が大きいことを意味しています。一般に生産性はシステムの規模と相関があり、大規模なシステムほど低下してくることが知られています。 弊社の調査では大規模システムと小規模システムの間で見られる生産性のバラつきは4倍程度ですが、規模以外の条件の影響を排除していくと、一定範囲に収束することが確認されています。 .

プロセス・コストの分析方法

 業務プロセスのコストを分析する方法として昔から有名なのはレーンごとに業務フローを列挙するというものです。 業務担当者AがNo101のタスクを終了すると、その業務は次のレーンの担当者に引き継がれます。このケースでは、次の担当者は存在せずシステムが処理するので、業務遂行主体はシステムということになります。この業務フローは、システムがNo201のタスクを処理するとすべて終わりとなります。    業務プロセス全体のコストは、各タスクのコストを総和したものになります。各タスクのコストは、平均所要時間と時間単価によって計算されます。  システム投資によって生み出されるキャッシュ・フローは、この業務フローにおいてシステムが担当している部分を人的作業に置き換えた場合の、そのタスクのコストがいくらになるかという視点で算出します。システム化がゼロだった場合の、総人件費がシステムが生み出すキャッシュ・フローの最大値です。

ITバランス・スコアカードへの応用

 バランス・スコアカードの考え方を情報システムに応用したのがITバランス・スコアカードです。情報システムの場合には、明確な財務目標がない場合もありますから、実際には全体コストの削減や資産効率の向上といったものを目標とします。  以下はITバランス・スコアカードの戦略マップと設定したKPIの具体例です。

バランス・スコアカードの基本的な考え方

 バランス・スコアカードは、米ハーバード大学のロバート・S・キャプラン教授経営コンサルタントのデビッド・P・ノートン博士が考案した、情報化社会に対応した新しい業績評価フレームワークです。  従来の財務分析による業績評価(財務の視点)に加えて、顧客の視点、業務プロセスの視点、成長と学習の視点(アイデア、モチベーションなどの無形資産)をプラスした評価を行なうことで、 企業の価値を総合的に評価します。  企業は大きなビジョンをもとに戦略が策定されます。そして、その戦略を実現するための目標を定めるわけですが、バランススコアカードではここに上記4つの視点を活用します。各視点ごとに具体的目標を設定し、その進捗度合いを検証するための評価指標(KPI)を設定、到達度を評価していきます。  4つの視点における各目標やそれに基づくKPIは独立したものもありますが、相互に関連性があるものも存在します。的確に評価するためには相互の因果関係も理解しておく必要があるため、戦略マップと呼ばれる因果関係の地図も合わせて作成します。

キャッシュ・フローの予測が困難なシステム

 情報システムはその種類によってキャッシュ・フローの予測が困難なものがあります。特に情報系のシステムには直接その効果を金額換算できないものいくつか出てきます。またインフラ系のシステムも場合によってはキャッシュ・フローの換算が難しくなります。  一方、業務系のシステムは比較的キャッシュ・フローへの置き換えが簡単です。業務系システムを導入する効果を一般化すると以下の4種類に集約できます。  ・人員のシステムへの単純な置き換え ・システムを使ったリソースの最適化 ・処理能力の向上 ・人的ミスの回避  これらについては、削減された人件費など直接的にキャッシュ・フローを生み出す原資が存在するので、キャッシュ・フローの予測は容易です。  直接的にキャッシュ・フローに換算できないものについては、思い切って評価対象から除外するか、関連性のあるその他システムから、名目上、貢献度に合わせてキャッシュ・フローを分けてもらうなどの方法があります。

初期投資額の不確実性をどう考えるか?

 DCF法を情報システムに適用するにあたっての主要な問題のひとつが、初期投資額の不確実性といえるでしょう。 通常の投資プロジェクトであれば、1億円の投資で得られるものはほぼ決まっているので、投資金額自体が変化することはないと想定して計算を進めていきます。しかし情報システムの場合には、初期投資金額自体に大きなブレがあります。当初は1億円と思っていたものが、実際に作ってみたら3億円だったということがザラにあるのです。1億円で投資対効果がプラスと判断していたのに、実際には3億円というのでは話になりません。 DCF法をうまく適用させるためには、1億円は1億円で確定できるようする必要があるのです。  情報システムの初期投資額が大きくブレるのは、ソフトウェアの生産性にばらつきがあるからです。生産性が低いチームと高いチームでは最大6倍近くの差がつく可能性があります。弊社には3000件近いシステム・コストの評価実績がありますが、同一条件であっても6倍近く生産性が異なる事例が見られます。  しかし初期投資額のブレというものは、システムの規模を事前に特定し、開発にあたるチームの生産性を正しく評価することではるかに正確に予測することができるようになります。どのような条件の時に生産性がどの程度上下するのかというメカニズムは相当な水準まで解明されてきています。正しく事前評価をすれば、1億円が3億円になってしまうようような事態は避けることができるのです。

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