文：「情報システム調達研究会」事務局
10月17日、本年度第1回目となる情報システム調達研究会報告のオフ会（全体会）が開催された。オフ会では、本年度の主要研究テーマである、「調達ガイドReference Model」および「情報システムのベンチマーク」について中間取りまとめの発表を行った。本稿では、その中から「情報システムのベンチマーク」について、その分析結果と今後の方針を報告する。
前々回（第2回）のコラムで、当研究会で行う「情報システムのベンチマーク」の検討イメージおよび調査・分析手法について述べた。自治体が情報システム導入や評価する際に必要なシステムの規模、予算、品質、構築期間などについて、情報システム構築の事例データを収集・分析し、規模の設定や品質管理、見積評価などに役立つベンチマークを検討していくという試みである。今回は実際に集まったデータによる分析結果の一部を紹介したい。
工期、コスト、品質などの適正度合いを探るツールとして
研究会では、企業における情報システム構築の定量的データを提供する日本情報システムユーザ協会（JUAS)「ソフトウェア・メトリックス調査2007」の調査項目の中から、自治体でも簡単に取り組みやすい項目を選択して調査・分析を行った。
調査の実施に際しては、初めての取り組みということもあり情報の集約には苦労した。「過去のデータを分析してどうするんだ」「回答できる項目が少ない」「守秘義務で数字を出せない」など、実施前には研究会メンバーから様々な意見が上ったが、実際に結果を見てみると「なるほど、そうやって分析をするのか」と好評であった。
今回は11システムのデータが集まったが、例えばこのデータから「予算－工期」の適正性についての分析ができる。ベンダーに「このシステム、どのくらいの金額／期間でできる？」と聞くと、「1年で1億円位ですかね」といった答えが返ってくるが、これは、勘と経験に基づくものである。もっと正確性を高めるために、統計データが使えるのである。以下の図1がその分析結果である。中央の3次曲線が国内の情報システムを分析した一般的なデータであり、その周辺に今回収集したデータをプロットしている。
| 図1●一般的なシステムの予算－工期とのズレ |
 |
| 国内の情報システムを分析した一般的なデータに今回収集した自治体のデータをプロットしたもの。 |
ここで強調しておきたいのは、「曲線から大きく外れたシステム＝計画の出来が悪い」と言っているわけではないということだ。図1を見ると、Gシステムは曲線から大きく外れているが、このシステムはLANを中心としたシステムであることから、グループウェアなどのライセンス料が大きな割合を占めたためかもしれないと考えられる。FやJのシステムは、規模が大きいシステムが安価に契約できたのかもしれないし、一般的な工期より長い工期で構築したものかもしれない。今回はヒアリングによる検証を行っていないので推測の域を出ないが、実際に各自治体はこのようなデータを使うことにより、工期の妥当性を関係者に確認しながら計画を作っていくことが可能になる。
図中の矢印は、予算と実績が大きく違う場合の分析である。各システムのデータを収集したときには、計画値と実績値を登録するようにしている。そこで、計画値と実績が同じものは、単に英語の記号「A」「B」「C」……として記述している。図の中で「F」と「FR」といったようにR（Realの略）がついているものがあるが、この場合は「F」が計画値、「FR」が実績値ということである。
例えば、Dシステムは予算をとったときには高めの予算を確保していたが、入札後にDRの金額で契約しており、結局は標準的な費用に落ち着いたのではないかと考えられる。逆にIのシステムのように、予算のときは標準的だったのが途中で費用が増加しているものもある。ここで、DのシステムやIのシステムはグラフ中の曲線の左上にあるが、この部分にあるということは、工期が標準より短い高い可能性がある。このようなデータによる分析は、あくまでも参考値であるが、JUASが集めた過去の民間のシステム開発事例データでは短工期で開発したシステムは満足度が低くなるという結果も出ていることから、グラフの読み方を知っていればプロジェクトを注意しながら進めることも可能になる。このように従来の勘と経験に頼る方式に比較すれば、定量データを使った分析方法は、調達においてかなり有効な方法といえるのではないか。
個別のシステムの分析も今回は試みている。例えば「Aシステム」を工数で分析してみたのが（図2）である。予算を基に一般的な工数にすると71．7人月、工期を基に一般的な工数にすると72．3人月、実際には計画工数で81人月、実績工数で87人月になっている。一般データに対して人を若干多く使っているが乖離は小さく、一般的なデータの範囲内と判断できる。
| 図2●一般的なシステムの工数－工期と「Aシステム」とのズレ |
 |
上記のような分析のほかにも様々な分析ができる。例えば、Aシステムのテストの密度と品質や満足度の関係を見てみよう。
このAシステムの場合、テストの密度は、単体テストで、1ファンクションポイントあたり0.39ケース、コード数である1KLOCあたり3.25ケースだった。これを一般的なテスト密度と比較すると、10分の1程度しかテストをしていないことが分かった。一方、結果としての欠陥率は0.264（一般的なシステムの範囲内）であり、稼働後一カ月の不具合数も、ユーザの受け入れ試験のときの10分の1の不具合数という良好な結果を得ていた。この場合は、テストケース密度が低いという問題の兆候があるものの、品質という観点で見ると、問題の兆候は低品質という形で顕在化しなかったということが分かる。
では、満足度という観点から見るとどうか。開発部門は満足しているものの運用部門がシステムに不満を感じていた。この点については、テスト密度を高めることで防げた問題もあるかもしれない。つまり、このような問題の関連性について、さらなるヒアリングにより改善を図る余地が明確になるかもしれない、ということである。以上のように、A4の調査表数枚でこれだけの分析が可能となる情報システムのベンチマークは、PMOにとっては強力なツールになる可能性を秘めているといえる。
|
