千葉市情報システム全体最適化指針ガイドブック（PDF：895KB）

千葉市情報システム
全体最適化指針ガイドブック
＜目次＞
第Ⅰ部本書の目的と使い方 ····························································································· 1
第１章情報システム全体最適化の基本的な考え方 ············································ 1
第２章情報システムのライフサイクル······································································· 2
第３章指針の基本構成と本書の使い方 ································································· 3
第Ⅱ部各段階における実務 ····························································································· 4
第１章企画段階 ··········································································································· 4
第２章開発段階 ········································································································· 12
第３章運用段階 ········································································································· 21
第４章調達段階 ········································································································· 25
資料編（別冊）
・協議書・企画構想書・調達基本計画書等の参考書式・作成例
・情報システム開発協議等の対象範囲早見表
・情報システム開発関連ドキュメント一覧表
平成２５年４月
総務局情報経営部業務改革推進課
（第Ⅰ部）本書の目的
第Ⅰ部本書の目的と使い方
総務局（業務改革推進課）では、本市の各部門の情報システムの導入及び管理運営における標
準的な手順、作業内容及び留意点を示し、もって情報システムの品質の安定やコストの適正化を図
るため、千葉市情報システム全体最適化指針（以下「指針」という。）を作成しました。
指針は、大規模な情報システムに対応するように作業やドキュメントなどの解説を掘り下げた記述
が多いため、情報量が大きくなり、また、専門的な内容も含んでいます。このため、様々な規模・性質
の情報システムを担当する多くの職員が常に手元で活用するには難しい面があります。
そこで、これらを補うため、指針の庁内への公開に際して千葉市情報システム全体最適化指針ガイ
ドブック（以下「本書」という。）を作成しました。本書は、指針の記載内容のうち、パソコン１台のものか
ら専用マシンルームを備えるものまで、大小を問わず各情報システムの実務担当者が知るべき知識、
実践すべき作業手順に内容を絞り込むとともに、情報システム導入に係る協議などの庁内手続きにも
焦点を当てて、その説明や書式例を拡充することで、事務処理マニュアル的に多くの事案で活用さ
れることを目指しています。
第１章情報システム全体最適化の基本的な考え方
「全体最適」は「個別最適」に対応する概念であり、本市における情報システムの全体最適とは、
様々な情報システムを組織全体として見て、十分な機能を低いトータルコストで実現する最適な状態
を指します。これは、以下が満たされたときに実現されるものです。
（１）リソースの有効活用
本市の情報システムにおいて、必要な財源及び人材などのリソースを的確に把握し、全体的
な視点により優先度の高いものから集中的にリソースの投入を行うなど、限りあるリソースを有効
に活用します。
（２）情報システムライフサイクルの適正化
本市の情報システムについて、目標や効果などを明確にするとともに、評価を行うことで、情
報システムライフサイクルを適正化します。
（３）機能の集約及びコスト抑制
複数の情報システムにおいて共通的に利用する機能を集約することで、重複による無駄を
防ぐとともに導入・運用などにかかるコストを抑制（削減）します。
これらの完全な実現に到達することは容易ではありませんが、個々の情報システムの導入及び管
理運営に際して、各所管課が全体最適の考え方を理解しながら手順や作業内容の標準化を進める
ことでその状態に近づけようとするのが、指針が示す「全体最適化」の基本的な考え方です。
1
（第Ⅰ部）本書の目的
第２章情報システムのライフサイクル
指針では、情報システムのライフサイクルを下のように４区分し、それぞれを「○○段階」と呼ぶこと
としています。
（情報システムのライフサイクル）
企画
開発
運用
調達
この図示からも分かるとおり、各「段階」は、必ずしも明確な境界や時間的順序を有しません。企画
段階の作業の一部がそのまま開発段階の事前作業でもあるなど、企画・開発・運用の各段階で少し
ずつ重なりが生じるほか、調達は他の段階の業務の中で発生します。
各段階の範囲は以下のとおりです。
（１）企画段階
企画段階は、情報システム開発に係る調査検討に始まり、方針を決めて予算化し、実施に
移すまでのプロセスを指します。これは、庁内の合意形成・意志決定プロセスと言い換えること
もできるので、事務手続きとしては、検討結果を書面化しＣＩＯ補佐監（総務局次長）に協議する
ことが中心となります。
なお、本書や協議手続きにおいて、「情報システム開発」とは、特に断らない限り次の全てを
含みます。市販製品を導入し業務に適用することも開発の一形態として扱うので、これは「プロ
グラム開発」よりもかなり広い概念である点に留意を要します。
情報システム開発に該当する業務
・新規の機器導入、機器の更新・構成変更
・新規のプログラム導入、プログラム追加開発（改修）
・外部の情報システムの利用開始や、方針見直し
（２）開発段階
開発段階は、意志決定に基づき実際の業務に着手してから、運用（利用者へのサービス提
供）開始までのプロセスを指します。具体的には、システム構築などに係る契約直後のプロジェ
クト立ち上げから、成果の履行確認・検査までの範囲が該当し、契約相手方に適切に業務を行
わせることが担当者の作業の中心となります。
（３）運用段階
運用段階は、導入された情報システムを運用するとともに、定期的にその情報システムの評
価を行うプロセスを指します。
2
（第Ⅰ部）本書の目的
（４）調達段階
情報システムのライフサイクル（企画・開発・運用の各段階）において実施される調達のプロ
セスを指します。指針が最も重視しているのは、企画段階の検討結果を受け開発段階に進む
際の調達です。事務手続き面では協議と契約事務が中心となるので、本書もそのように構成し
ています。（企画段階の記述との重複も生じます。）
このほか、運用事業者の調達や、企画段階で検討支援を行うコンサルティングの調達など、
プログラム開発や機器調達を要素に含まない調達プロセスもあります。
第３章指針の基本構成と本書の使い方
指針は、次の６部で構成されています。
・情報システム整備基本方針
・情報システム企画ガイドライン
・情報システム開発ガイドライン
・情報システム運用ガイドライン
・情報システム調達ガイドライン
・情報システム統一標準
このうち、全体の方向性や課題を提示している整備基本方針と、技術の進展・市場の動向に合わ
せた継続的な改訂を予定している統一標準は、比較的ボリュームが小さく、また、事務処理の手順に
直接関わる内容ではないため、本書では省略しています。
次ページ以降の本書の本論部分では、企画・開発・運用・調達の各段階に対応する章を一つずつ
割いて、プロセスフロー図や作業の概要説明を示しています。
項目は各章の中で概ね時系列順に配置しているので、以下のようにご活用ください。
①各章の冒頭のプロセスフロー図で、工程全体を把握
現在の位置や次に進むべき工程を確認します。
②プロセスフロー図に対応する各項目の説明を参照
フロー図の番号（１－（１）、１－（２）、…など）は、各章内の説明文の番号と対応します。
③詳細について、対応する各ガイドライン本体を参照
参照すべきガイドラインや他資料の対応箇所は、このように網・枠を付けて示します。
3
（第 II 部第１章）企画段階
第Ⅱ部各段階における実務
以下の各章では、各情報システムの所管課において、情報システムライフサイクルの各段階で実
施すべき作業の概要と留意点とを記述します。
第１章企画段階
企画
開発
運用
調達
企画段階では、情報システムの目的、必要性及び情報システムに求める機能などを明確にすると
ともに、開発スケジュールや投資効果の試算を行うといった作業を行います。各所管課においては、
このガイドブックに記述されている手順及び内容に従って作業を進めてください。
また、検討の際には、情報システム統一標準の内容を参照しながら作業を進めるとともに、適宜、
業務改革推進課の支援を受けながら、効率的かつ効果的に作業を進めてください。
企画段階でのプロセスフロー図は、次ページのとおりです。
4
（第 II 部第１章）企画段階
区分
業務改革推進課
所管課
1-(1)企画検討
予算要求までに提出
・問題点や解決すべき課題の整理
・更新などの場合、運用状況の検証
・開発手法、調達方法の事前検討
・トータルコストの把握
・専門家の活用（コンサル委託、ＲＦＩ）
1-(2)開発協議
開発協議書
企
画
段
階
1-(3)審査・回答
・ヒアリング
・資料修正追加など
・企画構想書
・積算資料
・情報セキュリティ実施案
・運用段階自己チェック調書など
回答(承認)書
（予算措置）
財政課との手続き
・（付帯条件など）
要求→査定、配当
システム開発の類型によって
以降の処理が異なる
プログラム開発を
伴わない機器調
達案件
プログラム開発と
機器調達を一括
契約する案件
P.26［4-(1)A］へ
（調達段階）
5
プログラム開発を
機器調達と別に契
約する案件
P.27［4-(1)B］へ
（調達段階）
（第 II 部第１章）企画段階
１－（１）企画検討
情報システムの開発（機器更新、プログラム改修などを含む）を検討するに当たり、解決しなけれ
ばならない課題を整理し、導入の目的及び必要性を明らかにします。
情報システムを適用して解決する課題の範囲、情報システムに求める機能（概要）、費用対効果
などを検討するほか、更新の場合は検討段階で現行システムを適切に評価し、次期システムに反
映させることが重要です。
それらとともに、当該情報システムで取り扱う情報資産を機密性・完全性・可用性の各観点から
格付けして、必要な情報セキュリティ対策を検討します。
参照：・企画ガイドライン P.3「企画段階の作業内容」
・運用ガイドライン P.49「運用段階の自己チェック」
・情報セキュリティポリシー（千葉市情報セキュリティ対策基本方針、千葉市情
報セキュリティ対策基準）
指針の各ガイドラインの構成上、企画段階で検討・決定すべき事項の範囲・内容は、企画ガイド
ラインだけでなく、内容の関連性に応じ開発ガイドラインや運用ガイドラインにも分散して記載され
ていますが、以下では、早期の検討が欠かせないもの（予算要求への影響が大きいものなど）を取
り上げて説明します。
企画段階での検討を要する事項
・開発手法の事前検討
・開発における調達方法の検討
・事業者のスキルの活用の検討（ＲＦＩなど）
ア開発手法の事前検討
情報システム開発、すなわち情報システムの業務への適用や既存情報システムの更新、変
更の必要が生じた際に取り得る対応は、大きく分類すれば以下の３つとなります。
①既に本市が持っているものを活用・流用する
②市場などに存在しているものを加工せず調達し、単体で、又は組み合わせることにより
情報システムを構築する
③市場などに存在するものを加工する、または、新たに作成して（直接あるいは事業者に
作成させて）、情報システムを構築する
開発手法については、情報システムの各構成要素に対して別々にこれらの違いを考えること
ができるので全体としては単純な話になりませんが、ソフトウエアに関して③の方針で対応する
のが、プログラム開発（狭い意味の「開発」）にあたり、指針の開発ガイドライン及び情報システム
統一標準では主にその手法の詳細が説明されています。
6
（第 II 部第１章）企画段階
参照：・開発ガイドライン P.3「開発手法の種類」
・情報システム統一標準 P.1「活用方法」、
・情報システム統一標準別紙２「情報システム統一標準条件表」
パッケージや外部利用の導入検討に関する留意事項
開発手法の検討時に特に問題となるのは、パッケージや外部利用のうち、カスタマイ
ズを行う場合です。上に示した３分類では、②をあえて「加工せず」と限定し、カスタマイ
ズは自己開発と同じ区分に含めましたが、それには理由があります。
パッケージ等を導入する場合は、カスタマイズ範囲を最小限に抑制することが非常に
重要で、データ形式や処理の流れに手を付けないことが基本となります。他システムと
連携させるため入出力機能だけ別プログラムを作って組み合わせるとか、データ形式を
左右しない範囲で印刷帳票や画面表示のレイアウトを変更するなどのカスタマイズは、
単純に導入コストとの兼ね合いで判断すべき場合もありますが、ソフトウエアの他の部分
に影響しない独立した改変であることが大前提となります。
一般市販品のパッケージに限らず、自治体向けに提供される業務用パッケージのソ
フトウエアも、ある程度のユーザ数がある製品ならば、法令改正への対応や技術水準の
向上を受けて、何らかのタイミングで開発事業者によりバージョンアップ品が提供される
ことが一般的です。ところが、本市の事務ルールに合わせたり、使い勝手を向上させる
などの理由でカスタマイズしていた場合、バージョンアップが容易に適用できず、国の
都合などの外部要因に振り回され、割高な改修が必要となる場合があります。このよう
に、カスタマイズはパッケージの利点を阻害することに等しく、総合的なコストで独自開
発より劣る結果すら招く場合もあります。
パッケージは「使えるものを（全体であれ一部であれ）変更せず使うもの」と割り切り、
検討初期の情報収集段階で、機能の充実度だけでなく、製品を構成するプログラム間
モジュール間の独立性やバージョンアップの有無・条件を把握することが望まれます。
また、外部サービスを利用する場合も同様です。
イ開発における調達方法の検討
開発に当たっての調達には、以下の事項を考慮に入れる必要があります。
①ハードウエアとソフトウエアの適切な更新サイクルは、一致しないことがある。ハードウ
エアは数年で入れ替えが必要だが、業務用プログラムは多くの場合、それより長い期間、
同じものを使うことを考えて導入する必要がある。
②パソコンなどの機器や市販プログラムは量産品であり、市場に競合品が存在している
状況においては、メーカーや契約相手を特定する理由が成り立たない。
7
（第 II 部第１章）企画段階
③プログラム開発は法令上の「製造の請負」にあたることが多いので市に帰属するのが
原則となる。
調達方法と予算要求に関する留意事項
プログラム開発を行い、その成果のソフトウエアを市の資産として管理していく場合
は、開発委託と機器調達を切り離す分離調達が原則となります。状況により両者を一契
約とすることもありますが（委託成果品の一部として機器を取得したり、逆に、プログラム
開発経費を賃借料に上乗せして支出するケース）、一般論として望ましい調達とは言え
ません。機器は通常、耐用年数などを考慮し計画的に更新しますし、現在のパソコンや
サーバは複数のメーカー・機種で同じプログラムの動作を見込めるので、新規導入時だ
けでなく、更新や台数追加の調達時も競争原理を重視しなくてはなりません。他方、プ
ログラム（特に、独自開発したもの）は数年で入れ替えるとは限りません。機器寿命より
長く使い続けることが多く、制度改正などによるプログラム改修は大抵、随意契約になり
がちです。
すなわち、プログラムと機器類とでは、更新周期も、追加発注時の業者選定の前提条
件も大きく異なるので、ある時点の調達を一本化すると、次の調達では問題が生じる可
能性があると言えます。一括調達にも、障害発生時の対応を一業者に任せられることな
どの利点はありますが、それは適切な運用設計など、別のアプローチで解決し得るの
で、一括調達を支持する決定的理由にはなりにくいものです。
開発ガイドラインでは、プログラム開発と機器調達の分離を当然の前提とした上で、さらに、
大規模なプログラム開発を年度などで分割発注する場合の考え方と留意点を示しています。
参照：・開発ガイドライン P.4「開発における調達の考え方」
調達方法（一括調達、分離調達）に関する留意事項
機器や市販プログラムを買うか借りるか、また、それらとプログラム開発（カスタマイズ
含む）を一括調達するか分離調達するかといった問題は、予算措置に直結します。いっ
たん決められた予算の変更は簡単ではありません。目・節の科目間の流用はまだしも、
単年度で支払う経費と複数年度に分けて支払う経費との垣根を超える変更は、余程の
理由がなければ財政局に承認されません。予算要求時に「この部分は賃借に含める」
「これは使用権の買い取り」などの判断を誤ると、その年度の実施を諦めて先送りせざる
を得なくなることもあります。
この問題は、新規導入の場合に注意するのは当然ですが、機器更新などのケースで
も同様です。また、現状で使っているプログラムの権利がどうなっているかなどの条件次
第で、選択すべき最適な判断が異なる場合もあります。
8
（第 II 部第１章）企画段階
ウ事業者のスキルの活用の検討（ＲＦＩなど）
情報システム開発の予算化を行う場合に、職員のみで条件を整理し、見積りを作成すること
は容易ではないことから、何らかの形で事業者に情報を求めることは有用です。
複数社の比較が可能な形で、事前提案・参考見積を均質に行うための手法がＲＦＩ（Request
For Information、情報提供依頼）の実施です。業者選定を前提に執行段階で行う事業者への
働きかけはＲＦＰ（Request For Proposal、提案依頼）と呼ばれますが、そちらは具体的な要件、
選定条件を固めた上で実施するものです。（入札通知もＲＦＰの一種です。）それより前の段階
で、企画検討の一環として行う予備的な調査がＲＦＩです。「書面による参考見積もり依頼」であ
り、予算要求前の実施が一つのタイミングとして考えられます。
情報提供依頼（ＲＦＩ）に関する留意事項
事業者に対し、口頭の連絡で「事前提案書」や「参考見積書」を徴することも行われま
すが、これにはいくつか問題があります。既存システムの運用受託者など、接触の多い
業者から偏って話を聞くと「囲い込み」前提の話になりやすく、最新の技術や市場の動
向をコスト削減に反映させる話になかなかなりません。他方、あまり接触のない業者だ
と、１回や２回呼んだ程度では、現実的な作業スケジュールなどの話は難しい面があり
ます。そのほか、提案活動に伴うコストを特定業者に集中して生じさせると、それを業者
はどこかで回収しようとするため、事前提案を丁寧に実施させ過ぎると当該事者の開発
コストが不透明になっていくという矛盾もあります。
参照：・企画ガイドライン P.13「情報提供依頼（ＲＦＩ）について」
前述の情報提供依頼（ＲＦＩ）以外にも、情報システム開発を進める上で外部専門家を活用す
る場合があります。例えば、開発着手前の調査分析をコンサルに実施させる委託や、開発業者
による設計書などの成果物が後の調達における競争を不当に妨げないか、別の事業者に点検
させる委託があります。後者は工事に伴う施工監理委託に近いもので、本市での実施例は少
なく、委託の予算も確保しにくい業務ですが、状況によっては一定の効果があります。
１－（２）開発協議
各所管課は、企画検討の結果を情報システム企画構想書（以下「企画構想書」という。）に整理
し、電子情報処理規程（第１３条第２項）に基づく所管課（局長）から総務局次長（ＣＩＯ補佐監）への
協議を実施します。
開発協議書の構成（例）
・協議書｛かがみ文：局長（○○課扱い）→ＣＩＯ補佐監（総務局次長）｝
・企画構想書
・システム構成図
9
（第 II 部第１章）企画段階
・経費の積算資料
・情報セキュリティ対策実施案
参照：・企画ガイドライン P.5「企画構想書の内容」
・資料１開発協議関係（参考書式及び作成例）
開発は、小規模なものはパソコンへの市販プログラムなどの導入から、大規模なものは複数年に
またがるプログラム開発、多数の端末機器導入まで、多岐にわたります。その性質や規模によって
協議などの手続きが不要な場合もありますが、指針の各ガイドライン及び本書で示す基本的な考
え方は、協議対象とならないケースにも当てはまるものです。
参照：・資料４情報システム開発協議等の対象範囲早見表
（備考）執行機関による取り扱いの違い
独自の電子情報処理規程を持つ部門（消防局、病院局及び教育委員会）では、手
続が執行機関内で完結する形式です。（部長→消防局長・病院局長・教育長）
しかし、全庁的な方針との適合性や経費の積算の適正化を含め、総合的な判断を部
門内のみで実施することは必ずしも容易でないため、業務改革推進課に意見照会等を
行うことで、協議と同様に取り扱うこととします。
１－（３）審査・回答
業務改革推進課は、所管課とのヒアリングなどを適宜実施し、企画段階における協議書（企画構
想書）の内容を審査します。審査に当たっては、以下に示す内容を踏まえて総合的に判断し、その
結果を所管課へ回答します。
・基本的な方針（システム概要など）、目的及び必要性
・実現可能性（実現方法、代替手段の可能性など）
・開発する情報システムの効果、目標
・開発を進めるに当たっての体制などの整備状況
・開発及び運用の経費
・全庁の計画及び方針との適合性
・その他、企画段階の審査に当たり必要と認められる事項
など
当該開発経費の予算化には、企画検討の結果が反映される必要があります。（必要に応じ業務
改革推進課・財政課の間で参考情報の交換を行いますが、基本的には、所管課において協議手
続きと予算手続きの整合性の確保に努めてください。）
10
（第 II 部第１章）企画段階
開発協議と予算措置の完了によって、当該情報システム開発のプロジェクトを実施に移すことが
可能になります。しかしながら、施行決定などの手続で仕様を確定し、契約を締結するまでの間は、
まだ開発内容に未確定部分が残っている場合もあり、その意味では企画段階が終わっていない状
況にあります。
企画段階から開発段階に進む過程で、要件や経費に係る精査の状況を再度審査（又は点検）
することになりますが、具体的には、調達段階（第４章）で整理・説明します。
参照：・資料４情報システム開発協議等の対象範囲早見表
なお、開発協議に対する回答に際して、その事案が複数部門の事務事業に影響する場合など、
必要に応じて「指定情報システム」に指定し、当該開発プロジェクトに係る委員会の設置や、進行
管理の結果報告を指示することとなります。（電子情報処理規程第１５条、同第１６条。）
11
（第 II 部第２章）開発段階
第２章開発段階
企画
開発
運用
調達
開発段階では、情報システムの開発作業を定められた手順で実施することにより、予定どおりの期
間と経費で構築することを可能とするとともに、信頼性、安全性、保守性など品質の高い情報システム
構築を目指します。各所管課においては、本書に記述されている手順及び内容に従うとともに、適宜、
業務改革推進課の支援を受けながら、効率的かつ効果的に作業を進めてください。
なお、本書は市職員を対象としていますが、開発事業者の開発技法に制約を与えるものではなく、
標準的な開発手法や手順、役割分担、プロジェクト管理方法を示すことにより、開発事業者とのコン
センサスを明確にして円滑なプロジェクト進行が図れるように活用されることを期待するものです。
開発段階でのプロセスフロー図は、次ページのとおりです。
なお、指針の開発ガイドラインは委託などによるプログラム開発を前提としており、本書も概ねそれ
に準じた説明を行っていますが、市販ソフトウエアを活用して職員が自らデータベースを構築するよう
な小規模な情報システムの単独開発においても、開発事業者と担当職員を適宜読み替えることで基
本的な概念や手順が当てはまるように記述しています。
12
（第 II 部第2章）開発段階
区分
業務改革推進課
所管課・開発事業者
(
1-(1)企画検討
・開発手法、調達方法の事前検討など
企
画
段
階
協議・回答
P.5及び
P.26-27
参照
（中略）
)
4-(4)契約手続き
(
)
調
達
段
階
報告受領、確認
4-(5)契約締結の報告
契約締結報告書
2-(1)プロジェクト計画
・契約書及び仕様書（写）
・プロジェクト計画書など
2-(2)プロジェクトの立ち上げ（キックオフ）
2-(3)設計
・機能設計、データ設計
・システム構成、セキュリティ方式
・プログラム仕様、テスト手順
・運用設計、移行計画など
開
発
段
階
(
2-(4)プログラム
製造
調
達
段
階
2-（5)機器調達
P.26［4-(1)A］へ
（調達段階）
2-(7)テスト
2-(6)運用計画
)
・単体テスト
・結合テスト
・総合テスト
・運用テスト
2-(8)運用開始の準備
・研修・教育、移行リハーサル
・マニュアル整備など
・ＣＨＡＩＮＳに接続する場合などは
情報システム課への協議
2-(9)運用開始の決定
［開発協議の回答時に指定する案件の場合］
2-(10)開発結果の報告
開発結果報告書
報告受領、確認
・運用段階自己チェック
調書の記載要領など
P.22［3-(1)］へ
（運用段階）
13
（第 II 部第２章）開発段階
２－（１）プロジェクト計画
発注仕様を確定して契約を締結することで、開発に係る法的な条件は確定しますが、プログラム
開発や機器の大量導入などは、契約して成果の納入を待つだけでは目的が達成されません。運
用開始までには本市と開発事業者それぞれに多くの作業が発生しますが、作業の全体をプロジェ
クトとして管理することが必要であり、開始時において、両当事者の間で、プロジェクトの目的、意義
及びシステム全体イメージを共有することが重要です。
そこで方針を示し、それを具現化するためのスケジュールや体制、役割分担、各工程の作業内
容と成果物、課題管理方法などを事業者に書面として提示させ、認識を一致させるプロセスを経る
ことが大切となります。
参照：・開発ガイドライン P.7「プロジェクトの立上げ」
なお、調達段階で協議（又は開発委託などの調達点検）を実施した場合は、その事案の契約締
結結果を業務改革推進課に報告しますが、プログラム開発の事案（賃借と一体契約である場合も
含む）においては、プロジェクト計画書を添付し、業務が正常に着手されたことを併せて報告しま
す。
参照：・本書 P.31「契約締結の報告」
２－（２）プロジェクトの立ち上げ（キックオフ）
プロジェクト計画書が調達目的に沿った内容となっているか評価・判断した上で、実際の開発工
程に進むこととなります。この作業は、開発ガイドラインの「主な確認ポイント」及び「プロジェクト計
画書の記載項目例」をチェックリストとして使用することで、遺漏なく実施できます。
参照：・開発ガイドライン P.9「プロジェクト計画書の記載項目例」
・開発ガイドライン P.11「プロジェクト計画書の評価及びプロジェクト開始判定」
判断の結果、承認となったところで、プロジェクト管理の責任者（以下本書では「プロジェクト管理
者など」といいます。）が関係者を招集し、目的意識を確認した上で、計画の承認とプロジェクト着
手を宣言します。また、プロジェクトの立ち上げ後も、工程の大きな節目は、必ずプロジェクト管理
者などが進捗状況を確認します。
参照：・開発ガイドライン P.8「プロジェクトにおける意識の共有化を図ること」
２－（３）設計
設計からテストまでの工程で生じる具体的な作業は、開発規模・開発手法によって異なります。
14
（第 II 部第2章）開発段階
業務用サーバを設置し、各クライアントをネットワークで結ぶ比較的大規模な情報システムは、基本
設計と詳細設計に工程を分割することが一般的ですし、各工程の中の具体的な作業になると、事
業者によって技法や用語までも異なることがあります。
開発ガイドラインでは、過去の大規模開発で多く採用されてきたモデルに沿って全体を説明し、
他の手法の特徴を補足する形の記述方法を採っています。
参照：・開発ガイドライン P.6「工程の定義」
・開発ガイドライン P.12「基本設計」
・開発ガイドライン P.16「詳細設計」
・開発ガイドライン P.22「プログラム設計」
以下では、開発手法や規模によらない共通的な事項について記述します。
ア要件定義の確認・最終確定
要件定義は入札・契約前に発注者が作成して事業者に示すものであり、調達仕様書にも主
要な要素として反映されるものですから、本来これを契約後に変更することはありません。しか
し、実際に事業者に取り組ませると、曖昧な記述などが発見されることがあります。これをプロ
ジェクト着手直後の段階において市と事業者の双方で洗い出し、必要な部分には明確化のた
めの修正を加えます。
要件定義を最終確定しないまま設計以降の工程を進めると、「作業の後戻りが発生する」、
「成果品を受け入れる段階になって条件変更などの交渉（協議）が発生する」などの問題を引き
起こす恐れがあることから、この作業は早期に徹底して行う（行わせる）ことが求められます。
参照：・調達ガイドライン P.4「システム要件定義書」
・調達ガイドライン P.7「調達仕様書の項目例」中の「業務要件」、同 P.8「システ
ム要件」
要件定義などに関する留意事項
要件定義の確定は本来、企画段階から開発段階に進む前の調達に際して行う作業
ですが、開発段階に入ってから何度も作業を後戻りする事例が見受けられます。やむを
得ない理由により契約締結後に要件定義を見直す場合においては、前の段階に立ち
戻り、改めて要件をしっかり固める必要があります。
その際、要件の明確化といえる範囲を超えて、明らかな変更になってしまう場合は、
変更契約を締結せざるを得ません。
イ仕様凍結
設計を終えて次のステップに進む段階は、開発工程の中で特に大きな節目であり、ここでプ
ログラムの機能・動作などの仕様が確定、凍結されます。
15
（第 II 部第２章）開発段階
これ以降に機能・動作などを変更する場合は、遡って設計にも変更を加えなければなりませ
ん。開発手法としてウォーターフォールモデルを採用している場合はもちろん、試作から始める
プロトタイプモデルや既存プログラムに手を加えるパッケージ活用であっても、設計完了の宣言
後に前の工程に戻ることはありません。また、大規模な開発では設計以降の工程が本格的な
分業となり（プログラミング作業の分担のほか、運用計画策定やデータ移行準備、市の機器調
達の支援など、設計完了後はプログラム完成を待たずに同時進行で作業し得る工程が多数あ
ります。）、これ以降の変更は広範囲の作業をストップ、後戻りさせる可能性があります。
開発の規模に関わらず、設計の変更が工期・工数に与える影響は無視できず、遅延や品質
低下、契約変更に直結することもありますので注意が必要となります。
参照：・開発ガイドライン P.57「スパイラルモデルの開発における特徴」
・開発ガイドライン P.65「パッケージ活用による開発における特徴」
ウ運用設計
情報システムの構築は、「プログラムが組まれたらそれで終わり」「パソコン等が設置されたら
それで終わり」とはなりません。運用の手順を決めたり、調書やツールを用意するのが運用開始
より前（開発段階）の作業であることは自明ですが、その基本的な考え方や条件の整理は、設
計工程の一部として行います。例えば「管理端末へのエラー表示」「自動的なバックアップ作成」
のような機能を考えれば分かるとおり、運用条件はプログラムや機器構成にも影響するので、こ
の工程で検討し、中間成果である設計書に反映させる必要があります。運用ガイドラインに記
述している作業の中にも、開発事業者が実施するものが多く存在します。
参照：・開発ガイドライン P.15「基本設計書の構成要素」中の「運用設計」
・開発ガイドライン P.21「詳細設計書の構成要素」中の「運用設計」
・運用ガイドライン（P.1「運用ガイドラインの役割」ほか全般）
エ移行計画・移行設計
機器やプログラムを入れ替える場合は、業務データの移行、利用者登録の移行など、様々
な作業が必要です。データ変換に専用のプログラムを用意するケースもありますし、空白期間
の許されない業務の場合には、新旧システムの並行運用期間を設けることもあります。（新旧の
機器を動かす場合は、設置場所や電源確保、障害対応の手順なども解決しなければなりませ
ん。）
これらに係る方針を後から変更すると、プログラム製造やテストの手順、機器調達の日程など、
別工程の内容に予想外の大きな影響を与える可能性があるので、これらは仕様凍結前に専門
スキルを持つ技術スタッフにドキュメント化させなければなりません。従って、これはプログラム
設計などとは若干異なりますが、設計工程の一要素として確実に実施すべきものです。
16
（第 II 部第2章）開発段階
参照：・開発ガイドライン P.29「移行」
２－（４）プログラム製造
この工程で市職員の行うべき作業は、基本的には何もありませんが、進捗状況の把握は怠らな
いようにします。
なお、「２－（７）テスト」のうち単体テストは、製造した結果の直接的な確認にあたるので（単体テ
ストがクリアできないと、製造が終わったものとして認められない。）、業者の経費積算資料や、工程
管理のスケジュール表では、単体テストを製造工程の一部とする整理が多くみられます。
参照：・開発ガイドライン P.23「製造／単体テスト」
２－（５）機器調達
企画段階でも触れたとおり、一般的にプログラム開発と機器調達は分離して行うことが望ましいと
言えます。その場合、機器の構成や機能・性能、ＯＳなどの種類・バージョン、ネットワーク機器の条
件などは、開発事業者から資料を提出させて、市の作成する調達仕様書に反映させることになりま
す。
なお、調達に係る手続きなどは、段階（第４章）で記述します。
参照：・本書 P.７「開発における調達方法の検討」
２－（６）運用計画
運用計画は、指針ガイドラインの構成上は運用ガイドラインの内容となっていますが、実際にそ
の策定作業を行うのは、運用事業者ではなく開発事業者です。時期的にも、運用の体制や手順を
決めたり、必要なドキュメント類を揃えるのは、運用開始前に済んでいなければ業務を開始すること
ができません。
大規模な情報システム、すなわち、開発費や機器保守費と別にシステム運用経費が必要になる
情報システムでは一般に、開発と運用の発注は別のものとして整理します。（契約上、同一事業者
や系列事業者に発注する場合でも、開発と運用とでは求められるスキルが異なり、事業者内で同じ
人間に担当させる必然性がないからです。）
運用に係る経費（委託料など）の事前の積算は、ここで算定要素が出揃います。開発スケジュー
ルによりますが、一般的には、これを受けて当該委託の予算要求を行うことになります。
なお、小規模な情報システムでは委託などを伴わず直接運用することもありますが、その場合も、
運用の体制や手順を決めるのは開発段階の中の一工程として整理されます。
参照：・運用ガイドライン P.4「運用管理」
・本書 P.2１「運用段階」、P.2３「運用の調達」
17
（第 II 部第２章）開発段階
２－（７）テスト
テストには開発事業者が行うテストと、発注側の市職員が行うテストの両方があり、開発ガイドライ
ンでは、単体テスト、結合テスト、総合テスト、運用テストの４つに分類しています。
ア単体テスト
先に「２－（４）プログラム製造」で触れましたが、単体テストは製造工程の一部として整理する
ことも多くあります。ある程度以上の規模を持つプログラムは、小さなプログラムの集合体として
作成する手法が常用されています。
単体テストでは発注者（市職員）の具体的な作業は発生しません。発注者（市職員）は、事業
者に対する進捗管理を実施します。
参照：・開発ガイドライン P.23「製造／単体テスト」
単体テストに関する留意事項
単体テストは、機械装置に喩えると、部品を作って全体を組み立てるようなものです
が、その検査の実施責任や費用の流れを整理する際には、装置の性能の検査と一緒
にするよりも、部品の話は部品だけで完結させたほうが多くの場合に合理的であると言
えます。これと同じように、単体プログラムが設計どおり動くかどうか確認する作業は、そ
の製造の一環として扱うほうが、経費積算やプロジェクト管理の点においても合理的と
言えます。
イ結合テスト
結合テストは、小さなプログラムを合わせたプログラムが全体として設計どおり動くかどうかを
開発環境又はテスト用環境の中で検証する工程です。設計を基本設計・詳細設計・プログラム
設計に分類する場合、結合テストは詳細設計に対応し、それが正しく実現されているか確かめ
るものですから、プログラムの品質確保上、特に重要な工程です。
その性質上、結合テストも、それ自体は市職員が直接作業を実施したり、立ち会ったりする
必要のない事業者内部の工程ですが、市としての関わりは、単なる日程上の進捗管理だけで
は不十分であり、テストの手順や使用するパターン、不具合発見時の対応などについて、事
前・事後の報告を受け、事業者が行っている作業の中身を把握する必要があります。
参照：・開発ガイドライン P.25「結合テスト」
ウ総合テスト
総合テストは、プログラムのテストとしては、最終テストとなります。
テスト環境は原則として本番用の動作環境を使用します。（本物の本番環境の使用が許可さ
れず、概ね同等の動作が見込まれる疑似本番環境を使う場合もあります。）総合テストでは、使
18
（第 II 部第2章）開発段階
用するデータも、単なるモデル的なパターンだけでなく、本番で想定している件数を処理したり、
滅多に存在しないレアケースも含めた処理を試します。従って、本物のデータを抽出できる場
合は、それを元にしたデータを使って（ただし、個人情報を伏字に変換するなど、情報セキュリ
ティ対策上の問題をクリアした上で行うことが大前提となります。）、全ての機能を検証します。
他システムや外部との連携もテスト対象となるので、本物の他システムと接続するか、それが無
理な場合には、代わりになるダミー入出力の機構やデータを用意します。
総合テストは上述のとおり、本番環境や他システム連携の調整などがあるため、テストそのも
のは事業者が実施するのものですが、結合テストまでとは異なり市職員が関与する必要があり
ます。規模や所要時間にもよりますが、事業者から書類報告を受けるだけでなく、現地で立ち
会うこともこの工程から発生する場合があります。
参照：・開発ガイドライン P.37「総合テスト」
エ運用テスト
プログラム自体は完成している前提で仮の引き渡しを受け、それを市職員が実際に操作して、
本当に使えるか、問題が残っていないか確認する工程です。開発事業者の支援は必要ですが、
市が自ら計画し実施するもので、使用する環境やテストデータは当然、本番用又はそれに限り
なく近いものが必要となります。
この工程は、テストとは言っても、既に運用準備に近いものであり、切れ目なく運用準備に突
入していくことが考えられます。所管課の開発担当者だけでなく、実際の本番ユーザとなる予
定の複数の職員に使わせることや、運用テスト期間を長めに取って、その一環として移行のリ
ハーサルを行うことなども必要となります。
参照：・開発ガイドライン P.42「運用テスト」
２－（８）運用開始の準備
上述のとおり、運用テストと、（テスト以外の）運用開始の準備との間には必ずしも厳密な線引き
がありません。（フロー図で「運用テストが先」、「運用開始の準備が後」としているのは、あくまで便
宜的な表示です。）
準備項目としては、利用者への教育・研修や、ドキュメント類の最終的な整備などが挙げられま
すが、これらは運用テストを行いながら準備あるいは実施することが考えられます。また、ＣＨＡＩＮＳ
と接続したり、所管課のパソコンをＣＨＡＩＮＳに収容しクライアントとして使用する場合はＣＨＡＩＮＳ
利用要綱による手続き（情報システム課長との協議）が必要であり、当該接続や収容を進めてから
でなければ運用テストが十分に行えない場合もあります。
したがって、この段階で実施する項目や順序について、スケジュールを組み立てるのが「２－（１）
プロジェクト計画」の重要な要素ですし、そこに変更が生じた場合は、プロジェクト管理者などがそ
れを的確に把握しなければなりません。
19
（第 II 部第２章）開発段階
参照：・開発ガイドライン P.45「システム切替」
・開発ガイドライン P.48「教育・研修」
・開発ガイドライン P.49「各種マニュアル作成」
・ＣＨＡＩＮＳ利用要綱第８条、同第１８条及び「ＣＨＡＩＮＳ接続ガイドライン」
２－（９）運用開始の決定
運用開始に向けた準備が整ったら、プロジェクト管理者などは改めて関係者を招集し、運用開
始を決定します。この場合の関係者は、基本的にはプロジェクト立ち上げ時の関係者の会議と同じ
範囲になる筈ですが、運用の関係課などに範囲が広がることはあります。また、開発協議の回答で
指定した「指定情報システム」の場合は業務改革推進課長又はそれに代わる職員が開発委員会
のメンバーになるため、その決定に際しては、関係課の一つとして業務改革推進課の意見も吸い
上げて頂くことになります。
参照：・開発ガイドライン P.47「サービス運用開始判定」
２－（１０）開発結果の報告
指定情報システムにおいては、サービス開始（カットオーバー）を確認した後に、開発結果の報
告を要しますが、併せて、運用段階自己チェックシートを作成し、業務改革推進課に報告すること
となります。
参照：・運用ガイドライン P.49「運用段階の自己チェック」
20
（第 II 部第３章）運用段階
第３章運用段階
企画
開発
運用
調達
運用段階では、情報システムを利用し、導入目的を享受するために、構築された情報システムを正
常に運転し、サービスの提供を行います。情報システムのライフサイクルにおいては、最後のプロセス
にあたりますが、構築されたシステムを複数年にわたり利用することとなるため、最も長いプロセスとな
ります。
情報システムは業務を遂行するための手段として重要な位置付けを担っていることから、情報シス
テムが利用できない事態は、住民サービスの提供にも影響が及ぶこととなります。常に円滑なサービ
スを提供するため、システム運用に関わる関係者は適正な運用を行うことが求められます。
運用ガイドラインは、その実現に有効と考えられる体制や実施事項など、運用における参照モデル
を示したものです。これは、必ず実施しなければならない事項を規定しているものではなく、システム
運用の検討に参考となる情報を掲載しているものです。
各所管課の取り組みとしては、運用ガイドライン、情報システム統一標準及び本書の内容を、それ
ぞれの情報システムの運用方法の検討に参考として活用して頂くこととなります。
運用・保守に関する留意事項
運用ガイドラインを活用する場合においては、開発と運用の区別を明確にすることが
欠かせません。各情報システムの「運用委託」などの契約を結ぶ際に、プログラム改修
のうち比較的小規模なものを、その委託の対象業務に含めている場合があり、予算の
確保や執行の都合からやむを得ない側面もあると考えられますが、運用ガイドライン及
び本書の中では、プログラム仕様の改変は、どれほど小規模なものであっても（予算の
要求内容や契約方法、開発協議の要否などに関わらず）、全て開発に該当するものと
して整理しています。一方、確定しているプログラム仕様を変えず、その仕様の範囲内
で業務データやテーブル化されている変数を書き換える作業は、運用に含まれます。こ
の区別を念頭に置いてください。
運用段階でのプロセスフロー図は、次のとおりです。
21
（第 II 部第3章）運用段階
区分
業務改革推進課
所管課・開発事業者・運用事業者
2-(3)設計
(
・運用設計など
開
発
段
階
P.13参照
・運用設計等
2-(6)運用計画
)
(
（中略）
3-（1)運用の調達
［開発協議の回答時に指定する案件の場合］
2-(10)開発結果の報告
)
調
達
段
階
P.28［4-(1)C］へ
（調達段階）
開発結果報告書
報告受領、確認
・運用段階自己チェック
調書の記載要領など
3-(2)運用プロセス
ア運用管理
イ運用サポートプロセス
・事象管理
・問題管理
・変更管理など
運
用
段
階
ウサービス提供プロセス
［別途、個別指定する情報システムの場合］
3-(3)自己チェックの実施
3-(3)自己チェック結果の定期報告
自己チェック結果報告書
報告受領、確認
・運用段階自己チェック調書
・運用コストに係る資料など
（
運
用
実
務
へ
の
フ
ィ
ー
ド
バ
ッ
ク
）
3-(4)自己チェック結果の反映
（
フ更
ィ新
ー・
ド変
バ更
ッへ
クの
）
（次年度予算へのフィードバック：
財政課への予算要求）
P.5［1-(1)］へ
（企画段階）
22
（
次
回
の
運
用
の
調
達
へ
の
フ
ィ
ー
ド
バ
ッ
ク
）
（第 II 部第３章）運用段階
３－（１）運用の調達
開発段階の「２－（６）運用計画」で決めた運用の体制、手順などに合わせて、契約の範囲、方法
を決定します。
また、各所管課において適切な調達を実施することとなります。
参照：・運用ガイドライン P.4「運用管理」
・本書 P.17「運用計画」
・本書 P.２５「調達段階」、Ｐ．２８【フロー図４－Ｃ】
３－（２）運用プロセス
情報システムの運用に関するプロセスとその作業項目は、次の内容に分類されます。これらの各
プロセスは、必ずしも時系列的な順序関係が付けられるものではなく、同時的、重層的に実施され
ることになります。また、概念的には全ての情報システムに対して各プロセスが存在すべきですが、
具体的にどれを委託の対象として、どれを職員が直接行うか、どれを書面化するかなどは、各情報
システムの規模や重要性により、ケース毎に判断することになります。
ア運用管理
情報システムを運用し、求められる機能をユーザに提供するために必要なオペレーションな
どの作業を行います。
イ運用サポートプロセス
日々寄せられる情報システムに関するユーザからの要求に応え、業務のサポートを行うプロ
セスであり、さらに、以下の内容に分類することができます。
・構成管理：情報システムの現状に関連する情報を管理し、運用管理に必要な
情報を提供します。
・事象管理：情報システムの運用において発生するさまざまなトラブルなどの事
象について、事象の発生から解決までのライフサイクルを管理します。
・問題管理：発生した事象の原因を追究し、根本的な解決を図るための対応を
行います。
・変更管理：情報システムに対して実施する変更について、変更プロセスの管
理を行います。
・リリース管理：情報システムへの変更をユーザに提供するために、ユーザが利
用する環境へ反映する作業を管理します。
ウサービス提供プロセス
業務やサービスなどの目標を達成するために、情報システムに関する機能やサービスの品
質を継続的に提供するとともに、改善を図るプロセスであり、さらに、以下の内容に分類すること
23
（第 II 部第3章）運用段階
ができます。
・稼動管理：情報システムの機能やサービスを適正にユーザに提供するために、
情報システムの性能を確保します。
・可用性管理：情報システムの運用において、機能やサービスを継続して提供
します。
・セキュリティ管理：情報システムの運用において必要なセキュリティ対策を行
います。
・災害対策管理：災害などの不測の事態が発生し、システム停止等の恐れがあ
る場合の対応を行います。
・サービスレベル管理：情報システムにおいて提供される機能やサービスを、Ｓ
ＬＡ（Service Level Agreement、サービスレベル合意書）などによって一定の水
準で確保します。
参照：・運用ガイドライン P.3「システム運用に関するプロセス」
３－（３）自己チェック結果の定期報告
情報システムが、その導入効果を発揮し続けるためには、定期的な評価と改善、そして目標の
再設定を続けることが必要です。これは「Ｐｌａｎ → Ｄｏ → Ｃｈｅck → Ａｃｔion」のサイクルとして
示され得るもので、考え方の枠組みは、良く知られている「品質マネジメントシステム（ＩＳＯ９００１）」
や「環境マネジメントシステム（ＩＳＯ１４００１）」と同じです。
参照：・運用ガイドライン P.49「運用段階の自己チェック」
３－（４）自己チェック結果の反映
自己チェックの結果は、運用実務、次回の運用予算や契約、情報システムの更新・変更のそれ
ぞれについて検討する際の材料となります。
また、担当者の人事異動に伴う引き継ぎ資料や、更新・変更を行う際の開発協議の資料として使
用することも有用と考えられるので、各情報システムの所管課においては、自己チェックを記録して
残すよう努めてください。
なお、運用を管理する所管課の担当者が運用上の問題点を記載、分析することが自己チェック
調書の主たる要素なので、一般ユーザの立場で情報システムの機能の改善について書くものでは
ない点には、留意が必要です。
参照：・運用ガイドライン P.53「目標の達成状況、運用の取組に関する考察と今後の
対応」等
24
（第 II 部第4章）調達段階
第４章調達段階
企画
開発
運用
調達
情報システムに係る調達を行う際に、構築する情報システムの内容を明確化して発注者側の要求
を受託者側に的確に伝え、適正な内容と価格でシステム調達を行うために必要な作業及び手順を示
すものです。調達の流れは、調達方式によって異なりますが、本書に記述された手順は、情報システ
ムの開発、情報システムに必要な機器類の新規調達や機器更改における調達、運用事業者の調達、
企画の支援を行うコンサルティングの調達など、さまざまな調達においても適用が可能なものです。
各所管課においては、本書に記述されている手順及び内容に従って作業を進めることとします。ま
た、検討の際には、情報システム統一標準の内容を参照しながら作業を進めるとともに、適宜、業務
改革推進課の支援を受けながら、効率的かつ効果的に作業を進めてください。
調達段階でのプロセスフロー図は、次ページ以降、３種類に分けています。
４－Ａ機器調達（プログラム開発と一括で契約する場合を含む）
４－Ｂプログラム開発などの調達（機器調達と一括で契約する場合を除く）
４－Ｃその他の調達（運用委託の調達、コンサルティング委託の調達など）
25
（第 II 部第４章）調達段階
【４－Ａ：機器調達（プログラム開発と一括で契約する場合を含む）】
区分
業務改革推進課
所管課
システム開発の類型によって
このフローへの移行ポイントが異なる
（
企
画
段
階
・
開
発
段
階
）
プログラム開発を
機器調達と別に契
約する案件
P.13［2-(5)］から
（開発段階）
プログラム開発を
伴わない機器調
達案件
プログラム開発と
機器調達を一括
契約する案件
P.5［1-(3)］から（企画段階）
※開発協議に対する審査・回答
4-(1)A 調達計画
・積算の精査
・機器仕様書案の作成
・契約方法等の確認
4-(2)A 買入れ等協議
買入れ等協議書
4-(3)審査・回答
調
達
段
階
・ヒアリング
・資料修正追加など
回答書
・機種選定について
・積算について
・（付帯条件など）
・調達基本計画書
・積算資料
・セキュリティ対策実施案
・機器仕様書案など
4-(4)契約手続き
・施行決定
・入札
・支出負担行為
4-(5)契約締結の報告
契約締結報告書
報告受領、確認
（
開
発
段
階
）
・契約書・仕様書（写）
・機能比較表
・プロジェクト計画書など
プログラム開発を
機器調達と別に契
約する案件
P.13［2-(7)］へ
※（総合）テスト
26
（それぞれ
元の流れに
戻る）
プログラム開発を
伴わない機器調
達案件
プログラム開発と
機器調達を一括
契約する案件
P.13［2-(1)］へ
※プロジェクト計画
（第 II 部第4章）調達段階
【４－Ｂ：プログラム開発などの調達（機器調達と一括で契約する場合を除く）】
区分
業務改革推進課
所管課
プログラム開発を機器調達と別に
契約する案件
（
企
画
段
階
）
P.5［1-(3)］から（企画段階）
※開発協議に対する審査・回答
4-(1)B 調達計画
・積算の精査
・要件定義書の作成
・契約方法等の確認
［開発協議の回答時に指定する案件の場合］
4-(2)B 調達時点検の依頼
調達点検依頼書
調
達
段
階
4-(3)審査・回答
・調達基本計画書
・積算資料など
・ヒアリング
・資料修正追加など
回答書
4-(4)契約手続き
・積算について
・（付帯条件など）
・施行決定
・入札
・支出負担行為
4-(5)契約締結の報告
契約締結報告書
報告受領、確認
・契約書・仕様書（写）
・機能比較表
・プロジェクト計画書など
（
開
発
段
階
）
P.13［2-(1)］へ
（開発段階）
27
（第 II 部第４章）調達段階
【４－Ｃ：その他の調達（運用委託の調達、コンサルティング委託の調達など）】
区分
運
用
段
階
等
）
（
開
発
段
階
・
業務改革推進課
所管課
P.13［2-(6)］から
（開発段階）
P.22［3-(4)］から
（運用段階）
その他
（適宜）
4-(1)C 調達計画
調
達
段
階
・積算の精査
・仕様書案の作成
・契約方法等の確認
4-(4)契約手続き
・施行決定
・入札
・支出負担行為
（
運
用
段
階
等
）
P.22［3-(2)］へ
（運用段階）
28
その他
（適宜）
（第 II 部第4章）調達段階
４－（１）Ａ / ４－（１）Ｂ / ４－（１）Ｃ調達計画
各所管課は、機器賃借、プログラム開発委託、システム構築に係る一契約毎に、調達計画を策
定します。
調達計画のポイント
・企画検討結果（企画構想書の内容）との整合性
・機器調達の場合（４－（１）Ａ）：機能・性能の適正さ
・プログラム開発の場合（４－（１）Ｂ）：要件定義の適正さ
・契約方法の確認
・納入までの日程及び体制の確認
・経費の精査
参照：・調達ガイドライン P.1「調達段階の作業内容説明」
機器の調達やプログラム開発を含まない調達（運用委託やコンサルティング委託などの契約）で
は業務改革推進課への協議や調書の提出は要しませんが、各所管課は、プログラム開発委託、
機器賃借等、システム構築に係る一契約毎に、調達計画を策定します。
４－（２）Ａ買入れ等協議
各所管課は、調達計画を情報システム調達基本計画書（以下「調達基本計画書」という。）に整
理します。電子計算機（≒コンピュータ装置）の買入れ又は借入れ（以下「買入れ等」という。）を行
う場合は施行決定・執行伺いなどの財務手続きに先立ち、これを用いて、電子情報処理規程（第２
１条）に基づく所管課（局長）から総務局次長（ＣＩＯ補佐監）への協議を実施します。
なお、歳出予算科目に関わらず、対価を伴う機器の取得は買入れなどに該当するので注意を要
します。（調査委託等の成果品の一部として機器を納入、市に帰属させる契約などの場合。）
買入れ等協議書の構成（例）
・協議書｛かがみ文：局長（○○課扱い）→ＣＩＯ補佐監（総務局次長）｝
・調達基本計画書
・機器調達仕様書（案）
・システム構成図（企画段階から精査を進めたもの）
・経費の積算資料（同上）
・情報セキュリティ対策実施案（同上）
参照：・資料２買入れ等協議関係（参考書式及び作成例）
・資料４情報システム開発協議等の対象範囲早見表
29
（第 II 部第４章）調達段階
（備考）執行機関による取り扱いの違い
独自の電子情報処理規程を持つ部門（消防局、病院局及び教育委員会）の手続き
は、協議の形式ではなく機種選定に係る調査審議依頼の形式となります。（審査の過程
における実質的な扱いは協議と同等です。）
４－（２）Ｂ調達時点検の依頼
電子計算機の買入れなどを伴わないプログラム開発委託などの調達は買入れ等協議の対象で
はありませんが、新規開発や大規模な開発に関しては、企画検討結果（企画構想書の内容）との
整合性や、経費積算、日程・体制などについて、所管部門の判断に加えて、業務改革推進課で必
要に応じ点検を実施します。（点検の必要性が前段階の開発協議の際に明らかになっている案件
に対しては、開発協議に対する回答時に、その旨を条件として付記します。）
調達点検依頼書の構成（例）
・点検依頼書（かがみ文：課長→業務改革推進課長）
・調達基本計画書
・システム構成図（企画段階から精査を進めたもの）
・経費の積算資料（同上）
・情報セキュリティ対策実施案（同上）
参照：・資料４情報システム開発協議等の対象範囲早見表
４－（３）審査・回答
業務改革推進課は、協議書（調達基本計画書）又は点検依頼書の内容を審査し、以下の各点
を踏まえて、機種選定の妥当性など、当該調達の考え方の適否を総合的に判断し、回答します。
・開発協議で承認したとの整合性（相違がある場合はその理由）
・機種選定の考え方
・機能・性能水準
・経費の積算（予算額や更新前の機器と比較して精査されているか）
・目的達成可能な日程及び体制が組まれているか
・情報セキュリティ対策が調達仕様に適切に反映されているか
など
協議に対する審査の過程で、案件の規模・性質により必要と判断した場合（機種等を特定して
調達しなければ必要な機能が実現できない場合など）には、電子計算機機種選定委員会を開催し、
所管課にも説明者として出席を求め、調査審議を行います。
30
（第 II 部第4章）調達段階
電子計算機機種選定委員会の構成
・委員長
CIO 補佐監（総務局次長）
・委員
業務改革推進課長、情報システム課長
財政課長、管財課長、契約課長
４－（４）契約手続き
施行決定や入札の通知・公示、支出負担行為などの契約事務は、契約課の示している通知類
や手引きに従って適切に実施することとなりますが、それらと合わせ、調達ガイドラインも適宜、参
照してください。（主に、公募プロポーザルや総合評価落札方式など、事業者の提案を評価する調
達方法を採用する場合。）
参照：・調達ガイドライン P.９「提案依頼書の作成」、Ｐ．１０「提案書評価基準の作成」
等
４－（５）契約締結の報告
電子計算機の買入れなどの契約を締結した後は、電子情報処理規程（第２３条）に基づく報告を
行います。プログラム開発委託などのうち、調達時点検の依頼・回答を経て契約したものについて
も、これに準じて報告します。
契約締結報告書の構成（例）
・契約締結報告書
（かがみ文：局長→ＣＩＯ補佐監。委託等の場合は課長→業務改革推進課長）
・入札調書の写し
・契約書の写し
・機能比較表
・プロジェクト計画書
プロジェクト計画は本来、開発段階に属するものですが、事業者との契約締結後の最初期の段
階で生じる代表的な中間成果物であり、プログラム開発や機器の大量導入などの調達においては、
業務の立ち上げに不可欠なものでもあります。契約締結報告書への添付により、業務が正常に着
手されたことを業務改革推進課にも提示することとなります。
参照：・資料３契約締結報告関係（参考書式及び作成例）
31
32

Download Report