付録１

調達の現状
ケース１

A 自治体における人事給与システム構築プロジェクト【概要】
・ 情報化基本計画に基づき，各原課が業務を情報化。
・ システム課は，共通な基盤システムの担当。原課には側面支援。
【業者選定】・ 平成 10 年度に基本設計業者を選定。
・ 人事部門による業務分析は殆んど行われず，不十分な仕様のまま一般競争入札を実施。
・ 最低金額を提示した既存人事システムの担当メーカーB社が受注。

（１）プロジェクトマネジメントの普及不足（視点①）・・（２）プロジェクトにおける具体的方法論不足（視点①）・あいまいな仕様の解釈における受注側と発注側の調整方法がない。

（３）作業負担が過剰（視点①）・原課だけで予め仕様を確定させる事は時間的にも困難。

（４）職員の能力不足（視点③）・【システム構築プロジェクト】
・ 人事部門担当者が定期的に B 社の進捗報告を受ける管理方法でシステム構築を推進。
・ 詳細仕様は，詳細設計フェーズで B 社が実施。
・ B 社が提示する詳細仕様案に対して人事部門が意見を述べるやりとりを重ね，仕様変更に時間を要した。
・ 稼動まで 1 年を切った段階で，未だ詳細設計が固まらず。
・ しかし B 社の大丈夫との報告を受け，人事部門は特に危機意識がなく対策を実行せず。
・ 見かねたシステム部門が介入し，B 社に説明を求め，改善を要求。プロジェクトメンバーが一新され，リカバリーできた。

原課は、システム構築の方法やリスクを無理解。
原課では、情報システム調達において非科学的プロジェクトマネジメントが行われており，本当の管理ができていない。

原課職員に、システム調達の仕様を明確化するスキルがない。

（５）ＩＴ業界の環境（その他）
・・

安値受注などで、システム構築スキルの不足したメンバーが投入される。
受託側は，費用内で抑えようとパッケージカスタマイズで出来る範囲に拘泥。

調達の現状(つづき)ケース２

Ｃ自治体の会計管理システム構築プロジェクト【背景】
・ 安定的に稼動していたホストコンピュータによる財務システムを西暦２０００年問題を機会に置換。
・ クライアントサーバ方式によりシステムを再構築。
・ 同時に，他システムとの連携も目指す。
・ 原課が主導するプロジェクト。
【業者選定】
・ 従来システムの機能に加え，他システムの連携などを目指し，平成 8 年度に指名競争入札による仕発注様策定を委託。
・ 翌年に開発業務についての一般競争入札。
・ C 自治体のもともとの財務システムは D 社が開発を行ったものであったが，ライバルの E 社が積極的な営業戦略を打ち出し，破格の安値で落札。
【システム構築プロジェクト】
・ 営業戦略上の受託であり，E 社はリソースを十分に投入。
・ Ｅ社は、当初先行自治体で開発したシステムの活用を想定していたが，業務要件の相違により，活用が困難であることが判明。
・ 並行して開発していた他社の受託したシステムとの連携に関して，コミュニケーションが悪く仕様確定に時間を要した。
・ システム部門の支援を原課が拒否する形となり，結局，品質が安定しないまま本稼動。

（１）ＩＴ業界の環境（その他）
・・・・

D 社からのリプレースで新規業務受託を目指した E 社の安値入札に端を発する。
E 社はおそらく受託することを最優先に考え，このプロジェクトのリスク把握をおろそかにしたと思われる。
業務分析が不十分であることや，並行して開発している他システムのベンダーとも仕様調整が必要となり，受託後のプロジェクトが困難なものとなった。
しかし，民間企業のマインドを考慮すると，このような戦略を単純に非難することはできないのではないか。

（２）プロジェクトでの人間関係管理の不足（その他）
・・

ライバル企業間の意思疎通が難しいことは容易に予見できる事項であり，プロジェクトの進捗に影響を及ぼすような情報交換については，トラブルとならないようにマネジメントする必要がある。
発注側がシステム部門が様々な支援を試みたが，原課は不必要と判断したため，原課側の顔色を優先した業者は，状況改善の必要性進言を避けたと考えられる。

1

調達の現状(つづき)ケース３

F 自治体の人事情報システム構築プロジェクト【背景】
・ 自治体総合計画に基づく総合的な人事情報システム開発。
・ ホストオンライン方式からクライアントサーバ方式によるパッケージソフトへの移行を前提。
【業者選定】
・ ２段階審査による提案コンペ方式。
・ 第１次審査は指名４社に提案を求め，予め設定の評価シートに基づき職員が採点。客観的評価と主観加点を合算。
・ 第２次審査は，各社のプレゼンテーションを受け，自治体内の選定委員による主観的な評価。
【構築プロジェクト】
・ メーカーG 社系の地場業者 H 社が担当し，F 自治体の人事部門担当者が事実上の進捗管理。
・ G 社のワークフローパッケージを活用することを H 社が提案し F 自治体が了解。
・ 設計を進めるうちにワークフローパッケージでは実現できないことが頻発。F 自治体が運用でカバーするなど譲歩。
・ G 社パッケージでありながら，開発は G 社系ソフト子会
社 I 社であり，H 社が I 社との意思疎通を欠く。わずかな機能の確認に１ヶ月を要したり，ライセンス上，プログラムを改変できないことがあるなど問題が続出。
・ プロジェクトの終盤になって，パッケージとそれ以外のシステムとの連携に致命的問題が発覚。決裁権限確認などがワークフローから他システムへデータ引渡し後にしか行えず，ワークフローに戻せない。
・ 結局，仕様変更などで開発費の上乗せを行ったにもかかわらず，不満足な機能のまま運用でカバーして本稼動。

（１）プロジェクトマネジメントの普及不足（視点①）・

何をしたいのかという業務分析よりも，どのような技術で実現したいのかというシステム構成の整理に重きが置かれている。クライアントサーバ方式やパッケージソフトウェアの導入を最優先で考えたように見える。

（２）プロジェクトにおける具体的方法論の不足（視点①）
・・

選定の場面でも，何をしたいのかが十分に煮詰まっていないまま，ベンダーの提案を見てから投票するという方法を採用しており，客観的な機能評価よりも，プレゼンテーションの巧拙など情緒的な判断が反映した可能性がある。
ただし，このような採用の方法は全国で行われているし，パッケージソフトウェアが効率的で優れていると評する風潮が支配的な昨今では，このケースを取り分け批判できない。

（３）職員の能力不足（視点③）・・ワークフローの採用という重要な岐路において，技術的評価が極めて弱い。プロジェクトの後半に発覚した致命的問題などは，きちんとした技術者が十分な評価を行えば，事前に予見できる範囲と考えられる。また，調達時の評価を含め，外部専門家にアドバイスを求めた形跡もない。
ただし，パッケージの内容を詳細に評価することは簡単ではなく，自治体が技術的な判断を行うことができない。

（４）ＩＴ業界の環境（その他）
・地域代理店が受注した案件で，パッケージソフトウェアの理解，開発元との調整能力が不足していた。

2

調達の現状(つづき)その他のケース
・ 情報に対する不足感が話題にのぼることがしばしばあった。
どのような技術が実現可能なのか（１）プロジェクトにおける具体的方法論の不足（視点①）
・ 業者選定の基準，費用対効果の分析手法などがない。

どのようなパッケージが存在しているのか（２）標準的プロセスの適用の不整合（視点①）

それらの技術やパッケージにはどのような特徴があり，ど・ 自治体毎にプロセスが違うため，他自治体の取組をそのまま適用する事は難しい。
（３）作業負担の過剰（視点①）・ 教科書的プロセスの適用は、調達規模により負担が重い。
・ テストや監査を徹底するには作業負担が重い。のような問題があるのかベンダーの技術力やリソース状況はどうか
適正なコストは幾らくらいか等

・ 実際，同じような検討が複数の自治体で重複して行われていたり，同じようなシステムの調達・構築が異なるコストで落札されているという事例がある。
・ 自治体毎に契約，評価の役割分担が違い，他の自治体の事例を参考にするのは難しい。
・ 現状の情報システム調達では，開発業者がその後の運用も担当することを前提に行われている。
・ ベンダー毎にシステム仕様が異なっていて，業務のためにシステムを連携するのが難しい。
・ ベンダー毎にドキュメント作成の作法が違い，他のベンダーのＳＥが見ても理解し辛い。
・ 調達に関わる調達制度や会計制度，高度 IT 人材を育成，確保するための人事制度など，地方自治の制度上の制約が改革に足枷となっている。

（４）設計・開発技法の不足（視点②）・ ＳＬＡ策定方法がなく、開発と運用の切り離しが不可能。
・ 価格の積算技法がない。

（５）職員の能力不足（視点③）・ 高度 IT 人材の確保が困難。

（６）業者の能力不足（視点③）・ 要求仕様や SLA に完全に対応できる能力がない。

（７）組織的対応の不足（視点④）・ IT 導入の企画・管理が業務毎にばらばらに行われている。
・ 原課、情報システム部門、財政部門の役割分担が不明確。

（８）制度との不整合（視点④）・ 仕様変更を調達仕様書に見込む事は制度上困難。

（９）ＩＴ業界の環境（その他）
・・

情報サービス産業の能力、本当の競争力がなくなっている。
大手ベンダーを頂点としたピラミッド構造で、中小、ベンチャーの地場 IT 企業の新規参入が困難。
3

付録２

調達改革への取り組み
ケース１

高知県におけるライフサイクル調達の取り組み（高知県における実導入）【背景】（１）調達仕様書を職員が作成できない（視点①，③）（２）プロジェクトマネジメントが未熟（視点①）【概要】
・ 平成１４年度に情報システム調達ガイドブックを策定。

【確認できた効果】（１）プロジェクトマネジメントの体系化
・ 今まで情報システムの調達の現場では、個人の資質と経験に依存したマネジメントが行われており、知識を体系化して整理された作法が存在していなかった。

（２）原課でも一定水準の調達が実現
・・ 平成１５年度から１，０００万円以上の調達については調達ガイドブックを適用する事を全庁的にオーソライズ。
・ 調達ガイドブックを活用するための手引書を作成し、プロセス毎の成果物の例をテンプレートとして収録。
・ システム担当部門（情報企画課）に専任者を任命してガイドブックの活用を推進。
・ 調達ガイドブックを原課で利用してもらうために、支援室を新設し、調達ガイドブックの策定に関わった民間企業の担当者を半常駐させてサポート。

情報システム調達に携わったことのない原課の担当者が、当初、何をして良いかがわからないままにＡ４版で２枚程度の調達仕様書を書き上げたが、ガイドブック及びテンプレートに基づいて見直しを行い、支援室のサポートをうけながら、必要充分な数十ページの調達仕様書を書き上げた。

（３）詳細な仕様書の作成で開発が予定通り実現
・原課で調達仕様書の作成に手間取り、入札が予定より２ヶ月遅れで行われたが、中身の濃い調達仕様書だったので、入札後すぐに開発作業が始まり、予定通りに納品されて稼働した。

【明らかになった課題】（１）システム規模によっては作業負担が重い（視点①）（２）外部専門家に業務範囲が不明確（視点③）（３）職員の育成が必要（視点③）・ 現場支援として、１３課室の１５事業について仕様書作成支援、提案書評価等を行う。
・ 平成１６年度の予算要求時には３０課室５０事業の支援を実施。

4調達改革への取り組み（つづき）
ケース２

福岡県における開発技術標準【背景】【確認できた効果】（１）調達仕様書を職員が作成できない（視点①,③）（２）高度ＩＴ知識を持つ職員の確保が困難（視点③）（３）全体最適でのシステム設計が不在（視点②）（１）あいまいなシステム開発作業が定義可能
・ 業務標準化文書のシステム開発業務を方法論に従って開発プ【概要】（２）TSO（Total Cost of Ownership ）の削減
・ 電子自治体システムを構築する技術として、Ｊ２ＥＥ（Java2・ システム構築の改善を，標準技術の導入によって実現しロジェクトを推進し、システム開発会社から提出される成果物をチェックする事によって、システム開発に対するプロジェクトマネジメントが可能となる。

Enterprise Edition）準拠を基本とした標準的な技術を統一ルールに策定し、またデータ中心アプローチ（DOA）を実装できるアーキテクテャを統一ルール化し、技術革新への柔軟な対応、機能・業務双方の容易な拡張性を獲得でき、ＴＣＯが大幅に削減された。

ようという取り組みを推進中。
・ システム仕様の把握や実現性の判断が自治体側に出来ずに大手ベンダーの言いなりになっていることの解消のため，標準技術や文書表現の標準化を推進。
・ 業務システムごとにばらばらによく似たシステムが構築され重複が多く，しかし連携が進んでいないことを解消するため，システム連携方法の規定や業務処理手順の規定を整備。
・ 属人的なシステム立案の解消のため，各種標準化文書を策定。
・ 高度 IT 人材アカデミーにより職員を養成。

（３）システム間連携が容易に可能・TRM（Technical Reference Model）を用意し、システム連携方法や運用保守などの管理形式を統一する事を実現した。

【明らかになった課題】（１）標準化文書の構成の検証（視点①）（２）SLA（Service Level Agreement）の標準化（視点④）（３） 「共通化技術標準」の適合認証（視点②）5

調達改革への取り組み（つづき）
ケース３

長崎県における取り組み【背景】【確認できた効果】（１）調達仕様書を職員が作成できない（視点①,③）（２）大手ベンダー独自技術に依存（視点②）（３）地場ＩＴ産業を育成したい（その他）（１）発注内容を職員が把握
・ 発注単位が小さく、職員が内容を把握しているため、ミス、トラブルにも迅速に対応できる環境となり、納期の遅延も少なくなった。

（２）大手ベンダー依存から脱却【概要】
・ 民間から CIO を招聘し、権限ある参事監として任命。
・ CIO 中心に職員が業務分析を徹底。それに基づき内部で基本設計を行う。集中 DB 方式を採用し、システム間の連携の電文も定義している。
・ メーカー色をなくすため、開発技術としてオープンソー
スソフトウェア（Linux，Mysql，PHP）を採用。
・ 発注仕様書への記載漏れなどは、発注側である自治体側のミスとして責任を持って追加費用で別発注を行う。
・ モジュール単位等，数十万円から大きくても一千万円程度の小さな単位で分割発注を実施。例えば、従来の考え方では電子申請システムとして１本の契約を、１００件程度の委託契約で実施している。
・ NPO 法人による人材育成の仕組み、成果をオープンソース化する仕組みを立ち上げ中。

・ 発注金額が小さくなり、結果的に大手ベンダーの落札が減った。
・ オープンソースソフトウェアの採用により、庁内職員でも安価で容易に技術を習得できるようになった。

（３）システム間連携が容易に可能
・ 業務機能毎の個別データベースではなく、基盤となるデータベースを一つにし、個々のシステム構築後にシステム間連携の必要がなくなった。

（４）透明性の高い公平な入札が実現
・ オープンソースソフトウェアの採用により、大手ベンダーと中小地場ＩＴ企業との差が縮まり、メンテナンス作業や改修作業を１社独占とする必要がなくなった。
【明らかになった課題】（１）個人への依存が高まった（視点③）・ 技術面において参事監１人に依存している。また、２〜３年で異動してしまう職員の育成も課題。

（２）地場ＩＴ企業の育成（その他）・

今まで大手ベンダーの下請けとしてやってきた地場ＩＴ企業
は、提案能力や業務知識の点で、大手ベンダーと互角に戦えるだけの力が備わっていない。
6

調達改革への取り組み（つづき）
その他のケース【背景】【明らかになった課題】（１）調達仕様書を職員が作成できない（視点①,③）（２）大手ベンダーに依存（視点②）（３）行政としての制度的な問題（視点④）（４）地場ＩＴ産業を育成したい（その他）（１）組織的対応の不足（視点④））【概要】（３）制度との不整合（その他）

・ 情報システム調達に関わる人材育成を行いたいが、２〜３年で異動する人事制度では、長期の育成は不可能。
・ 業務に精通した原課と技術知見のある情報システム部門が協力して調達を行う体制が不可欠であるが、共同でプロジェクトチームを編成する事が難しい。
・ ライフサイクル調達を考える時、予算の決定権限が財政部門にあるため、予算をライフサイクルを通して確保す

・ 高度 IT 人材の育成及び確保は、現状の人事制度では難しい
・ 情報システム調達の庁内の役割分担が明確になっていない。

（２）ＩＴ業界の環境（その他）
・ 今まで大手ベンダーの下請けとしてやってきた地場ＩＴ企業
は、提案能力や業務知識の点で、大手ベンダーと互角に戦えるだけの力が備わっていない。
・ 仕様変更への対応責任が不明確。
・ 調達手続き中の交渉・請願は，自治法になじまない。

（４）追加経費・不確定経費の問題（その他）
・ 運用開始後に手直しが必要となる場合，予算確保がされていない事が多い。

（５）具体的な手法の不足（視点②）・ SLA の策定技法がない。
・ 価格の積算技法がない。
・ 納品物検証の具体的な方法論がない。

ることが難しい。
・ 発注後の仕様変更については、追加契約の処理を考えると困難であり、ベンダーとの付き合いの中で含めて開発を行ってもらう。
・ 地場ＩＴ企業の育成のために，優先的に発注を行おうとするも，ＷＴＯルールからの逸脱が懸念される。また，行政事務の業務知識が不足していることがある。
7