年度

区分

監査対象

１５

大阪府電子調達システム開発委託（第一期）

○H14電子入札システム開発分の導入業務における安全性・信頼性・効率性の確保の確認

大阪府電子調達システム開発委託（第二期）

○H15開発分（電子入札システムの機能追加開発、業者情報システムの開発、調達業務支援システムの設計）の各業務における安全性･信頼性･効率性の妥当性監査

１６ 

大阪府電子調達システム開発委託（第二期）

○H１5開発分の｢導入業務｣における安全性・信頼性・効率性の確保の確認

○H16開発分（電子入札システムの機能追加開発、業者情報システムの機能追加開発、調達業務支援システムの開発）の各業務における安全性･信頼性･効率性の妥当性監査

１７

大阪府電子調達システム開発委託（第二期）

○H１6開発分の｢導入・運用業務｣における安全性・信頼性・効率性の確保の確認

○H17開発分の安全性･信頼性･効率性の妥当性監査

項目

指摘事項

対応状況

(1)新システムの全体像確立 

新システムにおける３サブシステム連携の全体イメージの統一化が、共有されていない。

 新システムの全体像をまとめた。

(2)要件定義工程の進捗に関する具体的な尺度の設定

要件定義の進捗に関する具体的な尺度の設定が、なされていない。

プロジェクト会議において、進捗状況の報告を求めた。

項目

指摘事項

対応状況

(1)大阪府の作業範囲の明確化と見直し

既存のシステムがあるものは「新旧システム要件比較表」を作成し、新システム稼動後のルールや体制の見直しを行い、現行システムと新システムのルールや体制の変更点を明確にし、庁内で承認を得ておくことが重要です。

「現行システムと新システムの機能比較表」をもとに、新システム稼働後に影響を受ける業務・管理体制・組織・ルールの見直しについて、庁内の別の会議体によって検討した。

(2)システム化の目的の実現

システム化の目的がどの機能において反映されているかを、全庁的な観点からみた共通認識および各部局の意見統一、またＢＰＲについての検討を中心に進める必要がある。

全庁共用システムとしての観点から見た業務の標準化および効率化の検討、各部局の意見統一化が細部も含めて検討し、庁内の他の関連システムとの連携による重複事務の削減も検討した。

(3)プロジェクト運営の強化

・トップダウンによる全体開発方針の明確化

府庁側の意見の集約や意思決定に多くの時間を要しており、事務局がより一層の関連部署との調整統括機能を発揮することにより短期間での要件定義を完了させることが望まれる。

システム全体に影響する課題を解決し、システムに関する全体課題の検討の場として、プロジェクト管理会議を設置し、開発業者に対して最優先課題としてシステム全体像、システム間連携、移行計画などの提示を促した。これによりトップダウンによる全体方針が明確になり、それを各開発会議に連携し反映することで、全体と個別課題に関するぶれが少なくなり、システム全体としての整合性がとれるようになった。

・    開発体制の見直しと、会議の目的の明確化

3サブシステムの開発を検討する会議で、システム間連携や移行など、電子調達システム全体の整合性やシステム間を横串で捉える必要のある課題に対して対応することは困難であり、手戻りの繰り返しが多く見られるようになってきた。

また、要件定義作業と部局間調整作業が混在して進められているケースがある。

８／末において開発体制が大幅に見直し、業務知識の豊富なメンバーを各会議に分かれて参画させた。その結果、課題管理表において保留になっていた課題項目の多くが早期に解決されるようになった。

項目

指摘事項

対応状況

(1)プロジェクト運営の強化

開発受託者として現在の状況が緊急事態であることを認識し、経営トップ自らが行動に移すことを求めた。

平成15年11月より、本プロジェクト最高執行責任者自らがプロジェクト管理会議に出席し、プロジェクト全体の課題に取り組み、方向付けと改善に対する対策を説明し、大阪府に対して合意および承認を得るように積極的に行動した。また、現場に対して適切な指示を行った。

プロジェクト全体の遅延が大きくなってきたため、プロジェクト管理体制及び開発体制の強化を求めた。

プロジェクト管理体制に増員がなされ、プロジェクト全体のコントロールが可能になり、機能するようになった。製造の工程に入った段階で、パートナー企業も含めた積極的な人員投入が行われた。

平成16年3月8日稼動の実現を目指して、緊急時における緊急対策体制の確保を求めた。

平成16年3月3日に、危機管理策として、「緊急対策体制」を構築した。また、パッケージや業務等に精通した専門スキルを保有した技術者の増員も図られ、問題点のタイムリな収集と情報共有が可能になりました。 

(２)対応策の明確化と開発進捗管理のための計量的な資料の提示

要件定義（ＳＡ）／基本設計（ＵＩ）のレビューが行われたにも拘わらず、システム全体方針および課題が未確定のまま、個別課題の検討が先行されたため、整合性の矛盾や漏れが発生し、要件定義（ＳＡ）／基本設計（ＵＩ）工程が確定せず、全体的に約３ヶ月の遅延が回復できないまま、次工程（詳細設計（ＳＳ）工程）に進んだ。今後、開発要員を投入してこの大幅な進捗遅延を吸収できる製造工程（プログラム設計（ＰＳ）工程〜単体テスト（ＩＴ）工程）に、納期の遵守と品質の低下を防ぐために、より厳しい進捗管理と品質管理を具体的な管理指標を用いてプロジェクトを進めていく必要があることを指摘した。

 プログラム設計、プログラミングについては、作成本数を基準にした予実績管理、テスト工程についてはテストケースの消化率を進捗率として、毎週のプロジェクト管理会議で報告された。

(３)問題点の原因の特定の迅速化と調査・分析の徹底

  平成16年2月下旬にシステムテスト、総合テスト、運用テストを実施した際の問題点（不具合）に関して、原因の特定に時間がかかっていた。

 プロジェクト内のコミュニケーションの徹底を呼びかけた。

データベースに関する性能の低下やデッドロックに対する対処などについても、些細なチューニングや変更により、性能面等で大幅に改善されることがあり、さらなる調査・分析をより細かく実施することが必要である。

ＩＴ推進課の協力を得て、進めるようにした。 

進捗を急ぐあまり、品質面でのチェック、レビューが疎かにされている面が見受けられるので、納期遵守と品質確保の両側面から進捗管理をすることが必要である。

十分な検証期間がとれるようスケジュールを調整することとした。

(４)システム連携についての具体的な検討および必要工数の明確化

システム間連携における製造工程後の各々のシステム間連携（結合テスト）段階においてシステム間の不整合という大きなリスクが発生することが予測されることから、今後、より具体的なインタフェース仕様を決定していく必要があることを指摘した。 

 新システムにおけるシステム連携の全体イメージの統一化に関するドキュメントが開発業者から提示され、基本的には大阪府と開発業者の間で共通認識に基づく検討が可能になりました。

システム間連携に関する機能の検証は、「総合試験」工程の2月下旬で、インタフェース仕様の不整合による障害が発生する可能性を指摘した。特に、パッケージの開発元が異なっていることから、一部の機能において言語仕様の違いにより引き起こされる障害を防止するためにも、開発元間の、より緊密な準備と打ち合わせを実施することを求めた。

言語仕様の違いにより引き起こされる障害が平成16年2月下旬の「総合試験（ＳＴ２）」の工程において発生した。急遽、稼動実績のある開発言語により、開発を行い、対応した。　

システム連携については、進捗管理表上、納期面ではスケジュールがほぼ遵守されている状況だが、進捗と品質の確保にばかり目を向けていると、システム間連携の結合フェーズにおいてイレギュラーな情報連携があった場合に、障害が発生することが予測され、そのリスクを考慮しておかないと本稼働リリースは困難になることを指摘した。

当面利用しない機能について、開発を遅らせることにより対応した。

(５)入出力設計（画面・帳票等）における設計ポリシーの確立 

 画面設計に当たって、その設計ポリシーが欠落している状況が認められましたが、他のドキュメント（システム化業務フロー、帳票設計書、その他）においても、ポリシーの整理が必要である。

３システムの操作性の統一を図り、大阪府のユニバーサルデザインにもある程度準拠した設計方針を考慮したＧＵＩの標準化、さらには「電子調達システム」全体の画面ポリシーを規定した「大阪府電子調達画面ポリシー」平成15年10月に規定した。

(６)基本設計における成果物の品質改善 

基本設計のドキュメントは、大阪府が意思決定を行うための判断材料や前提条件に関する項目が不足している場合が認められた。また、新旧機能比較表の提示や要件定義における現行システムと新システムの差異の可視化についても十分な取り組みが行われていない状況にある。

平成15年12月の第2週において集中的な討議が双方でなされた結果、大幅な品質の改善が認められるようになりました。

(７)システム監査へのさらなる協力

システムテスト、運用テスト工程で発生した単体テストレベルの不具合の原因がどの工程で作り込まれたのかを明らかにするためにも、単体テスト時のテストケースや成績結果がわかるようなドキュメントの提示が必要であることを指摘した。

既存の資料の活用により、ドキュメントの整備を進めた。

項目

指摘事項

対応状況

(1)事務局の体制の充実

平成16 年度においては前年度に比べて開発規模も大きく、さらに会議体の開催頻度も多く、各部局のリーダの積極的な協力と、自主的な推進が必要である。

特に、「実績評価型指名競争入札方式」の「自動審査機能」の適用は、複雑であり、自動審査項目の絞り込みと審査ロジックの簡素化を行うため、事務局による取りまとめと実行可能な結論に向けての方向付けが必要である。

開発体制の見直しにより、各部局の意識が高まり、プロジェクト推進に関して協力的になった。

・    会議の時間短縮

各会議において、ある課題について何度も会議にかけられ、出席人数の多さもあって、なかなか結論が出ず、時間が多くかかる場合がある。

時間内に完了できない課題は、参加者を絞って検討し、その内容を開発会議にフィードバックしたり、事前資料の配布、参加者による検討項目の事前抽出等により、時間の短縮が望まれる。

時間が多くかかり時間内に完了できない課題の場合は、参加者を絞って検討し、その内容を開発会議にフィードバックするような対応をとった。また、事前資料の配布も各開発会議において徹底されるようになった。

・承認ルールの確立

各会議間の報告、承認のルールが曖昧であり、一度決定したことが後戻りしないような体制がさらに必要であることを求めた。

プロジェクト内のコミュニケーションの徹底を呼びかけた。

(3)システム運用に係る不備対応項目と要望項目の切り分けを調整する場を設けること

大阪府から開発業者に対して、元々の仕様がどうであったのか、不備対応なのかまたは要望なのかの項目の洗い出しを要請していたが、具体的に切り分けされず、検討する場がなかった。

切り分け会議を設置して、集中して解決するようにした。

(４)他のシステムとの連携について、テスト環境の確保を行うこと

平成１６年度開発において、財務会計システムなどの他のシステムとの連携について、テスト環境の確保を行うことを求めた。 

 システム連携のテストおよび検証環境を確保するために、開発業者でテスト環境を用意することになった。

(５)データ移行計画を早期に確定すること

新システムの業務範囲が明確でなく、現行データの移行と新データの入力範囲が確定していない状況となっていたので、データ移行計画を早期に確定することを求めた。

データ移行の調査、どこまでシステムにのせるかを検討した。

(６)入札契約センター（ＮＫＣ）の制度設計や庁内決裁ルールなどの規程改定についてできるだけ早急に承認を得ること

入札契約センター（ＮＫＣ）の運用については、業務の流れが明確でなく、平成16年12月にその資料が提示された。ＮＫＣの組織については、運用面、システム面および制度面から実際に機能するかどうかの早急な検証を求めた。

開発工程上、影響があるため、当面、NKCの仕様は固定し、17年度に運用が固まってから、再度検討することとした。

(７)システム環境等について他部局（ＩＴ推進課等）との緊密な協力体制を確立すること

庁内ＬＡＮにおけるレスポンス低下などが、以前から発生していたが、システム環境等について、今後も、ＩＴ推進課や関連他部局との緊密な連携によりプロジェクトを推進していくことが肝要であることを求めた。

ＩＴ推進課との連携により速やかな対応策が取り、特にレスポンス低下のような問題は発生しなくなった。 

項目

指摘事項

対応状況

(1) 進捗遅延に対する対応策の明確化と開発進捗管理のための計量的な資料の提示

非常にタイトなスケジュールの中で、仕様の確定作業を短期間で集中して実施し、有効で効率的な対策をとる必要がある。

開発業者から各ベンダーに対して進捗状況の文書による連絡が徹底され、担当者レベルのみならず上層部レベルにまで、状況把握がエスカレーションするようなルールが実行された。

システム開発の進捗の遅れを取り戻すために、その原因を明確化し、次工程以降のスケジュールの見直しおよび体制の強化などの具体的な方針を明らかにする必要がある。

製造工程の管理経験を持った人材を選出して、組織横断的な進捗管理グループを新たに設置し、さらに、それらの選出メンバーを開発現場に配置し、品質管理・進捗管理を行うことになった。

計量的な資料に基づき、システム開発の遅れを取り戻すとともに、発生した問題に対しては、迅速で的確な対応を行うことの重要性を求めた。

プロジェクト管理ツール（MS-Project）の導入により、システム全体および機能（タスク）ごとの進捗度（達成率）の精度が向上した。

(2)平成15 年度成果物の品質確保の徹底と16 年度開発へのエスカレーション

平成15 年度の稼動にあたって、障害が多く発生した。原因としては、要件定義／基本設計の確定に長期間を要し、工期の短縮化を図るため、開発人員は増強したものの、製造工程の期間短縮、テスト期間の短縮などに影響がでてきたものである。16 年度開発は、製造工程の効率化、相互チェック体制の強化、課題管理の徹底等が、必要である。

平成15年度の障害対応と16年度開発の体制を分けることにより、比較的安定的なシステム運用が可能となった。 

(３)システムテスト・運用テストを一層効率的で網羅的に実行すること

平成１６年度開発において、システムテスト・運用テストを一層効率的で網羅的に実行することを求めた。

開発業者から、テストシナリオ全体像、総合試験スケジュール、運用上の対応策（制約事項）の案が提出され、総合試験、検証試験における全体像を網羅的に可視化することが可能になった。

(４)「課題管理」の徹底

現在、残課題に対して課題管理表にて管理されているが、管理項目がシステムごとに不統一であり、担当者が不明確なものや、日付の定義が不明確なものがあった。

書式および管理項目を統一し、具体的に誰がいつまでに課題を解決するかを明確化する必要がある。

 書式および管理項目を統一するとともに、具体的に誰がいつまでに課題を解決するかを明確化するために１項目ごとに単票の「課題管理票」を作成して管理すし、課題管理については、障害連絡票で管理され、共有化された。

(５)品質管理の徹底と開発現場への浸透

品質管理グループが各開発システム単位に設置されたが、開発業務が逼迫していることから、納期を優先していることも否めず、連絡・報告の徹底、さらなるレビュー体制の充実、貴庁を交えた品質面での検証と確認などを求めた。

検証ルールを明確にし、その徹底を求めた。

(６)障害／不具合の解決後のリリース

検証試験で発生した障害や不具合の結果、リリース時期の延期や本稼働において運用上の制限事項を設けることになった。このことは、利用者（発注者側・受注者側）に負担と労力を掛けることにもつながることを指摘した。

平成16年度中の解決はできなかったため、17年度において、制限事項の解消を行うこととした。

(７)統括会議検討結果の開発要員への伝達の徹底

「連絡票」では、統括グループにより「障害」と「要望」の切り分けを実施し、「障害」と判定されたものを優先して改修している。切り分け会議の検討結果は、各関連システムの開発要員（上位管理層のみならず担当者レベルまで）に確実に浸透させ、徹底させておく必要がある。

障害の切り分けルールを明確にし、その徹底を求めた。

(８)システム運用について、監査証跡を記録として残すためにルール化すること

作業ミスの防止を目的に、作業計画、作業手順、作業内容、作業結果などをサーバ上で作業内容を確認できるしくみ（作業届）を確立し、プロジェクト内で回付するルールを徹底されたが、書式、回付ルールに改良を求めた。

 プロジェクト管理会議において、「障害管理（障害対応・要望管理）の基本方針（手順）」が提示され、詳細な「連絡体制図（案）」が提示された。

(9)平成１６年度開発において、ピーク時のシステム性能、レスポンスの検証を行うこと 

ピーク時のシステム性能、レスポンスの検証を行うことを求めた。

平成16年11月の「一斉受付」稼動に向け、ピーク日の処理件数2,500件／日と想定し、システム性能およびレスポンスの検証を実施し、性能低下が発生せず、安定して稼動することを確認した。