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

開発コストの評価方法

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

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

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

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

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

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

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

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

複雑なシステムはコストが高いというのはウソ

 ベンダーからシステム提案を聞いたり、見積書の提供を受けたりする際に、担当者から「このシステムは複雑なのでコストが高くなってしまう」という説明を受けることがあります。複雑なシステムは高価だという話に納得してしまいやすいのですが、ここには大きな落とし穴があります。  そもそもソフトウェア工学の世界では「複雑な」なシステムというものは存在しないのです。本コラムでも何回か解説しましたが、情報システムというものはどんな種類のものであれ、入力、出力、加工、蓄積といったごく簡単な機能の積み重ねで出来ています。  これは名簿を管理するシステムであっても、ロケットを制御するシステムであっても、金融機関の勘定系システムでも同じです。 「複雑な」システムというのは、おそらく機能がたくさんあるシステムのことを指しているのだと思いますが、これはまさに規模が大きいシステムということになります。つまり、ソフトウェア工学の世界では、複雑なのではなく規模が大きいのです。  もしベンダーからの説明の通り、機能の絶対数が多いシステムであれば、コストが高くなるのは避けられません。ですがイメージとして複雑であっても、機能の絶対数が少ないシステムの場合には、コストが増加することはありません。  あいまいな表現を避け、機能の絶対数を数値で示すことができれば、このような誤解が生じることはありません。規模の数字による特定は非常に重要なのです。

価格交渉の第一歩は発注側の体制強化から

 システムのコストが増大してしまう理由には様々なものがあります。米国の民間企業の調査によると全案件の実に53%に遅延もしくはコスト増加のトラブルが発生しています。システム・コストが増加する原因は以下のようなものがあります。  ①機能要件の見誤り ②業務プロセスに関する情報不足 ③ベンダーとユーザーでの責任分担不明確 ④システム要件未決定 ⑤頻繁な仕様変更  このうちもっとも多いと思われるのは①機能要件の見誤りです。これはベンダー側の担当者がシステムに求められる機能要件を正確に仕様に織り込めず、手戻りが生じることが原因です。 これには発注側にも責任があるケースがよく見られます。業務プロセスが不明確なままベンダーに作業を丸投げし、仕様が未確定のまま設計が進んでしまうといった事態です。ベンダー側の担当者が優秀であれば、発注側が曖昧な状況であっても、うまく解決していくことが可能です。しかしベンダーの担当者がすべて優秀なわけではありませんから、時としてこのような問題が発生します。  ②から⑤についても発注側の体制がしっかりしていれば防げるものばかりです。上記データはプロジェクトの予算超過についてのデータですが、これは発注前の価格交渉や予算策定でも同じことです。 ベンダーに対してどんな機能をシステムに求めているのか、正確に伝えることができなければ、ベンダーは正しく見積もりをすることができませんし、ユーザー自身も価格を予想することができなくなってしまいます。

ソースコード生産性を使えば複数システムのコスト比較が可能

 コード行数の情報を使って複数システムを比較し、高いか安いか判別するには、ソースコード生産性という指標を用います。  ソースコード生産性はソースコードの行数(あるいはファンクション・ポイント数)をシステム開発に要した工数で除して求めることができます。 考え方としては、土地や建物における坪単価と同じです。ソースコード生産性が高い数値を示すシステムは単位あたりのコストが安く、逆にソースコード生産性が低いシステムは単位あたりのコストが高いということを意味しています。  ソースコード生産性の数値は、標準的な環境でトラブルなく開発された案件であれば、一定の範囲に収まります(具体的な数値は、本サイトで紹介している弊社マニュアル書籍をご覧下さい)。 この範囲から逸脱したシステムには必ず何らかの原因があります。もしこの原因がベンダー側にある場合には、本来は値引きの対象となるものです。

ソースコードの量が分かればおおそのコストは決まったようなもの

 前回まではファンクション・ポイント法によってシステムの規模を特定する方法や、もっと簡便にソースコードの行数を使って同じくシステム規模が特定できることを説明してきました。  システム開発の環境はシステムによって様々であり、コストもそれによって大きく変わってくるといわれています。ですが、システムのコストの大半は「システムの規模」によってほぼ決定されてしまいます。  ソースコードの量が2倍になれば、システムのコストも基本的には2倍になります。厳密にはシステム規模とコストは正比例の関係ではなく、コストは規模の累乗関数となります。簡単なイメージで説明すると、ソースコードの量が2倍になれば、コストも2倍になりますが、ソースコードの量が10倍になると、コストは10倍ではなく、12倍だったり15倍だったりします。  このあたりの具体的な数値は本サイトで紹介している弊社マニュアル書籍をご覧いただければと思いますが、ともかくケタが同じ範囲ではほぼ比例し、ケタが変わると単純比例ではなくなるといったイメージになります。  ですので、複数のシステムを比較した場合、ソースコードの量が同じレベルなのにシステムの開発コストが2倍も3倍もするシステムというのは何らかの問題を抱え、コスト増加してしまったシステムということになるのです。

プログラマの個人差はどう考えればよいのか?

 前回、オープン化が進んだ現在でもソースコード行数は有効な指標であると説明しましたが、プログラマの個人差は影響しないのでしょうか? つまり能力が高いプログラマやSEがシステムを開発するケースと、そうでないケースでは、同じ機能でありながらコースコードの量が異なってくるのではないかという問題です。当然、能力の低いプログラマやSEからなるチームではコードの総量が多くなり、割高になるではないかと懸念されます。  確かにプログラマの力量と開発生産性には大きな相関があります。弊社のテストでは高い能力のチームと低い能力のチームでは生産性に6倍もの差が開きます。また能力の高いチームでは、場合によっては50%程度コードの量を少なくすることが可能です。  ですが実際に開発に従事するチームでそこまでの差が開くことはほどんどありません。特定のチームだけに優秀なSEやプログラマを集中させることは、現実のオペレーションを考えると不可能だからです。  日本のシステム会社は欧米に比べると定着率が高く、年功序列型です。しかも新卒採用の割合が高いのが特徴です。新卒時には適性がどの程度あるのかは分かりませんから、どのチームに優秀(将来優秀になる)なSEやプログラマがやってくるのかについては数学的にランダムになります。 若手は経験が浅く、ベテランになるほど経験値が上がってきますが、ベテランは一定割合でチームから去り、一定割合で新人が入ってきます。 結局のところ、チームの能力は上下のブレはありますが、一定の範囲に収斂していくことになります。  ということで、発注するベンダーの人的な能力はマクロ的には常に平均値水準であると考えて問題ありません。もちろん中にはシステム会社の総力をあげて取り組む案件というものがあり、そこには優秀な人ばかりが投入されるという特殊なケースもあることでしょう。ですが、そのようなプロジェクトはごく稀にしかありません。

ソースコード行数は今でもシステム規模の特定に有効な指標

 ファンクション・ポイント法よりさらに簡単に、システム規模を特定する方法があります。それはシステムのソースコード行数を用いるというものです。  使用する言語が同じであれば、ある機能を実現するプログラムの記述に必要な行数はほぼ同一です。したがってソースコードの行数はシステムの規模とほぼイコールということになります。 実際、メインフレームが主流の時代には、アーキテクチャが同一で、言語もCOBOLに統一されていましたので、ソースコード行数(Step数ともいう)が規模を表す重要な指標でした。ベテランのSEになれば、おおよその機能がイメージできると、即座にコード行数が頭に浮かんいました。「これのシステムはだいたい何Step?」「じゃあ○×億円くらいですね」などという会話が日常的に交わされていたのです。  最近ではシステムのオープン化が進み、複数のアーキテクチャが混在する環境が当たり前となってきました。また使用する言語も様々です。したがって理論上では、ソースコードの行数は様々な値をとることになります。  となると、コード行数は規模の特定には使えないのでしょうか?そんなことはありません。コード行数はシステム規模の特定において十分実用になります。ここでも、本コラムで何回か述べているマクロ的現象が効果を発揮します。  たしかにCOBOLとJavaでは、同じ機能を実現するために記述しなければならないコードの行数は異なります。 Javaの方が抽象度が高く、カプセル化が可能ですので、一般に少ないコードで済むといわれています。実際、弊社のシミュレーションでも、COBOLはJavaに対して3倍程度の文章量が必要との結果が出ています。 しかし一方で、抽象度が高い言語ほど、事前の構造設計が重要となり、コーディングの作業速度は遅くなるというのも事実です。結果として、COBOLでもJavaでもコードを記述する生産性には大きな違いは生じません。  したがって、システムの見積書、あるいは提案書をベンダーから受け取るときには、必ずコード行数の見込みを記載してもらうとよいでしょう。

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