沖縄県情報システムガイドライン ·...

沖縄県情報システムガイドライン

本編

平成 30 年 6 月

沖縄県

目次

Ⅰ ガイドラインの位置づけ ............................................................................. 1

１目的と位置づけ ................................................................................................... 1

２対象範囲 ............................................................................................................ 5

３情報システム基本方針及びガイドラインの構成 .......................................................... 8

４ガイドラインの見直し ............................................................................................. 9

Ⅱ 情報システム基本方針の考え方 ................................................................ 10

１業務・システムの基本方針 .................................................................................... 10

２外部発注の基本方針 ........................................................................................... 11

３推進体制の基本方針 ........................................................................................... 13

Ⅲ 情報システムマネジメントのプロセスと実施事項 ........................................... 14

１．企画・計画プロセス .............................................................................................. 16

1.1 計画概要協議書の作成 .................................................................................. 18

1.2 計画概要協議書の協議 .................................................................................. 20

1.3 （新規事業調査～）予算要求 ........................................................................... 22

２．調達プロセス ...................................................................................................... 24

2.1 調達準備 ..................................................................................................... 26

2.2 調達詳細協議書の作成 .................................................................................. 28

2.3 調達詳細協議書の協議 .................................................................................. 30

2.3 予算執行伺い ............................................................................................... 32

2.4 事業者の選定 ............................................................................................... 33

2.5 契約交渉・締結 ............................................................................................. 35

３．開発プロセス ...................................................................................................... 36

3.1 プロジェクトの立ち上げ ................................................................................... 38

3.2 プロジェクトの実施管理 ................................................................................... 40

3.2.1 詳細要件整理 ............................................................................................ 40

3.2.2 設計・製造・テスト ......................................................................................... 42

3.2.3 移行 ......................................................................................................... 44

3.3 検収・検査 .................................................................................................... 46

3.3.1 検収 ......................................................................................................... 46

3.3.2 検査 .......................................................................................................... 48

3.4 プロジェクトの終結 ......................................................................................... 50

3.5 情報システム台帳への登録・更新 ...................................................................... 52

４．運用・保守プロセス .............................................................................................. 53

4.1 運用・保守準備 ............................................................................................. 55

4.2 調達 ............................................................................................................ 57

4.3 運用・保守計画及び手順の策定 ....................................................................... 58

4.4. 運用・保守の実施 ......................................................................................... 60

4.4.1 運用・保守の実施管理 ................................................................................. 60

4.4.2 サービス品質評価 ....................................................................................... 62

５．評価・廃止プロセス .............................................................................................. 64

5.1 システム運用中評価 ....................................................................................... 66

5.2 システム更改前評価 ....................................................................................... 68

5.3 システム廃止 ................................................................................................. 70

別表 ........................................................................................................... 72

Ⅰ ガイドラインの位置づけ

1


１目的と位置づけ

1.1 目的と目標

情報システムは、今やどのような業務を行うにも欠かせない存在となっており、本県においても、

数多くの情報システムが導入され、一定の成果をあげてきている。しかし、一方で、業務主管課主

導で個々に導入・運用を重ねてきた結果、以下のような問題が生じている。

システム機能の不足や重複が見られたり、システム間連携が不十分または非効率である

情報システム間やネットワーク内における動作環境の技術的不整合が発生している

内容が明確でない調達契約や安易な随意契約が見受けられる

これらの直接的な要因としては、全庁経営戦略的な視点や将来の技術動向を見据えた検討の

不足、また、情報システムの必要性や内容あるいは仕様検討の不足があげられるが、その根底に

は、情報システムについての全庁的・組織的なマネジメントの欠落という統制・管理上の問題があ

る。このことは、平成 21年 9月に実施した全庁アンケート調査によって、各所属における情報シス

テムの導入や運用における管理レベルが一部を除き低いものにとどまっていること、参照する手

順書等のドキュメントが不足していることとして明らかになっている。

このような背景を踏まえて、情報システムに関するマネジメントの仕組みを確立するため、情報シ

ステムの企画・計画から評価・廃止に至るまでのライフサイクルプロセスに沿って、組織としてマネ

ジメントすべき基本的事項及び基準を定めた「沖縄県情報システムガイドライン」（以下、「本ガイド

ライン」という）を策定する。

本ガイドラインの目的、目標は、以下のとおりである。

●本ガイドラインの目的と目標

目的目標

情報システムの調達の適正化

情報システムの（技術的）整合性確保

情報システムの有効性確保

所管課の情報システム関連事務の軽減

情報システム関連コストの適正化

全庁の情報システムの調達方法の統一を図り、不適切な契約方法や仕様の不備等を無くすこと

定められた全庁的な技術指針に不適合な情報システムの導入をなくすこと

情報システムの有効性と全庁における適切性を確保するための管理方法を定め、改善を図る仕組みを確立すること

情報システムの適切な導入・管理を図るための手法を全庁で共有するとともに、管理のための負担を軽減すること

全庁のIT関連コストを把握し戦略的投資を可能にするとともに、有効な削減手法を共有しコストの適正化を図ること


2

1.2 位置づけ

本ガイドラインは、おきなわ ICT 総合戦略のうち、行政分野の基本方向「ICT による行政サービ

スの向上と業務効率化」における施策展開のうえでその中核をなすものであると同時に、その他

の情報化計画等における情報システム調達を含め、「沖縄県情報システム基本方針」に基づいて、

本県の情報システムのマネジメントを行うため、企画・計画から評価・廃止に至るまでのライフサイ

クルプロセスに沿って実施すべき基本的事項及び基準を定めるものである。

後述する範囲の組織では、情報システムの各ライフサイクルプロセスにおいて、本ガイドラインに

定める内容を遵守しなければならない。このため、本ガイドラインは、これまで一般にわかりにくい

とされてきた情報システムに関する業務を整理し、ガイドライン運用のための手引きや、作成すべ

き書類のサンプル等を含め、システムを所管する組織で活用可能なものとして整備する。

なお、本ガイドラインは、情報セキュリティに関しては、沖縄県情報セキュリティ基本方針及び同

対策基準に準拠するとともに、沖縄県の行政事務用情報ネットワークである CORAL21 ネットワー

ク、総合情報政策課が調達・配付する一括導入パソコンについては、多くの情報システムとの関

連が深いことから、本ガイドラインでは、一部にこれらに関する内容を含み記載している。

●沖縄県の情報化関連文書の体系

※ その他同等な計画や基準等がある場合は、それに置き換え、導入・運用に適用する。


3

1.3 用語等

本ガイドラインで用いる用語については、「２．対象範囲」に記載する組織、対象システム等の例

によるもののほか、CORAL21 ネットワーク及び一括導入パソコンについては、以下の規定で定め

るところによる。

○CORAL21ネットワーク運用管理要綱

○一括導入パソコン等及び運用管理要綱

1.4 強靭化対策後の情報システム開発、運用への注意喚起

平成27年5月に発生した日本年金機構の情報漏洩問題を受け、総務省より新たな自治体情報

セキュリティ対策の抜本的強化が要請されたため、庁内においては国が示す「自治体情報システ

ム強靭性向上モデル」にそって、平成28年において順次、庁内ネットワーク強靱化対策が行われ

た。

従来のＣＯＲＡＬ21ネットワークは、番号利用事務系、LGWAN系、インターネット接続系に分割

される（次頁参照）。番号利用事務系、LGWAN 系はインターネット接続系との通信はできなくな

る。インターネットの閲覧は仮想環境を利用したものとなり、外部とのメールやファイルのやり取りを

行う際には無害化処理を行った上で LGWAN系に取り込む必要がある。

また、インターネット接続系に置かれるシステムは一部のWebサーバやメール等に限られ、個人

番号を利用するシステムは番号利用事務系に、その他ほとんどのシステムは LGWAN 系に置か

れることとなる。

基本的にインターネットに接続できる環境において行政事務を行うことができなくなることから、

今後システムの新規導入や更改、運用にあたっては前述の強靭化対策による庁内環境の変化を

十分把握し、利用及び運用が可能なシステムとなるよう十分に留意すること。


4

●強靱化対策前のネットワーク構成イメージ図(２０１７．１．１９時点)

●強靱化対策後のネットワーク構成イメージ図(２０１７．１．１９時点)


5

２対象範囲

2.1 対象組織と役割

(1) 対象組織

本ガイドラインの対象組織は、以下のとおりである。

●本ガイドラインの対象組織

(2) 役割

各組織の体制と役割は以下のとおりである。

●各組織の体制と役割

組織責任体制役割

沖縄県高度情報化推進本部

最高情報統括責任者

（企画部長）

情報統括責任者

（企画部総合情報政策課長）

ガイドラインを統括管理し、

適正な運用を確保する。

情報管理主管課

(企画部総合情報政策課※1、警察本部警

務部情報管理課、教育庁教育支援課)

情報管理主管責任者

（左記組織の長）

業務主管課のシステム導入

等にあたり、審査、支援を実

施する。

業務主管課

(該当システムを所管する課室、

出先機関等)

情報管理者


システムの導入、運用を実

施する。

財政主管課

(総務部財政課)

財政主管責任者


業務主管課のシステム導入

等に要する費用を審査する。 ※1 知事部のほか、出納事務局、県議会事務局、労働委員会、人事委員会、監査委員においては、情報管理主管課として企

画部総合情報政策課が審査、支援を実施する。

2.2 対象情報システム及びマネジメント区分

(1) 対象情報システム

本ガイドラインの対象は、コンピュータ（ハードウェア及びソフトウェア）やネットワークを利用する

もので、本県がその内容や仕様を示して調達、保有する、あるいは職員が自己開発する情報シス

テムとする。

対象組織対象外組織

知事公室

総務部

環境部

子ども生活福祉部

農林水産部

商工労働部

文化観光スポーツ部

出納事務局

企業局

病院事業局

労働委員会

人事委員会

監査委員

公安委員会

教育委員会

各種委員会知事

県議会事務局

保健医療部

企画部

土木建築部


6

このため、以下については、対象とならない。

○事業者が業務遂行のために、自らの資産として調達、使用するもの（業務のアウトソーシング1）

○国や他団体が調達主体であり、県はその利用者となるもの

○実施方針や仕様を示す主体が県でないもの

また、以下については、システムや調達の性質上、対象から除外する

○研究用分析装置（これに連動する計算ソフト等を含む）

○設備の制御用コンピュータシステム（ダムや浄水場の制御システム等）

○パソコン等のハード単体、ソフトウェア製品単体、ホームページコンテンツ用素材

○汎用的なネットワークインフラ整備としてのサーバ機等を含まない LAN 構築、拠点間のネットワ

ーク接続、通信サービス契約

○電話（音声通話）のみに利用するネットワークまたはネットワークシステム

○実証実験等により、政策的判断を伴い、企画・計画から構築までを一貫して行う事業において、

業務の調達段階で導入システムの規模や仕様等における定めを設定せず、費用内でこれらに

ついて一定の流動性を許容することが可能なもの

○治安維持等のために高度な秘匿性が必要なシステム

ただし、これら本ガイドラインの対象外となるものについても、情報セキュリティ基本方針及び同

対策基準に留意し、組織または接続するネットワークによっては、当該管理上の各種確認手続き

を要するほか、本ガイドラインの趣旨を踏まえたマネジメントが求められる。

●本ガイドラインの対象となるものの分類と例

分類形態対象例

新規導入・更改

○新規導入：情報シス

テムを新規に導入す

る場合

○更改：情報システムを

全面的に見直す場

合。サーバ等の主要

なハードウェアの更

新、及びソフトウェア

の大幅な変更の場

合。

一括

調達

自己導入情報システムの新規構築、再構築、更改

サービスの調達（ASP2／XaaS3）共同運営システムの構築、既存 ASP の利用

分離

調達

開発システムの設計や開発部分を分離調達

ハードウェアシステムのハード部分を分離調達

運用・保守システムの運用・保守部分を分離調達

コンテンツ制作（外部委託するも

ので 100 万円を超えるもの）ホームページのコンテンツ制作

ネットワークサーバ機等によりコントロールまたはサービス

を提供する機能を含むネットワーク

変更・追加

○変更：主要なハードウェア・ソ

フトウェアはそのまま継続利

用し、情報システムの一部を

変更する場合

○追加：ハードウェア・ソフトウェ

ア等の一部を追加する場合

ハードウェア、ネットワークの変

更・追加

端末、サーバ機器、ネットワーク機器、回線の

追加や構成変更

ソフトウェア改修、機能追加制度改正に伴う改修、新機能の追加

コンテンツ変更・追加 Web コンテンツの更新

サービス調達の変更・追加調達サービスの拡張

運用・保守の変更・追加運用・保守水準の変更

データセンター／移設・移転データセンターの利用とそれに伴う移設

1 アウトソーシング：庁内行っていた業務を、専門企業に外部委託すること。情報システムに関わる業務を外部委託することに限

らず、窓口業務等、業務自体の外注も含めて外部委託することも含まれる。 2ASP (Application Service Provider)：業務用のアプリケーションについて、ネットワーク（インターネット等）を利用して、顧客に提

供する事業者あるいはサービスを指す。 3XaaS（X as a Service）：情報システムの開発や運用に必要な資源(ソフトウェア、ハードウェア、開発環境等)を、ネットワークを通

じて利用するサービス。特にソフトウェアを提供する SaaS(Software as a Service)の利用が広まっている。このほか PaaS(Platform)、

IaaS(Infrastructure)等がある


7

(2) マネジメント区分

本ガイドラインでは、対象システムを、その規模、影響度等に応じ「別表マネジメント区分」のと

おり、大・中・小に区分してマネジメントを実施する。

●マネジメント区分の考え方

2.3 対象プロセス

本ガイドラインでは、情報システムのマネジメントに係る以下の５つのプロセスを対象とする。

調達

企画・計画

開発

運用・保守

情報システムの目的、内容、方法等を明確化し、計画を立案するとともに、導入

の実施判断を行う。

企画・計画した情報システムの開発、運用・保守あるいは機器の納入等を行う

事業者を選定し、契約を締結する。

情報システムの設計、開発（製造）、テスト等を実施し、稼働が可能な状態にす

る。

情報システムを稼働させ業務を円滑に遂行するとともに、そのための予防保

全、障害解析、復旧、移行を実施する。

評価・廃止企画・計画時の目的・目標が実現できているかどうかを検証し、改善を実施す

る。また、評価結果等に基づき情報システムの廃止を行う。

大

中

小

大

小

規模・影響度


8

３情報システム基本方針及びガイドラインの構成

「沖縄県情報システム基本方針」及び「沖縄県情報システムガイドライン」の構成は、以下のとお

りである。

●基本方針及びガイドラインの体系

沖縄県情報システムガイドライン

プロセスに沿って実施すべき事項

プロセスに沿って実施すべき事項についてのより具体的な解説

プロセスに沿って作成すべき主要ドキュメントの様式、サンプル

ガイドライン本編

沖縄県情報システム基本方針情報システムの企画から廃棄にいたるマネジメントの方針

運用の手引き

様式・サンプル集

技術指針

情報システムについての準拠もしくは考慮すべき技術の方針

情報システム台帳

本ガイドラインの対象となる情報システムに

関する情報が登録されている台帳。

ガイドライン協議を行う際の基礎資料。

台帳に記載する項目は情報管理主管責任

者が別に定める。


9

４ガイドラインの見直し

本ガイドラインに基づき実施した情報システムマネジメントの PDCA サイクルによって得られた成

果や、情報システムに係る新技術等の環境変化を、随時ガイドラインに反映することとする。

これにより、情報システムマネジメントの継続的改善を図っていくものとする。

Ⅱ 情報システムの基本方針

10

Ⅱ 情報システム基本方針の考え方

情報システムの開発や更改等に際しては、全庁的・長期的経営目標から導かれる情報システム

の目的・目標を、資源と危険性を最小にとどめ達成できるよう、全体最適の視点で取り組むことと

し、「沖縄県情報システム基本方針」に基づき、本ガイドラインに従ってそのマネジメントを実施す

る。

以下に、基本方針の第２章以下の事項について、ガイドラインの策定・運用における考え方を記

載する。

１業務・システムの基本方針

業務・システムの基本方針として掲げられる事項と、ガイドライン策定・運用にあたっての考え方

は次のとおり。

1.1 業務の標準化・効率化

情報システムの導入にあたっては、現行業務の把握とともに問題点を分析し、その目的を明確

にしなければならない。また、業務範囲、役割分担、手順等の見直しを行い、業務の標準化、効

率化を進め、行政運営の効率化と費用の削減を図らなければならない。

【考え方】

システムの導入を検討する過程では、システム化を図ること自体が目的化してしまう事態に陥ること

がある。まず、現状分析と課題抽出を行い、目的を明確にした上で、その目的達成に貢献する観点

からシステムの企画・計画を立案することが肝要である。

情報システムの導入を行う際、現状の業務処理方法を変えずにそのままシステム化した場合、シス

テム化のメリットが十分に得られないことも多い。導入の際には、業務フローの見直し、不要帳票の削

減、業務の集中化や分散化等の方法により、標準化・効率化を図ることが重要である。また、システム

の更新においては、より効率的な方法を導入する等の検討が可能である。

なお、検討の過程において業務そのものを外部委託することも考えられる。

1.2 全庁的・長期的視点

情報システム導入にあたっては、データ体系の標準化、システムや運用の統合、共通する業務

基盤の整備や活用、システム間の連携確保等、全庁的かつ長期的な視点でシステムのあり方を

検討し、効率性、有効性の高いシステムを実現しなければならない。

【考え方】

システム導入時には、個々のシステムやその時点での要求事項からの観点だけで検討しがちであ

る。その結果、同様な機能を持ったシステムが庁内に乱立したり、互いの情報資産を有効に生かせな

い、あるいは、稼働直後に大規模な改修が必要になる、といった結果をもたらす。

このため、全庁横断的な視点を持った導入が必要であり、具体的には、システム統合、データ連携、

共通データベース等の手法を検討することが求められる。


11

1.3 採用技術の標準化

情報システムで採用する技術は、調達における競争性の確保と、拡張性、柔軟性、外部提供サ

ービスにあたっては県民の利便性を確保するために、極力標準的な技術、公開された技術を採

用するとともに、別に示される技術指針との整合性を確保しなければならない。

【考え方】

特定事業者固有の技術に基づくシステムを導入すると、特定事業者と随意契約をせざるを得なくな

り費用が高止まる、あるいは他のシステムとの連携が難しくなる等の問題が生じる。また、県の技術方

針に反した技術に基づくシステムを導入すると、他のシステムに悪影響を及ぼす可能性がある。

このため、システムの構成要素には、国際・国内規格または事実上の標準とされる技術の採用や、

ソースコード4が公開されているオープンソースソフトウェア5の活用を推奨する。

また、庁内環境の標準化を進めるため、システム形態、OS、ブラウザ等の指針を定めた県の情報シ

ステム技術指針への適合を求める。

1.4 情報セキュリティの確保

情報システムのライフサイクルにおけるすべての工程において、沖縄県情報セキュリティ基本方

針及び対策基準をはじめ、その他組織に適用されるセキュリティポリシー等に従って、情報セキュ

リティ水準の確保、向上に取り組まなければならない。

【考え方】

情報セキュリティ対策は、システムの企画、調達や、開発における設計段階から考慮しないと、十分

な対策を実施することが困難であり、また運用や廃棄といったその他情報システムのライフサイクルプ

ロセスにおいても情報セキュリティ対策を考慮する必要がある。

このため、アクセス権限の設定、冗長化、データパックアップ対策、入力値チェック、セキュリティパッ

チ6の適用やウィルス対策ソフトの運用、ログの取得、廃棄時のデータ消去等の情報セキュリティ対策

の実施が求められる。

２外部発注の基本方針

外部発注の基本方針として掲げられる事項と、ガイドライン策定・運用にあたっての考え方は次

のとおり。

2.1 調達単位と調達先選定方法の適切な設定

情報システムの外部発注にあたっては、品質の確保と同時に競争性を確保するため、工程や対

象の分離等合理的な調達単位を設定するとともに、その規模や内容に応じて適切な調達先選定

方法を採用しなければならない。

4 ソースコード：人が理解しやすいようプログラミング言語を用いて記述したソフトウェアの文。コンピュータ上でプログラムを実行

するにはこのソースコードをコンピュータが実行できるファイルに変換する必要がある。 5 オープンソースソフトウェア：ソフトウェアのソースコードを、著作者の権利は守りながら、インターネットなどを通じて無償で公開

し、誰でもそのソフトウェアの改良、再配布が行なえることが可能なソフトウェア。国もその開発や配布を推進している。 6 セキュリティパッチ：ソフトウェアにセキュリティ上の弱点(セキュリティホール)が発覚した時に配布される修正プログラム。


12

【考え方】

情報システムは、調達方法の適用が不適切であると、調達価格を下げることができても、十分な品

質が得られないおそれがあるほか、十分な競争効果が得られず高止まりする可能性もある。調達にあ

たっては、対象とする単位や事業者の選定方法を適切に設定することが重要である。

このため、適切な事業者選定手法（一般競争入札、総合評価一般競争入札、プロポーザル等）の

適用、分割発注や長期継続契約等の手法の採用について考慮する必要がある。また、県として地元

業者の参入機会の創出の視点も必要になる。

なお、調達の際には、他自治体の優良な事例を参考としたり、システムを保有しないサービス調達の

形態や、パッケージ製品の適用についても検討しなければならない。このほか、大規模なシステムや

複雑なシステムの調達においては、コンサルタントを活用することも効果的な手法と考えられる。

2.2 仕様の明確化

調達する情報システムや運用・保守の仕様についてはあいまいな表現を排除し、発注先に対し、

要求事項を漏れなく適切に示すことができるよう定義しなければならない。

【考え方】

情報システムや運用・保守の仕様は、県が求めるシステムの要件、内容を示すものであり、仕様が

漏れなく適切に示されていなければ、期待するシステムの導入や運用は不可能である。また、一方的

な発注者優位の内容であった場合には、事業者の疲弊や契約不成立を招き、最終的に県が求める

成果を得られない恐れもある。

仕様の明確化と受発注者の責任分担の明確化を図ることにより、事業者側のリスク負担分が上乗せ

されることや、仕様変更が発生することによるコスト増、トラブルを防がなければならない。

2.3 ライフサイクルコストの管理

情報システムの設計、開発から廃止に至るまですべての工程を対象とした費用の管理を行うこと

により、長期的な視点で費用の削減を図るとともに、次の更新を踏まえた知的財産権の扱いや格

納データの方法を考慮しなければならない。

【考え方】

情報システムのコストは、長期的には、開発導入費用よりも運用費用の方が大きくなることがある。コ

スト管理にあたっては、システムの設計、開発から廃棄に至る費用を含んだコスト全体を捉えることが

重要である。また、権利関係の問題で更新時期に他の事業者へ変更しづらくなることも避けなければ

ならない。

このため、著作権の保有・共有による県の権利確保や、運用費用を含めた評価を実施調達するこ

と、データの移行や廃棄コストを含んだ管理が求められる。

2.4 品質の管理

情報システムや運用・保守の調達にあたっては、費用面だけでなく、品質についても総合的に

評価するとともに、開発にあたってのプロジェクト管理の徹底、運用にあたってのサービス水準の

管理といったシステムやサービスの品質の確保と継続的な向上を図る仕組みを導入し、情報シス

テム及びサービスにおける有効性、信頼性、効率性、保守性の確保に努めなければならない。


13

【考え方】

情報システムは、決められた物品を調達するものと性質が異なり、受発注者のスキル・ノウハウや管

理の方法によって、その品質は大きく異なってくる。調達時から運用管理に至るまで、品質を十分に

管理することが必要である。これらの管理は、受注者側のみに頼るものではなく、発注者側の責任に

おいて管理を実施する必要がある。

このため、発注者側においても、開発におけるプロジェクト管理を確実に行い、事業者に品質マネ

ジメントの実施を求め、設計書、手順書、作業報告書等の提出を徹底させるとともに、提供サービス水

準をあらかじめ合意し、品質を保証する SLA7の導入を推奨する。

また、運用においては、安定稼動に伴い、リスクの過大評価や不要な機能・サービスの停止を含

め、委託等における適正化を図る必要がある。

３推進体制の基本方針

推進体制の基本方針として掲げられる事項と、ガイドライン策定・運用にあたっての考え方は次

のとおり。

3.1 マネジメント体制の確立

情報システムの導入や運用を確実に実施するため、各工程における責任と役割分担を明確に

し、十分なマネジメント体制を確立しなければならない。

【考え方】

情報システムには、さまざまな利害関係を持った組織や個人が関与し、節目における意思決定と調

整が必要になることから、導入、運用を円滑に進めていくためには、責任と役割が明確な体制が重要

となる。また、情報システムは専門性の高い内容を多く含むことから、発注者側にも業務を適切に実

施できる十分な体制が求められる。

このため、情報システムをマネジメントするための体制を構築する必要がある。

3.2 職員の育成・スキルの継承

有効性、信頼性、効率性、保守性の確保された情報システムの導入を進め、継続した安定運用

を行っていくために、職員の育成とスキルの継承を推進しなければならない。

【考え方】

県においては、人員の定期的な異動が行われるが、情報システムのマネジメントを行っていくため

には、一定の専門知識とスキルが必要であり、職員の知識やスキルの維持、向上に意識的に取り組

んでいく必要がある。

このことは、情報システムのブラックボックス化を防ぎ、いわゆる事業者への丸投げの回避に直接つ

ながるものである。

7 SLA（Service Level Agreement）：サービス提供者と利用者との間で、提供するサービスの内容や品質に対する要求（達成）水

準をあらかじめ合意しておく契約。水準として定める例としては、システムの稼働率や回線速度、保守対応時間等が挙げられ

る。

Ⅲ 情報システムマネジメントのプロセスと実施事項 1．企画・計画プロセス

14

Ⅲ 情報システムマネジメントのプロセスと実施事項

情報システムマネジメント上の各プロセスにおいて、業務主管課での検討や作業の主たる内容

を、情報管理主管課が確認できるよう、図表に示す４つの協議、提出等の手続き事項を定める。

このほか、システムがネットワークに接続される場合、各ネットワークの管理上、接続のための手

続きに留意する必要がある。

●庁内において協議や提出、届出が必要な事項

※1 本ガイドラインの対象となるすべての情報システムで必須とする。ただし、変更・追加の場合で、マネ

ジメント区分が「中」に該当しないものは、協議を要しない。

※2 ネットワークに接続する場合に実施し、マネジメント区分とは関係しない。

※3 本ガイドラインの対象となるすべての情報システムで届出を必須とする。

２調達

１企画・計画

３開発

４運用・保守

計画概要協議書の協議

調達詳細協議書の協議

マネジメント区分に応じて実施

必須

目的、費用対効果等における実施の必要性

や、企画・計画の内容は妥当か

仕様内容は適切か、調達方法は適切か

大・中

すべて※1

５評価・廃止

プロジェクト計画書・評価書の提出

スケジュールや開発管理方法、体制は明確

か、共有すべき教訓はないか

接続ネットワーク管理上の手続き

ネットワークに接続して問題はないか

（CORAL21 ネットワーク等との接続要件）

大

－ ※2

必要に応じて実施

対象区分協議、提出等の種類

システム廃止協議書

システムを廃止する場合の届出

すべて※3

システム更改前評価書の提出大

企画・計画と比較しての評価

計画概要協議書の添付書類として提出


15

なお、組織またはシステムが接続されるネットワークにおいて、システムの導入や接続に関する

管理手続きが定められており、本ガイドライン上の手続と、趣旨、時期、手続き主体及び手続きの

相手方を同じくする場合、双方の合意のもとで、ネットワーク管理等の手続きに本ガイドラインの協

議等内容を含め、事務手続きを集約、簡素化してもよい。（例：CORAL21 ネットワーク運用管理要

綱及び同要領上の協議等手続き）

●実施フローにおける凡例

※ なお、本ガイドラインでは、業務主管課単独導入による実施フローとして記載するが、関連する他部署との共

同プロジェクトとして実施する場合、その意思決定の実施フロー等について関連部署と調整する必要がある。

項目

関係者と役割

　ライフサイクルプロセスの開始や終了

　前プロセスからの引継ぎ、次プロセスへの引継ぎ

　作業

　条件に応じて実施する作業

　各作業に関連するドキュメント

　各作業における判断

フロー記号

説明

　　プロセス及びサブプロセスの実行において、関係する部署や委員会、事業者等とその役割を示す。

プロセス　　ガイドラインでは、情報システムのライフサイクルプロセスを５つの段階に区分する。

　　この段階区分を「プロセス」という。（「1 企画・計画」「2 調達」「3 開発」「4 運用・保守」「5 評価・廃棄」）

サブプロセス　　各プロセスにおいて実際に作業を行い、結果を出す行いを「サブプロセス」という。

　（例　「1.1 システム計画協議書の作成」「1.2 システム計画協議書の協議」など）


16

１．企画・計画プロセス

企画・計画プロセスは、情報システムの導入を行う場合のファーストステップである。

ここでは、計画概要協議書の作成と協議、新規事業調査を含む予算要求といったサブプロセス

を実施する。

まず、情報システムの目的・目標、対象範囲、内容、実現方法、費用、効果、実施時期等を検討

する。その検討結果を「計画概要協議書」としてとりまとめ、この協議書を基に、実施の可否、実現

内容・方法等の妥当性の判断を行い、妥当性が認められれば予算が措置される。

なお、予算の流用等当年度内の予算執行となる場合も同様の扱いとなる。また、予算に係る財

政主管課との協議を必要としない場合においても、調達プロセス開始以前に情報管理主管課へ

の協議(実施フロー図 1.2)することが必須である。

企画・計画プロセスは、情報システムに関するプロセスの中で、方針や費用概算を決定するステ

ップであり、重要性が高い。企画・計画プロセスの検討が不適切であると、以下のような根本的な

問題や、県にとって大きなリスク負担が発生する。

○目的・目標が明確でなく、最終的に導入の効果が得られない

○効果のないシステムを導入することとなり、費用の無駄が発生する

○実現方法が不適切で、後に方針変更のコストや遅延、過剰な運用負担が発生する

○必要資源（予算や人員、期間等）の見積りが不適切で、投資額の超過、品質の低下、稼働の

遅延等が生じる

また、調達方針として職員による自己開発や運用を想定する場合は、開発が自己収斂すること

や職員の異動により、新たなリスクが発生することを念頭に置く必要がある。

○職員のスキルに左右されることから、セキュリティ対策がおろそかになったり、標準的でない

設計、コーディングにより後々のメンテナンスが行いづらくなる

○ドキュメント作成や管理がおろそかにされ、システムがブラックボックス化する

○運用・保守そのものが行われなくなるか、または著しくその質が低下する

これらのことから、企画・計画プロセスでは、入念な検討が必要である。

なお、本プロセスの処理概要を以下に記載するが、検討すべき項目やその具体的な考え方、協

議書の作成手順等については「運用の手引き」の企画・計画プロセス部分を参照すること。


17

■本プロセスにおける実施フロー

8

8 RFI（Request For Information）：情報システムの導入や業務委託を行なうにあたり、案件に対する解決策を持つ業者に情報提

供を依頼し、経費その他の調達条件を決定するために必要な情報を集めること。

会議体等情報管理主管課業務主管課財政主管課事業者等

1.2計画概要協議書の協議

1.3（新規事業

調～）予算要求

サブプロセス

関係者と役割（実施フロー）様式・成果物

1.1計画概要協議書の作成

協議

（目的、方法、内容判断）

協議

（可否判断）

査定・予算化

可

システム計画立案の合

意

情報提供（概算見積）

再検討指示

計画中止

（必要により調整）

システム計画の

策定

予算の申請

（協議委員会等を設置する場合）

事業計画の作成

2 調達

システム化要件の整理

計画概要

協議書

RFI 8

依頼書

RFI

回答書

不可

不可

RFI

依頼書

RFI

回答書

計画概要

協議書

計画概要協

議結果書

新規事業

調査表

歳出予算

概算見積書

新規事業

調査表

歳出予算

概算見積書

計画概要協

議結果書

予算内示予算内示

新規事業

協議結果

協議結果

協議結果

協議（目的、方法、内容判断）

開始

新規事業

協議結果

技術指針適

合ﾁｪｯｸｼｰﾄ

技術指針適

合ﾁｪｯｸｼｰﾄ

予算内示受理・報告

予算内示確認


18

1.1 計画概要協議書の作成実施時期予算要求１月前まで※1 協議・提出の対象区分★ すべて

目的と概要：

計画している情報システムの目的、内容、方法等を明らかにした、計画概要協議書を作成す

る。計画概要協議書はシステム計画実施の可否判断を行うための根拠となる。

(1) 実施時期・実施対象

情報システムを新規導入・更改あるいは変更・追加を行う場合については、規模を問わず、すべ

て計画概要協議書の作成を実施する必要がある。

計画概要協議書は、予算化に向けた協議に先立ち作成する必要があることから、予算要求の１

ケ月前までには作成する必要がある。計画概要協議書は内容の検討に一定期間が必要であるこ

とから、早期に着手することが望ましい。

※1 当年度中の調達の場合は、システム計画協議に先立ち、実施する必要がある。

なお、予算要求を伴わない職員による自己開発等の場合は、随時実施する。

(2) 実施主体

○業務主管課責任者：当該組織の長(情報管理者)

実施者：当該組織の担当者

○その他支援者：情報管理主管課

(3) サブプロセスに関係する資料（インプット・アウトプット）

インプット主要作業・方法アウトプット

◇システム更改前評価報告書

（更改の場合）

○上位計画、システム化方針

○現状の業務・システムの資料

○現状・動向調査

○目的、内容、方法等の検討

○情報提供依頼書の作成

と回答書の取得

○計画概要協議書の作成

◆計画概要協議書 ※2

◆改修概要

(更改、変更、追加の場合)

◆RFI 依頼書 ※3

◆RFI 回答書（見積等）

◆技術指針適合チェックシート

参照基準・参照手順等作成資料の様式・サンプル等

○運用の手引き（システム計画の策定、計画概要協

議書の作成）

○技術指針

○様式 G0-1 協議書等提出鑑

○様式 G1-1 計画概要協議書（新規導入・更改）

○様式 G1-2 計画概要協議書（変更・追加）

○様式 G1-2-1 計画概要協議書(変更・追加) ※4

○資料 G1-4 技術指針適合チェックシート

○様式 G0-a 改修概要サンプル

○資料 G1-a 計画概要協議書（新規導入・更改）サンプル

○資料 G1-b 計画概要協議書（変更・追加）サンプル

○様式 G1-b-1 計画概要協議書(変更・追加)サンプル

○資料 G1-ｃ RFI サンプル

○資料 G1-d 費用対効果整理シート

インプット・アウトプット欄： ◆；必須 ◇；マネジメント区分により必須 ○；任意

※2 計画概要協議書は、新規導入・更改と変更・追加で様式が異なる。

★ 情報管理主管課に対する協議や提出、届出を要するマネジメント区分


19

※3 職員による自己開発の場合等で外部発注がない場合は不要。

※4 G-2-1 計画概要協議書(変更・追加)は、「変更・追加」の目的が以下の場合に限り使用できる。

(4) 実施事項

① 業務主管課において、当該情報システムを計画することについて合意する。

② 業務主管課の実施者は、現状や動向の調査を行う。

③ 業務主管課の実施者は、計画概要協議書の記載項目を網羅するシステムの要件、内容等を

検討する。

④ 業務主管課の実施者は、事業者に対して情報提供依頼（RFI：Request For Information）を行

う等の方法で費用の積算を行う。RFI を実施しない場合でも、外部発注を伴うシステムの場合

は、見積りの取得は必須である。

⑤ 業務主管課の実施者は、現状や動向調査、RFI回答書を基に計画概要協議書を作成する。

⑥ 業務主管課の実施者は、計画概要協議書について、責任者の承認を得て、次のサブプロセ

スに進む。

(5) 留意点

① 計画概要協議書の作成にあたっては、課題や効果・目標、システム要件、費用、スケジュー

ル等について検討する必要がある。「運用の手引き」及び様式・サンプル集「計画概要協議

書」を参照し、作成すること。

② 計画概要協議書は、情報システムを新規導入・更改する場合と、変更・追加する場合で様式

が異なるので注意すること。

③ 大きな事業の一部として情報システムを構築するような場合も、必ず計画概要協議書を作成

すること。

④ 計画概要協議書の作成中、不明点がある場合は、情報管理主管課に相談すること。

○法改正または制度改正に対応するものである場合

○他の連携するシステムの改修に応じて対応するものである場合

○メーカーサポートが終了した主要なソフトウェアの更新等、セキュリティ上必要な対応である場合


20

1.2 計画概要協議書の協議実施時期予算要求前１ヶ月間※1 協議・提出の対象区分すべて

目的と概要：

作成した計画概要協議書の目的、内容、方法について情報管理主管部門と協議を行い、その

妥当性について審査を受ける。協議結果に基づき、必要に応じて計画内容の見直しを行う。


情報システムを新規構築・更改あるいは変更・追加する場合は、すべてのマネジメント区分にお

いて、計画概要協議書の協議を実施する必要がある。

協議は予算要求に先だって行うものであり、予算要求には協議の結果が必要となることから、予

算要求の前の１ヶ月間を目処に実施する(例：予算の新規要求が 9 月中旬開始であれば、8 月中

旬～9月上旬)。

※1 当年度中の調達の場合は、補正予算、流用等予算措置手続き及びシステム調達手続きに先立ち、実施す

る必要がある。

なお、予算要求を伴わない職員による自己開発等の場合は、随時実施する。

(2) 実施主体

○業務主管課責任者：当該組織の長（情報管理者）


○情報管理主管課責任者：当該組織の長（情報管理主管責任者）




◆計画概要協議書

◆RFI 回答書（見積等） ※2

◇システム更改前評価報告書

○内容協議 ◆計画概要協議結果書

◆協議の記録


○運用の手引き（企画計画段階の運用基準）

○技術指針

○様式 G0-2 協議の記録

○様式 G1-3 計画概要協議結果書

○様式 G0-b 協議の記録サンプル


※2 職員による自己開発の場合等で外部発注がない場合は不要。

(4) 実施事項

① 業務主管課の実施者は、情報管理主管課に計画概要協議書及び添付資料を提出する。


21

② 業務主管課の実施者は、情報管理主管課の実施者と計画概要協議書について協議を行う。

ただし、大規模または影響範囲の広い情報システムについては、協議委員会等で協議を行う

ことも考えられる。

③ 情報管理主管課の実施者は、協議において重要であると思われる事項を「協議の記録」に記

録する。

④ 情報管理主管課の実施者は、協議の結果を基に計画概要協議結果書を作成し、「協議の記

録」と共に責任者の承認を受ける。

⑤ 情報管理主管課の実施者は、業務主管課に計画概要協議結果書及び「協議の記録」を示

す。

⑥ 業務主管課の実施者は、協議結果が「不可」となり、情報管理主管課から再検討の指示があ

れば計画概要協議書の見直しと再協議を実施する。

⑦ 業務主管課の実施者は、協議結果が「可」となった場合、次のサブプロセスに進む。

(5) 留意点

① 下に記す書類を必ず添付すること。

○見積書 ( { 工数 × 単価 } 形式で作業の内訳が記載されているもの )

○これから調達するシステムのネットワーク構成を説明した資料

○調達のスケジュール案

上記に加えて、調達の種類に応じて下に記す書類を添付すること。

新規導入の場合は下記の書類を添付すること。

○これから調達するシステムの「要件」がわかる資料

更改・変更・追加の場合は下記の書類を添付すること。

○現行システムからの変更点が解る資料( 改修概要 )

○現行システムの運用・保守契約書

○現行システムの仕様を説明した資料

② マネジメント区分が「大」のシステムにおいては、システム更改前評価報告書を必ず添付する

こと。


22

1.3 （新規事業調査～）予算要求実施時期予算要求時期※1 協議・提出の対象区分－

目的と概要：

システム計画実施の可否判断のために、事業計画書を作成し、財政主管課による査定を受け、

予算措置を受ける。（従来の予算要求の流れと同様）


新規事業に関する書類、予算要求に関する書類提出の具体的な実施時期は、財政主管課か

らの通知による。また、提出の際には、前プロセスの結果としての計画概要協議結果書を必ず添

付しなければならない。

※1 当年度中の調達で、補正予算、流用等予算措置手続きを伴う場合は、その時期にあわせ行うものとする。ま

た、職員による自己開発等により、外部発注が不要なシステムについては、本作業は不要である。

(2) 実施主体



○財政主管課責任者：当該組織の長（財政主管責任者）





◆見積（RFI 回答書）

◆計画概要協議結果書

○新規事業調の作成

○システム計画の可否判断

○事業別説明書、見積書の

作成

○予算査定

◆新規事業調査表［財政主管課

様式］ ※2

◆歳出予算概算見積書［財政主

管課様式］ ※2 ◆新規事業審査結果［財政主管

課任意形式］

◆予算内示［財政主管課任意形

式］


- ○新規事業調査表［財政主管課様式］

○歳出予算概算見積書［財政主管課様式］

○新規事業審査結果［財政主管課様式］

○歳出予算査定結果［財政主管課様式］


※2 事業内にシステム構築等を含む場合は、計画概要協議書及び協議結果書を添付する。

(4) 実施事項

① 業務主管課の実施者は計画概要協議書及び同結果書、見積り（RFI 回答書）を基に新規事


23

業調査表（財政主管課の指定する様式による。以下同じ。）を作成する。また、この計画概要

協議書及び同結果書、見積りとその他必要な資料を添付資料とする。

② 業務主管課の実施者は、新規事業調査表等について、責任者の承認を得る。

③ 業務主管課の実施者は、新規事業調査表及びシステム計画協議結果書等の添付資料を財

政主管課に提出する。このとき、財政主管課では、情報管理主管課とシステム計画協議を経

ていない新規事業調査表は受理しない。

④ 財政主管課の実施者は、業務主管課の実施者と新規事業調査表について協議を行う。

⑤ 財政主管課の実施者は、責任者に協議結果の承認を得、協議結果を業務主管課に示す。こ

こで協議結果が「否」となった場合、予算を伴う当該システムの計画は中止となる。

⑥ 業務主管課の実施者は新規事業調査表及び添付資料を基に歳出予算概算見積書（財政主

管課の指定する様式による。以下同じ。）を作成する。

⑦ 業務主管課の実施者は、歳出予算概算見積書について、責任者の承認を得る。

⑧ 業務主管課の実施者は、歳出予算概算見積書及び添付資料を財政主管課に提出する。こ

のとき、財政主管課は、情報管理主管課とシステム計画協議を経ていない事業別説明書及

び見積書は受理しない。

⑨ 財政主管課の実施者は、歳出予算概算見積書等を査定し、予算内示を作成する。金額の変

動による機能等の変動が見込まれる場合、業務主管課及び財政主管課の各実施者は必要

に応じ、情報管理主管課と調整を行う。

⑩ 財政主管課の実施者は、予算内示と予算化について、責任者の承認を得る。

⑪ 財政主管課の実施者は、予算内示を業務主管課に示す。

⑫ 業務主管課の実施者は、予算内示を情報管理主管課に報告する。

⑬ 業務主管課の実施者は、内示を得て、次のサブプロセスに進む。

(5) 留意点

① システム構築等が、事業の一部を構成する場合は、新規事業調査表、歳出予算概算見積書

に新規または更新する情報システムの構築や新たな運用調達等が含まれる場合はこれを明

記すること。

② ここで示す積算資料は、可能な限り精度の高いものとすること。

Ⅲ 情報システムマネジメントのプロセスと実施事項２．調達プロセス

24

２．調達プロセス

調達プロセスは、発注する事業者等を選定し、実際に調達契約を締結する段階である。

ここでは、調達準備、調達詳細協議書の協議、予算執行伺い、事業者の選定、契約交渉・締

結といったサブプロセスを実施する。

情報システムの調達は、システムの種類や規模、技術等により、事業者の選定方法や契約方

式が異なってくるため、調達内容に応じた対応が必要となる。

調達プロセスは、情報システムマネジメントに関するプロセスの中でも特に重要性が高い。調達

プロセスにおいて、仕様書の内容、事業者の選定方法に関する検討が不適切であると、システム

導入による目標や目的を十分に達成できず、以下のような根本的な問題や、県にとって大きなリ

スク負担が発生することになる。

○仕様書の内容が不明確であると、事業者側は価格を設定にそのリスク分を上乗せすることに

なる。または、仕様から読み取れる最低限の業務履行にとどまり、発注元の真の意向と乖離す

る。

○事業者の選定方法に関する検討が不適切であると、意図しない事業者が発注先となり、シス

テム開発に支障をきたす（調達内容を実現しうる技術水準を有していない、事業規模を有して

いない等）。

○結果として、システム導入による目標や目的を十分に達成できない。

○運用・保守に過剰な負担が発生する。

このような事態に陥らないよう、調達プロセスでは、調達するシステムに応じた最適な事業者を

選定するために、入念な検討と準備が必要である。

調達プロセスは、職員による自己開発等の場合には、事業者を対象とするサブプロセスは対象

とならないが、仕様の確定とその意思決定については、本ガイドラインを適用する。

なお、本プロセスの処理概要を以下に記載するが、検討すべき項目やその具体的な考え方、

協議書の作成手順等については「運用の手引き」の調達プロセス部分を参照すること。


25


会議体等情報管理主管課財政主管課事業者等

2.1調達準備

2.2詳細協議書の協議

2.3予算執行

伺い

2.4事業者の

選定

サブプロセス

関係者と役割（実施フロー）様式・成果物業務主管課

2.5契約交渉・

締結

要件定義（情報提供依頼含む）

予算執行伺の作成

契約交渉・締結契約交渉・締結

見積・提案・入札への参加

（選定委員会等を設置する場合）

提案書の審査

合議

1 企画・計画

情報提供（見積含む）

3 開発　または、4 運用・保守

契約書

ＲＦＩ回答

競争入札

随意契約（見積合せ・一社契約）プロポーザ

ル方式入札公告

（資料配布・説明会）

入札

最低価格落札方式

総合評価方式

開札

落札者の決定・通知（公示）

見積書徴収

受注者の決定・通知

招請（資料配布・説明会）

提案書の受領（プレゼンテーション）

提案書の審査

プロポーザル方式

総合評価方式

優先交渉権者の決定・通知（公示）

結果通知

結果通知書

仕様書・関連資料の作成

仕様書

債務負担行為以外の区分

支出負担行為書

調達詳細協議書

要件定義書（ＲＦＩ資料）

ＲＦＩ回答

優先交渉権者選定要項

契約書

結果通知書

支出負担行為書

仕様書

募集要項

評価基準

契約書案

予算執行伺予算執行伺

優先交渉権者選定要項

選定委員会の設置

仕様書、関連資料の承認

・プロポーザル方式・競争入札（総合評価方式）

選定方法

・プロポーザル方式・競争入札（総合評価方式）を除くそれ以外の選定方法

要件定義書（ＲＦＩ資料）

債務負担行為債務負担区分

契約形態

契約形態

契約形態

募集要項

評価基準契約書案

大中

マネジメント区分

調達詳細協議書の作成

協議（内容審査）

協議（内容審査）

（協議委員会等を設置する場合）

調達詳細協議書

可協議結果

不可再検討指示調達詳細

協議結果書調達詳細

協議結果書

小

※本ガイドラインでは、これより先の財務手続き(支出負担行為等)についてはサブプロセスとしての記載を

省略する。


26

2.1 調達準備実施時期予算執行伺い前協議・提出の対象区分大・中

目的と概要：

システムの要件定義を行い、システム調達に必要となる仕様書や調達関連資料（実施要項、評

価基準、契約書案等）を作成する。


調達準備は、システム調達に必要な仕様書及び調達関連資料を作成する作業である。

マネジメント区分「大」「中」のシステムにおいては、調達詳細協議書の協議が必要であり、協議

書の作成に先立ち実施する。

(2) 実施主体



○その他支援者：選定委員会

事業者等：発注候補事業者



◆計画概要協議書 ○要件定義

○仕様の検討、作成

○調達関連資料の検討、作成

必要に応じて、

○情報提供依頼（RFI）

◆要件定義書（RFI 資料）

◆情報提供書（RFI 回答） ※1

◆仕様書

◆調達関連資料（募集要項、評価

基準書、契約書案等） ※1


○運用の手引き（調達準備における実施事項）

○技術指針

○沖縄県情報セキュリティ対策基準

○資料 G1-c RFI サンプル

○資料 G2-c 要件定義書及び仕様書項目例

○様式 G2-d 契約書サンプル

○様式 G2-e 募集要項サンプル

○様式 G2-f(2) 評価基準書項目例・別紙評価基準

サンプル


※1：職員による自己開発の場合等で外部発注がない場合は不要

(4) 実施事項

① 業務主管課の実施者は、システムの要件定義を行う。

② 業務主管課の実施者は、必要に応じて、事業者に対して情報提供依頼（RFI：Request For

Information）を行う等の方法で、仕様書の参考情報や調達時の参考費用の情報を収集す


27

る。

③ 業務主管課の実施者は、要件定義書や収集した情報を基に、仕様書及び調達関連資料を

作成する。調達関連資料には、募集要項、評価基準書、契約書案等が含まれる。

④ 業務主管課の実施者は、仕様書及び調達関連資料について、責任者の承認を得る。

⑤ 業務主管課の実施者は、承認を経て次のプロセスに進む。

(5) 留意点

① 要件定義書や仕様書の作成にあたっては、長期的視点に立ち、システムの機能・非機能要

件だけでなく、運用・保守の要件についても十分に検討する必要がある。また、調達関連資

料（募集要項、評価基準、契約書案）の作成にあたっては、応募資格の設定、評価項目の設

定や評価方法、契約書への記載事項や著作権の取り扱い等についても十分に検討する必

要がある。「運用の手引き）」及び各様式・サンプル集を参照し、作成すること。

② RFI 実施（見積り取得）にあたっては、事業者間の見積りの比較を容易にするために、原則と

して様式・サンプル集「RFIサンプル」の付属資料を参考とすることが望ましい。


28

2.2 調達詳細協議書の作成実施時期予算執行伺い前協議・提出の対象区分大・中

目的と概要：

計画しているシステムの調達に向け、調達範囲、契約形態（事業者選定方法、契約内容）や参

加資格等を明らかにした、調達詳細協議書を作成、協議する。調達詳細協議書は、システム調達

実施の可否判断を行うための根拠となる。


調達詳細協議書の作成は、マネジメント区分が、「大」「中」のシステムにおいて必要である。

ここで策定する調達詳細協議書は、システム調達に係る具体的な内容を明記したものであり、

予算執行伺いに先立ち作成する必要がある。

(2) 実施主体







◆改修概要

(更改、変更、追加の場合)

◆仕様書

◆調達関連資料（募集要項、評

価基準書、契約書案等）

○調達詳細協議書の作成

◇調達詳細協議書

○優先交渉権者選定要項


○運用の手引き（調達詳細協議書の作成） ○技術指針


○様式 G2-1 調達詳細協議書（新規導入・更改）

○様式 G2-2 調達詳細協議書（変更・追加）

○資料 G2-a 調達詳細協議書（新規導入・更改）サン

プル

○資料 G2-b 調達詳細協議書（変更・追加）サンプル

○資料 G2-f(1) 評価基準書項目例・優先交渉権者

選定要項サンプル


(4) 実施事項

① 業務主管課の実施者は、計画概要協議書、仕様書や調達関連資料を基に、調達詳細協議

書を作成する。


29

② 業務主管課の実施者は、調達詳細協議書について、責任者の承認を得て、次のサブプロセ

スに進む。

(5) 留意点

① 調達詳細協議書の作成にあたっては、計画概要協議書で記載した内容の変更点や添付す

る資料等について明記する必要がある。「運用の手引き」及び様式・サンプル集「調達詳細協

議書」を参考に作成すること。なお、計画概要協議書の協議を経ていない場合は、計画概要

協議書もあわせて作成すること。

② 調達詳細協議書の作成中、不明点がある場合は、情報管理主管課に相談すること。


30

2.3 調達詳細協議書の協議実施時期予算執行伺い前協議・提出の対象区分大・中

目的と概要：

作成した調達詳細協議書の内容について情報管理主管課と協議を行い、その妥当性について

審査を受ける。協議結果に基づき、必要に応じて調達内容の見直しを行う。


調達詳細協議書の協議は、マネジメント区分が、「大」「中」のシステムにおいて必要である。

協議は予算執行伺いに先立ち実施する必要があるため、その 1 ヶ月前を目安に実施する。

(2) 実施主体








◆調達詳細協議書

◆調達関連資料（募集要項、評

価基準書、契約書案等）

○内容協議 ◆調達詳細協議結果書

◆協議の記録


○運用の手引き（調達段階の運用基準） ○技術指針

○様式 G0-2 協議の記録

○様式 G2-3 調達詳細協議結果書

○様式 G0-b 協議の記録サンプル


(4) 実施事項

① 業務主管課の実施者は、情報管理主管課に調達詳細協議及び添付資料を提出する。

② 業務主管課の実施者は、情報管理主管課の実施者と調達詳細協議書について協議を行う。

ただし、大規模または影響範囲の広い情報システムについては、協議委員会等で協議する

ことも考えられる。

③ 情報管理主管課の実施者は、協議において重要であると思われる事項を「協議の記録」に記

録する。

④ 情報管理主管課の実施者は、協議の結果を基に調達詳細協議結果書を作成し、「協議の記


31

録」と共に責任者の承認を受ける。

⑤ 情報管理主管課の実施者は、業務主管課に調達詳細協議結果書及び「協議の記録」を示

す。

⑥ 業務主管課の実施者は、協議結果が「不可」となり、情報管理主管課から再検討の指示があ

れば調達詳細協議書の見直しと再協議を実施する。

⑦ 業務主管課の実施者は、協議結果が「可」の場合、次のサブプロセスに進む。

(5) 留意点

①下に記す書類を必ず添付すること。

○見積書 ( { 工数 × 単価 } 形式で作業の内訳が記載されているもの )

○これから調達するシステムのネットワーク構成を説明した資料

○これから調達するシステムの開発(導入作業)契約書案・仕様書案

○これから調達するシステムの運用・保守契約書案

○調達のスケジュール案

上記に加えて、調達の種類に応じて下に記す書類を添付すること。

新規導入の場合は下記の書類を添付すること。

○これから調達するシステムの「要件」がわかる資料

更改・変更・追加の場合は下記の書類を添付すること。

○現行システムからの変更点が解る資料( 改修概要 )

○現行システムの運用・保守契約書

○現行システムの仕様を説明した資料


32

2.3 予算執行伺い実施時期事業者の選定前協議・提出の対象区分－

目的と概要：

システム調達に向けた予算執行伺いを行う財務規則上の行為である。債務負担行為を伴う場

合には、予算執行伺いについて、財政主管課との合議が必要となる。


予算執行伺いは、事業者の選定に先立ち実施する。

(2) 実施主体



○その他支援者：財政主管課



◆仕様書

◆調達関連資料

○調達詳細協議書

○予算執行伺の作成

○財政主管課の合議決裁

（債務負担行為時）

◆予算執行伺[財務規則による]


- ○予算執行伺様式[財務規則による]


(4) 実施事項

① 業務主管課の実施者は、予算執行伺いを作成する。

② 業務主管課の実施者は、予算執行伺いについて、責任者の承認を得る。

③ 債務負担行為の場合、業務主管実施者は予算執行伺いについて財政主管課と合議を行う。

(沖縄県財務規則による。)

④ 業務主管課の実施者は、次のサブプロセスに進む。


33

2.4 事業者の選定実施時期契約交渉締結前協議・提出の対象区分－

目的と概要：

発注候補事業者から、実際にシステム調達を行う発注先事業者を選定する。事業者の選定は、

契約までの形態（事業者の選定方法）により実施内容、実施フローが異なるため、各形態に応じ

た対応が必要となる。


事業者の選定は、契約交渉・締結に先立ち実施する。

(2) 実施主体



○その他事業者等：発注候補事業者

支援者：情報管理主管課



◆仕様書

◆調達関連資料 ○事業者の選定（見積精

査、入札、提案評価） ○結果通知書


○運用の手引き（事業者の選定における実施事

項）

○資料 G2-g 結果通知書サンプル


(4) 実施事項

＜随意契約（見積合せ、一社契約等）の場合＞

① 業務主管課の実施者は、事業者等から見積書を徴収する。

② 業務主管課の実施者は、事業者等から受注者を決定する。

③ 業務主管課の実施者は、受注者の結果について、責任者の承認を得る。

④ 業務主管課の実施者は、事業者等に結果を通知する。

＜プロポーザル方式の場合＞


34

① 業務主管課の実施者は、公告等により事業者等へシステム調達に係る資料を配布し、提案

事業者を招請する。必要に応じて、説明会を開催する。

② 業務主管課の実施者は、提案事業者から提案書を受領する。必要に応じて、プレゼンテーシ

ョンを要請する。

③ 業務主管課の実施者または選定委員会は、提案書の内容を審査する。

④ 業務主管課の実施者または選定委員会は、優先交渉権者を決定する。

⑤ 業務主管課の実施者は、優先交渉権者の決定について、責任者または選定委員会の承認

を得る。

⑥ 業務主管課の実施者は、事業者等に結果を通知する。

＜競争入札（最低価格落札方式）の場合＞

① 業務主管課の実施者は、入札公告を行い、事業者等へシステム調達に係る資料を配布する。

必要に応じて、説明会を開催する。

② 業務主管課の実施者は、入札、開札を行い、落札者を決定する。

③ 業務主管課の実施者は、落札者の結果について、責任者の承認を得る。

④ 業務主管課の実施者は、事業者等に結果を通知する。

＜競争入札（総合評価方式）の場合＞

① 業務主管課の実施者は、入札公告を行い、事業者等へシステム調達に係る資料を配布する。

必要に応じて、説明会を開催する。

② 業務主管課の実施者は、入札を行う。

③ 業務主管課の実施者は、事業者等から提案書を受領する。必要に応じて、プレゼンテーショ

ンを要請する。

④ 業務主管課の実施者または選定委員会は、提案書の内容を審査する。

⑤ 業務主管課の実施者は、開札を行う

⑥ 業務主管課の実施者は、提案書の評価結果と入札価格から、落札者を決定する。

⑦ 業務主管課の実施者は、落札者の結果について、責任者または選定委員会の承認を得る。

⑧ 業務主管課の実施者は、事業者等に結果を通知する。

⑨ 業務主管課の実施者は、結果通知後、次のサブプロセスへ進む。

(5) 留意点

① 事業者の選定にあたっては、「WTO 政府調達協定」「地方自治法及び同施行令」「沖縄県財

務規則」等に留意する必要がある。「運用の手引き」を参考に実施すること。


35

2.5 契約交渉・締結実施時期開発着手前協議・提出の対象区分－

目的と概要：

事業者選定の結果、発注予定となった事業者（発注先事業者）と契約内容を交渉し、契約を締

結する。なお、庁内財務手続きである支出負担行為書は当該サブプロセスと同期して行う。


契約交渉・締結は、システム開発の着手に先立ち実施する。

(2) 実施主体



○その他事業者等：発注先事業者



◆結果通知書

◆契約書（案） ○契約内容の交渉

○契約の締結

○支出負担行為書の作成

◆支出負担行為書

◆契約書


- ○資料 G2-d 契約書サンプル

○支出負担行為書[財務規則様式]


(4) 実施事項

① 業務主管課の実施者は、発注先事業者と契約交渉を行い、契約を締結する。

② 業務主管課の実施者は、契約締結後、次のプロセスへ進む。

(5) 留意点

① 契約交渉にあたっては、仕様書等に定める内容に齟齬がないよう十分に協議すること。

② 「沖縄県財務規則」に留意し、契約の締結前に支出負担行為を行うこと。

Ⅲ 情報システムマネジメントのプロセスと実施事項３．開発プロセス

36

３．開発プロセス

開発プロセスは、発注先の事業者を選定後、実際にシステム開発に着手する段階である。

ここでは、プロジェクトの立ち上げ、プロジェクトの実施管理（詳細要件整理、設計・製造・テスト、

移行）、検収・検査、プロジェクトの終結といったサブプロセスを実施する。

特に、詳細要件整理は、実現したい内容や条件を明確化する作業であり、システム製造の成

否を決めるとともに、その後の業務運用にも大きな影響を及ぼすきわめて重要な作業である。この

サブプロセスにおいて、不明確な内容のまま設計や製造に着手すると、以下のような根本的な問

題や、県にとって大きなリスク負担が発生する。

○要件の変更や拡大により、開発期間が延び、スケジュールの遅延が発生する。

○要件の変更や拡大により、開発費用が膨張する。（予算内におさまらなくなる）

○スケジュール遅延や開発費用の抑制にともない、成果物の品質が低下する。

また、設計・製造・テストを事業者任せで行なった場合、要求機能が実現できない、品質が確保

できないなどし、最終的に運用開始時期の遅延、費用の増加を招くとともに、当初の目標や目的

を十分に達成できない可能性がある。

これらの事態に陥らないよう、開発プロセスでは、業務主管課は主体性をもって積極的に関与

するとともに、円滑なプロジェクト運営を図り、システム開発を推進するよう取り組まなければならな

い。

開発プロセスにおいて、職員による自己開発等の場合には、事業者を対象とするサブプロセス

は対象とならないが、仕様の確定とその意思決定については、本ガイドラインを適用する。

なお、本プロセスの処理概要を以下に記載するが、検討すべき項目やその具体的な考え方、

協議書の作成手順等については「運用の手引き」の開発プロセス部分を参照すること。


37


会議体等情報管理主管課事業者等

3.3検収・検査

サブプロセス


3.1プロジェクトの立ち上げ

－

3.3.1検収

業務主管課

3.2.1詳細要件

整理

3.2.2設計・製

造・テスト

3.2.3移行

3.3.2検査

3.4プロジェクト

の終結-

3.2プロジェクトの実施管

理

運用開始

プロジェクト

の立ち上げ（キックオフキーティング）

プロジェクトの評価

・終結

テスト結果の評価製造・テスト（単体・結合・総合テスト）

完了検査の実施・評価

プロジェクト

運営支援

（複数部課に亘るプロジェクト組織を設

置する場合）

2 調達

4 運用・保守

プロジェクト計画書

の承認

受入テストの実施・評価受入テストの実施支援

移行実施・ユーザ教育実

施支援

完了報告

プロジェクト

計画書

プロジェクト

評価書

詳細要件の整理

詳細要件の検討（Fit&Gap）

設計要件（カスタマイズ

要件）の整理

カスタマイズ設計／

基本設計・詳細設計

不良

良好

移行作業・

ユーザ教育

移行計画書

評価再検討指示

（当該作業へ戻る）不良

良好

設計内容の評価

不良

良好

再検討指示

不良

良好

プロジェクト

計画書

移行計画書

完了報告書

検査合格書

各種納品物

プロジェクト

評価書

基本設計書詳細設計書

(ｶｽﾀﾏｲｽﾞ設計

書)

単体テスト

計画書

結合テスト

計画書

総合テスト

計画書

単体テスト

結果報告書

結合テスト

結果報告書

総合テスト

結果報告書

詳細要件詳細要件

【CORAL21ネットワークの接続に関

する協議】

・部局ネットワーク接続協議

・部局システム接続協議

・Web、FTP、電子メール等の特別

なサーバを含む接続協議

・外部遠隔運用システム接続運用

協議

・端末類の導入及び接続協議

・電子機器等に関するインターネッ

ト特別利用申請

・グローバルIPアドレス取得協議

・サブドメイン名取得協議

・監視機器装置設置等協議

（必要に応じ、情報政策課へ申請）

あり

なし

CORAL21

ﾈｯﾄﾜｰｸ協

議結果書

プロジェクト計画書

の受領

プロジェクト評価書

の受領

受入テスト

結果報告

受入テスト

結果報告

各種

マニュアル

各種

マニュアル

＜CORAL21ネットワークの場合の例＞

プロジェクト計画書案の

作成

ネットワーク

への接続

評価

再検討指示評価

再検討指示

完了報告書

各種納品物評価

検査合格書

CORAL21

ﾈｯﾄﾜｰｸ協

議結果書

単体テスト

結果報告書

結合テスト

結果報告書

総合テスト

結果報告書

単体テスト

計画書

結合テスト

計画書

総合テスト

計画書


38

3.1 プロジェクトの立ち上げ実施時期ＰＪ実施管理前協議・提出の対象区分大

目的と概要：

発注先事業者とシステム開発プロジェクトの計画や管理など運営方法を整理した、プロジェクト

計画書を作成する。プロジェクト計画書は、開発プロセスにおいて骨格となるドキュメントとなる。


プロジェクト計画書の作成は、すべてのマネジメント区分で作成することが望ましいが、情報シス

テムの新規導入・更改を行うマネジメント区分「大」の場合には、情報管理主管課への提出が必須

である。

プロジェクト計画書は、詳細要件整理等実際の開発作業の着手に先立ち作成する。

なお、情報管理主管課では提出されたプロジェクト計画情報を共有し、他のプロジェクトの参考

とする。

(2) 実施主体



○その他事業者等：開発の受託事業者




◆契約書（仕様書含む） ○プロジェクトのキックオフ

○プロジェクト計画書の作

成

◆プロジェクト計画書


○運用の手引き（プロジェクトの立ち上げ） ○様式 G0-1 協議書等提出鑑

○資料 G3-a プロジェクト計画書サンプル


(4) 実施事項

① 業務主管課の実施者は、プロジェクトマネージャーやメンバ等のプロジェクト関係者を選任し、

プロジェクトを立ち上げ、キックオフミーティングを開催する。


39

② 業務主管課の実施者は、事業者等へプロジェクト計画書案の作成を要請する。

③ 業務主管課の実施者は、プロジェクト計画書案について、責任者の承認を得る。また、マネジ

メント区分「大」の場合は情報管理主管課へ提出する。

④ 業務主管課の実施者は、プロジェクト計画書をプロジェクト関係者に配布し、次のサブプロセ

スに進む。

(5) 留意点

① プロジェクト計画書の作成にあたっては、プロジェクトの目的、成果や目標、作業範囲、スケジ

ュール、体制、業務管理の方法等について検討する必要がある。「運用の手引き」及び各様

式・サンプル集を参考に必要項目を明記した計画書の作成を事業者等へ要請すること。


40

3.2 プロジェクトの実施管理

3.2.1 詳細要件整理実施時期設計作業前協議・提出の対象区分－

目的と概要：

計画しているシステムにおいて実現したい内容や条件を明らかにするため、詳細要件を整理す

る。パッケージ・ソフトウェアを採用する場合は、県の業務内容や処理方法等に適合しているか詳

細に検討・分析を行い、追加開発の必要性について整理する。


ここで整理する詳細要件は、システムにおいて実現したい内容や条件を洗い出す作業であり、

設計作業に先立ち実施する。

(2) 実施主体







◆仕様書

○プロジェクト計画書

○詳細要件の検討

（フィット・ギャップ分析の

実施）

◆詳細要件整理資料


○運用の手引き（プロジェクトの実施管理、プロジェク

ト実施管理の詳細事項）

○技術指針


－


(4) 実施事項

① 業務主管実施者は、プロジェクトを開始し、プロジェクトを管理する。

② パッケージソフトを採用する場合、業務主管課の実施者は事業者等と協力して、パッケージソ

フトの標準機能が、業務内容や処理方法に適合しているか等を検討し（フィット・ギャップ分析


41

9等）、必要な機能等の詳細要件について整理する。

③ 独自開発の場合、業務主管課は他事例等を参考に必要な機能等の詳細要件を検討し、整

理する。

④ 業務主管課の実施者は、詳細要件の整理後、次のサブプロセスへ進む。

(5) 留意点

① 詳細要件の整理にあたっては、業務要件の整理、実現する機能、画面遷移、操作性等につ

いて十分に検討する必要がある。「運用の手引き」を参考に、詳細要件を整理した資料の作

成を事業者等へ要請すること。

② パッケージソフトを採用する場合、BPR10（ビジネスプロセス・リエンジニアリング）の観点から、

業務をパッケージに合わせ、カスタマイズは極力行わないようにすること。

9 フィット・ギャップ分析：パッケージ・ソフトウェアを導入する際に、組織の業務の流れやシステムに対する機能要求とパッケー

ジ・ソフトウェアが提供する機能の間で、適合（フィット）やズレ（ギャップ）がないかを調査、分析、評価すること。 10 BPR(Business Process Re-engineering)：行政改革を図るために、既存の組織や規則を抜本的に見直し、業務フロー、役割分

担、情報システム等を再設計すること。


42

3.2.2 設計・製造・テスト実施時期移行作業前協議・提出の対象区分－

目的と概要：

整理した詳細要件から、実際のシステムにおいて実現する機能や条件等の設計要件（カスタマ

イズ要件）を整理する。また、その内容等に基づき、事業者等に対して、設計・製造・テストの実施

を指示するとともに、各成果物の評価を実施する。

なお、ネットワークと接続を伴う場合、当該ネットワークへの接続に関する庁内協議を実施の

上、必要な各種事項について整理し、設計内容に反映する。


ここでの工程は、システムそのものの開発工程であり、移行作業に先立ち実施する。

(2) 実施主体







◆仕様書

◆詳細要件整理資料


○設計要件の整理

○設計内容の評価

○テスト結果の評価

◆各種設計書（基本、詳細）

◆詳細テスト計画書（単体、結

合、総合）

◆テスト結果報告書（単体、結

合、総合）





○資料 G3-c 課題管理表サンプル


(4) 実施事項

① ネットワークとの接続について

ⅰ ネットワーク接続を行う場合、業務主管課の実施者は、当該ネットワークの管理者に対し、

あらかじめ必要な協議を実施し、必要な各種事項について整理する。

例えば、対象ネットワークが CORAL21ネットワークである場合、CORAL21ネットワーク運用

管理要綱及び同要領により、必要に応じ、次のような協議が必要とされている。


43

○部局ネットワーク接続協議

○部局システム接続協議

○Web、FTP、電子メール等の特別なサーバを含む接続協議

○外部遠隔運用システム接続運用協議

○端末類の導入及び接続協議

○電子機器等に関するインターネット特別利用申請

○グローバル IPアドレス取得協議

○サブドメイン名取得協議

○監視機器装置設置等協議

ⅱ 接続を行わない場合、業務主管実施者は、次の作業（実施事項②）へ進む。

② パッケージソフトを採用する場合、業務主管課の実施者は、事業者等と協力してパッケージソ

フトのカスタマイズ要件を整理し（必要となる詳細機能のうち、カスタマイズするもの・しないも

のを整理する）、その内容を設計要件とするように事業者等へ指示する。

③ 独自開発の場合、業務主管課の実施者は、事業者等と協力して設計要件を整理し、その内

容を設計要件とするように事業者等へ指示する。

④ 業務主管課の実施者は、事業者等の作成した設計書の内容を評価する。

⑤ 業務主管課の実施者は、設計書の評価について、責任者の評価を得る。評価が良好であれ

ば次の作業に進み、不良であれば、設計書の再検討を指示する。

⑥ 業務主管課の実施者は、設計書に基づき事業者等が製造した成果物について、各種テスト

（単体テスト、結合テスト、総合テスト）の実施を指示する。また、テスト実施にあたり、各種テス

ト計画書（単体テスト、結合テスト、総合テスト）の作成を指示する。

⑦ 業務主管課の実施者は、事業者等が行ったテストの結果（単体テスト、結合テスト、総合テスト）

を評価する。

⑧ 業務主管課の実施者は、テスト結果の評価について、責任者の承認を得る。評価が良好で

あれば次のサブプロセスへ進み、不良であれば、製造・テストの再検討を指示する。

(5) 留意点

① 設計内容の評価にあたっては、システム要件、アプリケーション機能、ハードウェア要件等に

ついて評価する必要がある。「運用の手引き」を参考に、必要項目を満たした内容であるか評

価すること。また、評価結果が不良の場合、事業者等へ再検討を指示するとともに、結果が

良好となるまで管理すること。

② テスト結果の評価にあたっては、各種テスト計画書で定めたテスト項目及びその完了基準を

達成した内容であるか評価すること。また、評価結果が不良の場合、事業者等へ再検討を指

示するとともに、結果が良好となるまで管理すること。

③ 開発プロセスの終了時に、スムースに運用が開始できるよう、運用・保守プロセスを意識して

おくこと。


44

3.2.3 移行実施時期検収作業前協議・提出の対象区分－

目的と概要：

システムの移行スケジュールや方法等を明記した移行計画書の作成を事業者等へ指示すると

ともに、移行計画に基づき移行作業を実施する。また、利用者の業務・システムへの理解やシス

テム操作の習熟を目的にユーザ教育を実施する。


移行作業は、実運用の開始に向けて実施する本番機等へのシステムやデータの移行作業で

あり、検収作業（受入テスト）に先立ち実施する。

(2) 実施主体







◆各種テスト結果報告

○プロジェクト計画書 ○移行作業の検討・実施

○各種マニュアル等の作成

○ユーザ教育の実施

◆移行計画書

○各種マニュアル等

○移行完了




－


(4) 実施事項

① 業務主管課の実施者は、テスト完了後、事業者等へ移行計画書の提出を指示し、提出を受

けた計画書を審査のうえ、承認する。

② 事業者等は、移行計画書に基づき、移行環境の構築、データ移行等のシステム移行を実施

する。業務主管課の実施者は、事業者等の作成した移行計画書に基づき、移行作業を支援

する。

③ 業務主管課の実施者は、契約内容に応じて、事業者等へ各種マニュアル等の作成を指示す


45

る。

④ 業務主管課の実施者は、事業者等の支援をうけ、ユーザ教育を行う。

⑤ 業務主管課の実施者は、移行作業及びユーザ教育の実施後、次のプロセスに進む。

(5) 留意点

① システム移行作業にあたっては、移行計画書で定めたスケジュールや手順に沿って実施して

いるか、検証項目とその完了基準を満たしているか等について管理する必要がある。「運用

の手引き」を参考に、移行作業を実施すること。

② ユーザ教育にあたっては、利用者の業務・システムへの理解度やシステム操作の習熟度等を

高めることを目的に事業者等に協力を要請し、実施することが必要である。「運用の手引き」

を参考に、ユーザ教育を実施すること。


46

3.3 検収・検査

3.3.1 検収実施時期検査作業前協議・提出の対象区分－

目的と概要：

利用者が業務の流れに沿ってシステムのテストを行い、システムが利用者の要求内容や条件

に沿った仕様を実現していることを確認する。


検収作業は、開発したシステムが利用者の要求内容や条件を実現していることを確認する作

業であり、検査作業に先立ち実施する。

(2) 実施主体







○移行計画書（結果）

○各種テスト結果報告


○受入テストの検討・実施・

評価 ◆受入テスト計画書

◆受入テスト結果報告書


○運用の手引き（検収・検査、プロジェクトの実施管理

の詳細事項）


－


(4) 実施事項

① 業務主管課の実施者は、事業者等の支援を受け、受入テスト計画書の作成と受入テストを実

施し、システムの評価を行う。

② 業務主管課の実施者は、受入テストについて、責任者の承認を得る。評価が良好であれば

次のサブプロセスに進み、不良であれば原因究明とその修正作業を指示する。


47

(5) 留意点

① 検収にあたっては、「運用の手引き」内の「「検収・検査における」実施事項」を基に、定めた水

準を達成した内容であるか評価が必要である。「運用の手引き」を参考に、検収作業を実施

すること。また、評価結果が不良の場合、事業者等へ再検討を指示するとともに、結果が良

好となるまで管理すること。


48

3.3.2 検査実施時期ＰＪ終結前協議・提出の対象区分－

目的と概要：

事業者等から完了報告書及び各種成果物の提出を指示し、契約書（仕様書含む）で定めた成

果物が漏れなく納品されていることを確認する。また、契約の取り決めにしたがい、所有権の移転

等を行い、契約を終了する。

財務手続き上の支出手続き（精算払い）においては、一般的にこのプロセスと同期する。


検査作業は、契約書（仕様書含む）で定めた成果物が納品されていることを確認する作業であ

り、プロジェクトの終結に先立ち実施する。

(2) 実施主体







◆契約書（仕様書含む）

○プロジェクト計画書 ○各種成果物等の受領・検

査 ◆各種成果物

◆完了報告書

◆検査合格書

◆支出調書（精算払いの場合）


○運用の手引き（検収・検査、プロジェクトの実施管理

の詳細事項）

－


(4) 実施事項

① 業務主管課の実施者は、検収完了後、事業者等へ完了報告書及び各種成果物の納品を指

示する。

② 業務主管課の実施者は、事業者等から完了報告書及び各種成果物を受領し、検査する。

③ 業務主管課の実施者は、検査結果について、責任者の承認を得る。検査結果が良好であれ

ば検査合格書を発行し、不良であれば再検討を指示する。


49

④ 業務主管課の実施者は、契約の取り決めにしたがい、事業者等からシステムに関する所有権

の移転、精算（支払手続き）等を行う。

⑤ 業務主管課の実施者は、システム運用を開始し、次のサブプロセスに進む。

(5) 留意点

① 検査にあたっては、「契約書（仕様書含む）」で定めた成果物が漏れなく納品されているか評

価が必要である。「運用の手引き」を参考に、検査を実施すること。また、評価結果が不良の

場合、事業者等へ再検討を指示するとともに、結果が良好となるまで管理すること。

② システムの運用開始は、運用・保守プロセスが開始されることにほかならない。開発プロセス

の終盤においては、運用・保守プロセスについて意識しておく必要がある。


50

3.4 プロジェクトの終結実施時期検査完了後協議・提出の対象区分大

目的と概要：

プロジェクトの実績と評価を報告したプロジェクト評価書をとりまとめる。プロジェクトの全工程が

完了したことを確認し、プロジェクトを終結する。


プロジェクトの評価・終結は、検査完了後、速やかに実施することが望ましい。

プロジェクト評価書は、情報システムの新規導入・更改を行う場合のマネジメント区分「大」の場合

には、作成後、情報管理主管課へ提出する必要がある。提出されたプロジェクト評価書は、情報

管理主管課において情報を共有し、他システムや次の更新等の参考とする。

(2) 実施主体






◆検査合格書 ○プロジェクトの評価

○プロジェクトの終結 ◆プロジェクト評価書


○運用の手引き（プロジェクトの終結）


○様式 G3-2 プロジェクト評価書

○資料 G3-b プロジェクト評価書サンプル


(4) 実施事項

① 業務主管課の実施者は、総括としてプロジェクトの評価を行い、プロジェクト評価書をとりまと

める。

② 業務主管課の実施者は、プロジェクト評価書について、責任者の承認を得、マネジメント区分

に応じ、情報管理主管課へ提出する。

③ 業務主管課の実施者は、プロジェクトの全工程を完了したことを確認し、プロジェクトを終結す


51

る。

④ 業務主管課の実施者は、プロジェクト終結後、次のプロセスに進む。

(5) 留意点

① プロジェクト評価書の作成にあたっては、当初目標の達成度、発生した問題と対処事項、体

制、今後の課題や引き継ぎ事項等を評価し、整理することが必要である。「運用の手引き」を

参考に、作成すること。


52

3.5 情報システム台帳への登録・更新実施時期検査完了後協議・提出の対象区分すべて

目的と概要：

調達したシステムについて、情報システム台帳への登録を行う。既に登録済みのシステムの場

合はその情報の更新を行う。


検査完了後、調達したシステムについて、情報システム台帳への登録を速やかに行う。

既にシステムが登録済みの場合は、登録されている情報を最新の情報に更新する。

(2) 実施主体






◆調達したシステムの仕様書

◆調達したシステムのネットワー

ク構成図

○情報システム台帳への登

録・更新 ◆情報システム台帳 (最新の状

態)


○運用の手引き（情報システム台帳への登録・更

新）


(4) 実施事項

① 業務主管課の実施者は、情報システム台帳に調達したシステムについての情報を登録する。

② 調達したシステムが既に登録されている場合は、情報システム台帳の該当のシステムの情報

を最新の状態に更新する。

(5)留意点

①情報システム台帳に記載する項目は、協議時の技術動向等によって変更されることがある。

②情報システム台帳の項目で不明な点は導入・開発・運用・保守業者にそれぞれ確認し、

正確な情報を記入すること。

Ⅲ 情報システムマネジメントのプロセスと実施事項４．運用・保守プロセス

53

４．運用・保守プロセス

運用・保守プロセスは、情報システムの開発後に、実際に運用・保守を行うプロセスである。

ここでは、運用・保守準備、調達、運用・保守計画及び手順の策定、運用・保守の実施といった

サブプロセスを実施する。

運用・保守プロセスでは、開発した情報システムが、県が求める要件や基準に沿って安定して

確実にサービス提供できるよう、運用・保守の計画及び手順を定め、適切に情報システムの運用・

保守またはその管理を実施する。また、当初設定した品質水準に達しているかどうかを評価し、継

続的な改善を実施する。

情報システムのライフサイクルを考えると、全体の中で運用・保守の期間がもっとも長く、支出さ

れる費用も開発に係る費用より大きくなることも多い。また、提供されるサービスの品質は、行政サ

ービスの品質に直結する。

したがって、運用・保守プロセスの取り組み次第で、システムの費用対効果は左右される。情報

システムの運用・保守を確実に実施し、継続的な評価、改善を行い、情報システムのサービスの

維持・向上に努めることが大切である。

運用・保守は、開発プロセスの後段となるプロセスではあるが、運用・保守の要件については、

上流工程から作りこんでいく必要がある。企画・計画プロセスから検討し、開発プロセスにおいて

確定しておく必要がある。

運用・保守プロセスの処理概要を以下に示すが、検討すべき項目やその具体的な考え方、協

議書の作成手順等については「運用の手引き」の運用・保守プロセス部分を参照すること。

なお、これらは、運用・保守作業を外部事業者に委託する場合を想定して記載しているが、職員

による自己運用、自己保守の場合は、本ガイドラインに示された内容に沿って、自ら管理を実施し

なければならない。


54


会議体等情報管理主管課事業者等

4.2調達

－

4.3運用・保守計画及び手順の策定

－

4.4運用・保守

の実施

4.4.1運用・保守の実施管理

4.4.2サービス品

質評価

サブプロセス


4.1運用・保守

準備－

業務主管課

運用・保守要件定義

3 開発

「2 調達」に同じ

運用・保守計画書

の承認

運用・保守の実施管理

情報提供（見積含む）

運用・保守手順書

サービス品質測定手順

書

の承認

（監督）

運用・保守の実施

運用・保守計画書案

の作成

運用・保守手順書案

サービス品質測定手順

書案の作成

運用・保守

要件定義

書

評価測定

サービス品質評価

改善計画の検討

5.1 評価

サービス品

質評価報告

各種管理

台帳

業務運用・

保守記録

改善の実施

運用・保守

計画書

運用・保守

手順書

サービス

レベル基準

運用・保守

要件定義

書

運用・保守

計画書

運用・保守

手順書

サービス品

質評価報告

各種管理

台帳

業務運用・

保守記録

サービス

レベル基準

サービス品

質測定手順

書

サービス品

質測定手順

書


55

4.1 運用・保守準備実施時期運用・保守の調達の前協議・提出の対象区分－

目的と概要：

調達した情報システムが提供するサービスを保証するために必要な、システムの運用・保守に

関する要件を検討し、明確化する。


ここでとりまとめる運用・保守要件定義書は、運用・保守の調達仕様書の一部になるものであり、

運用・保守の調達の前に実施する必要がある。

(2) 実施主体






◆仕様書

○業務に関する要求事項 ○運用・保守要件の検討 ◆運用・保守要件定義書

○サービスレベル基準


○運用の手引き（運用・保守要件定義） ○資料 G4-a 運用・保守要件定義書項目例


(4) 実施事項

① 業務主管課の実施者は、システムが提供するサービスの基本的な管理目標やその目標を達

成するためのシステムの運用・保守の要件、サービスレベル基準を検討する。

② 業務主管課の実施者は、①の検討内容を運用・保守要件定義書、サービスレベル基準とし

てとりまとめる。

③ 業務主管課の実施者は、運用・保守要件定義書、サービスレベル基準について責任者の承

認を得て、次のサブプロセスに進む。


56

(5) 留意点

① 運用・保守要件定義書の作成にあたっては、運用・保守の対象・内容・条件、セキュリティ要

件等について検討する必要がある。「運用の手引き」及び様式・サンプル集「運用・保守要件

定義書項目例」を参照し、作成すること。

② システム運用・保守要件の基本的な内容は、その費用に大きく影響することから、システム調

達時における仕様書作成時に検討しておく必要があり、さらにその詳細な内容は、開発段階

の早い時期から同時並行で検討する必要がある。

③ 運用・保守要件には、提供サービスのための運用・保守のみならず、システム保有資産に応

じたセキュリティ案件（資源管理、ログ管理、パッチ及びウィルス対策管理）についても網羅す

る必要がある。特に、担当者によるセキュリティプログラムの更新は、更新漏れが発生する可

能性が高いため、業者と保守または運用の契約を締結し、その中で実施することを強く推奨

する。

④ 運用・保守要件の一部として、求めるサービスレベル水準（例：システムの稼働率、障害の回

復時間、操作ミスの発生率等）について、可能な限り規定すること。


57

4.2 調達実施時期システム稼働開始前協議・提出の対象区分大・中

目的と概要：

開発と運用・保守を分離した場合など新たな調達が必要な場合は、定義した運用・保守要件に

基づき、調達手続きを実施する。


「２．調達」に同じ。

(2) 実施主体




(4) 実施事項


(5) 留意点

① 運用・保守の調達を実施する場合には、サービスレベル協定書（SLA：Service Level

Agreement）を交わすことが望ましい。


58

4.3 運用・保守計画及び手順の策定実施時期システム稼働開始前協議・提出の対象区分－

目的と概要：

システムの運用・保守を確実に実施するために、運用・保守の計画を策定するとともに、システ

ム運用・保守の内容を明確化した手順書を策定する。


運用・保守計画及び手順は、システムの運用・保守の内容や手順を定めるものであり、システム

の稼働開始前に策定する必要がある。

(2) 実施主体



○その他事業者等：運用・保守の受託事業者




◆運用・保守要件定義書

○サービスレベル基準 ○事業者による検討 ◆運用・保守計画書

◆運用・保守手順書

○サービス品質測定手順書


○運用の手引き（運用・保守手順書の策定）


○資料 G4-b 運用・保守計画書項目例

○資料 G4-c 運用・保守手順書項目例


(4) 実施事項

① 業務主管課の実施者は、運用・保守要件定義書（仕様書）や業務のスケジュール等を示し、

事業者等に、実施する運用・保守業務の内容を定めた運用・保守計画書案の作成を要請す

る。

② 業務主管課の実施者は、事業者等が作成した運用・保守計画書案について内容の精査・確

認を行い、見直しが必要であれば事業者等との協議を実施する。

③ 業務主管課の実施者は、運用・保守計画書案について、責任者の承認を得る。


59

④ 業務主管課の実施者は、事業者等に、システム運用・保守の手順を明確化した運用・保守手

順書案、サービスレベル基準に対する具体的な測定方法を示したサービス品質測定手順書

案の作成を要請する。

⑤ 業務主管課の実施者は、事業者等が作成した運用・保守手順書案、サービス品質測定手順

書案について内容の精査・確認を行い、見直しが必要であれば、事業者等との協議を実施

する。

⑥ 業務主管課の実施者は、運用・保守手順書案、サービス品質測定手順書案について、責任

者の承認を得る。

⑦ 業務主管課の実施者は、システムで実現する新業務を実施するための組織・体制整備、利

用者に対する周知や利用促進等の取組みを実施（事業者等による実施も含む）し、次のサブ

プロセスに進む。

(5) 留意点

① システム運用・保守手順書の作成にあたっては、システム運用作業（バックアップ、監視、更

新プログラムの適用作業等）、システム保守（ハードウェア保守、ソフトウェア保守）作業につ

いて検討する必要がある。「運用の手引き」及び様式・サンプル集「運用・保守手順書項目例」

を参照し、事業者等に作成を要請すること。

② 運用・保守計画書は、期間を定めて作成する。通常は、年次及び月次レベルで作成する。必

要に応じて、週次や日次の計画書を作成する。

③ サービスレベル基準は、必要に応じて見直しを行うこと。


60

4.4. 運用・保守の実施

4.4.1 運用・保守の実施管理実施時期システム運用中協議・提出の対象区分－

目的と概要：

システムの安定的な稼働をさせるため、システム運用・保守手順書に沿って、運用・保守を実施

する。


運用・保守の実施管理は、システムの運用中に継続的に行う事項である。

(2) 実施主体



○その他事業者等：運用・保守の受託事業者



◆情報システム台帳(従前の状

態)

◆運用・保守計画書

○運用・保守手順書

○運用・保守要件定義書

○運用の実施管理

○保守の実施管理 ◆情報システム台帳 (最新の状

態)

○運用・保守記録

○各種管理台帳


○運用の手引き(情報システム台帳への登録・更新)

○運用の手引き（運用・保守の実施管理）


－


(4) 実施事項

① 業務主管課の実施者は、情報システム台帳に記載されている内容に変更があった場合、速

やかにこれを情報システム台帳に反映する。

② 業務主管課の実施者は、事業者等が運用・保守手順書に沿って行う運用・保守の実施状況

について、事業者から報告を受ける。

③ 業務主管課の実施者は、報告内容について、運用・保守計画書や運用・保守手順書に照ら

し合わせ、実施状況を確認する。


61

④ 業務主管課の実施者は、定期的に実施状況を責任者に報告し、承認を得て、次のサブプロ

セスに進む。

(5) 留意点

① 情報システム台帳に記載する項目は、協議時の技術動向等によって変更されることがある。

② 情報システム台帳の項目で不明な点は導入・開発・運用・保守業者にそれぞれ確認し、正確

な情報を記入すること。

③ 運用・保守の実施管理に当たっては、報告方法、確認方法、報告に基づく対応について検

討・実施する必要がある。「運用の手引き」を参照し、検討・実施すること。

④ 大規模なソフトウェア保守(追加・改修)を実施する場合は、企画・計画、調達、開発プロセスの

事項を実施する。


62

4.4.2 サービス品質評価実施時期システム運用中協議・提出の対象区分－

目的と概要：

情報システムが提供するサービス品質を継続的に向上させていくために、サービスの評価を実

施する。


サービス品質評価は、システムの運用中に月単位、四半期単位、年単位等、期間を定めて定

期的に実施する。

(2) 実施主体






○サービスレベル基準

○サービス品質測定手順書 ○測定の実施

○評価の実施 ○サービス品質評価報告書

○改善計画


○運用の手引き（サービス品質評価報告）－


(4) 実施事項

① 業務主管課の実施者は、事業者等からサービス品質評価報告書（サービスレベル基準で定

めた項目について、サービス品質測定手順書にのっとり測定を行った結果をまとめたもの）に

ついて報告を受け、定期的に評価を行う。

② 業務主管課の実施者は、評価の結果、改善すべき事項が見出された場合には、改善計画を

立案する。

③ 業務主管課の実施者は、改善計画について責任者の承認を得て、計画を実施する。


63

(5) 留意点

① サービス品質評価に当たっては、報告方法、評価方法、改善計画立案等について検討・実

施する必要がある。「運用の手引き」を参照し、検討・実施すること。

② サービスレベル協定書を交わす場合には、同協定書のっとり、評価を実施すること。

③ ここでの評価は、「5.1 システム運用中評価」「5.2 システム更改前評価」における素材のひと

つになることを念頭に測定、評価すること。

④ サービスレベル基準についても、必要に応じて見直しを行うこと。

Ⅲ 情報システムマネジメントのプロセスと実施事項５．評価・廃止プロセス

64

５．評価・廃止プロセス

評価・廃止プロセスは、運用・保守を実施している情報システムについて、その稼働後や更改の

前に評価を行うとともに、不要になった場合に廃止手続きをするプロセスである。

ここでは、システム運用中評価、システム更改前評価、システム廃止といったサブプロセスを実

施する。

システム評価とは、導入したシステムについて検証し、システムの改善・見直しを図っていくこと

である。システムの効果的な活用を図るためには、導入したままにするのではなく、その継続的な

検証を行うことが重要である。

システム運用中評価サブプロセスでは、稼働して一定期間の後に、計画した目的・目標を達成

しているかどうか等を評価し、その後の稼働期間中の改善方針を検討するものである。システムは

通常５年以上は運用する。早期に改善を図れば、その後の長い活用期間内における導入効果等

を高めることができる。

一方、システム更改前評価サブプロセスでは、システム更改のタイミングにおいて、当初の計画

に立ち戻って振り返りを行い、更改の機をとらえた効果的な改善を検討・実施するものである。シ

ステム更改前評価サブプロセスは、このような、より長期継続的な改善のサイクルを確立すること

に狙いがある。

また、システムはいずれ使わなくなるときが到来し、廃止するときが来る。システムの廃止に当た

っては、廃止することで、他のシステムに影響がないか、また資産管理上の問題はないか等を確

認する必要がある。システム廃止サブプロセスでは、そのための手続きを実施する。

なお、本プロセスの処理概要を以下に記載するが、検討すべき項目やその具体的な考え方、協

議書や評価書の作成手順等については「運用の手引き」の評価・廃止プロセス部分を参照するこ

と。


65



66

5.1 システム運用中評価実施時期システム稼働から１年後協議・提出の対象区分大

目的と概要：

稼働後のシステムに関して、当初の目的・目標の達成状況や改善の必要性等について評価を

行い、システム運用中評価報告書をとりまとめる。報告書はその後の運用に当たっての改善方針

の検討に活用する。


システム運用中評価報告書の作成と提出は、マネジメント区分が大のシステムを対象に実施す

る。当面、企画部総合情報政策課が主管する組織のみ実施する。

システム運用中評価は、当該システムのその後の改善方針の検討材料となる。したがって、シス

テム稼働から１年程度が経過し、当該システムについて一定の評価が可能になった時点で実施

する。

(2) 実施主体







◆計画概要協議書 ○対象システムの運用中評

価 ◇システム運用中評価報告書


○運用の手引き（システム運用中評価報告書の作

成）


○様式 G5-4 システム運用中評価報告書

○資料 G5-c システム運用中評価報告書サンプル


(4) 実施事項

① 業務主管課の実施者は、当該システムについて、システムの目的・目標の達成度合いを測る

ための指標の調査を行う。

② 業務主管課の実施者は、システム運用中評価報告書作成手順に基づいて、システム運用中


67

評価報告書を作成する。

③ 業務主管課の実施者は、システム運用中評価報告書について、責任者の承認を得る。

④ 業務主管課の実施者は、システム運用中評価報告書の結果に基づいて必要な改善を実施

し、次のプロセスもしくはサブプロセスに進む。

(5) 留意点

① システム運用中評価報告書の作成にあたっては、目標の達成状況、問題点、改善方針等に

ついて検討する必要がある。「運用の手引き」及び様式・サンプル集「システム運用中評価報

告書」を参照し、作成すること。

② 計画の時点で、定量的な目標を示していない場合も、関連する事実を示すなど、目的・目標

の達成状況の根拠を明示する。


68

5.2 システム更改前評価実施時期更改計画の着手前協議・提出の対象区分大

目的と概要：

運用中のシステムに関して、当初の目的・目標の達成状況や改善の必要性等について評価を

行い、システム更改前評価報告書をとりまとめる。報告書は更改時の方針の判断材料として活用

する。


システム更改前評価報告書の作成と提出は、マネジメント区分が大のシステムを対象に実施す

る。

システム更改前評価は、当該システムの更改にあたっての方針（継続、全面更改、廃止等）を判

断するための材料となる。したがって、システム更改に関する企画・計画の前に実施する必要があ

る。

(2) 実施主体








◇システム運用中評価報告書 ○対象システムの評価 ◇システム更改前評価報告書


○運用の手引き（システム更改前評価報告書の作

成）


○様式 G5-1 システム更改前評価報告書

○資料 G5-a システム更改前評価報告書サンプル


(4) 実施事項

① 業務主管課の実施者は、システムの目的・目標の達成状況を整理するとともに、外部環境の

変化に伴う見直しの必要性等について検討する。

② 業務主管課の実施者は、システム更改前評価報告書作成手順に基づいて、システム更改前


69

評価報告書を作成する。

③ 業務主管課の実施者は、システム更改前評価報告書について、責任者の承認を得る。

④ 業務主管課の実施者は、システム更改前評価報告書の結果に基づき、次のプロセスもしくは

サブプロセスに進む。

(5) 留意点

① システム更改前評価報告書の作成にあたっては、目標の達成状況、問題点、改善方針等に

ついて検討する必要がある。「運用の手引き」及び様式・サンプル集「システム更改前評価報

告書」を参照し、作成すること。

② 計画の時点で、定量的な目標を示していない場合も、関連する事実を示すなど、目的・目標

の達成状況の根拠を明示する。

③ システム更改前評価報告書は、システム更改にあたっての計画概要協議書の添付資料とし

て、また廃止する場合は廃止届の添付資料として提出する。


70

5.3 システム廃止実施時期廃止の数か月前協議・提出の対象区分すべて

目的と概要：

システムを廃止する判断になった場合に、その廃止が他に問題となる影響を与えないよう、シス

テムを廃止し、設置スペース、電源、ネットワーク空間等の開放を行う。


システム廃止協議書は、すべてのマネジメント区分のシステムを廃止（停止）する１か月前までに

提出する必要があり、廃止の検討はその数カ月前に実施する。

(2) 実施主体







○システム更改前評価報告書 ○廃止手続きの検討 ◆システム廃止協議書

◆情報システム台帳(当該システ

ムが抹消された状態)


○運用の手引き（システム廃止協議書の作成）

○運用の手引き(情報システム台帳への登録・更新) ○様式 G0-1 協議書等提出鑑

○様式 G5-1 システム廃止協議書

○資料 G5-3 システム廃止協議結果通知書

○資料 G5-b システム廃止協議書サンプル


(4) 実施事項

① 業務主管課において、他機関、他システムへの影響を確認し、システムを廃止することにつ

いて合意を得る。

② 業務主管課の実施者は、システム廃止協議書を作成する。

③ 業務主管課の実施者は、システム廃止協議書について、責任者の承認を得る。

④ 業務主管課の実施者は、システム廃止協議書を情報管理主管課に提出する。


71

⑤ 情報管理主管課の実施者は、システム廃止協議書の内容を確認し、接続ネットワークへの影

響、工事の有無、設置箇所、データの抽出保存または抹消等廃止にあたって問題点がある

場合には、業務主管課への指示を行う。

⑥ 業務主管課の実施者は、協議の結果、指示がある場合には対応策を実施する。

⑦ 情報管理主管課の実施者は、業務主管課にシステム廃止協議結果通知書を提示する。

⑧ 業務主管課の実施者は、協議結果が「可」となった場合にシステムの廃止を行う。

⑨ 業務主管課の実施者は、システムの廃止後、速やかに情報システム台帳における当該シス

テムの抹消登録を行う。

(5) 留意点

① システム廃止協議書の作成にあたっては、廃止時期、廃止に伴う作業、廃止の影響範囲等

について検討する必要がある。「運用の手引き」及び様式・サンプル集「システム廃止協議書」

を参照し、作成すること。

② システムの廃止にあたっては他機関及び他システムへの影響がないことに留意し、必要に応

じ関係機関を含めた協議を実施すること。

別表

72

別表

別表マネジメント区分

●新規導入・更改のマネジメント区分

区分定義

大

「中」に該当し、さらに以下のいずれかに該当する情報システム

(1)外部調達の場合に、初期開発費用の総見込み額、もしくは、運用・保守の開始にあたり 1 年間の

総費用が 7,000 万円以上のもの

(2)複数の部局が利用するか、庁内利用者が 200 名以上のもの

(3) その他、情報管理主管課長が指定するもの

中

外部調達の場合に初期開発費用の総見込み額、もしくは、運用・保守の開始にあたり 1 年間の総費

用が 100 万円以上で、以下のいずれかに該当する情報システム

(1)複数の課室等が利用するもの、または県民が直接利用するもの（情報公開用 Web サイトを除く）

(2)CORAL21 ネットワークに接続するもの

(3)保有する情報資産の重要性分類が A 及び B のもの

小「大」「中」に該当しないすべての情報システム

※総費用の多寡に関わらず、原則的にすべての情報システムが協議対象となる（詳細は、「2.2 対象情報システ

ム及びマネジメント区分(1)対象情報システム）」を参照）。

●対象に変更・追加を行おうとする場合のマネジメント区分（以下のように読み替える）

区分定義

中

以下のいずれかに該当する情報システム

(1)外部調達の場合に、変更・追加費用の総見込み額が 100 万円以上のもの

(2)CORAL21 ネットワークに接続するもので、利用端末及びネットワーク環境要件に変更が発生する

もの

(3) その他、情報管理主管課長が指定するもの

協議

対象外

「中」に該当しない情報システム

沖縄県情報システムガイドライン ·...

Documents