文:「情報システム調達研究会」事務局

 情報システム調達研究会では、2007年度から「自治体の情報システムのベンチマーク」について調査・分析をスタートさせた。日本情報システムユーザ協会(JUAS)の協力を得て、企業における情報システム構築の定量的データを提供する「ソフトウェア・メトリックス調査2007」の調査項目の中から、自治体でも簡単に取り組みやすい項目を選択して調査を実施しており、民間とのデータ比較も可能となっている。

 連載第4回(昨年11月に公開)ではプレ調査の結果を報告したが、今回は本調査(2007.12-2008.1に実施)の結果を報告する。神奈川県、滋賀県など、9自治体28システムのデータがが収集まった。

 調査の結果、多くの自治体システムはが標準的な工期より長めの工期で開発を行っており、計画時点で改善の余地があることが分かった。また、システムによってはファイルやプログラムの分割が多すぎるなど構造的な問題も調査を通じて浮かび上がってきた。

開発単価は自治体の方が安い

 収集したデータは、ファンクションポイント(FP)等の規模を基準に分析をしている。しかし、すべての自治体がFPやコード数などで開発規模の管理ができているわけではない。そこで、評価対象のすべてのシステムの規模について、「ソフトウェア・メトリックス調査2007」のデータを基にFPに換算して分析を実施した。

 システムの規模を表すFPという単位を初めて聞く人は、建物でいえば坪のようなものだと思っていただければイメージしやすいだろう。100坪のオフィスといえばおおよその広さが分かるし、「坪当たりの単価」「坪当たりの欠陥数」といった具合いに、コストや品質などについて客観的な比較検討を行うための指標にもなる。

 調査の結果、FP当たりの開発価格は平均で2.7万円/FP、最も高く払っているシステムは9.7万円/FP、最も安いシステムは0.5万円/FPであることが分かった。基準となるFPには統計処理した換算データを使ったとはいえ、システムにより支払額が大きく違っていることが見て取れる。

 JUASによる「ソフトウェア・メトリックス調査2007」によると、民間企業のシステムでは平均が11.7万円/FPであり、全体的に自治体のシステムは低価格で開発していることがわかる。FP当たりの開発価格が最も高かった9.7万円/FPのシステムが、ベンダーにカネを払いすぎかというとそういうわけでもないということだ。

 ただし、FPは開発の難易度やシステムに求める信頼性にも左右されるし、今のところFPを使いこなせる人材は少なく算出した数値がぶれることもあるため例えば「自治体システムの開発単価は10万円/FPを基準価格とする」と言えるほどには、まだデータの信頼性は確立していないことには留意が必要だ。

システムの品質は民間企業とあまり変わらない

 規模をベースにシステム稼働後の欠陥数を見てみると、平均が0.0054個/FP、最大は0.016個/FP、最小は0.0003個/FPだった。システムによって欠陥数には大きな開きがある。

 今まででは、稼働してから「何だか欠陥が多いなぁ」と思っても、ベンダーに「こんなものですよ」といわれると相手が専門家だけになかなか反論できなかった。しかし、このようなデータを使うことで、「おかしくないですか?」と切り返すきっかけができる。その上で品質が悪い原因を解明するなど前向きな議論ができるのではないだろうか。

 開発規模当たりではなく、システム全体工数をベースにした欠陥率(ユーザの行う受入れテスト+稼働後一カ月の間に発見された欠陥数を全体開発工数で除算したもの)も、システムの品質の分析ではよく使われる。JUASでは、欠陥率0がAランク、欠陥率3以上がFランクとして民間企業の事例を分析しているが、今回の自治体システムは、ほとんどのが一般に許容されるDランク(欠陥率1未満)に収まっていた。

プロジェクト全体の状況把握方法での工夫

 また、システムの全体状況を一見して判断できるように、下の図1のような分析も行っている。今回は業務に直結した処理時間改善など、業務特性に依存する成果の評価は難しいと判断し、成果の評価の代わりに満足度を使い、投資執行の適正さとシステムの品質という観点を中心にデータの収集を行っている。

 図1は「要件定義の経験がある人が管理したシステムか?」「仕様は明確に書かれていたか?」「工期は標準工期に対して十分に用意されていたのか?」「プロジェクトマネジャーに適正な人が配置されていたのか?」「その結果の欠陥率はどのレベルになったのか?」「その結果としてどのくらいの満足度になったのか」が一見で分かるように整理してある。現場担当者はもっと詳細なデータを分析するが、CIOや市民への説明としてはこのくらいのレベルで行われた方が分かりやすいのではないだろうか。

図1●投資執行の適正さとシステムの品質などの満足度
図1●投資執行の適正さとシステムの品質についての満足度
CIOや市民が一目で分かるように整理した。

 多くのシステムを俯瞰したイメージは以下の図である。CIOは、この中から問題のあったシステムを抽出して、失敗を次に生かしていくためのヒントを考えていくことも重要である。例えば、プロジェクトマネジャーの経験が不足していて失敗したシステムがあったとすれば、次に開発を行う時には、プロジェクトマネジャーに面接を取り入れるなど、失敗に対する対策を打っていくことも可能だし、中間段階でこの俯瞰した図を見ることで、問題をはらむハイリスク・プロジェクトを抽出することも可能である。

図2●多くのシステムを俯瞰したイメージ
図2●多くのシステムを俯瞰したイメージ
CIOは、この中から問題のあったシステムを抽出して、失敗を次に生かしていくためのヒントを考える。