デジタル社会推進実践ガイドブック DS-120

デジタル・ガバメント推進標準ガイドライン
実践ガイドブック2023 年（令和５年）3 月 31 日
デジタル庁

〔ドキュメントの位置付け〕
Informative
参考とするドキュメント〔キーワード〕ＩＴマネジメント、プロジェクトの管理、予算要求、サービス・業務企画、要件定義、調達、設計・開発、サービス・業務の運営と改善、運用及び保守、システム監査〔概要〕
デジタル・ガバメント推進のためのサービス・業務改革並びにこれらに伴う政府情報システムの整備及び管理について、プロジェクトを運営する職員の視点に立って実務的なノウハウ、実例、ひな形等を記載した標準ガイドラ
イン参考文書。

i

改定履歴
改定年月日
2023年3月31日

改定箇所
第３編第２
章

第３編第３
章

第３編第４
章

第３編第５
章

第３編第６
章

改定内容
・クラウドサービスの契約内容の変更等に伴い想定外のコストが発生するリスクに関する記載を追加
・クラウドサービスの契約方法により、リスクが顕在化するタイミン
グが異なる旨の記載を追加
・クラウドサービス利用における為替変動リスクに関する記載を追加
・受容せざるを得ないリスクとその対応方法の例示に関する記載を追加・政府情報システム整備における費用対効果の考え方に関する記載を追加
・プロジェクトの立ち上げの承認時に手段の妥当性を確認するための工夫に関する記載を追加
・費用対効果は、会計検査院の検査でも用いられている３Ｅ（経済性、効率性、有効性）の観点で確認することが重要である旨の記載を追加
・データ移行が伴う情報システムの構築では、既存情報システムのデータの抽出自体に費用がかかる留意点に関する記載を追加
・機能改修の特性を踏まえた効率的なテストの実施に関する記載を追加・事業者への見積り依頼に関する記載を修正
・クラウド環境を従量課金の価格体系で利用する際の留意点に関する記載を追加
・クラウドサービス事業者をクラウドサービス提供者に修正
・効果の算定における例示を追記
・３Ｅの観点を踏まえて費用対効果を検討するための工夫に関する記載を追加
・ウェブアクセシビリティ導入ガイドブックに関する記載を追加
・一般的なベンダーロックイン防止の対応例の記載を追加
・テスト計画に関する記載を追加。また、表5-34「テストに関する要件」にテスト実施主体を追加
・最終的な秘密文書の定義の判断は、行政文書の管理に関するガイド
ラインを参照の上、決定する旨を追記
・オープンソースソフトウェアの特徴に関する記載を追加
・ソフトウェアライセンスの引継ぎに関する記載を追加
・表5-38「引継ぎ事項」の記載を修正
・クラウドサービスやパッケージ製品の導入について、システム方式を決定する上での留意点に関する記載を追加
・ウェブアクセシビリティ導入ガイドブックに関する記載を追加
・クラウドサービスプロバイダをクラウドサービス提供者に修正・クラウドサービス事業者をクラウドサービス提供者に修正
・「調達仕様書と関連するドキュメント例」の表を「調達に必要なドキュメントの関係図」の図に差し替え
・既存情報システムの機能改修を行う場合に準備するドキュメントに関する記載を追加
・総合評価落札方式におけるライフサイクルコストの観点で評価するための工夫に関する記載を追加
・オープンソースの有償と無償の境界に関する記載を削除
・設計・開発業務とクラウドサービスの一括調達に関する方針について、「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」も参照するよう注記を追加
・仕様書及び仕様書に紐づく設計書等の適切な文書管理に関する記載を追加

ii

第３編第７
章
第３編第８
章
第３編第９
章

2022年4月20日

第３編第１
章

第３編第２
章

第３編第３

・クラウドサービス利用時のベンダーロックインに対する注意点の記載を修正
・アジャイル開発では、システム開発全般にわたって、発注者の主体的な関与が必要である旨の記載を追加
・入札参加等級を緩和することで、多様な事業者の参入を促すことが望ましい旨の記載を追加
・中小・スタートアップ企業などの入札参加が具体的に見込まれる場
合、単一年度内に複数回の検収・支払いタイミングの設定を検討する旨の記載を追加
・総合評価方式の入札参加資格で規模要件を撤廃した事例を追加
・「参考：クラウドサービスを利用する際の調達計画の考え方」を削
除・デジタル化により入札事務手続きを簡素化した事例を追加
・一者応札状況を改善するための施策例として、十分な準備期間と事業者間の引継ぎ期間を確保する旨の記載を追加
・情報システムの整備において、請負契約を締結している外部事業者
からの再委託に関する記載を修正
・クラウドサービスプロバイダをクラウドサービス提供者に修正・クラウドサービス事業者をクラウドサービス提供者に修正・テスト計画の作成に関する記載を追加
・受入テストの実施期間に関する記載を追加
・利用者からの問合せ対応の工夫関する事例を追加
・機能改修の特性を踏まえた効率的なテストの実施に関する記載を追加・運用・保守フェーズにおけるヒヤリ・ハットを見つけて、改善していくことが重要である旨を追記
・想定読者に関する記載を追加
・第3章予算要求を第3章予算及び執行に修正
・政府ＣＩＯポータルサイトをデジタル庁Webサイトに修正
・府省ＣＩＯをデジタル統括責任者に修正・府省副ＣＩＯを副デジタル統括責任者に修正
・内閣官房ＩＴ総合戦略室をデジタル庁に修正
・総務省行政管理局をデジタル庁に修正
・政府ＣＩＯをデジタル庁に修正・開発イベントマップの記載を削除
・ベンダロックインをベンダーロックインに修正・事例に関する注意書きを追記
・「プロジェクトの立上げ、初動」に係る記載を修正
・府省ＣＩＯをデジタル統括責任者に修正・ＣＩＯ補佐官の記載を削除
・ＣＩＯをデジタル統括責任者に修正・副ＣＩＯを副デジタル統括責任者に修正
・府省共通システムの記載を削除し、関連箇所を修正
・内閣官房IT総合戦略室をデジタル庁に修正
・総務省行政管理局をデジタル庁に修正
・様式例2-1内の図の文言を標準ガイドライン本編に合わせて修正
・図2-5の文言を標準ガイドライン本編に合わせて修正
・サービス・業務企画段階でのリスク軽減に関する記載の追加
・府省重点プロジェクトの記載を削除し、関連箇所を修正
・第3章予算要求を第3章予算及び執行に修正・ＰＭＯの機能に係る記載の修正
・総務省統一研修を情報システム統一研修に修正・コラムの図に関する注意書きを追加
・第3章予算要求を第3章予算及び執行に修正

iii

章

第３編第４
章

第３編第５
章

第３編第６
章

・事例に関する注意書きを追記
・Step1のタイトル名を修正
・Step1の前文を修正
・Step6のタイトル名を修正
・Step7のタイトル名を修正
・Step8を追加
・予算要求の年間スケジュールに係る記載を修正
・予算要求に向けた作業に係る記載を修正
・政府共通プラットフォームの記載を削除し、関連箇所を修正
・Step3予算要求に必要な資料の準備をStep5に移動
・誤字の修正・図3-4の「府省ＣＩＯ補佐官」をＰＭＯに修正
・府省ＣＩＯ補佐官の記載を削除
・内閣官房をデジタル庁に修正
・総務省をデジタル庁に修正
・見積り精査を行うにあたっての参考資料に係る記載を追加
・Step6の前文を修正
・「A.府省内の確認」を「A.ＰＭＯによる調整」に変更し、記載内容を修正・「予算要求のプロセスでＰＭＯと会計担当部門が密接に連携」の事
例を削除
・Step7の前文を修正
・図3-6「執行計画作成からの移替えまでの作業フローのイメージ」
を追加
・「1.人事異動時は確実に引継ぎする」を「1.執行計画案の作成」に変更し、記載内容を修正
・「2.プロジェクト計画書に反映して最新化する」を「2.執行計画案の調整」に変更し、記載内容を修正
・「３.予算の移替え・予算執行管理」の記載を追加
・事例に関する注意書きを追記
・図4-1の文言を標準ガイドライン本編に合わせて修正・利用者のニーズの把握に関する記載の追加
・「齟齬」を「そご」に修正
・企画案の方向性の決定に関する記載の追加
・事例4-10におけるＵＲＬを修正
・府省共通システムの記載を削除し、関連箇所を修正
・標準ガイドライン本編の改定内容に合わせ、「システムではなくサービスを作る」を「情報システムではなくサービスを作る」に修正
・ＣＩＯ補佐官の記載を削除
・事例に関する注意書きを追記
・「齟齬」を「そご」に修正
・政府共通プラットフォームの記載を削除し、関連箇所を修正
・府省共通システムの記載を削除し、関連箇所を修正
・概念検証による性能要件の実現可能性の確認に関する事例の追加
・政府機関等の情報セキュリティ対策のための統一基準群を政府機関
等のサイバーセキュリティ対策のための統一基準群に変更し、関連箇所を修正
・ソフトウェアの修正・不具合への対応や機能追加等のバージョンア
ップに係る記載を追加
・システム方式として検討した内容を情報システムの実現案として決定する旨の記載を追記
・府省ＣＩＯ補佐官の記載を削除
・事例に関する注意書きを追記
・ベンダロックインをベンダーロックインに修正
・ＣＩＯ補佐官の記載を削除
・府省ＣＩＯ補佐官の記載を削除

iv

第３編第７
章

第３編第８
章
第３編第９
章
第３編第１
０章
2021年3月30日

第３編第１
章
第３編第２
章
第３編第３
章

第３編第４
章
第３編第５
章

・
「基本の単位」を「基本項目」に修正
・クラウドサービスを利用する際の調達計画の考え方に係る記載を追加・クラウドサービスの調達にあたって検討すべき点に関する事例を削除・総合評価落札方式を適用する場合の財務大臣への届出に関する記載を削除
・事例6-2におけるＵＲＬを修正
・技術的対話に関する記載の追加
・「牽制」を「けん制」に修正
・図６-４の政府共通プラットフォームの記載を削除・作業実施体制に関する注意点の事例を追加
・受託者を受注者に修正
・「齟齬」を「そご」に修正
・誤字の修正・府省重点プロジェクトの記載を削除
・「参考」を「注記」に修正
・「成果物の取り扱いには要注意」を「成果物の取り扱いに注意する」に修正
・ベンダーロックインによる問題を回避するための工夫に係る記載を追加
・事例に関する注意書きを追記
・パッケージ製品等を導入する際のＦｉｔ&Ｇａｐ分析に係る記載の追記
・使い勝手の良いシステムを構築するための工夫に関する事例を追加
・「齟齬」を「そご」に修正
・図の番号を修正
・アジャイル型をアジャイルに修正
・府省ＣＩＯ補佐官の記載を削除
・誤字の修正・表7-14の体裁の修正・事例に関する注意書きを追記
・ＲＰＡの入力を考慮した画面変更についての記載を追加
・事例に関する注意書きを追記
・誤字の修正・府省共通システムの記載を削除し、関連箇所を修正・事例に関する注意書きを追記
・ＣＩＯ補佐官を「政府デジタル人材、高度デジタル人材」に修正
・府省重点プロジェクトの記載を削除し、関連箇所を修正
・予算要求時のチェック項目として費用対効果の確認を追加
・予算要求時のチェック項目として基本設計書についての記載を追加
・資料間の不整合の修正
・資料間の不整合の修正
・クラウドサービスの調達・契約の方法の概要をまとめた事例を追加
・費用対効果とその把握についての記載の追加
・引継ぎに関する記載の修正
・クラウドサービスの見積もりに関する事例を追加
・クラウドサービス特有の料金体系についての例示を追加
・クラウドサービスのライフサイクルコストについての記載を追加
・現状分析結果報告書の様式例を追加
・体裁の修正・データ利活用促進を含めたデータ要件を「データに関する事項」として集約、関連する記載の追加
・クラウドサービス事業者に預けたデータが消失した事例を追加

v

第３編第６章

第３編第７章

2020年3月31日

第３編第８
章
第３編第９
章
第３編第２
章

第３編第３
章
第３編第４
章

第３編第５
章

第３編第６
章
第３編第７
章

第３編第８
章
第３編第９
章

2019年2月27日-

・機能の拡張性に関する記載を追加
・変化に強い情報システムの構築における工夫の例示を追加
・資料間の不整合及び体裁の修正・契約方式の検討に関する記載を追加
・契約方式の選定における工夫に関する事例を追加
・アジャイル開発の契約方式についての留意点を追加
・クラウドサービス利用時のベンダロックインに対する注意点を追加
・資料間の不整合及び体裁の修正
・成果物のメンテナンス性についての記載を追加
・基本設計書についての記載を追加
・「事例：ウォーターフォールとアジャイル開発を組み合わせた開発計画」の修正・引継ぎに関する記載の修正
・設計・開発事業者と運用事業者間でスムーズに引継ぎを行う工夫の事例を追加
・資料間の不整合の修正
・資料間の不整合及び体裁の修正・責任者体制、エスカレーション、早期共有等の重要性および情報共有ツールを利用した事例を追加
・ＰＭＯの取組として予算チェック、基盤整備、人材育成等の事例を追加
・ハードウェア保守を抜本的に見直した事例（第三者保守等の活用）を追加
・故障実績に基づいて保守形態を変更した事例を追加
・業務で利用する主要な情報のとりまとめ方法を追加
・必要に応じて既存ルールありきではなく、制度自体も考え直すことの重要性について追加
・発注者の要件定義への関わり方を追加
・データモデル等での定義方法の例示を追加
・データマネジメントの重要性について追加
・システム構成において稼働率目標のバランスをとった構成の重要性について追加・普段からの業務継続訓練の重要性について追加
・クラウドサービスの調達において検討すべき点を追加
・一者応札の状況を改善するためのノウハウを追加
・民法改正に伴う契約不適合責任の注意点を追加
・基本設計段階でのコミュニケーション失敗事例を追加
・アジャイル開発における注意点を追加
・緊急時の対応計画の準備としてコンティンジェンシープラン準備の重要性について追加
・要件定義と設計内容の突合を行ったＲＴＭ手法について紹介
・システムの利用促進のためのプロモーション事例を追加
・運用・保守における作業自動化、通知自動化、判断・制御自動化等の事例を追加・複数システム間の監視業務を統合して効率化と情報分析強化を行った事例の追加・初版決定vi

デジタル・ガバメント推進標準ガイドライン

１ 背景と目的
情報システムの整備及び管理は、多岐にわたる活動から構成され、専門的な内容が多く含まれるため、前提知識や経験のない職員にとって、全体像が理解しづらいものとなっている。
このため、本章ではＩＴマネジメントの活動について、事例やドキュメントひな形
等の紹介を含めて、プロジェクトを進める職員の立場から実践的な進め方を示すこと
で、プロジェクトを着実に推進し、利用者が実感できる効果を達成することを目的としている。
２ 適用対象
本方針の基本的な適用対象は、デジタル・ガバメント推進標準ガイドラインが適用されるサービス・業務改革並びにこれらに伴う政府情報システムの整備及び管理に関する事項を想定している。
ただし、本書はルールを示したものではなく参考文書であるため、適用対象の事項であっても本書の記載に従う義務はない。
３ 位置づけ本書は、「デジタル・ガバメント推進標準ガイドライン」、「デジタル・ガバメント
推進標準ガイドライン解説書」を上位ドキュメントとしている。
「デジタル・ガバメント標準ガイドライン」は、政府情報システムを整備及び管理する際の共通ルールである。そのため、政府情報システムを整備及び管理する際には、この内容に準じることが求められる。
「デジタル・ガバメント標準ガイドライン解説書」は、「デジタル・ガバメント標
準ガイドライン」の記載内容について逐条解説を行っているものであり、参考文書である。
本書「デジタル・ガバメント標準ガイドライン実践ガイドブック」は、上位ドキュ
メントの主要な構成に沿って、プロジェクトを進める職員の立場から実践的な進め方を示すことを目的とした、参考文書である。
４ 用語
本書において使用する用語は、本書に別段の定めがある場合を除くほか、原則として標準ガイドライン群用語集の例による。ただし、本書は職員にとって読みやすくわ
かりやすい構成とすることを重視しているため、厳密な用語を使うと可読性を損なうと考えた部分については日常的に使う表現を優先している部分もある。なお、参照しやすいよう用語集と同様の定義を記載する場合がある。そのほか専門的な用語については、民間の用語定義を参照されたい。

-

7 -デジタル・ガバメント推進標準ガイドライン

実践ガイドブックの全体像
第１章 実践ガイドブックの構成
本書の想定読者は、こんな人です
Point.1 実践ガイドブックの概要
Point.2 チェックリスト
第２章 プロジェクトの管理
Step.1 プロジェクト管理活動全体の流れ
Step.2 プロジェクトの立上げ、初動
Step.3 プロジェクト計画書等の作成
Step.4 プロジェクトのモニタリング
Step.5 プロジェクトの終結
第３章 予算及び執行
Step.1 予算要求の活動の全体の流れ
Step.2 予算要求の事前準備
Step.3 予算要求に必要な資料の準備
Step.4 見積り依頼
Step.5 見積りの精査
Step.6 予算を要求する
Step.7 予算要求後の対応
第４章 サービス・業務企画
Step.1 サービス・業務企画活動全体の流れ
Step.2 サービス・業務企画の開始準備
Step.3 利用者視点でのニーズ把握
Step.4 業務の現状把握
Step.5 サービス・業務企画内容の検討
Step.6 軌道修正
Step.7 新しい業務要件の定義
第５章 要件定義
Step.1 要件定義の活動全体の流れ
Step.2 要件定義の事前準備
Step.3 ＲＦＩの実施
Step.4 要件定義の全体像
Step.5 機能要件の定義
Step.6 非機能要件の定義
Step.7 要件定義終了後の対応-

8 -デジタル・ガバメント推進標準ガイドライン

第６章 調達Step.1 調達の活動の全体の流れ
Step.2 調達の事前準備
Step.3 調達仕様書の作成
Step.4 調達仕様書以外のドキュメント作成
Step.5 調達手続とプロジェクト管理
Step.6 検収第７章 設計・開発
Step.1 設計・開発の全体の流れ
Step.2 設計・開発を開始するための事前準備
Step.3 設計・開発の計画
Step.4 設計・開発・テストの管理
Step.5 見落としがちな活動に注意
Step.6 新業務の運営を円滑に行うための準備
第８章 サービス・業務の運営と改善
Step.1 サービス・業務の運営と改善の流れ
Step.2 新しいサービス・業務の事前準備
Step.3 業務の定着と次の備え
Step.4 業務の改善
第９章 運用及び保守
Step.1 運用及び保守活動全体の流れ
Step.2 運用・保守を開始するための事前準備
Step.3 運用・保守の計画
Step.4 運用・保守の定着と次への備え
Step.5 運用・保守の改善と業務の引継ぎ
第１０章 システム監査
Step.1 システム監査の全体の流れ
Step.2 システム監査の理解
Step.3 システム監査計画と監査実施計画
Step.4 システム監査の実施
Step.5 指摘事項を踏まえた改善-

9 -デジタル・ガバメント推進標準ガイドライン

デジタル・ガバメント推進標準ガイドライン
実践ガイドブック（第３編第１章

実践ガイドブックの構成）

-

10 -

（第３編第１章 実践ガイドブックの構成）

目次
本書の想定読者は、こんな人です .............................. 12
Point.1 実践ガイドブックの概要 .............................. 15
１ 本書の読み方 ........................................................................ 15
２ 本書の対象読者 ..................................................................... 16
３ 本書の概要 ........................................................................... 17
第２章 プロジェクトの管理............................................... 17
第３章 予算及び執行 ....................................................... 18
第４章 サービス・業務企画............................................... 18
第５章 要件定義 ............................................................. 18
第６章 調達 .................................................................. 19
第７章 設計・開発 .......................................................... 19
第８章 サービス・業務の運営と改善 ................................... 19
第９章 運用及び保守 ....................................................... 19
第１０章 システム監査 .................................................... 20

Point.2 チェックリスト.......................................... 22
１ 新サービス企画時のチェックリスト ............................................ 22
２ 予算要求前のチェックリスト .................................................... 23
３ 調達実施前のチェックリスト .................................................... 24
４ 設計・開発時のチェックリスト ................................................. 25
５ サービス実施時のチェックリスト............................................... 26

-

11 -

（第３編第１章 実践ガイドブックの構成）

本書の想定読者は、こんな人です
入省４年目の若手職員、吉川君（男性職員）は、ある日、上司の中山室長（女性職員）に呼ばれました。あるデータベースシステム開発の企画から要件定義、調達、開発、運用まで全てを担当してほしいとのことです。
「僕がですか？ＩＴなんてまるで知りませんよ。
」
そう。文系の大学を出て、入省後もＩＴとは無縁の仕事をしてきた吉川君には、データベースシステムを導入するなど、どこか遠い世界の話で、そもそも何をどこからやれば良いのか、まるで知識がありません。
それでも室長は、この仕事を是非、吉川君にと言います。
「今の時代、役人だって、ＩＴ知らないじゃ通用しないわ。勉強のつもりでやってみてよ。
」
吉川君は、不安に首を少しだけ傾げます。
「でも、本当に大丈夫ですかね、僕で。」「周りの先輩達だって、みんなやってきたことよ。吉川にだって、できないことはないはず。」室長の顔に迷いはありません。生来、真面目な吉川君は、傾げたままの首を二、三回縦に振りました。
「わ、わかりました。まあ、これまでの調達仕様書とか見て、発注さえすれば、あとはプロであるＩＴベンダがやってくれるわけですからね。」吉川君の言葉に室長の目が少し厳しくなりました。
「ダメよ。ＩＴに、そんなお客様気分は通じない。ＩＴ導入を行うなら、どんな業務を実現するために、システムにどんな機能や性能を持たせるのかを自分で考えなきゃいけないわ。そこをいい加減にやってプロジェクトが失敗して、発注者側が裁判でも負けたなんて例もあるんだから。
」「システム開発の失敗が客の責任になっちゃうんですか？」「それに仕事は発注までじゃない。ベンダの作業中も、その進捗とか課題をしっかり観察して、場合によっては、こっちから是正指示をしなきゃいけない場合だってあるのよ。
」
室長の言葉に吉川君は唇を尖らせました。
「それじゃあ、システムが本当に作り終わるまで、こっちは気が抜けないじゃないですか。ただでさえ忙しいのに。」
中山室長は一旦、腕組みをしてから、ゆっくりした口調で言います。
「でもね、吉川。さっきも言ったけど、こういうＩＴの発注は、これからの公務

-

12 -

（第３編第１章 実践ガイドブックの構成）員が、どうしても避けて通れないことだと思わない？公務員のコスト削減や働き方改
革だって、今、政府がやろうとしている重要な政策は、どれもＩＴ抜きには考えられない。自分の頭の中にある構想を具現化するとき、どんな情報システムを作るかを考えて実現する力がどうしても必要だし、逆に、そういうスキルをつけることは、吉川自身の将来にとっても大事なことだと思う。
」「それは、まあ、そうかもしれないですけど。」
これからはＩＴ抜きで仕事なんてできないし、その知識を得ておくことは、公務員にとっても必須と言うことは吉川君にもわかります。吉川君は尖らせた口を元に戻しました。でも、傾げた首は、まだそのままです。必要だと言うことはわかっても、そもそも何から始めたら良いのかすら、よくわかりません。
「でも、ＩＴの発注って何をどうすれば良いんだか・・・」質問する吉川君に、今
度は中山室長が首を傾げます。
「デジタル庁 Web サイトに載ってる、デジタル・ガバメント推進標準ガイドラインと解説書、読んだんでしょ？」「いや、それは読みましたけど。。。」吉川は言葉に詰まってしまいました。室長の言うドキュメントは、確かに一度読んだことがあります。ＩＴ導入で発注者側である
公務員がやるべきことや考え方が、一通り書いてあったのは覚えています。ただ、それらは、どちらかと言うと、基本的な考え方やルールが中心で、読んでいても、いま
ひとつ、自分がなすべき作業の実感がわかないと言うのが正直なところでした。
「読むには読みましたけど、イマイチ、リアリティが持てなくて。例えば、要件定
義で決めるべき事柄は分っても、実際、そのために、どんなドキュメントをどう作るのかとか、何に気をつけないと、どんな危険があるかとか、そう言うリアルなことが良くわからなくて。」
室長は小さく頷きました。
「そうよね。私もそう思う。」そう言いうと、室長は自分のパソコンを吉川君の方に向けました。
「こういうのが出たの知ってる？」「デジタル・ガバメント推進標準ガイドライン実践ガイドブック」
そう題されたＰＤＦファイルが画面いっぱいに表示されていました。
「君が言うとおり、標準ガイドラインや解説書は、正しいことを正しく書いてはいるけれど、本当に職員が何をすべきか、何に気をつけるべきかってことに関して、実

-

13 -

（第３編第１章 実践ガイドブックの構成）感を持って伝えるものじゃない。だから、そう言うこと、つまり、実際に役人がすべ
きこと、作るべきものについて、実例なんかを元に具体的に書いたのがこれよ。」「ちょっとすみません。
」
吉川君は、そう言うとパソコンを自分の方に引き寄せ、表示されたＰＤＦファイル
を数ページ進めて見ます。ＩＴ導入において、実際に作るべきドキュメントの例や、失敗から得た知見などが、工程ごとにまとめられている。確かに、これなら、各工程で自分が成すべきこと、注意すべきことが、リアルに実感できそうです。
「これを見ながらやれば、ＩＴ素人の吉川でも、なんとかやっていけるんじゃない？」中山は微笑んだが、吉川は、まだ少し首を傾げたままだ。
「内容はいいですけど、でも、これ全部読むんですか？何百ページもありますよ。」「馬鹿ね。こんなもの最初っから最後まで読み通す必要はないのよ。そもそもそんなことしたって、頭に入らない。」「ですよね。」「これはね。”辞書”なの。自分が作業をしていてわからなくなったら、その部分だ
けを見ればいい。調達仕様書って何を書くのか、プロジェクト管理って何をするのか、疑問にぶつかった時に、その部分を参考にする。だったら、そんなに手間もかからないでしょ？」「そう言うことですか。」吉川君は、再びＰＤＦファイルを眺めて、やがて大きく頷きます。
「わかりました。やってみます。」吉川の首が、初めて真っ直ぐに戻りました。
こうして吉川君は、慣れないＩＴ導入の仕事に取り組むことになりました。さて、読者の皆さんは、いかがでしょうか？もしかしたら、吉川君と同じようにＩＴに関す
る知見に自信のない人も多いかもしれません。この「デジタル・ガバメント推進標準
ガイドライン実践ガイドブック」は、標準ガイドラインに従って、ＩＴ導入の仕事を進めるとき、具体的に何をすべきかと言うことを、必要な部分だけ拾い読みできるように構成しています。ＩＴ導入でわからないことがあったときには、是非、このガイドブックから必要な部分を参照しながら、円滑なＩＴ導入の役に立ててください。

-

14 -

（第３編第１章 実践ガイドブックの構成）

Point.

1 実践ガイドブックの概要

この実践ガイドブックには、実際にプロジェクトを進める職員の視点で、具体的なノウハウ、
進め方、注意点、ひな形等を記載しています。多くの内容を盛り込んだ結果、全体で約 350
ページと、なかなかボリュームのあるドキュメントとなっています。
基本的には、冒頭の吉川君と中山室長のやりとりにもあったように、プロジェクトを進める中でわからないことがあったら、その部分を辞書的に参考にするような使い方を想定しています。
ということも含めて、まずは実践ガイドラインの全体像や読み方等について説明します。

１ 本書の読み方
本書は、「デジタル・ガバメント推進標準ガイドライン」の通称「三部作」の１つです。
本編には、政府情報システムの整備や管理に際して守るべきルールを書いています。
様々なプロジェクトで発生する多様な状況に対して正確に実施すべき内容を伝えるという性格を持つドキュメントであるため、正確さを優先して、いささか固めの表現となっています。
解説書は、そんな本編の内容を補足するものです。逐条解説という体裁で、本編で示した
ルールについて、その趣旨を説明したり、解釈方法の例示を行ったりしています。本編よりは固い表現ではないものの、やはり読みやすさよりは正確さを優先した表現となっています。
そこで、読みやすさや実用性を重視したのが、本書、実践ガイドブックです。

図 1-1
デジタル・ガバメント推進標準ガイ
ドライン

つまり、本書に書いている内容は、守るべきルールではありません。本書の記載を読んで、

-

15 -

（第３編第１章 実践ガイドブックの構成）

使えると感じた部分は使って頂きたいですし、使えないと感じた部分は無視して頂いて構いません。
また、本書の要点を短時間で確認したい人に向けて、サマリーを用意しました。この後の「３ 本書の概要」で、各章で記載している内容のポイントをまとめています。
実際の業務で活用しやすいように、チェックリストも作成しました。「Point2 チェックリスト」をご覧ください。

２ 本書の対象読者
本書では、主として次の読者を直接的な対象として想定しています。この他、地方公共団
体や独立行政法人の職員の方等にも活用いただける内容となっているため、是非ご参照ください。
各府省のＰＪＭＯとして情報システムに関連する企画、調達、開発、運用等の実務に携わる職員（特に、冒頭に記載した吉川君のように業務の進め方に慣れていない職員）
各府省のＰＭＯとして、府省内のＩＴ施策に関する全体管理を行う職員
デジタル統括責任者、副デジタル統括責任者
デジタル庁の各職員
政府情報システムの企画、調達、開発、運用等を協働して実施する事業者の方々

参考：目の前の仕事に忙殺されていると感じたときに多くの人は、目の前の仕事に忙殺されます。
例えば、新制度の導入に伴い、情報システムを作ることになったとしましょう。あなたは、そのプロジェクトの担当者です。来年度にはシステム開発に着手する必要があるので、急いで予算要求のための資料を整えます。制度概要の説明資料を作り、事業者に対して見積を依頼し、何とか予算要求の資料を整えました。予算を確保して安堵するのもつかの間、今度は調達に向けた準備です。他の事例を参考に見様見真似で要件定義書を作成し、目の前の仕事をこなし続けて、なんとか予定どおりに調達手続きに入ることができました。本当におつかれさまでした。
さて、この後、どのようなことが起こるでしょうか。調達を経て、事業者が決定してから、問題が次々に起こります。システム設計を進める中で、現場の職員からブーイングの嵐が巻き起こります。多様な業務をこなすための機能を考慮できていなかったからです。
ただ、既にシステム開発事業者と契約締結済なので仕様追加は困難です。やむを得ず、目の前の仕事として情報システムの完成を優先します。
何とか情報システムが出来上がり、稼働を開始しました。しかし、情報システムを使っていてはかえって業務が非効率なので、現場の職員は別の方法で業務を実施します。
情報システムを利用する人はほとんどいなくなりました。皮肉なことに、使われない情報
システムはシステム障害を起こすこともないため、外見的には順調に情報システムが動

-

16 -

参考 1-1
目の前の仕事に忙殺されていると感じたときに（第３編第１章 実践ガイドブックの構成）

いているように見えます。しかし、実態的には、価値のない情報システムに、延々とコストだけがかかっています。
どうして、こんなことになってしまったのでしょう。

目の前の仕事を進めながらも、一歩、踏みとどまることが重要だと考えています。
本当に、このままプロジェクトを進めてよいだろうか。何か、重要なことを忘れていないだろうか。そんな疑問を持ったときに、実践ガイドブックを手にとってもらえれば、何かヒントになることがあるかもしれません。本書では、プロジェクトの各工程の中で、どのような視点で何をしたほうが良いのか、具体的な手順や注意点を記載しています。また、過去に実際のプロジェクトで発生した良例又は悪例を含めて、様々な参考事例を掲載しています。
過去には、「一歩」を踏みとどまることができず、失敗と言われてしまうプロジェクトもありました。これから進めるプロジェクトの中では、少なくても同じ失敗をすることは避けたいですね。

３ 本書の概要
本書の第２章以降では、標準ガイドライン本編の章立てに沿って、具体的な進め方やノウ
ハウ等を説明します。

第２章

プロジェクトの管理

プロジェクトの立上げ時に、目標を安易に設定してしまうことがあります。第２章の冒頭では、
悪い目標設定例を題材にした上で、現場で発生している事実をつかみながら利用者が本当に困っていることを分析して、利用者が実感できる効果を目標に設定する方法を説明します。
また、機能するプロジェクト体制を作ることが重要です。制度所管部門、業務実施部門等を含めた組織的体制で、ＰＪＭＯにも十分な要員を確保する方法を具体例とともに示します。

-

17 -

（第３編第１章 実践ガイドブックの構成）

プロジェクトを実行する段階においては、ＰＪＭＯ自身によるモニタリングを行います。目標、経費、進捗、品質等を確認し、場合によっては抜本的改善のプロセスに入ることもあります。
様式のひな形

プロジェクト計画書、プロジェクト実施要領、
デジタル庁によるレビューでの説明前提事項

第３章

予算及び執行

予算要求に関連する作業の年間スケジュールを示し、十分な準備期間を確保することの重要性を強調しています。そして、予算要求に必要となる主要資料のそれぞれがどの工程の検討成果物であるかを示した上で、関係者に対してわかりやすい構成となるように、「全体から詳細につながる」といった資料作成のポイントを示しています。
また、情報システムのコスト削減のポイント、事業者から入手した見積りの精査ポイントについて、具体的に解説しています。
様式のひな形

第４章（特になし）

サービス・業務企画

サービスデザイン思考という言葉や、サービス・業務改革（BPR）という言葉を聞いたことがあっても、いざ自分が担当したときに何をどう検討すればよいのかわからないかもしれません。
まず、サービス設計１２か条の内容に基づいて、検討への心構えと視点を説明します。そして、利用者の立場からの分析を行うために、ペルソナ分析やジャーニーマップといった手法
を説明します。また、サービス・業務の現状把握のために、どのように調査を行い、どのような資料を集め、どのように分析するかを詳細に解説します。事例を交えた解説の中で、平均や合計での分析だけでは不十分であること、時間と期間を区別すること等、本当の事実をつかむための分析の着眼点や注意点を示しています。
このような検討を通して作成した企画案について、様々な方向から見直せるように、見直しの観点も多数示しています。
様式のひな形

第５章

現状分析結果報告書、業務要件定義書

要件定義

これまでの検討で作り上げた業務要件を実現するために、情報システムに求める要件を具体化します。
まず、RFI や事業者からの情報収集といった活動を通して、市場にあるサービス、海外や国内の類似事例、新たな技術の動向や製品のライフサイクル、概算の予算規模、スケジュー
ル等について把握を行います。
その上で、機能要件と非機能要件を明確にします。機能要件では、機能、画面、帳票、データ、外部インタフェース等について、非機能要件ではユーザビリティ、システム方式、規模、性能、信頼性、情報セキュリティ等について記載します。記載項目のそれぞれについて、記載する目的、作成するドキュメントのイメージ、注意点等を説明しています。

-

18 -

（第３編第１章 実践ガイドブックの構成）

様式のひな形

第６章

機能要件定義書、非機能要件定義書

調達

要件定義までの工程で情報システムに求める全体機能は明確になりましたが、この内容をどのような単位に分けて調達を行うのかは重要なポイントです。分離調達を行うことのメリットとデメリットを説明し、調達の単位をうまく定めて調達計画を作成する方法を示します。
調達仕様書についてはひな形を示した上で、調達目的の正確な記載、作業内容と納品物を紐づけた明確化、実施体制や発注者としての役割について考え方や注意点を記載しています。また、総合評価落札方式で事業者の提案を評価する際に、評価点の配分の留意点や、事業者から WBS として示される作業予定内容の精査のポイント等について説明しています。
様式のひな形

第７章

調達仕様書

設計・開発

設計・開発を事業者に丸投げしては、良い情報システムは作れません。要件を事業者に正しく伝え、関係者間の調整を行い、進捗状況を正しく把握し、情報システムの出来具合をテストするのは発注者である職員自身です。設計・開発において、職員自身が実施することにフォーカスして、業務内容を説明しています。
例えば、テストについても、結合テスト、総合テスト、受入テストといった工程の中で、機能面（シナリオテスト、業務サイクルテスト等）はもちろんのこと、非機能面（負荷テスト、セキュリ
ティテスト、縮退テスト等）をそれぞれ確認します。職員自身がテスト計画やテスト結果について正しく判断できるように、テストの内容と確認ポイントについて説明しています。また、移行、
リハーサル、運用・保守の準備、マニュアル等、重要なのに見落とされがちな作業について、計画の立て方、ドキュメントの作成方法、注意点等を示しています。
様式のひな形第８章

設計・開発実施計画書、設計・開発実施要領、受入テスト計画書

サービス・業務の運営と改善業務を実施する中でも、うまく外部委託を活用します。作業量が多く定期的に発生する作業は外部委託に向いていますが、業務上の専門知識を必要とする作業や品質確認が必要
な作業は外部委託にはあまり向いていません。役割分担のコツについて説明します。
また、日常の業務の中で、利用者からの要望、インシデント、ログ情報等、様々な情報が蓄積しますが、それらの情報はサービスや業務を改善するための宝の山です。これらの情報を蓄積し、分析するための手法として事例等を紹介しています。
様式のひな形

第９章（特になし）

運用及び保守-19 -（第３編第１章 実践ガイドブックの構成）

運用及び保守の目的は、情報システムの安定的な稼働を維持することだけでなく、利用者へのサービスを継続的に改善することや運用コストを低減していくことも含まれます。
そこで、まず運用及び保守で実施する代表的な作業項目を説明しています。これらの作業は、事業者に実作業を依頼する比率が高くなるため、作業分担を明確にすることが重要です。
運用契約の「忘れ物チェックリスト」等を含めて、注意点を記載しています。
また、運用工程では複数の事業者が関わるため、会議体の種類が多くなる傾向があります。
代表的な会議体の種類と目的を示すとともに、定例会議における報告内容についても注意点を記載しています。
そのほかにも、変更管理、ログ等の蓄積、指標管理、運用業務の改善方法等、職員が主体的に運用・保守業務を管理するための具体的な知識やノウハウを説明しています。
様式のひな形

運用計画書、運用実施要領、運用報告書
保守計画書、保守実施要領

第１０章

システム監査システム監査は、各プロジェクトの取り組みがその目標達成に正しく向かっているのか、プ
ロジェクトの各フェーズでの実施プロセスは適切かといった観点から、現状を調査し、改善すべき点がないかを第三者の視点で客観的に点検・評価する活動です。
まず、各省ＰＭＯが複数年単位での監査計画を立て、どの情報システムを監査対象とするかを決めます。実際の監査の中では、監査責任者が監査実施計画書を作成し、監査目的、
監査範囲、スケジュール、監査体制、実施方法等を定めますので、その記載方法等を示しています。また、予備調査の進め方、インタビューの実施方法、監査報告書の作成方法、監査後の改善の進め方等について解説しています。
様式のひな形

監査実施計画書、監査報告書

-

20 -

（第３編第１章 実践ガイドブックの構成）

参考：ＷＢＳ
標準ガイドラインに定めた作業の全体像を理解しやすくするために、登場する作業を定義した資料として WBS(Work Breakdown Structure)を別紙に用意しています。

-

21 -

参考 1-2
WBS

（第３編第１章 実践ガイドブックの構成）

Point.

2 チェックリスト

読者の方が直面している業務内容に即して本書を読み進められるように、特に重点的に読んでいただきたい内容をチェックリストとしました。実務での作業計画や見直しに活用してください。

１ 新サービス企画時のチェックリスト
プロジェクトの立上げ、初動1目標とする成果が正しく定められているか

第 2 章 Step2 1□

2

サービスを改善するための十分な体制を組んだか

第 2 章 Step2 3□

利用者視点でのニーズ把握
3

サービスの利用者の種類や人数を把握したか

第 4 章 Step3 1□

4

利用者の立場でサービスへのニーズを把握したか

第 4 章 Step3 2□

業務の現状把握
第 4 章 Step4 1□

5

業務の現場へ行って業務実態を詳細に把握したか

6

業務で生まれる各実績データを収集して分析したか

第 4 章 Step4 2□

7

業務の制約条件及び前提条件を洗い出したか

第 4 章 Step5□

第 4 章 Step5□

8

業務のリスクアセスメント（リスク特定、リスク分
析、リスク評価）を実施したかB,C

サービス・企画内容の検討
9

エンドツーエンドの視野での企画案になっているか

第 4 章 Step5 2 C□

10

自分で作りすぎず、シンプルな企画案になっているか

第 4 章 Step5 2 I□

11システムを作る前に、業務を標準化したか

第 4 章 Step5 2 E□

12

一遍に全てを実現するのでなく、段階案を検討したか

第 4 章 Step6 1□

第 4 章 Step6 2□

プロジェクト計画書
13

プロジェクト計画書の段階的な改定を行ったか

-

22 -

（第３編第１章 実践ガイドブックの構成）

２ 予算要求前のチェックリスト
予算要求の事前準備
1

予算要求に向けた活動計画を立てたか

第 3 章 Step2 1□2

コスト削減に向けた検討を計画的に行ったか

第 3 章 Step2 3□

第 3 章 Step3 1□

第 3 章 Step3 1□

第 3 章 Step4 1□

予算要求に必要な資料の準備
3
4

プロジェクトが目標とする成果の詳細化・具体化を行っているか
予算要求の目的とプロジェクトの目標とで整合性はと
れているか

見積り依頼
5

見積り依頼前に、制約条件、前提条件、リスク及び問題点を考慮して要件を精査したか

6

一式ではなく、詳細な見積り内訳を把握したか

第 3 章 Step5 全体□

7

人件費について工数の妥当性を精査したか

第 3 章 Step5 1□

8ハードウェア等について経費の妥当性を精査したか

第 3 章 Step5 2□

第４章 Step５ 2 G□

第 3 章 Step7 2

□

費用対効果
９

ライフサイクルコストの観点から費用対効果を確認したか

プロジェクト計画書
10 プロジェクト計画書の段階的な改定を行ったか

-

23 -

（第３編第１章 実践ガイドブックの構成）

３ 調達実施前のチェックリスト
調達の事前準備1

プロジェクト全体の調達計画を立てたか

第 6 章 Step2 1□2

リスクの対応方針を検討したか

第２章 Step3□

第 2 章 Step2□

3

プロジェクトが目標とする成果で求める品質又は成功基準を検討したか

要件定義書の作成

4実現する機能の優先順位を検討したか

第 5 章 Step4 2□

5

機能、画面、帳票、データ等の要件を明確にしたか

第 5 章 Step5 1□

6

実施頻度の低い機能も含めて漏れなく要件化したか

第 5 章 Step5 2□7規模、性能、信頼性等の非機能要件を明確にしたか

第 5 章 Step6 1□

第 5 章 Step5 1 E□

第 5 章 Step7 1□89

業務で必要となるデータの項目、品質等を明確にしたか
要件定義の全体内容を関係者に共有したか

調達仕様書の作成

10

調達の目的を正しく伝えているか

第 6 章 Step3 2 A□

11

作業内容と納品物を関連付けて定義しているか

第 6 章 Step3 2 C□

12

事業者の実施事項、役割を明確に定義しているか

13

ベンダーロックインの構造を理解し回避しているか

第 6 章 Step3 2
D、E
第 6 章 Step5 2□□

現状の把握・分析結果の確認（現行の業務、システムがある場合）

14

現行の業務、システム、データ及び運用の状況を分析したか（現状分析結果報告書）

第 4 章 Step5 1□

第 2 章 Step3 1□

プロジェクト計画書

15

プロジェクト計画書の段階的な改定を行ったか

-

24 -

（第３編第１章 実践ガイドブックの構成）

４ 設計・開発時のチェックリスト
設計・開発を開始するための事前準備

1

プロジェクトの目標・目的と機能要件、非機能要件などがそれぞれ紐づけ管理できているか

第 5 章 Step4 1□2

設計・開発で職員が担うべき役割を理解したか

第 7 章 Step2 1、２□３

基本設計書の構成、内容は確認したか

第７章 Step2 2 E□

第 6 章 Step6 1

□

設計・開発

４

完成後のサービス提供・業務利用を想定して課題管
理、リスク管理を行っているか

５

工程の進捗を定点観測しているか

第 7 章 Step3 1 A□

６

事業者任せではなく自分で理解して判断しているか

第 7 章 Step3 1 B□

ガントチャートや EVM で進捗実態を把握している

第 7 章 Step3 2 E、F□他システム連携の内容に細心の注意を払ったか

第 7 章 Step4 1 B□

９

様々なテストのレベルと種類を理解したか

第 7 章 Step3 3 B□

10

テスト実施に向けた職員側の体制を確立したか

第 7 章 Step3 3 A□

第 7 章 Step4 4□

第 7 章 Step4 5□

第 7 章 Step5 1 A□

第 7 章 Step5 1 B□

第 7 章 Step5 1 B□

第 2 章 Step3 1

□

７
８

か

テスト

11
12

負荷テスト、セキュリティテストなどの非機能テス
トを十分に実施したか
現場に即したシナリオで受入れテストを実施したか

移行、リハーサル

13
14
15

システム移行、データ移行、業務移行を計画したか
本番稼働前に切り戻しのルール及び手順、コンティ
ンジェンシープランを作成したか
本番稼働前にリハーサルを入念に行ったか

プロジェクト計画書

16

プロジェクト計画書の段階的な改定を行ったか

-

25 -

（第３編第１章 実践ガイドブックの構成）

５ サービス実施時のチェックリスト
業務の実施、改善

1
2

職員への研修・教育を継続的に実施しているか業務で扱うデータの品質を維持しつつ適切なライフサ
イクル管理を行っているか

3

業務の実績データや利用者要望を分析できているか4

プロジェクトの目標達成状況を確認しているか

第 8 章 Step3 1□

第 8 章 Step3 3□

第 8 章 Step3 4
A、B、D

□

第 8 章 Step3 4 C□システムの運用・保守

5

運用・保守事業者の作業範囲を明確にしているか

第 9 章 Step2 2 A□

6

非機能要件に関する実績データを把握しているか

第 9 章 Step3 1 D□

7必要となる会議を、極力簡潔に開催できているか

第 9 章 Step3 1 E□

8運用・保守作業の実績工数を詳細に把握しているか

第 9 章 Step3 1 G□

9

改善のインプットとなる情報を集めているか

第 9 章 Step4 3 B□

第 2 章 Step3 1□

プロジェクト計画書

10 プロジェクト計画書の段階的な改定を行ったか

-

26 -

デジタル・ガバメント推進標準ガイドライン

デジタル・ガバメント推進標準ガイドライン
実践ガイドブック（第３編第２章

プロジェクトの管理）-1 -

（第３編第２章 プロジェクトの管理）

目次
Step.1 プロジェクト管理活動全体の流れ ..................... 5
Step.2 プロジェクトの立上げ、初動 ........................... 6
１ 目標とする成果を見定める ......................................................... 6
A. 現場で発生している事実をつかんだ上で今後の目標を定める ..... 6
B. 上位計画の目標をブレークダウンし、プロジェクト目標と紐づける ................................................................................ 10
２ 手段の妥当性を確認する .......................................................... 17
３ プロジェクトの投資対効果を算出する ......................................... 19
４ プロジェクトへの投資判断を行う............................................... 20
５ 機能する体制を作る................................................................ 21
A. 制度所管部門、業務実施部門等を含めたＰＪＭＯ体制とする ... 21
B. プロジェクトの規模に見合った体制を組む .......................... 22
C. 他組織と連携できる体制を作る ........................................ 25
D. 先行経験を持つ人のノウハウを活用する ............................ 27

Step.3 プロジェクト計画書等の作成 ......................... 30
１ プロジェクト計画書を作成する ................................................. 30
A. プロジェクト計画書は段階的に詳細化する .......................... 31
B. 抜け漏れのない実施計画を作成する .................................. 33
２ プロジェクト管理要領を作成する............................................... 34
A. 問題に対処できる会議体を構成する .................................. 35
B. 本質的なリスクを事前に予見して、対応を準備する .............. 38
C. 品質管理を事業者任せにしない ........................................ 41

Step.4 プロジェクトのモニタリング ......................... 42
１ プロジェクトをモニタリングし・検証する ................................... 42-

2 -（第３編第２章 プロジェクトの管理）

A. 目標、経費、進捗、品質等を中心にモニタリングする............ 42
B. モニタリングは適時に実施する ........................................ 44
C. モニタリングと監査をうまく組み合わせる .......................... 44
D. プロジェクトは状況に応じて停止・改善する ....................... 44

Step.5 プロジェクトの終結..................................... 46
１ プロジェクトの終結を処理する ................................................. 46
A. プロジェクトを完了する ................................................ 46
B. プロジェクトを終了する ................................................ 46
C. 後続プロジェクトを策定する ........................................... 46【コラム】ＰＭＯの取り組み事例 .............................. 48
A. ＰＭＯの機能強化 ......................................................... 48
B. 省内共通基盤の整備 ...................................................... 48
C. 体制強化・人材育成 ...................................................... 49-

3 -（第３編第２章 プロジェクトの管理）

事例・参考の一覧
ポイント：利用者視点での目標設定には、サービスデザイン思考を！ ............. 9
ポイント：事実を詳細につかむことも忘れずに ......................................... 9
事例：事務作業を効率化し、国民向けの対応サービスを強化 ...................... 10
事例：ＫＰＩトレーサビリティ・ツリーによる目標の紐付け ...................... 12
参考：バランスト・スコアカードによる目標の紐付け ............................... 15
事例：トレーサビリティ・ツリー、ＢＳＣを利用したＫＧＩ/ＫＰＩ策定 ....... 15
事例：制度・業務・システムの三位一体のプロジェクト体制 ...................... 21
参考：ＰＪＭＯの主要業務................................................................. 22
事例：情報共有ツールによる関係者への情報共有 .................................... 26
事例：原則にとらわれない環境作り ..................................................... 27
事例：府省を跨った特別移行支援チーム................................................ 28
様式例：プロジェクト計画書のひな形 .................................................. 31
参考：補正予算で開始するプロジェクト................................................ 32
様式例：プロジェクト管理要領のひな形................................................ 35
事例：業務実施部門が参加しなかったプロジェクト ................................. 36
事例：幹部職員への定期的な報告 ........................................................ 37
事例：開発途中の機能追加による目標の形骸化 ....................................... 43
事例：抜本的な改善のために新たな体制を構築 ....................................... 44※事例には当時の役職名やシステム名を使用しているため、現在使用されていな
い名称が記載されている場合があります。

-

4 -（第３編第２章 プロジェクトの管理）

Step.

1 プロジェクト管理活動全体の流れ

情報システムの構築に関するプロジェクト管理には、一般的に様々な手法が存在し、たくさんの書籍や報告書等にも知識や経験則が示されています。確かに、専門性の高い知識やノウハウがあるに越したことはありませんが、全てを熟知しないとプロジェクト管理ができないわ
けではありません。
ここでは、プロジェクト管理の専門家ではない職員が、標準ガイドラインに沿ってプロジェク
トを管理し、推進していくために必要となる具体的な知識やノウハウについて説明します。
本ドキュメントの構成は、次のとおりです。

Step.2 プロジェクトの立ち上げ、初動
プロジェクトの初動とは、プロジェクトが生み出され、スタートを切ろうとしている際のタイミングです。この出だしでいくつかの内容を理解し、行動しておくことで、プロジェクトの手戻りを大きく減らすことができます。
ここでは、これらの知識やノウハウについて、具体的に説明します。

Step.3 プロジェクト計画書等の作成
プロジェクトには必ず定めるべき事項が存在します。それは、プロジェクトスタート時点で決められるもの、プロジェクトが進むにつれて具体化されるもの、状況に応じて内容を見直すもの等、様々な情報で成り立ちますが、全てはプロジェクト計画書に記載され、関係者にて共有される必要があります。
ここでは、まずプロジェクト計画書とはどのような位置づけで、何に気をつけて作成していくのかについて、説明します。
また、具体的な活動方針であるプロジェクト管理要領の作成に関する要点についても説明します。

Step4 プロジェクトのモニタリング
プロジェクトは、プロジェクト計画書にのっとり実施されます。実施中、特に管理面で発生するイベントを中心にその内容と留意点を説明します。

Step.5 プロジェクトの終結
プロジェクトの実施期間が 10 年を超えるものも珍しくありませんが、期間の長短にかかわらずスタートしたプロジェクトはいずれ終わりを迎えます。
ここでは、プロジェクトの終了前後で何をすべきか、どんな終わり方があるのか、後続となる
プロジェクトへのバトンの渡し方について、説明します。

-

5 -（第３編第２章 プロジェクトの管理）

Step.

2 プロジェクトの立上げ、初動

プロジェクトを立ち上げることになってメンバーの１人に任命されたんだけど、いったい何をしたらいいんだろうか。新しいプロジェクトの立ち上げに携わる時には、誰もがうれしさ半分、とまどい半分という入り混じった気持ちになります。
プロジェクトを立ち上げる際には、目標や方向性を適切に定めることが重要です。そこで、
ここではプロジェクトを立ち上げる際の動き方について、特に重要になる点を説明します。

１ 目標とする成果を見定める【標準ガイドライン関連箇所：第３編第２章第１節 1)】

今まで、いくつかの失敗プロジェクトがありました。
失敗プロジェクトについて後から振り返ってみると、プロジェクト開始当時に業務分析を軽視し、楽観的な推測を基に想定効果を過大に見積っていたという傾向が共通的に見られました。このような失敗を繰り返さないために、新しいプロジェクトを開始する際には、ぜひこれから説明する内容を意識してください。

A. 現場で発生している事実をつかんだ上で今後の目標を定める
このタイトルを読んだだけでは、当たり前のことのように思えるでしょう。ただ、一口に「事実をつかむ」と書いても、どの水準までつかむ必要があるのか、人によって理解は様々です。
そこで、ここでは１つの例を題材として、考えてみましょう。
紙の申請書を窓口で受け付けていた業務について、ＩＴを使ってサービスを改善するためのプロジェクトを立ち上げたとします。このプロジェクトの目標は何でしょうか。
まず、「申請者の利便性向上」といった言葉が思い浮かぶかもしれません。窓口に来るということ自体、申請者にとっては面倒なことです。電子申請を導入すれば、申請者の手間を減らすことができるかもしれません。ただ、電子申請を導入したとしても、窓口に来る方が便利という人もいるでしょう。まずは、全ての申請件数のうち、60%程度を電子申請経由とすることを目指すのが現実的な線でしょうか。
さて、これで目標設定が完了しました・・・。本当に、これで大丈夫でしょうか？

プロジェクトの目標が安易に設定された例 （悪い例）
電子申請の実現
KPI

課題： 申請者が窓口へ来訪する必要がある
目標： 電子申請を実現し、来訪を不要とする
指標： 電子申請利用率 60% （xx年度）

実は、この例には目標設定に当たって決定的に抜け落ちている観点があります。何が抜けているのか、順をおって説明しましょう。

-

6 -

図 2-1
目標設定の悪い例

（第３編第２章 プロジェクトの管理）

誰が何に困っているのか
ここで原点に立ち返って、現場で発生していることをよく見てみましょう。
申請者は、本当に困っているのでしょうか。困っているとして、何に困っているのでしょうか。
現場に行って、実際に現場で発生していることを調べてみると、例えばこのような状況に気づくことができます。
審査期間が長すぎるある業務では申請を受け付けてから審査結果を返すまでに１ヵ月程度の期間を要していました。申請者は、窓口へ来訪する手間よりも、審査結果が遅いことに対して大きな不満を持っていました。
審査結果の回答期日が不明
ある別の業務では、審査の回答期限を定めていませんでした。申請者は、いつ申請結果が返ってくるかが全くわからず、何度も窓口に電話で問合せては、その度に「現在処理中です。回答できる期日はわかりません」と返答を受けて、困っていました。
申請様式が拠点ごとにバラバラ
ある企業は全国的に事業を展開していますが、申請書を提出する地方拠点ごとに申請書の様式や記載項目が異なっていました。そのため、企業内では一元的にデータを管理しているにもかかわらず、各拠点の様式に合わせて手作業で申請書を書かなければならず、手間が発生していました。
これらの例では、窓口に来なければならないことよりも、さらに深刻に困っていることがありました。電子申請を進めるだけでなく、ほかにも対策を打つべきことがありそうです。
「申請者は窓口へ来訪する手間に困っている」というストーリーは、推測に基づくものでした。現場を知らない人の推測のみで目標を設定するのではなく、現場の流れ、利用者の状況を調べて、本当の「困っていること」を把握することが最初の第一歩です。

利用者にも、色々な種類があるのではないか
そもそも、利用者とは誰でしょうか。先の例では、「申請者」という１つの言葉で表現していましたが、申請者の中にも、様々な種類の利用者がいるのではないでしょうか。
本人か代理人か
実際に申請を行うのは、手続の主体となる本人でしょうか、それとも代理人でしょうか。代理人による申請の場合は、委任状が必要になるなど必要書類や事務手続が異なる可能性があります。
個人か法人か企業等の法人が日常的に申請を行っている場合は、１つの手続ごとに窓口にくるのではなく、ある程度まとめて一括で申請を行っているかもしれません。
また、大量の申請を行っている企業は、紙の申請書を自動出力できるように独自の情報システムを整備済みかもしれません。この場合、拙速に電子申請を進めても、紙の申請書の方が便利であるため、電子申請が使われないことになりかねません。
そのほかにも、地域別、世代別、世帯構成別など、申請者を様々な観点から分類することができます。重要なことは、「困っていること」が異なるグループがあれば、それらの個々-

7 -（第３編第２章 プロジェクトの管理）のグループについて、それぞれの困りごとを把握するということです。また、独自の情報シ
ステムを整備済みの企業の例のように、「困っていない」グループを把握することも重要です。
なお、この例における「申請者」のような、複数のグループを包括する名詞には注意が必要です。このように十把一絡げの形で利用者像を捉えてしまうと、特定のグループが困っていることを見落とすことになりかねません。

申請内容にも、色々な種類があるのではないか
申請内容にも様々な種類があります。申請の種類ごとに、審査の内容や必要時間を調べていくと興味深いことがわかりました。
形式的な内容確認のみを行うもの （大部分の申請）
必須記載事項が正しく記載されているかなど形式的な確認のみを行うものが、申請件数の大部分を占めていました。
なお、さらに実態を調べていくと、実質的な確認に要する時間は僅かであり、各部門を流れていく際の待ち時間が長いことがわかりました。また、窓口で申請書類を受領した際の確認が十分でなく後日に申請者へ再問合せを行うな
ど、再確認作業にも相当の手間が発生していることがわかりました。
専門の審査官による実体的な審査を行うもの （一部の申請）
一部の申請については、審査官が専門知識と経験に基づいて各種資料を総合的に確認した上で審査を行っていました。ただ、上述の形式的な内容確認も同一の審査官が実施しているため、専門的な審査に十分な時間が割けない場合があることもわかりました。

エンドツーエンドの視野で、ほかに問題はないか
業務実施部門の視点で見ると、窓口で申請を受付け、審査を行うという業務は所管業務の重要な一要素です。一方で、利用者が申請の事前、事後で作業を行っていることについては、業務実施部門の「所管外」として意識されないことがあります。
しかし、利用者の視点で見ると、事前、事後に必要となる作業も同様に重要なプロセスです。そこに、困りごとは発生していないでしょうか。
利用者が申請を行う前に必要となる作業
代理人が申請するときに、本人からの委任状をどのように手配しているのか・
申請可能な時期を確認する・申請後にどのような順番で処理されるのか（先着順、申請期間完了後一斉処理等）
利用者が審査結果を受領した後に必要となる作業
審査結果を別の行政機関に提出している◇◇◇
このように、利用者視点を重視して現場で発生していることを調べていくと、解決すべき
課題に様々な種類があることがわかります。
ここで例示したプロジェクトについては、目標とする成果を次のように見直すこととしまし
た。

-

8 -

注記
エンドツーエンドとは、利用者が、ある目的を達成するためにサービスを受ける必要があると考えた時点から、当該サービスを受けたことにより目的を達成した時
点、又はサービスを享受し終わった後の行動までに生じる、利用者の感情を含めた思考や一連の行
動全体のこと。

（第３編第２章 プロジェクトの管理）

プロジェクトには投資が伴います。投資を行ってまで得たい成果が何なのか。それを具体的な形で明確にすることが重要です。

図 2-2
目標設定の改善例

プロジェクトの目標の設定例 （改善例）
審査期間の短縮

課題： 審査期間が長く、平均2週間、長いものでは2か月を要している
目標： （例外を除き）審査期間を原則１週間以内とする。
課題： 全国展開企業や代行業等の大量申請者の手続きが煩雑

大量申請者への対応

目標： 拠点ごとに異なっていた申請様式を統一
大量申請者向けのデータ一括申請の導入

添付書類の不要化

KPI

課題： 申請時に必須となる添付書類を別窓口から入手する手間が発生
目標： システム連携により、申請時の添付書類を不要化
対象手続きの審査１週間以内遵守率80% （xx年度）
100% （xx+2 年度）＜目標設定のポイント＞
・利用者が困っていること（審査期間）への対応を優先
・申請者や申請内容の異なりを捉え、個々のニーズへ対応（大量申請者）
・利用者目線で事前、事後の作業も改善（添付書類）
・小さく始める。そして、軌道修正しながら最終目標へ到達する（段階的なKPI）

ポイント：利用者視点での目標設定には、サービスデザイン思考を！

ポイント 2-1
利用者視点での目標設定には、
サービスデザイン思考を！

抜けている着眼点として、４つの事例を紹介しました。実際のプロジェクトの立ち上げに際しては、このような着眼点を検証するためのサービス・業務企画の活動を先行的に行いながら、同時並行でプロジェクトの目標を定め、プロジェクト計画書等を作成することとなります。プロジェクトの目標を定めるためには、上の例で挙げたように
利用者視点に基づいた現状の把握と分析が不可欠です。これらの具体的な検討方
法については「第４章 サービス・業務企画」で詳述しています。特に、サービス・業務
企画の活動の最初に掲げている「サービスデザイン思考」については重要な観点となりますので、ぜひ本章と併せてご確認ください。

ポイント：事実を詳細につかむことも忘れずに
先ほどの例では、審査期間の短縮として原則１週間以内にするという目標を立てました。ただ、まだこの時点では、審査期間がなぜ長くなってしまうのか、その原因をしっかりつかめているわけではありません。
サービス・業務企画の活動の中では、発生している事実を詳細につかむことも非常に重視しています。実際の１件１件の審査案件を調べてみて、どこで滞留が発生しているのか、その滞留が発生する背景にはどのようなことがあるのか、そのようなこ-

9 -ポイント 2-2
事実を詳細につかむことも忘れずに（第３編第２章 プロジェクトの管理）とを丹念に調べていくことで初めて本当の問題点をつかむことができます。このような事実のつかみ方についても、「第４章 サービス・業務企画」で詳述しています。
プロジェクトの立ち上げ時には、利用者が困っていることを把握した上で、その困りごとを解消するための目標を立てます。その後に詳細な現状把握を行って問題の発生原因を突き止めていくので、場合によっては目標の修正が必要になることもあるでしょう。プロジェクトの立ち上げ後は、このように現状把握を進めながらプロジェクトの目標自体も正確に見定めていきます。そして、サービス・業務企画をまとめあげる頃には、設定した目標に対して関係者の合意もとりつけて、目標を確定します。

事例：事務作業を効率化し、国民向けの対応サービスを強化
プロジェクトの目標として、職員の業務時間削減を設定することがあります。
確かに、業務に非効率な部分があり、そこをシステム化によって改善することができれば、その部分の業務時間は減るでしょう。でも、減った時間はどこに行くのでしょうか。
１つの考え方は、時間外労働を減らすということです。定常的に時間外労働が発生している職場であれば、働き方改革を推進する面からも重要な目標になります。
もう１つの考え方は、減った時間を他の業務に有効活用するということです。今までは非効率な作業に忙殺されて手がつけられていなかった重要な業務を、今後はしっかり取り組めるようになるということです。この考え方に立つならば、非効率な業務を減らす部分を数値化するだけでなく、それによってどのような新しい業務を可能にするのか、そこまで踏み込んで考えていくと、本当に役立つ目標となります。
ある業務では、窓口に来訪した国民向けに様々なアドバイスをしながら、その人に合ったサービスを探していくコンサルティングを実施しています。しかしながら、来訪者が最初に記載する紙書類の処理、応対記録の作成、様々な業務分担の職員間での情報連携等、事務的な処理に多くの時間を要していたため、来訪者１人１人に向き合って対応する時間が十分でなく、多くの来訪者を待たせてしまうことにもなっていました。
そこで、まずはシステム化等により煩雑な事務作業を効率化することにしました。
そして、そのことによって浮く時間を、来訪者向けのコンサルティングサービスに振り向け、サービスを充実させることとしました。

B. 上位計画の目標をブレークダウンし、プロジェクト目標と紐づける
前述の例は、現場のニーズや困りごとに基づいて、新規のプロジェクトを立ち上げる例でした。一方で、政策や施策等、上位に当たる計画があった上で、それを実現するために
情報システムを活用したプロジェクトを立ち上げるという形も、実際によくみられる形態です。また、予定されている法改正等に伴い、情報システムの対応が不可欠になるという状
況もよくみられます。
このような場合、どのようなことに留意すべきでしょうか。

上位計画の目標と、プロジェクトの目標を紐づける
上位計画が長期的視点で広範囲にわたる効果を目指している場合は、その目標設定も包括的で概括的なものとなる傾向があります。例で示す方が、わかりやすいでしょう。

-

10 -

事例 2-1
事務作業を効率化し、国民向けの対応サービスを強化

（第３編第２章 プロジェクトの管理）

児童の学力向上
過疎地域の若年人口拡大
地域活動への多様な人材の参画
助成制度利用企業の売上金額の拡大
受給権者への確実な給付の達成
これらの上位計画を達成するために、その１つの施策として情報システムを活用したプロ
ジェクトが必要になることがあります。この場合、上位計画の「大目標」とプロジェクトの「部分目標」が実体的に紐づくべきなのですが、その過程を省略して、プロジェクトの目標も「大目標」で置き換えてしまう例が見られます。しかし、そのプロジェクトが果たして「大目標」にどれほど貢献できるのか、その効果の程度がよくわからなくなってしまいます。
目標が紐づくとは、どのような状態を指すのでしょうか。
以下では、目標設定において重要な概念であるＫＧＩ/ＫＰＩについて説明した後、目標の紐づけの方法を示します。

「ＫＧＩ」「ＣＳＦ」「ＫＰＩ」の定義と関係
重要目標達成指標（ＫＧＩ：Key Goal Indicator）
政策目標等、プロジェクトの最終目標を達成するために管理すべき指標
重要成功要因（ＣＳＦ：Critical Success Factor）
ＫＧＩを達成する（成功させる）上で重要となる要因
重要成果指標（ＫＰＩ：Key Performance Indicator）
プロジェクトを推進し、新しいサービス・業務を実現することで重要目標達成指標を達成するために管理すべき指標

ここで、資格試験に合格するために勉強するという場面を想定して、これらの具体例を考えてみます。
資格試験の合格、すなわち「試験で 70 点以上取得」がこの場合のＫＧＩとなります。
では、このＫＧＩを達成するためのＣＳＦは何でしょうか。まずは、「十分な勉強時間を確保すること」（リソースの確保）が挙げられます。他には、自分の周りでこの資格を既に取得している人やこの資格の分野に詳しい人を見つけて質問できるようにしておき、「わからないことがあっても解決できるようにすること」（協力体制の確立）、「周りから邪魔されずに集中して勉強できる環境を確保すること」（阻害要因の排除）などが挙げられます。このように、ＣＳＦは、これらが揃えば確かに成功（目標を達成）しそうだと思える要因であることが大切です。
そして、ＫＰＩとして、「1 週間あたりの勉強時間：10 時間以上」、仕事が忙しくて勉強できないということがないように「1 週間あたりの残業時間：5 時間未満」などといった指標を設定します。ＫＰＩは、これらが達成されればＣＳＦ（ここでは「十分な勉強時間を確保すること」）が実現できたといえるような指標を設定します。
ＣＳＦは抽象的であるため、具体的に何をすれば良いのかわかりにくい場合がありますが、このようなＫＰＩを設定することで、自由時間を勉強に当てるだけでは 1 週間あた
り 3 時間ほど足りないので、さらに勉強時間を捻出するために通勤時間に電車の中でも勉強できるように準備をする、資格試験までの期間は業務量が多くなりすぎないよう
上司や同僚に相談するといった具体的なアクションを考えることができるようになりま

-

11 -

（第３編第２章 プロジェクトの管理）す。
このようなアクションを通じてＫＰＩが達成されると、「これらが揃えば確かに成功（目標を達成）しそうだと思える要因」であるＣＳＦが揃うので、ＫＧＩを達成できる可能性が高まります。

図 2-3[「ＫＧＩ」「ＣＳＦ」「ＫＰＩ」の関係

ＫＧＩ/ＫＰＩは設定するだけでは意味がありません。モニタリングを実施し、プロジェクトの目標の達成度合いを評価することが重要です。そのためにも、ＫＧＩ/ＫＰＩはどのように測定するかについてもあらかじめ検討し、計測できる指標を設定しましょう。
また、モニタリングは、目標の達成期日になってから実施するだけでなく、継続的に実施して変化の度合いを把握し、それが不十分である場合は改善策を実施することが必要です。そのため、モニタリングの実施頻度（実施時期）、各時点での目標値をあらかじめ定めておくことが重要です。
KGI/KPI を策定する際に、将来の目標だけを設定するというケースがあるのですが、これに加えて現状（プロジェクト開始時点の状態）の水準も把握することが重要です。現状とのギャップが分かるように、目標を設定します。
そして、そのＫＧＩ/ＫＰＩの策定には様々な手法が存在します。以下では、その例として「ＫＰＩトレーサビリティ・ツリー」と「ＢＳＣ（バランスト・スコアカード：Balanced Score
Card）」を用いてＫＧＩ/ＫＰＩを設定する手法を示します。

事例：ＫＰＩトレーサビリティ・ツリーによる目標の紐付けあるプロジェクトでは、国民向けに実施しているサービスをさらに向上させるために、政策目標（ＫＧＩ）に対して、複数の重要成功要因（ＣＳＦ）を設定し、さらに個々の重要成功要因に対して、プロジェクトの目標（ＫＰＩ）と紐付けました。
このことにより、プロジェクトが実現する個々のサービスや業務の改善内容が、全体としてどのような効果につながるかをＰＪＭＯ職員や関係者が共通に理解することができました。利用者（求職者・求人者）と職員の双方にメリットがある有効な目標を設定することができました。実際に行った作業を紹介します。
(1) 業務要件定義時点でのＫＧＩ・ＫＰＩのトレーサビリティの確保
まずは調達時にＰＪＭＯで準備し、整理してまとめておく必要がある項目・内容を、次のとおり抽出しました。
【政策目標（ＫＧＩ）】
利用者からの電子申請率の向上による、申請処理の迅速化及び事務負担軽減

-

12 -

事例 2-2
ＫＰＩトレーサビリティ・ツリーによる目標の紐付け（第３編第２章 プロジェクトの管理）【重要成功要因（ＣＳＦ）】
電子申請ページを利用しやすくする（どこにあるか見つけやすくし、ページの中
身自体もわかりやすくする）【重要成果指標（ＫＰＩ）】
利用者が目的のページに達するまでの状態遷移数：a 秒未満、n 画面以下
検索機能の処理能力：適合率 p%以上、再現率 r%以上、検索速度 s 秒未満
電子申請ページでの入力が完了するまでの時間：m 分未満
次に、これらの項目とＫＧＩを頂点とする紐づけを作成し、ツリー（木）の構造に似た形式で整理し、関係性を明らかにしました（下図）。これにより、情報システムの調達過程で「この機能（サービス）は何のために必要なのか？」「この機能の性能が不十分だった場合、どういった業務、ＫＧＩ/ＫＰＩに影響するのか？」などが把握しやすくな
り、目の前の作業だけにとらわれてそもそものゴールを見失うことを防ぎ、価値を生み出すＩＴガバナンスの実行に寄与することができました。

(2) 設計・開発時点でのＫＧＩ・ＫＰＩのトレーサビリティ確保
設計・開発時点で詳細化されていく項目・内容について、要件定義時点でのＫＧ
Ｉ・ＫＰＩのトレーサビリティ・ツリーを土台にし、同様にしてＫＧＩを頂点とした紐づけを相互に行い、ツリー（木）の構造に似た形式で整理し、関係性を明らかにしました（下
図）。

-

13 -

（第３編第２章 プロジェクトの管理）【要件定義書（情報システム要件定義書）】
要件定義書名：○○○要件定義書
業務カテゴリ、業務フローの名称：ＩＤ○○○
機能（サービス）詳細：
画面・帳票・バッチの名称：
画面・帳票・処理要件 など：【基本設計書】
基本設計書名：○○○基本設計書
基本設計書の記載箇所 など【詳細設計書】
詳細設計書名：○○○詳細設計書
詳細設計書の記載箇所 など【テスト計画書・仕様書】
テスト計画書・仕様書名：○○○テスト計画書・仕様書
テスト計画書・仕様書の記載箇所 など【その他】
課題管理、修正（履歴）管理
このＫＰＩトレーサビリティ・ツリーを用いて管理することにより、情報システムの設計・開発過程で「何のためにこの機能（サービス）は設計・開発しているのか？」「この機能の性能が不十分だった場合、どういった業務、ＫＧＩ/ＫＰＩに影響するのか？」などが把握しやすくなりました。
また、目の前の作業だけにとらわれてそもそものゴールを見失うことを防ぎ、価値を生み出すＩＴガバナンスの実行に寄与することができました。特に開発スケジュー
ルの中盤を過ぎると、各開発の現場は超近視眼的になり、周囲を考慮しない作業になりがちなため、トレーサビリティ・ツリーによって全体を俯瞰した視点で作業を実施できました。

-

14 -（第３編第２章 プロジェクトの管理）

参考：バランスト・スコアカードによる目標の紐付け

参考 2-1
バランスト・スコアカードによる目
標の紐づけ

バランスト・スコアカード（ＢＳＣ）は、目的を達成するためには、顧客（国民・利用者）にどのような価値を届けるべきか、そのために設けるべき業務プロセスとは何か、
その業務プロセスを行うために必要な人材・スキルとは何かというように｢成果の視点｣、｢顧客の視点｣、｢プロセスの視点｣、｢学習と成長の視点｣を段階的に整理することで、取りこぼしのないアクションにつなげるものです。
ＫＧＩ/ＫＰＩを設定する手法の例の 1 つとして、このＢＳＣを利用するイメージを以下に示します。この図のように段階的に整理することで、目的を達成するために行うべき重要な要因を浮き彫りにできます。これらの要因が、どの程度、達成できたかを計測する指標としてＫＧＩやＫＰＩを設けます。

※1 本来のＢＳＣでは「成果」 ではなく「財務」の視点であるが、政府においては「財務」の視点が必ずしも正しくないため、便宜上「成果」としています。
※2 案件の特性により、顧客の視点での設定内容が、ＫＧＩになるケースと、ＫＰＩとなるケースがあるため、ＫＧＩ/ＫＰＩと記載しています。

事例：トレーサビリティ・ツリー、ＢＳＣを利用したＫＧＩ/ＫＰＩ策定
ある農業関連システムにおけるＫＧＩ/ＫＰＩ策定事例を示します。
これまで、農業に関連する情報は関係機関ごとにバラバラに管理されており、来訪に赴く農業従事者には大きな負担でした。
そこでデジタル技術を活用して農業関連情報を統合し、一元的に管理できる情報
管理システムを設けて、申請の一元化・デジタル化により農業従事者が関係機関に来訪する負担を軽減しました。

-

15 -

事例 2-3
トレーサビリティ・ツリー、ＢＳＣを利用したＫＧＩ/ＫＰＩ策定

（第３編第２章 プロジェクトの管理）※

当事例では、農業従事者の負担軽減には、当該システム・サービスの利用・

-

16 -

（第３編第２章 プロジェクトの管理）普及が進まなければならないため、サービスの対象となる従事者が使いやすいユーザインタフェースを実装する必要がありました。そのためには、設計段階において農業従事者が利用しやすいユーザインタフェースの設計を行うとともに、達成度合いを測る指標（ＫＰＩ）を設けることが重要でした。

ＫＧＩ/ＫＰＩ策定にあたっての留意点
定量化できる指標であること
達成状況を正しく評価し、改善につなげるためＫＰＩは定量的な指標とする。
（「使いやすさ」といったあいまいで定量的ではないものは設定しない）
例） オンライン利用率、オンライン申請件数標
客観性のある指標であること
誰が見ても同じ内容で理解ができる客観的な指標とすること。
（ＫＧＩ/ＫＰＩを達成できるように、後から定義を変えないこと）
例) オンライン利用率、システム稼働率計測できる指標であること自動的に収集できるなど現実的な指標とすること。
例） ＷＥＢサイトのアクセスカウンターなど自動的に収集できるもの
効果につながる指標であること
ＫＰＩは効果を推計できる強い相関がある指標を選定すること。
（ＫＧＩが最終目標でＫＰＩがそれを測るための中間の指標となります。ＫＰＩの達成がＫＧＩの達成につながるかが重要です）
例） 業務実施部門の経費削減（ＫＧＩ）に対して、事務処理を自動化するシス
テム（ＲＰＡ等）の利用回数

２ 手段の妥当性を確認する
プロジェクトの立上げに当たって、プロジェクトの目標とする成果を定め、その成果を得るための手段が妥当であることを確認します。以下では、手段の妥当性を確認する観点について、例を示します。必ずしもこの分類で考える必要はありません。プロジェクトの特性、実状に応じて、本質的に確認すべき観点を事前に考えてみてください。

プロジェクト立上げ要否の検討
情報システムを整備する必要があるか。
例えば、現行の業務では、担当職員が国民からの問合せを属人的に管理する問合せ履歴に記録しており、部署内での情報共有がうまくいっていないという課題があるとする。
この業務を情報システム化するプロジェクトの立上げの妥当性を評価する
場合、そもそも情報システムを整備する必要があるのかを評価する。問合せ件数が少ない場合、情報システムを整備するのではなく、問合せ履歴を記録した Excel ファイルを部署内の誰もが参照・更新できるような運用

-

17 -

（第３編第２章 プロジェクトの管理）方法に変更する という選択肢もあり得る。なお、その際は、機械判読可能
な表記方法とすることに留意すること。
また、業務によっては現行の業務から変更しないという選択肢も合わせて検討する。
サービス・業務の見直し有無の確認
サービス・業務改革（BPR）の実施を検討しているか。
プロジェクトのライフサイクルの中でも、新規のプロジェクトの立上げの段
階は、サービス・業務の見直しを行う好機である。そのため、見直しに当たっては、現行の業務内容を踏襲するのではなく、サービス・業務改革（BPR）を実施することが重要である。
プロジェクトの妥当性の評価においては、サービス・業務改革（BPR）の実施にあたり、「第４章 Step. 2-1-A 心構えと視点（サービス設計 12 か条）を理解する」で示すサービス設計 12 か条の心構えと視点に基づいてサービス・業務企画を実施する計画となっているかを評価する。
政府・府省方針との整合性や利用する技術の妥当性の確認
クラウド・バイ・デフォルトの原則に沿って検討しているか。
情報システムの整備に当たっては、クラウドサービスの利用を第一候補として検討する。プロジェクトの妥当性の評価においては、「政府情報システ
ムにおけるクラウドサービスの適切な利用に係る基本方針」に基づいて、適切にクラウドサービスの利用を検討する計画となっているかを評価する。
共通機能等の利用を想定しているか。
情報システムをすべて新たに構築するのではなく、デジタル庁で整備している共通機能や自府省で整備している省内共通基盤等 を利用すること
で、設計・開発期間を短縮し、整備経費を抑えられる可能性がある。
プロジェクトの妥当性の評価においては、これらの共通機能等の利用を検討する計画となっているかを評価する。
政府内の類似システムや民間サービスの活用を検討しているか。
情報システムを新たに構築しなくとも、政府内の既存の類似システムや民間企業が提供しているサービスをそのまま利用することができれば、設計・開発に要する時間やコストをなくすことができる。そのまま利用できないま
でも、既存システムの機能拡張によって利用できるのであれば、設計・開発を最小化して、整備経費を抑えられる可能性がある。
プロジェクトの妥当性の評価においては、プロジェクトで実現しようとしている情報システムと類似の既存システムやサービスの有無を調査し、利用を検討する計画となっているかを評価する。
事業者の提案内容を鵜呑みにしていないか。
ＰＪМＯはシステム化の方法を事業者に相談する場合に、事業者は自社の機器やソリューション等の利用を前提とした提案をすることが想定される。1
社の提案内容を鵜呑みにすると、他の事業者では実現できず競争を阻害
したり、他の事業者からより良い実現方法の提案を受けられなかったりする可能性がある。
プロジェクトの妥当性の評価においては、特定の事業者の機器やソリュー

-

18 -

参考 2-2
統計表における機械判読可能なデータ作成に関する表記方法
https://www.soumu.go.jp/main_co
ntent/000723626.pdf

（第３編第２章 プロジェクトの管理）

ション等の利用を前提とした提案内容を鵜呑みにするのではなく、プロジ
ェクトの目的を踏まえて、より良い実現方法を検討する計画となっているかを評価する。
技術的な実現可能性を考慮しているか。
これまで利用実績の少ない技術を用いて情報システムの整備を検討する
際に、技術的な実現可能性を判断することが困難な場合がある。その場
合、情報システムの設計・開発を行う前に概念検証（PoC）を実施するなどして、当該技術の実現可能性を評価することができる。
プロジェクトの妥当性の評価においては、技術的な実現可能性を考慮して、プロジェクトを推進する計画となっているかを評価する。また、技術的な実現可能性だけでなく、関係システムや関係者に対して導入する情報システムへ円滑に移行できるように、関係者への支援体制の確立、スケジ
ュールの共有、説明資料の提供や問合せへの対応なども十分に考慮されている計画となっているかを確認する。

３ プロジェクトの投資対効果を算出する【標準ガイドライン関連箇所：第３編第２章第１節 1)】

標準ガイドラインでは、情報システムの整備を投資的整備と維持的整備に分けています。
投資的整備／維持的整備と投資対効果の評価方法の詳細は、標準ガイドライン解説書「第2 章 １．プロジェクトの立ち上げ及び初動 （２）立ち上げの承認」を参照して下さい。情報システム整備のうち投資的整備に該当する案件は、国民・利用者の利便性向上・負担軽減等の効果を得ることを目的としているため、投資対効果をしっかりと精査・評価していくことが重要になります。投資対効果の精緻な算出は、「第４章 Step．5-2-G 精緻に効果を積算し、主要な効果を実感可能なものとする」で示した考え方に従い、プロジェクトを推進しながら、予算要求までに実施します。プロジェクトの立上げ時にも同様の考え方を踏まえるとともに、以下の留意事項に沿って、投資対効果の概算を見定めることが重要です。

投資対効果の算出における留意事項
投資額の算出
投資対効果を算出するためには、情報システムに係る経費のうち、いくらが投資額となるのか算出する必要があります。
調達案件ごとに投資的整備のみに該当するか否かを分類できれば簡単なのですが、実際にはそうならず、一つの調達案件に投資的整備に当たるものと、それ以外に当たるものが混在していることが一般的です。
そのため、目的に応じて、経費を投資的整備に該当する経費と投資以外の経費へ分類することが必要となりますが、その分類が難しい場合は、以下の(ア)(イ)を参考に投資額の内訳を算出することを検討してみましょう。
(ア) 情報システムの特性等から分類します。
例えば、機能改修を行う際に、投資的整備に分類される改修は独立性の高いサブシステムに対するものに限定され、それ以外の整備と区別して見積りを取得できる場合などが該当します。サブシステム単位で投資
的整備、維持的整備が分類しやすい場合は、サブシステムで分類する。
このようにサブシステム単位で分類できない場合は、改修する機能の単位で分類する。

-

19 -（第３編第２章 プロジェクトの管理）(イ) 見積もりの中で整備、維持を分けられない場合は、（ア）のように明確な区別ができない場合は、画面数、業務数、職員数、開発規模など、それぞれの実情に見合った数値を使って、全体に対しどれだけの比率を占めるか計算し、その比率で経費全体を按分して算出します。
例えば、投資的整備に該当する改修を行う画面数が 40、維持的整備に該当する改修を行う画面数が 60 である場合、投資額は経費全体の 4 割とします。
ライフサイクル全体における経費の考慮
機能改修の考慮
情報システムを整備しても、予見していない環境の変化等により期待した効果が得られない場合もあります。
そのため、情報システム稼働後に、期待した効果が継続的に得られるよう、必要に応じて機能の追加や改修を行うことが重要です。
このような機能の追加や改修は当初のプロジェクト計画を補完するものと考え、それにかかる経費や効果を織り込んで投資対効果を算出してください。
情報システムの利用促進
情報システムの整備による効果を得るために、その情報システムの利用の普及が必要である場合は、十分な効果が現れるまでに時間がかかる傾向があります。そのような場合に高い投資対効果を得るには、情報システムの構築だけ
でなく、効果的な広報活動など、情報システムの利用を促進する施策を考慮する必要があります。

４ プロジェクトへの投資判断を行う【標準ガイドライン関連箇所：第３編第２章第１節 2)】

プロジェクトへの投資判断と、予算要求（査定）との違いがわかるでしょうか。
プロジェクトへの投資判断は、プロジェクトの目標とする成果を明確にした上で、その成果を得るために必要となる経費や人的資源等を見積り、その費用対効果を踏まえた上でプロジェクトを開始することを責任者が意思決定することです。
一方で、予算要求とは、プロジェクトへの投資判断が行われていることを前提として、翌年度以降に必要となる所要額を見積り、所要額の妥当性の観点から査定を受けるものです。確かに、予算査定過程でもプロジェクトの目的や想定効果を確認しますが、これは予算要求部
局内での投資判断がなされていることを前提に、その判断結果を第三者の観点から再確認
するプロセスと言えます。
ただ、この点については政府の中では誤解されがちなポイントでもあります。とりあえず予算を要求してみて、予算が通ったらプロジェクトの進め方を考えるという人も少なくないかもしれません。また、実際に新規に立ち上げるプロジェクトでは、投資判断と予算要求のタイミングが重なることも多いため、これらの違いを明確に意識しないことが多いかもしれません。
しかし、これでは、あるべき順序が逆転しています。標準ガイドラインでも、「デジタル統括
責任者は、プロジェクトの新規立ち上げに当たって、目標設定及び、手段の妥当性、費用対効果を確認し、その承認を行い、プロジェクト推進責任者及び当該プロジェクトに関する情報

-

20 -

（第３編第２章 プロジェクトの管理）

システム責任者を指名するものとする」としています。予算要求よりも前の時点でプロジェクトを立ち上げ、デジタル統括責任者が承認することをルールとして求めています。
プロジェクトの立ち上げに当たっては、目標とする成果、その達成方法（手段）、概算での費用に基づく費用対効果を明確にして、デジタル統括責任者の承認を通して投資判断を確実に行うようにしてください。このうち費用対効果は、会計検査院の検査でも用いられている３Ｅ（経済性、効率性、有効性）の観点で確認することが重要です。３Ｅの観点を踏まえた費用対効果の確認については、「第 4 章 Step. 5-1-A.参考：３Ｅの観点を踏まえた費用対効果の確認」を参照してください。

５ 機能する体制を作る【標準ガイドライン関連箇所：第３編第２章第１節３)】

プロジェクトの体制構築は、プロジェクトの命運を分ける大事な準備事項です。プロジェクトの初期に十分な体制を構築できずに、結果としてプロジェクトの円滑な運営を行えないケースは残念ながら少なくありません。
プロジェクトの体制構築についてのポイントを見ていきましょう。

A. 制度所管部門、業務実施部門等を含めたＰＪＭＯ体制とする「ルールは変えられないから、今のルールを前提にどう工夫できるか考えよう」、「業務実
施部門に業務のやり方を変えてほしいと頼んでも、聞く耳を持ってくれない」。情報システ
ムを主として担当する組織にいると、このような会話を耳にすることがあるかもしれません。
しかし、制度面でも業務面でも今のやり方を変えないのであれば、たとえ素晴らしいシス
テムを作ったとしてもその効果はかなり限定的になってしまいます。
情報システムを整備するプロジェクトでは、情報システム部門が中心となると捉えられがちです。しかし、利用者視点でサービス・業務改革を推進していくためには、制度設計の責任を持つ制度所管部門、業務の実施を行う業務実施部門もＰＪＭＯに参画し、それぞれが協働してプロジェクトを進めていく必要があります。
また、制度所管部門、業務実施部門、情報システム部門を含むＰＪＭＯを組織しても、それぞれがあまり連携せずに、別々に動いてしまうことも多々あります。互いが密接に連携しなければ、実態に沿ったサービス・業務を行うための制度設計や適した情報システムを構築することはできません。
そのため、それぞれの部門が適切に情報を連携できるよう、会議やコミュニケーションのルール等を整備することも重要です。また、政策目的やプロジェクトの目標・目的を踏まえて、各々の役割と責任を確認し、サービス・業務改革の意識を醸成するための活動として、最初にＰＪＭＯのメンバー全員を集めてキックオフを実施することも大切です。

事例：制度・業務・システムの三位一体のプロジェクト体制
ある省において大規模な情報システムを運用していましたが、情報システム部門と制度所管部門・業務実施部門とは異なるロケーションにあることもあり、双方の職員がコミュニケーションを行う機会は限定的になっていました。
そのような中で、情報システムの次期更改のタイミングに合わせて、一層のサービスの向上や運用コストの削減を目的として、業務・システムの見直しを実施することにしました。プロジェクトを立ち上げた当初は、情報システム部門が中心となって検討を

-

21 -

事例 2-4
制度・業務・システムの三位一体のプロジェクト体制

（第３編第２章 プロジェクトの管理）進めました。しかし、全体をとりまとめて推進する役割や、業務について検討すべき
項目ごとの担当が不明確であったため、制度所管部門や業務実施部門からの積極的な理解が得られないなど関係者の調整が難航し、プロジェクトがうまく進みませんでした。
そこで、プロジェクトの体制を大幅に見直すこととしました。制度、業務、システムが「三位一体」となってサービスを改革することを目指し、それぞれの部門の職員を含めて統合管理チーム、業務・機能検討チーム、アーキテクチャ検討チーム等のチームを結成し、局長をトップとした意思決定組織を作ることで全体を統括した意思決定を行えるようにしました。

このような三位一体のプロジェクト体制を構築したことで、各部門の職員がコミュニ
ケーションを緊密に実施できるようになり、解決すべき問題が発生したときにも幹部まで問題内容がエスカレーションされて意思決定を行えるようになり、円滑にプロジェクトを運営できるようになりました。

B. プロジェクトの規模に見合った体制を組む
利用者や関係者が多いプロジェクトでは、情報システムの１つの機能を決めるに当たってもきめ細かな調整が必要になりますし、情報システムを運用する中で利用者からの問合せや要望等に応えながら情報システムを改善していく業務にも大きな労力が必要です。また、多額の経費を投資するプロジェクトでは、情報システム構築や運用が事業者任せにならないように、情報システムの構成や運用状況を常時把握して、課題への対応方針を決め、必要となる経費の妥当性を判断することが必要になります。
このような業務を円滑に実施していくためには、ＰＪＭＯに担当者を十分に配置することが不可欠です。

参考：ＰＪＭＯの主要業務
プロジェクトがどのような段階であるかによっても異なりますが、ＰＪＭＯには様々な業務に対応することが求められます。代表的な業務を例示します。

-

22 -

参考 2-3ＰＪＭＯの主要業務

（第３編第２章 プロジェクトの管理）＜総括＞
プロジェクトの立上げ、体制確立、組織運営ルール作成、執務環境整備
調達計画作成、見積り依頼、見積り精査
予算要求資料作成、予算に関する関係者折衝
政府全体方針、各省方針等との整合確認、各計画のフォローアップ対応
監査等への対応
プロジェクトのモニタリング＜企画＞
利用者のニーズ把握、利用者調査、要望やクレーム等の分析
業務の現状把握と分析、業務フロー等の可視化、実績データ分析
利用者分析、業務分析結果を踏まえたサービス・業務企画
今後の改善内容について、他府省、他組織等との折衝
外部関係者を交えた検討会、内部職員での検討会議等、各種会議運営
企画内容のとりまとめ、関係者への説明
業務要件、機能要件、非機能要件等の各種ドキュメントの作成＜調達＞
調達仕様書等の作成、評価基準や評価体制の準備、会計担当部門との調整
提案評価、プレゼンテーションの審査＜開発管理＞
開発事業者の実施計画の確認・承認、スケジュール等の詳細調整
課題調整会議等での課題管理・調整、進捗報告会議等での進捗管理
設計等各種会議での検討、関係者の合意形成、設計書等各ドキュメントの承認
外部組織等との設計内容、連携方式、テスト方式等の調整
テスト計画、テスト実施結果等の作成、確認
移行計画、移行作業等の実施、運用計画・保守計画の作成
利用者への事前連絡、マニュアル作成、研修等の実施＜業務運営、保守と運用＞業務実施状況の確認、課題要望管理、プロジェクトの目標達成状況モニタリング
システムの運用（監視アラート対応、バッチ処理、バックアップ、定期作業等）
アプリケーション保守（要件確認、テスト結果確認、リリース管理等）
利用者・関係者との調整、利用状況確認、利用上の問題発生対応
システム障害への一次対応・根本対応、インシデント管理
ヘルプデスク等での問合せ受付、ＦＡＱ等のとりまとめと更新
アクセスログ等の分析、指標管理、改善点検討
ソフトウェア等のサポート期限等の管理、パッチ等の適用
コスト削減の検討、今後のシステム改修や次期システム更改に向けた検討
システムの規模にもよりますが、このような多種多様な業務をこなすには十分な数の職員を専任でＰＪＭＯに配置することが必要になります。

ＰＪＭＯに十分な数の職員を配置できないと、どのようなことが発生してしまうでしょうか。

-

23 -

（第３編第２章 プロジェクトの管理）

人数が少なかったり、他の仕事と兼任でＰＪＭＯの仕事に専念できないと、予算要求や調達等の必要不可欠な作業を実施するだけで精一杯となり、利用者分析、現状分析、要望分
析、実績データ分析等の本質的な業務にまで手が回らなくなります。その結果、システム
だけは出来上がっても、想定していた効果を出すことができません。
例えば、次のように「本末転倒な」事態が発生してしまいます。
サービス利用者が不便を感じる
情報システムの画面構成がわかりにくく、ヘルプデスクに問合せを行っても混雑して電話がつながらず、申請した手続がいつ回答されるかがわからない・・・。ＰＪＭＯの体制が少ないと事前分析が不十分になるため使いにくい情報システムができてしまい、そのサポートも十分にできないといった形で、サービス利用者に大きなストレスをかけてしまいます。
業務実施部門の業務効率が悪化する
情報システムに機能が不足していて、システム外の手作業で様々な追加作業を行う必要がある、情報システムにトラブルが頻発してなかなか解決されない・・・。現場で発生している課題を解決するための情報システムであるはずなのに、逆に業務実施部門の負担を増やしてしまいます。
ＰＪＭＯの担当職員が疲弊する
利用者や業務実施部門からの要望や苦情に追われる一方で、システム関連事業者からは対応が難しいと主張される・・・。このように板挟みの状況の中で、仕事が山積みになり担当職員が疲弊してしまいます。
使われない情報システムに、経費ばかりがかかる
システム関連事業者への依存体質が定着してしまい、小規模なシステム改修にも多額の経費を請求され、その経費妥当性を担当職員が判断できないため事業者の見積金額のまま予算要求をせざるを得ない・・・。利用者から業務実
施部門から評判の悪い情報システムにもかかわらず、経費だけは膨らんでいくという事態になりかねません。
プロジェクトにトラブルが起こり始めてから担当職員を追加しても、なかなか本質的な解
決はできません。例示したような事態を避けるためには、プロジェクトを立ち上げる当初から
ＰＪＭＯに十分な体制を準備することが不可欠です。
では、何人の体制を準備すればよいか。それは、関係者の多さやプロジェクトの特性によるので一概には言えません。実質的に１人の職員で回すことができる小規模プロジェクトもありますし、100 名以上の体制を組む大規模プロジェクトもあります。
ただ、毎年数億円や数十億円といった経費を使う大規模プロジェクトにもかかわらずＰＪ
ＭＯの人数が数名しかいないという体制も見受けられますが、それではさすがに人数が少なすぎるように思います。恐らく、このような体制ではシステムの運用維持や必要最小限の予算要求と調達を実施することで忙殺されてしまい、とても利用者の要望に応えながらサービス・業務の改善点を検討するような時間を捻出できなくなってしまいます。制度所管部門、業務実施部門等の職員を加えて、ＰＪＭＯの体制を強化することが望まれます。なお、
内部人材で体制を確立するだけでなく、ＩＴ業界等での経験がある外部人材を任期付職員
等の形で採用しているＰＪＭＯもあります。
プロジェクトの規模や特性によって差異はありますが、ＰＪＭＯに数名の職員を追加したとしても、業務実施部門の業務効率を考えるとその何倍もの効果があるはずです。また、情報システムの経費面でも大きな効果があるはずです。プロジェクトが目指す成果に応じて、

-

24 -

（第３編第２章 プロジェクトの管理）

その成果を達成するために十分な体制を組むことが、結果としてサービスの向上と行政の効率化につながるといえます。
また、ＰＪＭＯの体制を組む際には、ＰＭＯにも相談してみてください。重要なプロジェクトについては、ＰＭＯ職員も直接ＰＪＭＯ体制に含めて、定例会で情報を共有したり、課題への解決方法を一緒に検討したりすることもできます。また、大きな問題が発生しているときには、デジタル統括責任者、副デジタル統括責任者へ相談を持ち掛けやすくなり、早期に問題への対応を行えるようになります。

C. 他組織と連携できる体制を作る
利用者視点、つまり利用者にとってエンドツーエンドの観点でサービスを改善するということは、裏を返すと多くの組織にまたがって業務を見直すことにほかなりません。
ＰＪＭＯには制度所管部門、業務実施部門を含めた体制としています。ただ、ここでいう制度所管部門、業務実施部門とは、あくまでプロジェクトの「中心」となる制度や業務を担当する部門です。利用者の視点でサービスを見渡すと、これらの部門以外にも様々な組織が直接的、間接的に連携していることがわかります。これらの関係者については、プロジェ
クト管理要領でステークホルダーとして定義した上で、プロジェクトへの関わり方を決めていきます。
さて、ステークホルダーと一口で言っても、同じ省内の他局である場合もあれば、他府
省、他組織（民間企業、自治体、独立行政法人等）であることもあり、様々な関係者が存在します。実際には、これらの組織を横断して問題提起を行い、解決方策をまとめることは大変難しいものです。しかし、関係する組織間の調整や協力を行わずにプロジェクトを進めても、サービス・業務改革は成し得ません。
ステークホルダーの多いプロジェクトを円滑に進めるためには、次のことが特に重要となります。
各組織の責任者の連携体制を作る
プロジェクトの普段の活動では、各組織の担当者間で調整を行います。ただ、調整が難航した際に、担当者レベルで検討が止まってしまうということが往々にして発生しがちです。
この点は重要なので、強調します。実際に多くのプロジェクトで、このような担当者レベルでの検討停滞が頻発しています。「うちは基盤システムだから、個々の情報システムへの個別対応は行わない」、「今回例外対応を認めると先例になるため、そのような対応は行わない」、「当方の所管範囲を超えることなので、何もできない」、このように様々な理由を述べながら、担当者レベルで検討が停止してしまうという事態は頻繁に発生します。
組織をまたいで業務改革を行うためには、このような停滞が発生したときに問題解決の場を一段、二段と上に上げて、各部門の責任者レベルで対応方法を検討できるようにすることが有効です。プロジェクトの体制として関係部門の責任者を明確に記載した上で、状況に応じて責任者本人が会議に出席して調整や意思決定を行う場を作ることが重要です。
発生した課題をエスカレーションできる仕組みを作る
上記のような責任者による連携体制を機能させるためには、プロジェクトの普段の活動の中で、以下の両方のルートを確立することが必要です。
１つ目が、ＰＪＭＯ自身の課題管理を起点とするルートです。各ステークホルダ
ーとの折衝状況や発生課題を管理し、解決が困難な課題についてはＰＪＭＯからエスカレーション（上位者への情報連携）を行い、関係する組織の責任者

-

25 -

（第３編第２章 プロジェクトの管理）との折衝を行います。
２つ目が、関係する各組織からの意見を起点とするルートです。プロジェクトの検討内容やＰＪＭＯのプロジェクト推進方法に課題があると認識した際に、各組織からＰＪＭＯやステークホルダー全体に対して意見提起を行えることが必要です。
特に、２つ目のルートについては明示的に設定されていない例も多く見られます。しかし、関係する各組織がプロジェクトに対して課題や不安を抱えたまま、その状況を正式に伝える窓口が存在しないと、その課題が解決されないままにプロジェクトが進行してしまいます。課題、要望、意見等について提起を行える連絡窓口や連絡方法について明示的に設定するとともに、集まった意見等については定例会議等の場で意見交換を行える仕組みを作ることが望まれます。
状況を早期に関係者へ共有する
プロジェクトを推進するＰＪＭＯ側の立場では、様々な情報について検討段階
で関係者へ共有するのではなく、正式決定後に初めて共有するというやり方になってしまいがちです。事前に共有した情報に変更が発生すると、変更内
容の再連絡や意見調整に手間がかかるということが、その一番の理由でしょう。
一方で、プロジェクトの影響を受ける関係者側の立場では、検討段階でも構わないので現時点の検討概要を早く知りたいと考えることが多くなります。「自身が管理する情報システムの改修が見込まれるため、影響範囲を調査するために現時点の要件定義内容を知りたい」、「テスト計画を作成するため、現時点のインタフェース設計内容を知りたい」、「体制を組むために、テストの実施時
期や内容を知りたい」等、理由は様々ですが、検討中の内容を早く知りたいというのが関係者側の強い要望となることが多いです。
このような要望が発生することを踏まえて、関係者に影響を与える検討内容については、この内容が検討中のものであるというステータス情報と今後の検討
スケジュールを明確にした上で事前共有を行い、関係者からの意見も取り込
みながら最終的に正式内容を共有するといった形で、数度にわたって段階的に行うことが望まれます。
また、大規模なプロジェクトでは提供するドキュメントが多量になるため、ドキュ
メントを種類別、内容別等で検索しやすくするような情報共有ツールを活用することも有効です。

事例：情報共有ツールによる関係者への情報共有あるプロジェクトでは、各府省に多数の利用者や関係者がいるため、情報共有ツールを導入しました。
このツールは、Web ブラウザ上でファイルサーバのようにファイルを共有することができ、このツールのＩＤを持っている職員は各府省のＬＡＮ端末からすぐにアクセスすることができます。このツールに、関係者向けに開催する会議資料、設計書やマニュアル等のドキュメント、各組織とのやりとりに用いる連絡票や課題管理表など、関係者の権限に応じて様々なドキュメントを参照、検索できるようにしました。このツールによって、過去の資料でも簡単に検索することができ、関係者間の情報共有が非常に便利になりました。

-

26 -

事例 2-5
情報共有ツールによる関係者への情報共有（第３編第２章 プロジェクトの管理）

また、ある別のプロジェクトでも、政府内部だけでなく民間企業、自治体等の多数の外部関係者に影響を与える大規模な計画内容であったため、ＩＤを持っている人はインターネット経由で同様に各種ドキュメントを検索できるツールを導入しました。
多くの関係者が存在するプロジェクトでは、会議の度にメール等で資料を送付するような方式では、資料を受領する側でも資料全体を管理しきれません。このような情報共有ツールは比較的安価に導入でき効果も大きいので、利用することを検討してみてください。

事例：原則にとらわれない環境作り
インターネットを通じたコミュニケーションツールは、「約款によるサービス」に当たるため原則利用が禁止されています。しかし、目的に鑑み、リスクが少ないと情報セキュリティ責任者が判断できれば、ツールを利用することは可能です。
あるプロジェクトでアジャイル開発を推進するに当たり、複数の府省と民間企業十数社が参画する体制で、関係者間で密にコミュニケーションを図る必要がありました。特にこのプロジェクトではアジャイル開発を採用して短期間で機能開発や改善を進める必要があるため、職員と開発事業者が、柔軟にコミュニケーションをとれる体制が不可欠でした。そこで、このプロジェクトではコミュニケーションツールの利用目的を明確にした上でリスク評価を行い、情報セキュリティ責任者判断のもとでツールを導入し、アジャイル開発に求められる早いサイクルでの設計、開発、評価の繰り返しをスムーズに行うことができ、利用者の満足度が高いシステムを構築できました。
「原則禁止」、「前例がない」というだけで選択肢をせばめてしまうのではな
く、目的達成のために有用な手段なのであれば、その手段を利用するリスクについて評価を行った上で、その利用について情報セキュリティ責任者の承認を得ることを検討しましょう。まずはサービス・業務目的をどうすれば効率的かつ効果的に達成できるかからはじめ、十分に検討した上で「前例を作っていく」ことが重要です。

D. 先行経験を持つ人のノウハウを活用する
多くの人が同じ苦労をするというのは、とても非効率な状態です。
ただ、システムの導入順序や体制をうまく整備しないと、こういった無駄なことが起こってしまいます。なぜだかわかりますか。
例えば、全国 100 拠点に全く新しいシステムを一斉に導入するとします。各拠点で、今までは紙で事務処理していた作業を、今後は新しいシステムで実施することになりました。
ところが、現場には様々な例外処理があります。登録済の内容を過去に遡及して修正す
るにはどうすればよいか、月末までに処理を間に合わせてほしいという希望にどう対応する
か、今までは紙処理で当たり前のように実施していた業務を、システムではどう実施すべきなのか、各拠点の職員はそれぞれが同じような問題に突き当たり、その解決策をそれぞれが苦労しながら考えます。その結果、拠点によって事務処理方法やシステム利用方法もバ
ラバラになってしまい、拠点間を人事異動した職員が業務実施方法の違いに戸惑うような状態になってしまいます。

-

27 -

事例 2-6
原則にとらわれない環境作り

（第３編第２章 プロジェクトの管理）

もちろん、システムの企画、要件定義、設計等の段階で、業務での例外処理も含めたあらゆる状況を想定してシステム機能を作り、業務マニュアル等を充実させるのが理想的な状態です。ただ、このようにあらゆる状況を想定し尽くせなかったとしても、体制面で工夫を行えるのです。
まず、先行的に数拠点の現場で、システム導入を実施します。そして、その拠点でシス
テムへの対応方法を経験して様々な例外処理等への対応方法にも知悉した職員のノウハ
ウを、他の拠点でも活かすのです。他拠点の職員にとっては初めて遭遇する問題でも、最初の拠点の職員にとっては既に馴染みのある問題であることが多いでしょう。非常に効率的に、問題を解決し、対応方法を決めることができるようになります。
このような機動的な体制を組む際の障害は、人事面でしょう。地方拠点の職員を、システ
ムの導入状況に合わせて次々に人事異動させていくのは現実的には困難かもしれません。ただ、人事異動までは行わなくても、短期間の出張での対応でも構いませんし、電話やメールでの相談だけでも良いかもしれません。
重要なことは、組織の縦割りでの役割分担にとらわれず、先行経験を持つ人のノウハウを後続での作業に活かしていくことです。

事例 2-7
府省を跨った特別移行支援チーム

事例：府省を跨った特別移行支援チーム
各府省が共通で利用する、ある政府情報システムでは、府省単位で移行スケジュールを決めて段階的に当該システムへの移行を進めていました。移行に際しては、移行計画の作成、データの整備、エラーへの対応など様々な作業が必要になりますが、初期の段階では各府省の担当者がそれぞれに苦労しながら移行作業を進めていました。しかし、このような体制では、各府省で苦労をした人の経験が今後移行をする府省には受け継がれません。
そこで、府省を横断した形での「特別移行支援チーム」を結成することとしました。
このチームには、このシステムへの移行経験や業務実施経験が豊富なベテラン職員を十数名配置しました。なお、これらベテラン職員は、当然ながら各府省においても重要な戦力なので、移行支援だけに専念することも困難でした。そこで、各府省においては従来の業務も実施しながらこの特別移行支援チームの業務もできるように、体制を工夫しました。
■ 特別移行支援チーム体制

特別移行支援チーム

担当府省（PJMO）

移行支援ベンダ・利用府省 （移行経験を有する職員、システム的知識を有する職員）
・担当府省（PJMO）から選抜

・ 移 行総合プランの作成
・ 各 種マニュアルの改訂
・ 移 行データの全体管理
・ 運 用センタとのやり取り

人的サポート

重点サポート・ イン シデント分析・ 各 種研修等の実施

物的サポート・移行ノウハウが集約された担当者目線の移行マニュア
ルの提供
・移行前の研修環境の提供

府省に赴き計画策定から移行、さらには本番稼働後の具体の助言を提供

その他府省

移行ノウハウが少ない小規模府省移行に関し、計画段階からのノウハウが少ない小規模府省は直接サポート

直接サポート凡例■ 特別移行支援チーム役割（例）
プラン作成・研修等支援（Ｈ２７）

・勉強会・研修の講師等必要な支援・移行計画書・調達仕様書作成支援
・平成28年度導入に向けた総合プラン作成の支援
・移行マニュアル作成支援

移行サポート（Ｈ２８）・移行に関する直接的なサポート・移行に困難を極めている府省の分析及び直接サポート

必要に応じたサポート

本番稼働サポート（Ｈ２９）・本番稼働後の状況に応じて、経験等に基づいたサポート

この特別移行支援チームは、これから移行を行う組織の職員向けに何度も勉強会

-

28 -

（第３編第２章 プロジェクトの管理）を開催したり、個別の相談に乗ったり、様々な支援を行いました。
その結果、短期間で効率的に、全府省がこのシステムへの移行を完了することができました。

-

29 -（第３編第２章 プロジェクトの管理）

Step.

3 プロジェクト計画書等の作成

プロジェクトの目標とする成果や体制等を決めた後は、今後のプロジェクトの実施方法を検討し、プロジェクト計画書、プロジェクト管理要領として明文化します。プロジェクト計画書はプ
ロジェクトで「実施する内容とその目的・目標」を記すのに対して、プロジェクト管理要領はその「実施に係るルール」を定義するものです。
プロジェクト計画書は、プロジェクトのライフサイクルを通じて達成すべき成果を明確にし、各工程における意思決定や関係者との合意における指針として参照することにより、プロジェ
クト本来の目的に対して最大の成果を発揮することを目指す上で欠かせないものです。
情報システムのプロジェクトは長期にわたり、また多くの組織や担当者が関わるため、実施するプロジェクトの目的や内容に関して明文化されたプロジェクト計画書を拠り所にすること
で、主要なステークホルダー間で共通理解を形成することが必要です。また、どのようなプロジェクトであっても、途中段階で要件変更等を余儀なくされることがありますが、そうした場合
でもプロジェクト計画書に明記された本来の目的を見失わず、目標を達成できているかモニ
タリングと改善を繰り返すことにより、政策目的実現のために最大限の成果を発揮することが可能になります。このように、プロジェクトのライフサイクルを通してプロジェクト計画書を中心に据えた考え方に基づいてプロジェクト運営を推進することにより、手戻りを減らし、さまざまな制約がある中でも目的に対して最大の成果を発揮することを目指します。
プロジェクトには外部関係者（利用者、関連する公的機関や民間企業等）、内部関係者（システムの利用者となる職員、関連する各部門）、内部の推進体制（各省 PMO やデジタル庁
等）、プロジェクトに関連する各種事業者等、様々なステークホルダーが存在します（第 2 章
プロジェクトの管理 Step.２ プロジェクトの立上げ、初動 ３ 機能する体制を作る Ｃ．他組織と連携できる体制を作る を参照）。これらの多種多様な関係者、そしてＰＪＭＯ内部の職員も含めて様々な局面で合意形成を図る際に、プロジェクトの目標や推進状況を的確に説明するための中心となるのがプロジェクト計画書です。プロジェクト計画書の記載の中から、個々の関係者が知りたい内容を抜粋して伝えることができるように、原典となる方針や進め方をプ
ロジェクト計画書に一元的に集約することで、プロジェクトの姿を矛盾なく効率的に説明できるようになります。
プロジェクト計画書及びプロジェクト管理要領の２つのドキュメントについて、記載項目やポ
イントとなる点を見ていきましょう。

１ プロジェクト計画書を作成する【標準ガイドライン関連箇所：第３編第２章第２節 1)】

プロジェクト計画書を中心に据えたプロジェクト運営を推進するためには、プロジェクト計画
書を適切に作成・更新していく必要があります。
この実践ガイドブックには、別添としてプロジェクト計画書のひな形を示しています。

-

30 -

（第３編第２章 プロジェクトの管理）

様式例：プロジェクト計画書のひな形
プロジェクト計画書のひな形を本章別紙としてまとめています。

このひな形はあくまで例示ですので、プロジェクト内容に応じて記載内容を個別に追加、変更して構いません。
以降では、プロジェクト計画書を作成するときに、特に注意が必要なポイントについて説明
していきます。

A. プロジェクト計画書は段階的に詳細化する
プロジェクト計画書は定義する内容が多く、作るのが大変そうだという印象があるかもしれません。たしかに、プロジェクトは、長期間にわたって多数の活動を行うため、全ての活動を隅から隅まで定義するのは大変労力がかかります。
でも、安心してください。プロジェクト計画書は、最初から全ての計画の詳細を記載する
ものではなく、段階を踏んで徐々に詳細化していくものだからです。初期の段階のプロジェ
クト計画書は、各項目についての概要を記載した上で、各項目の詳細化を行うタイミングを計画します。

-

31 -様式例 2-1
プロジェクト計画書のひな形

（第３編第２章 プロジェクトの管理）

図 2-4
プロジェクト計画書の段階的な詳
細化のイメージ

なお、プロジェクト計画書を詳細化していくと記載量が増加していきますので、１つのドキ
ュメントとして維持していくと、少し読みにくくなってしまいます。
そこで、詳細化を行う中では、別紙構成としたり、サブプロジェクト計画書を切り出したりといった形で、プロジェクト計画書の本体に追加していくことを推奨します。プロジェクト計画
書の本体には、追加した記載内容の要点と別紙への参照を記載していきます。こうすることで、プロジェクト計画書は詳細化が進むにしたがってプロジェクト全体の概要を示す目次のようになっていきます。

図 2-5
詳細化されたプロジェクト計画書のイメージ

ただし、詳細化の結果として、計画全体に係る変更がある場合は、変更管理の手順に従った上で、その内容を各項目に反映していく必要があることを忘れないでください。
また、プロジェクトの実務作業が忙しくなっていくと、プロジェクト計画書の更新がなおざりになってしまうこともあります。しかし、プロジェクト計画書が更新されていないと、人事異動
等で新しい担当者が着任した際に現在の状況や正確な内容がわからず、その後のプロジ
ェクト活動に影響を与えてしまいます。
プロジェクト計画書は詳細化や変更発生の都度更新していくことが望ましいですが、四半期や半期等の周期でも、プロジェクトの最新の状況が確実に反映されているかを確認するようにルール化しておくことも効果的です。

参考：補正予算で開始するプロジェクト

-

32 -

参考 2-4
補正予算で開始するプロジェクト

（第３編第２章 プロジェクトの管理）補正予算で新規に情報システムの構築を行うプロジェクトには注意を要します。
補正予算の場合、当該年度内で執行が完了することが必須となるため、プロジェ
クトの計画に大きく影響します。補正予算で新規に情報システムを構築することは推奨しませんが、実施する場合は以下の点に気をつけてください。
予算要求時点では見積りの精査が難しいが、可能な限り精査した上で要求する。
予算要求時点では見積りの精査が難しいため、予算執行時までに必要経費を精査できるように計画する。
補正予算で整備したハードウェア、ソフトウェア、アプリケーション等には、整備年度以降もランニングコストが発生することに留意し、ライフサイクルコスト全体で費用対効果を判断する。
要求内容の優先順位付けを事前に行い、問題が発生したときに対応できるように準備する。
設計・開発の期間が限られることから、サービス・業務企画や要件定義が十分に行われていないケースも散見されるため、サービス・業務企画や要件定義を行う
体制、期間と時間等を十分に確保する。

B. 抜け漏れのない実施計画を作成する
プロジェクトの立ち上げ当初は、実施計画（スケジュール）についても概略で構いません。プロジェクトで実現する事項も大きなカテゴリ単位となりますし、時間軸についても月単位や四半期単位等、概略での作業時期をプロットする形で構いません。実施計画も、段階的に詳細化していくものです。
実施計画の例を図 2-5 に示します。
図 2-6
実施計画の例

実施計画から漏れやすい作業に注意
実施計画を作成する際には、ＰＪＭＯが責任範囲を持つ部分のみで計画を立てがちですが、影響を受ける側（業務担当職員、連携先システム、移行元の既存システム等）も含めた全体的な計画が必要です。
実施計画から抜けやすい作業項目を次に示します。実施計画を段階的に詳細化する際に、このような作業が漏れていないか確認してみてください。

-

33 -

（第３編第２章 プロジェクトの管理）計画から抜けがちな作業項目
関係者との要件や仕様の調整、確定作業
システム連携等で影響を与える関係者に対して、要件定義内容や設計仕様を調整し、確定した要件、仕様として双方での合意を形成する作業（マイルストーンとして、いつまでに「確定」するかを関係者で事前合意することが重要）
データ移行関連作業
既存情報システムからのデータ移行、既存データの整備（クレンジング）作業、
紙にしか存在しないデータのパンチ入力作業
テスト関連作業現行システムと新システムで処理結果を比較する実データテスト、連携先情報

注記
クレンジングとは、データベースのデータやファイル等に存在している、不要なデータの削除や、不整合なデータを整合性が合うように修正する作業のこと。

システムとのデータ連携テスト、システムの性能を確認するためのストレステスト
等（総合テスト、受入テストの中で、このようなテストが確実に含まれているかど
うか）
移行リハーサル
業務実施部門による業務移行リハーサル、情報システム部門によるシステム
移行リハーサル（社会的な影響が多いシステムでは、数度のリハーサルを経た上で本番切替えを行うことが多い）
教育、研修、利用者サポート
利用者（国民等）への利用マニュアルの作成、職員向けマニュアルの作成（業
務面、システム操作面）、職員向けの研修実施 （業務面、システム操作面）、
ヘルプデスクの準備・運営
利用者への連絡やプロモーション
新サービス開始についての利用者・関係者への事前連絡、自府省 Web サイト
や広報媒体を活用したプロモーション業務を実施する環境の変更
業務フロー変更に伴う窓口の配置変更や移転に伴う工事の調整運用段階での利用状況分析、効果測定
アクセスログや処理件数等から利用状況を把握し、業務・システムの改善を図る。また、プロジェクトが目標としていた成果に対して、実績としての効果を測定する。
（効果を測定するための分析機能を、システム開発範囲に盛り込んでおくことが重要）

２ プロジェクト管理要領を作成する【標準ガイドライン関連箇所：第３編第２章第２節２)】

このステップの冒頭でも説明しましたが、プロジェクト計画書はプロジェクトで「実施する内容とその目的・目標」を記すのに対して、プロジェクト管理要領はその「実施に係るルール」を定義するものです。
この実践ガイドブックには、プロジェクト管理要領についても別添としてひな形を示しています。あくまでこのひな形は例示ですので、プロジェクト内容に応じて記載内容を個別に追加、

-

34 -

注記
パンチ入力とは、データを情報シ
ステムに人の手で入力する作業のこと。（以前はコンピュータにデータを登録するためには、専用のカード（紙）に孔をあけて（パンチ）
読み込ませていたことに由来する。）

（第３編第２章 プロジェクトの管理）変更して構いません。ひな形を見ると、何をどのようなレベルで書くべきかの参考になると思います。

様式例：プロジェクト管理要領のひな形
プロジェクト管理要領のひな形を本章別紙としてまとめています。

以降では、プロジェクト管理要領を作成するときに、特に注意が必要なポイントについて説明していきます。

A. 問題に対処できる会議体を構成する
会議体の構成は、プロジェクトの工程によって変わっていきますが、基本的には次のような定例的な会議を主軸としながら進めていきます。
実際の会議体では、複数の会議機能を１つの会議で集約することも多いですが、会議の機能として次のようなものが漏れていないか確認してみてください。

会議体の構成例
仕様検討会議 （要件定義、設計）
現場で業務を実施している職員等の意見を反映しながら、業務の改善ポイントやシステムに求める機能などを詳細に決める会議です。業務の種類やサブシ

-

35 -

様式例 2-2
プロジェクト管理要領のひな形

（第３編第２章 プロジェクトの管理）

ステム単位で複数の会議を設定することもよくあります。名称については、検討ＷＧ（ワーキンググループ）、作業部会、分科会等の名称になることもあります。
重要なことは、これらの会議において業務実施部門の職員自らが仕様を決定することです。業務を実際に担当している職員の現場感覚がなければ、業務に役立つ良い情報システムは作れません。

事例：業務実施部門が参加しなかったプロジェクトあるプロジェクトでは、システム開発事業者が提示した設計内容案に対して業務実施部門の職員が形式的な確認しか行わず、システムのテスト時点
で「こんなシステムは業務に合わない」と業務実施部門がクレームを行うということが発生しました。しかし、設計内容は既に確定しているため、業務実施部門の要求を実現するためには、さらに改修等が必要となってしまいました。
このような事態になってからでは、後戻りすることは困難です。情報システ
ムの要件定義や設計内容（特に情報システムの機能に関わる部分）は、業
務実施部門が責任を持って決定する必要があります。

連携調整会議 （要件定義、設計）
システム連携等で他システムとの調整が必要な場合に、システムの連携仕様
やテスト実施方法等を詳細に決める会議です。
システム連携の調整は、連携仕様そのものを決めるだけではありません。連携
データの量（ピーク時の最大処理件数等）、連携データの種類（最新歴だけ
か、過去歴も含むか等）、連携エラー時の処理（代替処理、エラーメッセージの出し方等）、連携テストの実施時期、運用時の対応体制等、様々な調整事項を決める必要があります。また、一度決定した連携仕様を変更すると関係者への影響が大きいため、連携仕様の決定は慎重に行う必要があります。これらの点を考慮して、仕様調整会議では十分な調整期間と体制を確保することが望まれます。
テスト調整会議、テスト確認会議 （テスト）
テスト工程では、テスト計画書の内容を確認した上で、各種テストを実施し、テスト結果に応じて対応を行います。また、総合テストまでの工程では、開発事業者が主体としてテストを実施しＰＪＭＯはテストの実施状況を確認しますが、受入テストでは業務実施部門を含めたＰＪＭＯの職員自身がテスト計画を作成
してテストを実施します。
特に複数のプロジェクトにまたがるテストを実施する場合は、テスト内容、テスト
実施時期、テスト実施環境、テスト体制等の調整を慎重に行う必要があるた
め、やはり十分な調整期間と体制を確保することが望まれます。
進捗報告会議、定例報告会議 （全工程）システム関連事業者の作業報告を含めて、プロジェクト全体の状況を確認する会議です。システムの開発工程では「進捗報告会議」、システムの運用工程で

-

36 -

事例 2-8
業務実施部門が参加しなかった
プロジェクト（第３編第２章 プロジェクトの管理）は、「システム運用定例報告会議」、「アプリケーション保守定例報告会議」等の形で開催することが多いです。
システム関連事業者ごとに月１回程度の進捗報告を求めることが基本的な形ですが、多数の事業者が関係するプロジェクトでは、事業者単体での進捗報
告会議に加えて事業者全体での「全体進捗定例会議」を開催することで、事業者間の情報共有を図ることもあります。
課題調整会議 （全工程）
課題管理表をベースとして、課題の発生状況と対応状況を確認し、対応が停滞している課題に対してはシステム開発事業者の作業進捗状況を確認する会
議です。
変更管理会議 （全工程）確定した仕様に対する変更要求、実装済の機能に対する変更要求、システムの運用手順に対する変更要求等に対して、変更の可否を決定する会議です。
変更が発生した際に必要となる会議であるため、定例的な会議として運営するというよりは、臨時的な会議として開催することが基本的です。また、他の会議
体（仕様調整会議、連携調整会議、テスト調整会議、課題調整会議等）で、この会議の機能を包括することもあります。
ＰＪＭＯ情報共有会議 （全工程）
ＰＪＭＯの全職員を集めた全体定例会議、ＰＪＭＯの中でリーダーとなる職員を集めたリーダー会議等、ＰＪＭＯ内での情報共有を行う会議です。
プロジェクトの中では、特定の人しか状況を知らないという「情報の局所化」が発生しやすいので、月次、週次等で定例的に会議を開催することが有効です。
なお、プロジェクトで発生する問題の全てを、ＰＪＭＯの体制下で解決できるわけではありません。問題の大きさに応じて、自府省の幹部職員に状況を伝達し、幹部レベルでの問題対応を図ることが必要になります。また、問題が発生した時だけ幹部に相談する形では情報共有が不十分になりがちなので、常日頃からプロジェクトの計画内容、進捗状況、重要
課題を関係する幹部職員が把握できるように進めていく必要があります。
プロジェクトの影響度や重要性に応じて、幹部職員への連絡会議を設定するなど、幹部から定期的な関与が得られるように調整を行うと良いでしょう。

事例：幹部職員への定期的な報告あるシステムでは、システム稼働開始後に様々な問題点が発生したため、抜本的な改善を行うこととしました。この抜本改善の過程では、次のような形で幹部職員への情報共有を行っていました。
ＰＪＭＯの担当参事官、当該府省の副ＣＩＯ、関係組織（内閣官房等）との情報共有会議を実施（抜本改善の中心時期には毎週１回、改善後の時期も月２回開催）
上記打合せを開催した週のうちに、事務次官、官房長（ＣＩＯ）にも直接状況を報告このように頻繁に幹部職員への情報共有を行うことで、プロジェクトを推進する中で発生した問題を早期に幹部に伝え、対応を素早く行うことができるようになりまし
た。

-

37 -

事例 2-9
幹部職員への定期的な報告

（第３編第２章 プロジェクトの管理）

B. 本質的なリスクを事前に予見して、対応を準備する
リスク管理については、リスク管理表等のドキュメントは一通り作成しているものの、実際のプロジェクトの中で役立てているケースはまだ少ないようです。
しかし、実際にはプロジェクトを進める中で様々な問題が顕在化しています。問題が起こってしまってから対処方針を考えても、予算面や既存の契約条件面等から制約が大きく、抜本的な対応を行うことが困難になります。
やはり、それらの問題が発生しないうちに事前にリスクとして認識し、必要な対応を準備しておくことが重要となります。
プロジェクトを進める中で発生しやすいリスクとその対応方法について、例を示します。
わかりやすさのために、大きく「品質」、「コスト」、「納期」の観点で分類していますが、必ずしもこの分類で考える必要はありません。プロジェクトの特性、実状に応じて、本質的に対応が必要となるリスクを、事前に考えてみてください。

品質に関するリスクと対応方法の例
多数の事業者間をまたいだシステム障害が発生するリスク
多数の事業者が参画する体制（マルチベンダー体制）においてシステム障害が発生した際に、各事業者が自身の責任範囲ではないことを主張し、問題を主体的に解決する主体が存在しないことによって、原因究明や対応実施が長期化するというリスク。
→リスクを軽減するためには、プロジェクト全体を統括する品質管理チームをＰＪ
ＭＯ職員と特定事業者によって構成する等の対応が考えられる。プロジェクト
内でシステム障害等の問題が発生した際には、この品質管理チームが問題解決を統括し、複数事業者をまたがる問題についても問題の切り分けと問題
対応者（事業者）の決定を行う。また、各事業者が品質管理チームの指示に従って必要な対応を行うことをプロジェクトのルールとしても明示する。
個人情報等の重要情報が漏えいするリスク
個人情報等の重要情報について、本来は参照権限がない利用者が参照してしまったり、外部へ流出してしまったりといった漏えいが発生するリスク。
→本番稼働前の段階においてリスクを軽減するためには、情報セキュリティの専門経験を持つ要員によるセキュリティ設計を行い要件定義で定めた情報セキュリティ対策要件の充足性を確認するとともに、実作業の中でも本番データを扱うテストにおいて氏名等の重要情報をマスキング（匿名化）した形で実施するなど、万一の情報流出時にも影響範囲を限定化する対応を行う。
→本番稼働後の段階においてリスクを軽減するためには、運用計画や運用実施要領等の中で重要情報を扱う際の手順を明確に示した上で、実際の実施状況について定期的に確認することや、セキュリティ監査の実施計画を立てて監査の実施とフォローアップを行う等の対応を行う。

コストに関するリスクと対応方法の例
システムの機能追加に関する要望が多発するリスク
開発段階や運用段階において、業務実施部門の職員等からシステム機能に対する改善要望が多発する一方で、予算範囲内では対応できる範囲が限定

-

38 -

（第３編第２章 プロジェクトの管理）されるため、業務実施部門とシステム機能に対する合意が形成できなくなるというリスク。
→サービス・業務企画段階でのリスクを軽減するためには、業務の中核を担うベテラン職員等を巻き込み、当該職員の豊富な現場経験を活かしながら、全体のバランスを考慮して検討を進めることで、業務実施部門との円滑な合意形成を行えるようにする。
→開発段階に入る前（調達を行うまで）の段階でリスクを軽減するためには、要件定義内容を詳細に業務実施部門に提示し、システム導入後の業務実施方
法を具体的にイメージできる状況の中で、必要となる機能のフィードバックを受ける等の対応を行う。また、特定のユーザに固有の少数要望についてはシ
ステム本体ではなく簡易な外部ツール等で対応できるようにして、そのための予算化も事前に行うことも考えられる。
→開発段階でリスクを軽減するためには、要件定義や基本設計段階においてプ
ロトタイプを作成して業務実施部門の職員がシステムの動きを詳細に理解できるようにする等の対応を行う。また、一方で各職員の個別要望だけでシステ
ム機能が増え過ぎないように、システムのコストや保守性等も勘案した上で機能要件を増やすことの判断を業務実施部門が組織的に行うルールを導入することも考えられる。
→運用段階でリスクを軽減するためには、毎年の予算要求に間に合うように改修要望のとりまとめ方法をルール化するとともに、改修対象の選定基準や選定結果について関係者全体へ説明することで、バランスのとれた合意形成が行えるようにする。
本番稼働後に想定以上の利用があり、対応能力が不足するリスクシステムへのアクセス数が想定以上に増加し、システムのレスポンス遅延やア
クセス不能状態が発生するため、ハードウェア等への追加投資が必要になるというリスク。又は、本番稼働後にシステムの操作方法や不具合に対する問合せが頻発し、ヘルプデスクの対応能力を超えてしまったため、ヘルプデスク体制の増強等に追加投資が必要になるというリスク。
→アクセス増加へのリスクを軽減するためには、本番稼働を段階的にすることで実際の利用規模を見定めながら必要な投資を行う、ピークを分散するように業
務スケジュールを見直す、クラウドサービスを利用することで突発的なアクセス増加に対しても対応能力を高める等の対応を行う。
→問合せ増加へのリスクを軽減するためには、よくある質問（ＦＡＱ）を Web サイト等で公開することで問合せ件数を抑制する、ヘルプデスクに寄せらせる問合せを分析し、業務面やシステム面での必要な改善を細かなサイクルで回す等の対応を行う。
クラウドサービスの契約内容の変更等に伴い想定外のコストが発生するリスク
クラウドサービスの料金体系やサービス内容の変更等により、想定外のコストが発生するリスク。例えば、IaaS を利用して情報システムを構築する際に、途中で値上げがあった場合は、それに応じざるを得ず、またサービス内容の変更があった場合は、それに伴う情報システムの構成に関する検討等の追加作業が発生し、情報システムの構築にかかるコストが増加する。また、利用していたサービスの一部が終了する場合もあり、他のサービスへの切替え等に伴う作業が発生する。

-

39 -（第３編第２章 プロジェクトの管理）→値上げによるリスクへの対策として、利用するクラウドサービスのうち変更可能
なサービスや縮退可能なリソースをあらかじめ特定しておき、継続的にクラウドサービスに係る実績コストのモニタリングを行い、リスクが顕在化した際は、サービスレベル変更やリソース停止により縮退運転を行う。
→サービス内容の変更や終了によるリスクを軽減するために、情報システムを整備する際に、情報システムを構成する要素を特定のベンダの技術や製品に依存しない、オープンな技術仕様に基づくものとし、将来的に他の製品やサービスへの乗り換えが可能な構成とする。
クラウド利用における為替変動リスク
為替レートが円安に振れることで、クラウドサービスの利用料が想定以上に高額となるリスク。クラウドサービスの中には、ドルベースで料金設定を行っているものがあるため、予算の算出時に想定していた為替レートよりも円安に振れると、その分だけ利用料が増加する場合がある。
→為替レートが円安に振れるリスクを軽減するために、利用するクラウドサービスのうち削減できるリソースをあらかじめ特定しておき、リスクが顕在化した際は、当該リソースを停止して縮退運転を行う。
→リスクを軽減するために、為替レートが予算要求時点よりも円安に振れることを一定程度見込んだ額で予算要求を行う。

納期に関するリスクと対応方法の例
必要資源の配備が遅延するリスク
ハードウェアの配備、ネットワークの開通、データセンターの供用開始、ＩＣカー
ド等の必要備品の準備等、資源の配備が計画時期に間に合わないというリスク。
→リスクを軽減するためには、計画上のバッファ（余裕）確保、代替計画の準備（ネットワークが開通しない場合に、ネットワークを利用しないテスト工程等を先行開始する）、段階的配備（テストに必要な数枚のＩＣカードだけ先に供給を受ける）等の対応を行う。
関係する他機関からの情報提供が遅延するリスク
制度変更が予定されている場合における変更の詳細内容、システム連携を行
うための連携仕様書やテスト計画書等、他機関から提供される情報が期日に間に合わず遅延するというリスク。
→リスクを軽減するためには、計画の部分変更（変更影響を受ける部分の機能開発を後送りにする）、段階的開発（仮決めの仕様を基に開発を行い、仕様確定後に差分部分を再開発する）等の対応を行う。
また、リスクの内容によっては、回避、軽減することが難しく、リスクとして受容せざるを得ないものもあります。そのような場合においても、当該リスクを回避不能なリスク（受容するリスク）としてリスク管理表に記載し関係者の合意を形成しておくことで、実際にリスクが顕在化した場合でも、比較的円滑に対応を行うことができます。例えば、クラウドサービスで障害が発生した場合、クラウドサービス提供事業者から個々の障害の原因や再発防止策は詳細に開示されない場合があります。このため、ＰＪＭＯはクラウドサービス提供事業者から発生した障害に関する情報や再発防止策が提供されないリスクを受容せざるを得ません。

-

40 -

注記
クラウドサービスの契約方法により、リスクが顕在化するタイミングが異なる。クラウドサービス提供
者との単価契約の場合は、発注者が月次で支払うクラウドサービ
ス利用料に影響が出る。
一方、総価契約の場合、契約期間内はクラウドサービス利用料の変動に関わらず、発注者が支払うクラウドサービス利用料に影響しない。クラウドサービス利用料に影響が出るのは後続の契約となる。
発注者は総価契約においても、クラウドサービスの利用にかかっている実績コストを把握して、翌年度以降の予算等の検討に活用することが重要である。
総価契約／単価契約の違いについては、「事例：第二期政府共通
プラットフォームにおけるクラウドサービスの調達」を参照すること。

（第３編第２章 プロジェクトの管理）

ただし、クラウドサービスの異なる地域（リージョン等）・拠点（アベイラビリティゾーン、ゾー
ン、可用性ゾーン、可用性ドメイン等） にも環境を構築する、情報システムを監視する項目を増やす等リスクを軽減する方策はあるため、事前に運用・保守事業者と相談の上、情報システムの運用方針を検討する対応を行うことができます。

C. 品質管理を事業者任せにしない
品質管理は、サービス・業務としての品質管理とシステムの品質管理に大別されます。
まず、サービスや業務自体に求める品質についてです。利用者に発行する証明書の内容に誤りがあったり、利用料金の計算にミスがあったりしては、利用者からの信頼を大きく損なってしまいます。サービス品質、業務品質として、品質目標を定めた上で実際の品質達成状況を確認していくことが重要です。
なお、サービス品質、業務品質は、プロジェクト管理要領で忘れられがちなポイントです。後述するシステムの品質だけでなく、サービス・業務の品質にも留意してください。
次に、システムの品質についてです。本来はハードウェア等の品質管理も重要なのですが、よく「ソフトウェア品質」という言葉もほぼ同じ意味で使われます。ソフトウェア品質には、
機能性、信頼性、使用性、効率性、保守性、移植性といった特性が含まれます。また、「サービスレベル」という形で品質上の重要な事項を指標化します。
ここでは、これ以上詳細に踏み込みませんが、重要なことはシステムの品質についても事業者任せにしないということです。求める水準の品質を得るためには、発注仕様書の段
階で具体的に品質水準を提示し、試験の過程で発注者側が品質について関与する内容を明確にし、品質における事業者と発注者側の役割を明らかにすることが必要です。また、事業者内での品質管理体制も確認する必要があります。
事業者の工程完了時に、検収を行う担当者以外にＰＪＭＯの中から成果物や品質報告に対する承認を行う担当者を設けて、工程完了時にこの担当者による承認を必須とするようなルールを作ることも有効です。このようなルールを設けることで、システムの品質達成状
況の実態を把握している職員が確実にチェックを行えるようになるので、一定の品質を保つことができます。

-

41 -（第３編第２章 プロジェクトの管理）

Step.

4 プロジェクトのモニタリング

プロジェクト計画書及びプロジェクト管理要領が出来上がりました。この内容に沿って、プロジェクトを実施する具体的な方法については、第３章（予算及び執行）から第９章（運用及び保守）で詳述します。このプロジェクトを実施する過程では、プロジェクトの進行状況や達成度
合いについてモニタリングを行うことが重要になります。
特にＰＭＯが指定したプロジェクトについては、工程レビューの仕組みが準備されています。プロジェクトが目標に向かって正しく進んでいるかをＰＪＭＯ自身でチェックした上で、ＰＭＯ等の第三者の視点でも確認しましょう。
また、どのプロジェクトにおいても、ＰＪＭＯ自身による定期的なモニタリングが必要です。
様々な理由から、プロジェクトが目標どおりの成果を達成できないこともあるでしょう。今後も改善できる可能性が少なければ、予算がついているという理由だけでプロジェクトを延命するのではなく、早期にプロジェクトを終結させることも重要です。プロジェクトが生み出している成果について、定期的に確認を行いましょう。

１ プロジェクトをモニタリングし・検証する【標準ガイドライン関連箇所：第３編第２章第４節３)】

プロジェクト実施中は、業務実施部門の職員や事業者との調整、ＰＪＭＯ内での調整や問題対応、関係者間の仕様調整等、様々な出来事で日々忙殺されがちです。そのような状況の中ででも、プロジェクト全体が意図した方向に進んでいるか、包括的な視点で確認することが必要です。
プロジェクトを船に例えましょう。船を進ませるために、船長、船員は様々な業務をしています。ただ、その結果として船が今どこにいるのか、航路からずれていないか、目的地に近づいているかを確認する必要があります。
それが、モニタリングです。モニタリングはＰＪＭＯ自身によって定期的に行われるプロセスです。モニタリングを行うことで、プロジェクトの状況を包括的に把握しましょう。

ポイント
報告内容に「問題なし」が続くとモニタリングの実施間隔が伸びたり実施を取りやめたりしてしまうことがあるが、問題が発生していなくても、あらかじめ定めた内容を継続してモニタリングすることが重要。
問題を把握したときは、定量的に事実を共有し、改善に向けて迅速に行動に移す。あらかじめ基準と対応手順を定めておけば、問題が発生したときに迅速に対応できる。

A. 目標、経費、進捗、品質等を中心にモニタリングする
モニタリングでは、主として目標、経費、進捗、品質等を確認します。もちろん、プロジェ
クトの特性によってモニタリングする項目も変わります。モニタリング対象項目をあらかじめ定めておくとともに、それらの項目を継続的に確認しやすいように測定方法を決めておいてください。

-

42 -（第３編第２章 プロジェクトの管理）

モニタリングの内容例
プロジェクトの目標の達成度合い
利用者へのサービス向上や業務効率向上等の観点から、プロジェクト計画書で定義した目標に対して、モニタリング実施時点での達成度合いを確認する。
→設計・開発等の段階においては、システムの機能等が目標を達成するために必要十分であるかを確認する。
→運用段階においては、実際のサービス・業務において目標が達成できていることを確認する。

事例：開発途中の機能追加による目標の形骸化あるプロジェクトでは、業務を効率化するためのシステムを整備するとともに、この業務に関連する決済についても決済関連システムへ自動連携することで、業務担当者の作業負荷を減らすことを目標の１つとしていました。
しかし、システム開発を進める中で、ある部署の現場担当者から要望が出ました。現在は多数の拠点において紙帳票を出力して関係機関へ持ち込む
形で決済業務を行っており、自動連携を行うと全拠点の情報のとりまとめが別途必要になるなど業務分担の追加や変更が発生するので、現状どおり紙帳票も出力できるようにしてほしいというものでした。
ＰＪＭＯの中では、担当者レベルの打合せの中でこの要望に対応することを決め、決済データを自動連携する機能と紙帳票を出力する機能の両方を選択できるようにしました。このような対応を行ってしまった結果、当初の目標の１つであった決済関連業務の効率化については、多くの担当者が紙帳票のまま業務を継続することとなり、達成できませんでした。
この事例の問題点は、目標の達成度合いに関わる重要な変更を、担当者レベルで勝手に決めてしまったことです。
まず、本来的には、システム開発に入る前の企画段階で様々な部署の決
済業務の運用方法を調べ、自動連携できることを確認すべきです。ただ、開発に入ってから現場の業務実施方法に合わないという問題が顕在化してしまうことも、実際にはあります。この時に、当初決めた方針なので紙帳票の機能は追加しないと押し切ってしまうと、業務上で大きな不都合が発生しかねません。ですので、紙帳票の機能も追加したこと自体は、結果としては正しい判断だったのかもしれません。ただ、その判断の際に、プロジェクト推進責任者がプロジェクトの効果目標を修正することになると理解した上で、それでも機能追加を行うという責任を持った判断をすることが不可欠だったといえます。
このように、システム開発の過程では様々な要望や制約が判明する中で、実現機能を修正することが求められます。だからこそ、要所でモニタリングを行い、当初目指していた目標の達成度合いを確認することが重要になります。

経費の計画と実績
プロジェクト計画書の中で定めた年度単位での予算額計画に対して、実績での経費を確認する。経費については、ＰＪＭＯが直接的に執行した経費だけで

-

43 -

事例 2-10
開発途中の機能追加による目標の形骸化

（第３編第２章 プロジェクトの管理）なく、業務実施部門等で移行や運用支援のために必要になる経費等を含めて、プロジェクトに関連して支出した経費の全体像を把握するようにする。
作業進捗の計画と実績
システム開発等の作業について、計画したスケジュールに対する実際の進捗状況を把握する。
品質の管理基準に対する実績
プロジェクト管理要領に定めた品質基準に従って、システム開発や運用等の各プロセスが実施されていることを確認する。

B. モニタリングは適時に実施するモニタリングの実施頻度は、四半期に１度とすることや、半期に１度とすることを例示として挙げますが、プロジェクトの状況に応じて柔軟に設定してください。

C. モニタリングと監査をうまく組み合わせる
プロジェクトのモニタリングと、第１０章で後述する監査とが同一と誤解されることがありますが、そうではありません。モニタリングと監査は別のものです。モニタリングは血圧測定のような自分自身による日々の健康チェックで、監査は専門的な医師が行う人間ドックのようなものです。モニタリングは実施頻度を定めて継続して行い、監査は数年に１回等のタイミングで計画的に利用するという二本立てで、プロジェクトの健康を保持しましょう。
また、モニタリングやシステム監査の結果を、後続プロジェクトでも活用しましょう。過去に気づいたこと、指摘を受けたことを、今後は同じ誤りをしないように教訓としてためていき実
際の案件で活かしていくことが、長期的にはとても重要なことです。

D. プロジェクトは状況に応じて停止・改善する
関係者と合意したプロジェクト計画どおりにプロジェクトが進行できないときは、正常な状態に戻すための活動を進めることになります。このような状況になったときは、ＰＪＭＯである
あなたは、客観的な資料を揃えて、関係者に正確な実情を共有してください。
資料を確認したＰＭＯ等が抜本的な見直しや、場合によってはプロジェクトの停止を判断し、更に深刻な事態に発展することを防ぎます。

事例：抜本的な改善のために新たな体制を構築
各府省が共通で利用する政府情報システムでは、システム稼働開始後に様々な問題点が発生したため、政府ＣＩＯへも状況を共有した上で、抜本的な改善を行うこととしました。
このシステムの利用については、府省単位で段階的に移行を行っていましたが、移行作業をいったん中断することとしました。その上で、システムの機能等の改善だ
けでなく、業務自体や背景にある制度自体の見直しも含めた抜本的な改善を行うた
めに、各府省の事務次官をトップとする体制（推進会議）を立ち上げた上で、具体的な見直しを実施するための検討室を内閣官房の組織として設置しました。

-

44 -

事例 2-11
抜本的な改善のために新たな体制を構築

（第３編第２章 プロジェクトの管理）

その後、検討室がまとめた「改善計画」に基づいて制度、業務、システムの改善を実施し、利用を予定していた全府省がシステムを利用しています。

-

45 -

（第３編第２章 プロジェクトの管理）

Step.

5 プロジェクトの終結

プロジェクトの立ち上げは、新しいことへのチャレンジや変化への期待もあって注目されま
すが、終わる方は何となく存在が薄いように感じませんか？
そのようなことはありません。プロジェクトの終結は、これまでの活動を振り返り、活動の評価を行うことにより、新たなプロジェクトへの糧となる重要なプロセスです。
終結処理を確実に行い、気持ちよくプロジェクトを完遂しましょう。

１ プロジェクトの終結を処理する【標準ガイドライン関連箇所：第３編第２章第７節】

プロジェクトを実行している間には、様々な要因で計画内容の追加や変更が発生します。
その結果、プロジェクトの期間が延長され続けて、いつまでも終わらない状態になったという経験はありませんか？プロジェクトは「有期であること」と定義付けられています。終わりのない
プロジェクトはプロジェクトではありません。
そのような状況とならぬよう、プロジェクトが対象とする業務の継続有無に着目して、終結する手順を確認しましょう。
プロジェクトを終結することにより、最終的なプロジェクトの達成評価とプロジェクト体制の要員を解放できます。

ポイント
プロジェクトの状況ではなく、プロジェクトが対象とするサービス・業務の継続に着目して、完了又は終了の処理を行う。
特に問題なく運用しているプロジェクトでも、区切りをつけて達成評価し、継続する後続プロジェクトにその評価結果を活かす。

A. プロジェクトを完了する
プロジェクトが提供するサービス・業務が問題なく運用されている場合や、様々な問題で運用に入れず期間を延長して開発を続けているような場合は、定めたプロジェクト期間に従って、まずはプロジェクトの評価を行い、一旦完了させてください。

B. プロジェクトを終了する
何らかの理由でプロジェクトの対象となる事業が不要となることがあります。それに伴いサービス・業務を支援していた情報システムが不要になりますので、その場合はプロジェク
トを終了させてください。

C. 後続プロジェクトを策定する
プロジェクトの対象とする事業が継続され、引き続きプロジェクトで扱う情報システムを利用するときは、後続プロジェクトについて策定しましょう。
現在のプロジェクトで運用している各種計画書等をそのまま引き継いで利用できますの

-

46 -

（第３編第２章 プロジェクトの管理）で、プロジェクトを新規に立ち上げるときと比較すると、準備に必要な負荷は少なくなります。

ポイント
情報システムの規模で異なるが、現プロジェクトの完了の３年前を目安に後続
プロジェクトの策定を開始する。
後続プロジェクトでより良い情報システムとするためには、現プロジェクトにおける課題や要望等を日常的に整理しておくことが重要。

-

47 -

（第３編第２章 プロジェクトの管理）【コラム】ＰＭＯの取り組み事例
個々のプロジェクト計画を定めるのは PJMO ですが、府省単位でプロジェクトを束ねて、管理、支援するのが府省 PMO の役割です。
PMO とは、Portfolio Management Office の略称で、府省の全プロジェクトについて、計画
管理、プロジェクト推進責任者等、デジタル人材管理、予算管理、執行管理、データマネジメントの推進、情報資産管理、ＰＪＭＯ支援、ドメイン管理、システム監査管理、政府情報システ
ムに係る文書管理、デジタル人材の業務環境整備、連絡調整窓口、非常時対応を行います。
各省 PMO では、プロジェクトの管理や支援を円滑に行うために、様々な工夫を行っています。その一例をご紹介します。

A. ＰＭＯの機能強化(1) 「受け身のＰＭＯ」から「働きかけるＰＭＯ」へ(ア) 新規システム構築時のＰＭＯへの事前相談
ＰＪＭＯが新規のシステム構築等を行う場合に、ＰＭＯが必要に応じて助言・指導を行う。従来は、「ＰＪＭＯから相談があれば受け付ける」との受動的な対応であったが、事前・前広にＰＭＯに相談をしてもらうように省内へ周知。
(イ) 主要プロジェクトの指定
ＰＭＯが支援する必要があるシステム案件を省内の主要プロジェクトとして指定し、ＰＭＯが PJMO の定例会へ出席したり、レビュー対応等の支援を実施。
従来は、ＰＪＭＯ側の要請があったものを主要プロジェクトに指定していたが、ＰＭＯがプロジェクトの難易度やＰＪＭＯの体制等を踏まえて指定。
(ウ) ソフトウェア・サポート期限のチェック
ソフトウェアのサポート期限をチェックするルールを導入。ＰＪＭＯがソフトウェアのサ
ポート期限等を管理しＰＪＭＯ、ＰＭＯ双方でチェック。
サポート期限切れが近いものはＰＭＯからＰＪＭＯへ予算要求等を行うよう指導。
(2) システム予算のチェック機能の強化 ～予算査定との連携強化～
これまで６月（各局庁が会計部門へ予算要求を提出した後）に行っていたＰＭＯによるシステム予算のヒアリングについて、会計部門との連携を強化して以下を推進。
(ア) 新規システムの構築等を対象としたレビュー（２～３月）、全システムを対象とした詳
細なヒアリング（４～６月）を実施する早期・詳細なヒアリング方式に見直し。
(イ) ヒアリング結果をまとめた意見書については、会計部門での査定に明確に反映。

B. 省内共通基盤の整備
デジタル・ガバメントを効率的・効果的に推進するため、各ＰＪＭＯがばらばらで対応するのではなく、ＰＭＯが企画し、一元的な整備・運用を図る省内共通基盤を整備。
いずれも中長期計画にも位置付け、運用開始を目指して推進中。
(1) 行政手続等の共通申請システム
利用者の利便性向上のため、当省所管の行政手続・補助金手続をオンラインで申請できる共通的なシステムを構築。
オンライン化に当たっては、利用者視点で、添付書類の削減など手続の改善も検討。
(2) クラウド・プラットフォーム基盤
クラウド・バイ・デフォルトの方針に沿って、省内システムの基盤の集約を図るため、当省独自のクラウド・プラットフォーム基盤を構築。コスト削減、セキュリティや運用保守水

-

48 -

（第３編第２章 プロジェクトの管理）

準の向上のほか、ＰＪＭＯの負担軽減が期待。

C. 体制強化・人材育成(1) ＰＭＯの体制強化
１名→３名に増員配置。ＣＩＯ補佐官からの指導・助言を仰ぎながら、業務経験を積ませる等より、属人的でなく組織として機能するＰＭＯ体制を構築。
(2) 計画的な人材確保・育成
特にＰＭＯを担え得る人材を特定部門の出身者だけに頼らず、省内外から幅広く確保。
システム業務だけでなく、政策の業務経験も積ませる等により、ＰＭＯとしての役割を担える人材を計画的に育成。
IT 業務を担う職員を新卒で新規採用（一般職）
若手職員の配置、ＰＭＯとＰＪＭＯの人事交流、独法との人事交流など省内外の人事交流を活発化
スキル認定、情報システム統一研修など政府全体の取組を最大限に活用するほか、当省職員の能力のレベルに応じた独自の研修を実施。
ＰＭＯ・ＰＪＭＯ経験者や研修参加者の情報を集約。
ITガバナンス業務（※）

1月

2月

3月

4月

5月

6月

7月

8月

9月

10月

11月

12月

1月

2月

短期間でのフォローアップ対象のフォローアップ

１．デジタル・ガバメント中長期
計画

3月

改定
全体フォローアップ

２．人材育成・確保
PMO強化・改善

PMO内定例会の運営、ITガバナンス施策改善検討・推進、PMO職員研修

PJMO向け研修

評価

評価

PJMO職員育成（標準ガイドライン等）

PJMO向け研修

３．予算要求と執行
PJMOからの随時相談対応（随時）（１）随時相談対応（新規整備、コスト削減、調達手続き、見積精査、予算要求、セキュリティ課題、要件定義、技術審査等）（２）IT調達事務講習（各局予算担当、PJMO向けのルール説明）

予算

調達

手続

手続

案内

提出
指示

全施策

（会計部門向け）

ヒアリング・資料
審査

総務省ヒアリング（情報システム予算）

総務省

財務省ヒアリング

新規施策
二次評価

手続

意見書作成

一次評価

省内ヒアリング（早期相談開始の徹底）（成果）

新規施策相談対応
予算（成果・プロセス）（３）予算要求管理

予算

相談対応

手続
案内

ヒアリング対応

提出

PJMOフォロー

財務省

ヒアリング対応

提出

PJMOフォロー

（４）予算の執行管理
調達仕様書審査（随時）

調達仕様書審査

当年度執行案件

運用・保守系

審査ピーク

仕様書審査ピーク

４．情報資産の管理
登録指示

要求額の登録指示→PJMO登録
登録指示

予算額の登録指示→PJMO登録

ソフトウェア情報の更新指示
PMOによるソフトウェアサ
ポート期限チェック

登録指示

登録指示

→PJMO登録→PJMO登録

サポート期限チェック

サポート期限チェック→予算要求指導→予算要求指導５．重点プロジェクト、その他支援対象プロジェクト
工程レビュー
技術審査会

重点プロジェクトの工程レビュー、モニタリングまたは推進

キックオフ
定例会
工程完了会議その他支援対象プロジェクトのモニタリングまたは推進

プロジェクトの検証
６．システム監査
当年度

システム監査計画策定

監査計画策定システム監査の実施

システム監査の実施※） １～６は、デジタル・ガバメント推進標準ガイドラインのITガバナンス編にて定められているPMO業務

表：府省 IT ガバナンス業務年間スケジュール俯瞰図（中～大規模府省モデル）
注）本表はデジタル庁発足前の体制に基づくスケジュールですが、参考として掲載していま
す。

-

49 -

デジタル・ガバメント推進標準ガイドライン

デジタル・ガバメント推進標準ガイドライン
実践ガイドブック（第３編第３章-

予算及び執行）1 -（第３編第３章 予算及び執行）

目次
Step.1 予算活動の全体の流れ .................................... 6
Step.2 予算要求の事前準備....................................... 8１ 予算要求の活動を計画的に実施する .............................................. 8
A. 予算要求の年間スケジュールを把握する............................... 8
B. 予算要求に向けた作業のポイント ....................................... 9２ 予算要求の対象範囲を早期に決める ............................................ 10
A. プロジェクト計画書を再確認する ..................................... 10
B. 予算要求から漏れがちな項目を理解する............................. 12
C. 関係者との役割分担は早期に確認 ..................................... 14
３ コスト削減の検討 .................................................................. 16
A. ハードウェア・ソフトウェアのコスト削減観点 .................... 16
B. アプリケーションのコスト削減観点 .................................. 17
C. 運用業務のコスト削減観点.............................................. 17
D. その他のコスト削減観点 ................................................ 18

Step.3 見積り依頼 ................................................ 22
１ 見積り依頼書の作成................................................................ 22
A. 要件が未確定な部分を明確にする ..................................... 22
B. プロジェクトの状況によって内訳粒度を変える .................... 23
C. 見積りフォーマットを指定する ........................................ 23
D. 工程の名称の違いをなくす ............................................. 24
E. 見積り手法に注意する ................................................... 24
F. できるだけ詳細な要件を書く ........................................... 25
２ 事業者への見積り依頼 ............................................................. 25
A. 見積りしてくれる事業者を探す ........................................ 25
B. 見積り事業者と対話して、発注者の意図を正しく伝える ......... 26-

2 -（第３編第３章 予算及び執行）

Step.4 見積りの精査 ............................................. 27
１ 人件費の見積り精査................................................................ 27
A. 安易な掛け算の精査 ...................................................... 28
B. 作業重複の精査 ............................................................ 28
C. 主要成果物との比較 ...................................................... 28
D. 開発生産性の精査 ......................................................... 29
２ ハードウェア等の見積り精査 .................................................... 31
A. 製品単価を精査する ...................................................... 32
B. 高額な製品を中心に、必要性を精査し他製品と比較する ......... 32
C. ソフトウェアライセンスを精査する .................................. 33
D. 保守料を精査する ......................................................... 33
３ 複数事業者の見積りの比較 ....................................................... 33

Step.５ 予算要求に必要な資料の準備 ........................ 37
１ 全体像と要点の明確化 ............................................................. 37
２ 予算要求資料の作成上の注意点 ................................................. 38
A. 「予算要求の概要」の作成ポイント .................................. 39
B. 「サービス・業務の説明資料」の作成ポイント .................... 40

Step.6 概算要求に向けた調整 .................................. 41
A. ＰＭＯによる調整 ......................................................... 41
B. デジタル庁による調整 ................................................... 42

Step.7 予算執行について ....................................... 43
１ 執行計画案の作成 .................................................................. 43
２ 執行計画案の調整 .................................................................. 44
３ 予算の移替え・予算執行管理 .................................................... 44
A. 予算の移替え .............................................................. 44
B. 予算執行管理 .............................................................. 45

Step.８ その他の注意点について .............................. 46-

3 -（第３編第３章 予算及び執行）

１ 人事異動時は確実に引継ぎする ................................................. 46
２ プロジェクト計画書に反映して最新化する ................................... 47-

4 -（第３編第３章 予算及び執行）事例・参考の一覧
参考：予算要求時期とプロジェクト計画書策定時期との関係 ...................... 12
事例：第二期政府共通プラットフォームにおけるクラウドサービスの調達 ..... 14
事例：全面的にハードウェア等の構成を見直し運用コストを削減................. 16
事例：第三者保守等を活用したハードウェア保守費用の削減等 ................... 18
事例：PC の保守形態の変更 ............................................................... 20
参考：ＬＯＣ法による工数見積り ........................................................ 24
参考：ファンクションポイント法（ＦＰ法）による工数見積り ................... 24
参考：見積り精査を行うにあたっての参考資料 ....................................... 29
参考：ハードウェア・ソフトウェア等の見積りの記載例 ............................ 31
参考：三点見積りによる予算要求額の算出 ............................................. 33
事例：クラウドサービスの見積りの精査................................................ 34
参考：クラウドサービス特有の料金体系................................................ 35
参考：ライフサイクルコストを考慮した予算要求 .................................... 41
事例：引継ぎ不足により、後日問題が顕在化した .................................... 46※事例には当時の役職名やシステム名を使用しているため、現在使用されていな
い名称が記載されている場合があります。

-

5 -（第３編第３章 予算及び執行）

Step.

1 予算活動の全体の流れ

情報システムに求められる役割は年々増大している中、いかに必要な予算を確保するかということは、プロジェクトの成否を決定づける重要な要素です。
それだけに、付け焼刃的に予算要求を行った場合は、必要な予算を確保することに失敗することにもなり、プロジェクト全体の失敗につながりかねません。
しかし、予算要求時期までに計画的に準備作業を行うことができれば、予算要求に必要となる作業のハードルは、高いものではなくなるかもしれません。本章では、予算要求を計画的に進め、必要な時期までに、必要な検討を終えて、必要な資料を揃えるための方法について説明します。
本章の構成は、次のとおりです。

Step.2 予算要求の事前準備
予算要求の直前に作業が集中したり、手戻り作業が発生したりすることがないように、予算要求を行う前に整理すべき検討事項や事前準備の内容について説明します。

Step.3 予算要求に必要な資料の準備
予算要求では、必要な経費を正確に把握するために事業者に見積りを依頼しますが、自分たちのやりたい事・見積もってほしい事をまとめて伝えるために、見積依頼資料を提示します。見積依頼資料とは、何を準備し、どのような点に気をつけて作ればよいのかを説明します。

Step.4 見積り依頼
情報システムの見積りには、やや専門的で見慣れない表現や内容が含まれることがあります。職員自身が見積りの内容を十分に理解しながら事業者から必要な情報を入手するための具体的な方法を説明します。

Step.5 見積りの精査
見積金額は、過少でも過大でも問題です。必要十分な金額水準とするために、事業者から受け取った見積りに対して内容の過不足を見つけ、より精度を高めるための作業について、その流れと注意点を説明します。

Step.6 概算要求に向けた調整
予算要求作業の流れでは、省内や省外の予算要求関係者に対して、予算の内容、必要性、金額妥当性等の説明を行うことが不可欠です。避けて通れない第３者による様々なチェ
ックや調整で気をつけるべき注意点を説明します。情報システムに係る経費であればこその様々なチェックが入りますので、いつどんなチェックが入るのか、そのチェックをクリアしていく
ためのノウハウをお伝えします。

Step.7 予算を執行する
予算要求が完了したあとの処理について説明します。予算要求が終わりほっとしてしまうと-

6 -（第３編第３章 予算及び執行）

ころですが、予算要求が通ってからがプロジェクトの実質的な始まりですので、プロジェクトの実務を計画的に進めるための準備作業を早めから行っておくことがポイントです。

Step.8 その他の注意点について
その他、予算活動で注意すべきポイントをまとめています。

-

7 -（第３編第３章 予算及び執行）

Step.

2 予算要求の事前準備

予算要求の事前準備として、どのようなことを想像するでしょうか。
とりあえず、３社くらいに見積りを取っておけばよいか・・。そのように安易に考える人もいる
かもしれません。しかし、そのように準備を手抜きした場合は、予算要求内容の査定段階で要求内容の必要性や経費妥当性等を十分に説明することができず、必要な予算額を確保できないということにもなりかねません。
逆に、プロジェクトの目標、内容、経費、効果等について第三者にもわかりやすい説明資料を準備しておけば、その後の査定段階でも関係者の理解を得ることが容易になります。
予算要求の資料をどのように準備していけばよいか、見積りをどのように取得してどう精査すればよいかについて、具体的に説明します。

１ 予算要求の活動を計画的に実施する【標準ガイドライン関連箇所：第３編第３章全般】

予算要求の活動の中では、資料の作成、見積りの取得、関係者との調整等を行います。

A. 予算要求の年間スケジュールを把握する
まずは、予算要求の基本的なスケジュールを見てみましょう。なお実際には、毎年度発出される、事務連絡等の指示に従ってください。（なお、本項では、基本的に一括計上対
象システムについて記載します。）

図 3-1
情報システム関係予算の予算要求の年間スケジュール① 特殊要因登録

特殊要因とは、一時的に大きく増える義務的な経費をあらかじめ財務省に登録することです。例年４月頃に登録し、６月頃まで調整して決定されます。
ただし、認められるには財務省の審査があり、高いハードルを超える必要があります。特殊要因分の金額と通常の概算要求の金額を区別しなければなりませんので、ＰＭＯは財務省との調整結果をデジタル庁に報告する必要があり
ます。

-

8 -

表 3-1
予算要求の年間スケジュール

（第３編第３章 予算及び執行）② 概算要求
内容整理

③ 確認・
助言

④ 最終調整
⑤ 予算編
成・ヒア
リング等

ＰＪＭＯは、予算要求に必要な資料の準備を進め、デジタル庁またはＰＭＯからの指示内容に従って資料を完成させます。この間には、事業者との対話を経て事業者から提出される見積りの精査等も行います。
一括計上対象システムについては、ＰＭＯはデジタル庁からの指示に基づき金額の調整を行い、概算要求額を決定します。
一括計上対象外システムについては、各府省の予算担当（会計課等）にて調整を行います。
なお、概算要求以後に、追加要求はできません。
ＰＭＯが①特殊要因登録や②概算要求内容整理を行うにあたり、悩んだり困ったりすることがあれば、当該案件の内容を踏まえ、必要に応じてデジタル庁へ相談することができます。デジタル庁は、ＰＭＯから相談を受けた内容について、政策的観点・技術的観点・投資対効果の観点から確認や助言を行うこと
で、ＰＭＯの取組を支援します。
概算要求基準を基に予算額の調整を行います。一括計上対象システムについてはデジタル庁にて、一括計上以外のシステムについては、ＰＭＯ及び会計課等にて調整を行い、概算要求額をとりまとめ財務省に提出します。

財務省は、提出された概算要求に基づきヒアリングを実施します。
「要求ヒアリング→宿題対応」を繰り返すことになりますが、回答期間の短い作
業もありますので、迅速に対応できるようにしておく必要があります。

対応⑥ 省庁各担当間等調
整⑦ 補正予算デジタル庁は必要に応じて財務省との間で調整を行います。また、各ＰＭＯや
各ＰＪＭＯとの間で必要に応じて調整を行います。
デジタル庁は情報システム関係予算の概算決定額をとりまとめます。
補正予算編成がある場合には、上記②～⑥までの作業を１か月程度の短い期間で行います。そのため、あらかじめ補正予算に相応しい内容について検討しておくことが必要です。

予算要求・編成作業は、各段階において作業の締切り日が厳格に定められていますので、作業が遅延すると必要な予算を確保できないことになってしまいます。そのような事態とならないため、いつ頃どの作業を行うかを意識し、計画を立てて、十分な時間と期間を確保して進めれば、スムーズに作業を進めることができます。

B. 予算要求に向けた作業のポイント
予算要求の対象の特定
後述する「予算要求から漏れがちな項目」にも注意しながら、予算要求の対象となる項目をピックアップします。また、情報システムの機能に影響がありそうな制度改正の動向や、情報システムの構成に影響がありそうな技術動向等、予算要求の前提となる背景事象については、事前調査も必要となるので、そのための期間を確保します。
当然増減額の整理
当年度限りの経費（当然減）は翌年度予算では計上する必要がなくなります。逆に当年度の途中から運用開始をして、予算上数箇月分しか計上されていないもの（平年度化増）については、翌年度に１２か月分必要となりますので、自動的に増えることになります。
このような、自動的に増減するような経費をあらかじめ特定して、基礎的な金額を把-9 -（第３編第３章 予算及び執行）

握しておきます。
経費の見積り予算要求額の前提となるための見積りを取得します。
見積り対象の規模にもよりますが、事業者に見積り依頼を行ってから見積りを受領す
るまでには、数週間必要になることが一般的です。また、見積り依頼のプロセスは１回で完結するわけではありません。事業者から提示を受けた見積り内容について、対象範囲や積算根拠を確認し、場合によっては前提条件を変更した上で再見積りを依頼することもあります。見積り取得後にこのような精査を含めることも考慮して、経費の見積りに十分な期間を確保しましょう。
資料の準備
予算要求の全体がわかる資料、業務説明資料等を作成します。
特に、新規に情報システムを整備する際には、資料の準備には数箇月にわたって十分な期間を確保することが必要です（大規模な情報システムを新規に構築する場
合は、サービス・業務企画の期間を含めて数年をかけることもあります）。予算要求の内容に応じて、十分な期間を確保できるようにしましょう。

２ 予算要求の対象範囲を早期に決める【標準ガイドライン関連箇所：第３編第３章全般】

情報システム関連の予算要求は、情報システム特有の専門的な言葉や知識が数多く登場するために難しい印象があると思います。また、情報システムの開発や運用を経験したことがない人にとっては、どのような経費がいつ必要になるかが理解しにくいと思います。
まずは、予算要求の前提となるプロジェクト計画書を丹念に読み直してみましょう。プロジェ
クト計画書には、予算要求の対象となる活動が、プロジェクト全体でどう位置づけられ、何を達成し、何の条件を守らないといけないかが書いてあります。これを理解して予算要求作業を進めることで、予算要求の内容が具体的になり、第三者にも理解しやすいものとなります。
では、具体的にどのようなポイントを踏まえ、何を行えばよいかを見ていきましょう。

A. プロジェクト計画書を再確認する
予算要求に当たっては、予算要求年度に必要となる経費だけに着眼してしまいがちですが、プロジェクト全体における「予算要求の全体像」を把握することが大切です。プロジェ
クトが進んでいく過程では、多様な作業が複雑に発生するため、どうしても目前に必要となる作業だけに気を取られることになりがちです。
特に重点的に確認すべき点を、次に示します。

プロジェクト計画書を再確認する際に気をつける点
プロジェクトの目標達成への充足性
プロジェクトの目標を達成することを念頭に、実現するサービス・業務を俯瞰した視点から、必要な作業や経費の漏れがないかを確認します。
例えば、職員の働き方を改善することを目的に持ち運び可能なＰＣを導入するのであれば、ＰＣを導入するだけで通常と同様の業務をリモート環境でも実施できるかを考える必要があります。場合によっては、業務に必要となる紙書類を電子化して参照できるようにしたり、利用頻度の高い情報システムをリモートからでも操作できるよ

-

10 -

注記
リモートとは、固定された場所（自席等）のみではなく、自席以外の会議室、外出先、自宅等のから、職務遂行に必要なサーバへのア
クセス、メール受信等をすること。

（第３編第３章 予算及び執行）

うに変更したりすることが、併せて必要かもしれません。
情報システムを導入することを目的としないように、目指す姿を実現するために必要なことが何か、プロジェクト全体を見渡してもう一度確認してみましょう。
プロジェクトの方向性の確実性
現状分析や検討が十分に行えていない段階でプロジェクトが立ち上がった場合は、担当者の経験や推測に基づいてプロジェクトの方向性を定めた状態となっていることが多いでしょう。このような状態からすぐに情報システムの開発に着手すると、十分な効果を得られない可能性があります。
情報システムの開発や改修のために多額の予算を確保する前に、詳細な現状分析に基づいたサービス・業務企画を実施し、プロジェクトの方向性を検証、改善するための予算を確保することが重要です。
スケジュールとの整合性
プロジェクトの全期間にわたって、必要となる作業の内容、開始時期と終了時期を確認します。特に、作業間で順序関係があるものには注意が必要です。
例えば、情報システムの新規開発を行う際には、遅くともテストを実施する時期までに情報システムが動作する環境が必要です。この環境を構築するためには、事前にサーバやネットワーク機器等のハードウェアを調達することが必要です。また、サーバ等の機器を設置する場所（データセンター）や通信回線については、さらにその前から準備する必要があります。このように、必要となる作業を並べてみながら順序関係を整理し、抜け漏れがないかを確認することが重要です。
役割分担の網羅性
関係者が多いプロジェクトでは、予算要求に先立って、関連する部門の役割分担について綿密に調整することが重要です。設計・開発工程では、情報システム連携、データ移行、テスト等の役割分担、運用工程では障害時対応、利用者からの問合せ対応等については、特に役割分担の観点から問題になりがちです。プロジェクト
計画書やプロジェクト管理要領に記載した体制やステークホルダーを再確認し、予算要求の前提となる基本的な役割分担が決まっていて、予算要求に漏れがないことを確認しましょう。

なお、以下のようにスケジュール表の形で計画を可視化し、各年度で必要となる経費を一覧でまとめておくと、次年度以降の経費項目の要求漏れの防止に効果的です。

-

11 -

（第３編第３章 予算及び執行）

図 3-2
スケジュール表の例

参考：予算要求時期とプロジェクト計画書策定時期との関係
通常のケースでは、まずプロジェクトを立ち上げ、プロジェクト計画書を作成し、現状把握、サービス・業務企画、要件定義等の内容について基本となる方針を決めた上で、必要となる予算について要求を行います。そのため、予算要求を行う前には、検討のための十分な期間と体制を確保する必要があります。
ただ、実際には様々な理由から急な予算要求をせざるを得ず、予算要求の時点
ではプロジェクト計画書が未作成という状況も発生します。このような状況では、どのように対応すべきでしょうか。
基本的には、当該年度の予算要求を見送り、次年度以降に要求することを検討してください。計画と検討が不十分な状態で予算が決まってしまうプロジェクトは、多くの場合に「情報システムが使われない」、「現場の職員が苦労する」等の悲惨な結末を迎えてしまうからです。
しかし、時期的な問題から予算要求を見送ることが難しいこともあります。そのような場合は、例えば、プロジェクト計画書としてのドキュメントの整備は後回しにしたとしても、準備する予算要求資料の中でプロジェクト計画書等に相当する内容を具体的に組み込むといったやり方もあるかもしれません。ドキュメントとしての完成有無よりも、実質的な検討の有無が重要です。また、このような状況で対応方法について迷うことがあれば、ＰＭＯに相談してみましょう。

B. 予算要求から漏れがちな項目を理解する
情報システムを構築する際に、主要な作業経費（設計・開発経費やハードウェア関連経

-

12 -

参考 3-1
予算要求時期とプロジェクト計画
書策定時期との関係

（第３編第３章 予算及び執行）費等）が漏れることはまずありませんが、付随する作業経費については予算要求時点で漏れる可能性があります。
特に、次のような項目については漏れることが比較的多いので、注意してください。

経費項目

留意点

データ移行

新規で情報システムを構築するに際し、既存の情報システムがある場合は、データ移行が発生します。データ移行は、新規情報システムの構築事業者
だけで完結することは難しく、既存情報システムからのデータ抽出等については、既存情報システムの保守運用を行っている事業者と共同で作業を実施することが一般的です。既存事業者側の必要作業について予算要求を漏らさないようにしましょう。
また、データ移行に際して、データ形式の変換用のプログラムが必要となるケースもありますし、既存データの修正（データのクレンジング等）や、データ化されていないデータの電子化（パンチ入力作業等）が必要になることもあります。データ移行の作業後も、テスト工程の中で新旧の処理結果比較を行ったり、新旧情報システムの並行稼働を行いながら最新のデータを移行（差分連携）することも必要になったりします。これらの作業が、予算要求内容に含まれていることを確認しましょう。
さらに、既存情報システムから新規情報システムへの移行に伴い、クラウドサービスの場合は、既存情報システムのデータの抽出自体に費用がかかることに留意が必要です。データ移行が伴う情報システムの構築では、既存情報システムの運用・保守事業者のデータ抽出にかかる費用について予算要求を漏らさないようにしましょう。
なお、既存の情報システムが存在しない新規開発においても、他の情報シス
テムからデータを連携するケースでは初期データの投入が発生する場合もあるため、留意が必要です。

他システム連携

他の情報システムと連携が発生する場合、対向となる情報システム側の予算も検討する必要があります。反対に、対向の情報システムに変更が入る場合も同様に検討が必要となります。
これらは、情報システムに係る変更だけでなく、テスト・移行が含まれることにも留意が必要です。特に連携テストについては、テストを実施する環境（本番
環境ではなくテスト用の環境を双方の情報システムが準備する等）、テストに用いるデータ（本番データに相当するテストデータで重要部分のみマスキン
グする等）、テスト種類（異常系テスト、負荷テスト等を含めた実施範囲）、テス
ト実施方法（スケジュールや体制等）について、事前に十分に調整が行えずにテスト実施時期に問題となるケースがあるため、関係する情報システムの担当者と事前に調整を行いましょう。

システム
操作研修

情報システムの新規構築時や大幅な変更を行う場合、職員向けの操作研修の検討が必要となります。利用者の量や拠点数等により、場所・移動費・人件費等が大きく変動するため留意が必要です。
多数の利用者がいる場合は、利用者が自学自習できるようなｅラーニング環
境を整える、操作研修の模様を撮影して配布する等、操作研修を直接受講できない利用者への対応方法も工夫しましょう。

マニュアル作成

一般的なプロジェクトでは、次の３種類のマニュアルを作成します。
・業務マニュアル（職員向け）
業務全体を対象に実施方法や注意点を記載するもの
・情報システムの操作マニュアル（利用者向け）
情報システムの利用者（職員を含む）向けに、操作方法を説明するもの
・情報システムの運用マニュアル（管理者向け）
情報システムの運用者（職員、事業者）向けに運用方法を説明するもの
特に、新規のサービスや業務内容が大きく変わる場合、業務マニュアルの作
成・更新は必要不可欠であり、効果指標の達成に対しても大きな影響を与え
ます。

-

13 -

表 3-2
見積項目の漏れがちな項目

（第３編第３章 予算及び執行）

経費項目

留意点

運用計画作成情報システムの運用に関する経費は、運用する段階で予算要求すればよいと考えがちです。しかし、実際には設計・開発を行う時点で同時並行的に運用計画を作成し、質の高い運用業務を実施できるように情報システムの設計
内容に反映するとともに、運用体制を確立するための準備を進めます。
運用計画は、効果指標のモニタリングを適切に行うためにも重要です。日々の運用業務を行うなかで、情報システムが利用者に使われているか、利用者に役立つ効果を達成できているかを定期的に把握するため、各種ログや主要統計指標を分析できるように考慮しましょう。

引継ぎ

プロジェクトに関係する事業者との契約が切り替わる際には、事業者間での引継ぎが必要になります。例えば、設計・開発事業者から運用事業者への引継ぎでは、設計・開発工程で作成した運用計画や手順書の内容を引き継ぎます。
引継ぎをスムーズに行うためには、現行の運用事業者から新規の運用事業者への引継ぎにおいて、運用手順等の内容に加えて、過去に発生した課題と対応方法、過去の経験から判明した注意すべき点などについて、具体的な内容を引き継ぐことが有効です。また、設計・開発事業者と運用事業者の契約期間の設定を工夫する方法があります。（実践ガイドブック第 3 編第 7 章
Step6-2 事例：異なる事業者間で引継ぎをスムーズにする工夫 参照）
引継ぎへの対応は、引継ぎを行う側の事業者にも、引継ぎを受ける側の事
業者にも必要です。予算要求の時点で、検討漏れがないか注意しましょう。

サポート
終了対応

情報システムを構成するハードウェア、ソフトウェア等の製品には、製品供給
元からのサポートサービスの提供期限が定められていることが一般的です。
特に、各種ソフトウェア（ＯＳ、ブラウザ、アプリケーションサーバ用のミドルウ
ェア、データベースサーバ用のミドルウェア等）については、バージョン別に
細かくサポートポリシーが設定されており、注意が必要です。
サポートが切れた製品の利用を継続すると、当該製品に対するセキュリティ
脆弱性等の問題が発生した際に製品供給元からの対応が行われない可能性があります。そのため、原則として、サポートが終了するまでに後継製品を導入する等の対応をとってください。

C. 関係者との役割分担は早期に確認
予算要求に当たって、他プロジェクトにも影響がある場合は、可能な限り早期にその状況を伝えましょう。最初の一報を入れる際には、影響の詳細がわかっていなくても構いません。法改正への対応等が典型的な例ですが、影響範囲が確実に判明する時期まで待っていると、他プロジェクトへ連絡する時期がとても遅くなってしまいます。影響が発生する可能性を把握した段階でまず一報を入れ、その後に影響範囲が具体的に見えた段階で続報を入れるといった段階的な伝達を行うことで、影響を受ける側のプロジェクトにとっても十分な検討期間を確保することができます。
また、予算要求を行う時期までには、それぞれのプロジェクト間で対応方法に関する役
割分担を決めましょう。役割分担が不明確なままでは、双方のプロジェクトが必要以上に作業範囲のリスクバッファを積む形となり、結果的に過大な予算要求内容となってしまうためです。

事例：第二期政府共通プラットフォームにおけるクラウドサービスの調達

事例 3-1
第二期政府共通プラットフォーム
におけるクラウドサービスの調達

クラウドサービスの調達・契約にはどのような方法があるのでしょうか。
現時点では、アプリケーションの設計・開発、クラウドサービスの利用、それらの運用・保守等を一括で委託し、その総額を固定した形で契約するケースが多くなっています。

注記
第二期政府共通プラットフォーム
におけるクラウドサービスの調達とその契約に係る報告書

https://cio.go.jp/node/2703

-

14 -

（第３編第３章 予算及び執行）

一方で、第二期政府共通プラットフォームでは、クラウドサービスの利用分を実績額で支払うという従量課金の形態で契約を行っています。その詳細については、「第二期政府共通プラットフォームにおけるクラウドサービス調達とその契約に係る報告書」の中で、今後のクラウドサービスの調達・契約を検討する際に参考とできるように、本調達の検討過程で議論された論点や留意点を記載しています。以下でその一部をご紹介します。
また、実践ガイドブック「第 3 編第 6 章 Step.2-1-B.参考：クラウドサービスの調達にあたって検討すべき点」では、クラウドサービスの契約期間を検討する上での参考を掲載しているので、本事例と併せてご確認ください。
・直接契約／間接契約の検討
クラウドサービスの契約方法については、クラウドサービス提供者との直接契約と中間事業者※を介してクラウドサービスの提供を受ける間接契約を検討しました。（※
クラウドサービス提供者が提供するクラウドサービスに関する契約行為、支払行為等のすべてを代行する事業者のことです。）

直接契約のメリットとして、当該クラウドサービスの提供に不具合が発生した場合に、原因追及や対処方法等が早く提供されることや、コスト面において中間マージンが発生しないことが考えられます。しかし、調達プロセスを経て直接契約を締結する
ためには、クラウドサービス提供者特有の契約の考え方や事務処理について課題があり、令和２年度においては採用できないと判断しました。
・従量課金（単価契約）の検討
利用料金の観点については、利用した分だけ支払うという従量課金を実現できる契約方法を検討しました。
国の契約においては、総額をもって契約する総価契約が原則ですが、特例として、単価契約が認められています。単価契約とは、契約上の数量が確定できないものについて、単価を契約の主目的とし、期間を定めてその供給を受けた実績数量を乗じて得た金額の代価を支払うことができる契約形態です。
クラウドサービスの調達におけるコストメリットの達成方法の一つは、従量課金による契約であり、政府共通プラットフォームにおいては、従量課金のメリットを最大限活かすために単価契約の契約形態としました。
ここまで第二期政府共通プラットフォームにおける調達・契約の論点の一部を紹介しましたが、採用するクラウドサービスやシステム規模などの違いによって、適切な調達・契約が異なるため、各システムの実情に合った検討が必要です。例えばクラウドサービスで従量課金（単価契約）を採用する場合、アプリ部分とインフラ部分とで契約が分かれることで煩雑になることもあります。また、第二期政府共通プラットフォー

-

15 -

（第３編第３章 予算及び執行）

ムでは今後の利用システムの増加に柔軟に対応することなどを考慮して、単年度で間接契約を継続する形としています。一方で、クラウドサービスの中には複数年予約型割引を適用することで、安価にできるケースもあります。
このように契約方式や契約期間等について、様々な観点から比較・検討することが必要です。

３ コスト削減の検討【標準ガイドライン関連箇所：第３編第３章第４節】

既に情報システムが導入されている場合は、見積りを依頼する前に、まず現状の情報シス
テムのコストを削減する余地がないかチェックしてみましょう。
また、新規に情報システムを導入する際も、これから予算要求を行う対象に無駄がないかチェックしてみてください。

A. ハードウェア・ソフトウェアのコスト削減観点

削減観点

留意点

A1

サーバの統合や削減

サーバの全体構成や使用率、ピーク特性等を把握した上で、サーバの統合や削減等を行う。

A2

端末の統合や削減

端末の全体構成、使用率、ピーク特性等を把握した上で、不要な端末削除や同一端末への機能集約を行う。

A3

専用機器の標準機器へのリプレース

特定の情報システムのみで利用可能な専用端末、専用プリ
ンタ及び専用通信機器などの機器類を、一般に市場で調達可能な標準製品にリプレースする。

A4

周辺機器の削減・機種統
一等

プリンタ等の周辺機器について、使用率、ピーク特性等を把握した上で不要な機器の削除、機種統一等を行う。

A5

システムアーキテクチャの変更

メインフレーム型のシステムアーキテクチャを刷新し、 Web
サーバ型などに変更する。

A6

ソフトウェアの集約や削減

サーバや端末等における市販ソフトウェアの利用状況を調査し、ライセンス数の見直し等を行う。

A7

オープンソースソフトウェアの活用

オープンソースソフトウェアへの代替可能性を検討し、ソフトウェア利用に要するコストを削減する。

A8

ハードウェア・ソフトウェアの保守条件の見直し

保守時間帯、保守実施方法等の条件を見直し、過剰な条件を修正することで保守費用を削減する。

A9

機器やソフトウェア単位での保守対象等の見直し

保守費用／借料の比率確認、細かな構成機器に対する保守の見直し、予備機のハードディスクへの保守の見直し、業
務利用しないソフトウェアの保守の見直し等を行う。

A10

レンタル契約の見直し

長期にわたってレンタル契約を締結している場合に、買取り
又はリース契約等への変更を行い、全体経費を削減する。

事例：全面的にハードウェア等の構成を見直し運用コストを削減あるプロジェクトでは、全国に存在する多数の業務拠点ごとに拠点サーバを配置
し、中央のデータセンタには本番環境以外にも本番環境とほぼ同じ構成の環境を複数用意するなど、多数のハードウェアに多額の投資を行っていました。

-

16 -

表 3-3
ハードウェア・ソフトウェアのコスト削減観点

事例 3-2
全面的にハードウェア等の構成を見直し運用コストを削減

（第３編第３章 予算及び執行）

しかし、実際にハードウェアの使用状況（ＣＰＵ使用率等）を詳細に確認してみると、サーバを廃止、集約したり、データセンタやネットワークを見直したり、大きく改善の余地があることが判明したため、全面的な構成見直しを行うこととしました。
また、サーバ構成の見直し等は次期更新時まで待つ必要がありましたが、すぐに取り組める改善事項として一部の不要機器を即時撤去することで保守費を削減した
り、新規機器を導入予定であった部分に不要機器を転用したりといった工夫も行いました。
「すぐにできる改善」と「次期更新時の改善」の両方の観点から、総合的に取組を行った結果、大幅な運用コスト削減を実現することができました。
すぐにできる改善【センター】

不要機器の即時撤去（保守費の削減）
別途必要なものをサーバ転用で代替使用率の低いサーバの廃止・集約

ネットワークの見直し
データセンタの集約

次期更新時の改善
拠点サーバの廃止

【拠点Ａ】

【拠点Ｂ】
周辺機器の廃止（プリンタ、OCR等）

サーバ構成の見直し
周辺機器の廃止
ネットワークの見直し
データセンタの集約

B. アプリケーションのコスト削減観点

削減観点

留意点

B1

保守実績の把握による工数精査

アプリケーション保守に関する作業実績を確認し、必要に応じて工数や生産性を見直す。

B2

利用頻度の低いアプリケーションプログラムの廃止

アプリケーションの機能単位等で利用状況を調べ、利用頻度の低いアプリケーションプログラムを廃止する。

B3

システム管理対象データのスリム化

保存期限を超えたデータを削除する、媒体に退避する等の対策により、管理対象データをスリム化する。

B4

アプリケーションプログラムの保守条件の見直し

保守時間帯、保守実施方法等の条件を見直し、過剰な条件を修正することで保守費用を削減する。

B5

保守作業の効率化

テスト工程の手順や環境の見直し、ＯＳバージョンアップ対応の効率化等の工夫により、保守作業を効率化する。

C. 運用業務のコスト削減観点

-

17 -

表 3-4
アプリケーションのコスト削減観点

（第３編第３章 予算及び執行）

削減観点

留意点

C1

運用実績の把握による工数精査

運用に関する作業実績を確認し、必要に応じて工数や生産性を見直す。

C2

運用業務の効率化、一元化

複数情報システムでの運用一元化や、オペレータの集約
等、各種作業の見直し等により、運用業務の効率性を高める。

C3

運用作業のピーク平準化

リリース作業、帳票印刷、データ入力等の業務ピーク特性を把握し、運用作業のピークを平準化することで運用業務全体の工数を削減する。

C4

冗長化・ＢＣＰ対策の適正化

東日本大震災以降、各府省の業務システムのバックアップ
体制の充実が図られたが、冗長化・ＢＣＰ対策が過剰と思われるケースも散見されるので、可用性要件とコストの実態を把握し、適正化を検討する。

表 3-5
運用業務のコスト削減観点

D. その他のコスト削減観点

削減観点

留意点

D1

サービス内容の見直し

ASP、SaaS、PaaS、ホスティングサービス等について、利用実績等を勘案してサービスの必要範囲を見直す。

D2

ネットワークの統合

ネットワークの全体構成や使用率、ピーク特性等を把握した上で、ネットワークの統合や削減等を行う。

D3

ネットワークの保守条件の見直し

保守時間帯、保守実施方法等の条件を見直し、過剰な条件を修正することで保守費用を削減する。

D4

データセンタの統合や条件見直し

複数データセンタの集約等を検討し、データセンタへの経費を削減する。

D5

関連経費の見直し

研修、ヘルプデスク、コールセンタ、監査、情報セキュリティ
検査等について、実施回数、実施内容、実績等を勘案して範囲を見直す。

事例：第三者保守等を活用したハードウェア保守費用の削減等あるプロジェクトでは、50 台弱の物理サーバを持つ業務系情報システムのハード
ウェア/ソフトウェア製品について、第三者保守等を活用し、保守費用の削減等を実現しました。
＜第三者保守の活用＞
第三者保守とは、メーカーによる直接的な保守サービスではなく、メーカー以外の第三者が保守サービスを提供する形態です。海外では導入事例も増えており、日本国内でも第三者保守サービスの調達が可能なことが判明したため、その利用を検討しました。
複数の第三者保守ベンダーに対象機器リストを提示して保守料の簡易見積りを依頼したところ、サーバやネットワーク機器等の汎用的な製品については、従来の保守金額と比べて、安価に保守サービスを受けられることがわかりました。一方で、一部の機器については第三者からの保守サービス提供が難しいことが判明しました。（注

-

18 -

表 3-6
その他のコスト削減観点

事例 3-3
第三者保守等を活用したハード
ウェア保守費用の削減等

（第３編第３章 予算及び執行）意点として後述）
また、費用面だけでなく保守条件についても検討した結果、当該プロジェクトにおいては、従来の SLA と同等なサービスを維持できることを確認しました。
上記のことから、当該プロジェクトにおいて第三者保守を活用することとした結果、システム更改のサイクルの長期化と保守費用の削減を実現することができました。
（注意点）
第三者保守を活用する際には、以下のような点について、注意が必要です。
①第三者保守は中古市場から保守部品を調達するため、シェアの低い製品や特殊な機器等は対応ができません。
②第三者保守は新製品には対応できないため、最初の数年はメーカー保守が必要です。
③メーカー直接保守に比べて、修理時間の拡大とシステム稼働率の低下が発生する可能性があるため、リスクの検討を行った上で SLA の見直しが必要になる場合があります。
＜調達におけるその他の工夫＞
当該プロジェクトでは、従前、ハードウェアのメーカーも様々であるため、保守を全体管理する請負事業者に一括で委託し、サポート窓口となる事業者経由で各メーカ
ーの保守サービスを受けていました。
今般、第三者保守を採用するにあたり、調達単位を見直し、第三者保守サービ
ス、メーカー直接保守（定額保守）、メーカー直接保守（オンコール保守）の３つの契約形態に分割して調達を行う工夫をした結果、保守経費を従来よりも削減することができました。
なお、この場合においては、保守契約を複数に分割しているため、障害発生時の一次切り分け（障害機器の特定）を発注側で行う必要があることに注意が必要です。

-

19 -

（第３編第３章 予算及び執行）事例 3-4
PC の保守形態の変更

事例：PC の保守形態の変更
府省の LAN システムでは、多くの PC を導入しています。また、個別の情報システ
ムでも専用の PC を導入しているものもあるでしょう。これらの PC の保守はどのような形態で行っているでしょうか。
あるプロジェクトでは、PC について年単位での定額保守契約を行っていました。
定額保守といっても、全ての事象について契約金額内で修理できるわけではありません。PC 自体に衝撃を加えてしまった場合、飲み物をこぼしてしまった場合等でディスプレイ交換や基盤ボード交換に至るケースがありますが、利用者側の過失による故障については基本的に定額保守契約を結んでいたとしても、修理内容に応じて追加料金が必要となります。
そのような事情も勘案した上で、どういった保守形態が適切かを検討するために、
直近３年間の PC の故障実績を調べてみました。
実績を調査した結果まずわかったことは、故障件数が多いのは導入１年目であり、しかもこれらの故障は１年間のメーカー無償保証でカバーされる初期不良が多いということでした。
ついで、導入 2 年目以降は修理に追加料金が必要な故障が多く定額保守契約の範囲で対応可能な故障が実はあまり多くないということでした。
以上の調査結果から、定額保守契約を結んだ上で修理内容に応じて追加料金を支払う場合と、定額保守契約は結ばずに導入１年目のメーカー無償保証とスポット
保守（PC の故障の都度に有償で対応依頼）を併用する場合の料金を比較してみると、定額保守契約と追加料金の合計金額よりも、１年目のメーカー無償保証とスポッ
ト保守を併用する場合の合計金額のほうが、低くなることがわかりました。
＜定額保守とスポット保守の料金比較＞
作業日
故障内容
修繕内容
作業日
故障内容
修繕内容
作業日 4/10
故障内容
修繕内容
起動不可
メインボード交換
4/10 起動不可
メインボード交換
4/10 起動不可
メインボード交換
5/1
LAN切断頻繁
メインボード交換
5/1
LAN切断頻繁
メインボード交換
5/1
LAN切断頻繁
メインボード交換
5/1
キーボード不良
キーボード交換
5/1
キーボード不良
キーボード交換
5/1
キーボード不良
7/12 HDDエラーキーボード交換
HDD交換
7/12 HDDエラー
HDD交換
7/12 HDDエラー
HDD交換LCDパネル交換
7/26 画面表示障害
7/26 画面表示障害
LCDパネル交換
7/26 画面表示障害
・・・・・・LCDパネル交換
・・・
・・・
・・・
・・・
・・・
・・・
・・・ ・・・
・・・
・・・
・・・
・・・
・・・
・・・
・・・
・・・

金額
金額
金額
50,00050,00050,000 50,000
50,00050,000 10,000
10,00010,000 50,000
50,00050,000 70,000
70,00070,000 ・・・
・・・
・・・
・・・
・・・
・・・

定額保守
スポット保守N 年度

N＋1 年度

N＋2 年度

この比較結果を踏まえて、翌年度からは定額保守契約を結ぶよりも、実績に基づいた保守の予算要求を行った上でスポット保守に切り替えることとしました。

-

20 -

（第３編第３章 予算及び執行）

また、業務の継続性を確保するため、修理の間もユーザの業務に支障がでないよ
う実績に基づいて故障率を算出し、必要な台数の代替（予備）機をあらかじめ調達しておきました。
なお、予算要求についてはこの実績資料を根拠として想定される修理金額と代替機の金額を算定し、単年度で要求する形としました。
機器の故障のような予測しにくい出来事については、何が起きても対応できるように「定額」、「フルサポート」のようなサービスを選んでしまいがちです。しかし、そのよ
うなサービスは必要以上にコストがかかってしまいます。実績を調べた上で、業務の継続性を確保しつつ、サービスを適切な水準に見直すことがとても重要です。

-

21 -

（第３編第３章 予算及び執行）

Step.

3 見積り依頼

正確な情報を伝えれば、正しい見積りが返ってくる。
確かにそのとおりなのですが、これを行うことは容易ではありません。そもそも正確な情報がない中で見積らなければいけない状況も多く、そのことに苦労しているのではないでしょうか。
また、情報システムに関する作業内容や製品選定は、専門的な知識がないと正確に理解することが難しいため、事業者から提示された見積りを精査することが難しいという実感を持っているかもしれません。
まずは、情報システムの見積りの特性を理解した上で、どのように見積り依頼を行えばよい
情報を入手することができるかを解説していきます。

１ 見積り依頼書の作成【標準ガイドライン関連箇所：第３編第３章第４節】

プロジェクトの初期の段階で事業者に見積りをお願いするときに、細かい粒度の見積りを求めて嫌がられたり、協力を得られなかったりしたことがありませんか？また、見積りの比較検討の際に、比較のための編集作業に大変な労力を割いたことがありませんか？
事業者に見積りを依頼するときに工夫をしておくと、後で見積りを比較したり精査したりする
際に苦労をしなくて済みます。見積りを依頼する際のポイントを見ていきましょう。

A. 要件が未確定な部分を明確にする
見積りを依頼するタイミングによっては、情報システムに求める機能や前提条件等について、詳細な内容が決まっていないこともあります。例えば、プロジェクト初期段階の見積り
では、十分な現状把握や要件の検討ができていないこともあります。また、新しい制度を導入する場合や、既存の制度を変更する場合等においては、制度自体の方向性や内容が、見積り依頼時期にはまだ定まっていないこともあります。
見積りを依頼する場合は、見積りの対象や前提条件を明確にすることが大前提ですが、サービスや業務を開始する時期の１年ほど前に見積りを依頼する必要があるため、現実的には上述した例を含めて、未確定な部分が発生することもあります。
見積りの対象や前提に未確定な内容がある場合、次の点に留意してください。

未確定な内容がある場合に気をつける点
見積りを依頼する要件の中で詳細が未確定な箇所には、未確定である旨、その理由、どのタイミングで詳細化できる予定であるかを記述する。
未確定な箇所については、できるだけ複数の対応案を示し、それぞれの対応案に対して見積り金額を把握できるように見積り依頼を行う。また、見積り前提が変わった
際の影響範囲（見積り金額だけでなく、工期や連携先情報システムへの影響等を含めた全体的な影響）について事業者に確認する。
未確定な箇所を一覧にまとめる。後述するプロジェクトの概要の前提条件・制約として記述する。

-

22 -（第３編第３章 予算及び執行）

ただし、大前提としての注意点ですが、精度の高い見積りを取得するために、まずは、見積り前にできる限り詳細を決定するようにしてください。

B. プロジェクトの状況によって内訳粒度を変える
見積りは、サービス・業務の内容や情報システムが提供する機能等の要件が明確になればなるほど精度が上がっていくものです。特に、プロジェクトの初期段階の見積りは、実際にかかる費用と見積りは大きくかい離していることが一般的です。
一方で、見積りを行う事業者にとっては、見積りに求める粒度が細かくなればなるほど見積りにかかる労力が高くなります。サービス・業務企画の内容や情報システムの要件の大半が未確定の段階で粒度の細かい見積りを求めても、詳細な根拠がないため、想定条件を設定した上での按分計算等により、見た目だけ細かくするだけの結果となってしまいます。
結果として事業者は無駄な労力を消費し、ＰＪＭＯは精査に必要以上の時間を使ってしまう
ことになりかねません。また、見積り算出に係る負荷を敬遠して、事業者から見積りの協力すら得られないことも往々にしてあります。
見積り内訳は細かい粒度であるほど精査を行いやすくなりますが、要件が十分に精査できていない段階で見積り内訳だけを細かく要求することにも無理があります。プロジェクトのシチュエーションに合わせて適切な粒度を検討することが重要です。

シチュエーション

粒度の設定例
粒度：大主要な機能の単位等で必要工数や金額の提示を依頼する。詳細な実現方法等については、機能の向上やコストの低減を含めて事業者からの提案の余地を含めた粒度とする

情報システムを新規に構築する場合

粒度：中
既存情報システムの改修や機能追加等を行う場合（前提となる要件が不明確）

法改正の詳細条件が不明な中で予算要求を行う必要がある場合等においては、対応する範囲について前提条件を置いた上で、改修等に必要となる大まかな作業単位で工数の内訳を求める
粒度：小既存情報システムの改修や機能追加等を行う場合（前提となる要件が明確）必要となる作業が明確であるため、改修対象となる画面数、帳票数、バッチ処理数等を事前に分析した上で、必要な作業を詳細な粒度で積算するように内訳を求める。

C. 見積りフォーマットを指定する
一般的に、事業者は各社独自の見積りフォーマットを使って見積りを行います。複数事
業者から見積りを取得した後、発注者側が各社の見積りを比較して差異を確認することになりますが、見積りフォーマットがバラバラだと比較や事業者への問い合わせに大変な労力を要します。
無駄な労力を使わないよう、見積り依頼時に見積りフォーマットを指定しましょう。各府省で見積りフォーマットを準備していれば、それを有効活用してください。
なお、複数事業者に見積り依頼を行う際は、見積りフォーマットの表頭（最初の１行目にあるヘッダ部分）だけを指定するのではなく、表側（最初の１列目）に主要な作業項目や機

-

23 -

表 3-7
シチュエーションごとの見積り粒度の設定例

（第３編第３章 予算及び執行）能を指定しておくことを推奨します。見積り結果を受領した後で各社の見積り内容を比較する際に、合計金額だけでなく内訳単位で比較を行うことができるからです。また、同じ内
訳単位で比較して金額の差が大きい場合は、その理由を事業者に再確認することで、金額水準や見積り条件を見直すことができるようになります。

図 3-3
見積りフォーマット（アプリ開発）の例

D. 工程の名称の違いをなくす
複数の事業者へ同一内容の情報を提供しても、回答する事業者によってその情報の捉え方が異なることがあります。例えば「詳細設計」という作業名称は、事業者によって呼び名が違ったり実施する内容が異なったりすることが多々あります。見積り依頼時に工程の名
称と工程の示す作業範囲を指定すると、受領した見積りの比較検討が楽になります。
標準ガイドラインで定義する工程と事業者各社が用いる工程の名称の比較は、「第７章
表 7-1 標準ガイドラインと各社が定義する工程の比較」をご参照ください。

E. 見積り手法に注意する
見積りを客観的に評価するためには、検証可能な計算式により見積根拠を明らかにしておく必要があります。
作業工数（人件費）の見積り方法は、発生する作業単位で必要な人数と期間を算出して足し上げる「積み上げ法」が実務的にはよく見られますが、その他にもシステムの開発規模から見積りを行うＬＯＣ法、ＦＰ法等があります。

参考：ＬＯＣ法による工数見積り

参考 3-2
ＬＯＣ法による工数見積り

類似情報システムや過去の開発実績を基に、アプリケーション（プログラム）のステ
ップ数を類推し、アプリケーションの規模を見積もる手法です。 そのアプリケーションの規模を開発生産性で除したものが、開発工数となります。

参考：ファンクションポイント法（ＦＰ法）による工数見積り
アプリケーションの規模を測定する手法の一つで、アプリケーションが持つ機能数（内部論理ファイル、外部インタフェースファイル、外部入力、外部出力、外部照会の各機能の数）を洗い出し、洗い出した機能を複雑さによって重み付けをして、集計した値にシステム特性を加味する方法によって、そのアプリケーションの規模を見積る手法です。 そのアプリケーションの規模を開発生産性で除したものが、開発工数に
なります。

-

24 -

参考 3-3
ファンクションポイント法（ＦＰ法）
による工数見積り（第３編第３章 予算及び執行）

理想的な状態は、見積り依頼時に発注者側が見積り手法を指定し、同じ手法を前提に複数の事業者の見積りを比較できることです。
ただし、事業者もそれぞれ自社の標準的な見積り手法に基づいて経験を培ってきています。そのため、見積り手法を限定的に指定することによって見積り精度が落ちたり、事業者の協力を得にくくなったりすることもあります。見積り手法の指定が難しい場合は、事業者が選択する見積り手法で積算することになりますが、その際においても算定根拠となる計算式や基礎数値は明記するように依頼してください。
LOC 法でもＦＰ法でもプロジェクトの中で過去の生産性指標を蓄積することを推奨します。
発注者と事業者が共通の物差しで開発規模や生産性を測定し共有することによって、見積金額の妥当性を評価しやすくなると共に、見積もり根拠を対外的にも説明し易くなります。

F. できるだけ詳細な要件を書く
以上のような注意点を参考にしながら、見積り依頼書を作成してください。
事業者が詳細な根拠に基づいて正確な見積りを作成できるように、開発する情報システ
ムに求める機能要件（機能一覧、画面一覧、帳票一覧、外部インタフェース一覧等）と非機能要件（の機能要件を整理して、提示しましょう。
なお、現行情報システムに対する改修の場合は、システムの規模を参考にできるため、現行情報システムのＬＯＣ値やファンクションポイント数を、参考資料として提示します。

２ 事業者への見積り依頼【標準ガイドライン関連箇所：第３編第３章第４節】

予算要求時点の見積りは、調達時の見積りとは違い事業者の受注に直結しないため、事業者も大きな労力を割きづらく、事業者の見積り協力を得にくいことや、意図にそぐわない見積りとなることがあります。
事業者から欲しい見積りを取得するためには、協力してくれる事業者を効率的に探し、資料では伝わりにくい意図を対話によって的確に伝えていくことが大切です。
事業者から良い見積りを効率的に取得するポイントを見ていきましょう。

ポイント
見積り依頼できる事業者が見つからない又は少ない場合は、ＰＭＯ等に協力を依頼する。
事業者の見積り精度を上げるために、事業者との意思疎通を十分に行い、発注者側の意図ややりたいことを正確に伝える。そのためには、説明会・ヒアリング等を積極的に活用する。

A. 見積りしてくれる事業者を探す
見積りは、原則として、複数の事業者から取得し、取得結果を比較・検討する必要があります。見積りを依頼できる事業者が見つからないときは、ＰＭＯ、デジタル庁に相談してください。
また、事業者から見積り辞退の回答を得たときは、その理由を確認し、情報不足や調達内容の制約等、見直しが可能な事項は見直しを検討しましょう。

-

25 -

（第３編第３章 予算及び執行）

留意事項
事業者を選定する際は、事業者間に資本関係がないことを確認してください。資本関係がある場合、見積りの客観性の問題があったり、利害関係から見積りを辞退されたりする可能性があります。
クラウドサービスを利用して、モダンな情報システムを構築する場合は、モダン技術に明るい事業者に依頼しましょう。
現行システムがオンプレミスであり、既存事業者が見積もった場合、オンプレミスと同様の構築手法を前提とした見積りが提示される可能性があります。そのため、モダン
技術に明るい事業者も含めて見積りを依頼し、提出された見積りの前提や技術的な妥当性等の情報を比較の上、より良い見積りを採用しましょう。
「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」に見積り取得時の留意点を記載しているので、見積りを依頼する前に確認し、適切な事業者を選定するようにしましょう。

B. 見積り事業者と対話して、発注者の意図を正しく伝える
特に、プロジェクト初期段階のサービス・業務企画や情報システムの要件が粗い場合は、資料だけではプロジェクトの趣旨や実現したい内容、欲しい見積りの粒度等が伝わりにくく、結果として発注者の意図に合わない見積りとなり、双方にとって無駄な労力となることもあります。
事業者の見積り精度を上げるためにも、事業者との意思疎通を十分に行い、発注者側の意図ややりたいことを正確に伝えることは重要です。そのために、事業者への説明会を開催したり、見積り内容に対するヒアリングを行ったり、様々なコミュニケーションを通して発
注者の意図を正しく伝えましょう。

-

26 -

注記
モダン技術とは、令和 4 年度現在であれば、マイクロサービスア
ーキテクチャ、API、クラウドネイテ
ィブ、マネージドサービスのみによる構成等の新しい技術のこと。

（第３編第３章 予算及び執行）

Step.

4 見積りの精査

情報システムの開発や運用等を委託する事業者は、情報システムを運営していくためのパートナーですので、事業者と良好な関係を維持することはとても重要です。
ただ、この良好な関係とは、決して業務の一切を事業者任せにする状態ではありません。
適切な役割分担の下で緊張感を持って協働することこそが、良好な関係です。このことは、事業者が提示する見積の精査についても当てはまります。つまり、発注者側である職員が見積
内容を十分に理解し、前提条件や取り得る選択肢を理解した上で、実現機能と価格のバラン
スを取ることが求められます。見積り金額を減らせばよいというものでもありません。必要不可
欠な項目が抜け落ちてしまうと、システム開発や運用の段階で大きな問題になります。
見積りの精査は、実際には簡単なものではありません。ハードウェア、ソフトウェアの見積りには専門的知識がないとわからない横文字が列挙されていますし、人件費の工数積み上げについても、どのような観点で確認すべきか迷うことがあるでしょう。
見積り金額を適切な範囲に収めるとともに、発注者側・事業者側の双方がこの先の工程で円滑に活動ができるために、見積りを精査する具体的な方法について解説します。

１ 人件費の見積り精査【標準ガイドライン関連箇所：第３編第３章第４節】

情報システムの設計、開発、試験等に関わる経費、アプリケーション保守や運用に関わる経費等、多くの経費はＰＭ（プロジェクトマネージャ）、ＳＥ（システムエンジニア）、ＰＧ（プログラマ）、等の人件費で構成されています。人件費の積算は、基本的に工数と単価の掛け算です。工数については、「人月」や「人日」といった単位で表されます。４人体制で 15 日間の作業が必要な場合は、60 人日（３人月）の工数になります。そして、人件費単価が 120 万円/人
月であれば、掛け算をして合計 360 万円となります。人日と人月の換算は、営業日ベースで計算するので、20 人日を１人月とすることが標準的です。
見積りの中で、数十人月、数百人月といった大きな単位で一式としての工数が示されても、その中に様々な作業が混在して合算されているため、個々の作業工数の妥当性を判断することができません。まずは、工数内訳を詳細に確認できるようにしてください。
工数の内訳は、機能や作業単位で分けることが非常に重要です。時々、数百人月といった大規模作業を、工程単位（設計、開発、試験等）、期間単位（月ごとの工数等）、要員種別
単位（ＰＭ、ＳＥ、ＰＧ等）で分けて、一見すると詳細な内訳として提示されることがあります。しかし、このような分け方ではこれ以上精査することが困難です。
居酒屋のコース料理に例えると、本来、料理のメニューや飲み放題の時間等のサービス内
容面で金額が決まるはずなのに、料理人の人数や作業時間だけで金額を説明しているようなものです。そのような内訳では、サービス内容を調整して料金を変えることも困難ですし、サービスごとの費用妥当性を判断することも困難です。
個々の経費項目の必要性や生産性水準について精査できるようにするためには、実現する機能単位、実際に発生する作業単位での詳細工数が明記された見積が不可欠です。このような見積が提示されていない場合は、事業者に対して見積精査上の必要性を伝えた上で、必要な粒度での工数見積を取得しましょう。

-

27 -

（第３編第３章 予算及び執行）

A. 安易な掛け算の精査
画面、帳票等を作成、改修する際に、単純に画面数等の数量で掛け算をして工数が積算されることがあります。また、データの入力、変換等の各種作業を実施する際にも掛け算が利用することがあります。ただ、安易に掛け算を行うと、工数が過大に積算される可能性があります。
例えば、作業を共通化、自動化できる可能性があります。作業対象が 10 件あったとしても、作業全体工数が１つの作業工数の 10 倍になることはほとんどありません。作業工数の中には対象件数によらず必要となる共通部分があるため、その部分を外へ括り出すことが必要です。また、作業件数が増えた場合は自動化の工夫を行うことも有効です。ツールの作成や設定等、自動化のための準備作業に一定の工数がかかるものの１件当たりの作業
工数を大幅に削減できるので、全体としての工数を下げることができます。

B. 作業重複の精査
見積書の各作業項目を見比べると、類似の名称の作業項目が存在したり、成果物が同一と思われる作業が列挙されていたりすることがあります。
例えば各種の設計を行う作業についても、見積書では方式設計、構成設計、環境設計、
データ設計、機能設計、性能設計、パラメータ設計など、様々な名称が使われることがあります。これらの作業項目の名称だけでは重複有無を判断しにくいですが、各作業の成果
物（ドキュメント）を明らかにすると、重複を発見しやすくなります。
また、事業者間での作業重複についても気を付ける必要があります。例えば、複数事業者協働してテストを実施する際に、それぞれに事業者がテスト工数を見積ります。ただ、実際のテスト作業においては、テスト計画書の作成、テストシナリオの準備、テスト環境等の準備、テストの日程や体制の調整といった前工程作業や、テスト結果のとりまとめ等の後工程作業を主体的に担う事業者が１社存在し、残りの事業者はその活動を支援しながら自社分の部分的な役割を担うことが多いです。この場合、工数積算においては、支援側の工数が相対的に少なくなるはずです。テスト工程だけでなく様々な工程で、事業者の作業分担を確認した上で工数のバランスを確認することが重要です。

C. 主要成果物との比較
工数の妥当性を判断する際の拠り所は、その作業によって完成する成果物の質と量です。
特に、システム開発では様々な種類のドキュメントを作成します。要件定義書、各種設計書、構築作業の設定書や手順書、テスト計画書、テスト結果報告書、運用設計書、運用手
順書、マニュアル等が代表的な例になります。これらのドキュメントの作成工数は、発注者にとっても妥当性を判断しやすい部分です。
まず、各ドキュメントの「量」について、「50 ページ程度」、「300 ページ程度」など概算で構わないので何ページ程度の成果物を作成予定かを確認します。
次にドキュメントの「質」として、主要な構成を確認します。例えば、システム操作説明を主体としたマニュアルであれば、システムの機能構成単位で画面イメージを貼付ける構成となり作成工数も比較的少なくなるでしょう。一方で、業務面での解説を中心としたマニュア
ルであれば、業務上で発生する状況に合わせて情報システムの使い方を説明する形となり、作成工数も比較的多くなると考えられます。
このように、成果物であるドキュメントの量と質を確認すると、ドキュメントを作成する作業
規模や難易度がわかるため、作成工数の妥当性を判断しやすくなります。

-

28 -

（第３編第３章 予算及び執行）

D. 開発生産性の精査システム開発の実作業の中では、再利用できる「部品」を様々に準備した上で、それらを組み合わせて実装を行うことが中心となります。そして、このように再利用可能な部品によって体系的に構築された情報システムであれば、機能の追加や変更に際して特定の「部品」等への限定的な追加作業を行うことで十分な対応を行うことができるはずです。
前述の「Ａ．安易な掛け算の精査」とも重なりますが、画面や帳票の新規追加を行う場合
においても、実作業としては限定的な作業で済む場合が多いはずです。
まずは、画面、帳票等の各機能を追加する際に、具体的にどのような作業が必要になるかを把握してみましょう。画面については、基本的な「ひな形」が複数種類存在していて、その一部を使って新規画面を構成することが多くなります。特に、既存機能と類似の画面を作成する場合は、その類似画面をベースとした上で流用開発を行うことが多いです。つまり、既存の「ひな形」や「類似画面」との相似度が高いほど、追加的な工数は少なく済むはずです。
帳票については、帳票作成に特化したミドルウェア（ツール）を利用することもあります。
このようなミドルウェアを導入することで、帳票のレイアウト設計や出力制御を簡易な作業で実施できるようになります。このような帳票作成ミドルウェアを導入している場合は、そのツールを前提とした作業工数になっているかを確認することが有効です。
開発生産性を精査するためには、テストにおいて不要なテスト項目が含まれていないか
確認することも有効です。例えば、機能改修を行う場合に、改修を行わない部分に対する影響がないかリグレッションテストを実施しますが、影響範囲の絞り込みが不十分であるためにテスト範囲が広すぎ、 生産性が低下している場合があります。
機能改修の特性を踏まえて、テスト自動化の検討、テスト項目の妥当性の精査、機能改修による影響範囲の特定などを適切に実施することで、効率的にテストを実施し、過剰な工数を削減することができます。
また、プロジェクトを通して見積工数の計画と実績を蓄積しておくことも重要です。このよ
うな蓄積があると、見積りを精査する際に過去の類似見積りとの比較を行うことができます。

参考：見積り精査を行うにあたっての参考資料
これまで本書で紹介してきたような観点で見積りを精査することが重要ですが、様々な団体がまとめている見積標準や調査報告等を参照することで、見積り手順や比較対象となる指標等を知ることができます。
本項では、見積り精査の参考となる資料の例を三つ紹介します。ただし、見積り内
容はプロジェクトの前提条件や性質により変化するため、参考資料の指標等と比較して差異があったとしても、必ずしも不適切な見積りとは限りません。これらの資料に記載された指標等との差異について見積り事業者と意見交換することで、事業者による見積りの考え方と発注者の認識との違いを明らかにし、要件定義等に向けて軌
道修正すべきポイントを把握することが重要です。
また、プロジェクトの中で見積り精査の精度をさらに上げるためには、プロジェクト内で発生するそれぞれの見積りについて、開発規模や生産性のデータを蓄積し、発注者側で見積りの妥当性を判断できるようにすることも重要です。
さらに、蓄積した生産性データを分析することで、例えば、ドキュメント作成に過剰な工数がかかっているなど、作業の効率性を振り返るきっかけにもできます。
「情報システムの調達に係る見積標準」（一般財団法人 経済調査会 ）本資料は、情報システムの整備・運用等に係る業務の発注者を対象として、見積りに関する基本的な考え方を示しています。見積りの精査や予算要求額の積算等で

-

29 -

参考 3-4
見積り精査を行うにあたっての参
考資料

注記「情報システムの調達に係る見積標準」
https://www.zaikeicho.or.jp/software_research/（第３編第３章 予算及び執行）の利用が想定されています。
見積りの精査に関連する記載としては、望ましい見積書の構成や、確認すべき根
拠資料が紹介されているなど、見積りの依頼から精査に至るまでの業務を体系的に知ることができます。また、「ソフトウェア開発データリポジトリの分析」に掲載されている開発工程別工数比率や技術者別参画比率を利用した見積りの手順も紹介されています。

出典：https://www.zai-keicho.or.jp/software_research/「ソフトウェア開発分析データ集」（独立行政法人情報処理推進機構）
本資料は、ソフトウェア開発現場でプロジェクトのデータを精査・分析する方などを想定読者として作成されており、掲載されたデータをベンチマークとして活用することができます。
見積り精査への活用という観点では、例えば、開発生産性の一種であるＳＬＯＣ（コード行数）生産性について、調査に基づく統計値が記載されており、事業者から取得した見積りのＳＬＯＣ生産性と比較することで、見積りの妥当性を定量的に確認することが可能です。

-

30 -

注記
「ソフトウェア開発分析データ集」
https://www.ipa.go.jp/ikc/reports/20200930.html
注記
ＳＬＯＣ生産性とは、ＳＬＯＣの規模を設計・開発にかかる工数で除算したもので、一人 1 時間または一人 1 月あたりの作業に対し設計・開発できる規模（ＳＬＯＣ）のこと（第３編第３章 予算及び執行）

出典： https://www.ipa.go.jp/ikc/reports/20200930.html「ソフトウェアメトリックス調査（システム開発・保守調査、IT 運用コスト調査）」（一般社団法人 日本情報システム・ユーザー協会）
本資料は、開発・保守・運用プロジェクトの実態に関するデータについて、調査報告書として取りまとめられたものです。掲載されている指標は、情報システムの開発
期間や工数の妥当性評価等に活用することができます。
見積り精査への活用という観点では、例えば、各工程の工数の割合について統計値が記載されており、事業者から取得した見積りの各工程の工数割合と比較することで、割合の妥当性を確認することができます。

注記「ソフトウェアメトリックス調査」
https://juas.or.jp/library/researc
h_rpt/swm/

出典：https://juas.or.jp/library/research_rpt/swm/

２ ハードウェア等の見積り精査【標準ガイドライン関連箇所：第３編第３章第４節】

ハードウェア、ソフトウェアの借料や保守経費は、経費全体の中で大きな比率を占めます。
まずは、大前提として製品単位での価格内訳を入手してください。予算要求段階では「一式」等の形で大括りの見積が事業者から提示されることもありますが、一式の状態ではそれ以上に金額の精査を行うことができません。新規に整備する情報システムであっても想定する製品に基づいて金額を積算しているはずなので内容を確かめるべきですし、既存情報システ
ムに対する改修や更改等の案件であればなおさら詳細な積算内訳を求めることが重要です。

参考：ハードウェア・ソフトウェア等の見積りの記載例
製品単位で、数量、借料、保守料の内訳が示される形が一般的です。
製品については、「ＷＥＢサーバ 一式」といったグループ単位で金額が示されることもありますが、できるだけＷＥＢサーバを構成する本体部分やオプション部分も含めて詳細内訳を入手するようにしてください。

-

31 -

参考 3-5
ハードウェア・ソフトウェアの見積りの記載例

（第３編第３章 予算及び執行）＜ハードウェアの見積り記載例（サンプル）＞
種別WEBサーバ #1

WEBサーバ #2

製品名称
Sugoi Server SG2017
CPU for Sugoi Server (3.0GHz/4コア/10MB）
メモリ32GB （32GB RDIMM）
LAN拡張ボード（10Gbps）
ファイバーチャネル拡張ボード（8Gbps）
内蔵ＤＶＤ－ＲＯＭユニット
電源ユニット（800W）
Open source OS for Server 基本サポート
Sugoi Server SG2017
CPU for Sugoi Server (3.0GHz/4コア/10MB）
メモリ32GB （32GB RDIMM）
LAN拡張ボード（10Gbps）
ファイバーチャネル拡張ボード（8Gbps）
内蔵ＤＶＤ－ＲＯＭユニット
電源ユニット（800W）
Open source OS for Server 基本サポート

製品番号SG2017STD
SGCPU30X4
SGMMR32
SGLAN10G
SGFC8G
SGDVD
SGPWR
SGOSSPRT
SG2017STD
SGCPU30X4
SGMMR32
SGLAN10G
SGFC8G
SGDVD
SGPWR
SGOSSPRT

数量 借料（月単価）
借料（月合価） 保守料（月単価） 保守料（月合価）
1
6,500
6,500
1,870
1,870
2
7,800
15,600
2,100
4,200
8
10,80086,4003,400
27,200
1
1,840
1,840
530
530
1
3,350
3,350
830
830
1
450
450
200
200
2
3,230
6,460
1,800
3,600
1
3,000
3,000
－
－
1
6,500
6,500
1,870
1,870
2
7,800
15,600
2,100
4,200
8
10,80086,4003,400
27,200
1
1,840
1,840
530
530
1
3,350
3,350
830
830
1
450
450
200
200
2
3,230
6,460
1,800
3,600
1
3,000
3,000
－
－

＜ソフトウェアの見積り記載例（サンプル）＞
種別

DBサーバ #1

DBサーバ #2

製品名称
Rippana Database Standard License (2core)
Rippana Database クラスタリング・オプション (2core)
Rippana Database バックアップ・オプション (2core)
Rippana Database モニタリング・オプション (2core)
Rippana Database メンテナンス・オプション (2core)
Rippana Database 管理機能オプション (2core)
Operation Management Agent （運用管理）[OSS]
Storage Management Middleware（ストレージ管理） (1Server)
Cyber Attack Protection （セキュリティ対策） (1Server)
Open source OS for Server [OSS]
Rippana Database Standard License (2core)
Rippana Database クラスタリング・オプション (2core)
Rippana Database バックアップ・オプション (2core)
Rippana Database モニタリング・オプション (2core)
Rippana Database メンテナンス・オプション (2core)
Rippana Database 管理機能オプション (2core)
Operation Management Agent （運用管理）[OSS]

製品番号
RDBSTD
RDBCLSO
RDBBKUORDBMNTORDBMTNORDBMNGOOMAGNT
SMM1SVRCAP1SVRSGOSS1SVR
RDBSTD
RDBCLSO
RDBBKUORDBMNTORDBMTNORDBMNGOOMAGNT

数量 借料（月単価） 借料（月合価） 保守料（月単価） 保守料（月合価）
6140,400
842,400
108,000
648,000
6
98,000588,000
67,000402,000
6
14000
84,0008950
53,700
6
8500
51,0006850
41,1006
7100
42,6003770
22,6206
11280
67,6808000
48,0001
1
18,00018,00036,00036,000
1
2,100
2,100
1,000
1,000
1
6
140,400
842,400
108,000
648,000
6
98,000588,000
67,000402,000
6
14000
84,0008950
53,700
6
8500
51,0006850
41,1006
7100
42,6003770
22,6206
11280
67,6808000
48,0001-※ 上述の見積り記載例は、特定の事業者を想定したものではなく、借料等の金額も架空のものです。

A. 製品単価を精査する
まず、主要な製品について定価や実勢価格との差異を確認してみましょう。
ハードウェアについては、オープン価格として定価（希望小売価格）を明示的にしていな
い製品もありますが、多くのハードウェアについては Web サイト等で定価を確認することができます。また、製品名称や製品番号等をキーワードにして Web サイトを検索すると、各種販売代理店等による実際の販売価格を把握することができます。代理店によって販売条
件（納期、納品場所条件、各種サポート条件、支払期限、支払方法、キャンセルポリシー等）
が異なるため販売価格の最安値と単純に比較することは合理的ではありませんが、調査した販売価格の水準（実勢価格）と取得した見積価格とのかい離が大きい場合は、その理由
を営業担当者に確認すると良いでしょう。
ソフトウェアについても、まずは同様に定価や実勢価格との比較を行ってみましょう。ライ
センス数の精査については後述します。
また、同一製品で異なる単価設定になっていないか、過去に受領した見積りと比べて同一（類似）製品の価格が高くなっていないか等、製品単価を比較してみましょう。

B. 高額な製品を中心に、必要性を精査し他製品と比較する
次に、見積り内容を分析して、どのような製品が高額となっているかをつかみましょう。１
つの製品が突出して高額な場合もありますし、低額な製品（部品）が多数計上された合計で高額となっている場合もあります。
そして、高額な製品についてはその必要性を確認しましょう。例えば、ストレージ装置が高額となっているならば、容量（記憶できるサイズが何ＴＢか）、性能（読み書きの速度等）、機能（複製、圧縮、冗長性確保等のための諸機能）等について内容を確認し、他製品との比較検討を行い、当該製品が必要以上のスペックになっていないか確認します。
全ての製品について必要性の確認を行うのは大変な作業ですが、高額な製品から順番に突合せを行うことで、効率的に価格構成上の主要部分を精査することができます。

-

32 -

（第３編第３章 予算及び執行）

C. ソフトウェアライセンスを精査する
ソフトウェアのライセンスの考え方は各社各様であり、課金単位も様々です。サーバに導入するソフトウェアについては、サーバ台数又はサーバに搭載されているＣＰＵ数を単位とするものが比較的多い状況です。他方、利用するＰＣの台数、利用するユーザの数、ユー
ザの最大同時接続数、利用するデータ量など、利用形態に対して課金する形態もあります。
いずれのライセンス形態であっても、サーバ台数、ＣＰＵ数、ＰＣ台数、利用ユーザ数等の実際の使用状況（あるいは使用予定状況）に比べて過剰なライセンスが積算されていな
いかを確認しましょう。
また、特にＣＰＵ数を単位とするライセンスについては、現行情報システムの瞬間的なピークだけを捉えて必要数を積算していないか、実際のＣＰＵ使用率の推移を確認してみてください。夜間バッチ、バックアップ等の目的で業務時間外に短時間だけＣＰＵ使用率が高くなっていても、通常の業務時間のＣＰＵ使用率が低ければ、基本的にそのピークに合わせる必要はありません。

D. 保守料を精査する
保守料は、保守サービスの前提によって価格が変わります。保守サービスの対応日（週末の有無当）、対応時間帯、故障発生時の駆け付け時間、サービスの各種オプションの有無等が価格に影響する代表的な要素です。
一般的な機器については、保守サービスの条件に応じた年間保守料が設定されています。まずは、Web サイト等でこれらの保守料を調べて、見積内容と比較してみましょう。
また、全ての機器に、良い条件の保守サービスを一律にかけるべきであるか検討してみましょう。全ての機器を定期保守（故障発生頻度にかかわらず定額で対応を行う方式）でオ
ンサイト対応（故障時に現地で修理・交換を行うサービス）でなくても、スポット保守（故障発生都度に修理対応料金を払う方式）やセンドバック対応（故障時に故障製品を指定先に送付し、代替品が交換で送付されるサービス）で十分な場合もあります。
いずれにしても、保守金額は条件によって大きく変わり得るものなので、前提条件やサービス内容を確認して、必要十分な水準になるように検討しましょう。

３ 複数事業者の見積りの比較【標準ガイドライン関連箇所：第３編第３章第４節】

複数事業者から見積りを取得した場合は、その内容について比較を行います。
比較に際しては、合計金額だけで比較するのではなく、主要な経費項目の単位で比較を行うことで事業者の得意分野、不得意分野等を把握することができます。

参考：三点見積りによる予算要求額の算出
三点見積りとは、例えば５つの事業者から見積りを取得した際に、最高額と最低額を除外した３者で平均して算出した額を指します。見積り経費項目ごとに三点見積りを行い、総合計したものを予算要求額とします。
三点見積りは、金額だけではなく、工数や期間の算出にも適用できます。

-

33 -

参考 3-6
三点見積りによる予算要求額の算出

（第３編第３章 予算及び執行）事例：クラウドサービスの見積りの精査

事例 3-5
クラウドサービスの見積りの精査

標準ガイドラインでは、情報システム関係予算の要求に当たって、原則としてクラウドサービスの利用を前提とした見積りも取得することを定めています。
これを受け、各府省でクラウドサービスの導入事例が増えていますが、見積りの取得の過程では、従来のオンプレミスを継続した場合とクラウドサービスを利用した場合の比較が適切に行われていない例も散見されます。以下に、実際にあった不適切な比較の事例をご紹介します。
・

割高なクラウドサービスが選定されているクラウドサービスは国内外含め様々なものが提供されています。その中でも利用料が割高なクラウドサービスの利用を前提としている場合には、見積額全体も高額になるケースが多くなっています。見積り事業者自身やそのグループ企業でクラウドサービスを提供している場合は、他のサービスより割高であっても当該クラウドサービスの利用を想定した見積りがなされることが多くなります。このため、割安なクラウドサー
ビスも比較対象として見積もるよう求めたり、現行事業者だけでなくクラウドサービスの導入実績が多い事業者を含めた複数事業者から見積りを取得したりすることが重要です。
・

適切ではない価格体系を前提としている
使った分だけ支払う従量課金の価格体系によって無駄なコストを抑えられることがクラウドサービスのメリットの一つですが、一定の利用量を超えると複数年予約型割引※を採用したほうが安くなる場合があります。
ある府省では、24 時間週 7 日利用されることが想定されているにも関わらず複数
年予約型割引を採用していない高額な見積りが事業者から提示されていました。（※
1 年以上の長期利用予約することで割引が受けられる仕組み。）

一方で、24 時間週 7 日情報システムを稼働する必要がない業務もあります。オン
プレミスの場合は、サーバの稼働時間が運用等経費に影響しないことを背景として単純にサーバを 24 時間週 7 日稼働しているケースが多いです。
クラウド環境を従量課金の価格体系で利用する場合は、サービス利用料はサーバの稼働時間に影響を受けます。そのため、一定の時間クラウド環境を停止してサーバの稼働時間を抑えることで、サービス利用料を低減することができます。したがって、見積り時にはオンプレミスを踏襲した 24 時間週 7 日の稼働を前提としがちですが、夜間等に稼働が必要でないサーバについては、業務に支障がない業務終了後から翌営業日の早朝までを停止する前提で見積りを依頼することも検討しましょう。
・

不確定要素に対して過剰な費用が上乗せされている業務内容に不確定な要素がある場合、事業者がリスクを見込んで見積りが高額となる可能性があります。ただし、それが適切な範囲なのかは確認が必要です。
ある府省では、クラウドサービスへ移行する場合の環境構築費用がオンプレミスを継続する場合の 1.5 倍の金額で見積もられました。事業者に原因を確認したところ、クラウドサービスと省内 WAN との接続において、作業や費用の見通しが十分ではな
いままの状態で、オンプレミスと比較して大きな金額を見積もったとの回答がなされました。そのため、省内 WAN との接続に必要な作業について、精査を求めました。
・

現行システムの構成のまま移行している
オンプレミスで構築した情報システムをクラウドサービスへ移行する場合、現行システムの基盤部分を同じ構成（オンプレミス）のままで更改するのと比較して整備経費が高額になる場合があります。
ある府省ではオンプレミスとクラウドサービスの比較といいながら、オンプレミスの構成をクラウド環境にそのまま持ち込み（現システムへの影響を最小限にするという理

-

34 -

注記
ベアメタルとは、ユーザから申し込みがあると、あらかじめ事業者のデータセンタに用意された物理
サーバを割り当てて利用可能とするサービスのこと。
一般的なクラウドサービスに対応
していないソフトウェアも利用でき
る、リソースを専有できて他の利用者の影響を受けないなどのメリットがある。
一方で、利用に当たって初期コストがかかる場合がある、サーバを仮想化しておらず共用できないた
め、リソースを柔軟に変動させることができないといったデメリットがある。

（第３編第３章 予算及び執行）

由でベアメタルのクラウドサービスを採用）、オンプレミスの構築費用に加えてクラウド
利用量を上乗せする形で比較し、クラウドサービスの長所を全く活かしていない事例がありました。
クラウドサービスの長所を活かせるように改修を加えてからクラウドサービスに移行
すると、整備経費は高額となりますが、運用費用は下がり、長期的に見るとコスト削減につながる可能性があります。短期的に発生する経費だけでなく、情報システムのラ
イフサイクル全体を考慮した見積り比較を行うことが必要です。
・

各種費用を二重計上しているクラウドサービスによっては、特定のソフトウェアのライセンス料をクラウドサービス
利用料に含んだオプションがあります。
ある府省で事業者に見積りを依頼すると、ソフトウェアライセンス料込みのクラウドサービス利用料を計上した上で、さらにそのソフトウェアのライセンス料・保守料を追加で見積もっており、二重計上になっていることがありました。このような不要な費用が見積もられていないか、見積りを精査することが必要です。
・

災害対策環境が本番環境と同じ構成となっている
社会的な影響が大きなシステムなど、特に高い可用性が求められるシステムでは、大規模災害によって本番環境が復旧不可能となった場合に備えて、代替環境である災害対策環境を設置することがあります。
ある府省で事業者に見積りを依頼すると、本番環境と同じ構成で災害対策環境を常時稼働させる前提で見積もられており、見積額が高くなる原因となっていました。
災害対策環境を本番環境と同一の構成とするのではなく、本番環境よりも冗長性を省いた限定的な構成としたり、常時稼働ではなく、ウォームスタンバイやコールドスタ
ンバイとしたりして、復旧する目標に応じた適切な水準とすることで費用を抑えることができます。
・

過剰なスペックで見積もられているリソースの性能や容量が大きければそれだけ高額になるのは、クラウドサービスでも同様です。クラウドサービスでは、ディスク容量だけでなく性能（IOPS）も選ぶことができます。性能の高い製品ほど高額になりますが、ある府省では、数百 TB ものディ
スクが、すべて当該クラウドサービスの最高スペックで積算されており、見積もり額の大部分を占めていました。
リソースの性能や容量は、要件にあったものが選定されているか精査する必要があります。
クラウドサービスは正しく利用することで、大幅なコスト削減を実現できる可能性がありますが、本事例のように、事業者にクラウドサービスを前提とした見積りを依頼しても、必ずしもシステムの特性を踏まえて安い金額で見積もってもらえるとは限りません。オンプレミスを継続するケースなどと比較して割高になっている場合には、本事例のように、見積りが適切に行われているか、内訳を精査して妥当性を確認する必要があります。
しかし、このような精査には専門的な知識が必要となることも多いため、事業者が出した見積りに疑問がある場合には、PMO に相談することも検討しましょう。

参考：クラウドサービス特有の料金体系
適切に利用することで情報システムのコストを削減できる可能性があるクラウドサービスですが、オンプレミスとは料金体系が異なるため、思わぬところでコストが増大しないように注意しましょう。
例えば、クラウドサービスによっては、クラウド環境から外部へ送信するデータの量

-

35 -

注記
ウォームスタンバイ、コールドスタ
ンバイとは、本番機の障害発生時に予備機に切り替えることで信頼性を向上させる手法であり、ほかにホットスタンバイがある。
ホットスタンバイ、ウォームスタン
バイ、コールドスタンバイの順に切替えが早い。
なお、災害対策環境をウォームス
タンバイやコールドスタンバイとす
ると、大規模災害発生時には同環境が設置された拠点に利用が集中してリソースを確保できない
おそれがある。そのため、システ
ムの特性や目標復旧水準を踏まえた検討が必要となる。

注記
IOPS とは、１秒間あたりに入出力できる回数のことで、性能指標の一つ。
IOPS は Input/Output Per Secondの略。

参考 3-7
クラウドサービス特有の料金体系

（第３編第３章 予算及び執行）に応じて課金される場合があります。動画配信サービスのように極端にデータのダウンロードが多いシステムにおいて、このような点を考慮せずにクラウドサービスを採用してしまうと、想定外に大きなコストが発生するおそれがあります。本番環境と災害対策環境など、異なる拠点間でデータ同期を行う場合にこの課金が適用される点にも注意が必要です。
また、クラウドサービスでは、データに対するアクセスの容易さや価格の異なる
様々なストレージから必要なものを選択することができます。オンプレミスでは磁気テープに保存していたバックアップデータも、バックアップやアーカイブでの利用を想定した安価なストレージに保存することができ、管理も容易になります。このようなストレージの種類を考慮せず、古いバックアップデータやログデータなどの即座にアクセスする必要のないデータまで頻繁なアクセスを想定したストレージに保存してしまうと、同じデータ容量でも高額な利用料となるおそれがあります。
そのほかに、バースト機能の使用にも注意が必要です。バースト機能を使用すると、一時的に、あらかじめ定められたリソースの使用率（ベースライン）を超えてリソースを使用することができます。ただし、バースト機能の使用には限り（クレジット）があり、クレジットがなくなると、リソースの利用率がベースライン以下まで低下するか、追加で使用するために追加料金の支払いが必要となります。バースト機能を使用する
前提で性能試験をして、本番運用時にはクレジットを消費してしまって思った性能が出ないなどといったおそれがあります。
単純にクラウドサービスに移行すれば自動的にコストが減少すると考えず、情報シ
ステムの特性と、クラウドサービスの料金体系を踏まえて検討することが必要です。

-

36 -

（第３編第３章 予算及び執行）

Step.

5 予算要求に必要な資料の準備

予算要求には様々な資料を作成しなければならず、作業負荷が高いと感じる方も多いかもしれません。確かに、複数の資料を作成することが必要になりますが、これまでの検討過程の資料をうまく取りまとめることが主体であり、予算要求のためだけに新たな検討を行う部分は少ないと言えます。
一方で、予算要求の過程では短期間で多くの関係者に対してプロジェクトの目標や予算の必要性等を理解してもらう必要があるため、要点をわかりやすく表現することが求められます。また、わかりやすい資料を作成することで、事業者からも有意義な提案を受けて的確な見積りを取得することが可能になります。
どのように予算要求に必要な資料をまとめればよいか、そのポイントと注意点を解説します。

１ 全体像と要点の明確化【標準ガイドライン関連箇所：第３編第３章第２節】

まず、資料を作り出す前に一呼吸を置いて、頭を整理してみましょう。
説明資料を作成する人は、プロジェクトの背景や状況を詳しく知っているため、そのような大前提の説明を飛ばしてしまい、プロジェクトが直面している課題だけにフォーカスを当てがちです。
他方、説明を受ける側は、そのプロジェクトに対する知識が全くない場合があります。そのため、「素人でも理解できるように」このプロジェクトを理解してもらえるようにするにはどうすれば良いかを考えて作成することが必要です。
プロジェクトの内容を第三者に正確に伝えるためのコツは、「全体」から「詳細」につながるような構成で説明することです。まず、サービスや業務の全体を俯瞰した視点を示し、目指している目標を明らかにした上で、その中で今回のプロジェクトがどの範囲なのか、今回の予算要求対象がどの範囲なのかと順を追ってクローズアップしていく構成にすることで、資料の読み手に対して正確にプロジェクトの姿と予算の必要性を伝えることができます。

-

37 -

（第３編第３章 予算及び執行）

図 3-4
全体を俯瞰した視点のイメージ

資料の読み手は、予算要求内容を確認する担当者（ＰＭＯ、デジタル庁、財務省主計局）
だけではありません。ＰＪＭＯ内部の職員も、利用者や関係者等のステークホルダーも、見積り依頼先の事業者も重要な読み手です。読み手によって、関心のポイントが異なる部分もありますが、どの読み手も共通して知りたいのがサービスや業務の全体像です。プロジェクトの前提を間違えて捉えると、的確な判断ができないからです。
また、これらの資料は、ＰＪＭＯ内部やステークホルダーに対しても、プロジェクトの目標や全体像を共有するための良いツールとなります。
プロジェクトとして、これらの全体像がわかる資料をわかりやすく整理するとともに、プロジェ
クトの進捗や変化に応じて資料内容をバージョンアップする活動を日常的に行うことで、予算要求に限らず、様々な状況でプロジェクトの状況説明を円滑かつ効率的に行えるようになります。

２ 予算要求資料の作成上の注意点【標準ガイドライン関連箇所：第３編第３章第３節】

予算要求で作成する資料の詳細については、事務連絡等をご参照いただくこととして、
ここでは、主な資料について、作成上注意した方が良いポイントを解説します。

-

38 -

（第３編第３章 予算及び執行）

A. 「予算要求の概要」の作成ポイント
予算要求の概要は、プロジェクト計画書の内容を前提に、予算要求を行う範囲についての目標、内容、スケジュール、体制等を要約した資料です。
この資料は、予算要求の過程の中で、様々な関係者が真っ先に確認する資料となります。前述したように全体像と要点を明確化して、簡潔に理解できるように工夫しましょう。

作成時に気をつける点
全体像と目標の明確化
サービス・業務観点からの全体像と現時点の問題発生状況を明らかにした上で、プロジェクトの目的・目標を示し、サービス・業務の改善後の実現像を示す。
具体的な改善内容の明確化
改善を実現するために必要となる事項として、サービス・業務の改善内容、制度や業務ルールの改善内容、情報システムの改善内容を明確にする。
（情報システムの改善だけの目線にならないように留意する）
主要なスケジュールの明確化
全体スケジュールを作成し、新しいサービス・業務の開始時期を明示するともに、情報システムの主要な整備スケジュール（要件定義、調達、設計、開発、テスト等）、関連する制度変更のスケジュール、サービス・業務の変更のための手続等を明確にする。
体制とステークホルダーの明確化
プロジェクトの体制や、主要なステークホルダーへの影響有無を記述する。また、難易度の高い調整が発生する場合に、今後の調整方法（各ステークホル
ダーへの調査やヒアリングを通して詳細な分析を行う、ステークホルダーの責任者を集めた会議体を設置する等）を明らかにする。
前提条件や制約の明確化
プロジェクトを推進する上での前提条件や制約がある場合は、その主要なものについて記述する。また、前提条件や方針等に不明確な箇所がある場合は、この資料にまとめて記述する（業務の説明資料、情報システムの説明資料等の個々の資料にも記載した上で、この資料にまとめる）。
費用対効果の考え方の明確化
情報システムの整備を行う予算要求をする際には、情報システムの整備により得られる効果を明確にする。この「効果」については、恩恵を受ける対象ごとに適切に設定されている必要がある。特に行政サービスの場合は効果の対象が国民であること、また、このような効果はいつまでにどのように把握するのか明確になっていることが重要である。さらに、累積効果がプロジェクト期間全体の投資額（予算要求する経費の総額）を上回るまでの回収期間について明確にする。
（累積効果については、第 4 章サービス・業務企画 Step.5-2-G.「精緻に効果を積算し、主要な効果を実感可能なものとする」において解説する）

-

39 -

（第３編第３章 予算及び執行）

B. 「サービス・業務の説明資料」の作成ポイント
プロジェクトが前提としているサービス・業務の概要を説明する資料です。
サービス・業務の現状分析や検討方法の詳細については、「第４章 サービス・業務企画」
で詳述します。サービス・業務企画での詳細な検討成果を、予算査定に係る様々な関係者にわかりやすく伝えるため、業務自体の概要、業務全体を示す業務フロー（概略）を１枚から数枚程度で簡潔に説明したものが、ここで作成する資料となります。

図 3-5
業務概要図

作成時に気をつける点
業務（情報のやりとり）が発生する主体を明確化し、矢印等を使ってやりとりする内容を明確にする。
管理指標と現在の達成状況について、定量的に記述する
顕在化している課題を記述する
異なる主体であっても業務や取り扱う情報等に共通点がある場合には、一括して記述するなど、図が難解にならないようにする

-

40 -

（第３編第３章 予算及び執行）

Step.

6 概算要求に向けた調整

概算要求に向け、府省内外からの様々なチェックを通過して行かなくてはなりません。これらに対応する労力は掛かりますが、事前に作業スケジュールを把握し、必要とされる資料を準備し、発生するやり取りとその目的や効果を理解することで、軽減することができます。

A. ＰＭＯによる調整
ＰＭＯはデジタル庁からの連絡・指示に基づき概算要求額の調整を行うことになります。
府省によって確認対象や実施スケジュール等は異なりますが、ＰＪＭＯが作成した予算
要求内容をデジタル庁（または、一括計上対象外システムにあっては各府省会計担当部門）に提出する前に、基本的にはＰＭＯによる事前ヒアリングが行われます。事前ヒアリング
では、ＰＭＯの職員が専門的見地から様々な内容の確認・調整を行います。例えば、以下のような項目です。
政府方針や府省方針等との整合性
利用者視点の効果、サービス・業務改革（ＢＰＲ）等の検討十分性
省内、省外情報システムとの機能重複回避、共用・統合の推進
見積積算方法の妥当性、経費水準の妥当性
ＣＰＵ使用率等の現状分析に基づいたサイジングの適切性の確認
ライフサイクルコストとして将来発生するコストの確認
セキュリティポリシーとの整合性、サポート期限の対応網羅性の確認
バックアップ機能、ディザスタリカバリ（ＤＲ）等、信頼性確保状況の確認
投資計画の妥当性の確認
概算要求金額の調整

参考：ライフサイクルコストを考慮した予算要求
オンプレミスで構築した情報システムからクラウドサービスへ移行したり、特定ベンダの技術に依存した OS・ミドルウェア等からオープンな製品に乗り換えたりすると、現
行システムの基盤部分を同じ構成のままで更改するのに対して初期コストが高額になりがちです。
しかし、このような移行や乗り換えを適切に行えば、初期コストは高額になっても、改修コストや運用保守コストが削減でき、情報システムのライフサイクルコスト全体で見るとコストを低く抑えることができる場合があります。
例えば、クラウドサービスでは、仮想化レイヤまでのパッチ適用、ハードウェアの定期点検、計画停電等が不要となります。加えて、マネージドサービス（ストレージ、データベース、セキュリティ対策、運用管理等の仕組みを、従量課金のサービスとして利用できるもの）の活用で運用・保守作業の対象を減らし、自動化機能で運用・保守

-

41 -

参考 3-8
ライフサイクルコストを考慮した予算要求

（第３編第３章 予算及び執行）作業を自動化して運用・保守コストを削減できます。また、オンプレミスのようにハード
ウェアのリース期間や耐用年数の制約がないため、更改のサイクルを 5 年より長くして、更改にかかる費用を抑えることができます。
特に、当該情報システムが取り扱う制度が恒久的に続くものである場合、ライフサ
イクル期間は長くなり、初期に大きなコストを要したとしても、運用期間中のコストの差
が積み上がって、長期的には回収できる可能性が高まります。
このように、クラウドサービスへの移行に際しては、情報システムの特性や現行シス
テムの契約内容に鑑み、業務改革やリース期間満了のタイミングで移行するなど、ライフサイクルコストの観点からしっかり分析することが必要です。
初期コストが高額となっても、ライフサイクルコストでは安くなるイメージを以下に示します。このイメージでは、オンプレミスの現行システムをクラウドサービスへ移行する
際に、現行システムをできるだけ改修しないように移行（リホスト）すると、抜本的な刷
新、再構築によりクラウド環境に最適化して移行（リビルド）する場合に比べ、初期コ
ストを安く抑えられています。しかし、リビルドした方が、前述のような運用・保守コスト削減が可能となるため、ライフサイクルコストは安く抑えられています。

注記
マイクロサービスとは、小さな複数のサービスを連携させてアプリ
ケーション全体を構成する開発手法のこと。各サービスは独立性が高いため、改修時の影響範囲が局所化される。

B. デジタル庁による調整
デジタル庁は、一括計上対象の情報システム経費予算全体額について、後年度負担額を含め、各府省の優先順位やレビュー結果、政府全体の方針等を踏まえ、概算要求基準に基づき調整し、概算要求額を決定します。
デジタル庁が特に重要と考えている情報システムについては、デジタル庁が直接ヒアリングをし、その内容を精査することになります。
外部からの視点で確認し、より専門的・客観的に評価することが目的です。事前ヒアリン
グで使用した資料等を活用して、十分な説明ができるよう準備してください。

-

42 -

（第３編第３章 予算及び執行）

Step.

7 予算執行について

実際にどのように予算執行を行うのか、特に一括計上対象システムについては、デジタル庁から予算の移替えによる予算配分を受ける必要があります。
執行計画作成から移替えまでの作業フローのイメージは以下のとおりです。

図 3-6
執行計画作成から移替えまでの作業フローのイメージ

ここでは、作業とポイントについて解説します。

１ 執行計画案の作成【標準ガイドライン関連箇所：第３編第３章第９節】

予算が決定された後、ＰＪＭＯは「いつの時期」に「何の調達案件」を「いくら使う」のかについて、記載した１年間の執行計画案を作成します。
調達案件毎に執行計画案を作成することは、年度開始以降に予算管理をしていく上で、非常に重要です。調達案件毎に執行計画に記載されたとおりに執行できているか、執行計
画の金額より少ないのか、多いのか、という状況を執行計画と執行実績を突き合わせることで、

-

43 -

（第３編第３章 予算及び執行）

今の予算執行状況を把握することが出来るようになります。
予算執行状況の把握は、各ＰＪＭＯにおいて重要な意味を持つだけではなく、ＰＭＯにおいても重要な意味を持ちます。
プロジェクトによっては、調達後に外部的な要因で変更せざるを得ないことや、セキュリティ対策など、予算要求・編成時に想定していたことと異なる事情が生じ、予算内では収まらない状況が生じることがあります。
その場合、プロジェクト毎の執行状況をＰＭＯが把握し、プロジェクト間の執行計画と執行状況の差異を調整することが可能となります。（ただし、金額の調整にはデジタル庁の同意が必要です。）
また、一括計上対象システムにあっては、その調整を政府全体で行う事が可能です。
このように、執行計画は予算の執行管理をする上での基礎となる資料となります。

２ 執行計画案の調整【標準ガイドライン関連箇所：第３編第３章第８節】

ＰＪＭＯが作成した執行計画案はＰＭＯにて集約します。
ＰＭＯは提出された執行計画案について、予算額を超過していないか、予算決定時から、内容が変わっていないかをチェックします。
また、すでに調達済・契約済のものがあれば、その金額と執行計画案に記載されている金額と相違がないかについてもチェックが必要です。
以上のチェックを経て、問題がないものであれば良いですが、プロジェクトによっては、予算決定以後に生じた事情により、執行計画の内容を変更せざるを得ないものが出てくることがあります。
その場合、ＰＭＯはＰＪＭＯから内容を聴取し、必要に応じて資料を徴求するなどして、変更内容が妥当か否か確認し、変更の是非を判断します。また、変更により予算を超過せざるを得ない場合には、プロジェクト間での調整を行うことになります。
ＰＭＯは、このように確認・調整をした執行計画案をとりまとめ、一括計上対象システムについてデジタル庁に提出をします。
デジタル庁はＰＭＯから提出された執行計画案をレビュー等により精査し、執行計画を決定し、当該年度の予算配分を行います。

３ 予算の移替え・予算執行管理
A. 予算の移替え
デジタル庁は決定した執行計画の金額を基に、各システムの案件毎の調達時期に応じて、各府省に対し予算の移替えを行います。
予算の移替えについては、財務大臣協議が必要となっておりますので、移替え予定の金額の内容について、財務省主計局への説明が必要です。
年度途中に事情変更により追加の移替えが必要となる場合には、ＰＭＯはデジタル庁に執行計画の変更を申請し、デジタル庁において執行計画の変更を行った上で、追加された予算の移替えを受けることになります。
また、落札差額等により移替えられた予算に執行残が出た場合には、デジタル庁において執行計画を変更し、各府省からデジタル庁へ移戻しを行います。

-

44 -

（第３編第３章 予算及び執行）

B. 予算執行管理
ＰＭＯは移し替えられた予算の範囲内で、各ＰＪＭＯが適切に執行しているかについて、
予算執行管理を行います。
執行計画と執行実績を対比させ、調達案件毎に金額を管理していきます。また、執行計
画に記載されている時期と比較し、仮に調達が遅れている場合には、そのプロジェクトが遅延している可能性がありますので、その場合、ＰＭＯはＰＪＭＯに対し助言等を行います。
執行金額が執行計画額と大きく乖離している場合、その原因を追求するとともに、必要に応じて、翌年度予算要求にその内容を反映させる必要があります。
予算が不足するような状況が発生する場合は、そのプロジェクトの計画に問題があることが想定されますので、再度精査が必要です。逆に、大幅に余剰が出る場合には、予算要求時の見積り方に問題がある可能性があり、その原因を追及することで、翌年度予算要求において、より効率化された予算を組むことが可能となります。
このように、予算執行管理は、そのプロジェクトが置かれている状況を金額面から把握する有用な手段ですので、ＰＭＯ，ＰＪＭＯの業務として重要です。

-

45 -

（第３編第３章 予算及び執行）

Step.

８ その他の注意点について

実は今やっておくだけで後々発生するリスクや負荷を減らすことができる作業があります。
ここでは、それらの作業とポイントについて解説します。

１ 人事異動時は確実に引継ぎする【標準ガイドライン関連箇所：第３編第３章全般】

様々な検討と工夫をして予算要求をしても、プロジェクト推進責任者等のプロジェクトの中心となる職員が人事異動になってしまい、後任の職員がプロジェクトをうまく進められないことがあります。異動する当人が心残りであることは言うまでもありませんが、プロジェクトにとっても大きな痛手となります。
このような予期せぬ事態に備えて、予算要求にまつわる一連の作業は、複数名のグルー
プで実施しましょう。これにより、多くの情報が常に共有できます。その上で、異動する職員は、
まず後任の職員ではなくグループの他のメンバーへ引き継ぐことにより、引き継ぐ情報量が少なくて済み、円滑に引継ぎができます。
引き継ぐ内容は、実務的な内容はもちろんですが、なぜこのプロジェクトを進めるのか、どのようにサービスを向上するのか、といった熱い想いを引き継ぐことが重要です。
その後、後任の職員には、既存のグループメンバーが時間をかけて十分な教育ができます。
そのほか、１名でプロジェクトを任された場合には、後任に十分な情報を引き継ぐためにも、資料をしっかり作成し、引継ぎを実施しましょう。資料は、様々な決定事項に関する経緯がわかることが重要であり、それらは後任者の大きな手助けとなります。

ポイント
予算要求から執行までの間に、当該プロジェクトのＰＪＭＯを変更することは推奨しない。
やむを得ず、異動が決定した場合は、十分な引継ぎを準備し、後任に引き継ぐ。引
継ぎには、決定事項だけでなく経緯も伝達する。

事例：引継ぎ不足により、後日問題が顕在化したある省において、監査の結果、新たに機器・ソフトウェア等を購入しなければ情報
セキュリティ対策ができないことが判明しました。その結果が判明した後、原課側担当者が人事異動で交替しましたが、新たな情報セキュリティ対策用の予算を確保しなければならないことについて、引継ぎが十分に行われていませんでした。
１年後、その原課で情報漏えい事案が発生し、原因究明や報道対応を含めた様々な対応業務が大量に必要となりました。このとき、監査結果を反映した情報セキュリティ対策が講じられていれば、情報漏えい事案が発生しなかった可能性が高い

-

46 -

事例 3-6
引継ぎ不足により、後日問題が顕在化した

（第３編第３章 予算及び執行）ことが判明しました。しかしながら、原課の予算担当、会計課、ＰＭＯにおいても監査結果による新たな情報セキュリティ対策が必要なこと、そして予算要求が必要だった
ことを誰も知りませんでした。

２ プロジェクト計画書に反映して最新化する【標準ガイドライン関連箇所：第３編第３章第８節】

ここまで予算要求の作業を進めてきましたが、見積りを入手した後、プロジェクトの目的・目標を達成するために、多岐にわたって調整や変更を行い、予算要求を行ったことと思います。
その結果、検討の過程でプロジェクト計画書に記載されていた内容とは、異なる方針に変
更した項目があるのではないでしょうか。
予算にまつわる作業の最後の締め括りとして、変更内容をプロジェクト計画書に反映しましょう。
今回実施した内容を基にプロジェクト計画書を最新化することにより、次回の予算要求のときは、プロジェクト計画書を見直すことなく、計画書の内容に沿って作業を進めることができる
ため、準備作業が減ります。
また、人事異動が発生しても、最新のプロジェクト計画書を使って引継ぎができます。

ポイント
プロジェクト計画書に記載されている内容を、予算要求作業の結果から発生した変
更を基にＰＪＭＯ内で検討の上、修正し最新化する。
修正したプロジェクト計画書を、関係者と共有し合意する。
プロジェクト計画書の各項目に対し、予算要求の活動から変更される頻度の高い内容を次の表に示します。

No.

項目

変更例

1

政策目的

当項目はプロジェクト全体への影響が大きいため、基本的には変更しない。例外的に政策の方針転換等があったときのみ変更す
る。

2

対象範囲

整備する情報システムが提供するサービス・業務の範囲が変更されたときは、その内容に修正する。

3

実施期間

期間延長や短縮が発生したときは、その内容に修正する。

4

サービス・業務企画の方向性等

当初想定していた予算内でサービス・業務企画内容を実現することが困難であると判明し、企画の方向性等の変更を検討したときは、決定した内容に修正する。

5

予算

プロジェクトの構想段階に記載されていた年度ごとに見積った経費区分ごとの概算予算を、当初予算が承認された段階で、初年度分については、作成した予算に係る各種資料を基に修正する。また、次年度以降の予算見積りを見直した結果を記載する。

6

目標

主にサービス・業務企画の方向性等の変更とともに、達成目標とする指標及び達成目標年度等の変更する必要有無を検討し、その結果を反映する。

7体制

見積りの結果、人件費が当初想定よりも増減したときに、体制の増
強又は縮小を検討し、その結果を反映する。

-

47 -

表 3-8
予算要求活動後に修正が必要となるプロジェクト計画書の変更内
容の例

（第３編第３章 予算及び執行）

No.

項目

変更例

8

実施計画

プロジェクト計画書に記載されている他の項目（特に実施期間、対象範囲）に変更が発生したときに、あわせて当項目も整合性が取れるよう検討した上で変更する。

9

モニタリング

目標が変更されたときは、モニタリングで定義している内容の変更もあわせて検討し、変更する。

10

その他

見積りの際に事業者から得た情報や、省内・省外調整の過程で把握したプロジェクト運営上の課題やリスク等を追記・更新する。

-

48 -

デジタル・ガバメント推進標準ガイドライン

デジタル・ガバメント推進標準ガイドライン
実践ガイドブック（第３編第４章

サービス・業務企画）-

1 -（第３編第４章 サービス・業務企画）

目次
Step.1 サービス・業務企画活動全体の流れ ................... 5
Step.2 サービス・業務企画の開始準備 ........................ 6
１ サービスデザイン思考を理解する................................................. 6
心構えと視点（サービス設計 12 か条）を理解する ................. 6

Step.3 利用者視点でのニーズ把握 .............................. 8
１ 利用者のことを知る.................................................................. 8
どんな利用者がいるかを調べる .......................................... 9
利用者の人数を把握する ................................................ 10
２ 利用者のニーズを理解する ....................................................... 11
利用者のニーズから出発する ........................................... 11
エンドツーエンドで考える.............................................. 13

Step.4 業務の現状把握 .......................................... 16
１ 業務を観察する ..................................................................... 16
事実を詳細に把握する ................................................... 16
推測ではなく、現場で発生している事実をみる .................... 17
１か所だけの現場分析結果を全体に拡張しない .................... 19
日常的に業務の課題を収集し、分析に利用する .................... 20
２ 実績データを分析する ............................................................. 21
平均、合計ではなく、ばらつきを見る ............................... 21
時間と期間を区別して滞留状況をつかむ............................. 22
業務量のピークを捉え、ピークの発生原因を把握する............ 25
問合せや要望は、根本原因が同じになる粒度まで分類する ...... 26
３ 業務を可視化する .................................................................. 28
様々な立場の人が理解できる業務フローを作成する .............. 28
業務ルールや業務実施方法をまとめる ............................... 30
入出力情報や管理対象情報をまとめる ............................... 31-

2 -（第３編第４章 サービス・業務企画）

Step.5 サービス・業務企画内容の検討 ...................... 34
１ 課題を整理し、分析する .......................................................... 34
優先順位・影響度・費用対効果による分析 .......................... 34
２ 企画案を作成する .................................................................. 36
全ての関係者に気を配る ................................................ 36
利用者の日常体験に溶け込む ........................................... 37
縦割り組織にやわらかく横串を刺す .................................. 38
必要に応じて制度自体を見直す ........................................ 38
システムを作る前に、業務を標準化する ............................. 39
将来の業務フローには、効果を紐づける ............................. 39
精緻に効果を積算し、主要な効果を実感可能なものとする ...... 40
オープンにサービスを作る ............................................. 43
企画案を客観的に見直してみる......................................... 44

Step.6 軌道修正 ................................................... 49
１ 軌道修正しやすい進め方にする ................................................. 49
一遍にやらず、一貫してやる ........................................... 49
２ 柔軟に軌道修正する................................................................ 49
何度も繰り返す............................................................ 49
無理に継続しない ......................................................... 51

Step.7 新しい業務要件の定義 .................................. 53
１ 業務要件をまとめる................................................................ 53
２ 定義内容を関係者に共有する .................................................... 54【コラム】外部委託事業者の関わり方 ......................... 55
事業者と役割分担して作業を進める .................................. 55
発注者の、要件定義への関わり方 ..................................... 55-

3 -（第３編第４章 サービス・業務企画）

事例・参考の一覧
事例：自動車登録検査業務における利用者分類 ......................................... 9
参考：ペルソナ分析 ......................................................................... 12
参考：ジャーニーマップ ................................................................... 14
事例：現場の業務と合わないサービスを提供し活用されなかったシステム ..... 18
事例：１か所のみだった現場調査を改善................................................ 19
事例：１件１件の業務処理の滞留状況を可視化（ヘビ図） ......................... 23
事例：関係者間を往復する複雑な処理状況を可視化（シーケンス図） ........... 24
事例：利用ピークの分析を活かして電子申請利用率を向上 ......................... 25
事例：根本原因が特定できるまで詳細な分類を行う ................................. 27
事例：業務は複数の切り口で表現すると漏れなく可視化できる ................... 31
様式例：現状分析結果報告書のひな形 .................................................. 33
参考：３Ｅの観点を踏まえた費用対効果の検討 ....................................... 35
事例：利用者の状況の調査不足でシステム改善が迷惑化 ............................ 36
事例：利用者が日常的に使用するソフトウェアからのＡＰＩ申請................. 37
事例：業務削減効果の積算方法の見直し................................................ 42
事例：案段階の企画内容を Web サイトで公開 ........................................ 44
事例：個別管理システムを統合してサービス向上とコスト削減を実現 ........... 47
事例：一部地域で試行してから、サービスを全国へ展開 ............................ 50
様式例：業務要件定義書のひな形 ........................................................ 53※事例には当時の役職名やシステム名を使用しているため、現在使用されていな
い名称が記載されている場合があります。

-

4 -（第３編第４章 サービス・業務企画）

Step.

1 サービス・業務企画活動全体の流れ

サービス・業務企画は、まさにプロジェクトが実現したい将来像を具体化する活動です。そして、その土台となるのは、利用者視点でのニーズ把握と業務の現状把握です。現状把握、
プロジェクトを推進する上での制約条件、前提条件、リスク及び問題点を抽出した上での分析、適切な対応の検討、これらのプロセスを十分な時間をかけて実施することが重要です。このプロセスを怠った企画は、ほとんど失敗してしまいます。
政府の各種プロジェクトにおける過去の経験を踏まえ、サービス・業務企画を的確に行うための心構えと視点として「サービス設計 12 箇条」があります。本ドキュメントでは、このサービス設計 12 か条を具体的に実践するための作業の進め方やノウハウについて、事例を交えて説明します。
本ドキュメントの構成は、次のとおりです。

Step.2 サービス・業務企画の開始準備
サービス・業務企画を開始する前に、理解すべき心構えと視点を説明します。後に続く全ての作業の前提となる内容になっていますので、最初に目を通してください。

Step.3 利用者視点でのニーズ把握
利用者視点でのニーズを把握するためには、まずどのような利用者が存在するかを把握した上で、利用者の立場に立ってサービスの現状を考えることが重要です。そのような利用者についての分析手法について説明します。

Step.4 業務の現状把握
何かを変えようとするときには、まず今がどうなっているかを正確に把握することから始めましょう。ですが、むやみに情報をかき集めても、整理しきれず、重要な情報の抜け漏れを招く
おそれがあります。ここでは、現状の業務やシステムを理解するためには、どの情報をどのように集め、整理すればよいのかを説明します。

Step.5 サービス・業務企画内容の検討
現状の業務・システムを調査した結果を基に、課題をどのように把握し分析するのか、さらに、その分析結果から次の業務・システムの方向性を決める過程で気をつけるべきポイントと、新たなサービス・業務に向けた企画案を作成する手順や注意点について説明します。

Step.6 軌道修正
プロジェクトの方針は、把握した情報に応じてより良いものに見直されるべきものです。その見直しの判断条件をどのように定め、変更した場合の影響をどのように扱えばよいかを説明します。

Step.7 新しい業務要件の定義
Step.２、３で把握した現状をベースに、Step.４、５で検討した次の業務・システムの方向性にのっとり、次の新しい業務に関する要件を定めていく過程を具体的に説明します。

-

5 -（第３編第４章 サービス・業務企画）

Step.

2 サービス・業務企画の開始準備

医師は、まず患者の話をよく聞き、どのような症状が出ているかをよく調べます。患者の症状をほとんど調べず、いきなり手術するような、そんな医師にはかかりたくないですね。システ
ムを作るときも同じです。まず、今のサービスや業務の現状をよく調べます。そして、誰が何に困っているのか、その背景にどのような事象が発生しているのか、事実を正確に把握するのです。
今までの政府のシステム整備プロジェクトでは、往々にして事前調査のプロセスを簡略化し、システムを作ることが先行する傾向がありました。そのような進め方では、サービスの利用者がよくなったと実感できる効果を出すことはできません。そこで、「サービスデザイン思考」を導入しようという声が高まりました。サービスデザイン思考に基づいた活動の中では、利用者の立場になり利用者と協働しながら、実際に発生している事実を正しく把握した上で、段階的にサービスや業務を改善していきます。
この章では、サービスデザイン思考というものが何なのか、そしてサービスデザイン思考に沿って企画を行うためにどのような活動を行うべきかについて、具体的に解説します。

１

サービスデザイン思考を理解する【標準ガイドライン関連箇所：第３編第４章第１節】

サービスデザイン思考とは何でしょうか。サービスデザインを進めていくに当たり、概念や方法論などを整理したものなのですが、言葉を２つに分けて考えてみましょう。
まず、行政による「サービス」についてです。簡単に言えば、国民生活の安定と向上のために、国や地方自治体等が国民や企業に対して何かをするといった行動そのものです。
次に、「デザイン思考（Design Thinking）」についてです。「デザイン思考」とは、デザイナー
がデザインを行う際の進め方や考え方を適用して、利用者中心の視点からビジネス上の問題
点を解決する方法です。この方法では、サービスの利用者がどのように振る舞い、どのように考えているかを理解した上で、利用者体験全体をデザインします。
言葉をつなげると、「サービスデザイン思考」とは「サービス」＋「デザイン思考」であり、「サービスの現状における課題を、デザイン思考を用いて解決しよう」という考え方や手法のことを表しています。

心構えと視点（サービス設計 12 か条）を理解する
利用者中心の行政サービスを提供し、プロジェクトを成功に導くために必要となる重要な考え方については、デジタル・ガバメント実行計画において「サービス設計 12 箇条」としてまとめています。これらは、利用者中心としてサービスを設計するサービスデザイン思考を具体化したものであり、これまでのサービス・業務改革（ＢＰＲ）の取組から得られたノウハウをベースとしつつ、サービス改革に関する近年の国際的な動向を取り入れたものです。
本章では、このサービス設計 12 か条に示された心構えと視点を具体的に推進し、サービス・業務改革（ＢＰＲ）を実現するための実践的な解説を行っています。

-

6 -

注記
サービスとは、公共サービス基本
法（平成 21 年法律第 40 号）第 2条では、「公共サービス」について、「国民が日常生活及び社会生
活を円滑に営むために必要な基本的な需要を満たすもの」と定義されたもの。

（第３編第４章 サービス・業務企画）

図 4-1
サービス設計 12 か条

まず最初は、利用者のニーズ把握から出発し、業務の現状把握を通して企画案を検討しますが、そのプロセスを何度も繰り返し、プロジェクト初期の想定と異なる結果になると判明した際は、計画全体を柔軟に軌道修正します。
なお、サービス設計 12 か条は、全工程を対象とした心構えと視点を表すものですが、とりわけ企画時点で重要になるポイントが多いこともあり、本章でまとめて解説を行っています。
また、本章の解説の中では、サービス設計 12 か条を補足する意味合いで、さらに注意
すべき観点や参考にすべき考え方等を追記しています。

-

7 -（第３編第４章 サービス・業務企画）

Step.

3 利用者視点でのニーズ把握

利用者視点で考えるという言葉は、あまりにも当たり前のことのように思うかもしれません。
そこで、最初に簡単なテストをしてみましょう。あなたが現在担当している業務について、考
えてみてください。
まず、利用者の顔が、何人分思い浮かぶでしょうか。窓口サービス等で日々利用者に接する業務に従事する人であれば、すぐに数十名の利用者の顔が思い浮かぶでしょう。一方で、間接的な業務が中心の人は、あまり具体的な顔が思い浮かばないかもしれません。
次に、そのうち１人の利用者を思い浮かべてみて、その人のことをどこまで知っているか考
えてみましょう。名前、住所、家族構成、職業、勤務時間、通勤経路、趣味、・・・。利用者からの相談業務に従事する人は詳細な状況を知っているかもしれません。しかし、多くの場合は、利用者がサービスを受ける瞬間の状況しか見えないので、あまり詳細な状況を知るチャンス
はないかもしれません。
テストはこの２問で終わりです。どうでしょうか。意外と利用者のことを知らないということに気づいたかもしれません。でも、心配はいりません。利用者のことを知っていると思い込むよりも、利用者のことを十分に知らないと認識した上で、利用者の状況をしっかり調査することの方が何倍も重要なことだからです。
それでは、利用者の状況を把握する方法を見ていきましょう。

１

利用者のことを知る【標準ガイドライン関連箇所：第３編第４章第２節】

民間企業が提供するサービスでは、利用者の人数を少なくても１日単位で把握し、週単
位、月単位等で集計を行いながら利用者数の変化を機敏に察知しています。１日単位どころ
か、１時間単位、１分単位で利用者数を把握している企業も多いでしょう。例えば Web サイト
で広告や販売を行っているサービスであれば、アクセスログを分析し、利用動向がすぐに把握できるように工夫しています。利用者数が、企業の収益に直結するからです。
行政機関が提供するサービスでは、利用者数を詳細に把握できているでしょうか。確かに窓口でのサービスであれば、１日ごとの利用者数を把握しているところも多いかもしれません。でも、システムの利用者数となると、アクセスログとしてシステム内に記録しているはずだ
けど、その集計結果を見たことがない、ということもありそうです。
しかし、行政機関においても利用者のことを知ることは不可欠です。民間企業であれば、サービスが悪い企業は自然淘汰されます。しかし、行政機関については基本的に他の選択肢がないので、サービスが悪くても利用者は使い続けるしかありません。だからこそ、行政機関
は利用者の状況を知り、サービス内容が十分になっているか、改善すべき点がないかを自ら把握することがとても重要になります。
新しいサービス・業務を企画する際にも、まず利用者を知ることからスタートしましょう。
「どのような利用者が」「どこに」「どれくらい」いるのか、その利用者は「何のために」「どのように行動し」「何を求めて」いるのかを事実に基づいて把握し、情報を整理していきます。
なお、利用者とは、外部の利用者に限りません。内部の職員も利用者の１人です。職員自身が情報システムを利用してサービスを提供したり、様々な業務を実施したりするのであれ
ば、その職員が業務を実施しやすいように十分な考慮を行うことが重要だからです。

-

8 -（第３編第４章 サービス・業務企画）

どんな利用者がいるかを調べる
まずは、どんな利用者がいるのか、利用者の種類を調べるところがスタートです。一般的には、次のような分類から考え始めると考えやすいかもしれません。

利用者の分類の例
サービスの利用目的による違い
サービスの利用の仕方で分類します。例えば、行政機関に証明書発行を求める直接的な利用者がいる一方で、その証明書を確認することで業務を行う間接的な利用者がいます。
本人か代理人かによる違い
実際に手続等を行うのが、手続の主体となる本人か、それとも本人から委任を受けた代理人であるかで分類します。代理人による申請の場合は、委任状が必要になるなど必要書類や事務手続が異なる可能性があります。
個人か法人かによる違い
個人と法人では手続の目的、内容、手段が大きく異なる可能性があります。例
えば、企業等の法人が日常的に申請を行っている場合は、１つの手続ごとに窓口に来るのではなく、まとめて一括で申請を行っているかもしれません。また、申請のためのシステムを企業内で整備しているかもしれません。
詳細属性ごとの違い
上記の分類に加えて、さらに地域別、世代別、世帯構成別など、ニーズの特性が異なるグループがあれば、詳細に分類することで個々のニーズを捉えやすくなります。

事例：自動車登録検査業務における利用者分類
利用者の分類は、抽象的な表現だけでは実感しにくいので、具体例に基づいて考えてみましょう。
自動車の登録検査業務（新規登録、継続検査（車検）等の業務）について、様々な種類の利用者が関わっています。
まず、自動車の所有者自体が個人であることもあれば法人であることもあります。また、継続検査等の手続は、自動車所有者本人が直接行うこともありますし、自動車の販売事業者、整備事業者、行政書士等の代理人が行うこともあります。また、これらの手続は運輸支局で実施しますが、オンラインで行える仕組み（ＯＳＳ：自動車保有関係手続のワンストップサービス）でも実施できるので、ＯＳＳ経由で本人申請や代理人申請を行う利用者が存在します。これらが、直接的な利用者の代表例となるでしょう。
一方で、これらの利用者へのサービスを提供しているのは運輸支局等の職員です。職員が効率的に業務を行えなければ、直接的な利用者へのサービスの品質は低下してしまいます。よって、これらの職員についても、利用者として十分に考慮する必要があります。
また、間接的にサービスを受ける利用者も存在します。上記の手続完了後に自動車検査証（車検証）が発行されますが、その車検証は様々な人が様々な目的で確認します。例えば、警察による路上調査、損害保険会社による自動車損害保険加入時-

9 -

事例 4-1
自動車登録検査業務における利用者分類

（第３編第４章 サービス・業務企画）の確認、フェリー会社による自動車積載時の全長・車幅の確認等があるでしょう。車
検証の形態や内容を変更することがあれば、これらの間接的な利用者にも十分に配慮することが必要となります。
このように、１つのサービスであっても、その利用者は多岐にわたることがあります。利用者を漏れなく把握して分類することが、利用者を理解するための第一歩となります。

利用者の種類を把握する手法には、以下のようなものがあります。

利用者の種類を把握する手法の例
現在のサービス・業務を利用している現場での観察
現在使用している業務マニュアル、手順書等の確認による利用者の洗い出し
業務データや各種ログ等の分析による利用者の洗い出し想定する利用者に対するインタビュー、アンケート
利用者を把握した結果の整理方法としては、定量分析と定性分析があります。
利用者の定量分析は、利用者を洗い出し、種類ごとに量、利用時間帯、拠点等の情報をまとめたものです。これらは効果指標の基礎情報になりますので、正確で詳細な情報を収集してください。
利用者の定性分析は、利用者の種類、特徴、満足度、要求事項等を収集しまとめたものです。個々のサービス・業務ごとに一覧を作るのではなく、利用者から見たエンドツーエ
ンドの範囲を網羅した１つの表でまとめると良いでしょう。基本的には利用者１種類を１行として整理しますが、年齢や性別、拠点等の特徴ごとに細分化して詳細を把握することを推奨します。

利用者の人数を把握する
利用者の種類を把握することは比較的簡単ですが、利用者の人数を把握することは難しい場合があります。サービスの直接的な利用者であればまだ把握しやすいですが、間接的な利用者になると人数を正確に把握することは困難でしょう。しかし、正確でなくとも、大まかな規模感をつかむことは重要です。
利用者の人数を把握する手法には、以下のようなものがあります。利用者を十把一絡げにして合計人数を出すのではなく、利用者の種類ごとに人数を把握しましょう。

利用者の人数を把握する手法の例 （既存サービス）
申請数、窓口対応数、問い合わせ件数等、業務で蓄積したデータからの推計システムに蓄積したデータに基づく統計情報からの推計
現場での利用動向や業務状況のサンプリング調査に基づく推計
上記手法が取れない場合には、 一般的な統計情報に基づいた推計（該当地域の対象世帯人口に対して一定の利用比率を掛ける等）
さて、利用者が既に存在するサービスについては上述のように人数を把握することができますが、新規に立ち上げるサービスでは利用者の人数を「予測」しなくてはなりません。
このような場合は、サービスの想定利用者を種類ごとに区分した上で、それぞれの利用者層に対して次のような手法を活用して人数を見積りましょう。

-

10 -

（第３編第４章 サービス・業務企画）

利用者の人数を予測する手法の例 （新規サービス）
類似するサービスの利用者数からの推計
利用者の最大人数を把握した上で、段階的な利用率の推計
利用者へのインタビューやアンケート調査に基づく推計
上記手法が取れない場合には、 一般的な統計情報に基づいた類推（該当地域の対象世帯人口に対して一定の利用比率を掛ける等）
ここで気を付けてほしいことは、多くの人が、利用者数を楽観的に「多め」に予想するということです。新しいサービスを立ち上げる際に、サービスを立ち上げる側の人はどうしてもサービス自体への思い入れも含めて、サービスが数多くの人に利用してもらえることを想定しがちです。想定する利用者数が多くなるほど、対応する職員側の人数もシステム費用も増えていきます。サービス開始当初から一遍に多数の利用者数を想定して投資するのではなく、利用者を段階的に増やすことも含めて、適切な水準で利用者数を見積もるように注意しましょう。

２

利用者のニーズを理解する【標準ガイドライン関連箇所：第３編第４章第２節】

利用者のニーズを理解するために必要なことは、想像や推測ではなく、調査です。
例えば、「利用者は、窓口へ来訪することを面倒に思っている」ことから、面倒ではなくしてほしい、というニーズがあるのではないでしょうか。本当にそのようなニーズが強いかもしれま
せんし、逆にそのようなニーズよりもっと本質的に困っていることがあるかもしれません。それは、調査をしてみないとわかりません。
実際に調査をしてみると、いろいろなことがわかります。例えば、窓口へ来訪することよりも、申請後の審査に長期間かかっていることに困っているかもしれません。この例については、実践ガイドブック「第２章 Step．2-1 目標とする成果を見定める」で詳述しました。
また、一部の利用者から寄せられた意見・要望だけを確認して、利用者全体のニーズが把握できたと思い込んではいないでしょうか。実際は大半の利用者が全く異なるニーズを持っているかもしれません。もしも自発的に意見・要望を述べることはない多数の利用者が存在する
場合、調査をしなければそのニーズを知ることはできません（全体を適切に把握する調査の仕方については、「Step.5-2-G. 精緻に効果を積算し、主要な効果を実感可能なものとする」
を参照ください。）。
現場を知らない人の推測のみで目標を設定するのではなく、現場の流れ、利用者の状況を調べて、利用者の本当のニーズを把握することが最初の一歩です。

利用者のニーズから出発する
利用者のニーズを把握するには、具体的にどのような調査をすればよいでしょうか。サービスを提供する側は、どうしても「提供者側の視点」に立ちがちです。様々な利用者のそれ
ぞれの立場でニーズを把握するための手法として、「ペルソナ分析」があります。
「ペルソナ」とは、サービスの典型的な利用者の、目的、意識、行動等のパターンを構造化し、利用対象者を仮想の人物として定義するものです。例えばサービスのターゲットを「会社員」と抽象的に定義すると、検討チームのメンバーそれぞれが思い描く「会社員」の姿が異なるため、チームとして判断する際にブレが生じてしまいます。ペルソナ分析ではもっと具体的に「氏名、年齢、性別、家族構成、勤務先、仕事内容、その他の詳細条件」等を設定します。このような具体的な利用者像をイメージしながら検討を行うことで、利用者が

-

11 -

（第３編第４章 サービス・業務企画）

抱える課題や問題を浮き彫りにし、具体性の高いアイデアを創出しやすくなります。
「すべての人を万遍なく満足させようとすると、結局誰にも喜ばれない」という考え方があります。ペルソナ分析を使えば、具体的な利用者の具体的なニーズに基づいて、少なくともその利用者にとって喜ばれるサービスを検討することができます。
なお、ペルソナ分析も１つの手法に過ぎません。重要なことは、提供者側の視点ではな
く利用者側の視点に立つことです。サービスを検討するための大前提として、利用者の立場でサービスを受けることを想像し、利用者のニーズがどこにあるかを考えてみてください。

参考：ペルソナ分析「ペルソナ」とは、サービスの典型的な利用者の、目的、意識、行動等のパターンを構造化し、利用対象者を仮想の人物として定義するものです。ペルソナを作成して検討を行うことで利用者体験を洗い出すことができ、検討を行う関係者の間で共通認識を持って検討ポイントを具体化することができます。
例えば、引越しに関する手続の改善を検討した際には、次のような家族をペルソナとして設定した上で、この家族が引っ越すときに必要な手続の内容やタイミング等について理解を深めました。

＜ペルソナの作り方＞
以下に紹介する手順は一例です。検討対象や状況に応じて臨機応変に対応してください。
(1) ターゲットとなる利用者に関する情報を収集する
ターゲットとなる利用者又は近い属性を持つ人について、情報を収集します。情報収集方法としては、インタビュー・アンケート、Web 検索、公開されている調査デー
タ、既存システムのログ等が挙げられます。
(2) 収集した情報を分析し、グルーピングする収集した情報を、関連性が高いと思われるものごとにグルーピングして整理します。収集した情報全てが対象になりますが、自由回答のものからもパターンが見えて

-

12 -

参考 4-1
ペルソナ分析

（第３編第４章 サービス・業務企画）

くること（サービスに関する調査方法、サービスを選択する際の判断基準、サービスとのタッチポイントで使用するツール、日常の行動パターン、等）があります。何の観点でグルーピングしたかがわかるように名前を付けておくと良いでしょう。
(3) グルーピングした情報から利用者像を具現化、ペルソナを作成
グルーピングした結果から、最も典型的と思われる利用者の輪郭を浮かび上がらせます。この時、最初はぼんやりでも構わないので、ペルソナの骨格となるものを整理します。これを基に、性格や嗜好、考え方やライフスタイル等の情報を加味していくことでペルソナ像を明確にしていきます。

注記
タッチポイントとは、サービス提供者と利用者の間に存在するあらゆる接点のこと。サービスを申し込む Web サイ
ト、サービスの受付窓口、コールセンター等がある。

(4) 作成したペルソナの内容を見直す
ペルソナの案を作成後、ターゲットとなる利用者と直に接している人等に、実際の利用者像とかけ離れたところがないか、ターゲットたる利用者としてふさわしいかを確認してもらいます。実際の利用者像と作成したペルソナにかい離が見られた場合
は、随時内容を修正してください。

エンドツーエンドで考える
行政組織は縦割りです。新たなサービス・業務を企画する人も、どこかの行政組織に属している以上、所属する組織の所掌範囲を意識せざるを得ないでしょう。
ただ、利用者にはそんな事情は関係ありません。関係する組織が１つであるか複数であるかには関係なく、手間は最小限に、サービスは丁寧かつ迅速に受けたいというのが利用者のニーズです。
利用者のニーズ把握を行うためには、自らが所属する組織の所掌範囲だけで個々のサービスや手続のみを切り取って検討するのではなく、利用者がサービスを受ける必要が生じた時の最初の行動から最後の行動まで（エンドツーエンド）の視野に立ち、他の行政機
関や民間企業が担うサービスの利用まで含めた利用者の行動全体を一連の流れとして考えることが重要です。

図 4-2
サービス・業務企画の対象範囲の例

このような利用者の行動全体の流れを可視化するための１つの手法として、「ジャーニー
マップ」があります。ジャーニーマップを用いることで、利用者の日常体験の中でどのように
行政サービスが使われているかを可視化することができます。

-

13 -

（第３編第４章 サービス・業務企画）

参考：ジャーニーマップ
ジャーニーマップは、利用者のサービス・業務に関わる一連の行動を旅になぞら
えて可視化したもので、利用者とサービス提供者の関わりをストーリーとしてまとめたものです。
例えば、前述の引越し手続の例では、ペルソナとして設定した家族を念頭に置いた上で、この家族が引っ越すときに必要な一連の行動をジャーニーマップとして可視化しました。

＜ジャーニーマップの作り方＞
ジャーニーマップの作成に確立された方法論があるわけではありませんので、以下の例の進め方にこだわる必要はなく、ジャーニーマップの作成目的や取り組みた
い課題によって柔軟に項目を変えるなど対応してください。
なお、ジャーニーマップを作成する際は、ステークホルダーによるワークショップを実施するのが良いでしょう。ジャーニーマップの作成を通して、利用者体験のエンド
ツーエンドへの理解を深めることが期待できます。
(1) ペルソナの設定（誰が）現状を調査した結果を分析してペルソナを設定します（「参考 4-1 ペルソナ分析」
参照）。以降、このペルソナの体験としてジャーニーマップを整理していきます。ジャーニーマップは、ペルソナごとに作成することになります。ジャーニーマップは、一人のペルソナ分だけでなく、主要な利用者層にいる最優先のペルソナとサブ的な層にいる二番手以降のペルソナ等の複数のパターンに対して作成できると、より深い検討を行うことができます。
(2) 場面の設定（いつ）
利用者の行動をいくつかの場面に分けて設定します。例えば、サービスを受ける
前、サービスを享受している最中、サービスを受けた後と分けたりします。それぞれの段階を更に細かく区切っても良いでしょう（例：サービスを認知する場面、それに関心を抱く場面、同様のサービスを比較し検討する場面、サービスを決定してそれを享受する場面、サービス享受後の場面、等）。

-

14 -

参考 4-2
ジャーニーマップ（第３編第４章 サービス・業務企画）(3) 場所、タッチポイント、行動の整理（どこで、何を、どうした）
利用者がそれぞれの場面において、どこで何をどうしているかを整理します。
行動を整理する際は、タッチポイントを明確にすることも有効です。タッチポイントとは、サービス提供者と利用者の間に存在するあらゆる接点のことで、例えばサービスを申し込む Web サイト、サービスの受付窓口、コールセンター等のようなものを指しています。また、タッチポイントにおける直接的な行動だけを整理するのではなく、その前後の行動にも課題が潜んでいることがあるので、併せて整理してください。
例示した引越し手続のジャーニーマップではタッチポイントまでは詳細化していま
せんが、役所の窓口に何度行く必要があるか、郵送や電話での手続を何度する必要があるかをタッチポイントとして明確化すると、利用者体験をさらに具体化することができます。
(4) 利用者の感情の整理（どう考えたか、どのような感情だったか）
利用者が行動する際に、利用者がどのように考えたのか（感覚、疑問、不満、満足等）を明らかにすることも有効です。
ポジティブなものだけでなくネガティブな感情も整理してください。ネガティブな感情を抱くポイントには、往々にして改善すべき内容が含まれています。例えば、ジャーニーマップの中に、「同じことを何度も伝えるのが面倒」、「必要な書類の一覧がわ
からない」等の言葉を吹き出しで入れることで、問題点を強調することができます。
(5) 課題、改善案等の整理（現状に対する課題、こうあるべきという意見）
ここまでに整理された内容から浮かび上がってきた課題や、こうしたらもっと良くなるのではという意見、新しくこういうものを作ったら良いのではといった改善案等を整理します。既に顕在化している課題や、何かしらの基準を下回っているものがあればそれも記載しておきます。ここで挙げた情報を基に、実際の改善策を検討してい
きます。

-

15 -

（第３編第４章 サービス・業務企画）

Step.

4 業務の現状把握

利用者のニーズ把握と並んで重要なことは、実際に発生している様々な事象をしっかり観察し把握することです。現状を正しく把握せずにサービス・業務企画を行うと、見た目としては新しいサービスが実現できたように見えても、実際にはサービスが使われなかったり、業務上大きな問題が発生したりするなど、様々なトラブルが発生する危険性をはらんでいます。
この Step では、現状のサービス内容や業務内容を調査するに当たり、どのようなことに注意しながら、どのような調査をすべきかについて解説していきます。

１

業務を観察する【標準ガイドライン関連箇所：第３編第４章第２節】

業務を観察するということは、誰にでもできそうな簡単なことにも思えますが、観察者の経験によって見えてくるものは全く異なります。一般の人が工場見学に行った際に見える風景と、工場の生産性改善を専門とする人に見える風景は、全く異なるものでしょう。ですが、業務を観察する経験が少ない人であっても、これから説明するポイントを押さえれば十分に基本的な現状把握を行うことができます。
まず、一番に注意してほしいことは、先入観を持たずに観察するということです。
例えば、申請した案件に対する審査期間が長いという問題を調べることを想定してみましょう。この時、「審査職員の能力が重要」という先入観を持っていると、経験年数の異なる審査職
員を比較して、審査の着眼点や審査方法に違いがないかという分析をしたくなります。しかし、先入観を持たずに実際に発生していることをよく観察していると、単純に審査に入るまでの待ち時間が長かったり、やっと審査に入っても、基本的な書類の不備が見つかって差戻しになったりといった、本質的な審査に関係のない部分で多くの時間を費やしていることがわかるかもしれません。
仮説を立てて検証するという手法は多くの面で有効なのですが、最初の現場観察の時点で仮説を持っていると、重要な事象を見落としてしまうことになりかねないということに注意が必要です。つまり、あれこれと頭の中で考えることは後回しにして、まずは実際に発生している事実を詳細に把握するという姿勢で臨みましょう。

事実を詳細に把握する事実を詳細に把握するということは、サービス・企画のプロセス全般を通じて根底となる重要な姿勢です。この章の以降の説明では、いろいろな視点や事例に触れながら、どのよ
うな進め方だと事実把握が十分ではなく、その場合はどのように改善すべきか、について説明します。
ただ、この先の解説を読む前に、ぜひ留意してほしいことがあります。事実把握の方法について解説すると、どうしても当たり前で一般的な事柄のように思えてしまうという点です。これから、「平均、合計ではなく、ばらつきを見る」、「推測ではなく、現場で発生している事実を見る」等、様々な考え方を説明しますが、あまりにも当然のことであるため、そんなことはわかっていると読み飛ばしたくなるかもしれません。
しかし、今までに数多くのプロジェクトでトラブルが発生したり失敗に終わってしまったりした原因を辿ると、最初の企画時点で事実を詳細に把握できていなかったことに帰結する例
が本当に多いのです。

-

16 -

（第３編第４章 サービス・業務企画）

細かな粒度で１つ１つの事実を徹底的に把握していくと、今までに気づいていなかった物が見えてきます。実際に発生している事実に基づいて問題が可視化されれば、その問題に対して因果関係の整理を行った上で具体的な改善策を打つことができます。逆に本当の問題が可視化されなければ、思い込みや仮説に基づいてサービス・業務を設計することになり、その問題を解決することはできません。

図 4-3
事実を詳細に把握する

また、特にプロジェクトの業務分野の経験が長い方にとっては、自分自身が現場のことも含めてよく知っているため、あえて事実関係を調査するまでもなく、問題点や背景事象を説明できるかもしれません。ですが、そういった「プロ」の人ほど、いろいろな事象に対して頭の中で説明をつけてしまうので、かえって事実を見過ごしてしまうこともあります。現場を観察し、業務で発生する実データを確認しながら、何が起きているかを先入観なく調べてみましょう。

推測ではなく、現場で発生している事実をみる
政府のプロジェクトは、ボトムアップよりもトップダウンで立ち上がることが多いかもしれま
せん。トップダウンで立ち上がるプロジェクトは、本省等の数名の職員がチームとなって企
画内容をまとめあげるというような体制が典型的で、成果を達成する期限、そのための計画を作成する期限等が切られて、検討を短期間で完了させることも求められます。
このように少ない体制で多忙な中では、つい現場に足を運ぶことを省略しがちです。サービス・業務の概要は、既存のドキュメント（利用者向けの説明文書、内部の業務フローや業務手順書等）を読めば理解できるので、それらのドキュメントを穴が開くほど眺めながら、この業務に重複がある、この部分で利用者を待たせてしまっていると、問題点を指摘することができます。でも、このような進め方では、現場で本当に起こっている問題は見えませんね。
これはひどい例でしたが、実際にはもう少し丁寧なやり方になることも多いでしょう。現場にアンケート調査をかける形です。サービス・業務の流れや現状の問題点等について、書面でのアンケート調査を行い、その結果を整理します。そうすると、検討プロセスも外部に

-

17 -

（第３編第４章 サービス・業務企画）

説明しやすく、現場の声を反映した企画案のように見えます。しかし、これでも本当に十分でしょうか。アンケートの取り方の巧拙にも大きく左右されますが、現場の声を聞いたという証拠作りのためだけのアンケートでは、本当の問題を浮かび上がらせることは難しいかもしれません。
まずは、とにかく現場に行ってみましょう。現場に行かずして、サービス・業務企画は成立しえません。数多くの異なる現場に足を運び、現場を見た上で、業務実施方法や処理時間を調べてください。現場に行かず、「このような業務が行われているはず」と推測した結果に基づいて情報システムを作ると、現場では使えないものになりかねません。
また、現場に行くだけでなくドキュメントを集めることも非常に有用です。業務マニュアル
１つをとっても、組織全体で整備した標準的な業務マニュアルだけでなく、各拠点で独自の業務マニュアルを作成していることがよくあります。各拠点の業務マニュアルを入手し並べて比較してみると、標準的な業務マニュアルでは十分でなかった部分を補完したり、地域の実情に合わせた追加的な対応を行っていたり、様々に工夫していることがうかがえます。これらの工夫点は、今後のサービス・業務を企画するための貴重なインプットとなります。業務マニュアルだけでなく、前任者が後任者に引き継いだ際のドキュメントも有用です。このような様々な現物のドキュメントを集めることで、生々しい業務の実態を捉えやすくなります。
サービス・業務企画の段階で現場に調査に行くことは労力のかかることですが、プロジェ
クトがうまく行かなくなってから立て直すにはもっと労力がかかってしまいます。現場調査には、十分な期間を確保する価値があると考えて良いでしょう。

事例：現場の業務と合わないサービスを提供し活用されなかったシステム
あるプロジェクトでは、市町村が登録したデータを都道府県が審査して国へ送付する制度が新設されることに伴い、これらの情報を電子的にやりとりするシステムを整備することとしました。
このプロジェクトの企画段階では、一部の市町村を招へいして数回の検討会を開催しましたが、最終回の時点においても新制度での市町村等における業務の具体的な実施方法は決定しませんでした。また、新制度に関する情報をどのように分析し、活用し、公表するか、そのために収集する必要がある情報は何かといった点についても具体的な議論は行われていませんでした。
その後、システムを作ることが優先され、新制度の開始に伴いシステムの稼働が開始しましたが、結果としてこのシステムは非常に使いにくいものとなってしまいました。
例えば、都道府県が審査するための帳票はＰＤＦしか出力できず、集計作業が行えませんでした。また、市町村が登録した情報は一般利用者が確認できるようになっていましたが、利用者が情報の検索を行おうとしても、必要以上に詳細な項目を羅列しているなど閲覧しづらく、利用者が検索を行う目的に資するとは考えられないものでした。このような理由から、システムを利用する自治体はかなり少数に留まり、システ
ムの外で紙媒体や表計算ソフトを使って業務が行われることになってしまいました。
このプロジェクトは、会計検査院による検査を受けることとなりました。会計検査院の意見では、このような事態が発生した原因の１つとして、「システムの構築をするに当たり、市町村が通常の業務で使用し又は保有する情報の内容等の実態、交付申請等の手続の実施状況等を十分に把握していないこと」を挙げています。

なお、現場へのヒアリング等を行う際には、ヒアリングを受ける担当者への配慮が重要です。初対面の担当者にヒアリングするのであれば、その担当者も身構えてしまうのが自然な

-

18 -

事例 4-2
現場の業務と合わないサービスを提供し活用されなかったシステム（第３編第４章 サービス・業務企画）

ことでしょう。ともすれば、余計なことを口走って宿題をもらいたくない、業務が非効率になっていることへの責任を追及されたくないといった思いから、ヒアリングに非協力的になることもあるかもしれません。
まず、調査の目的がサービスや業務を改善することであり、問題の責任所在や犯人捜しをしているわけではなく、調査結果についても担当者や担当部署を特定できるような形での公表を行わないことなど、担当者が率直に回答しやすいための環境を整えましょう。
また、今回の取組みによって現場の担当者にもメリットとなることを、丁寧に説明することが重要です。例えば、業務やシステムの非効率で無駄な部分を取り除き、注力すべき本来的な業務に十分に時間を割けるようにすることを目標としているのであれば、その趣旨をしっかりと現場の担当者に伝えましょう。１回のヒアリングの場だけで調査を終えるのではな
く、ヒアリングを契機として今後も継続的に意見交換を図れるように担当者間の関係性を構築できることが理想ですね。

１か所だけの現場分析結果を全体に拡張しない
さて、先ほどは現場へ行くことの重要性を説明しました。では、とりあえず１つの現場に行けば、それで十分でしょうか？
１か所ではやはり少なすぎるのではないでしょうか。多くの場合、サービス・業務を運営している現場は１つではないでしょう。全国に拠点があるような業務であれば、数百、数千か所といった多数の拠点があることもあるでしょう。１か所の現場分析結果にその現場のみの特性が含まれていると、それを全体に展開しても、他の現場には適合しません。
とは言え、全ての拠点に訪問して調査することも現実的ではありません。まずは、全体を正しく代表する拠点を探しましょう。都市部と地方でも利用者のニーズは大きく違うでしょう。拠点ごとに扱っているサービスも違うかもしれません。それぞれの拠点が様々な特性の違いを持つ中で、細かな差異は置いておいたとしても大きな特徴を持つグループに分け、それぞれのグループから現場調査の対象拠点を選ぶことが効率的です。選ぶ拠点数は、一概には言えません。都市部で２拠点、地方で３拠点という選び方で良いケースもあるでしょうし、数十拠点を調べないといけないケースもあるでしょう。
なお、最初から調査拠点を選んでしまうのではなく、全拠点を対象に簡易なアンケート調査を実施した上で、特性の違いを考慮しながら詳細な現場調査を行うべき拠点を選択するという手法もあります。

事例：１か所のみだった現場調査を改善あるプロジェクトでは、特定条件に該当する施設利用者に対して支援金を支給する制度の開始に合わせ、各施設に必要となる事務作業を支援するシステムを整備することを計画しました。
全国に数千の施設が存在するのですが、当初の計画策定時には１施設だけに電話ヒアリングによる調査を行い、その結果に基づいて現行の業務フロー、サービス開始後の業務フロー等を作成していました。
しかし、ここでプロジェクトの進め方について見直しが入りました。本当にこのまま
システム構築を進めて良いのだろうか、もっと施設の現場を調べるべきではないか、
そのような観点から、計画の途中で軌道修正を行ったのです。
まず、施設の特性別、手続の種別、対象者の種別を基に、施設間の差異を洗い出しました。そして、支援金の支給対象地域における利用者層の人口や施設の規模により抽出基準を策定し、その基準に基づき、各特性を網羅するよう複数の施設を選定しました。つまり、施設ごとに様々に背景や業務実施方法が異なるため、各施設の特徴を「正しく対象として、現場調査を行うこととしました。調査方法も電話だ

-

19 -

事例 4-3
１か所のみだった現場調査を改善（第３編第４章 サービス・業務企画）

けでなく、書面、現地調査等の様々な方法を複合的に用いました。

調査方法の見直しにより、施設間の業務の違いを考慮した業務要件を定めることができ、早い段階で軌道修正することができました。

なお、多くの現場を調べることで、現場ごとの「ローカルルール」を把握することも重要です。ローカルルールを調べて業務を標準化することについては、「Step.5-2-D. システムを作る前に、業務を標準化する」で後述します。

日常的に業務の課題を収集し、分析に利用するサービス・業務企画を実施する時に初めて現場の課題を収集しようとしても、なかなか効
率的には収集できないでしょう。そもそも現場の職員は忙しいので、過去の話を聞いてもそのことを覚えていないかもしれません。課題がないかと聞かれても、過去に何かがあったよ
うな気がするけど何だったかなと、曖昧な回答になってしまいがちです。
発生した課題を最も記録しやすいタイミングは、発生した直後です。記憶が新鮮なうちに、どのような事象が発生して何が課題になったのかを記録することが習慣化されていると、後々になって業務改善や新たなサービス・業務企画を行う際にとても有用なナレッジとなります。
では、どのような情報をナレッジとして蓄積すればよいでしょうか。一般的な例を見てみましょう。

日常的な課題収集手法の例
現場の窓口等への問合せ、クレーム
組織に対する明示的な問合せ（公式の問合せ様式によるもの等）については管理しているものの、窓口に来訪した利用者からの口頭問合せや、電話での問合せについては、その場で職員が対応するだけで記録が残っていないケースが多くあります。窓口や電話についても対応記録を残すなど、組織全体
でナレッジを蓄積できることが望ましいと言えます。
利用者からの問合せがあった都度、問合せ管理台帳のようなドキュメントに記録を行います。問合せ管理台帳は、表計算ソフトで作成することもできますし、問合せの種類や件数が多い場合は専用のツールやシステムを活用することも

-

20 -

（第３編第４章 サービス・業務企画）

あります。
コールセンターやヘルプデスクへの問合せ
外部委託でコールセンターやヘルプデスクを開設している場合は、委託先の事業者が問合せ内容や対応履歴等を詳細に記録していることが一般的です。
ただ、せっかくこれらの情報を蓄積していても、この情報を見るのが一部の職員に限られていて、サービス・業務企画時に活かされないというケースもあります。また、管理対象となる件数が多いため、適切に分類を行わないと重要な課題が埋もれてしまうことにもなりかねません。このことに注意しながら、管理方法
自体も継続的に見直しを行うことが望ましいです。
情報システムへの要望やインシデント
外部委託で情報システムの運用を実施している場合は、利用者からの情報システムに対する要望や、情報システム起因の課題（エラーの発生等）が、通常業務の中でも報告されやすく、情報として管理されていることが一般的です。
ただし、上記と同様に管理対象となる件数が多いので、適切な分類を含めて、管理方法自体も継続的に見直すことが望ましいです。

なお、後段で説明しますが、これらの問合せ内容については根本原因が同じになる粒度まで分類を行っておくことで、サービス・業務改革のためのポイントを数多く把握できるよ
うになります。

２

実績データを分析する【標準ガイドライン関連箇所：第３編第４章第２節】

業務の現状を把握する方法は、現場へ行って人の動きやドキュメント等の実物を見るだけではありません。業務の中で生まれているデータを収集し分析することで、業務の実態をつぶさに可視化することができます。
ただ、実績データを収集することには労力がかかります。そして、やみくもにデータだけを入手しても、その先の分析で困ってしまいます。業務で発生している問題に対する先入観を持つ必要はないのですが、どのようなデータを調べたいかについて基本的な方針を立て、その目的に沿ってデータを収集して分析することが必要です。この作業には、少しコツのようなものが必要です。
以下に、実際に様々なプロジェクトでデータを分析した事例に基づいて、コツとなる部分
を例示します。

平均、合計ではなく、ばらつきを見る
このサービスを利用する人は、何人くらいでしょうか？
このような質問を受ければ、１日平均で 300 人ですとか、１年間の合計で７万人ですとか、平均や合計で答えるのが一般的だと思います。もちろん、平均や合計で表される数値
は、全体的な規模感をざっくりとつかむために大切な数値です。しかし、サービス・業務企
画で調査する内容としては、さらに踏み込みが必要かもしれません。
例えば、１日平均で 300 人なので、余裕を見て 400 人分の対応ができるようにサービ
ス・業務を設計しようと考えることがあるかもしれません。しかし、この考え方は少し安易すぎないでしょうか。なぜなら、平均や合計という代表値の裏に隠された、利用者ごとの違い、求めるニーズの違い、時刻や曜日ごとの違いといった様々な「ばらつき」を無視してしまっているからです。

-

21 -（第３編第４章 サービス・業務企画）

ばらつきを注意深く見ていくと、サービスの中でもよく利用されるものとほとんど利用されないものの差が大きかったり、特定の利用者が何度も繰り返してサービスを利用している傾向が見えたり、時間帯や曜日によって利用方法にピーク特性があったりと、様々な実情が見えてきます。このようなばらつきをうまく捉えることができれば、単純に平均 400 名の対応量を確保するというやり方ではなく、特定の利用者向けの対応を別出ししたり、特定の時期のみに体制を強化したりといった対策を打つことができるようになります。また、ピークを分散させ平準化させることも、有効な手段です。

図 4-4
ばらつきを分析する

このことは、様々な局面で注意してほしいポイントです。手続数、書類数、問合せ件数、業務処理時間といったサービス・業務面でも、アクセス数、画面レスポンス時間、夜間バッ
チ処理時間、障害発生件数といったシステム面でも、そのほかにも費用面、効果面、品質面など様々な指標を扱うときに、「平均」や「合計」といった言葉は頻出します。この言葉に出会ったときは、表面的な平均値や合計値だけを鵜呑みにせず、その陰に隠れているばらつきを捉えられているかどうか確認してみてください。

時間と期間を区別して滞留状況をつかむ
業務フローを可視化すると、様々な問題点が見えてきます。しかし、業務フローだけでは見えない問題があるのも、また事実です。
その１つが、業務のどこで滞留しているかを探ることです。そのためには、業務フローに紐づいた計測ポイントを設定し、業務処理の１件１件の単位で、それぞれの計測ポイントを通過した日時を確認します。
この分析を行うときには、時間（実際の業務処理に必要な時間）と期間（開始から終了ま
での全体の時間）を取り違えないように注意する必要があります。最初の計測ポイントから次の計測ポイントにいくまで５日間かかったとすれば、これは「期間」の考え方です。でも、その５日間の間で、実際に確認や審査等の実業務に要したのは僅か 30 分だったかもしれません。これが「時間」の考え方です。時間と期間を区別して捉えることで、実際の業務処理に必要な時間と、単に処理待ちで放置されていた時間を明確にすることができます。
このような分析を行うと、業務処理の中のボトルネックを可視化することができます。可視

-

22 -

（第３編第４章 サービス・業務企画）化ができれば、大きなボトルネックが発生している箇所について、その原因を確かめてみましょう。現場にヒアリングに行く際も、何も準備をせずにヒアリングへ行くと一般的な回答しか返ってきませんが、実データで特定部分にボトルネックが発生していることを示した上でその時に何が発生していたかを確認するようにすると、具体的で本質的な回答を得ることができます。

事例：１件１件の業務処理の滞留状況を可視化（ヘビ図）
ある内部的な精算業務において、精算が完了するまでの期間が長いことが積年の問題になっていました。過去にも様々な問題提起がなされ、精算期間の目標日数を定めるとともに、業務を標準化するためのマニュアル等も整備しました。
その後、精算業務の開始から終了までの「平均」期間について測定を行っていましたが、状況はあまり改善しておらず、日数を集計して平均しただけの情報では、どこに原因があるのか見当がつきませんでした。そして、このように状況が改善しない
理由としては、「他の業務が忙しい中で、精算業務は後回しになってしまう」、「最後は、担当者のやる気の問題」といったように、受け止められていました。
この状況に対して、まずは実際の決裁での滞留状況を可視化してみようということで検討活動がスタートしました。この精算業務では、複数の決裁者が内容の確認を行っているので、決裁者が確認を行い次の決裁者へ送るタイミングを計測ポイントとして、精算案件の１つ１つについて精算業務の際に利用するシステムのログを調べてみました。また、表形式でログを並べても滞留状況がわかりにくいので、次のような方法で決裁者ごとの処理期間を時系列に並べて可視化しました。

この表の中では、決裁者が当日中に処理しなかった部分を赤色に着色しています。そして、赤色部分が極端に長くなっている部分を中心に、この記録を示しながら該当する決裁者に長期間かかった理由と当時の状況についてヒアリングを行いました。そして、その結果を「滞留・差戻し理由一覧表」にまとめました。
この分析の結果、様々なことがわかりました。精算時に計算方法が誤っていたり必
要な資料が整っていなかったりすると差し戻し等で時間がかかるのですが、その前提となるルール自体が複雑でわかりにくく、部署間で統一もされていないことがわかりました。また、特定の人に業務が集中し、この精算業務が後回しになる実態も見えました。
実際の問題点がわかれば、その対策を行うことが可能になります。このケースでは、精算に係るルール自体を改めて見直すとともに、必要な資料の漏れを入力時に警告するようにシステムを改修し、精算処理の進捗状況もシステム上で可視化して、業務の集中状況を把握できるようにする等、制度（ルール）面、業務面、システム面
でそれぞれ対策を行うこととしました。
対策実施後も、精算完了までの期間については定期的に分析を行っています。
部署によって差はありますが、全体的には期間が短くなっており、目標としていた日

-

23 -

事例 4-4
１件１件の業務処理の滞留状況を可視化（ヘビ図）

（第３編第４章 サービス・業務企画）

数にほぼ近づいている状況です。
なお、この図については、関係者の間で「ヘビ図」と名前を付けていました。処理状況を示す形が、ヘビのように様々に形を変えながら長く伸びていたためです。
元々はこの精算業務の分析に始まった「ヘビ図」ですが、他のプロジェクトでも応用され、サービス・業務改革（ＢＰＲ）の１つのツールとして使われています。

上記の例は、前の決裁者の処理が終われば次の決裁者へ移るという、基本的に一方向での業務処理でした。
一方で、業務の中には、複数の関係者間で処理が何度も往復するような複雑なものもあります。このような業務について滞留状況の分析を行う際は、次に示すシーケンス図が有効です。

事例：関係者間を往復する複雑な処理状況を可視化（シーケンス図）
ある省で利用者向けに行われているサービスにおいて、利用者の申請を受け付けてから審査結果を返すまでの期間が長い事が問題となっていました。この業務では、利用者が申請書類を提出した後、書類を受け付けた担当者が内容に応じて様々な担当者に受け渡していくものであったため、関係する数多くの担当者のどの作業でどのくらいの時間が掛かっているのかがはっきりしておらず、対策を打つことができていませんでした。
そこで、業務処理の実態を正しく把握するための手段として、シーケンス図を用いて、分析を行うことしました。シーケンス図とは、業務に係る担当者を全て登場させ、担当者自身の作業と、担当者間のやり取りを区別できるように記載したものです。

これらのやり取りをした日時は、システムのログ等には存在しなかったため、関係者間の電子メールや関連書類の記録等を基に洗い出しを進めることにしました。手作業での洗い出しであり全件を対象とした分析は困難であったため、審査期間が長引いている案件を中心に選択的に分析を行いました。
シーケンス図の分析結果を見ると、関係者間で頻繁にやりとりする期間もある一方で、待ちが中心となる期間も存在することがわかりました。頻繁にやり取りする期間については、なぜ何度も状況確認を行う必要があったのか、その都度ごとの確認内容
や質問内容を確認し、審査の途中ではなく最初から必要な情報を得ることができな
かったか等について検討を行いました。また、待ちが中心になる期間についても、待ちが発生している理由等を調査しました。

-

24 -

事例 4-5
関係者間を往復する複雑な処理
状況を可視化（シーケンス図）

（第３編第４章 サービス・業務企画）

このように、シーケンス図を作成することによって、何に時間がかかっているかという全体的な問題構造を可視化することができ、関係者間でその内容を共有した上で、問題分析に当たることが可能となりました。

業務量のピークを捉え、ピークの発生原因を把握する
業務フローだけでは見えてこないものは、ほかにもあります。それは、業務処理量です。
業務フローだけを眺めると、毎日、決まりに従ってスムーズに業務が流れていくように錯覚しがちですが、実際の業務では日々の業務量が大きく異なるので、繁忙期には処理が停滞しがちです。業務量に応じて、処理の方法まで変わることもあります。
このため、業務量の変化を捉えた上で、特にピークが発生するポイントを把握することが重要です。ピークが発生する例としては、年度末等の申請時期の区切りの直前、長期連休
明けの営業日の午前中等が典型的ですが、業務の特性で様々な時期、時刻にピークが存在します。まずは、このようなピークがどこに発生しているかを把握しましょう。
業務のピークについては、サービス利用者側の要因で発生するものであり、サービス提供者側の工夫でピークを抑えることは難しいと考えてしまいがちです。しかし、まずは工夫
できる余地があるかどうかを検討するためにも、ピークの時に実際に何が起きているかを調べてみましょう。どのような利用者がどのような目的でその時期に利用せざるを得ないのか、実際に発生している事象を確認すると、ピークが発生している理由を理解することができます。
ひょっとすると、とてもつまらない理由でピーク時期に余計な負荷がかかっているかもしれません。そういった一例を、参考として示します。

事例：利用ピークの分析を活かして電子申請利用率を向上あるプロジェクトでは、ある免許の定期的な更新について、書面で行う方法だけでなく、電子申請でも行えるようにサービスを提供していました。この免許は、数年に１度の頻度で更新が必要であり、更新期限の３カ月前までに手続を終えることを規則で定めていました。
実際に電子申請のサービスを始めていくと、申請期限間際にサービスの利用が集中してしまうことが明らかになりました。そこで、その集中時における利用者のサービ
ス利用状況等を調べてみました。
すると、少し不思議なことが判明しました。正常に更新申請を行っている利用者以
外に、パスワードの再発行申請やログイン自体を諦めている利用者が、比較的多い
割合で存在していました。この時期の申請内容を確認したところ、以前に電子申請を使った経験のある利用者が、また書類申請に戻っているケースが一定数存在していたのです。一度、電子申請を経験すれば、次回も電子申請を使った方が効率的なはずなので、この理由は調べてみる必要があります。
色々と周辺状況を調べてみた結果、これらの利用者はパスワードを忘れている可能性が高いことがわかり、サービス利用状況の分析結果と一致しました。更新手続は数年に１度しか利用しないので、電子申請を行おうとした際にＩＤやパスワード等がわ
からず、パスワードの再発行を待っていると申請期限である３か月前を超えてしまうた
め、やむなく書面での手続を行っているということでした。

-

25 -

事例 4-6
利用ピークの分析を活かして電子申請利用率を向上

（第３編第４章 サービス・業務企画）

このようなケースが多くなると、せっかく整備した電子申請の利用が進みません。
様々な検討の結果、規則自体を改正し、書類申請の期限は変更しない一方で、電子申請サービスの申請期限のみを１か月前まで延長するようにしました。
これにより、書類申請期限と電子申請期限に差ができ、業務上の利用ピークが分散されるとともに、パスワード忘れによる再発行が発生したとしても、それを待って電子申請が行えるようになりました。

既存の業務内容そのままに業務量のピークを想定とすると、業務に必要な職員体制を見直すことも難しいですし、情報システムの処理能力も大きなものが必要となってしまいます。当然ながら、情報システムのコストも上がってしまいます。
特にピーク時と平常時の業務量の差が極端に大きい場合は、ピーク自体を分散化させることを検討したいですね。そのためにも、いつピークが発生しているか、そのピークに何が起きているのか、よく調べてみると改善のヒントをつかまえることができます。
業務のピークが、利用者の行動の締切り直前の集中にある場合は、利用者を締切り以前から行動するように誘導することや、利用者を複数のグループに分けて締切り自体を分散化することを検討します。例えば、公共料金の支払いにおいても、利用者を複数のグループに分けてそれぞれ支払い期限を変えていることが一般的になっています。
なお、業務量のピークを抑えることが根本的に難しい場合においては、システム方式としてクラウドサービスを導入することも有効な選択肢になります。クラウドサービスでは、基本的にリソース（サーバ等の能力）を使用しただけ費用が発生するので、瞬間的なピークにも対応しながら全体的にはコストを抑えるといった使い方が可能になります。

問合せや要望は、根本原因が同じになる粒度まで分類する
サービスを提供していると、様々な問合せ、要望等が寄せられます。ヘルプデスクとして電話で問合せを受けることもあるでしょうし、窓口で利用者から直接問合せを受けることもあ

-

26 -

（第３編第４章 サービス・業務企画）

るでしょう。毎日 10 件の問合せがあったとしても、１か月で 200 件、１年では 2,000 件を超える問合せを受けることになります。
さて、サービス・業務改革を進めるためには、このような問合せの履歴は「宝の山」になります。利用者が何に困っているのか、何を望んでいるのか、そこに利用者のニーズの原石が埋まっているからです。ただ、大きな山なので、なかなか掘り起こすのが大変ですね。年間数千件、場合によっては数万件にもなる問合せの履歴の山から、どのようにして宝となる原石を掘り当てればよいのでしょうか。
そのキーポイントとなるのが、分類です。多くの場合において、サービスの種類別や工程別に分類を行っていると思います。施設予約のサービスであれば、利用者登録、施設予約、抽選、料金支払いといった分類です。また、問合せ内容の原因別という観点もあるかもしれません。施設予約システムの操作方法、システムの動作環境、システムの不具合といった分類です。
しかし、いずれの例も、かなり大括りであることに気づかれたでしょうか。「利用者登録」の「システム操作方法」に関する問合せが今月 20 件あったとします。先月は 30 件でした。確かに合計数値では減少していますが、こういった数値を見て一喜一憂することに意味があるのでしょうか。この 20 件という数字は、内容の全く異なる問合せをその違いを考慮せずに単純に「合計」しています。これでは、どのような事象が利用者から問題にされていて、何を対策すればよいのか、何も探ることができません。
最初に少し手間はかかるのですが、利用者からの問合せが発生した根本原因が同じ所に行きつくまで、詳細に分類することが重要です。根本原因に行きつくまで分類を行った
一例を、以下の参考に示しました。

事例：根本原因が特定できるまで詳細な分類を行う
あるプロジェクトでは、ある資格の更新等を Web サイトで行える電子申請サービスを提供しています。しかし、申請の手順や操作方法等についてヘルプデスクへの問
い合わせが多く、利便性が高いサービスとは言えない状態になっていました。
これまでも、ヘルプデスクに問合せ対応履歴を登録する際には、問合せ対象となった機能、問合せの原因等である程度の分類は行っていました。しかし、実際に問合せの内容として登録されている文章を読んでみると、同じ分類とされているグループの中にも、全く異なる内容が多く含まれていることがわかりました。一方で、いくつかの内容を読んでいくと、問合せの中に頻発する「キーワード」があることがわかりました。そこで、頻発するキーワードを頼りにしながら分類の詳細化を進め、問合せの根本原因が同じ粒度になるまで分類を行っていきました。
例えば、頻発するキーワードの１つに「ポップアップ」という言葉がありました。ポップアップとは、Web ブラウザで画面遷移する際に新しく小さな子画面（ウインドウ）を出すことを指しているのですが、その子画面が出るはずのところで画面が出現しない（ブロックされる）という問合せのようでした。そこで、このキーワードが含まれる問合せを洗い出した上で、詳細な原因別に分類しました。いくつかの原因があったのですが、最も多かったのがブラウザの設定等でポップアップ画面を出すことを妨げていたので、設定を変える必要があるというものでした。
このように、内容がわかってしまえば対策が簡単な問題が多いのですが、利用者にとってはこのような問題が１つでも発生すると利便性が大きく低下してしまいます。
この例では Web サイトのＦＡＱ等のわかりやすい場所にポップアップに関する注意を載せるなど、問合せ内容の分析結果に応じて各種の対応を行いました。

-

27 -

事例 4-7
根本原因が特定できるまで詳細な分類を行う（第３編第４章 サービス・業務企画）

同じ原因別に分類することができれば、その発生傾向を分析することができます。
例えば、参考に記載した例では、ＦＡＱにわかりやすく注意を載せる等の対策を打ちました。この対策に効果があったかどうかは、対策を打つ前後で同じ分類の問合せの件数を見るとわかります。対策を打った後でこの問合せが大幅に減ったのであれば効果があったと言えますし、対策を打った後もこの問合せの件数がほとんど減らなかったのであれば、何か別の対策を打つ必要があるということです。
このような詳細な分類を行うことは、確かに手間がかかります。ただ、全体的な分類を一度見直すことができれば、その後に発生する問合せに対しても発生の都度正しく分類しや
すくなります。そして、何より利用者が感じている小さな不満から大きな苦情までを捉えることができ、同じ原因別での問合せ発生数を時系列で把握できるという点で、業務・サービス改革のために非常に有効な分析が行えます。
もし、利用者からの問合せのデータが大括りのままに眠っているとすれば、一度、職員の中で分析チームを作って分類を進めることにトライしてみてはどうでしょうか。

３

業務を可視化する【標準ガイドライン関連箇所：第３編第４章第２節】

業務を観察した結果、実績データを分析した結果は、様々な観点からまとめられた大量のドキュメント群となることがあります。分析を実施した当事者はこれらの内容をよく理解ができますが、これらの資料を初めて読む人にとっては、ポイントをつかむことが難しいでしょう。
業務の分析結果は、プロジェクト内部の職員（ＰＪＭＯ職員）、プロジェクト外部の利用者や関係者、システムを整備する際のシステム開発事業者等、様々な立場の人がその内容を確認する必要があります。これらの関係者に対して的確に業務の状況を伝えるためには、業務フロー等、業務を誰にとってもわかりやすく可視化した資料を作成することが重要です。

様々な立場の人が理解できる業務フローを作成する
業務フローは、現在行っている業務を「誰が（どの組織が）」「いつ」「何を」「どの順番で」実施しているか、「どの範囲が情報システム化されているか」を可視化するものです。対策の検討や企画後の業務内容の変化箇所を特定するためにも有効です。
業務フローには、現行（AsIs）と将来（ToBe）がありますが、ここで作成するのはまず現行の業務フローです。
業務フローの書き方については、様々な表記方法があります。基本的には、関係者にと

-

28 -

注記
AsIs とは、「現状」の意。「将来あるべき」の ToBe とセットでよく使われる。

（第３編第４章 サービス・業務企画）ってわかりやすい表記であれば、どのような表記方法でも十分です。縦に流れるフローでも、横に流れるフローでも、どちらでも構いません。

図 4-5
業務フロー（現行）の定義例

なお、将来（ToBe）の業務フローについては、「Step.5-2-E. 将来の業務フローには、効果を紐づける」で後述します。
業務フローの表記方法には様々な手法がありますが、次のようなことに留意すると関係者が理解しやすいものとなります。

業務フロー作成時の留意点
業務を実施する主体ごとに表記を分ける業務を実施する主体を分けないと、誰が実施している作業なのか区別がつか
なくなります。実施主体ごとに「レーン」を作成し、発生する業務をプロットします。
業務単位を軸に体系化する
業務フローは、大きくなりすぎると読みにくくなるため、一定の業務単位にサブフローとして１つのフローを作成します。業務の単位は、業務一覧の階層と合わせることで整合性がとりやすくなります。
システムを利用して行う業務を明確にする
業務フローの中には、人が手作業等で実施する業務と、システムを利用する業務が入り混じります。システムを利用する業務については、色を変えたり、枠
囲みによって利用するシステムを表したりすることで、区別できるようにします。
帳票やデータの受け渡し内容を明確にする
やりとりする帳票やデータ等の起点と終点を明らかにするとともに、その内容（特にインプットとアウトプット）を明確にします。なお、インプットとアウトプットに関する情報は、帳票名やデータ名に留め、詳細な項目は後述の業務記述書
や業務ルールに記載し、業務フロー上で詳細になりすぎないように注意しま
す。

-

29 -

（第３編第４章 サービス・業務企画）

業務の流れ方を一方向にする
横書きであれば左から右、縦書きであれば上から下の基本的な流れに沿って業務をプロットします。基本的な流れに沿わない業務の進み方が多くなると、
理解しにくくなってしまいます。
中心となる業務について記載する
実際の業務の中では様々な例外処理が発生しますが、それらを全て記載する
業務フローが複雑になりすぎて理解できなくなります。中心となる業務について記載し、例外等については後述の業務記述書や業務ルールとして別に書き出した方がわかりやすくなります。
業務のばらつきに留意する
業務フローを書くと全ての業務がこの標準的な業務フローで動いているかのよ
うに錯覚してしまうことがあります。実際には各拠点、各組織でそれぞれ工夫を行ったり独自の背景があったりするため、様々な業務のバリエーションが存在することが多くあります。確かに、これらのバリエーションを全て業務フローとして可視化するのは煩雑です。しかし、業務のばらつきが存在することについて
現地調査や担当者へのヒアリングを通じて十分に把握して、それらの業務も標準化するのか、又は複数の業務実施パターンを許容した上でシステムも各業
務パターンへの個別対応を行うのかについて、業務要件作成時に方針を定めることが重要です。
前述の業務フローのイメージは、一般的なＰＣのプレゼンテーション・ソフトウェア等で作成することをイメージしたものです。なお、業務フローを効率的に作成するためのツールも多種存在しているので、必要に応じてそのようなツールを整備することも検討してください。
また、業務フローの表記についての国際的な標準として、ＢＰＭＮ（Business Process
Model Notation：ビジネスプロセスモデリング表記法）があります。業務フローを作成するツールの多くは、このＢＰＭＮに準拠した表記を行うことができます。

図 4-6
ＢＰＭＮ表記で書いた業務フロー
図

業務ルールや業務実施方法をまとめる
業務を可視化した文書は、関係者がサービス・業務や情報システムの目指すべき姿を共

-

30 -

（第３編第４章 サービス・業務企画）有するものであるため、誤った定義や曖昧な定義が行われると、後続の工程に重大な影響を与えます。
そのため、業務を可視化した文書を作成する際には、次に示す点を参考に、正確で一貫性のある記載となるようにしましょう。
曖昧な用語や一般的な意味と異なる使い方をしている用語等は、プロジェクト
関係者間の認識そごを防止するため、用語の定義及び機能を定義する粒度や深さについて統一する。
サービス・業務企画内容の検討における作業のしやすさを考慮して、業務単位や区分、順番等を整理する。

事例：業務は複数の切り口で表現すると漏れなく可視化できる

事例 4-8
業務は複数の切り口で表現すると漏れなく可視化できるある省の大規模な業務システムの刷新プロジェクトにおいて、システムリリース後の業務要件を漏れなく調達仕様書で示すために、従来の業務要件定義のやり方を改め、より要件を漏れなく記述し、可視化する資料を作成する取り組みを行いました。
対象となる業務は、業務実施部門職員向けの特定業務に特化したマニュアルしか存在しておらず、網羅的かつ業務知識のない第三者でも理解できるような内容の資料とはなっていませんでした。
このため、業務を「流れ、判断、内容」の３つの視点から表現し、業務を可視化する
ドキュメントとして業務フロー、ディシジョンテーブル（条件分岐表）、業務説明書を作成することとしました。（下図（「業務可視化資料の作成について」（特許庁ＰＭＯ 平
成 27 年５月 18 日）を参照））

これらドキュメントを用いて、プロジェクト関係者間（業務実施部門、情報システム
部門、外部事業者）の課題認識の共有や、開発工程の効率化、開発範囲に対する設計の網羅性確認に活用することができました。
さらに、各ドキュメントを組み合わせて、記述内容をチェックすることで、要件の抜け漏れを防ぐことができました。

入出力情報や管理対象情報をまとめる
-

31 -

注記
「業務可視化資料の作成について」（特許庁ＰＭＯ 平成 27 年５月 18 日）（第３編第４章 サービス・業務企画）

業務を構成する要素には、業務フローに代表される「プロセス」だけでなく、「情報、デー
タ」があります。「プロセス」が業務の動的な側面（流れ、動き）を表すのに対し、「情報、デー
タ」は業務の静的な側面（常に成り立つ相互の関係と、ある時点での状態）を表すといった特徴があり、いずれも業務（システム）を定義するために欠かせない要素となります。
「情報、データ」の現状を把握するには、「入出力情報及び取扱量」及び「管理対象情報一
覧」をまとめます。
「入出力情報」と「管理対象情報」の違いは、「入出力情報」が画面、帳票、CSV 形式の一
時ファイルなど、実際の業務でやり取りする単位の情報であるのに対し、「管理対象情報」はそれらの要素を管理しやすい単位に分解、集約した情報（将来のデータベースの元情報）となります。
一般的な「管理対象情報」の抽出方法は以下のとおりになります。（）内は、別紙「業務要件定義書テンプレート例」における図書貸し出しシステムの事例です。
①「入出力情報」の項目を同じ単位の情報に分解する
ある入出力情報に記載されている項目を分析し、同じ単位で括れるものを抽出する。（例えば、「貸出申請書」の項目を、「書籍」「利用者」など単位が異なるものに分解する。）②「入出力情報」自体も、１つの「管理対象情報」として抽出する
入出力情報自身も、その事象自体を管理する場合は、管理対象情報となる。
（例えば、「貸出申請書」という入出力情報について、一枚ごとの「貸出申請」という事象は業務上で通常は管理するものであり、管理対象情報になる。一方
で、「貸出状況照会履歴」のように、貸出状況の照会を誰がいつ実施したかという情報までを業務上管理する必要がないのであれば、管理対象情報とする必要はない。）③

抽出した管理対象情報のうち、親子関係があるものをさらに分解する抽出した管理対象情報の中で、合計と内訳のように親子関係を持っているもの
で、親子別々に管理する必要があるものは、別の管理対象情報とする。（例えば、上記の「書籍」をその本の基本情報（タイトルや著者など）と、実体（本一冊ずつ）が持つ情報に分け、前者を「書籍情報」、後者を「書籍」と名づける。）例
えば、貸出用に同じ本が３冊ある場合は「書籍」としては３つの実体があり、そのタイトルや著者などの「書籍情報」としては１つとなる。

② 入出力情報自身① 単位が異なる
情報に分解

管理対象情報の抽出

貸出申請
担当
職員

貸出物
書籍

貸出先
利用者

③ 親子関係
に分解
書籍情報

個人

法人

既にシステム化されている業務においては、データベースの情報を参考に「管理対象情報」を作成することもできますが、ここでは、あくまでも業務視点で管理すべき情報を洗い出すようにしてください。（システムの都合で作られたデータや、業務のデータであっても管理単位
や属性の持ち方がシステム処理上の都合によって変更されているものは「管理対象情報」としては使わないでください。）

-

32 -

図 4-7
管理対象情報の抽出

（第３編第４章 サービス・業務企画）

様式例：現状分析結果報告書のひな形
現状分析結果報告書のひな形を本章別紙としてまとめています。システムを新規構築時に作成し、改修・更改時に更新しましょう。

-

33 -

様式例 4-1
現状分析結果報告書のひな形

（第３編第４章 サービス・業務企画）

Step.

5 サービス・業務企画内容の検討

Step.４は、Step.３で可視化された現状の業務・システムに関する調査結果を基に、そこに存在する課題を分析し、新しい業務・システムの方向性を検討します。
Step.３でも書きましたが、現状の業務・システムの調査結果が、次の業務・システムの形（企画方針）を決める重要なインプットとなります。

１

課題を整理し、分析する【標準ガイドライン関連箇所：第３編第４章第３節 1)】

ここまでで集めた課題は、多岐にわたり大量なものとなっています。この中には、システムの操作がわかりにくいといったレベルの問題から、利用者にとって深刻なサービス低下を招きかねない課題もあり、同等には取り扱えません。目立つ課題が、必ずしも最優先で解決しなければいけないもの、とは言い切れないことが多いのです。
これらの課題を仕分けし、課題の関係性を明らかにしつつ、本質的な原因を探るための手法・ポイントについて、見ていきましょう。

優先順位・影響度・費用対効果による分析
課題を原因ごとにグルーピングした後は、それらの課題を利用者への影響度や費用対効果を基に優先順位付けし、主要課題を抽出していきます。
これらの関係性は以下のようになります。

図 4-8
目標、個別の分析、課題の関係

優先順位付け時に気をつける点
利用者への価値最大化、及び、プロジェクト目標に対して影響度が高い課題を

-

34 -

（第３編第４章 サービス・業務企画）

優先的に検討する。
対策の優先順位を検討する際は、影響度を鑑みて、費用対効果が高い対策を優先的に行う。

参考：３Ｅの観点を踏まえた費用対効果の検討
標準ガイドラインでは、費用対効果の確認観点として、経済性、効率性及び有効性を例示しています。これらの観点は、会計検査院の検査でも用いられており、それぞれの英語の頭文字が「Ｅ」であることから、総称して「３Ｅ検査」と呼ばれています。
会計検査院で定義されている３E とは、以下の観点のことです。費用対効果が得られるか判断するためにも、３E の観点で検討することが望ましいです。
経済性（Economy）の観点：
事務・事業の遂行及び予算の執行が、より少ない費用で実施できないかといった観点。
効率性（Efficiency）の観点：
業務の実施に際し、同じ費用でより大きな成果が得られないか、あるいは費用との対比で最大限の成果を得ているかといった観点。
有効性（Effectiveness）の観点：
事務・事業の遂行及び予算の執行の結果が、所期の目的を達成しているか、また、効果を上げているかといった観点。
３Ｅはそれぞれ独立した要素ではなく、以下のイメージのように、重なり合う形で関連しています。したがって、費用対効果の確認観点が、３E のいずれか一つのみに該当するとは限らない点に注意が必要です。
また、経済性のみを優先して有効性を損なうなどといったことがないよう、３Ｅのバランスを考えることも重要です。

プロジェクトの費用対効果を、３Ｅの観点でどのように確認すればよいか、以下に具体例をあげます。これを参考に、あなたの関与しているプロジェクトではどのような観点で確認すべきか考えてみてください。
経済性
情報システムの整備に当たり、オンプレミス環境に構築しようとしているプロジェクトについて、クラウド環境に構築することで、より少ない費用で構築することができないか確認する。
効率性
全国の拠点へ業務端末を同じ台数ずつ設置しようとしているプロジェクトについて、全体として同じ台数であっても、より高い効果を得られないか、以下のような観点

-

35 -

参考 4-3
３Ｅの観点を踏まえた費用対効果の検討

（第３編第４章 サービス・業務企画）

で確認する。
各拠点の業務量に応じて設置する台数を変える。
設置後も利用状況をチェックして利用率が低い拠点から高い拠点へ移設し
たりする。
有効性
情報システムの整備を少ない費用で遂行しようとしているプロジェクトについて、機能が足りておらずプロジェクトの目的を達成できないリスクがないか確認する。

２

企画案を作成する【標準ガイドライン関連箇所：第３編第４章第３節 2)】

現状把握を行う際には、あれこれと頭の中で考えることは後回しにして、まずは実際に発生している事実を詳細に把握することが重要と説明しました。
その現状把握が終わった今、これからはまさに頭を使って、企画案を練り上げるフェーズです。おっと、頭だけではありませんでした。足も使っていろいろな関係者の所へ出向きながら、企画の具体的な内容を調整していきましょう。

全ての関係者に気を配る
企画案を作成する人は、どうしても自分の視野に見える範囲で考えてしまいます。自分の視野、自分の組織だけでなく、サービスを受ける利用者、関係者全体を見渡して、特定の人に不便なことが発生しないように配慮しましょう。例えば、視覚や聴覚等に障害がある
人が情報システムを利用する可能性があるので、サービス・業務の企画の段階からアクセ
シビリティの要件を検討することが挙げられます。
また、特に、企画案の方向性を決めるときには、発言力の強い人や現場経験の長い人の一言に左右されがちですが、客観的な調査の結果に基づき、関係者全体のニーズや困りごとを踏まえて決定することが重要です。

参考 4-4
ウェブアクセシビリティ導入ガイド
ブック（https://www.digital.go.jp/resour
ces/introduction-to-webaccessibility-guidebook/ ）を参照の上、障害があるなど様々な状
況にいる利用者や関係者へ配慮すること。

さらに、サービス・業務で用いる情報システムが、他の情報システムと新しく連携する際
は、連携先に与える影響について企画案を作成する段階から十分に考慮してください。情報共有や影響度の調査が不十分な場合、連携先のサービス・業務に思わぬ改修が必要となり、連携先に多額の変更コストを発生させることがあります。
サービスは様々な関係者によって成り立っています。利用者だけでな く、全ての関係者
についてどのような影響が発生するかを分析し、Ｗｉｎ-Ｗｉｎを目指すことが重要です。

事例：利用者の状況の調査不足でシステム改善が迷惑化
利用者や関係者に十分に気を配れていないと、システムを改善することでかえって迷惑をかけてしまう結果になることがあります。
あるプロジェクトでは、マークシートを用いた申請受付業務を行っていました。ただ、利用者にそれぞれ鉛筆でマークシートを記入してもらうのも手間がかかるため、
マークシートでの受付を廃止し、インターネット経由での電子申請により受付を実現することとしました。
システム改修が終わり、サービスの切替えに伴う過渡期を十分に取らないまま、新しい機能をリリースしたところ、大量に申請を行う事業者からクレームが上がりました。

-

36 -

事例 4-9
利用者の状況の調査不足でシス
テム改善が迷惑化

（第３編第４章 サービス・業務企画）

この事業者は、自社内の情報システムから、既存のマークシート様式に自動出力できる機能を開発済みであり、マークシートであれば効率的に業務を実施することができていました。ところが、今回の電子申請への変更によってマークシートでの受付が廃止されてしまったため、電子申請で１件１件の入力を手作業で行わざるを得なくな
り、業務効率が大幅に悪化してしまったとのことです。
マークシートを用いた申請業務が煩雑で手間がかかるということは、多くの利用者に該当することでしたが、一部の利用者には該当しなかったということです。企画案を作成する段階でこのような利用者の存在に気づけていれば、電子申請の開始後もマークシートでの受付も一定期間継続するなど、利用者の状況に合わせた対応を行うことができます。

利用者の日常体験に溶け込む
利用者の視点で考えると、行政サービスを受けるためだけにわざわざ行動するのは面倒ですね。利用者の日常の行動の中で何かのついでに行政サービスを受けることができると、とても便利になります。
企画案を作成する際には、利用者に新たな手間を増やすという方向でなく、新たに手間を増やさなくても既存の活動の中で完結できる方策を検討してみましょう。

事例：利用者が日常的に使用するソフトウェアからのＡＰＩ申請
電子政府の総合窓口（e-Gov）では、その機能の１つとして自宅や職場のパソコンから行政機関に対する申請・届出等の手続を行うことができます。
従来は、利用者が Web サイトを開いてそこで電子申請を行う方法しか提供していませんでした。そのため、多くの利用者は、日常的に利用している労務会計ソフトウ
ェア等で計算等の業務処理を行った上で、その処理結果を e-Gov の Web サイトに再度入力するという二度手間をかける必要がありました。
この二度手間をなくすために検討を行った結果、外部連携ＡＰＩを利用したオンラ
イン申請を実現することとしました。ＡＰＩ(Application Programming Interface)とは、複数のアプリケーション等を接続（連携）するために必要なプログラムを定めた規約のことです。この規約に従うように作られたソフトウェアは、e-Gov 電子申請システムと申請データのやり取りを直接行うことができるようになります。
外部連携ＡＰＩを利用したオンライン申請を行うことにより、申請データの作成から、申請、公文書取得までの電子申請に係る全ての機能について、利用者が日常的に利用する労務会計ソフトウェア等で一元的に操作を行えるようになるとともに、進捗管理も簡便に行えるようになり、利用者にとって効率的な申請・届出業務が行えるようになりました。

https://www.e-gov.go.jp/digital-government/api/shinsei.html

-

37 -

事例 4-10
利用者が日常的に使用するソフト
ウェアからのＡＰＩ申請

（第３編第４章 サービス・業務企画）

縦割り組織にやわらかく横串を刺す
他の行政機関や民間企業が担うサービスの利用まで含めて、利用者の行動全体を一連の流れとして考えることの重要性を前段で述べました。このようにエンドツーエンドの視野で分析を行うと、新しい企画案を作成するためには、他の行政組織や民間サービスとの連携が必要となることに気づきます。
さて、ここで大きな分岐点があります。あなたは、どちらの方向性で検討を進めていくでしょうか。
(1) 他組織の所掌範囲に踏み込むことは越権行為になる。他組織へもこれまでの検討
結果の情報提供は行うが、その上で自分自身は自組織の範囲内で検討を進める。
(2) 自らが主体となり他組織を巻き込んで組織横断的な検討組織を立ち上げる。その検討組織で全体的な方向性や各組織の実施事項をまとめる。
残念ながら、実際の検討の現場の中では、(1)に近い発言をする人が目立ちます。もちろん、行政組織の成り立ち上、他組織の所掌範囲に踏み込んで指示をするようなことになれば確かに越権行為と言われかねません。
ただ、他組織の中の職員も、自発的に同じ方向性で検討を進めるようになったのならば、全く問題はありません。そういう状態になるように、周りを巻き込みながら調整を進める
こと、このことこそ縦割り組織の弊害が激しい現状の中で、一番求められている行動です。
言うまでもありませんが、このような調整に高圧的、感情的な発言は全く不要です。また、
書面での一方的な連絡をもって他組織との調整を実施した証跡を作るといった小細工も全く不要です。縦割り組織の中に力ずくで横串を突き刺しても、組織にヒビが入るだけで組織の連携にはつながりません。
まずは、自らが調査、分析してきたこと、そして企画の方向性についてわかりやすく説明する資料を作成した上で、関係する組織の職員とフェースツーフェースで話をする。課題が出れば持ち帰って、また話をする。そうやって関係する組織の職員と方向性が合ってきた段階で、関係者を集めた会議を組織する。そのように、丁寧に時間をかけながら段階的に調整を進めていくというのが、調整巧者の王道であるように思います。

必要に応じて制度自体を見直す
サービス・業務を利用者視点で見直す際に、既存の制度やルールが制約になることがあります。
既存のルールを変えることには、大きな労力を伴います。組織内部で定めたルールであっても、変更する理由を関係者に理解してもらうには時間がかかるでしょう。まして、法律、
政令、省令等の変更が必要とならば、改正に向けた体制を確立することから始めて相当な準備、調整を行うことが必要です。
そういったことが見えているので、多くの人は既存のルールには手をつけないでおこうと考えてしまいます。利用者に回り道のような面倒な手続をさせることで既存のルールを回避したり、利用者が不満に感じていることについてもルールがあるから仕方がないと諦めたりといった事態になりがちです。残念ながら時々耳にしてしまうのが、「私の仕事は定められたルールに則って実施するもの。ルールを決めるのは私の仕事ではない」といった開き直った言葉です。もちろん定められたルールにのっとることは大前提ですが、その業務の中で問題があることを把握したときに、どうすべきかを考えるのか、それとも考えるのを放棄してしまうのか・・・。先ほどの言葉は、後者を選んだ人の自己弁護のための言い訳のように聞こえます。

-

38 -（第３編第４章 サービス・業務企画）「でも、私だけではどうしようもできない」。業務実施部門の一担当者、情報システム部門の一担当者だけでルールを見直すことは確かに困難です。
まずは、問題を可視化することです。利用者に対してどのような不便をかけてしまっているのか、その問題はどれくらいの頻度で発生しているのか、利用者がそのためにどんな苦労をしてしまっているのか、事実に基づいて問題状況を可視化します。現実に発生している問題を端的に可視化することができれば、その資料は関係者の間に自然と伝播していきます。この資料は関係者の注意を引き付け、そして関係者を団結させて、意思決定に至るための重要なツールになります。
そして、問題が関係者で認識された後は、プロジェクトの体制を確立することです。本書の第２章（プロジェクト管理）でも三位一体の体制として、制度所管部門、業務実施部門、
情報システム部門で PJMO の体制をつくることを挙げています。
現実社会において、制度が正しく運用されるようにするところまでが制度所管部門の重要な役割です。これらの部門が一体となり、真に必要性が高いのであれば法律、政令、省令等の変更も含めて対応を行っていくことが、利用者視点でのサービス・業務改革の真骨頂と言えます。

システムを作る前に、業務を標準化するシステムを作った後でよくトラブルになるのが、ローカルルールの存在です。
書類の審査１つをとっても、業務マニュアルに書いている審査手順や審査項目はあくま
で基本形に過ぎず、いろいろな拠点で審査項目を追加したり審査手順すら変更されていたりします。このような状態のままで業務マニュアルを前提にシステムを作っても、うちの現場では使えないといった反発が多発してしまいます。
前段で説明したように、現場へ行き、現場の業務マニュアルや引継書等のドキュメントを入手すると、このようなローカルルールの実態をよく把握することができます。その上で、これらのローカルルールをそのままにするのではなく、業務を標準化することを検討します。
ただし、ここで注意すべきポイントがあります。「標準化」と、かたくなな「一本化」は異なるということです。標準化とは、何が何でも１つに統一することではありません。ローカルルー
ルが発生した背景を調べた上で、それが組織全体に横展開すべき工夫であれば全体ルールに取り込むべきです。しかし、ローカルルールが発生した背景が、その現場でのサービス内容、地域特性、規模特性、利用者特性等、その現場だけの特性に基づくものであれ
ば、それを無理やり全体ルールに合わせるとかえって不都合が発生してしまいます。そのような場合は、全体ルールだけでなく必要に応じた個別ルールも設定するといった複層的な対応を行います。これが、標準化の考え方です。
システム開発の工数、費用を抑制する観点からも、システムを導入する前には業務を標準化することが必要です。ただし、ここで標準化の意味を取り違え、何が何でも統一するという一本化の考えに立ってしまうと、現場に役立つシステムはできません。似て非なる両者の違いに留意して、本当の標準化を目指してください。

将来の業務フローには、効果を紐づける
企画案についてある程度の方向性が見えれば、その案をプロジェクト内外の関係者にわかりやすく説明して、さらに改善点等のフィードバックを受けたいですね。
その際の最も有用なツールが、将来（ToBe）の業務フローです。
前段の作業で、現行（AsIs）の業務フローについては準備ができています。この現行業
務フローをベースにしながら、将来ではどこがどう変わるのか、その変更点を明確にプロットしていきます。システム化により業務効率の向上や負荷が軽減される、システム化により場所的な移動を伴わずに業務ができるようになる、システム化により事前準備していた添付書類が不要になる、このように業務フローの様々なポイントで、変更する点を記載できま

-

39 -

（第３編第４章 サービス・業務企画）

す。
このように将来の業務フローを作成する際には、変更点を淡々と記載するだけではなく、その変更によってどのような効果が生まれるかをわかりやすく記載することをお勧めします。以下のサンプルでは、吹き出しの形式で効果を示しています。このように想定効果を
業務フローに紐づけることによって、効果積算の根拠が明確になるとともに、関係者に対しても目指す姿をわかりやすく共有することができるようになります。

図 4-9
業務フロー(将来)の定義例

精緻に効果を積算し、主要な効果を実感可能なものとする
効果は業務フローに紐づけるとわかりやすくなると説明しました。
では、紐づけられたそれぞれの効果の大小を定量的に示すには、どのような積算を行えばよいでしょうか。
効果算定の基本となるのは、「１件あたりの効果」×「件数」という掛け算です。業務時間の削減効果であれば、「業務１件あたりの削減時間」×「業務件数」や、「職員１人あたりの削減時間」×「職員数」といった掛け算になるでしょう。また、国民の満足度向上など定性的な効果が見込める場合であっても、「満足度調査で大変満足と満足の合計の割合が 8割以上」のように定量的な指標を設定することができます。
具体的に、国民の利便性向上や経済効果が見込まれる場合を考えてみましょう。事業者が製品を販売するために国の認可が必要となる場合のように、国に対する申請自体が事業者の売上や利益に直結する場合には、申請から認可取得までの期間の短縮により、事業者の販売の機会が増え、売上や利益の拡大に繋がります。 このような場合、「情報システムの利用によって短縮された期間に申請者が得られると推測される利益/件」×「情報システムを利用した申請件数」という掛け算により効果を算出できます。
また、別の例として、届出のワンストップ化など、国民及び利用者の負担軽減、又は行政事務の省力化等のように経費の削減を目的とした場合は、「デジタル化による削減効果/
件」×「当該システムを利用した申請件数」という掛け算により効果が算定できます。
ただし、これらの掛け算を安易に実施してしまうと、積算された効果が過大（又は過小）になってしまうことがあるので要注意です。効果を積算する過程では、業務の全件を調査

-

40 -

（第３編第４章 サービス・業務企画）

することは難しいので、サンプリングを行うことが多いでしょう。このとき、母集団を正しく分類しないままサンプリング対象を選ぶと、その調査で得られた効果想定（１件あたりの平均効果）は全体を正しく代表していません。その状態のままで「件数」を掛け算すると、調査で発生した誤差が大きく引き伸ばされることになり、結果として積算された効果が実態と大きくかい離してしまいます。
では、良い例は、どのようなものでしょうか。それは、効果積算に用いる原単位が、全体を正しく代表する単位となっていることです。業務の中で、効果の観点から特徴が大きく異なるグループがあるのであれば、それぞれのグループでサンプリング調査と効果積算を行い、それらの数値を合計することで正しい数値を積算します。
図 4-10
実態をつかむサンプリング調査

このように、サービス・業務の処理単位、実施担当部門、処理する場所等で対象を分類した上で、可能な範囲で詳細な積み上げを行うようにしてください。例えば全国規模で多拠点の業務窓口を持っているところであれば、都市部、地方、山間離島等といったグルー
プに分けて積算することが良いかもしれません。若しくは、利用者向けのサービスメニュー
で分ける方法もあるかもしれません。効果を積算するに当たって、条件がほぼ同じと考えられるグループに分けて、それぞれのグループで調査と積算を行うことが重要なポイントです。詳細な単位で効果を積み上げることによって、実際にサービスを開始した後のモニタリ
ングにおいても、効果の計画と実績の差を精緻に管理することができるようになります。
また、もう１つ重要なことがあります。精緻に効果を積み上げていくと、効果の小さなもの
から大きなものまでが合わさり、複雑な計算過程を経て、第三者にわかりにくくなることがあります。
効果の積算結果を多くの関係者から理解してもらうためには、効果全体の中で特に大きな比率を占める主要部分について、その積算方法をわかりやすく示すとともに、確かにそれだけの効果が出そうであると実感できるような補強材料（別観点からの検証や実例等）を準備することが大事です。例えば、ある地方拠点では利用者が手続をするためだけに週１回、往復３時間をかけて施設へ来所する必要があり大きな負担になっているが、システムを

-

41 -

（第３編第４章 サービス・業務企画）

整備することでそれが不要になるとすれば、利用者にとって大きな効果です。このようなリアルな実態を踏まえた事例を効果積算の説明として加えることで、関係者の理解をより深めることができます。

事例：業務削減効果の積算方法の見直しあるプロジェクトでは内部事務のシステム導入を企画するに当たり、投資対効果を検討するために、導入後の業務削減効果について試算を行いました。
当初はサンプルとしてある組織を対象に調査を行い、大まかな業務単位で一人当たりの業務量を推算し、単純人数比で全組織の業務量として計算、全組織の業務量に一定削減率を乗じて効果を算出しました。その結果、業務に費やす時間は組織全体で約３/４に短縮されると試算されました。（下図）

この情報システムを導入してから数年が経過し、業務削減効果について実態を踏まえた調査を行いました。
最初に組織ごとに異なる業務単位を詳細に把握した上で、組織ごとの件数、回数等を積算し、それらを合算して全組織の業務量として計算し、この情報システム導入
前・導入済組織の実測により業務量を調査し、その差分で効果を算出しました。（下
図）

-

42 -

事例 4-11
業務削減効果の積算方法の見直し（第３編第４章 サービス・業務企画）

また、当初、業務処理時間として積算していた時間の中には、システムに馴染まな
い業務の時間を含めていたことから、その分を差し引くと、業務処理時間は導入前に試算した値から大幅に減少し、それに伴い、業務削減効果も減少しました。その結果、大まかな積算では見えていなかった数字も明確になりました。

オープンにサービスを作る
内部の職員だけで企画案の全てをまとめ上げる必要はありません。むしろ、検討段階か
ら積極的に利用者を巻き込んでオープンにサービスの在り方を議論した方が、内部職員
だけでは気づけない利用者視点でのニーズを拾いやすくなります。
制度変更等も視野に入れた比較的大規模な検討を行う場合は、外部有識者を交えた検討会を開催する形が一般的な進め方です。検討会の資料や議事等を適時に公開することで、検討会の出席者以外にも広く検討状況を共有します。
また、パブリックコメントを実施することも一般的な進め方です。企画案がある程度まとまった段階で企画案を公開し、国民からの意見を募集した上で企画案を再検討します。
ただ、このような検討会やパブリックコメントといった進め方だけでなく、さらに現場に近いレベルで検討の早期段階から利用者の意見を取り入れる方法もあります。
その一例が、ワークショップの開催です。サービスに関係する様々な立場の利用者、関係者を集めて、現状の問題点を共有した上で、今後のサービス改善の方向性等について意見交換を行います。
ワークショップで参加者が意見を出しやすくするためには、ワークショップ開催までの準備も大切です。前述の利用者視点での分析（ペルソナ分析、ジャーニーマップ等）やサー
ビス・業務の基礎的な情報（サービス概要、利用量等）をあらかじめ提示しておけば、基本的な前提を共有した上で現状の問題点等について効率的に意見の整理を行いやすくなります。
また、パブリックコメントといった正式な手続だけでなく、Web サイト等で適時に検討状況を公開している例もあります。検討案が固まりきった段階で初めて内容を公開するのではなく、検討を進める過程の中で段階的に内容を公開することで、検討経緯や方針決定理

-

43 -

（第３編第４章 サービス・業務企画）

由が明確になりますし、利用者や関係者の意見を十分に取り入れることが可能になります。
このようにプロジェクトの状況を公開することは、企画時点だけでなく、システム開発を行っている時や、サービス開始後でも同様に重要になります。特に、国民全般、企業全般、自治体等の関係組織全般に関わるようなプロジェクトについては、プロジェクトの方針、進捗状況、サービス提供状況等について適時に公開するとともに、利用者や関係者の意見を収集できるように考慮してください。

事例：案段階の企画内容を Web サイトで公開
あるプロジェクトでは、国民全般が利用するサービスの改善方法について調査研究を行い、企画案としてまとめた段階でその結果を省の Web サイトで公開しました。
公開した内容は、制度やサービスの変更内容だけでなく、業務の要件がわかるもの（業務要件の一覧や業務フロー図等）、利用するシステムの機能の要件がわかる
もの（機能の一覧や情報システムの構成図等）、非機能の要件がわかるもの等です。

このことによりサービスの利用者の声だけでなく、業務を実施する上での関係組織
やこの情報システムの構築を受託する可能性がある事業者を含めて、幅広い関係者
から意見を集められました。
そして、実際に集まった意見を踏まえて、制度の内容や業務・システムに求められる要件を見直し、更新しました。
また、どのような制度がいつ頃開始するのか、情報システムの構築がいつ頃行われるのかといった情報を関係者に対して早めに周知することができたことで、プロジェクトを円滑に進めることができました。

企画案を客観的に見直してみる
企画案の骨子が固まってきたら、ここで一度、クールダウンしてみることも重要かもしれません。企画を作っている人は、どうしても企画への思い入れが強くなるため、多くの目的を一度に達成しようとしたり、自らの力で全てを作ろうとしたり、少し力みの入ったプランになることがあります。
外部のサービスもうまく取り入れながら、段階的にバランスよくサービスを作り出すために、次のような観点から企画案を眺め直してみて、改善の余地がないか検討してみてくだ

-

44 -

事例 4-12
案段階の企画内容を Web サイト
で公開

（第３編第４章 サービス・業務企画）

さい。

サービスはシンプルにする
複雑なサービスは、利用者が理解できず、サービス利用への大きな障壁になります。既存の制度、ルール、業務分担がある中で新しいサービスを生み出そうとすると、既存の制度等を残存させながら新たなやり方を追加するといった屋上屋（おくじょうおく）を重ねる形になりがちです。前述の「縦割り組織にやわらかく横串を刺す」に記載したことと重複します
が、利用者の視点から極力シンプルにサービスを利用できるように、既存の制度等の見直しも含めて検討してみてください。
特に、利用者に提出や入力を求めるような「手間」が発生することについては、今の企画案で本当に「最小限」になっているか、逆に行政側から提供する情報が過多になっていな
いか、利用者にとって必要性の高い情報をわかりやすく提供できるようになっているかという観点で、確認してください。
また、システムの使い勝手についても同様です。システムを初めて利用する人やＩＴに詳しくない人でも、自力でサービスを利用して完結できる状態が理想的ですね。実際にシステムの画面等を考えるのは設計段階の話になりますが、企画段階においても利用者の操作性について必要な配慮が行われているか、今一度確認しましょう。

デジタル技術を徹底的に活用する
デジタル技術は日々進化しています。今までは手間を掛けなければできなかったことが、デジタル技術を活用することで飛躍的に効率的に実施する可能性があります。
例えば、このようなキーワードに該当する活動がないでしょうか。企画案や業務内容を見直してみて、デジタル技術をもっと活用できる余地がないか検討してみてください。
遠隔地からのモニタリングを人手で実施している→ ＩｏＴ技術、センサー技術等を活用してモニタリングを自動化できないか
熟練者による目視点検で品質や老朽化状況の確認を行っている。
→ ＡＩ、画像解析技術等を活用して、効率的かつ高度な確認が行えないか
申請内容の形式的なチェックを人手で実施している→ ＡＩ等を活用して自動審査できないか
複数のシステムに同じ情報を再入力している→ ＲＰＡ等を活用して、作業を自動化できないか
電話で問合せへの対応業務を行っている→ 定型的な質問へはチャットボット（音声やテキストで自動応答する仕組み）
等で対応できないか
業務やシステムで収集したデータを十分に分析できていない→ データ分析ツール等を使って、サービス改善への基礎分析を行えないか

また、情報セキュリティとプライバシーを確保する観点からも、IT マネジメント全体を通してリスク管理を適切に行い、情報セキュリティ対策を確実に行うデジタル技術の活用が重要ですし、自動運転、ドローン等、高度なデジタル技術を前提とした新しい仕組みも活用できる可能性があるかもしれません。
なお、各府省がデジタル技術を活用することも重要ですが、各府省が保有するデータを

-

45 -

注記
IoT とは、「Internet of Things」の略称。従来のＩＴ関連機器のみならず、家電やセンサーなど、あらゆる物がインターネットにつながる仕組みのこと。

（第３編第４章 サービス・業務企画）

オープンデータとして活用し易い形で公開することによって、国民や民間企業等の外部関係者がデジタル技術を効率的に活用できるようにすることも重要です。このことについては、第５章「要件定義」のデータ・情報に関する事項と併せて十分に検討してください。

情報システムではなくサービスを作る「システムを作ることが目的化する」という言葉がよく聞かれます。利用者が実感できる効果を達成するといった本来目的を達成するための手段としてシステムを作るはずだったのに、いつのまにかシステムさえ作ればよいと、システムの整備完了のみが目的化する状態です。
特にシステム整備の中でＡＩのような最新のデジタル技術を使うときには、注意すべきことのように思われます。前述したように、デジタル技術を徹底的に活用すると大きな効果を得ることができます。しかし、サービス・業務をどのように変えるかという明確な目的がなく、ただＡＩを導入すれば何とかなるだろうといった進め方では、効果がうまく得られません。ＡＩを入れれば業務課題が自動的に解決するわけではなく、ＡＩを適用すべき範囲に正しく導入
してこそ効果を生み出すことができるからです。
むしろ、全ての範囲をシステムが担うのではなく、一部は人手による作業を交えた方が、サービスの品質を上げられることもあります。
システムを作ることも同じです。システムは、あくまで手段です。全てを情報システムで実現するのではなく、必要に応じて人手によるサービス等も組み合わせて、最良のサービスを利用者に提供するという本来の目的を最優先に考えましょう。

自分で作りすぎない
サービスを一から自分で作ることも選択肢ですが、もっと効率的に作る方法はないでしょうか。民間サービスで活用できるものがあれば、そのサービスを活用した方が良いかもしれません。職員採用の Web サイトを立ち上げるなら、民間の人材採用 Web サイトのサービスを利用した方が良いかもしれません。
また、ＡＰＩ連携を使うことも有効です。前述の事例（利用者が日常的に使用するソフトウ
ェアからのＡＰＩ申請）で説明した e-Gov では、利用者が日常的に利用する労務会計ソフト
ウェア等から電子申請が行えるようにしました。これを可能としたのが、ＡＰＩ連携です。
行政自らがサービスを作るだけではなく、過剰な機能や独自技術の活用を避け、多くの人から利用しやすくするように心掛けることが重要です。

外部に丸投げしない
自分で作りすぎないことを前述しました。一方で、自らが責任を持ってプロジェクトを運営することは最も基本的な大前提です。自分で作りすぎないという考え方を言葉尻だけで捉えると、必要な予算だけは確保し、あとは委託事業者や補助金分配先の関係機関が実施すればよいと強弁する人がいるかもしれませんが、これは全く推奨できない進め方です。
あくまで、サービス、業務、システムを作り運営する主体は、プロジェクトの運営を行うＰＪ
ＭＯ自身です。もちろん、全ての作業を職員自らが行う必要はなく、委託事業者との契約や、補助金による関係機関主体での対応を依頼することもできますが、その際においてもプロジェクト全体としての目的達成のために、サービス・業務の改革方針を立て、システム整備の方針を立て、プロジェクトの進捗を管理し、サービス開始後も運営状況を確認し改善を続けていくのはＰＪＭＯ自身です。
そのため、複数の関係機関が連携して対応を行うプロジェクトについては、ＰＪＭＯ自身
がプロジェクトの運営を確実に行えるという観点から、システム整備の形態（分散型、集中型等）、システム整備の進め方（仕様の共通化、スケジュールの全体整合等）を検討するこ

-

46 -

（第３編第４章 サービス・業務企画）とが必要です。

事例：個別管理システムを統合してサービス向上とコスト削減を実現

事例 4-13
個別管理システムを統合してサービス向上とコスト削減を実現

あるプロジェクトでは、全国的に多数存在する関係組織がそれぞれ紙台帳による管理を行っていた情報を電子化してインターネット経由で検索できることを目指して、情報公開システムを開発することとしました。
当初の計画では、プロジェクトの中心となる業務取りまとめ組織（ＰＪＭＯ）から全国の関連組織に補助金を交付し、各々の組織が個別に情報システムを構築することを予定していました。
しかし、この計画のままプロジェクトを進めると、関係組織ごとに異なるシステムが存在するため、利用者は欲しい情報を一元的に検索することができません。
また、システムの操作方法等も異なってしまうなど、利便性の観点から問題がありそうでした。また、関係組織がそれぞれ独自にシステムを整備するため必要となるコ
ストが増大することも懸念されました。
さらに、このような関係組織が個別にシステムを整備する形態とすると、システムの内容や提供するサービスが各組織でそれぞれに決定されるため、業務とりまとめ組
織であるＰＪＭＯが全体管理を十分に行うことができないことも懸念されました。

そこで、この業務に求められる要件を満たした上で、利用者視点の要件を実現するために再検討を行いました。その結果、この情報公開システムはクラウドサービスを利用して開発することとし、関係組織が必要な情報を登録する形態とすることで、１つの統合システムで全国の情報を一元的に管理することとしました。

このような見直しを行ったことで、この情報公開システムでは正確で豊富な情報を全国一元的に検索することが可能となり、統一したユーザインタフェースにより使い

-

47 -

注記
ユーザインタフェースとは、ユー
ザから見た「見た目」。アプリケー
ションの画面デザイン（色、情報の配置、操作ボタンの位置等）のこと。ＵＩとも呼ばれる。

（第３編第４章 サービス・業務企画）

勝手も向上した結果、稼働開始直後から多くの利用者が利用することとなりました。
さらに、法令・制度が改正された際のシステム改修コストの抑制、運用保守コストの抑制にも寄与することとなりました。

-

48 -

（第３編第４章 サービス・業務企画）

Step.

6 軌道修正プロジェクトを立ち上げた際に目標や実施方針を定めていますが、サービス・業務企画を詳細に進める中で、当初は見えていなかった様々な課題や制約条件等が明らかになるはずです。当初に考えていた進め方よりもっと良い進め方があれば、目標自体や実施方針を見直し軌道修正を行うことが重要です。
この Step では、そのような軌道修正について解説していきます。

１

軌道修正しやすい進め方にする【標準ガイドライン関連箇所：第３編第４章第４節】

プロジェクトの目標は同じでも、その進め方によって成否は大きく異なります。
後から何度でも軌道修正を行いやすいようにするには、一度に全てを作り上げるのではな
く、段階的にサービスを導入しながら細かく変更を行っていく進め方を採ることが望ましいと言えます。

一遍にやらず、一貫してやる
今までにないサービスを始めたり、既存のサービスを大きく変えたりするような難しいプロ
ジェクトほど、全てを一度に実施するべきではありません。このような「一遍」に新しいやり方に変える進め方は、利用者のニーズに十分に応えることが難しいためです。
民間企業で製品開発を行うときは、必ず試作を行い、機能、品質、費用等の様々な要素から検証を行い、修正を何度も行いながら、最終的に製品として成功できると実感を持てるものを製品化します。
プロジェクトも全く同じです。開発段階でプロトタイプを作って利用者によるテストを行ったり、本番運用も一度に行うのではなく一部の利用者を対象に実証実験を行ってから本格的に展開するなど段階的に整備することによって、利用者の声を取り入れながら軌道修正を積み重ねることができます。これが、「一貫」した進め方です。

２

柔軟に軌道修正する【標準ガイドライン関連箇所：第３編第４章第４節】

軌道修正しやすい進め方を採用したとしても、やはり軌道修正をすることに躊躇してしまう
ことは理解できます。しかし、軌道修正すべきタイミングで軌道修正しなければ、その後プロジ
ェクトは十分な効果を達成できなくなります。
次に、実際に軌道修正を行う際の考え方を解説します。

何度も繰り返す行政の無謬性（むびゅうせい）という言葉があります。行政は絶対に間違いを起こさないという考え方です。この前提に立ってしまうと、仮にプロジェクトを進める中で修正すべき点に気づいても、修正を行うと過去の判断が間違いであることを認める形となってしまうため、修正することができないといった事態に陥ってしまいます。
行政は無謬ではありません。プロジェクトも無謬ではありません。限られた人数、時間制

-

49 -

（第３編第４章 サービス・業務企画）

約の中で、もちろん可能な限り現状把握や分析を通してサービス・業務の企画を行います
が、実際の企画を実現に移す段階で修正すべき点が発生してくるのはむしろ当然のことです。修正すべき点が全く出てこないとしたら、恐らく修正意見の聞き方を間違えていると考えた方が良いでしょう。軌道修正を躊躇し、初期の決定に固執してプロジェクトを進めると、利用者がほとんどいないサービス・業務が出来上がり、運用保守経費だけが毎年計上されるような悲惨な事態を引き起こしかねません。
このような考え方を前提においた上で、プロジェクト初期に想定したサービス・業務企画の前提となる課題や仮説が、現状調査の結果と異なっていたことが判明したときは、プロジ
ェクト計画全体の軌道修正を検討しましょう。 試行的にサービスの提供や業務を実施し、利用者や関係者からのフィードバックを踏まえてサービスの見直しを行うなど、何度も確認と改善 のプロセスを繰り返しながら品質を向上させることが重要になるからです。
この考え方は、サービス開始後も全く同じです。継続的に利用者や関係者からの意見を収集し、常に改善を図っていきましょう。
考え方のわかりやすい目安としては、「60 点を目指す」ということかもしれません。最初から 100 点満点のサービスが提供できればよいですが、なかなかそうはなりません。まずは
60 点のサービスを提供することに注力します。60 点のサービスが提供できれば、次に残りの 40 点に対しても改善を検討します。残りの部分についてさらに 60 点の改善を行えば全体で 84 点になります。もう一度改善を行えば 93.6 点となります。
それぞれの活動の目標は 60 点であっても、それを繰り返すことで高得点となります。ポイントは、改善のサイクルを早くすることです。まずはチャレンジし、次々に改善をしていくという姿勢を貫くことが、結果的には成功への早道です。
このような考え方に基づいて、サービス・業務企画の内容に軌道修正が必要かどうか、事実を積み上げて得られた内容に基づいて冷静に判断してください。

実施手順
当初想定した内容と把握した事実との差異を客観的に分析し、軌道修正が必要な対象を明らかにする。
軌道修正の方向性を、対象ごとに適切な関係者と検討する。
検討した軌道修正の方向性をとりまとめ総合的に判断した上で、プロジェクト全体としての修正方針を検討する。

事例：一部地域で試行してから、サービスを全国へ展開ある省では、対象者が全国規模となる調査業務を実施していました。
この業務では、回答率の向上と、大量データの集計作業を軽減することが重要な目標でした。そこで、調査回答を従来の紙様式だけでなく、オンラインでも受け付けられるようにするシステムを整備することとしました。調査対象者がデータを入力する手段については、パソコン用の Web サイトだけでなくスマートフォン用の Web サイトも用意し、極力簡単に登録が行えるように工夫を行いました。

-

50 -

事例 4-14
一部地域で試行してから、サービスを全国へ展開（第３編第４章 サービス・業務企画）

ただし、このオンライン回答については、全国で一斉にサービスを開始するのではなく、まずは一部の地域のみで先行的にサービスを開始することとしました。
試行的に実施を行うと、このサービス自体が回答率の向上と集計作業の軽減という目標にどの程度貢献できるかを、しっかり見定めることができます。また、施行実施の中で、どれほどの人数がオンラインでの回答を行ったかという実績値を取得することができるため、サービスを全国展開した際にシステムに必要となる能力を適切に見積もることもできます。
一部地域での試行の結果、当初の見込みどおりにパソコンとスマートフォンの両方から十分な数のオンライン回答があったことから、その後の調査では機能の拡充
やインフラの整備を行った上で、このサービスを全国に展開することとしました。

全国展開を行った結果、オンライン回答の割合は、当初見込んでいた予想を大きく上回り、約４割となりました。オンラインを利用した回答率が上がったことで、集計作業が軽減され、集計作業に要する時間を約３割削減することもできました。また、調査結果を今までより早く公開することも可能となりました。

無理に継続しない
軌道修正の考え方の延長となりますが、軌道修正だけでなくプロジェクトの継続必要性
自体を判断しなければならない局面もあります。
前述の行政の無謬性の観点からは、プロジェクトを中止することはなかなか判断に迷うことになるでしょう。特に既に予算をつけて契約をしてしまっている段階では、なおさら途中で中止することへの抵抗が大きいこともわかります。

-

51 -

（第３編第４章 サービス・業務企画）

しかし、費用対効果に乏しいと判明したプロジェクトをそのまま継続すると、この先もっと
多くの経費が支出され、ほとんど効果が得られないこととなります。長期的な見地に立てば、いつか「あの時、中止判断をしておくべきであった」と振り返られることになるでしょう。
「後悔先に立たず」です。後から振り返るのではなく、適切な時期に判断を行うことこそ、行
政運営を担う者として最も重要な責務の１つです。
プロジェクトを中止にする理由には、様々なものがあるでしょう。外部環境や内部環境の変化、プロジェクト初期段階の検討不足、プロジェクト進行中に判明した重要課題の存在等です。プロジェクトを中止するためには、関係者にその理由を説明することが不可欠です。プロジェクトの企画運営に携わった当事者として、中止に至った背景や理由については十分に分析を行うとともに、今後同じような失敗を繰り返さないための教訓として整理し、後日参考にできる形にして残しましょう。
プロジェクトを中止するための実務的なプロセスについては、まず、ＰＭＯに相談してください。

判断時の留意点
過去決定した方針を変えるためには、関係者に理解を得るための情報が必要となる。方針を変えずに継続した場合と軌道修正や中止した場合、双方の影響を客観的に整理し、可能な限り数値化する。
特に連携するサービス・業務があるときは、連携先の影響も含めた説明資料を準備することが重要である。
中止判断が遅れるほど、影響は深刻化する。ＰＭＯに相談して早めにアクショ
ンを取ることを心がける。

-

52 -

（第３編第４章 サービス・業務企画）

Step.

7 新しい業務要件の定義

新しい企画方針が出来上がれば、この内容に基づき新しい業務要件を定義します。
現行の業務をベースに変更部分を明らかにしていく、全く新規にサービス・業務を作り上げるなど、様々な状況が考えられますが、いずれの場合も進める際に理解しておくべき手段やノウハウについて、解説していきます。

１

業務要件をまとめる【標準ガイドライン関連箇所：第３編第４章第５節】

新たなサービス・業務企画の方向性が固まってきました。あなたはその内容を正確に第三者に説明できますか？
ここでは、新たなサービス・業務企画の内容を、業務要件という形で要素を分解して、可視化を行います。「要件」という言葉から、情報システム寄りの印象を受けるかもしれませんが、「業務要件」は、業務フローや、業務をいつ、どういう役割の職員が行うのかといった、サービス・業務の姿そのものを整理したものが中心となるため、実際に業務を実施する職員の視点に立たないと定義できません。
車の購入に例えると、業務要件は「アウトドアでキャンプする」「子どもの送り迎えをする」といった具体的な利用シーンを表します。機能要件（要件定義以降で検討）は、「４ＷＤで８人乗れるワンボックス」「チャイルドシートを装着しても、買い物を入れるスペースがとれる軽自動車」となり、それぞれ排気量や搭乗人数等の詳細な仕様を決定していきます。機能要件については自動車ディーラーに相談することができますが、業務要件は車を利用したい当事者でしか定義できません。ここで作成する業務要件も、まさに当事者にしか作成できないものです。
業務要件には、新しい業務実施手順（業務範囲、業務フロー等）、業務の規模、時期・時間、場所、目標として管理すべき指標、システム化の範囲等を記載します。具体的な書き方については、別紙のひな形を参照してください。基本的には、サービス・業務企画で検討してきた様々な分析結果を総合的にまとめた資料となります。
業務要件で作成した資料は、後続工程となる要件定義のインプットとして利用できます。

様式例：業務要件定義書のひな形
業務要件定義書のひな形を本章別紙としてまとめています。

-

53 -

様式例 4-2
業務要件定義書のひな形

（第３編第４章 サービス・業務企画）

２

定義内容を関係者に共有する【標準ガイドライン関連箇所：第３編第４章第６節】

新しいサービス・業務を定義したドキュメントが出来上がることで、関係者にとって理解しやすくなり、これまでは意識していなかった考慮点や抜け漏れが発見できる可能性があります。
そのため、作成した業務要件の定義内容を関係者に確認してもらい、その結果明らかになった変更要望や新たな課題は、ＰＪＭＯ内で対応方針を検討し、業務要件に反映した上で、再度関係者と共有してください。これにより、業務要件をより精緻なものへと更新することができます。
また、関係者に説明することで曖昧な内容や難解な箇所を修正でき、後続工程で事業者を含む第三者が理解しやすい内容になります。

-

54 -

（第３編第４章

サービス・業務企画）【コラム】外部委託事業者の関わり方
サービス・業務企画は、現状の調査から始まり、最終的には業務の要件を定義するまでの作業が含まれます。これらの作業には、多くの作業量が必要となったり、業務分析や情報システムに関する専門的な知識が求められたりします。その際に、これらの作業の一部について
コンサルティング等を専門分野とする事業者に委託することも選択肢の１つです。
ただし、外部委託事業者に作業を丸投げしてはなりません。作業を進める際に、発注者として気をつけるべきポイントについて見ていきましょう。

事業者と役割分担して作業を進める事業者にサービス・業務企画の作業を委託する場合、ＰＪＭＯと事業者とが「協働」して活動を進めていくことが重要です。事業者はサービス・業務企画を行うための知見を持っていますが、業務の実情を詳細に知っているわけではありません。また、ステークホルダーとの調整や作業の方針・内容の決定等、ＰＪＭＯにしかできない作業も数多くあります。
何より、成果物の内容を決定する責任は、ＰＪＭＯにあります。事業者が作成したドキュメ
ントの内容で理解できないものがあれば、ＰＪＭＯから事業者に説明を求めましょう。
また、実際のプロジェクトでは、他の様々な事業者からの協力を得ながら作業を進めることになりますが、構築する過程における認識の相違や後から発覚する制約等によって、本来実現したかった理想と現実とにかい離が発生することが多々あります。
これらを防ぐために、ＰＪＭＯや関係職員がサービス・業務企画の各活動に細かく関与
し、成果物（要件定義書や設計書等）をこまめにレビューしていく必要があります。ただし、
ＰＪＭＯや関係職員のリソースに制限がある場合は、レビュー対象とする成果物や活動への関与を平準化し、一部の成果物や活動に偏らないバランスを取った関与の仕方を工夫す
ることは有効です。
事業者に作業を委託する場合の留意点を以下に記載します。

委託時の留意点
全ての作業を事業者に委ねないよう、役割分担を明確にし、事業者と合意する。
優先順位付けや企画内容の決定等の意思決定は、発注者が責任を持って行う。
事業者とこまめなコミュニケーションをとり、事業者が実施できない作業（ステークホルダーとの調整等）を把握し、実施する。
事業者が作成する成果物をレビューし、不明点があれば事業者に対して説明を求める。

発注者の、要件定義への関わり方
要件定義を行う際は、発注者側が積極的に関わっていく必要があります。業務要件は
情報システム要件のインプットであり、対象システムに関わる全てのステークホルダーとの調整を経て確定するものです。そのため実情を把握していない外部委託事業者に丸投げすることは、論点が曖昧なまま要件が定まったように見える事態を発生させることにつながります。業務要件が定まっていないケースでは何度も情報システム要件に変更や追加が発生し、スケジュールやコストに大きなマイナスが発生します。業務要件がしっかり定まって

-

55 -

（第３編第４章

サービス・業務企画）いるプロジェクトは、それ以上の手戻りが発生しないためスムーズに進行できます。
要件定義を外部委託する際の発注者としての留意点を以下に記載します。

要件定義を外部委託する際の留意点
業務要件定義書は発注者が作るものです。発注者側が積極的に関わる体制を用意するよう意識して下さい。
具体的な役割分担を調達仕様書に記載することが重要です。
例えば、調達時に「支援」という言葉を使ったケースでは、支援の範囲について発注者側と事業者側とで認識に差異が生まれるおそれがあります。ドキュメント
作成の支援であれば、ドキュメントの初案を事業者が作成するのかどうかなど、
作業レベルでの具体的な役割について調達仕様書に明示することが重要です。
要件定義においても、最終成果物を作成することのみにフォーカスするのではなく、重要な論点については複数の実現方式案を作成した上で、各案のメリッ
ト・デメリットを整理することが重要です。このような比較資料についても、専門的知見を持つ事業者から提示を受けることが望ましいといえます。もちろん、最終判断は発注側が行います。

-

56 -

デジタル・ガバメント推進標準ガイドライン

デジタル・ガバメント推進標準ガイドライン
実践ガイドブック（第３編第５章

-

1 -

要件定義）

（第３編第５章 要件定義）

目次
Step.1 要件定義の活動全体の流れ .............................. 5
Step.2 要件定義の事前準備....................................... 7１ 要件定義で職員が得た知識は貴重な財産 ........................................ 7
２ プロジェクト計画や業務要件を把握する ........................................ 8

Step.3 ＲＦＩの実施 ............................................... 9
１ ＲＦＩを理解し、必要な資料を準備する ........................................ 9
A. ＲＦＩの意義と用途を理解する .......................................... 9
B. ＲＦＩに必要な資料を準備する ........................................ 10
２ 公平性等を確保したヒアリングを行う ......................................... 11
３ 収集した情報を基に資料を更新する ............................................ 11
A. ＲＦＩや発注前ヒアリングの結果を整理する ....................... 11
B. 既存の資料を最新化する ................................................ 12

Step.4 要件定義の全体像 ....................................... 13
１ 構成要素を把握し要件を定義する............................................... 13
２ 機能の優先順位は改善後の業務で判断する ................................... 15
３ 一貫性をもった論理的な記載とする ............................................ 15
４ 要件定義書は継続的にメンテナンスする ...................................... 16

Step.5 機能要件の定義 .......................................... 17
１ 個々の領域について要件を定める............................................... 17
A. 機能に関する事項 ......................................................... 18
B. 画面に関する事項 ......................................................... 19
C. 帳票に関する事項 ......................................................... 22-

2 -（第３編第５章 要件定義）

D. データに関する事項 ...................................................... 24
E. 外部インタフェースに関する事項 ..................................... 35
２ 必要な機能を漏れなく抽出し検討する ......................................... 37
３ 実現手段ではなく、求める結果を記載する ................................... 38

Step.6 非機能要件の定義 ....................................... 39
１ 個々の領域について要件を定める............................................... 39
A. ユーザビリティ及びアクセシビリティに関する事項 .............. 39
B. システム方式に関する事項.............................................. 41
C. 規模に関する事項 ......................................................... 41
D. 性能に関する事項 ......................................................... 43
E. 信頼性に関する事項 ...................................................... 45
F. 拡張性に関する事項 ....................................................... 47
G. 上位互換性に関する事項 ................................................ 49
H. 中立性に関する事項 ...................................................... 50
I. 継続性に関する事項 ....................................................... 50
J. 情報セキュリティに関する事項......................................... 53
K. 情報システム稼働環境に関する事項 .................................. 56
L. テストに関する事項 ...................................................... 62
M. 移行に関する事項 ........................................................ 63
N. 引継ぎに関する事項 ...................................................... 64
O. 教育に関する事項......................................................... 65
P. 運用に関する事項.......................................................... 66
Q. 保守に関する事項......................................................... 67
２ システム方式を決定する .......................................................... 68

Step.7 要件定義終了後の対応 .................................. 69
１ 定義内容を関係者に共有する .................................................... 69
２ プロジェクト計画書に反映して最新化する ................................... 69-

3 -（第３編第５章 要件定義）

事例・参考の一覧
事例：発注者側のキーマン交代で目的が異なる情報システムが出来上がる ....... 7
参考：ＲＦＩ（資料提供依頼）、資料提供招請、意見招請の関係 .................. 10
様式例：業務要件定義書、機能要件定義書、非機能要件定義書のひな形 ........ 14
様式例：機能要件定義書のひな形 ........................................................ 17
参考：砂上の楼閣を防ぐデータ・マネジメント ....................................... 32
参考：コンピュータの内部処理とデータ項目定義 .................................... 34
事例：要件の考慮不足が設計開発工程の遅延に繋がる ............................... 37
事例：非機能要件が機能要件に影響することもある ................................. 44
事例：概念検証により性能要件の実現可能性を確認する ............................ 45
参考：最適なシステム構成................................................................. 46
参考：拡張性要件の記載例................................................................. 47
参考：変化に強い情報システムの構築 .................................................. 48
参考：上位互換性要件の記載例 ........................................................... 49
参考：オープンな標準的技術又は製品の採用を求める場合の記載例 .............. 50
参考：事業者交代時の対応を求める場合の記載例 .................................... 50
参考：継続性に関する事項の記載例 ..................................................... 51
事例：クラウドサービスのハードディスク障害によるデータ消失の責任 ........ 51
事例：クラウドサービスの外へのバックアップの検討 ............................... 52
参考：業務継続の分かれ目................................................................. 52
参考：最低限記述すべき情報セキュリティ対策要件 ................................. 54
参考：クラウドサービスの要件例 ........................................................ 58
参考：運用要件（バックアップ）の記載例 ............................................. 66※事例には当時の役職名やシステム名を使用しているため、現在使用されていな
い名称が記載されている場合があります。
-

4 -（第３編第５章 要件定義）

Step.

1 要件定義の活動全体の流れ

要件定義は、事業者に任せることができるでしょうか？
要件定義では、業務要件、機能要件、非機能要件の大きく３種類の要件を決めていきます。特に情報システムに直接関わる機能要件と非機能要件は専門的な内容を多く含むため、内容を検討する際にその道のプロである事業者から支援を受けることはあるでしょう。
しかし要件定義の実質部分を事業者に丸投げしてしまっては、その先のプロジェクトは絶対にうまくいきません。家を建てるときに、どんなに優秀な建築士が支援したとしても、施主が自身の考えを伝えて様々な選択肢から判断しなければ、施主にとっての理想な家ができない
ことと同じです。つまり、情報システムを作る場合には、その情報システムをどのようなサービ
ス・業務に利用し、どういった利用者がどの程度活用して情報・データを収集・分析などを行
い、サービス・業務の目的を達成するかについて PJMO（主に制度所管部門及び業務実施部門が中心）がまとめておくことが重要です。
ここでは、要件定義を進める際に発注者として最低限知っておくべき知識・ノウハウについて、説明します。
本ドキュメントの構成は、次のとおりです。

Step.2 要件定義の事前準備要件定義を行う前に、これをやっておくとその後の作業をスムーズに進めることができる事
前準備について説明します。

Step.3 ＲＦＩの実施要件定義では、ＲＦＩ等の情報収集を行うことにより、様々な情報を複数の事業者から収集し、情報システム構築の方向性や実現性、適用可能な技術等の情報を把握することができます。しかし、漠然と情報提供を依頼して、収集・整理するだけでは効果が限られます。
ここでは、ＲＦＩ等の情報収集を行うに当たり、何に気をつけて作業を進めればよいかを説明します。

Step.4 要件定義の全体像
要件定義では、業務要件、機能要件、非機能要件で定めた各項目の内容を定義します。
これらの項目の多さや相互に関連する複雑性が、要件定義をより専門的なものとして難しく感じさせる要因ともなっています。
ここでは、要件定義の全体の構造と大まかな内容について説明します。これにより、各項目の位置関係を認識することで、その後の作業の理解を助けます。

Step.5 新しい機能要件の定義
機能要件を具体的に検討し、ドキュメント化する作業は事業者が行うことが多いものですが、発注者として最低限理解しておかなければいけない知識やノウハウを説明します。

Step.6 新しい非機能要件の定義-

5 -（第３編第５章 要件定義）

非機能要件というと、機能要件以上にどんな内容を決める作業なのか想像できないものかもしれません。
ここでは、機能要件と同様に、発注者として最低限理解しておかなければいけない知識やノウハウを説明します。

Step.7 要件定義終了後の対応
要件定義が完了したあとの処理について説明します。要件定義が終わると、ひとまずほっとするところですが、関係者への要件定義内容の共有等、忘れずに実施すべきことを記載し
ています。

-

6 -

（第３編第５章 要件定義）

Step.

2 要件定義の事前準備要件定義の作業に入る前の開始準備として、今直面している検討対象の内容にかかわらず、心得ておくべきことがあります。
ここでは、準備に必要な具体的な内容について、紹介していきます。

１ 要件定義で職員が得た知識は貴重な財産【標準ガイドライン関連箇所：第３編第５章全般】

要件定義を担当した職員は、要件定義を行うことにより、サービス・業務の企画内容、情報システムの要件に係る背景、決定経緯、理由等のドキュメントには表現が難しい暗黙知（職員が暗黙のうちに有する、長年の経験や勘に基づく知識）などの知識を収集しつつ可能な限り客観的にドキュメント化（言語化）し、形式知として蓄積していきます。これらの知識は、設計・開発以降の工程において、詳細な仕様の決定、設計のレビュー、要件変更の決定や受入テストのシナリオ作成等の際に、重要な材料となります。
要件定義を担当した職員が途中で異動してしまい、これらの知識がなくなってしまうことで、設計・開発以降の工程で、無駄な作業の発生、誤った判断、実現したい内容からのかい離、
利用者視点での品質の低下が発生し、プロジェクト全体の目標達成に影響を与えてしまうことが少なくありません。
このため、ＰＪＭＯは、これらの知識を有する職員が継続的にプロジェクトに取り掛かれるよう調整する必要がありますが、これらの知識を日常的に整理・文書化し、やむを得ず、これらの知識を有する職員がプロジェクトを離れてしまうときに、十分な引継ぎを行うよう備えておくことが重要です。
また、要件定義を複数人で行いクロスチェック等を行うことで、複数人にこれらの知識が蓄積され、相互に深めていく方法も効果的です。

事例：発注者側のキーマン交代で目的が異なる情報システムが出来上がる
ある省の業務システム開発プロジェクトにおいて、プロジェクト立上げ時から一人でＰＪＭＯを担当していた職員Ａさんが、設計・開発工程の途中で、異動することになりました。後任にはＡさんとは異なる情報システムの経験を持つＢさんが着任しました。急に決まった異動だったため、引継ぎ資料を準備する時間もなく、プロジェクトで作成したドキュメントの概要を、口頭で説明することで精一杯でした。

Ａさんが担当していた期間中、設計・開発事業者は、各機能の要件定義までの詳細な経緯をＡさんに確認し、それを踏まえて設計・開発を進めていました。交代後、Ｂさんも同様に確認を受けましたが、Ａさんから詳細な検討経緯等については引継ぎ-

7 -

事例 5-1
発注者側のキーマン交代で目的が異なる情報システムが出来上がる

（第３編第５章 要件定義）を受けていなかったため、Ｂさんは自身の経験に基づいた判断で、設計・開発事業者に回答や指示を行いました。その結果、開発された情報システムはＡさんが当初目指していた目的を達成しないものとなってしまいました。

この事例では、Ａさんが自身に蓄積された設計・開発工程までに得た知識を、日常的に文書化しておけば、引継ぎ資料として活用できたはずです。また、突然の担
当者の交代は、人事異動だけではなく、急病や家族の介護等、不可抗力で発生することもあります。このことを想定し、各工程への関わりを複数名で行う体制を構築することにより、知識の蓄積がＡさん一人だけに集中する事態を避けられたはずです。
リリースまでには大量かつ多岐に渡る情報が発生するため、個人の頭の中だけに残すことは不可能です。連続して蓄積された知識は、情報システム開発における様々な作業で不可欠なもののため、主要な担当職員の交代は、プロジェクトの成否に大きな影響を及ぼします。情報システムの開発には、連続して蓄積された知識がとても重要なため、それらを残すための日常的な備えが必要です。

２ プロジェクト計画や業務要件を把握する【標準ガイドライン関連箇所：第３編第５章全般】

要件定義では情報システム等に関わる詳細な要件も検討するため、どうしても各論に目がいきがちとなります。しかし、それぞれの要件は、政策目的やプロジェクト目標の達成、利用者への価値の提供のためにあることを忘れないでください。
例えば、関係者の要望を単に取り入れようとし、情報システムに求める要件が過度に増加することが多々ありますが、このような場合には、その要件の上位に当たる、法令、政策目的・目標の実現やプロジェクト目標の達成まで立ち返り、必要十分な情報システム化の範囲を選択することが大切です。
このため、要件定義を開始するに当たって、まずは、政策目的、目標、対象範囲、サービス・業務企画の方向性等、実施計画等を把握し、プロジェクトとして達成すべきゴールを把握します。その後、サービス・業務企画の活動でまとめた業務要件定義書を確認し、サービス・業務から見た情報システムに対する要求を理解した上で、要件定義を行う範囲を特定しま
す。

-

8 -

（第３編第５章 要件定義）

Step.

3 ＲＦＩの実施

ＲＦＩ（Request For Information）は、情報システムに関する様々な情報を収集するために事業者に対して、構築しようと考えている情報システムに関わる、技術的な情報や動向、参考事
例等の提供を依頼する活動です。
ただし、ＲＦＩを実施するために必要な資料の準備やスケジュール等、進め方の要点を捉えずに実施すると、有益な情報を十分に得られないこともあります。
このＳｔｅｐでは、ＲＦＩを実施するに当たり、何に気をつけて準備を行い、取得した情報を使って、どのように資料を更新していくかについて解説していきます。

１ ＲＦＩを理解し、必要な資料を準備する【標準ガイドライン関連箇所：第３編第５章第１節 1)】

ＲＦＩでは、主に具体的な調達を想定して必要な情報を収集します。必要な情報が集まるかどうかは、情報提供を依頼する事業者に対して、こちらが何を考え、どのようなことを実現しようとしているかを正確に伝えるかどうかに掛かっています。
ここでは、ＲＦＩに向けて資料を準備する際のポイントについて、見ていきましょう。

A. ＲＦＩの意義と用途を理解する
要件定義に必要な情報は、世の中の技術動向やサービスの動向、各種事例、要件を実現する方式に関するものなど多岐にわたり、担当者の知識や経験のみで網羅的かつ詳細に把握することは困難です。
しかし、必要な情報を入手しないまま要件定義を行った場合は、費用対効果に優れた手法を採用できない、優れた先進事例を取り込むことができない等のリスクがあり、さらには、その後の調達手続や設計・開発段階において、入札における不落や開発の手戻り等が発生することになります。
そのため、ＲＦＩを通じて必要な情報を入手し、要件を実現する上で必要な解決策や技術的な課題等を明確にしていきます。
ＲＦＩは、例えば以下のような情報を入手するために行います。

ＲＦＩで求める情報の例
市場にあるサービスの種類及びその動向
海外や国内の類似の事例とその教訓
新たな技術の動向や製品のライフサイクル
想定する要件を実現する方式とその実現可能度や制約事項
概算の予算規模
大まかな工程やスケジュール
著作権や法的な制約-

9 -（第３編第５章 要件定義）実現に際してのリスク 等
ＲＦＩは、その用途に応じて、プロジェクトの様々なタイミングで活用することが可能です。
新たなサービス・業務を開始するプロジェクトにおけるＲＦＩのタイミングの例を、以下に示します。大規模なプロジェクトでは、最新のサービス・技術の採用や計画の妥当性の確認を十分に行う必要があるため、サービス開始年度の３ヵ年前を目安として情報収集を始めることを推奨します。

図 5-1
ＲＦＩのタイミング例

参考：ＲＦＩ（資料提供依頼）、資料提供招請、意見招請の関係事業者から情報を収集するための代表的なやり方には、ＲＦＩ（Request For
Information、資料提供依頼）、資料提供招請、意見招請の 3 つがあります。
このうち、要件定義を行うための情報収集には、ＲＦＩ、資料提供招請を用います。
両者の大きな違いは、資料提供招請には、実施の条件や期間等の定めがある点です。
意見招請は、調達前に仕様書案に対する意見の提出を行うことが出来るようにするものであり、調達案件が 80 万ＳＤＲ以上の調達額と見込まれるものについては、原則必須となります。詳細は、標準ガイドライン「第６章３．4) 意見招請の実施」を参照
してください。
これらの手続は、「供給者の利便及び競争力のある内外の供給者による市場参入機会の確保に資するとともに透明性、公正性及び競争性の高い調達手続とする」こ
とが目的です。事業者からの情報収集に当たっては、標準ガイドラインのルールに従うとともに、「政府調達手続に関する運用指針」（平成 26 年３月 31 日関係省庁申合せ）を参考にしてください。

B. ＲＦＩに必要な資料を準備する
ＲＦＩでプロジェクトの成功に向け役に立つ情報を入手するためには、発注者側がどのよ

-

10 -

参考 5-1
ＲＦＩ（資料提供依頼）、資料提供
招請、意見招請の関係

（第３編第５章 要件定義）

うな事を考え、何をしようとしているかを正確に伝えるため、ＲＦＩのために資料を準備する
必要がありますが、この資料作成に負担を感じ、ＲＦＩを見送ってしまうという判断をしてしまうかもしれません。
しかし、資料の作成は、ポイントを押さえて、これまで収集・作成した資料を活用すれば、それほど難しいことはありません。以下に、ＲＦＩに必要な資料とその作成ポイントを示します。資料では意図が伝わりにくいこともあるため、説明会や個別ヒアリングを合わせて行うことも検討しましょう。

資料の種類

ポイント

調達の概要

事業者がプロジェクトの目的・概要・ＲＦＩの概要等の全体像を把握するための資料で、プロジェクト計画書から政策目的、目標、サービ
ス・業務企画の方向性等を集め、資料をまとめます。サービス・業務
企画や予算要求で業務や情報システムの概要資料を作成している
場合は、それを利用することで事業者が全体像を効率的に把握する役に立ちます。

その時点における検討内
容、要件案の概要等

サービス・業務企画で作成する業務要件定義書やＲＦＩ時点の要件
定義の定義書を利用します。未確定の項目や提案を求める項目については、その旨を明記しましょう。また、前提条件や制約等がある
場合は、必ず記載してください。

資料提供を求める内容等

ＲＦＩの趣旨（何の情報を何のため求めているのか）、ＲＦＩで求める内容を記載します。要件定義書の未確定の項目や提案を求める項
目をサマリすると事業者が網羅的に検討しやすくなります。

提出期限、提出場所、提出方法、提出資料における知的財産の取扱い等

各府省のルールを確認し、過去のＲＦＩの記載を参考にすると効率的に作成することができます。

表 5-1
調達に必要な資料

２ 公平性等を確保したヒアリングを行う【標準ガイドライン関連箇所：第３編第５章第１節 2)】

ＲＦＩを行うほど要件が確定していない場合等には、事業者に対して説明会や個別ヒアリン
グを行い、情報を収集する方法があります。事業者と直接ヒアリングすることは、資料では伝わりにくい目的や意図を伝えるのに有効です。しかし、発注前ヒアリングについても、ＲＦＩと同様に公平性・競争性を確保する必要があるため、ＲＦＩと同様に標準ガイドラインのルールに従うとともに、「政府調達手続に関する運用指針」（平成 26 年３月 31 日関係省庁申合せ）を参考にしてください。

３ 収集した情報を基に資料を更新する【標準ガイドライン関連箇所：第３編第５章第１節 3)】

ＲＦＩや発注前ヒアリングの結果、有用な情報が集まりました。これらを踏まえて、要件定義を始めましょう。でも、ちょっと待ってください。その前に一手間加えるだけで、要件定義が効率的に行えるようになります。
では、要件定義を行う前のちょっとした工夫を見ていきましょう。

A. ＲＦＩや発注前ヒアリングの結果を整理する
ＲＦＩにて複数の事業者から入手した資料や事業者とのヒアリング結果は、それぞれが独

-

11 -

注記
「政府調達手続に関する運用指針」（平成 26 年３月 31 日関係省
庁申合せ）

（第３編第５章 要件定義）

立した資料として残っているはずです。要件定義で入手した情報を十分に活用するためには、以下の観点で情報を整理し、資料としてまとめます。また、整理した結果から、より費用対効果が高い実現方式の検討や、リスク定義への追加等を行い、プロジェクト計画の変更を検討し、必要な更新を行います。

結果を整理する観点
複数事業者の情報を内容ごとに比較し、メリット、デメリットを評価する。事業者の提案はメリットを中心に行われるため、デメリットにも目を向けて評価する。
費用、目的との適合性等の複数の軸で総合評価する。

B. 既存の資料を最新化する
既存のサービス・業務や情報システムは、プロジェクトが進行している最中にも改善や機能追加が行われる可能性があります。既存のサービス・業務や情報システムの資料はサービス・業務企画時点で収集しますが、要件定義を開始する時点で最新化を行いましょう。
調達後に変更内容が判明した場合は、追加のコストがかかる可能性がありますので、留意
してください。

-

12 -（第３編第５章 要件定義）

Step.

4 要件定義の全体像

要件定義は、業務要件、機能要件、非機能要件で構成され、各要件には多数の項目が定義されており、それぞれの内容は項目間で影響し合っています。
このＳｔｅｐでは、この要件定義全体の構造を説明した上で、要件定義全般にわたって気を付けるポイントを解説します。

１ 構成要素を把握し要件を定義する【標準ガイドライン関連箇所：第３編第５章第２節 1)ア】

要件定義の内容は定義する項目が多数あるため、詳細を検討していく中で、どこかで同じ内容を検討してはいないか、本当に漏れがないか、と不安になってくることがあります。
まずは、要件定義の構造と定義する項目を俯瞰し、要件の上位に当たる、政策目的・実現する目標、達成すべきプロジェクト目標に沿って、何をどこで定義するのか、それぞれの項目
がどのように関連しているかを理解しましょう。要件定義は、それぞれの項目の整合性を逐次取りながら定義することで、無駄なく、漏れなく、効率的に検討していくことができます。

図 5-2
要件定義の構成要素とポイント

この実践ガイドブックの別紙として、業務要件、機能要件、非機能要件のそれぞれのひな形を用意しています。これを活用すれば、基本的な部分についての漏れをなくすことができます。
ただし、これらの要件定義を作成する時点では、全ての項目をきっちりと定義することが難しい場合もあります。未確定の項目は、後の工程で定義されることになります。このときに関連する項目に変更がある場合があるため、関連する項目の変更漏れがないように、未確定の項

-

13 -

（第３編第５章 要件定義）

目の関係性がわかるようにしておくことが大切です。
また、定義書が一通り作成された後、以下の観点で最終確認を行うことで、定義漏れを防ぐことができます。

確認の観点

解説

必要性

政策目的・目標の実現やプロジェクト目標の達成への貢献といった有効性の観点及び費用対効果の観点を踏まえ、実現すべき機能要件
及び非機能要件のみが定義されていること。

網羅性

業務要件が漏れなく定義され、その実現のために備えるべき機能要件及び非機能要件が漏れなく定義されていること。

具体性

機能要件及び非機能要件を実現する複雑さ、難易度、調達コストに影響する不確定要素が可能な限り排除されていること。

定量性

業務及び情報システムの規模等が定量的に示され、性能等に関する計測可能な指標と具体的な目標値が設定されていること。

整合性

業務要件、機能要件、非機能要件の内容に矛盾がないこと。また、関連する他のプロジェクトの要件定義内容と整合的であること。

中立性

調達コストの削減、透明性向上等を図るため、要件定義内容が特定事業者に不必要に依存したものでないこと。

役割分担の明確性業務の実施体制が明確であること。また、情報システムのテスト、移行、引継ぎ、運用、保守に関して、関係府省等も含め、自府省と事業者との役割分担が明確であること、

情報セキュリティ

自府省の情報セキュリティポリシーを遵守するために必要な対策が漏れなく定義されていること。

様式例：業務要件定義書、機能要件定義書、非機能要件定義書のひな形
業務要件定義書、機能要件定義書、非機能要件定義書のひな形を本章別紙としてまとめています。

-

14 -

表 5-2
要件定義内容を確認する観点

様式例 5-1
業務要件定義書、機能要件定義
書、非機能要件定義書のひな形

（第３編第５章 要件定義）

２ 機能の優先順位は改善後の業務で判断する【標準ガイドライン関連箇所：第３編第５章第２節 1)イ】

要件定義で検討する機能は、必ずしも全てを実現できるわけではありません。予算やスケジュールの関係から、実現する機能を絞らなければならないことはよくあります。
機能の実現要否を検討する際には、政策目的やプロジェクト目標との関係、費用対効果等の観点を主眼として優先順位を判断していきます。また、機能を代替する方法（業務担当者の手作業や運用・保守作業にする等）も合わせて検討します。

図 5-3
機能の優先順位付けの考え方

３ 一貫性をもった論理的な記載とする【標準ガイドライン関連箇所：第３編第５章第２節】

要件定義の内容を記した文書は、ＰＪＭＯと事業者がサービス・業務や情報システムの目指すべき姿を共有するとともに、事業者との契約上の合意文書となる重要なものであるため、誤

-

15 -

（第３編第５章 要件定義）

った定義や曖昧な定義が行われると、後続の工程に重大な影響を与えます。
そのため、要件定義の内容は、次に示す点を参考に、正確で一貫性のある記載となるようにしましょう。
曖昧な用語や一般的な意味と異なる使い方をしている用語等は、プロジェクト
関係者間の認識そごを防止するため、用語の定義及び機能を定義する粒度や深さについて統一する。
業務要件定義書のインプットであるサービス・業務企画の内容とも整合の取れた区分、順番で機能を記載する。業務の単位ごとに記載する場合も、共通処理機能を識別できるように整理する等、機能数を把握できるように記載する。
機能の説明は、箇条書き等にして簡潔に記載する。既存のサービス・業務や情報システムの変更を行う際の要件定義では、追加・変更となる要件が明確になるよう、変更箇所の記載ルールを定めて記載を統一する。

４ 要件定義書は継続的にメンテナンスする【標準ガイドライン関連箇所：第３編第５章第２節】

要件定義が確定した後、設計・開発等を実施していく中で、要件定義の内容に漏れや誤りを発覚することはよくあります。これらは、プロジェクト管理要領の変更管理及び事業者との取り決めに従って管理されますが、要件定義書自体の修正が行われないことが多々あります。
要件定義書は、プロジェクト関係者に情報システムの要件を正確に伝達するためのものであるため、変更が発生した際は常に最新化を行いましょう。
また、要件定義書の情報は、後工程である設計・開発において、設計情報のインプットとなる以外にも、各種テストのインプット情報にも、運用開始後における継続的なサービス・業務改善活動の基礎情報としても利用されます。しかし、メンテナンスという名の下、内容が変質したり、事業者側に有利な内容に変わってしまったりすることがあるため注意し、継続的な維持・管理を心掛けてください。

-

16 -

（第３編第５章 要件定義）

Step.

5 機能要件の定義

既に定められた業務要件に基づき、業務要件を満たすために情報システムの機能に求められる要件を定義していきます。
開発の進め方や採用する技術によって具体的な作業の進め方は異なることがありますが、いずれの場合も進める際に理解しておくべき手段やノウハウについて、解説していきます。

１ 個々の領域について要件を定める【標準ガイドライン関連箇所：第３編第５章第２節 1)イ】

機能要件として定義しないといけない内容は、機能、画面、帳票、情報・データ、外部イン
タフェースの５つです。要件定義の対象となる情報システムによっては、このうちの一部を定義しない場合もあります。例えば、バッチ処理しかしない情報システムであれば画面の定義は不要となりますし、他の情報システムと連携しない Web サイトであれば外部インタフェースの定義は不要となります。

様式例：機能要件定義書のひな形
機能要件定義書のひな形を本章別紙としてまとめています。

-

17 -

注記
バッチ処理とは、データの処理を即時実行（オンライン処理）せず、「10 分ごと」や「毎日午前０時」な
どのあらかじめ決められたタイミ
ングでまとめて実行する処理のこと。
様式例 5-2
機能要件定義書のひな形

（第３編第５章 要件定義）

A. 機能に関する事項「機能」とは、情報システムが外部に価値を提供する一連の動作のまとまりのことです。
基本的に「入力」・「演算(処理)」・「出力」で構成されます。ボタンを押したら画面に情報が表示されるのも、夜間にバッチ処理で帳票が大量に印刷されるのも、それぞれ１つの機能です。情報システムが提供する形は様々ですが、それらを「機能」として一覧化して整理するために用いるのが、「情報システム機能一覧」と呼ばれるドキュメントです。
「情報システム機能一覧」は、業務で求められる要件を情報システムで実現するために何が必要かを「機能」で表現したものであり、その概要や処理方式等を併せて記載し、情報システムの設計・開発を行う事業者に、情報システムに求められる要件を正しく伝えま
す。

No.

機能
ＩＤ

機能
分類

機能
名

1

XXXX

○○
登録
機能

2

XXXX

3

・・・

○○
申請
書登
録
○○
申請
書出
力
・・・

○○
出力
機能
・・・

機能概要

処理
方式

利用者
区分

現状の
機能と
の差異

補足

入力

処理

出力

記載
事項
の入
力
出力
方式
の選
択
・・・

・・・

・・・

オンラ
イン

○○申
請者

・・・

・・・

・・・

申請
書の
出力

オンラ
イン

○○申
請者

・・・

・・・

・・・

・・・

・・・

・・・

・・・

情報システム機能一覧は、基本的に１つの情報システムについて１つ作成します。（一覧が大きくなり過ぎた場合は、複数に分割する等、工夫することはあります。）一覧では、１
機能の情報を１行で表現し、この情報システムで使用する機能は全て定義されます。
この一覧は、業務要件の内容を詳細化し、そこから機能要件を取り出すことで作成することができます。例えば「○○申告書をオンラインで作成する」という 1 つの業務要件は、「申告内容を新規登録する」「申告内容を更新する」「申告内容を削除する」「○○申告書を作成する」「○○申告書をＰＤＦでダウンロードする」等に分解できます。ここから、必要な機能を特定します。
１つの機能が複数の業務要件に使われることもあります。同じ機能を重複して記載しないようにしてください。
情報システム機能一覧は、後工程の開発・設計で構築作業のインプットとなりますが、構築範囲や対象を特定する情報ともなります。事業者が設計・開発に関する作業を計画する
際、機能を 1 つの単位として考えることが多いため、発注者としてはこの一覧の内容まではしっかり理解し、この一覧を利用して事業者と会話できるようにしてください。
また、忘れがちなのが情報システムを管理するために必要な機能です。ユーザアカウン
トの追加削除、マスターデータの更新等、各種バッチ処理の実行、ログの記録や検索等、システム管理者が操作するための機能等も忘れずに検討してください。

クラウドサービス、パッケージ製品と比較できる粒度で整理
昨今のクラウドサービスやパッケージ製品は、様々なものが開発され、提供されています。「こんなものはないだろう。」といった先入観は持たず、まずは世の中にあるかどうかを確認し、採用が可能かを検討しましょう。
採用可否の判断の１つは、クラウドサービスやパッケージ製品が提供する機能群と、求

-

18 -

表 5-3
情報システム機能一覧

（第３編第５章 要件定義）

める機能群との適合性です。正確に比較するには、双方の機能を同じ粒度に揃えることがコツです。具体的にはその機能が扱う情報を「入力」・「演算(処理)」・「出力」の何れかに分解できるレベルに揃えることが１つの指針となります。
これにより、何が既にある機能で、何が新しく追加しなくてはいけない機能なのかを判別することができます。

B. 画面に関する事項
情報システムの画面は、利用者が業務の流れの中で情報システムとやり取りを行う窓口となるため、画面上で取り扱う情報の種類、画面を構成する要素の配置は、利用者の業務
効率や満足度に大きな影響を与えます。
この画面に関する要件を取りまとめるドキュメントは、一般的に画面一覧、画面イメージ（画面モックアップ）、画面遷移図、画面設計方針書（画面設計ポリシー）と呼ばれるもので構成されています。これらドキュメント間の整合性を保ちつつ、情報システム機能要件一覧との整合性も意識しながら作成を進めます。
●

画面一覧
画面一覧とは、情報システムで実現する全ての画面の要件を画面の単位で定義し、一覧化したものです。これにより、画面ごとの入出力要件や該当機能等を把握できます。
画面一覧は、基本的に１つの情報システムについて１つ作成します（一覧が大きくなり過ぎた場合は、複数に分割する等、工夫することはあります。）。一覧では、１画面の情報を１行で表現し、対象とする情報システムで使用する画面が全て記載されます。画面の要件
は、該当機能を実現する画面をイメージしながら、画面名、画面概要、入出力要件等を整理し記述します。複数の機能で同一の画面を使用する場合もあることに注意してください。

No.

●

1

画面
ＩＤ
XXXX

2

XXXX

3

XXXX

4

XXXX

画面
分類
申請
書作
成画
面

申請
書登
録画
面
申請
書出
力画
面

画面
名
○○
申請
書作
成
○○
申請
書確
認
○○
申請
書登
録
○○
申請
書出
力

画面
概要
○○申
請書の
作成画
面
○○申
請書の
作成確
認画面
○○申
請書の
登録画
面
○○申
請書の
出力方
法確認
画面

画面入出
力要件
表示方
法：・・・
入力操作
概要：・・・
表示方
法：・・・
入力操作
概要：・・・
表示方
法：・・・
入力操作
概要：・・・
表示方
法：・・・
入力操作
概要：・・・

画面設計
要件
Ｗｅｂブラ
ウザで表
示可能で
あること。
・・・

該当
機能
機能Ｉ
Ｄ:
XXXX

利用者
区分
○○申
請者

機能Ｉ
Ｄ:
XXXX

○○申
請者

・・・

機能Ｉ
Ｄ:
XXXX

○○申
請者

・・・

機能Ｉ
Ｄ:
XXXX

○○申
請者

補
足

画面イメージ（画面モックアップ）
画面イメージ（画面モックアップ）とは、本格的に画面を設計・開発する前に、発注者と事業者の認識を合わせるために作る画面の模型です。HTML 等で作ることで具体的な処理が組み込んでいないだけでほぼ実現したい画面の最終形になっているものもあれば、紙

-

19 -

表 5-4
画面一覧

（第３編第５章 要件定義）やホワイトボードに手書きで書いたラフなものまで、様々な作り方をされます。最終的には、
それらのイメージと解説をセットとしてドキュメントにまとめます。
要件定義の段階では、改修などの少数の画面に特定されている場合は別ですが、基本的には全画面のうち代表的なものについてのみ画面イメージを作成します。後工程で画面ごとに内容を確定させますので、要件定義の段階では代表的なものや特徴的なものが定義されていれば通常は十分です。
既存の情報システムがある場合は、その画面をベースに、追加・変更箇所がわかるようにする方法もあります。

図 5-4
画面イメージの定義例

●

画面遷移図
画面遷移図とは、画面間の遷移を図に表したもので、画面間の関係や画面の流れをイメージすることできます。
画面遷移図は、画面と画面とを線で結び、矢印で方向を示すことで、どの画面からどの画面に遷移するかを示します。画面遷移図を見ることで、情報システムで実現する画面群全体を俯瞰的に捉えることができます。その情報システムにおける基本的な画面遷移パターンと比べて、特殊な画面遷移をしている個所は、特別な理由が無ければ修正し、基本的な画面遷移パターンに合わせることで、統一感のある使いやすい情報システムとなります。

-

20 -

（第３編第５章 要件定義）

図 5-5
画面遷移図

●

画面設計方針書（画面設計ポリシー）
画面設計方針書（画面設計ポリシー）とは、画面設計を行う際の方針や遵守すべきルールを記載したものです。構築する情報システム全体として、どんな画面にしていきたいか、
どんなことを守る必要があるかを定めることで、発注者の意識を整理し、事業者に発注者の意図やルールを正しく伝えることができます。事業者は全ての画面をこの方針書に基づき設計していくことになります。
画面設計方針書は、既存情報システムや類似情報システムを参考にして、基本的な画面デザイン、ボタンの配置、画面遷移、操作手順等を検討した結果が記載されます。標準
ガイドライン解説書「第３編第５章２．1)ウ a) ユーザビリティ及びアクセシビリティに関する事
項」の定義内容との整合にも気をつけてください。
基本的には、画面デザインはシステム全体を通じて統一することが好ましいです。利用者にとっても操作方法を覚えやすくなりますし、システムを維持運用する観点からも改修等が行いやすくなるからです。とはいっても、業務の内容によっては、その業務に特化した専用画面を作ったほうがよいこともあるでしょう。統一するか、個別に作り込むか、最終的にはその画面を見る人の利便性を重視して、決めていきましょう。

画面イメージや画面遷移図を細かく決めすぎない
画面に関する事項の検討は、実際に利用する業務実施部門の職員の意見を取り入れることにより、利用者の満足度向上につながります。一方で、現場職員の意見を聞きすぎると、微細な点にまで議論が及び、いつまでも要件が確定しないという事態に陥りがちです。
また、詳細に決めすぎると、クラウドサービスやパッケージ製品の採用を検討するときに、「適合するものがない」「大幅なカスタマイズが必要」という結論に至る弊害が考えられます。
要件定義で定める内容は、あくまで作業規模の見積りとなる元情報及び、具体的なレイ
アウト・画面遷移を設計するに当たっての要求事項に過ぎません。最終的には、設計段階で画面レイアウトの詳細を決めますので、この段階では不必要に詳細部分にまで入り込む必要はありません。

-

21 -（第３編第５章 要件定義）

設計の技術的な前提条件を明記する
画面の設計・開発において前提となる各種標準やミドルウェア、ソフトウェアフレームワー
ク等が事前に決定されている場合は、それらの前提となる環境を画面設計方針書に詳細に明記します。また、画面イメージを検討する際には、それらの前提を踏まえた上で方針を決定してください。ミドルウェアやフレームワーク等によっては、出力イメージの実現に多大な工数が必要となる場合や実現不能となる場合があり、画面イメージが方針に沿っていな
いと設計時に大幅な手戻りを招く可能性があります。

注記
ソフトウェアフレームワークとは、
アプリケーションを開発する際に必要となる汎用的な機能や部品等をまとめて提供し、アプリケー
ションの枠組みとして機能するソ
フトウェアのこと。

C. 帳票に関する事項
情報システムの帳票とは、サービス・業務で使用するために情報システムから出力した紙やＰＤＦ形式等の電子帳票を指します。帳票は、利用者が業務上意識して用いられるものであるため、業務の内容やきっかけと結びついた重要な情報を持ちます。
帳票に関する要件を取りまとめるドキュメントは、一般的に帳票一覧、帳票イメージ、帳票設計方針書（帳票設計ポリシー）と呼ばれるもので構成されています。これらドキュメント間の整合性を保ちつつ、情報システム機能要件一覧との整合性も意識しながら作成を進
めます。
●

帳票一覧
帳票一覧とは、サービス・業務で使用する全ての帳票の要件を帳票の単位で定義し、一覧化したものです。これにより、帳票ごとの入出力要件や入出力形式、該当機能等を把握できます。気をつけたいのは、帳票一覧には情報システムが入出力しないものも記載する点です。明確に区別した上で、サービス・業務で取り扱う全ての帳票を記載することにより、管理がしやすくなります。
帳票一覧は、基本的に１つの情報システムについて１つ作成します（一覧が大きくなり過ぎた場合は、複数に分割する等、工夫することはあります。）。一覧では、１帳票の情報を１行で表現します。
帳票一覧は、業務の流れを意識して整理する抜け・漏れが防ぎやすいため、業務フロ
ー図と整合性を取って作成します。帳票概要は、誰が、どのような契機で、何のために、帳票をどうするかを記述します。また、入出力形式として紙、電子ファイル（ＰＤＦ等）の形式も明確にします。

N
o
.
1

帳
票
ＩＤ
XX
XX

2

XX
XX

3

XX
XX

帳票
名

帳票
概要

○○
申請
書

○○
申請
用

△△
申請
書

△△
申請
用

入出
力の
区分
出力

帳票
入出力
要件
モノクロ
印刷

出力

カラー
印刷

-

帳票
設計
要件
用紙サ
イズ：A4
用紙の
指定：
XX
用紙サ
イズ：A4
用紙の
指定：
XX

22 -

入出力
形式

該当
機能

利用者
区分

紙

機能Ｉ
Ｄ:
XXXX

○○申請者

ＰＤＦ

機能Ｉ
Ｄ:
XXXX

△△申請者

表 5-5
帳票一覧（例）

（第３編第５章 要件定義）●

帳票イメージ
帳票イメージとは、画面イメージと同様に、本格的に画面を設計・開発する前に、発注者と事業者の認識を合わせるために作る画面の模型です。Excel 等で作ることで詳細な項目まで表現されているものもあれば、紙やホワイトボードに手書きで書いたラフなものまで、様々な作り方があります。最終的には、それらのイメージと解説をセットとしてドキュメントにまとめます。
要件定義の段階では、改修などの少数の帳票に特定されている場合を除き、全ての帳票に対して帳票イメージを作成することは無く、代表的な帳票から選定して、異なる種類分を作ります。後工程で帳票ごとに内容を確定させますので、代表的・特徴的なものが定義されていれば、通常は十分です。既存情報システムの帳票があればそれを基に、今回追加変更したい内容がわかるように情報を加えます。基になるものがないような新規のサービ
ス・業務の場合は、紙やホワイトボード等にイメージを描きながら、職員と事業者とが対面で内容を擦り合わせます。
法定帳票等、既にフォーマットが決定しているものは、その内容を明示します。

図 5-6
帳票イメージの定義例●

帳票設計方針書（帳票設計ポリシー）
帳票設計方針書（帳票設計ポリシー）とは、帳票設計を行う際の方針や遵守すべきルールを記述したものです。構築する情報システム全体として、どんな帳票にしていきたいか、
どんなことを守る必要があるかを定めることで、発注者の意識を整理し、事業者に発注者の意図やルールを正しく伝えることができます。事業者は全ての帳票をこの方針書に基づき設計していくことになります。
帳票設計方針書は、作成した帳票一覧や帳票イメージ以外にも、既存情報システムや類似情報システムを参考にして、基本的な帳票デザイン、種類、様式、項目や罫線等の構成要素を検討した結果が記載されます。

帳票のレイアウトイメージを細かく決めすぎない
画面に関する事項と同様に、帳票レイアウトイメージも過度に細かく決めすぎないことが重要です。ここで決めた内容は、具体的なレイアウトを設計するに当たってのイメージ（要求事項）として扱われ、設計結果（確定したもの）として扱わないよう留意してください。

-

23 -

（第３編第５章 要件定義）

なお、法定帳票や OCR で読み取りをする帳票等、帳票レイアウトが確定しているものについては、レイアウトの定義を要件として明記します。
帳票のレイアウトイメージは、要求事項を伝えるための表現方法として使用し、具体的なレイアウト等の設計結果を示すものとは区別して記載すること。
帳票の利用目的を考慮し、法定の帳票や外部連携に用いる帳票等、業務の処理において不可欠な帳票を優先して整備する。
複数の機能で同一の帳票レイアウトを使用する場合は、１つの帳票に複数の機能を紐付ける形で整理する等、帳票の種類がわかるように記載する。
法定帳票等、帳票レイアウトが確定している場合は、遵守しなくてはいけない点（項目が満たされていればよい、配置も同一でなくてはならない、印刷位置
をミリ単位で厳守しなくてはならない等）を明確に記載する。

設計の技術的な前提条件を明記する帳票の要件として、「紙面に記載する情報」「紙面のレイアウト」に関して定義が必要であることは、想像がつきやすいのですが、「帳票を生成する方式」や「出力先」も要件の重要な要素です。バラバラの要件では、情報システムの構築にかかる費用見積りが過度に高くなる可能性があるため、同じような要件は可能な限り統一し、共通化できるように整理しておくことが有効です。
帳票の設計・開発において前提となる各種標準やミドルウェア、フレームワーク
等が事前に決定されているときは、それらの前提となる環境を詳細に明記すること。
出力先として複数のプリンタを使用し、プリンタの印字方式に制限があるとき、出力用紙にカーボンコピー用紙を使用する等の条件があれば、補足にその旨を記載すること。

D. データに関する事項
ここで定義する情報システムのデータとは、情報システムの中（データベース等）で管理されるものであり、利用者にとっては目に見えないものですが、当該情報システム内で使われるのはもちろん、国民共有の財産であるという認識に立ち、広く一般に利活用されることを想定したものでなければなりません。
一方、こうしたデータの利活用を効果的なものにするためには、当然のことながら、デー
タそのものの品質が十分に確保されていなければなりません。
すなわち、「データの利活用」と「データの品質確保」は、情報システム構築の際に欠かせない重要な要件となっています。
そこで、要件定義フェーズでは、プロジェクト計画書で記載した「データ利活用の方向性」に基づいて、情報システムで管理するデータの利活用や品質確保のための考え方を盛り込んだ、データに関する定義を記載します。具体的には、以下の分類に沿って、利活用するデータを識別・再構成し、各々の括りごとに、データ要件として定義します。

-

24 -

（第３編第５章 要件定義）

図 5-7
データの利活用と品質確保

データ要件の定義にあたり、既存の情報システムのデータについては現行の機密性レ
ベルや標準化レベル等の品質を改善すること、新規の情報システムのデータについては品質を十分に確保できるような定義を行うよう努めましょう。具体的な要件定義ドキュメントの説明に入る前に、これらデータの利活用方針や品質確保のための考え方や留意事項
を、以下に順を追って説明します。

オープンデータの範囲と公開方法●

オープンデータの定義と分類「オープンデータ基本指針」（平成 29 年５月 30 日高度情報通信ネットワーク社会推進

戦略本部・官民データ活用推進戦略会議決定）において定義されている内容を踏襲しま
すが、さらに以下の分類を行います。（図 5-8 参照）
オープン可能データ：情報システム上に存在するデータのうち、以下のものを除くすべてのデータ。
- 個人情報が含まれるもの- 国や公共の安全、秩序の維持に支障を及ぼすおそれがあるもの- 法人や個人の権利利益を害するおそれがあるもの- 法律等によって用途が制限されているもの
オープン状態データ：オープン可能データのうち、外部から人為的な手続きを経ずに取得できる状態（ダウンロードサイト、Web-API 公開など）になっている
データ。
オープン待機データ：オープン可能データのうち、外部から申請等の手続を経て取得できるデータ。
図 5-8
オープンデータの分類
注記
オープンデータは機械判読性に基づいた公開レベルによってレベル１（★１）～レベル５（★５）の５段階に分類される。この評価指標
を「５スターオープンデータ」といい、PDF は★１、XLS は★２、CSV は★３に該当する。
「５スターオープンデータ」
https://5stardata.info/ja/

-

25 -

（第３編第５章 要件定義）●

オープンデータの範囲と公開方法
上記「オープンデータの定義と分類」に基づき、情報システムで管理するデータに関し、以下の情報を定義します。
オープン可能データの識別
後述の「データ一覧」の「公開可否」列に明記する。オープン可能データ以外については、その理由も「公開不可の理由」列に記述する。
オープン状態データの一覧（「オープンデータ一覧」として一覧化）
オープン状態データの名称、概要・用途（メタ情報）、利用者及び公開の範
囲、利用目的、利用頻度・特徴、実装方式、処理方式等を記述する。
この時、オープン可能データの中で、オープン状態データの割合ができるだけオープン
待機データより大きくなるようにしましょう。また、オープン状態データの中でも PDF 形式よりは CSV 形式、さらには Web-API の公開というように、より活用の幅が大きくなるような公開形式を計画してください。
なお、オープン可能データの中にも、利用者ニーズに差があったり、意味のある公開データにするためには多大のコストがかかるものが存在したりします。利用者ニーズの大小や費用対効果を勘案の上で公開の範囲や優先度を決定するよう心がけてください。また、オープン待機データについては、そのメタ情報を公開し、様々な公開ニーズの発掘に努めましょう。

データの品質確保のための考え方
データ機密性定義と管理方法
ここでは要件定義として明らかにしておくべきデータの機密性定義とその管理方法について説明します。情報セキュリティに関する全般的な事項、つまり機密性、信頼性、可用性などに関する全体的なことは別章の「情報セキュリティに関する事項」及び「信頼性に関する事項」を参照してください。
個人情報漏えいのニュースは報道等で大きく取り上げられ、その管理責任が問われることも頻繁に起きている状況が続いています。情報システムを構築し管理する組織としては、
その重要性を認識し、システムの構築段階からデータに関する取り扱いを明確化し、適切に対応していくことが求められています。
要件定義においては、情報システムで取り扱うデータに関して機密性レベル別に分類し、その管理方法を定義しておく必要があります。システム内に存在することになるデータに関して、その機密性を認識し、分類し、またその管理方法を「データ要件」として記述することにより、その後の設計・開発作業に確実に繋げていくことができます。
下表 5-6 は、行政文書に関して整理した参考例ですが、個人情報等もこの分類で対応させて管理方法等を決めると分かりやすい整理ができます。なお、下表 5-6 の記載内容はあくまで参考であり、最終的な秘密文書の定義の判断は、行政文書の管理に関するガイド
ライン（https://www8.cao.go.jp/chosei/koubun/hourei/hourei.html ）を参照の上、決定することに留意してください。

分類 1

分類 2

分類 3

特定秘密

-

概要説明

備考

防衛、外交、特定有害活動、テロリズム関連でそのクラウド不可26 -

表 5-6
参考：行政文書に関する整理（電子的管理を含む）

（第３編第５章 要件定義）

分類 1

分類 2

分類 3

概要説明

備考

漏えいが我が国の安全保障に著しい支障を与える
おそれのある情報。
秘密文書

極秘文書

機密性 3

行政事務で取り扱う情報のうち、秘密文書に相当する機密性を要する情報。
（ 特定の職員のみ取り扱い）

クラウド不可（インターネット接続端末への
保存不可）

秘文書

機密性 3

同上

クラウド可（インターネットからの侵入に対する適切な情報セキュリティ対策が必要）。

機密性 2

行政事務で取り扱う情報のうち、秘密文書に相当する機密性は要しない
が、漏えいにより、国民の権利が侵害され又行政事務の遂行に支障を及ぼす
おそれがある情報（職員のみ取り扱い）。

要機密情報（機密性２以上）については、特にその取扱制限を検討する。
＊個人情報等に該当。

機密性 1

機密性２情報、機密性３情
報以外の情報。
（職員以外も取り扱い可）

まだ明確に定義できないデータもあると思いますが、特に機密性の高いデータに関しては、その洗い出しと分類、及び管理方法を可能な限り具体的に記述しておきましょう。情報の管理責任は発注者側にあります。その重要性を再認識し、要件として定義することが、情報漏えい等の問題を起こさない最も重要な作業の一つであると言えます。
整理する内容としては、データ名称、個人情報／特定個人情報の有無、保管方法（別の端末には置かない等）、暗号化有無、格付・取扱・アクセス制限設定（人、プログラムから等）、履歴管理（更新、参照者の特定レベル）、運用管理／手順のレベル等です。詳細は本ガイドブック別紙「機能要件定義書テンプレート例」の「第５章 データに関する事項」の「データ一覧」を参照ください。

マスターデータの標準化
マスターデータとは、「データを利用してサービスを実現するときに必要となる基本情報のことです。例えば、目的に合わせた基本データ集として整理された台帳のようなものや、
個人、組織、事業所、場所等の基本情報をリスト化したもの」（マスターデータ等基本デー
タ導入実践ガイドブックより）です。例えば情報システムでは事業所の情報（会社名、事業
所名、事業所番号、事業内容、住所、従業員数等）の一覧が電子リスト（マスターデータのこと）として定義され、システム内の各機能（プログラム）から参照することにより、事業所番号を入力するだけで関連する事業所の情報を画面に表示して選択を促すというような処理で利用されます。
●

マスターデータの標準化の重要性
上記のとおり、一つの情報システム内でも様々なプログラムから参照されるマスターデー

-

27 -

注記
「政府機関等のサイバーセキュリ
ティ対策のための統一基準（令和３年度版）」（NISC（内閣サイバーセキュリティセンター） 令和３年７月７日）
https://www.nisc.go.jp/active/ge
neral/kijunr3.html「行政文書の管理に関するガイド
ライン」（内閣府 平成２３年４月１日決定、令和２年７月７日一部改正）https://www8.cao.go.jp/chosei/koubun/hourei/hourei.html「特定秘密の保護に関する法律」（内閣官房 平成２５年法律第１０８号）
https://www.cas.go.jp/jp/tokutei
himitsu/「特に厳格な管理を要する行政文書の取扱い等に関するマニュアル案（概要）」（内閣府 令和元年
７月２５日）
https://www8.cao.go.jp/koubuniin
kai/iinkaisai/2019/20190725haifu.
html

（第３編第５章 要件定義）

タは、その情報の特徴から他のシステムでも同じような情報が必要になることが多くあります。例えば事業所の例では、一つのシステムに限らず、事業所情報を必要とするシステム
は多数あります。それらシステム毎に事業所のマスターデータを定義していたのでは非効率ですし、また使用するコードや項目も異なり、システム間で情報を連携する場合など、そのままでは情報交換することができなくなります。そういった非効率さをなくし連携までの時間を短縮するためにも、マスターデータは同じ目的で使用したい人達のために、より広いシステムの範囲で同じ内容のものを参照することが重要ということになります。そのレベル
は、地方自治体も含めた国全体で一元化し標準化するべきもの、省庁内で一元化し標準化するべきもの、あるいは部局内同種の業務で一元化し標準化するべきもの、などその標準化の範囲はそれぞれで最適なものを決定していく必要があります。現行システムで既にマスターデータが存在するものについては、その標準化レベルを改めて確認し、最適な標準化のレベルに向けて計画的に改善していきましょう。政府情報システムとしては、自分達主導でより広範囲の標準化を目指すことを基本とします。また、一般公開することで民間の利用も促し、社会全体として効率よくかつ均質化したサービスも提供できるようになります。
●

マスターデータ定義の考慮点
要件定義では、マスターデータとして分類されるものを定義し、その標準化レベルと公開方針等を決定します。分類とその考慮事項は下記を参照ください。

No

マスターデータ定義のケース分け

考慮事項

1

外部から入手（購入あるいは利用）し、そのまま活用する場合

国内外の各種標準や関連団体等を調査し、その更新頻度／更新情報の入手方
法、提供形態、保証／契約、意味定義の明確さ、項目数／レコード数の充足度等を自システムの利用シーンと照らして
決定する。

2

外部から入手し、項目を追加などして活用する場合

１に加え、追加項目の別ファイル／デー
タベースでの管理方法（オリジナルが更新された場合の考慮）、更新同期等を考慮する。

3

自システムで作り公開する場合（他も参照するマスターとして提供）

他システムの要件を満たすための調査あるいは調整有無とその工数・期間、公開
範囲（公開項目）、公開方法（※）、詳細
なメタ情報作成、更新運用等を考慮する。

4

自システムで作り公開しない場合

公開できない理由の明示（１，２あるいは３で、極力他システムとのスムーズな連携の土台となるシステムを目指すこと。）※マスターデータの公開に関しては、オープンデータとしてＤＡＴＡ ＧＯ ＪＰ（データカタログサイト）への公開を推奨する。
●

マスターデータの要件定義書への記載
要件定義としては、データ一覧をマスターデータとマスターデータ以外（トランザクション

データ、入出力ファイル等）に分けて作成し、データ名、概要・用途（メタ情報）、規模情報、
マスターデータ分類、分類選択理由、標準化レベル（国際標準、国内標準、省庁標準、部
局標準）、公開有無と範囲等を記載します。詳細は本ガイドブック別紙「機能要件定義書テ
ンプレート例」の「第５章 データに関する事項」の「データ一覧」を参照ください。
なお、要件定義フェーズではまだ項目の詳細は決まらないかもしれませんが、メタ情報と

-

28 -

表 5-7
マスターデータの分類と考慮事項

（第３編第５章 要件定義）

して可能な範囲で具体的に記述してください。より詳細な設計・導入の手順などは「マスターデータ等基本データ導入実践ガイドブック」を参照ください。

データ項目（コードを含む）の標準化
データ項目とは、情報システム内で取り扱う電子化された情報の基本単位と言えます。
例えば、書籍名、著者名、貸出日、出版社コード等、その各々が異なる一意の対象を表します。また、データ項目の中には、出版社コードのように出版社を特定するためにコードとして表すことも広く使われています。コードはＮ個の記号（例：ＡＢ５ＦＤＳ）やＭ桁の番号（例：９９０５６３）などで表すこともあります。
一方、情報システムでデータ項目を取り扱うということは、紙に書かれた文字情報を人が読むのと大きく異なります。人は紙に書かれた文字の多少の揺れや歪みを理解できるので、「貸出日」と「貸出し日」は表記が異なるだけで同じ意味の言葉であると理解できます。
一方、コンピュータは情報システム内のデータ項目を機械的に読むため、「貸出日」と「貸出し日」を別物として認識してしまいます。データ項目をそれぞれ別物と認識したらそのデータ項目を扱う処理も別となり、大きなトラブルにもなりかねません。よって、情報システムで取り扱うデータ項目は厳格な定義と扱いが求められます。
●

データ項目（コードを含む）の標準化の重要性
データ項目（コードを含む）の中には、他のシステムでも同じ目的で使うものが多くあります。それらの項目は、同じ項目名で同じ意味定義で設計されていると、お互いの連携をス
ムーズにかつ間違いなく行うことができます。つまり、マスターデータと同様に、より広範囲なデータ項目（コードを含む）の標準化を行えば、より効率的に短期間で他との連携ができることになります。また、データ項目やコードを一般公開することで民間での利用も促すことができます。「データ流通時代」と言われる今後のデジタル社会において、常にデータ項目
及びコードを標準化しオープンデータとして公開することを念頭に要件定義を行うことは非常に重要です。
●

データ項目（コードを含む）の標準化の考慮点と要件定義書への記載
要件定義書では主要なデータ項目とコードを洗い出し、発注者としてそれらの定義を行います。最終的には基本設計工程で全てのデータ項目とコードが定義されることになりま
すが、業務上主要なデータ項目とコードについては発注者がその標準化レベルを決め、意味を定義し、事業者に指示する形にすることが重要です。マスターデータと同様に、発注者（自分達）主導でより広範囲の標準化を目指しましょう。また、多くのデータ項目やコードは業務の方向性・範囲と密接に関係していますので、その点でも、発注者側がデータ項
目やコードを定義することで、要件及び仕様の連携が確実かつ正確に行われることにも繋がります。
主要なデータ項目及びコードについては、要件定義書に記載すること。より広い範囲での標準化を目指すこと。
また基本設計工程では全てのデータ項目（コード含む）の厳格な意味定義を行うこと、及び標準化の推進を事業者にも促すこと。
なお、コード及びコード以外のデータ項目標準化に関して、「コード（分類体系）導入実践ガイドブック」、「文字環境導入実践ガイドブック」及び「行政基本情報データ連携モデル」を業務の方向性・範囲に応じて参照することを推奨
する。

-

29 -

（第３編第５章 要件定義）

要件定義としては、「データ定義」に標準化レベル（国際標準、国内標準、省庁標準、部
局標準）、「コード一覧」にコード標準化分類、分類選択理由、標準化レベル等を記載します。詳細は本ガイドブック別紙「機能要件定義書テンプレート例」の「第５章 データに関する事項」の「データ定義」及び「コード一覧」を参照ください。

ライフサイクルを通じたデータの品質確保
異なる機能や画面から同じデータを修正、削除できるようにすることはよくありますが、その際に部分的な観点から処理を行ってしまうとデータの不整合が発生しかねません。
一貫性や完全性等の観点からデータの品質を確保するためには、情報システムの中で扱うデータについて重複なく全体を定義した上で、それらのデータが設計時点だけでなく運用時点でも品質が保たれるようにライフサイクルでの管理を行うことが重要です。
データに関する要件を取りまとめる際には、このような観点を踏まえたうえで、データモデ
ル、データ一覧、データ定義、CRUD マトリクス、コード一覧、コード内容定義、オープンデー
タ一覧等のドキュメントを整備することが重要です。これらのドキュメントは、基本的に１つの情報システムについて１つ作成します（一覧が大きくなり過ぎた場合は、複数に分割する等、工夫することはあります）。また、これらのドキュメント間の整合性を保つとともに、画面や帳票の要件を定義したドキュメントとも整合性を保つことが望まれます。

-

30 -

（第３編第５章 要件定義）

表 5-8
データの要件を取りまとめる際に整備するドキュメント例No.
1

ドキュメント名
データモデル

説明
画面や帳票などに含まれる情報を抜き出して、意味のある単位（識別キー）ごとにまとめた情報の集合体である「データ」と、他のデー
タとの関連を 1 枚に表現した図で、ER（Entity Relationship）図という表記法で記述します。
基本的に 1 つのデータ項目は、必ずどこか１ヶ所のデータのみに属するようにデータを定義します（これを「正規化」と言います）。
データモデルには「概念データモデル」「論理データモデル」「物理データモデル」の 3 種が存在しますが、要件定義では「概念デ

-

31 -

（第３編第５章 要件定義）

No.

ドキュメント名

2

データ一覧

3

データ定義

4

CRUD マトリクス

5

コード一覧

6

コード内容定義

７

オープンデータ一覧

説明ータモデル」を定義する事が多いです。
また、情報システムによっては要件定義時点でデータモデル定義を必要としないものもあります。
データがどのようなまとまりの単位になっているかを一覧形式で示
す表で、データモデルやデータ定義の目次として利用されます。
マスターデータとマスターデータ以外に分け、データの用途や保存期間、データ件数などを定義します。
データ一覧にあるデータのまとまり単位にそれぞれに含まれるデータ項目の内容・説明を示す表です。
１つ１つの項目がどのような意味を持ち、どのような表現やルールで記録されるかなどを定義します。
データが、機能一覧で定義した機能の時系列の流れの中でどう変化するのかを定義します。CRUD とは、C:Create（生成）、R:Read
又は Refer（参照）、U:Update（更新）、D:Delete（削除）の頭文字を取ったものです。
その情報システム内で使用するコードの用途や構造を定義します。
コードの値ごとに意味を持たせた場合の、コード値と意味の一覧です
データ一覧で示したデータのうち、オープンデータとして扱うデー
タの一覧です。
各オープンデータの利用者や実装方式、処理方式を定義します。

これら 7 つのドキュメントの詳細や機能一覧との関係性については、別紙「機能要件定
義書テンプレート例」の「第５章 データに関する事項」を参考にしてください。
後の工程で作られる情報に関する設計書等のドキュメントは、専門的な情報や記法で記載されることが多く、内容を詳しく理解するには難しいものになります。したがって、ここで作成するドキュメントとそれら専門的なドキュメントとの内容を同期させることを事業者に依頼し、専門的なドキュメントを見なくても、要件が充足しているかをチェックできるようにしてください。

参考：砂上の楼閣を防ぐデータ・マネジメント
社会・環境変化に応じてサービス・業務の質を継続的に維持又は向上していくた
めには、サービス・業務を進め方の改善を行う工夫が必要となります。その工夫を生み出すためには、サービス・業務に関係する情報・知識・知恵も必要となります。では、情報・知識・知恵はどうやって生まれるのでしょうか？
サービス・業務の目的に応じて様々な文書や帳票類を作成又は取得するなどし、それらに対しての確認や処理を行い、何らかの結果を生み出してサービス・業務を実施していくことが多いと思います。サービス・業務で扱う文書や帳票類には様々なものがあり、紙で扱うものもあると思いますが、現在ではそのほとんどが文書作成ソフ
トや表計算ソフト等を利用してデジタル処理を行うことが多いと思います。例えば、何らかの数値を集めて統計処理の対象となる統計データの場合には、デジタル処理す
ることがほとんどだと思います。また、行政文書については、公文書等の管理に関する法律（平成二十一年法律第六十六号）第二条において、電磁的記録（電子的方式、磁気的方式その他人の知覚によっては認識することができない方式で作られた記録をいう。以下同じ。）も文書と定義されています。統計データ、電磁的記録による文書、つまりデータを日常的に扱い、サービス・業務を遂行していることになります。
さらに、「世界最先端デジタル国家創造宣言・官民データ活用推進基本計画」（令和元年６ 月 14 日 閣議決定）において、官民データを活用して証拠に基づく政策立案（EBPM）を推進することが示されており、政策立案というより高度なデータ活用が期待されています。

-

32 -参考 5-2
データ・マネジメント

（第３編第５章 要件定義）

サービス・業務の遂行に必要となる Data（データ）、Information（情報）、
Knowledge（知識）、Wisdom（知恵）の関係性を示したのが DIKW モデルです。このモデルは 1980 年代に検討された思考モデルであり、その後改良され多くの分野で定義されていますが、その代表的なものを下図に示します。
DIKW モデルから考えると、「情報」の品質はデータの品質に影響を受け、同様にして「知識」の品質は情報の品質の影響を受け、「知恵」の品質は知識の品質に影響を受けることになります。つまり、全ての土台となるデータの品質が情報・知識・知恵に影響を与えることになるので、品質の悪いデータから導かれた情報・知識・知恵を利用してサービス・業務を遂行する場合には、十分な価値を提供できないと考えられ、砂上の楼閣になりかねません。誤ったデータを利用してデータサイエンスによる高度な分析を行ったとしても、その分析結果が正しいと言えるでしょうか？

サービス・業務の目的の達成に必要となるデータの項目、その意味や内容などを表すデータの定義を十分に行わないと、データを使いたいときにすぐに引き出して利用できない、誤って不適切なデータを利用して誤った結果を導き出してしまうなど
サービス・業務に支障をきたすかもしれません。つまり、品質の低い（不完全な、不正確な、有効期限切れなど）データは、誤用又は誤解を招くリスクがあります。このリスクを回避するためには、場合によっては語の整理を行い、サービス・業務に特化した辞書（用語集）を作成・管理するのもよいでしょう。また、ある意味を表す言葉が 1 語に決まれば問題ないのですが、似た意味を持つ語を複数用いることを許す場合には、カテゴライズして類語辞書を作成・管理することも必要です。
サービス・業務が安定的にその目的を達成していくためには、データの意味定義
だけではなく、入力・取得したデータの中身について次のような評価軸（例）で継続的に確認しつつ、適切に品質を管理することが重要です。
一貫性：データに不整合はないか？一貫して表現されているか？
完全性：データに欠損はないか（全ての要素は揃っているか）？
正確性：表現すべき「現実世界」の対象や事象を正しく表しているか？
精度：データの詳細度（有効桁数等）は十分か？誤りやノイズはないか？
一意性（重複排除）：同じ実体を示すデータに重複はないか？
データ品質を適切に管理するためには、時間推移に伴う社会・環境変化を考慮
し、データの更新・修正のタイミングや廃棄の考え方を検討した上でデータライフサ
イクル（計画、設計と実装、生成・取得、格納・維持、利用、強化、廃棄）の管理を行うことが必要となります。いつまでも古いデータだけを用いていたのでは、適材適所でないサービス・業務を提供するおそれが強まり、目的を達成できずじまいになりかねません。
「デジタル手続法（情報通信技術の活用による行政手続等に係る関係者の利便

-

33 -

（第３編第５章 要件定義）性の向上並びに行政運営の簡素化及び効率化を図るための行政手続等における情報通信の技術の利用に関する法律等の一部を改正する法律（令和元年法律第16 号））」が令和元年５月 31 日に公布されたので、今後、データをさらに活用して行
政のデジタル化を推進していくことになり、これまでの IT ガバナンスの強化だけではなく、データ・ガバナンスの強化も必要となります。加えて、サービス・業務の質を継続的に維持又は向上していくためには、前述したデータの意味定義及び品質管理、
そしてデータライフサイクルの管理を含めたデータ・マネジメントをプロジェクトの全体
を通して行う、全ての土台となるデータの適切なマネジメントが不可欠です。
また、ＰＪＭＯは、調達手続を通じて、サービス・業務企画や要件定義の内容等が事業者に明確かつ十分に伝達されるようにするのと同様に、データ定義を十分に行った上でその内容等を事業者に明確かつ十分に伝達されるようにすることが求められます。このとき、特にデータを活用する実際のサービス・業務に深く関与する制度
所管部門や業務実施部門が主体性を持って対応することが重要です。

参考：コンピュータの内部処理とデータ項目定義
機能要件定義書のデータ定義では、データ項目のデータタイプや桁数等を厳格に定義することが求められています。ここではコンピュータ内部で行われるデータ処理の仕組みを通して、データ項目に対する厳格な定義の重要性を説明します。
よく「コンピュータはデジタルな処理を行う」ということや、「コンピュータは０と１だけで処理を行う」ということが言われています。画面に表示される様々な文字は私たちが読めるような形式になっていますが、０と１だけで処理が行われているというのはどういうことなのでしょうか。
コンピュータ内部では電気的信号で０と１を検出し、その２進数の値を用いて様々な処理を行います。文字を処理する例として、半角文字の‘A’は、コンピュータ内では０と１の集合、つまり２進数で（０１０００００１）２と表されます（ここではＵＴＦ-８という一般的な符号化形式を使用しています）。ただし、２進数で表すと文字列が長くなり分かりづらくなるので、その２進数をさらに変換して１６進数の形式で表すこともよくあります。（０１０００００１）2 を１６進数に変換する場合、4 桁ずつ（０１００）2 と（０００１）２に分けられ、（０１００）2 は（４）16、（０００１）２は（１）16 となり、前者と後者を合わせて（４１）１６となります。
画面上に A という文字が表示されるとき、コンピュータ内部では A という文字を（０１０００００１）2 という０と１の組合せとして扱い、それを処理していることになります。私たちが通常使っている文字には、それぞれこのような値がひとつずつ割り当てられていて、それがコンピュータで内部処理されて画面などに文字として表示されるということになります。
ではなぜコンピュータで扱うデータに対して厳密な定義が重要なのでしょうか。ここでは情報システムでもよく入力する住所を例に説明します。例えば、「１丁目」と「一丁目」は人間には同じものだと理解できても、コンピュータは別のものとして理解し、別の住所として処理をしてしまいます。なぜなら、各文字には先ほど示したコンピュータ内で処理するための一意の値が割り当てられていて、「１丁目」は（ＥＦＢＣ９１Ｅ４
Ｂ８８１Ｅ７９ＢＡＥ）１６、「一丁目」は（Ｅ４Ｂ８８０Ｅ４Ｂ８８１Ｅ７９ＢＡＥ）１６という値で定義され、「１」は（ＥＦＢＣ９１）１６、「一」は（Ｅ４Ｂ８８０）１６とそれぞれ別の値として扱うからです。（下線斜体は説明のため）。よって、本来同一のものとして扱われるべきデータが別物として扱われることにより、同じ住所と認識されず複数存在してしまうというトラブ
ルを起こしてしまうかもしれません。住所の数字を算用数字で表すのか、漢数字で表すのか定義しておくことは重要なことなのです。
その他の例では、半角の‘A’は（４１）１６で全角の‘Ａ’は（ＥＦＢＣＡ１）１６となり、長さも値も全く別物になってしまいます。画面からの入力での全角と半角の違いは、人間にとっては同じことを意味していると認識できても、コンピュータの内部では全く違うものとして処理されるということです。

-

34 -

参考 5-3コンピュータの内部処理とデータ
項目定義

（第３編第５章 要件定義）

ここで、AI を使えば同じ意味だと認識してくれるようになるのではないかという意見もあることでしょう。確かにそのとおりかもしれませんが、AI を使った処理を行うこと
で、コンピュータ内では AI による認識のために多くの処理と時間を要するのです。
文字あるいは項目一つひとつに AI 処理を施すとすると、莫大な処理時間あるいは高い処理性能が必要になります。
コンピュータは、基本的に０と１の組合せ列を素早く単純に処理する能力に長けています。私たちはそのようなコンピュータの内部処理を意識せずに使っていますが、この「単純で速い機械」（＝コンピュータ）を最大限に活用するためには、そこで処理させるデータの名称や意味、範囲に対する厳格な定義が非常に重要ということです。同様に、複数のコンピュータ間でデータをやり取りする場合でも、そのデータ一
つひとつの定義が重要になります。標準化された、つまり同様の定義が与えられたデータを使うということがまさにデータ連携、データ流通を支える最も基本的かつ重要な事項です。
このようなコンピュータの内部処理を理解したうえで、情報システムの要件定義を行っていきましょう。

E. 外部インタフェースに関する事項
情報システムの外部インタフェースとは、サービス・業務の内容を実現するために、自分の情報システムが他の情報システムと連携して情報を受け渡す仕組みです。情報連携の内容や形式・仕組みには様々なものがあり、明確に定義する必要がありますが、連携先である他の情報システムの都合もあるため、双方の要件を出し合い、すり合わせることが必要となります。
この外部インタフェースに関する要件を取りまとめるドキュメントは、一般的に外部インタ
フェース一覧と呼ばれるものです。情報システム機能要件一覧との整合性も意識しながら作成を進めます。
外部インタフェース一覧では、他の情報システムと連携する全ての情報をそれぞれの情報の単位で定義し、一覧化します。これにより、情報ごとの相手先情報システムや送受信のタイミング、条件等を把握できます。
外部インタフェース一覧は、基本的に１つの情報システムについて１つ作成します（一覧が大きくなり過ぎた場合は、複数に分割する等、工夫することはあります。）。一覧では、１
連携情報を１表現し、対象とする情報システムと他の情報システムと連携が全て記載されます。要件には、連携先の情報システムとの送受信のタイミングや送受信の際の条件も、明確にして定義します。
なお、連携先となる情報システムの要件が確定していない等により、要件定義の段階で定義できない外部インタフェースの内容については、その理由を記述します。また、障害発生時や緊急時の代替手段が規定されていれば、それらも記述します。
外部インタフェース一覧で記載した連携は、情報システムが出来上がってからのテスト

-

35 -

（第３編第５章 要件定義）において、１つ１つテストを実施する必要があります。相手先の情報システムが同時に構築中の場合や改修が行われた場合等により、要件定義時に合意した内容が時間の経過とともに変更されていることがあります。連携先との意思疎通が不十分なときは、情報システム
がリリースされて初めて問題に気付くことも少なくありません。
そういったトラブルを未然に防ぐために、事業者や相手先情報システムのＰＪＭＯと連携
して、意思疎通が不十分とならないよう対策をしてください。

No.

1

外部
インタ
フェ
ース
ＩＤ
XXXX

外部
インタ
フェ
ース
名
申請
者情
報連
携

2

XXXX

申請
結果
連携

3

・・・

・・・

外部インタ
フェース概
要

相手
先シ
ステ
ム

送受
信区
分

実装
方式

送受
信デ
ータ

送受
信タ
イミン
グ

送受
信の
条件

申請の審査
に関わる申
請者の情報
を○○シス
テムから日
次で取得す
る。
審査におい
て承認され
た申請情報
を○○シス
テムに日次
で提供す
る。
・・・

○○
シス
テム

受信

ＡＰＩ

申請
者情
報

リア
ルタ
イム

日次

○○
シス
テム

送信

ファ
イル
共有

承認
済申
請情
報

リア
ルタ
イム

日次

・・・

・・・

・・・

・・・

・・・

補
足

表 5-9
外部インタフェース一覧

情報システム関連図で連携イメージが伝わるようにする
新たに整備する情報システムと他の情報システムとの連携は、情報システム関連図を作ることで、イメージが伝わりやすくなります。
この図を中心とし、次に示す点に留意して、表 5-9 に示す外部インタフェース一覧に要件を整理します。
データ互換性の確保のためにデータ変換が必要となる場合が多いことから、やり取りするデータだけでなく、物理的なインタフェース、プロトコル、フロー
図、文字コード、データフォーマット、取り扱う値の範囲、通信の速度等について、可能な限り詳細に記載する。
双方の情報システムが取り扱う情報の格付の区分等が異なる場合に、機密情報を連携することにより情報セキュリティ対策が不十分とならないよう、連携の方向や内容等に十分留意する。
データベースの所在国についても十分に留意する必要がある。例えば、個人情報保護法第 2 条第 2 項に規定する個人情報又は番号法第 2 条第 5 項に規定する個人番号を蓄積するデータベースについては、国内法が適用される
場所に制限する必要があることを認識し、問題がないことを確認することが考えられる。
要件定義の段階で定義できない外部インタフェースがある場合には、その理

-

36 -

注記
プロトコルとは、情報システムを構成する機器同士が通信をする際の手順や規約などを定めたもの。ネットワーク間で双方の機器が理解できる同じプロトコルを使わないと通信は成立しないため、インターネット上のプロトコルの大部分は RFC という形式で技術仕様が公開されている。

（第３編第５章 要件定義）

由を含めて記載すること。
障害発生時や緊急時の代替手段が規定されている場合は、それらも記載すること。

２ 必要な機能を漏れなく抽出し検討する【標準ガイドライン関連箇所：第３編第５章第２節 1)イ】

要件定義を進めていくと陥りやすいのは、優先度の高いやりたい事だけを定義してしまうことです。業務要件では、毎日行う業務ばかりに議論が集中して、日常的に実施頻度の少ない業務の議論は後回しになりがちですが、機能要件でも同様のことが発生します。

事例：要件の考慮不足が設計開発工程の遅延に繋がる
従来、紙で取り扱っていた申請書の管理を、オンライン入力してデータ保存できるサービスを構築することにしました。
テストの段階で、申請者が届出書に記載した内容に誤りがあった場合や、職員が情報を入力する際に間違ってしまった場合等に関する考慮が不足しており、情報シ
ステムにも修正や削除をする機能が備えられていないことが明らかになりました。従来から修正や削除の処理はありましたが、紙処理での手作業の場合は自由に作業ができたため、業務マニュアルには削除等の対応方法は記載されていませんでした。その業務マニュアルどおりにシステム機能を検討してしまったために、必要な機能の考慮が漏れてしまったことが原因でした。

その結果、業務手順の見直しから機能の検討、追加の設計・開発、テスト等が必要となり、リリース時期に影響を与える程のスケジュール遅延が発生してしまいました。
手作業の業務をシステム化検討する際は、通常よく行う作業（上記の例では、入力や参照）だけではなく、業務マニュアルに記載されていなくても職員が暗黙的に行っている作業（上記の例では、申請内容の誤りや間違いへの対応）も含めて検討し、作業を漏れなく洗い出す必要があることに留意してください。

画面操作を例とすると、基本的な機能やよく使う機能の要件は忘れない代わりに、めったに発生しないデータの処理手順や誤入力した際の回復処理については議論が抜けがちになります。これらは要件定義漏れとして、テストをすり抜け、リリース後発覚してトラブルとなる
おそれがあります。
誤入力の回復が簡単にできないと職員が認識している場合、本来行う基本的な業務で過

-

37 -

事例 5-2
要件の考慮不足がスケジュール
遅延に繋がる（第３編第５章 要件定義）度に慎重になってしまい、その業務のシステム利用が敬遠されてしまうことも考えられます。また、特別な処理が必要になったときに、運用事業者によるデータベース操作によるデータ補
正等のアプリケーション機能以外での対応が必要となり、運用・保守費用の増大に繋がりかねません。
このような事態に陥らないためには、業務要件から機能要件を抽出する際、業務の流れに沿った通常のシステム操作パターンを十分に検討し、発生し得る操作を漏れなく抽出することが重要です。また一方で、非常に頻度の低い操作や、回復処理を全て機能として盛り込む
必要はありません。発生頻度が極度に低いものは、運用対応と判断して妥当な場合もあります。
「人は間違うもの」という前提で、「ここで間違えたらどうやって訂正する？」「一連の操作を丸ごと取り消ししたくなったら？」等を抽出して、特殊な操作や回復方法を適切に検討しましょう。

３ 実現手段ではなく、求める結果を記載する【標準ガイドライン関連箇所：第３編第５章第２節 1)イ】

要件定義では、その情報システムが「どのように処理するか」ではなく、「結果としてどうなるか」を定義します。これは、要件定義段階で実現手段を定義してしまうことで、情報システムの専門家である事業者が、最適な実現手段を提案できなくなってしまうためです。
特に、新規構築ではなく、既存の情報システムの更改をする際には注意が必要です。既存の情報システムに問題があるにもかかわらず、使い慣れていることを理由に既存の情報シス
テムの機能を踏襲して要件を記載してしまうことがあるためです。
このように記載してしまうことで、新たな形での機能提案が得られず、新しい情報システムに
既存の情報システムの悪い面が継承されてしまい、更改の目的が果たされないこととなります。また、新システムで提案される新しい方式では、既存システムで行っている処理が不要になる可能性がありますが、要件として記載されていた場合、設計・開発事業者がその処理を不要と判断することが難しくなります。
既存の情報システム関連資料は、新たな情報システムを設計・開発するための重要な情報であることは間違いありません。ただし、これらは参考資料として提示し、既存の情報システムと機能を同一にする必要はないことを明示してください。

-

38 -

（第３編第５章 要件定義）

Step.

6 非機能要件の定義

既に定められた業務要件に基づき、業務要件を満たすために情報システムの非機能に求められる要件を定義していきます。
ところで、非機能とはなんでしょう？機能は想像がつきやすいと思いますが、非機能となるとどんなことを決めたらよいかわかりづらいですよね。
情報システムの専門家ではない職員のみで、多岐にわたる非機能要件を全て定義することは、通常困難です。技術的な厳密な定義を説明してもさらにわかりづらくなると思いますので、発注者側にとってわかりやすい具体例を示しながら非機能を説明しつつ、その要件として何を定義しなければならないかを解説していきます。

１ 個々の領域について要件を定める【標準ガイドライン関連箇所：第３編第５章第２節 1)ウ】

非機能要件として定義しないといけない内容は次に挙げる 17 個の内容（A～Q まで）です。
機能要件の場合は、内容の一部を定義せず、調達時の事業者の提案に委ねることもありま
すが、非機能要件の場合は基本的に全ての項目を定義します。もちろん、情報システムやプ
ロジェクトの特性によって、定義すべき内容の量は異なります。
項目は細分化されていますが、実は経験的に理解している内容が多くありますので、それらを見ていきましょう。

A. ユーザビリティ及びアクセシビリティに関する事項
情報システムは、提供するサービス・業務の利用者が、使いやすいと実感することにより利用が促進され、使いやすさは利用者の満足度や業務効率の向上に大きく寄与します。
本項では、「使いやすさ」をユーザビリティとアクセシビリティという２つの軸で明らかにします。
ユーザビリティとは、利用者がサービス・業務を利用して実施したいことを、ミスなく効率的に行うために必要となる事項であり、アクセシビリティは、目的の情報へのたどり着きやす
さを指します。どちらも利用者の年齢、身体的制約、利用環境等の違いによる配慮が必要
です。

No.
1

利用者区分
○○申請者

利用者の種類2○○入力担当
者

・・・

3

○○決裁者

・・・

4

・・・

・・・

・・・

特性
60 歳以上の割合：○○％業務の環境上、片手で必要な入力を行う必要がある
マウス入力が困難な環境で使用する対象手続に関する知識レベ
ルが高い
・・・

-

39 -

補足

表 5-10
情報システムの利用者の種類、特性

（第３編第５章 要件定義）

次に整理した特性をグループ化して、ユーザビリティ、アクセシビリティの分類を作成します。例えば画面の構成や操作のしやすさ等を分類として定義し、次に分類ごとにどのような使いやすさを実現したいかをユーザビリティ要件として示します。
また、当該情報システムの特性に鑑みて日本産業規格（JIS）への準拠や多言語対応等の要件を整理し、情報へのアクセスの容易さをアクセシビリティ要件として示します。アクセ
シビリティ要件の検討に当たっては、「ウェブアクセシビリティ導入ガイドブック」が参考にな
ります。

No.
1

ユーザビリティ
分類
画面の構成

2

操作方法のわかりやすさ

3

指示や状態のわ
かりやすさ

4

エラーの防止と
処理

5

ヘルプ

No.

アクセシビリティ
分類
基準等への準拠

1

注記「ウェブアクセシビリティ導入ガイ
ドブック」
https://www.digital.go.jp/resourc
es/introduction-to-webaccessibility-guidebook/

ユーザビリティ
要件
何をすればよいかが見て直ちにわかるような画面構成にすること
無駄な情報、デザイン及び機能を排し、簡潔でわかりやすい画面にすること十分な視認性のあるフォント及び文字サイズを用いる
こと
画面の大きさや位置の変更ができること
無駄な手順を省き、最小限の操作、入力等で利用者が作業できるようにすること
画面上で入出力項目のコピー及び貼付けができること
業務の実施状況によっては、ショートカットや代替入力方
法が用意されること（例えば、片手だけで主要な操作が完了することが求められたり、マウスを利用することが困難であったりする場合が考えられる）操作の指示、説明、メニュー等には、利用者が正確にその内容を理解できる用語を使用すること
必須入力項目と任意入力項目の表示方法を変えるな
ど各項目の重要度を利用者が認識できるようにすることシステムが処理を行っている間、その処理内容を利用者が直ちにわかるようにすること利用者が操作、入力等を間違えないようなデザインや案内を提供すること
入力内容の形式に問題がある項目については、それを強調表示する等、利用者がその都度その該当項目
を容易に見つけられるようにすること
電子申請等については、確認画面等を設け、利用者が行った操作又は入力の取消し、修正等が容易にできるようにすること重要な処理については事前に注意表示を行い、利用者の確認を促すこと
エラーが発生したときは、利用者が容易に問題を解決できるよう、エラーメッセージ、修正方法等について、わかりやすい情報提供をすること利用者が必要とする際に、ヘルプ情報やマニュアル等を参照できるようにすること

補足

表 5-11
ユーザビリティ要件

アクセシビリティ
要件
広く国民に利用され公益性の高い情報システムであるため、日本産業規格 JIS X 8341 シリーズ、「みんなの公共サイト運用ガイドライン」（総務省）、ＸＸ省ウェブアクセシビ
リティ指針等に従い、アクセシビリティを確保した設計・開発を行うこと（※引用した基準は例示である）

補足

表 5-12
アクセシビリティ要件

-

40 -

（第３編第５章 要件定義）

No.
2

3

アクセシビリティ
分類
指示や状態のわ
かりやすさ

言語対応

アクセシビリティ
要件
色の違いを識別しにくい利用者（視覚障害のかた等）を考慮し、利用者への情報伝達や操作指示を促す手段はメッ
セージを表示する等とし、可能な限り色のみで判断するようなものは用いないこと
本情報システムでは、日本語のほか、ＸＸ語で記載されたコンテンツに対応すること

補足

B. システム方式に関する事項「システム方式」では、定義された業務要件のうち、情報システムが処理・実行する範囲
について、情報システムとして動作するために必要となる「道具」の具体的な実現方法を明確にします。

No.
1

2

3

全体方針の
分類
システムアーキテ
クチャ
アプリケーション
プログラムの設
計方針
ソフトウェア製品の活用方針

システム基盤の
方針

全体方針

補足

本情報システムのシステムアーキテクチャは、【メインフレーム型／クライアントサーバ型／Ｗｅｂサーバ型／外部サービス利用型／スタンドアロン型】とする
情報システムを構成する各コンポーネント（ソフトウェアの機能を特定単位で分割したまとまり）間の疎結合、再利用性の確保を基本とする
広く市場に流通し、利用実績を十分に有するソフトウェア
製品を活用するアプリケーションプログラムの動作、性能等に支障を来た
さない範囲において、可能な限りオープンソースソフトウェア（ＯＳＳ）製品（ソースコードが無償で公開され、改良や再配布を行うことが誰に対しても許可されているソフトウェ
ア製品）の活用を図る。ただし、それらのＯＳＳ製品のサポートが確実に継続されていることを確認しなければならないクラウドサービス提供者が提供するサービス・機能を最大限活用した構成とするツール等を利用し、システムライフサイクルコストを削減する
アプリケーションの開発ツールは日々進歩しています。例えばノンプログラミングによる画面生成等プロトタイピング用のツール等を利用することにより、コストの削減等が見込める場合等には、積極的に採用を検討してください。
ＲＦＩ等を通じて事業者から得た情報を踏まえ、実現性が十分であること及びコ
スト効率を高めることを基本として方針を検討する。また、必要に応じて新技術の適用可能性も検討する。
システムアーキテクチャ及びシステム基盤の方針の検討は、クラウドサービスの活用も踏まえて行う。
ソフトウェア製品の選定においては、機能要件や非機能要件から適切なソフト
ウェア製品を選定できるよう、留意する。

C. 規模に関する事項「規模」とは、情報システムを使うユーザの数や取り扱う情報量を指します。利用者が多

-

41 -

表 5-13
情報システムの構成に関する全体の方針

（第３編第５章 要件定義）

ければ単位時間当たりで多くのリクエストを処理できる能力が必要となりますし、情報量が多ければ、より大容量のデータベース等が必要になります。要件定義では「利用者は最大100 人、平日は常時 80 人、土日は基本的に休みのため 10 人未満」といった要件を定量的に示します。
次に示す各表では、機器やデータ等の量について整理し、想定可能な最大値を要件として示します。

No.
1
2
3

機器の区分
クライアント端末
プリンタ
・・・

機器の用途
窓口入力用
証明書出力用
・・・

No.
1
2
3

データ区分
操作ログ
○○用データ
個人用フォルダ

最大 XXMB最大 XXMB最大 XXMB

No.
1

項目
アクセス数

2
3

○○操作件数○○処理件数

No.
1

利用者区分
○○申請者

2

○○入力担当
者
○○決裁者

3

機器数
XX
XX
・・・

設置場所
本省○階○○室
○局○○室
・・・

補足

表 5-14
機器数及び設置場所

補足

表 5-15
データ量

処理件数
定常時：XX 件/日
ピーク時：XX 件/日
ピーク特性：○月に年間の処理の XX％が集中
・・・
・・・

補足

表 5-16
処理件数

利用者数
同時アクセス可能人数：XX 人
アクセスの同時到達量：XX 回/min
利用時間帯：XX 時～XX 時
・・・

補足

表 5-17
利用者数

データ量

・・・

過度の規模要件は、過度の情報システム投資を招く「大は小を兼ねる」と言いますが、過大は無駄を招きます。「十分な」といった曖昧な表現を避け、「○○人」「××件」といった定量的な表現とすることで、適切な規模要件を設定してください。
情報システムの規模は、性能や信頼性に関する要件を検討する際の前提条件であり、機器の仕様や配置等の設計、調達コストに影響を与える。
過度の規模要件を規定することは、過度の情報システム投資を招くことになる。

設置場所を開示するべきでない場合の記載方法
設置場所が不特定多数の者に知られることが情報セキュリティ上問題あるサーバ等の機器については、「○○県内」「東京都 23 区内」といった記載にとどめ、詳細については契

-

42 -

（第３編第５章 要件定義）

約締結後、受注者のみに開示するものとし、設置場所が特定できないように配慮してください。
建物やフロア等、ネットワーク接続要件を考慮して、設置場所を記載する。例）
厚生労働省 X 階 XX 室、XX 局 XX 室
情報セキュリティの観点からみて、設置場所を明示する場合、設置場所に関する情報は広く一般に公開するものではない。このため、この情報については、非開示覚書(NDA)を交わした上で、閲覧等によって開示することを考慮する。

D. 性能に関する事項「性能」とは、情報システムの能力を指します。能力を測る指標には、応答性能やスルー
プット（処理性能）等があります。ネットショッピングで例えると、商品を検索し検索結果のリストが表示され、特定の商品を選択すると詳細情報が表示される、という一連の流れが一般的ですが、検索ボタンや選択ボタンを押してから、次の画面が表示されるまでの時間が応答性能です。スループットは、一度にどれだけの量を処理できるかという性能で、通常時でも大量に注文が発生するバーゲンセール開催中でも、定義した応答性能が担保されるということを表します。経験があるかもしれませんが、ネットショッピング中に検索結果が返ってこないと、購買する意欲が下がってしまいます。性能はサービス・業務の質に大きな影響を与えます。また、スループットを担保するためには、ハードウェアや回線増強等の投資が必要です。
性能に関する事項は、費用と性能のバランスをとって定義しましょう。

No.
1

設定対象
○○処理

2

指標名
レスポンスタイム
ターンアラウンド
タイム
サーバ処理時間

3
4

○○処理

5

目標値
定常時：X 秒以内
ピーク時：X 秒以内
定常時：X 秒以内
ピーク時：X 秒以内
定常時：X 秒以内
ピーク時：X 秒以内

レスポンスタイム

No.
1
2

設定対象
○○処理

補足

表 5-18応答時間

補足

表 5-19スループット90％
平均値
90 パーセンタイル
90 パーセンタイ
ル
平均値

ターンアラウンド
タイム
サーバ処理時間

6

応答時間達成率90％

目標値
XX 件/秒

多機能化で情報システムの性能が大きく劣化しないようにする
ユーザ要望や企画の実現、運用保守コストを削減するために、複数の画面や帳票の統合を検討することがありますが、統合することにより、次に示すようなデメリットが発生することもあります。

-

43 -（第３編第５章 要件定義）

１つの画面や帳票で取り扱う項目や機能が増えるため、画面の表示や帳票出力までの処理に時間がかかるようになる。
システム処理そのものに加え、途中で発生したエラーのリカバリー処理も統合することにより複雑化するため、テスト工数の増大も含め、かえって保守コストが増加することもある。
このような事態を避けるために、画面標準等で、１つの画面や帳票に盛り込む情報量の基準の設定や、現在画面や帳票が分割されている理由を、業務面だけではなくシステム
面からも確認しておくことが重要です。
現場の職員は１つの画面や帳票で多岐に渡る業務を行いたいと要望しがちですが、視認性や操作性の観点から、ストレスを感じることなくスムーズに使える範囲内で、適切に分割する方が有効です。

事例：非機能要件が機能要件に影響することもある
ある省の既存情報システムを更改するプロジェクトにおいて、改善検討を行うことになりました。現状調査の結果、画面で指定する組織名称のプルダウンの内容が異なるだけで、他の項目はほぼ同一の類似した画面が複数存在していることが判明しました。保守コスト削減の観点から、類似画面を統合することにしました。
その結果、統合した画面では、組織名称のプルダウンに全組織（数千）が表示されることになり、画面表示時に大量の組織名称の情報を取得するため、画面表示までの性能が大幅に劣化し、当該画面を通じて行う業務の効率が低下してしまいました。

機能要件では問題がないと見える事柄も、非機能要件では全く違った影響が発生することがあります。この例では、非機能要件のうち、規模に関する事項を検討することで機能要件自体の見直しが発生しました。既存情報システムがある場合は、非機能面において現在の仕様になっている経緯や背景も確認した上で、改変を行い
ましょう。

-

44 -

事例 5-3
非機能要件が機能要件に影響することもある（第３編第５章 要件定義）

想定値ではなく実測値等から真に必要とされる性能を指定する
性能を検討していくと、つい安全な方向に結論を倒しがちです。性能の指定においては想定値ではなく、実測値等から真に必要とされる性能が指定できるよう、留意してください。
要求事項の記載は、できるだけ定量的な表現となるようにすること。
過度な性能要件を設定して調達コストを押し上げることのないよう性能要件の指定においては想定値ではなく、実測値等から真に必要とされる性能が指定できるよう、留意すること。
常時・定期のモニタリングが必要な場合には、個別部分の性能、トランザクショ
ン量等について明示し、組み込みの必要性を指定すること。

事例：概念検証により性能要件の実現可能性を確認する
ある情報システムは、不特定多数の国民が同時に利用し、業務の特性上、高速なレスポンスが求められ、うまく動作しない場合には利用者に大きな混乱を招くおそれがあったことから、非機能要件の中でも特に性能面が重要でした。加えて、この情報システムは内部で複数の情報システムと連携した上で利用者にレスポンスを返す仕組みであったため、性能面で問題が発生する可能性が高いと考えられました。しかし、当該情報システムは、新規に構築するものであったため現行システム等の実測値から性能要件の実現可能性を判断することが困難でした。そこで、当該情報シス
テムの設計・開発を行う前に概念検証（PoC）を実施し、性能要件の実現可能性を検証することにしました。
概念検証では、実際の情報システム間の連携を再現した簡易な情報システムを構築し、想定される最大の負荷をかけた状態で目標とする性能要件が実現可能かを検証しました。概念検証において性能を低下させる要因の特定と排除といった改善活
動を繰り返し行うことで、最終的には目標値を大幅に上回り、性能要件が実現可能であることが確認できました。
また、概念検証を実施することで、発注者が実際の情報システムの利用場面をより具体的にイメージできたので、新たな機能追加等の要望が発生し、それらを盛り込
むよう要件をブラッシュアップすることができたという副次的効果もありました。
現行システムがなく実測値の測定が困難な情報システムの場合には、性能要件の想定値を指定して設計・開発に着手することが多いですが、社会的な影響が大きい
情報システムや性能によって評価が左右される情報システムなどでは、概念検証によって性能要件の実現可能性を検証することも有効です。

E. 信頼性に関する事項「信頼性」とは、情報システムが持つ故障への耐性の度合いのことを指します。一般的には平均故障間隔（分又は時間）で評価します。平均故障間隔の値が小さければ小さいほど信頼性は高いと言えます。
情報システムを、構成する要素（サブシステムやネットワーク等）に分解し、情報システム

-

45 -

事例 5-4
概念検証により性能要件の実現
可能性を確認する

（第３編第５章 要件定義）

全体での年間稼働率を踏まえて、各要素の信頼性に係る指標や目標値を要件として示します。

参考：最適なシステム構成
情報システム全体の信頼性はサーバや周辺機器、クラウドサービスだけでなく、サービス提供者と利用者を結ぶネットワーク等を含めて検討する必要があります。
例えば以下のような稼働率の要素で構成されたシステムは、サーバはシックスナイ
ンの稼働率を確保していますが、ネットワークや負荷分散装置を含めた稼働率はスリーナインを下回っています。

このように、局所的に高い稼働率を確保しても、他の構成要素の稼働率が低ければシステム全体の稼働率は低くなります。
高い稼働率を確保するには、信頼性の高い機器や冗長な構成が必要となり、コストがかかるため、過剰な構成とならないよう、業務要件に沿った設計が重要です。デジタル・ガバメント推進標準ガイドラインでは、情報システムに求められる稼
働率について、以下のような参考情報を示しています。

表 1 システムプロファイル
分類

判断要素

Type
Ⅳ

サービス停止等が起きた場合、これにより人命損害が発生する可能性があるもの
又は想定される経済的損失が甚大であるもの

Type
Ⅲ

サービス停止等が起きた場合、これにより身体への悪影響が発生する可能性があるもの又は想定される経済的損失が大きいもの

Type
Ⅱ

サービス停止等が起きた場合、これにより経済的損失が少なからず発生するもの

Type
Ⅰ

TypeⅡからⅣまでに該当しないもの

-

46 -

参考 5-4
最適なシステム構成

（第３編第５章 要件定義）

表 2 システムプロファイルから考えるシステム基盤に係る非機能要件のモデル
No.

大項目

1

主な非
機能要
求項目

TypeⅠ

稼働率

・1 年間で数日程度の停止まで許容できる（稼働率 99%）。

・1 年間で 1 時
間程度の停止まで許容できる（稼働率 99.99%）。

・1 年間で数分間程度の停止まで許容できる（稼働率 99.999%）。

障害目
標復旧
水準

・データのリカバリーを伴う復旧において、週次のバックアップデー
タからの復旧を行う。

・データのリカバリーを伴う復旧において、1 営業日以内での復旧を目標とする。

・データのリカバリーを伴う復旧において、数時間で障害発生時までの復旧を目標
とする。

TypeⅢ
TypeⅡ
TypeⅣ

可用性

2

表：デジタル・ガバメント推進標準ガイドライン（別紙５）から一部抜粋
信頼性の高いシステムは構築だけでなく、維持にもコストがかかります。業務要件の求める稼働率を大きく上回るような過剰な設計とならないように留意しましょう。

No.
1

設定対象
○○サービス2○○サービス

指標名
平均故障間隔（MTBF）
平均修復時間（MTTR）

目標値
平均故障間隔は 8,760 時間
以上
平均修復時間は 24 時間以
内
・・

補足

F. 拡張性に関する事項「拡張性」とは、情報システムの運用開始後に性能又は機能を向上させる場合に、容易に対応できる度合いを指します。性能については、将来の利用者の拡大やデータ量の増加に備えて、情報システムの処理性能を維持するためのハードウェア、ソフトウェアの対処

表 5-20
可用性要件
注記
ＭＴＢＦとは、システムが故障するまでの平均間隔のこと。
ＭＴＢＦは Mean Time Between
Failures の略。
注記
ＭＴTR とは、システムを復旧・修理するまでにかかる平均時間のこと。
ＭＴTR は Mean Time To Repairの略。

方針を、要件として定量的に示します。機能については、将来の制度改正や技術の変化等に備えて、容易に改修を行うための設計指針やアプリケーションの改修方針を示します。想定する拡張が必要となるケースを、提供するサービスや業務と併せて具体的に記載することが重要です。「利用者数が X 倍になる」だけではなく、「○○サービスを利用する部署が Y 倍になるため」といった、拡張の背景を記載することにより、設計時に考慮しやす
くなります。

参考：拡張性要件の記載例
ＸＸ年に予定される全国展開が完了した場合、利用者数が 1.5 倍になると想定されるが、これに伴い性能が落ちることのないよう、処理能力の向上やデータ保存

-

47 -

参考 5-5
拡張性要件の記載例

（第３編第５章 要件定義）

領域の拡張等が容易に可能な構成とすること。
本情報システムの刷新は、全国の拠点を地域で分割して段階導入を行うため、その段階導入のタイミングと併せて、ネットワーク機器やサーバ機器の予備のポートやスロットを用いて適宜最適な拡張が可能な構成とすること。

参考：変化に強い情報システムの構築

参考 5-6変化に強い情報システムの構築

社会情勢の変化や利用状況の変化に対応して情報システムを改修する際、拡張性が低いと改修に時間がかかったり、大きなコストがかかったりしてしまいます。このような改修を迅速に低コストで実現できる、変化に強い情報システムを構築する
ためには、どのようなことに留意すればよいのでしょうか。
以下では、情報システムの構築における工夫をいくつかご紹介します。
・

想定される変化を要件として示す
要件定義の段階で、制度改正による計算式の変更のような将来起こり得る変化とともに、それらの変化への効率的な対応を拡張性要件として定めることが重要です。そして、これらの要件を実現するための工夫を技術審査における評価項目とすることで事業者の創意工夫を引き出すことができます。
ある情報システムでは、定期的に発生する制度改正のたびに高額の改修コストがかかっていたことに加え、制度改正の成立日から施行日までの期間が短いため改修を短期間で行うことが負担となっていました。
情報システムの刷新にあたって、制度改正の発生時期や改修にかけられる期間の短さなどを調達仕様書に具体的に提示した上で、解決方法の提案を事業者に求めたところ、ある事業者からＢＲＭＳ（ビジネスルールマネジメントシステム）の利用が提案されました。
ＢＲＭＳは業務を遂行する上での判断条件及び処理（ビジネスルール）をアプリ
ケーションから切り離して管理し、それらを表形式等で可視化します。制度改正等
でビジネスルールを変更する際もコーディングなしにツール上で変更できるため迅速に対応することが可能です。
当該事業者の提案どおりＢＲＭＳを採用したところ、制度改正の対応にかかるコストを削減でき、短期間での対応も可能となりました。
なお、拡張性要件を定める際に、想定されるあらゆる変化への対応を求めると、構築コストが高額になってしまうおそれがあるため、影響範囲の大きい変化や、発生する可能性が高い変化などの観点で、本当に必要なものに限定することが必要です。
・

変化に柔軟に対応できるシステム構成を採用する
システム構成に関する工夫として、情報システムのうち変更が生じやすい箇所
は、一から開発するのではなく、既存のツールやサービスを採用するという方法があります。
例えば、セキュリティ対策として ID／パスワードによる認証から多要素認証へ認証方法を変更する可能性がある場合などには、主体認証にクラウドサービス（IDaaS）を採用するという方法があります。認証方法を変えたいときには、クラウドサ
ービスの設定を変更すればよく、作り込んだ認証機能を改修する場合に比べて簡単です。
また、クラウドネイティブと呼ばれるクラウド環境に最適化した設計・構築を行う方
法もあります。具体的には、マイクロサービス、ＣＩ／ＣＤ、ＩａＣなどがあり、疎結合化、自動化等を組み合わせることで、環境の変化に対して迅速かつ少ない労力で対応できるようになります。
・変化に対応しやすい設計・開発を行う

-

48 -

注記
ＢＲＭＳにおける、業務プロセス
内の条件および処理の例として、
勤怠管理システムにおける＜「18時 15 分以降の勤務時間」（条件）は「残業時間とする」（処理）＞というルールが挙げられる。組織内
で 17 時 45 分以降の勤務を残業時間として扱うようにルールが変更された場合は、表などに示された条件を変更することで対応できる。

注記
CI/CD とは、「Continuous
Integration／Continuous
Delivery」の略称。アプリケーショ
ンを改修する際に発生するビル
ド、テスト、デプロイなどの作業を自動化することなどによって、継続的に（頻繁に）アプリケーションの改善を可能とする手法。
注記
IaC とは、「Infrastructure As
Code」の略称。従来は手作業で行っていた OS、ミドルウェア等の導入や設定をコードで表現し、そのコードを実行することで自動的にインフラを構築する技術のこと。

（第３編第５章 要件定義）

設計・開発の段階では、ハードコーディングに注意する必要があります。ハードコーディングとは特定の値やメッセージなどをソースコードに書き込むことであり、変更が生じやすい値などをハードコーディングすると、変更が生じるたびにアプリケー
ションの改修が必要になります。
ハードコーディングを避ける工夫の一つに、外部ファイルを参照させる方法があります。変更を行うときは、ソースコードを修正しなくても、参照させる外部ファイルに手を加えればよいため、変更の負担が少なく済みます。
なお、せっかく外部ファイルを参照させる方法を採用しても、外部ファイルを変更
するたびに情報システムが正常に動作するかを細かくテストしていては、ハードコー
ディングと変わらなくなってしまいます。運用開始後はそのようなテストができるだけ不要となるように、外部ファイルの値を変更しても情報システムが正しく動作するかを設計・開発の段階でテストしておくことが必要です。
また、情報システムが簡易なものであれば、コーディングに代わる開発手法として、ソースコードの記述なしで開発が可能なノーコード開発も選択肢の一つとなります。ノーコード開発では、あらかじめ用意されているパーツをドラッグ・アンド・ドロッ
プするなどの直感的な操作で開発するため、変更が生じた際にもソースコードを修正する必要がありません。

G. 上位互換性に関する事項「上位互換性」とは、主にソフトウェア製品において、新しいバージョンの製品で古いバージョンの製品が利用できることを指します。代表的な製品は上位互換性がありますが、バージョンアップに伴い、帳票作成ツールの場合レイアウトが崩れたり、ブラウザの場合画面のレイアウトや特定のボタンが動作しなくなったりといった、一部の機能に限り上位互換性がないこともあります。
当該情報システムを構成するソフトウェア製品において、将来予想されるバージョンアップ時の対応可能性について、定義時点において明確にできる範囲内で、具体的な対象とバージョンアップ時の対処方針を要件定義書に記載します。

各製品のバージョンアップポリシーを踏まえて、コストを検討する
機能追加等のバージョンアップが頻繁に行われる製品を利用する場合、バージョンアップ後のテストに係るコストが膨大なものとなり、費用対効果が著しく悪化する可能性が高くなります。
したがって、製品の選定に当たってはバージョンアップ後のテストの簡略化等を検討するとともに、費用対効果が見込める場合には、OS・ミドルウェア等の乗換についても積極的に検討してください。
バージョンアップは将来の不確定要素であることから、上位互換性を過度に要求する場合、事業者が応札に対して慎重になる可能性や、リスクを見込んだ
高額な調達コストとなる可能性があることに留意する。

参考：上位互換性要件の記載例
クライアントＯＳのバージョンアップに備え、ＯＳの特定バージョンに依存する機能が判明している場合は、その利用を最低限とすること。
Ｗｅｂブラウザ及び実行環境等のバージョンアップの際、必要な調査及び作業を

-

49 -

参考 5-7
上位互換性要件の記載例

（第３編第５章 要件定義）

実施することで、バージョンアップに対応可能な情報システムとすること。

H. 中立性に関する事項「中立性」とは、情報システムを構成する要素が、特定の技術や製品に特化しないことを指します。特定の技術や製品に特化した構成とすると、ベンダーロックイン状態となってしまう可能性があるため、中立性に配慮する必要があります。
例えば、新規に情報システムを構築する際に、ある事業者が開発・販売している製品を利用しなければ運用・保守ができない構成にしたとします。その後、運用・保守業務を一般競争入札で調達しようとしても他の事業者ではその製品を入手できないなどの理由により、その製品を導入した事業者による一者応札となってしまいます。このような状態になることを防ぐために、特定の事業者の技術に依存せず、多くの事業者が扱える製品を採用するなど、中立性への配慮が必要です。
また、特殊なツールを利用する場合、将来的に他の製品への乗り換えが困難にならな
いよう、中立性の観点から問題のないツールであることを要件として示します。
なお、情報システムの調達において、ベンダーロックインを避けることを重視する場合には、中立性に関する事項を要件定義書に示すだけでなく、総合評価落札方式における加点項目とし、配点を高くすることも選択肢の一つです。

参考：オープンな標準的技術又は製品の採用を求める場合の記載例

参考 5-8
オープンな標準的技術又は製品の採用を求める場合の記載例

提供するハードウェア、ソフトウェア等は、特定ベンダの技術に依存しない、オー
プンな技術仕様に基づくものとすること。
提供するハードウェア、ソフトウェア等は、受託者以外の者が市場で調達することが可能である製品を選定すること。
提供するハードウェア、ソフトウェア等は、全てオープンなインタフェースを利用して接続又はデータの入出力が可能であること。
導入するハードウェア、ソフトウェア等の構成要素は、標準化団体(ISO、IETF、
IEEE、ITU、JISC 等)が規定又は推奨する各種業界標準に準拠すること。
ノンプログラミングによる画面生成等プロトタイピング用のツール等を採用する場
合には、当該ツールは中立性の観点から問題ないものを選定すること。

参考：事業者交代時の対応を求める場合の記載例
次期情報システム更改の際に、データ移行の妨げとなることや、特定の装置や情報システムに依存することを防止するため、原則として情報システム内のデー
タ形式は XML、CSV 等の標準的な形式で取り出すことができるものとすること。
特定の事業者や製品、技術等に依存することなく、他者に引き継ぐことが可能なシステム構成であること。

I. 継続性に関する事項「継続性」では、当該情報システムを構成する要素（サブシステム、サービス等）に分解し、情報システム全体での目標復旧時間を踏まえて、各要素の継続性に係る指標や目標値を要件として示します。

-

50 -

参考 5-9
事業者交代時の対応を求める場
合の記載例

（第３編第５章 要件定義）

No.
1

設定対象
○○システム2
3
4
56○○サブシステム

指標名
稼働率（「年間実稼働時間」／「計画停止等を除いた年間予定稼働時間」×100）
目標復旧時点（バックアップデータの復旧時点）
目標復旧時間（データ復旧までの時間）
稼働率
目標復旧時点
目標復旧時間

目標値
XX.X％

補足

表 5-21
継続性要件

XX 時間
XX 時間以内
XX.X％
XX 時間
XX 時間以内

クラウドサービスとオンプレミスは継続性の確保方法が異なる
例えば、クラウドサービスを利用する場合には、オンプレミスのようにテープ等の媒体で別途保管する必要はなく、クラウドサービス提供者が提供するバックアップサービスを利用すればよいと考えられます。ただし、バックアップサービスには様々な種類が存在することに鑑み、選択する手法が妥当なものであることを確認できるようにすることが重要です。

参考：継続性に関する事項の記載例

注記
オンプレミスとは、発注者が自ら情報システムに必要な機器（サーバ、ネットワーク、ソフトウェア製品等）を調達し、情報システムの運用を行うこと。

参考 5-10
継続性に関する事項の記載例利用するクラウドサービスで提供される仮想サーバ等の可用性に係る SLA に留意し、各構成要素について適切に冗長化等を行うこと。
バックアップの取得については、クラウドサービス提供者から提供されるバックア
ップサービスを利用して差し支えない。ただし、適用するサービスの種類、同時被災しないことを前提としたバックアップサイトの場所、バックアップデータの取得
時期及び保持期間（世代管理を含む）、自動化の程度等については、対象とするデータの性質等に応じて、業務に影響を与えず、かつコスト対効果が高いものを適宜選定すること。

事例：クラウドサービスのハードディスク障害によるデータ消失の責任
クラウドサービス提供者に預けたデータがハードディスク障害によって消失した場
合、クラウドサービス提供者の責任範囲については種々の議論がありますが、東京地裁では平成 21 年 5 月 20 日に以下のような判決がありました。
あるユーザ企業がサーバホスティング事業者の運営するサーバを利用してウェブサイトを運営していたところ、ハードディスク障害が発生し、プログラム・データが消失
してしまいました。ユーザ企業は、これについて損害賠償を求める訴訟を提起しまし
たが、裁判所は以下のように述べて訴えを退けました。
「サーバは完全無欠ではなく障害が生じて保存されているプログラム等が消失することがあり得るが、プログラム等はデジタル情報であって、容易に複製することができ、利用者はプログラム等が消失したとしても、これを記録・保存していれば、プログ
ラム等を再稼働させることができるのであり、そのことは広く知られているから、ユーザ
企業らは本件プログラムや本件データの消失防止策を容易に講ずることができたの
である。」

-

51 -

事例 5-5
クラウドサービスのハードディスク障害によるデータ消失の責任（第３編第５章 要件定義）(東京地判平 21.5.20 判タ 1308-260 より)
無論、裁判の結果は、個別の事情により異なりますが、上記の判決を見る限り、クラウドサービス提供者等にデータやプログラムを預ける際には、データ消失の対策としてバックアップの取得等を講ずることは、ユーザ側の責務であると考えられます。
しかし、データのバックアップ等消失対策を講じるためには別途費用が必要となる場合が多いため、ユーザは、各々のデータの重要性と対策にかかる費用について十分に検討し、バランスの良い対策をとる必要があります。

事例：クラウドサービスの外へのバックアップの検討

事例 5-6
クラウドサービスの外へのバック
アップの検討ある情報システムにおいて、プログラムを含むクラウドサービス上のすべてのデー
タが消失し、利用できなくなりました。発注者と情報システムの運用事業者の間では、この情報システムを継続して運用することが合意されていたものの、運用事業者
がクラウドサービスの利用継続手続きを怠っていたために、当初の契約期間満了とともにクラウドサービス上のデータが削除されたことがこの障害の原因でした。この障害により、クラウドサービス上に取得していたバックアップを含むすべてのデータが消失
し、復旧が不可能な状態となってしまいました。
このような障害では、仮に災害対策環境を設置していたとしても、それが本番環境と同じクラウドサービスであるなど、条件が変わらない場合には、本番環境とともに消失するおそれがあることに注意が必要です。
対策としては、オンプレミスの環境や別のクラウドサービスなどを用意しておき、定期的にバックアップを保管することが考えられます。ただし、バックアップを取得する
ためには、これらの環境を用意したり、運用事業者にバックアップ作業を依頼したりするために追加の費用がかかります。また、バックアップを取得する対象や周期、データの保持期間などの検討も必要となります。
したがって、当該情報システムの目標とする復旧水準と、対策に要する費用等を考慮して、バックアップ取得の必要性を総合的に判断する必要があります。

参考：業務継続の分かれ目
業務を継続するためには、緊急時対応計画や業務継続計画を定めることが必要
ですが、その計画に従って業務継続に係る目標が達成できるのか、また、計画や手順に抜け漏れがないか確認するために訓練を行うことが重要です。以下に業務継続に問題を起こさないように留意すべき 3 つの観点での訓練を挙げます。
① システムが全く使えない状況で業務を継続する訓練
長年利用している情報システムがあると、その情報システムが業務の大前提として組み込まれてしまい、いざ情報システムが停止した際に業務が大混乱してしまうことがあります。
次の 2 つの例を見てみましょう。どちらもシステムが全面停止するという深刻な障
害に見舞われましたが、業務継続性の観点では全く異なる結果となりました。
普段からシステム障害時に備えて紙台帳でも窓口業務をできるようにしていたため、実際に障害が発生した時に業務の効率は下がったものの来訪した利用者に対して必要なサービスを提供できた。
システムを過信し障害時の対方法を想定できていなかったため、実際の障害発生時に窓口が大混乱し必要なサービスを提供できず、利用者にはシステ

-

52 -

参考 5-11
業務継続の分かれ目（第３編第５章 要件定義）

ム障害を理由に一度帰ってもらうことになった。
後者のようにならないように、災害発生やシステム障害等、さまざまな予期せぬ状
況に対してできる限り業務を継続する準備や訓練が重要です。
② システム自体を災害対策拠点に切り替える訓練
多くのシステムでは年に 1 回程度、切替え訓練を実施しています。あるシステムでは、災害対策拠点を定義したものの、災害対策拠点に切替えてしまうと元の環境に戻せなくなることが事後的に判明したため、切替え自体の判断を慎重に求められることになってしまいました。要件定義の段階で、災害対策環境への切替えだけでなく、本番環境への復帰要否についても検討しましょう。
③ バックアップからデータを戻す訓練
バックアップを取っているだけでは安心できません。いざという時に復旧できなけ
れば意味がありません。定期的なバックアップからの復旧訓練の実施を検討しましょう。

J. 情報セキュリティに関する事項「情報セキュリティ」とは、一般的には、情報の機密性、完全性、可用性を確保することと定義されています。機密性とは、ある情報へのアクセスを認められた人だけが、その情報にアクセスできる状態を確保することです。完全性とは、情報が破壊、改ざん又は消去されていない状態を確保することです。可用性とは、情報へのアクセスを認められた人が、必要時に中断することなく、情報にアクセスできる状態を確保することです。
ここでは、自組織において定められた情報セキュリティポリシーを遵守するために必要な情報セキュリティ対策の内容について、具体的に記載してください。
個々の業務について記載するのではなく、業務分類等、グループ単位で記載します。また、ユーザ認証において、求められる要件（例えば、社内の認証サーバと連携できること
等）があるときは、それらも記載します。

No.
1
2
3

情報セキュリティ対策
主体認証
アクセス制御ログ取得及びログ管理対策に係る要件

補足

表 5-22
情報セキュリティ対策要件

当該情報システムに実装する機能や画面に対して、利用者の権限に応じた管理レベルを記載します。

No.
1

機能○○申請処理

利用者区分
一般ユーザ

2

○○申請処理一般職員

アクセス権限自申請情報のみ登録・参照・変更・削除可能自組織が担当する申請者の情報は登録・参照・変更・削除可能。他組織担当の申請者情報は参照のみ。

想定されるリスクの概要と対策について記載します。

-

53 -

補足

表 5-23
権限要件

（第３編第５章 要件定義）

No.
1

・・・

リスクの区分

2

・・・

3

・・・

リスクの概要と対策
インターネットからの不正アクセス等、外部からの攻撃を受ける可能性がある。
必要な対策を講じ、不正アクセス等の悪意ある攻撃を防ぐ。
来訪者エリアと職員エリアで、同じネットワークを利用するため、来訪者エリアからの進入等の被害につながる可能性がある。
ネットワークの論理分割、セグメント分割、ファイアウォ
ールやＤＮＺ等の設置により、進入を防ぐ。
利用者が担当業務に関係のない情報を閲覧し、情報漏洩につながる可能性がある。
必要十分な権限制御を行い、利用者に業務に不必要な情報を閲覧させない。

補足

表 5-24
リスク一覧

定義に当たっては、自府省の情報セキュリティポリシーを参照するとともに、必要に応じて「政府機関のサイバーセキュリティ対策のための統一基準群」及び「情報システムに係る政府調達におけるセキュリティ要件策定マニュアル」（平成 23 年４月 28 日内閣官房情報
セキュリティセンター）等を参照し、必要な対策を漏れなく記載しましょう。
当該情報システムに求めるセキュリティ要件については、次に示す「最低限記述すべき
情報セキュリティ対策要件」を参考にして、表 5-21 で示した様式を参考に記載してください。

参考：最低限記述すべき情報セキュリティ対策要件(1) セキュリティ機能の装備【情報システムの構築等の場合の記載例】
以下のセキュリティ機能を具体化し、実装すること。
本調達に係る情報システムへのアクセスを業務上必要な者に限るための機能
本調達に係る情報システムに対する不正アクセス、ウイルス・不正プログラム感染
等、インターネットを経由する攻撃、不正等への対策機能
本調達に係る情報システムにおける事故及び不正の原因を事後に追跡するための機能(情報システムに含まれる構成要素(サーバ装置・端末等)のうち、時刻設定が可能なものについては、情報システムにおいて基準となる時刻に、当該構成要素の時刻を同期させ、ログに時刻情報も記録されるよう、設定すること。)(2) 脆弱性対策の実施【情報システムの構築等の場合の記載例】
以下の脆弱性対策を実施すること。
(第三者による脆弱性検査を必要とする場合)
本調達に基づく改修(新規構築/更改)が影響する範囲について、第三者による脆弱性検査を実施し、その結果を関係府省に書面にて報告すること。
(第三者による脆弱性検査を必要としない場合)
本調達に基づく改修(新規構築/更改)が影響する範囲において、第三者による脆弱性検査を実施し、その結果を関係府省に書面にて報告すること。なお、脆

-

54 -

参考 5-12
最低限記述すべき情報セキュリ
ティ対策要件（第３編第５章 要件定義）

弱性検査ツールを用いる等により客観的なテストが可能であれば、受注者で実施することも可とする。
構築する情報システムを構成する機器及びソフトウェアの中で、脆弱性対策を実施するものを適切に決定すること。
脆弱性対策を行うとした機器及びソフトウェアについて、公表されている脆弱性
情報及び公表される脆弱性情報を把握すること。
把握した脆弱性情報について、対処の要否、可否を判断すること。対処したものに関して対処方法、対処しなかったものに関してその理由、代替措置及び影響を納品時に関係府省に書面にて報告すること。
【情報システムの運用・保守・点検の場合の記載例】
以下の脆弱性対策を実施すること。
機器及びソフトウェアについて、公表される脆弱性情報を常時把握すること。
把握した脆弱性情報について、対処の要否、可否につき関係府省と協議し、決定すること。
決定した対処又は代替措置を実施すること。
(3) 情報セキュリティが侵害された場合の対処
本調達に係る業務の遂行において情報セキュリティが侵害され又はそのおそれがある場合には、速やかに関係府省に報告すること。これに該当する場合には、以下の事象を含む。
受注者に提供し、又は受注者によるアクセスを認める関係府省の情報の外部への漏えい及び目的外利用
受注者による関係府省のその他の情報へのアクセスリスクの概要と対策を定義する
リスクが多様化しているので、なるべく多くのリスクの洗い出しを行うこと。
当該情報システムの格付けに見合った情報セキュリティ対策を行うこと。
公開される Web サイト等のドメインについては、利用者がわかりやい政府サイトとするとともに、政府サイトに似せたサイト上で個人情報を収集する等といったフィッシング等のセキュリティ事故が起こりにくい環境を実現すること。

第三者による脆弱性検査を実施する
当該情報システムに対して修正を行う場合、その改修が影響する範囲を対象として第三者による脆弱性検査を実施します。
第三者による脆弱性検査を実施するか否かの判断に当たっては、下表の観点を考慮し、案件ごとに判断してください。なお、第三者による脆弱性検査を実施しない場合には、実施しない理由を明確にします。また、第三者による脆弱性検査は、当該調達に基づく改修が影響する範囲を対象とし、情報システムとしての脆弱性がないことを検査するものであり、実装されたセキュリティ機能の検査を行うものではないことに留意してください。

No.
1

観点
情報の重要度2

外部アクセスの有無

判断条件
漏えいや消失によって、深刻な損害を被る可能性がある重要な情報（個人情報等）を扱う情報システムの場合は、第三者による脆弱性検査を必須とする。
インターネット等の通信回線を介して外部から情報シテムにアク

-

55 -

表 5-25
脆弱性検査の観点

（第３編第５章 要件定義）

No.

観点

3

利用者の属性

4

その他

判断条件
セスしてサービスの利用、業務の遂行、情報システムの管理等を行う場合は第三者による脆弱性検査を必須とする。
不特定多数の利用者が情報システムを使用する場合は、第三者による脆弱性検査を必須とする。
他の情報システムとの連携が生じる等、情報システムの特性に応じて、第三者検査を実施する。

K. 情報システム稼働環境に関する事項「情報システム稼働環境」とは、当該情報システムに係る、クラウドサービスの構成、ハードウェアの構成、ソフトウェア製品の構成、ネットワークの構成、施設・設備要件等を明らかにすることを指します。稼働環境には、運用、保守、研修、検証等に必要な環境も含めます。
「システム方式」は構成要素ごとの方針を示すものですが、情報システム稼働環境は、もう一段階分解し、構成要素の内容を具体的に示します。

図 5-9
ハードウェア構成図

No.
1
2

3
4

No.
1

ハードウェア分類
コンピュータ本体:
サーバ機器
コンピュータ本体:
メインフレーム・汎用機
記憶装置:
ストレージ・ＮＡＳ等
ネットワーク機器:
ＨＵＢ・ルータ・スイッ
チ等

ハードウェア名Ｗｅｂサーバソフトウェア分類
ＯＳ：サーバ用

ソフトウェア名Ｗｅｂサーバソフ

ハードウェア要件

補足

表 5-26
ハードウェア構成

補足

表 5-27
ソフトウェア構成

データ量：XX
ディスクの回転数：XX-

ソフトウェア要件
機能：XX

56 -

（第３編第５章 要件定義）

No.

ソフトウェア分類

ソフトウェア名
トウェア

2

ＯＳ：クライアント用3

ミドルウェア：Ｗｅｂサーバミドルウェア：アプリケーションサー
バパーソナルソフトウェ
ア：セキュリティ対策

アプリケーション
サーバソフトウェア
Ｗｅｂサーバソフ
トウェア
アプリケーション
サーバソフトウェア
アンチウイルス
ソフトウェア

4

5

No.
1

回線種別
高速デジタル専用線

2
3

ソフトウェア要件
バージョン：XX
必要ライセンス数：XX
保有済のライセンス内容：XX

補足

補足

表 5-28
ネットワーク構成

広域イーサネット網
パケット通信網

ネットワーク要件
・ネットワーク帯域：XX・冗長構成：有/無・通信回線装置におけるアクセス制御の設定：有/無・暗号化：有/無・通信プロトコル：XX
・・・
・・・

No.
1

施設名
○○施設

施設形態
国有施設

補足

表 5-29
施設・設備要件

2

○○施設

3

○○データセンタ

国以外の公的機関が保有する施設
商用ＩＤＣ

施設・設備要件
・制震／耐震／免震：有/無・非常用電源：有/無・非常用電源の稼働時間：・ラック数：XX
・使用可能な電源の容量：XX・位相及び系統：XX・許容する発熱量：XX・耐荷重：XX・・・・・・

クラウドサービスを利用する場合は、サービスに関する要件を記載します。オンプレミスで構築する場合は、ハードウェア構成、ソフトウェア構成、ネットワーク構成、施設・設備等の要件の定義に加えて、情報システムのハードウェア構成図も記載します。なお、記載に当たっては、仮想化による物理的な機器の削減についても考慮するとともに、将来的な拡張予定についても、その範囲を識別できるよう留意します。

レンタル/リース/買取の特徴を理解して、選択する
以前は高額なハードウェア製品が多く存在していましたが、昨今は製品価格が下落傾向にあるため、リースよりも買取の方が最終的には安価になることもあります。プロジェクトの特性に併せて、最適な方式を検討しましょう。
なお、事業者より見積りを取得する際には、「一式」ではなく、製品ごとの本体価格を提示するよう依頼し、機器単位で比較ができるよう留意してください。

-

57 -

（第３編第５章 要件定義）

取得方式
レンタル

リース

買取

メリット
初期費用を抑えることができる
経費計上できる
修理費用が不要
中途解約が原則可
初期費用を抑えることができる
経費計上できる
長期利用の場合、レンタル、リー
スより割安

デメリット
長期利用の場合、リース、買取時より割
高

表 5-30
レンタル・リース・買取の比較表

中途解約は原則不可
長期利用の場合、買取時より割高
修理費用は負担
初期費用が高い
固定資産税がかかる
機器の廃棄手続、費用が別途必要

クラウドサービス/オンプレミスの特徴を理解して選択する
稼働環境に係る要件を記載する場合、クラウドサービスとオンプレミスでは記載内容が異なることを理解して進めてください。
情報システムの稼働環境は、システム方式と同様に情報システム設計の基本的な前提条件であるため、定義時点において明確にできる範囲内で要件定義書に記載する。なお、将来的な拡張性要件を記載する場合、今回の調達対象を明確にするように注意すること。
クラウドサービスを利用する場合、サービスによって可用性に係る SLA が異なること、使用状況に応じてリソースを変動させることができること等から、厳密に構成を確定せず、想定構成を参考として記載するに留め、実際構成は適宜受注者に提案することを求める形とすること。また、運用・保守、移行、刷新等既存の情報システムがある場合も同様に実施すること。
調達仕様書において利用するクラウドサービスの要件については、次の記載例を参考にして定めてください。

参考：クラウドサービスの要件例
利用するクラウドサービスは、以下の要件を満たすものとすること。
(1) 政府情報システムの保護
情報資産を管理するデータセンタの物理的所在地が日本国内であること。
調達を実施する組織の指示によらない限り、一切の情報資産について日本国外への持ち出しを行わないこと。
障害発生時に縮退運転を行う際にも、情報資産が日本国外のデータセンタに移管されないこと。
クラウドサービスの利用契約に関連して生じる一切の紛争は、日本の地方裁判所を専属的合意管轄裁判所とするものであること。
契約の解釈が日本法に基づくものであること。
情報資産の所有権がクラウドサービス提供者に移管されるものではないこと。したがって、調達を実施する組織が要求する任意の時点で情報資産を他の環境に移管させることができること。
法令や規制に従って、クラウドサービス上の記録を保護すること。
情報資産が残留して漏えいすることがないよう、必要な措置を講じること。
自らの知的財産権について、クラウド利用者に利用を許諾する範囲及び制約

-

58 -

参考 5-13
クラウドサービスの要件例

（第３編第５章 要件定義）

を、クラウド利用者に通知すること。
(2) 技術的条件 クラウドセキュリティに関する次のいずれかを取得していること。
ISO/IEC 27017:2015 認証
CS ゴールドマーク

バージョンアップと新規調達した場合とを比較・検討する
保有するソフトウェアと同一のソフトウェアを調達する場合には、バージョンアップ※と新規調達の両方を検討し、より低額となる方法で提案可能な要件とします。なお、保有するソフトウェアの一覧（使用権の保有数等含む）は、閲覧資料一覧表に含め、応札希望者に提示してください。
※ ライセンスが引継ぎ可能であるか、現行事業者等に確認が必要です。
技術の検討に当たっては、国際標準規格や日本産業規格等のオープンな標準に基づく技術を選択すること。
調達から納入までの期間に技術の進展が見込まれる製品については、必要に応じて『**以上で最新のものを納入する』等の変更可能指示を入れておくこと。
特定製品に依存しないように留意すること。
特定製品を指定する必要がある場合には、その理由を明確に記載すること。
バージョンアップと新規調達でコストを比較し、より低額となる方法を選択すること。
現行情報システムと新たな情報システムを並行稼働する期間を設けるときには、新旧ライセンスを保有する費用が発生することがあるため、費用を事前に確認しておくこと。

オープンソースソフトウェアの特徴を理解して採用する
オープンソースソフトウェア（ＯＳＳ）には、先進的な機能が利用できるメリットがある一方で、不具合があってもサポートを受けられないなどのデメリットもあります。メリットとデメリットの両方を正しく理解した上で、プロジェクトの特性に合わせて、ＯＳＳの採用を検討しましょ
う。
メリット
拡張性

コスト（※）

先進性

デメリット

公開されているソースコー
ドをもとに、不具合の修正や機能拡張などを行うことができる。
ライセンス料がかからず、
導入コストを抑えられる。
ベースとなる機能や部品として利用することで、開発工数を削減できる。

コンプライ
アンス

先進的な機能が利用できることも多い。

サポート

-

59 -

ＯＳＳを利用して独自に開発したアプリケーションについてもソースコードを開示する義務が生じる可能性がある。
ＯＳＳ開発者へ損害賠償請求等ができない。
ライセンス違反を理由に第三者から訴訟を起こされる可能性がある。
緊急時のサポートを受けられない。

表 5-31
ＯＳＳ利用のメリットとデメリット

（第３編第５章 要件定義）

セキュリティ

品質

メリット
市販のソフトウェア等では、
ソースコードを確認することができないが、ＯＳＳでは、
ソースコードが公開されており、脆弱性等を直接確認することができる。
多くのユーザが利用しており、活動が活発なＯＳＳの場
合は安定した品質を期待できる。

セキュリティ

不具合修正

デメリット
ソースコードが公開されているため、脆弱性を突いた攻撃を受ける可能性がある。

活動が停滞しているＯＳＳの場合、不具合対応されない場合がある。

※ ＯＳＳではあるものの、製品自体が有償化されていたり、ＯＳＳの入手は無償であってもサポートなどが有償化されていたりする場合があるため、ＯＳＳの採用を検討する際にコストを確認することが重要です。また、以下の理由で、管理コストが割高になる可能性があることに注意が必要です。
ＯＳＳはサポート期間が一般的に短いものが多いため、バージョンアップなどの対応が増える場合があります。
製品に複数のＯＳＳが包含されている場合、包含しているＯＳＳのサポート体制
やサポート期間を含めて管理する必要があります。また、ＥＯＬがＯＳＳごとに異なるため、ＥＯＬの管理や脆弱性などの確認の実施が必要です。
ＯＳＳのライセンスには複数の種類があります。例えば、最も自由度が高い例としてApache ライセンスが挙げられます。これは、使用、複製、改変、再配布、ライセンス継承等

注記
ＥＯＬとは、「End Of Life」の略称。
ソフトウェア製品などの使用期限のこと。サポートが終了し、修正・更新プログラムの提供が行われなくなる。

について制限がなく、「Apache ライセンスを使用していること」を明記することだけが定められています。逆に、ＧＰＬ（General Public License）の場合は、以下４つのルールが定められています。
（1） ソフトウェアは無償で利用可能（2） 著作権は表示しなくてはいけない（3） 複製、改変、再配布、販売は制限なし（4） 再配布する場合は、ＧＰＬライセンスにしなくてはいけない
ＧＰＬライセンスのソフトウェアをプロジェクトにあわせて改変して利用する場合、当該ソフ
トウェアはＧＰＬライセンスのルールが維持されることになり、複製や再配布を認めなくてはならなくなります。このようなＯＳＳのライセンスにおいて特に確認すべきポイントとこれらのポイントが代表的なＯＳＳにおいてどのように定められているかを以下に示します。
ソフトウェアの利用は無償でも、利用者ごとのカスタマイズが必要なライブラリの改変は有償である場合やサポートが高額である場合があるため、ＯＳＳを採用する際は、ライセンスの内容を詳細に確認することが重要です。

確認ポイントライセンスと著作権の表示要否変更した旨の表示要否概要適用されるライセンス条件全文及びＯＳＳ著作者の氏名を、ソースコードや付属ドキュメントに表示することを求められるか否か。
ＯＳＳを含むアプリケーションを頒布する際に、オリジナ
ルのＯＳＳのソースコードを変更したことを示すことを求められるか否か。

-

60 -表 5-32
ＯＳＳのライセンスにおいて確認すべきポイント（第３編第５章 要件定義）

ソースコードの開示要否

ＯＳＳを含むアプリケーションを頒布する際に、オリジナ
ルのＯＳＳのソースコード及び改変を加えた部分のソースコードも公開して頒布することを求められるか否か。

ソースコードの改変可否

ＯＳＳのソースコードを改変することが可能か否か。

ソースコードの頒布可否

ＯＳＳのソースコードを独自に開発したアプリケーションに組み込み、第三者へ頒布することが可能か否か。
ＯＳＳに改変を加えて作成したものに対しても、オリジ
ナルのＯＳＳで採用しているライセンス条件を適用する
ことを求められるか否か。

派生物に対する
ライセンス条件の適用要否

-

61 -

注記
派生物とは、あるプログラムの一部／全部を、改変／引用して作成したプログラムを指す。それ自体を改変した場合だけでなく、ラ
イブラリなど他ソフトウェアと組み合わせた場合も派生とみなされる。

（第３編第５章 要件定義）

確認ポイント

GPL
（※1）

AGPL
（※2)

LGPL
（※3）

Apache
(※4)

MIT
（※5）

ライセンスと著作権の表示要否
変更した旨の表示要否

必要

必要

必要

必要

必要

必要

必要

ソースコードの開示要否

必要

必要

必要で
ない
必要

ソースコードの改変可否

可能

可能

ソースコードの頒布可否

可能

派生物に対するライセンス
条件の適用要否

必要

必要

可能

必要で
ない
可能

必要で
ない
必要で
ない
可能

可能

可能

可能

可能

必要

必要で
ない

必要で
ない

必要で
ない

表 5-33
代表的なＯＳＳの比較
注記
GPL は、改変したプログラムの配布を前提としており、サーバ上で動作するプログラムをネットワー
ク経由で利用する場合には、ソースコードの開示が求められない。
一方、AGPL（GNU Affero General
Public License）では、ネットワー
ク経由で利用する場合に、利用者にソースコードのダウンロードを可能とすることが定められている点が異なっている。

※1 GPL（ライセンス条文 英文）
https://opensource.org/licenses/GPL-2.0
https://opensource.org/licenses/GPL-3.0※2 AGPL（ライセンス条文 英文）
https://opensource.org/licenses/AGPL-3.0※3 LGPL（ライセンス条文 英文）
https://opensource.org/licenses/LGPL-2.1
https://opensource.org/licenses/LGPL-3.0※4 Apache（ライセンス条文 英文）
https://opensource.org/licenses/Apache-2.0※5 MIT（ライセンス条文 英文）
https://opensource.org/licenses/MIT

L. テストに関する事項
情報システムのテストには、ソフトウェアの設計に基づいて事業者が行うテストと、発注者及び情報システムの利用者の視点で行うテストが存在します。
テストに関する要件には、実施するテストの内容や方法、環境等を示します。
上記の点に留意し、情報システムの設計・開発等におけるテストについて、テストの種
類、目的、内容等を記載します。

No.
1

テスト
工程
単体
テスト

2

結合
テスト

3

総合
テスト

テストの目的、内容
アプリケーションを構成する最小の単位で実施するテストであり、主に機能単位で設計通りに動作するかを事業者（プログラマ）が確認する。
複数の機能を連携させて動作を確認するテストであり、主にユースケー
ス単位で設計通りに動作するかをテ
スト担当者が確認する。
システム全体が設計の通りに動作す
ることを確認するテストであり、ユース
ケースを組み合わせた一連の業務が行えることを機能面や非機能面の

-

62 -

テスト
環境
開発
環境

テストデータ
テスト用に作成
したデータ

検証
環境

テスト用に作成
したデータ

検証
環境

テスト用に作成
したデータ、又は本番データから作成した疑

テスト
実施主体
事業者
（※1）

表 5-34
テストに関する要件

（第３編第５章 要件定義）

No.

テスト
工程

4

受入
テスト

テストの目的、内容

テスト
環境観点からテスト担当者が確認する。
納品されるシステムが要件通りに動作することを確認するテストであり、発注者が主体となり、事業者と協力して確認する。

検証環
境又は
本番環
境

テストデータ
似データ
本番データ、又は本番データから作成した疑
似データ

テスト
実施主体
発注者

※1. 発注者もテスト計画を確認した上で、事業者に実施状況の報告を求め、報告書に記載されている実施結果に不足、誤り等が発生している場合は、課題等を整理し、指摘又は指導を行います。特に総合テストにおいては、発注者がテストシナリオやテスト評価方法の妥当性を確認し、過不足を指摘することで抜け漏れのないテストになるように関与します。

なお、それぞれのテスト工程の中でも、様々な観点からテストを行います。情報システムの特性により、テストの観点も大きく変わってきますので、それぞれの情報システムに見合ったテストを実施できるように要件を決めることが重要です。テストの観点のほか、各テスト工程におけるテストスケジュール、テスト環境、テストシナリオ等の情報は、事前にテスト計画書やテスト実施要領にまとめます。詳細については、実践ガイドブック「第７章 Step.3-3
テストの計画を立てる」に記載しています。要件定義をする際には、ぜひ第７章の記載も読んでみてください。

テストに関する各作業を、誰が行うのか明確に記載する
テストには、「テスト項目の作成」「テスト実施環境の準備」「テスト実施」「テスト結果の判定」等、様々な作業が存在します。それぞれの作業を誰がいつまでに行うのか明確にしてください。
テストを行う上で必要な関係者との連絡調整やその実施者、また、テスト環境の準備や費用負担等、誰が行うのか明確に記載すること。

過剰な要求は避ける
テストは、数多く実施すれば品質が上がるというわけではありません。当該テストの目的を踏まえて、必要十分なテスト内容・量を調整してください。
事業者に対してテスト環境の過剰な要求は避けること。
必要以上に厳密なテスト等の過剰な要求は避けること。

M. 移行に関する事項
移行には、データ移行、システム移行及び業務運用移行の３つの要素があります。大規
模な情報システムにおいては、既存の情報システムから新しい情報システムにデータ移行とシステム移行（新情報システム稼働）を行い、一定期間並行稼働させた後に、業務運用移行を行う場合もあります。他方で、中小規模の情報システムにおいては、３要素全ての移行を休日に実施する場合もあります。
いずれの場合においても、業務の安定的な継続が最重要課題であるため、移行の各ス
テップにおいて状況を評価し、最悪の場合でも既存の情報システムへ切り戻せるような計画と、プロセスの準備を要求しておくことが必要です。
移行元である既存の情報システム、業務、運用について、対象を漏れなく抽出します。
抽出に当たり、既存の運用・保守事業者の協力が不可欠となるため、事前に移行調査に必要となる既存事業者の要員確保について調整しておくことが重要です。移行対象の抽

-

63 -

（第３編第５章 要件定義）

出後、移行に際する制限事項を整理します。例えば、月次の締め処理がある業務の場
合、「月末の締め処理が完了するまでは移行不可」といった事項を明確にします。
ここでは、移行先への移行手段を詳細に記載する必要はありません。移行手段は設計・開発工程にて詳細化します。

No.
1
2
3

移行元
○○申請システム

移行対象データ○○テーブル○○申請ファイル
○○申請情報

件数
XX
XX
XX

提供方法
ＣＳＶ形式での提供
ＣＳＶ形式での提供
ＣＳＶ形式での提供

補足

表 5-35
移行対象データ

No.
1
2
3

移行元
○○申請システム

移行対象業務○○管理業務○○登録業務
○○情報業務

件数
XX
XX
XX

提供方法
電子媒体
電子媒体
電子媒体

補足

表 5-36
移行対象業務

No.
1
2
3

移行元
○○申請システム

移行対象システム○○管理システム○○登録システム○○情報システム

件数
XX
XX
XX

提供方法
電子媒体
電子媒体
電子媒体

補足

表 5-37
移行対象システム

N. 引継ぎに関する事項
情報システムの構築及びテストが完了し本番運用に移行する際、又は年度の節目等で事業者や要員が交代する場合、円滑な業務運営を維持するためには、あらかじめ引継ぎ
項目を整理し、想定しておくことが重要です。
現在その作業を担当している事業者を「引継ぎ元」と定義し、その事業者が担当している作業を「引継ぎ内容」として明らかにします。基本的には事業者ごとに作業・成果物等を定義した契約が存在しているため、その内容を基に整理すると効率的です。
引継ぎ期間は 1 か月程度を設定するのが一般的ですが、十分ではないケースが多くみられます。引継ぎ期間が十分でない場合には、他の事業者が参入できなかったり、その後の業務運営に支障が生じたりするおそれがあるため、十分な期間を確保することが重要です。
また、事業者が情報システムを構成するソフトウェアのライセンスを保有している場合、事業者が交代する際にソフトウェアライセンスを引継ぎ先の事業者へ譲渡することが必要になります。ソフトウェアライセンスの契約条件によっては譲渡に制約が生じ、引継ぎ先の事業者による運用・保守作業に支障が生じる場合があります。そのため、譲渡可能なソフトウェアライセンスを調達する旨とソフトウェアライセンスの譲渡に関する制約がある場合はその情報を開示する旨を、要件定義書に記載しましょう。落札後 、ソフトウェアライセンスの契約条件を発注者・事業者間で合意した上で、ソフトウェアライセンスを調達しましょう。
事業者間の引継ぎにおける工夫は、「第 7 章 Step6-2 事例：異なる事業者間で引継ぎをスムーズにする工夫」をご参照ください。

-

64 -

（第３編第５章 要件定義）

項番
1

2

引継ぎ
期間
令和〇年
〇月〇日
～
令和〇年
〇日〇月

引継ぎ先
本システムの運用・保守事業者（令和 X 年度後半に調達予
定）

令和〇年
〇月〇日
～
令和〇年
〇日〇月

連携先システムである●●システムのアプリケーション保守事
業者

引継ぎ
内容
ソースコード(テスト・構成管理・環境構
築等に利用するコード含む)
開発環境に必要となる各種ツール
各種設計書・ドキュメント類
運用課題（管理簿）
仕様課題（管理簿）
インシデント状況（管理簿）
連携業務 AP 対応状況
（管理簿）
ヘルプデスク作業
各種運用・保守作業
その他納品物一式(クラウドサービスの管理に必要なアカウントや鍵情報、また Infrastructure as
Code に基づくシステム構
築・管理等に係る構成管理
ファイル等情報を漏れなく含む)必要となる知識等

引継ぎ
手順
受託者は、引
継ぎ計画書の内容に基づいて、引継
ぎ作業を行
う。

補足

表 5-38
引継ぎ事項
注記
引継ぎ計画書とは、情報システムの引継ぎに係る引継ぎ対象、引継ぎ体制、引継ぎ内容、引継ぎ方
法、引継ぎスケジュール、理解度
確認方法、完了条件等を記載した受託者が作成する資料のこと

受託者は、引
継ぎ計画書の内容に基づいて、引継ぎ作業を行う。

O. 教育に関する事項「教育」とは、情報システムの利用者が、その情報システムの機能を理解し、効率的に運用していくために必要となる、利用者に対する操作研修等を指します。特に官公庁においては人事異動に備え、教育資料や年に数回程の操作研修を実施する等の対応が必要です。
業務要件定義で作成した業務フロー図等を参考に、教育対象者の範囲を定めます。基
本的には業務フロー図に表現されている全てのアクター（役割）が、教育対象者の候補となりますが、対象者の役割、所属する組織、場所等を考慮し、教育効果や費用を考慮して教育内容や用いる教材等について要件として示します。

No.
1

2

教育対象
者の範囲
○○入力
担当者

○○決裁
者

教育の
内容
窓口業
務にお
ける操
作
決裁に
おける
操作及
び分析

教育の
実施時期
運営開始
前準備時

教育の方法

教材

集合研修：
○○研修
所

操作手順
書

着任時

オンライン
研修：各職
員が日常使
用している
端末ＰＣ

システム管
理者用操
作手順書

-

65 -

教育
対象者数
○名程度

○名程度

補足

表 5-39
教育対象者の範囲、教育の方法

（第３編第５章 要件定義）

No.
3

教育対象
者の範囲
・・・

教育の
内容
・・・

教育の
実施時期
・・・

教育の方法
・・・

教材

教育
対象者数
・・・

補足

対象者
○○入力担当者

補足

・・・

以下の表では、教育に用いる教材等についての要件を示します。

No.
1

教材
操作手順書

2

システム管理者
用操作手順書

3

・・・

教材の概要
利用者区分ごとに操作手順書の内容を分割するなど、利用しやす
いように工夫すること個々の業務に沿った画面の流れを中心に作成すること
管理者権限のみが操作可能な機能に特化したシステム管理用操作
手順書を作成すること・・・

表 5-40
教材の作成

○○決裁者

・・・

P. 運用に関する事項
情報システムの運用とは、実稼働させているアプリケーションの仕様や、ソフトウェア、ハードウェア等の構成変更を原則として行わずに、稼働状態をあらかじめ定めた品質基準に基づき維持することであり、今ある環境を正常な状態に保ち続ける活動とも言えます。詳細な内容は情報システムの運用設計において検討しますが、運用要件の内容によって、情報システムの機能要件及び非機能要件に求める事項が異なることもあるため、基本的な要件はここで定義しておきます。

参考：運用要件（バックアップ）の記載例（従来のデータセンタ利用等の案件の場合）
重要データのバックアップは、週に○○回行い、△△世代保管すること。また、
バックアップに用いる記憶媒体は受注者が負担すること。本情報システムのバッ
クアップ用記憶媒体の種類は□□であり、一回のバックアップで約●●GB 必要とする。
（クラウドサービスを利用する場合）
重要データのバックアップは、週に○○回行い、△△世代保管すること。なお、
バックアップの取得については、クラウドサービス提供者から提供されるバックア
ップサービスを利用して差し支えない。ただし、適用するサービスの種類、同時被災しないことを前提としたバックアップサイトの場所、バックアップデータの取得
時期及び保持期間（世代管理を含む。）、自動化の程度等については、対象とするデータの性質等に応じて、業務に影響を与えず、かつコスト対効果が高いものを適宜選定すること。

情報システムをリリースした後、実際に運用業務に必要となる作業は、標準ガイドライン
解説書「第３編第９章２．解説ア運用業務 表 9-1」で示す事項になりますが、要件定義では、これら具体的な作業を設計するための方針を示します。

-

66 -

参考 5-14
運用要件（バックアップ）の記載例

（第３編第５章 要件定義）

運転管理・監視等要件
コンピュータで行う処理と運用管理者等で行う処理の切り分け、情報システムの運用を行う時間、内容、手法、連絡等について記載します。記載に当たっては、保守要件との責任分界を考慮し、作業の抜け漏れ、重複等がないように定義する必要があります。特に、情報システムの障害発生箇所の切り分け、発生原因の追究と解消について、アプリケーションプログラム、ソフトウェア製品、
ハードウェアそれぞれの保守事業者と連携し、単体では発生しない障害についても監視、切り分け、復旧が可能となるよう留意してください。
また、障害発生を検知した際に、障害対策の原因究明を行うために十分な情報をログ等として確実に記録したり、情報システムを継続的に運用する中で性能劣化が起きないよう定期的な測定と改善活動を行ったりするように留意してください。
運用サポート業務業務の実施に必要な体制以外に、情報システム利用者からの問合せ対応や操作研修等の運用サポート体制が必要となる場合は、その内容を記載します。
業務運用支援情報システムの稼働に当たり、業務実施部門が行う業務の運用支援作業について記載します。

Q. 保守に関する事項「保守」と「改修」の違いが混同されてしまうケースがよくありますが、機能要件に変更を加えずにプログラム修正のみを行うことが「保守」、機能改善を目的としたプログラム修正作
業が「改修」です。保守は「機能要件を変えずにプログラム修正する」という特徴があるた
め、現状の各種ドキュメントを正しく管理することが重要です。
アプリケーションやインフラの作業に着目しがちですが、ドキュメントの保守という観点を忘れないようにしてください。
保守作業には大別すると以下に示す４種類があります。

種類
是正保守
予防保守
適応保守
完全化保守

内容
ソフトウェア製品の引渡し後に発見された問題を訂正するために行う受身の修
正引渡し後のソフトウェア製品の潜在的な障害を運用障害になる前に発見し、是正を行うための修正
引渡し後、変化した又は変化している環境において、ソフトウェア製品を使用できるように保ち続けるために実施するソフトウェア製品の修正
引渡し後のソフトウェア製品の性能又は保守性を改善するための修正

なお、アプリケーションプログラム及びソフトウェア製品の保守要件については、表 5－
37 を踏まえ、訂正に係る保守（是正保守、予防保守）と改良に係る保守（適応保守、完全化保守）を区別して検討します。
アプリケーションプログラムの保守要件
情報セキュリティに関する脆弱性の修正や不具合等の確認及び修正、小規模な改修等の対応範囲や条件を記載します。記載に当たっては、情報システムの機能改修に相当する作業を含まないように留意してください。

-

67 -

表 5-41
保守作業の種類（第３編第５章 要件定義）

ハードウェアの保守要件
不具合の修理等の対応範囲や条件を記載します。
ソフトウェア製品の保守要件
情報セキュリティに関する脆弱性の修正や不具合への対応（パッチの提供）、
小規模な改善等を目的とするリビジョンアップや大幅な改修を伴うバージョン
アップ等の対応範囲や条件を記載します。
ソフトウェアの修正・不具合への対応や機能追加等のバージョンアップについては、業務や他の情報システムとの連携に影響を及ぼす場合もあるため、適用前に必ず影響を調査し、総合的に検討を行った上で実施の是非を判断する必要があります。例えば、脆弱性や不具合に対するパッチを適用する場合
は、適用した場合の業務への影響や適用しなかった場合のリスク評価等を実施した上で、パッチ適用の是非を判断します。また、新たな機能の追加が行われる場合も、追加した場合と追加しなかった場合それぞれのメリット・デメリットを比較するなどした上で、追加の是非を判断する必要があります。
なお、クラウドサービスのバージョンアップの方法はサービスごとに異なり、自動で適用されるものもあれば、自動で適用されないものもあります。利用するク
ラウドサービスのバージョンアップの方法を確認した上で、バージョンアップの情報を漏れなく把握し、適用前には必ず影響調査等を実施するように留意してください。
データの保守要件
情報システムの設定データやマスタデータの更新作業等に関する要件を記載します。
保守実績の評価と改善
情報システムの安定的な運用の維持と継続的な改善のために必要となる保守実績の評価、改善活動について記載します。

２ システム方式を決定する【標準ガイドライン関連箇所：第３編第５章第２節 1)エ】

「1-B. システム方式に関する事項」で検討した内容を他の要件の内容と調整し、情報システムの実現案として決定します。機能要件と非機能要件を定義することで、情報システムの全体像が明らかになっていきますが、それを実現するためのハードウェア・ソフトウェアや機能等の構成は必ずしも１つではありません。クラウドサービスを活用した案や独自にハードウェアから用意する案、また、サーバと配置する機能の組合せ等、複数の構成案があります。これらの比較検討を行い、事業者からの提案・見積りを踏まえ、最適な方式を選択する必要があります。
このため、システム方式として選択可能な方式を、複数案取りまとめます。伝達のしやすさを考慮し、図表形式で取りまとめることも有効です。
また、システム方式によって、要件を実現するための難易度が異なることがあるため、要件の優先順位も併せて検討します。

-

68 -

（第３編第５章 要件定義）

Step.

7 要件定義終了後の対応

要件定義に係る作業が一通り終わり、ほっとするところですが、実は今やっておくだけで後々発生するリスクや負荷を減らすことができる作業があります。
ここでは、それら作業とポイントについて解説します。

１ 定義内容を関係者に共有する【標準ガイドライン関連箇所：第３編第５章第２節 2)】

要件定義書が出来上がることで、関係者にとって整備しようとしている情報システムの内容
がより具体的に理解しやすくなり、これまでは意識していなかった考慮点や抜け漏れが発見できる可能性があります。
そのため、作成した要件定義書を関係者に確認してもらい、その結果明らかになった変更
要望や新たな課題は、ＰＪＭＯ内で対応方針を検討し、業務要件に反映した上で、再度関係者と共有してください。内容によっては機能要件のみが変更対象となるものもありますが、機能要件の前提や根拠となる業務要件を必ず確認することが重要です。加えて、要件定義書
完成時点で、当初の計画に対して工期や費用がどう変化したかについて評価し、プロジェクト
計画に反映していくことが望まれます。評価の仕方や内容に不安がある場合は、ＰＭＯに支援を求めてください。
これにより、業務要件から機能・非機能要件を定義する過程で発生した変更点の確認や、要件を「見える化」した結果、「イメージしていた内容と違う」といった認識そごが発見でき、関係者一同が合意した要件定義書として確定できます。
また、役割が異なる複数の関係者が確認することにより、曖昧な内容や難解な箇所を修正でき、後続工程で事業者を含む第三者が理解しやすい内容になります。

２ プロジェクト計画書に反映して最新化する【標準ガイドライン関連箇所：第３編第５章第３節】

これで要件定義書が確定しました。要件定義のゴールは間近です。
要件定義書を作成する過程で、プロジェクト計画書に記載されていた内容とのかい離が発生した項目があるのではないでしょうか。
要件定義に係る作業の最後の締め括りとして、変更内容をプロジェクト計画書に反映しましょう。要件定義を開始した段階のプロジェクト計画書は、サービス・業務企画を受け、一通りの項目が詳細化されている状態です。本章の作業結果により変更が必要な箇所を確認し、更新してください。今回実施した内容を基にプロジェクト計画書を最新化することにより、次の調
達や設計・開発において、今回の作業を基に修正したプロジェクト計画書の内容に沿って作業を進められるため、準備作業が減ります。
また、人事異動が発生しても、最新のプロジェクト計画書を整備しておけば、プロジェクトの全体像からこの時点で詳細化された情報まで正確な情報で引継ぎができます。

-

69 -

デジタル・ガバメント推進標準ガイドライン

デジタル・ガバメント推進標準ガイドライン
実践ガイドブック（第３編第６章

-

1 -

調達）

（第３編第６章 調達）

目次
Step.1 調達の活動の全体の流れ ................................. 5
Step.2 調達の事前準備 ............................................ 7１ 調達の単位・計画を確認する ...................................................... 7
A. プロジェクト立上げ時点で調達を計画する ............................ 7
B. 様々な調達単位があることを理解する ................................. 7
C. 調達にあった落札方式、評価方式を検討する ....................... 10
D. 調達計画を早めに公開する ............................................. 10
E. 契約方式を検討する ...................................................... 13
２ 調達の注意事項を理解する ....................................................... 18
A. 調達手続の基本的なルールを確認し理解する ....................... 18
B. 入札制限を正しく理解する.............................................. 20
C. 一者応札の状況を改善する.............................................. 21
D. 調達の前にリスクを再確認する ........................................ 24

Step.3 調達仕様書の作成 ....................................... 25
１ 関連ドキュメントとの関係性を理解する ...................................... 25
A. 調達仕様書と要件定義書の住み分けを理解する .................... 25
B. 付属文書を活用して可読性を上げ機密性を確保する .............. 26
C. 既存情報システムの機能改修を行う場合に準備するドキュメントを理解する ..................................................................... 26
２ 調達仕様書の記載内容を理解する............................................... 27
A. 調達の意図や目的を正しく伝える ..................................... 28
B. 関連する調達、入札制限を伝える ..................................... 28
C. 作業内容・納品物を関連付けて網羅的に記載する ................. 29
D. 外部事業者の具体的な作業内容を明確にする ....................... 29
E. 作業の実施体制を明確にする ........................................... 30
F. 成果物の取り扱いに注意する（知的財産権） ........................ 33-

2 -（第３編第６章 調達）

G. 再委託に関する事項を定める........................................... 33
H. 納品後に不具合が発覚したときの責任を明確にする。(契約不適合責任) ............................................................................ 34

Step.4 調達仕様書以外のドキュメント作成 ................. 37
１ プロジェクトに合わせた契約書を作る ......................................... 37
A. 調達仕様書と契約書の整合性を確認する............................. 37
２ 提案依頼書の内容を工夫する .................................................... 37
A. 具体的な作業計画を評価する ........................................... 38
B. 加点の配分を工夫する ................................................... 40

Step.5 調達手続とプロジェクト管理 ......................... 42
１ 調達手続に伴うプロジェクト管理作業とは ................................... 42
A. 第一次工程レビューを意識して資料をチェックする .............. 42
２ 情報システムの調達に特有の注意点 ............................................ 43
A. ベンダーロックインを理解し、回避する............................. 43
B. 入札参加要件を緩和する ................................................ 47
C. 入札事務手続きを簡素化する ........................................... 47

Step.6 検収 ........................................................ 49
１ 検収の位置づけと内容を理解する............................................... 49
A. 検収と受入れテストの違いを理解する ............................... 49
B. 残存する課題（軽微な瑕疵等）の対応を明確にする .............. 49-

3 -（第３編第６章 調達）

事例・参考の一覧
事例：サブシステム間でのシステム監視業務の統合 ................................... 9
事例：複数の組織で共通利用するＬＡＮ構築の調達 ................................... 9
事例：異なる立場の職員による説明会の実施 .......................................... 11
参考：ＩＴダッシュボードから事業者を選定する .................................... 12
事例：大規模システムでの契約方式選定の工夫 ....................................... 14
参考：アジャイル開発を行う場合の契約方式 .......................................... 15
事例：調達日程表のイメージ .............................................................. 19
様式例：調達仕様書のひな形 .............................................................. 27
事例：発注者にも受注者にも遵守しなくてはならない義務がある................. 30
参考：作業実施体制に関する注意点 ..................................................... 32
事例：知的財産権の帰属先が問題となった例 .......................................... 33
事例：再委託に関する失敗例 .............................................................. 34
事例：事業者の設計・開発実施計画書の作成能力に問題があった例 .............. 38
参考：総合評価落札方式の加点配分について .......................................... 40
参考：クラウドサービス利用時のベンダーロックインに対する注意点 ........... 45
参考：ベンダーロックインによる問題を回避するための工夫 ...................... 45
事例：総合評価方式の入札参加資格で規模要件を撤廃 ............................... 47
参考：デジタル化による入札事務手続きの簡素化 .................................... 47※事例には当時の役職名やシステム名を使用しているため、現在使用されていな
い名称が記載されている場合があります。

-

4 -（第３編第６章 調達）

Step.

1 調達の活動の全体の流れ

プロジェクトの中で検討してきたことを具体的に形作るためには、プロジェクトの目的と内容に適した事業者を選定することが重要です。１つのプロジェクトでは、通常、複数の調達を実施します。情報システムの設計・開発や保守・運用の委託、必要となる製品の購入や保守契約等が代表的ですが、その他にも調査研究やプロジェクト管理支援等の支援業務の委託、コールセンタやデータ入力等の運用サポート業務の委託、必要となる施設の賃貸借等、様々な種類の調達を実施することになるでしょう。
政府情報システムでは、これらの調達の進め方にルールが定められています。まず、大前提として、国の契約方式は一般競争契約を原則としています。政府の財政的消費は納税者の負担に基づいているため、納税者の機会均等と公正な処理を行うべきであり、金銭面での有利性を見いだすことが必要であるためです。
ここでは、このような調達を進める際の具体的なルールや手順とともに、発注者として知っておくべき工夫・ノウハウについて、説明します。
本ドキュメントの構成は、次のとおりです。

Step.2 調達の事前準備
多くの方は、プロジェクトの立ち上げと同時に調達を意識するのではないでしょうか。
調達について計画を具体化していく際にまず知っておくべきこととして、調達の単位・計画
や、調達の決まりごと等を説明します。

Step.3 調達仕様書の作成
調達仕様書とは、プロジェクトの目的の達成に必要な製品の入手や、必要となる役務を実施する外部事業者を選定するために示す、発注者側の条件を集めたドキュメントです。
ここでは、設計・開発作業を行う外部事業者を選定するための調達仕様書をサンプルとして、調達仕様書に記載する事項ごとに何に気をつけて記述すべきかを解説します。

Step.4 調達仕様書以外のドキュメント作成
調達では、調達仕様書以外にも様々なドキュメントを用意する必要があります。
ここでは、その主なドキュメントとして、提案依頼書と契約書を対象として、記載項目の紹介と作成時の留意点について解説します。

Step.5 調達手続とプロジェクト管理
プロジェクトの活動において、調達はそれ以前の活動の結果を集約し、その後の活動を方向づけるプロジェクトの結節点とも言えます。このタイミングでのポイントをおさえた上で調達手続きを行うことは、プロジェクト管理の視点からも重要です。
ここでは、調達活動中に実施するプロジェクト管理作業について解説します。

Step.6 検収調達の結果、外部事業者との契約が締結され、製品の購入手続も含め委託した作業がス-

5 -（第３編第６章 調達）

タートします。その結果、製品であれば納品、作業であれば完了報告が行われ、発注者はそれに対して検収を行ないます。
ここでは、設計・開発作業の外部委託をサンプルとして、プロジェクト活動の終了と調達に伴う検収との関係について解説します。

-

6 -（第３編第６章 調達）

Step.

2 調達の事前準備

調達は、プロジェクト成功の命運を左右する重要な活動です。プロジェクトの成功に向けて目標を着実に達成するためには、不調や不落といった後々の手戻りにつながることを防ぎ、さらには調達した情報システムを継続的に利用していくに当たって一者応札やベンダーロック
イン等による適正な競争を阻害する事態が発生しないよう十分な注意を払い、確実に調達内容を履行できる外部事業者又は製品等を選定できるように、事前に十分な時間を設けた上で準備をすることがとても大切です。
ここでは、実際の調達を始める前に行う事前の準備について説明していきます。

１ 調達の単位・計画を確認する【標準ガイドライン関連箇所：第３編第６章第１節】

情報システムを整備する多くのプロジェクトでは、外部事業者への作業の委託や製品の購入などの複数の調達が行われますが、情報システムに関する専門的な知識を有していないと、何の調達をどの単位でいつ行うかよくわからないものです。
しかし、ポイントを押さえて事前準備をすることで、実際の調達時に不十分な内容に起因す
る手戻りなどによる無駄な手間をかけずに効率的に調達作業を行うことができます。
では、具体的な調達の事前準備のポイントは次のとおりです。

A. プロジェクト立上げ時点で調達を計画する
調達の計画では、「何の調達を」「どの単位で」「いつ調達するか」を計画します。
調達の計画は、まず、プロジェクトの立上げ時に行うことが一般的です。プロジェクトの立上げ時には、プロジェクトの概要スケジュールとして「どの活動を」「いつ行うか」を計画していきますが、その際に「どの活動を事業者に委託するか」「製品等がいつから利用可能になるか」を踏まえて、予算要求の計画も行っていきます。これらの内容は、まさに調達の計
画の基礎情報となりますので、後々漏れることのないよう、プロジェクト計画書の実施計画（標準ガイドライン「第２章２．1) カ 実施計画」参照）に調達の計画も明記・可視化しておくべきです。
また、プロジェクトの立ち上げ時点で調達計画を立案することには、以下のメリットがあります。

プロジェクト立上げ時点で調達計画を立案するメリット
予算要求時点等、プロジェクト初期の段階でＰＭＯの確認や助言を受けることができます。
プロジェクト計画等の公開と併せて調達計画を公開することで、事業者に事前に調達の内容や時期を伝えることができ、事業者から多くの提案を得られる可能性が上がります。

B. 様々な調達単位があることを理解する

-

7 -

注記
ベンダーロックインとは、ソフトウ
ェアの機能改修やバージョンアップ、ハードウェアのメンテナンス
等、情報システムを使い続けるために必要な作業を、それを導入した事業者以外が実施することができないために、特定の事業者（ベンダ）を利用し続けなくてはな
らない状態のこと。

（第３編第６章 調達）

調達の計画で「何の調達を」「いつ調達するか」を特定した後、それらの調達を「どの単位で行うか」を検討します。
調達の単位は、標準ガイドライン解説書「第６章１．1) 合理的な調達単位の検討」で示す
16 種類が基本項目となりますが、これらの複数を１つの調達にまとめることや１つの単位を分割して複数の調達にすることも可能です。最適な調達の単位は、プロジェクトの規模や性質によって異なります。
また、調達を複数に分ける考え方を分離調達と言い、そのメリット及びデメリットは次のとおりです。

分離調達を実施した場合のメリット・デメリット
分離調達によるメリット
特定事業者に偏るというベンダーロックイン状態の解消
競争性・透明性の向上による価格の適正化と提案内容の質の向上
競争による市場の活性化
分離調達によるデメリット
調達を分割して参画する事業者が増えることによる、事業者の管理や事業者間の調整、リスク管理や問題発生時の対処等、発注者側の管理労力の増加及び調達作業負荷の増加

これらの分離調達のメリットとデメリットを理解し、競争性・透明性を保ちつつ、適切なプロ
ジェクト運営が行えるよう、プロジェクトの規模や性質に合った調達の単位を検討してください。
なお、十分な検討をせずに調達単位を決めてしまうと、事業者からの応札がなく不落となったり、一者のみからの応札となったりする場合もあり、結果として分離調達の意義が失われるおそれがあります。
以下に、調達単位を検討する際の具体的な事例を挙げます。

調達単位を考える際に留意すべき具体例
問題となる例【現行情報システムの調査】を、今後整備する新たな情報システムのアプリ
ケーション設計・開発、機器賃貸借業務に含める。
【現行情報システムからのデータ抽出】を、今後整備する新たな情報シス
テムのアプリケーション設計・開発、機器賃貸借業務に含める。
現行情報システムに対する作業を、これから予定している調達の中に含めた場合、現行情報システムの知識を十分に有する既存の運用・保守事業者が有利となり、競争性が損なわれるため、問題となります。

慎重に検討すべき例【アプリケーションの導入】を機器賃貸借業務に含める。
アプリケーション及び機器の【総合テスト】を機器賃貸借業務に含める。

-

8 -（第３編第６章 調達）【データ変換/投入作業】を全面的に機器賃貸借業務に含める。
【情報システムの切替え作業】を全面的に機器賃貸借業務に含める。
【障害の切り分け】を機器賃貸借業務（保守業務を含まない）に含める。
アプリケーション設計・開発事業者がＳＷを選定・設計・開発し、【ＳＷの導入】のみ機器賃貸借業務に含める。
専門性の異なる分野の業務を安易に束ねてしまうと、本来であれば多数の事業者に参入機会がある業務であっても、特定の事業者にしか応札できないものとなってしまいます。
ただし、１つの事業者が関連する作業をまとめて実施した方が、全体として効率的な場合もあります。上述のような例については、調達単位を分割することによる競争性確保と、束ねることによる効率性向上の両面を検討した上で、調達単位を決めてください。

プロジェクトを跨って調達単位を統合した例（良い事例）
複数のプロジェクトやサブプロジェクトで別々に実施していた業務を統合する。
複数の組織で別々に実施していた業務を統合する。
１つのプロジェクトだけで調達を行うだけでなく、他のプロジェクトや他の組織と連携することで、調達単位を統合し、対象業務も効率的に実施できる可能性があります。

事例：サブシステム間でのシステム監視業務の統合

事例 6-1
サブシステム間でのシステム監
視業務の統合あるプロジェクトでは、複数のサブシステムを持つ大規模情報システムの監視・運用コストの見直しに取り組んでいました。このプロジェクトでは、サブシステムの単位でサブプロジェクトの体制を組んでおり、各サブシステムの運用・監視を行う事業者を個別に調達していました。
現状の監視・運用業務を調査した結果、個別に実施している運用・監視業務の中には類似作業が多く含まれており、これらを統合することによって更に効率的に実施できることが明らかになりました。そこで、サブシステムごとに保有していた統合監視サーバ、統合監視端末、パッチ配信サーバを１セットに統合し、運用作業についても一元管理する事業者を調達する方針に変更しました。

事例：複数の組織で共通利用するＬＡＮ構築の調達
ある地方拠点事務所では、同一拠点で複数の組織が業務を行っており、過去の経緯からＬＡＮが個別に整備されていました。
ＬＡＮの整備や運用に関する煩雑な業務とコストを削減するため、中心と-9 -事例 6-2
複数の組織で共通利用するＬＡＮ
構築の調達

（第３編第６章 調達）なる組織の担当者がＬＡＮの統合に向けた検討を行いました。検討の中では、まず現状を詳細に把握するところからスタートしました。例えば、それぞれのＬＡＮでは、メールやグループウェア等の業務を行うためのサーバを多数導入していましたが、各サーバの CPU やメモリの使用率を調べると余裕が大きいことがわかりました。そこで、これらのサーバを統合することでコストを削減するとともに、サーバを設置していたサーバルームについても統合することとしました。
このように、ＬＡＮを統合して共通利用する場合のメリットとデメリットをまとめ、複数組織合同による情報化推進委員会に諮り、改善を進めました。

C. 調達にあった落札方式、評価方式を検討する
情報システムの整備に関する調達を行う際には、実施する案件の技術面や管理面等の難しさを踏まえて、調達内容を着実に履行できる事業者を選定する必要があります。残念ながら、契約した事業者が調達内容を十分に履行できずに、うまく立ち行かなくなったプロ
ジェクトは少なくありません。
このような事態を防ぐためにも、調達時には、その内容に適した落札方式を選択し、価格以外の技術的な評価を行う場合は、審査に必要となる評価基準、審査体制等を十分に検討した上で事業者の選定の準備を整えます。
総合評価落札方式には、除算方式と加算方式という２つの評価方式があります。ただし、除算方式は価格点が分母となり低入札価格による影響を極端に受けやすいため、基本的には加算方式を採用するのが良いでしょう。
調達の計画時点で、落札方式や評価方式も合わせて検討し、調達の手続を適正に行えるように、計画を立てるようにします。

D. 調達計画を早めに公開する
入札が不調（応札者が現れない）や不落（応札価格が全て予定価格を超過）となってしまうと、プロジェクト全体のスケジュールが大幅に遅延してしまいます。また、一者だけからの応札となってしまうと、十分な価格競争が働かない可能性があります。
このような事態を防ぐためには、次に示すような対策を行い、極力多数の外部事業者から応札を受けられるように準備しましょう。
過去に別プロジェクトで情報システムの調達を行った際に、応札や仕様書を受領した外部事業者等に問合せる。
プロジェクトの目的の達成に必要な技術的要件が明らかな場合には、その要件に合致しそうな製品等を探す。

-

10 -

（第３編第６章 調達）

さらに、調達計画を広く公開して透明性を確保し、外部事業者がプロジェクトの目的や調達内容について十分に理解できるような公平な機会を設けることも有効です。似たような調達が過去にないなどで外部事業者が見つからないときや調達計画の公開を検討する際
は、ＰＭＯに相談してください。

事例：異なる立場の職員による説明会の実施ある省庁では、ＲＦＩやＲＦＰを実施する前に、調達内容に関連しそうな事業や製品等を提供可能な外部事業者を複数探しだし、透明性を確保した上で説明会を開催し、公正に直接意見交換を行う機会を設けています。
このとき、担う業務特性又は所属部署に基づく特定の立場の職員だけが説明を行
うと、外部事業者に伝える内容に立場上の偏りが生じるおそれがあるため、会計担
当、技術担当等の異なる立場の職員が、それぞれの視点から説明を行うようにしています。また、大規模な情報システムでは、サブシステムごとに個別の説明会を実施
し、外部事業者へ丁寧な情報提供を行っています。

この結果、ＲＦＩによる有用な情報の入手や、公正で適切な調達が実行しやすくな
り、プロジェクトの目的の達成に大きく寄与しました。

-

11 -

事例 6-3異なる立場の職員による説明会の実施

（第３編第６章 調達）

参考：ＩＴダッシュボードから事業者を選定する
ＩＴダッシュボードの契約情報（行政事業レビュー）から、関連する外部事業者を把握することができます。
https://cio.go.jp/itdashboard
契約情報画面では、年度ごとに契約した事業者名、事業、調達額等を確認することができます。また、グラフを構成しているデータはＣＳＶダウンロードボタンよりダウンロードも可能です。
事業情報（ＣＳＶダウンロードボタン）
事業支出（ＣＳＶダウンロードボタン）
事業予算（ＣＳＶダウンロードボタン）「○○年度運用等経費 10 億円以上の情報システムに関わる事業一覧」では次に示す情報が参照可能です。
(1) 支出先別支出金額
支出金額を企業別に見ることができます。行政事業レビューには情報システム関連経費以外も含まれますので、情報システム別の予算とは一致しないことに留意してください。
(2) 選択ベンダ（事業者）の参加事業一覧
選択したベンダが関係する事業の一覧を見ることができます。
参加事業名を選択すると、公開されているレビューシートを参照することができます。

※ 上図では事業者名を匿名化していますが、実際には事業者名が表示されます。

-

12 -

参考 6-1
ＩＴダッシュボードから事業者を選定する

（第３編第６章 調達）(3) 支出先別支出金額割合
支出金額割合を企業別に見ることができます。行政事業レビューには情報システ
ム関連経費以外も含まれますので、情報システム別の予算とは一致しないことに留意してください。

(4) 運用等経費 10 億円以上の情報システムに関わる事業の支出先(上位 20 件)の分布(昇順)
支出先金額、支出金額割合の関係を見ることができます。

E. 契約方式を検討する
政府情報システムの調達は、原則として一般競争入札によって行うこととされています。
これは、不適切な調達を行っているのではないかと国民から疑念を抱かれないように、公共調達の競争性及び透明性を確保する必要があるためです。安易に随意契約を行うと、

-

13 -

注記
公共調達の適正化について
https://www.mof.go.jp/budget/to
pics/public_purchase/koukyou/koukyou_02.htm

（第３編第６章 調達）競争性や透明性が損なわれ、国民に対する説明責任を十分に果たすことができなくなる
おそれがあるため、「随意契約によらざるを得ない場合」を除いて随意契約を行うべきではありません。
どのような場合に「随意契約によらざるを得ない場合」とされるのかを理解するとともに、今回の調達の特性を踏まえ、どのような契約方式を選択すべきか検討する必要があります。
なお、仕様を詳細に確定させることが困難であるなど、発注者と事業者が対話を通じて相互理解を深めた上で契約することが特に重要な場合には、まだ政府では試行運用の段階ですが、技術的対話を取り入れた新たな調達・契約方法を採用する選択肢もあります。
詳細は「情報システムに係る新たな調達・契約方法に関する試行運用のための骨子」（令和元年５月 29 日 CIO 連絡会議決定）を参照ください。

事例：大規模システムでの契約方式選定の工夫ある大規模システムでは、毎年多数の契約が恒常的に発生する中で、ベンダーロ
ックインを防ぎつつ、価格交渉力を維持した契約方式を選べるよう、様々な工夫を行っています。以下で、具体的にどのような工夫を行っているかご紹介します。
まず、会計法令、デジタル・ガバメント推進標準ガイドラインなどのルールを前提に、個々の契約内容が中長期計画、プロジェクト計画書等と整合することを確認して予算・執行の妥当性を確保するとともに、CIO 補佐官、外部有識者、事業者、支援業者等からの意見等を踏まえ、客観的な実現性や公平性・公正性を保つために、予算管理・執行管理プロセスのチェック体制を整えました。
また、調達案件の特性に応じた契約方式を速やかに選定するための文書・ルー
ルをオーソライズし、実際に運用を開始しています。以下のフロー図は、契約方式選定までの流れを示す文書です。

さらに、随意契約となるケースをパターン化（後述）するとともに、開発案件の属性によって、どの随意契約のパターンに当てはまる可能性があるかを下表のように整理することで、随意契約の妥当性を迅速にチェックできるようにしました。

-

14 -

注記
情報システムに係る新たな調達・契約方法に関する試行運用のための骨子（令和元年５月 29 日
CIO 連絡会議決定）
https://www.kantei.go.jp/jp/singi/it2/cio/kettei/20190529kettei_1.
pdf
事例 6-4
大規模システムでの契約方式選定の工夫

（第３編第６章 調達）

随意契約のパターンは、これまでの実績等を踏まえて下表のように整理しました。
また、パターン化することに加え、これまで組織的に会計法を解釈し、随意契約の妥
当性を判断してきたものも外部有識者の見解等を踏まえて判断をルール化し、調達手続きの適正化・効率化を図っています。
この２つの表によって、当該開発案件の属性から該当する可能性がある随意契約の理由をマッピングすることができ、適切な契約方式を迅速に選定できるようにしています。

参考：アジャイル開発を行う場合の契約方式
アジャイル開発は、利用者にとって優先度の高いものから順次開発・リリースを進め、運用時の技術評価結果や顧客の反応に基づいて素早く改善を繰り返すという開発手法です。DX（デジタルトランスフォーメーション)時代における激しいビジネス
環境の変化に対応し、利用者が真に必要としている価値を提供するプロダクトをタイムリーに開発する手法として有用であるとされています。
また、アジャイル開発では、開発プロセスの中において、ビジネス環境の変化やユーザ企業内部のニーズの変化などに応じて、開発する機能の追加・変更やその

-

15 -

参考 6-2
アジャイル開発を行う場合の契約方式

注記「アジャイル開発版「情報システ
ム・モデル取引・契約書」」
https://www.ipa.go.jp/ikc/reports/20200331_1.html

（第３編第６章 調達）

優先順位の変更が行われ、当初は開発予定となっていた機能を開発対象から外す場合もあります。そのため、あらかじめ内容が特定された成果物を予定したとおりに完成させることに対して対価を払う請負契約より、業務を受託した事業者が専門家としての注意義務を果たしながら業務を遂行することそれ自体に対価を支払う準委任契約の方が馴染みやすいとする意見もあります。
一方で、政府の調達においては、伝統的に請負契約が用いられることが多いことも事実です。これは、法令などの制約に基づくものではなく、受注者の義務及びそれへの対価が明確であり、投入した費用に対する成果を国民に説明しやすいとの理由によるものです。
そこで、本項では、請負契約と準委任契約のメリット・デメリットを記すとともに、これらをアジャイル開発の契約方式として採用するに当たっての留意点について整理します。アジャイル開発の契約にあたっては、これらについて十分に検討し、個々の事情や条件、制約などに応じて最適な方式を採用する必要があります。
請負契約
説明
発注者が指定した成果物(ソフトウェア・機能など)を完成させることを受注者が約束する契約。
メリット・デメリット
メリット
契約締結時に、機能要件や非機能要件を明確に定めることができ、受注者の責任範囲が明確になる。
成果物が合意した仕様を満たしていないことが納品後に判明した場合、受注者に契約不適合責任（無償の修補、代替物の提供、代金減額等）を求められる。
費用の妥当性を外部に説明することが容易。
デメリット
契約前の見積りで対価が固定されてしまうことが多い。
工数が変動する要件、機能等の変更を行いにくい。
想定外の技術的困難の発見や体制変更などに対応しづらい。
アジャイル開発における留意点
一括請負契約としてしまうと、対価が固定されている受注者としては、工数の増える要件、機能等の変更をできるだけ減らすことがその利益に適うため、アジャイル開発の求める柔軟な機能変更等ができなくなるリスクがある。
開発対象のプロダクト全体を成果物とするのではなく、要件定義やプロトタイ
プの製作などについては別契約（準委任契約）で実施した上で、要件変更の可能性を極小化した部分について採用するのが望ましい。
採用するに当たっては、事後的に機能等の変更のきっかけとなり得る技術
的な困難も洗い出しておくことが望ましい。
成果物については、双方協議の上、工数を変えない範囲で要件、機能等を変更可能であることなどを契約書に記すのが望ましい。
準委任契約
説明
受注者は、成果物を完成させる義務は負わず、善管注意義務（民法第 656 条、第 644 条）を負い、専門家として期待される能力を以って業務を真摯に行うことが求められる契約。

-

16 -（第３編第６章 調達）

メリット・デメリット
メリット
要件、機能、優先順位等の変更が請負契約より容易。
受注者側要員の知識・スキル・経験を求めることが可能。
受注者側の要員を工数で管理することが可能。
要件、機能等の変更により工数が変化した場合に支払う対価（総額）が変動するため、合理的な開発費となる。
デメリット
成果物が完成しなくても、受注者に対し責任を問えない。
履行割合型で報酬を定めた場合、成果物が完成していなくても報酬の支払義務が発生する。
善管注意義務や専門家責任を客観的に評価することが難しい（監督職員、検査職員の負担が増える）。
予算の範囲内での執行の管理が請負契約より難しい。
成果物に不具合があった場合に受注者に契約不適合責任（無償の修補や減額等）を当然には求められない。ただし、善管注意義務違反を理由として損害賠償請求をすることは可能。
アジャイル開発における留意点
期待される品質保証（サービスレベル）を明確にすることや、一定の成果物（レポートを含む）の納入を求める場合はその要件を明確にすることで、善管注意義務違反の有無の判断を客観的にできるように工夫することが望ましい（どのような事象が善管注意義務違反にあたるかを確認、合意しておくことも考えられる。）。
期待される品質保証や成果物の要件が達成できない場合は、その理由を説明させる義務を定めておくことで、監督、検査の負担が軽減される。
一定の品質保証や成果物の要件を満たす場合にのみ報酬が支払われる報酬体系（成果報酬型）とすることも検討される。
アジャイル開発を行うための体制、役割分担等を明確にし、執行内容の管理を適正に行う必要がある。
発注者側がアジャイル開発業務の体制、役割を理解し、システム開発全般にわたって、主体的に関与する必要がある。
準委任契約の類型～報酬の定め方
準委任契約には、成果物が完成したか否かにかかわらず、委託業務の履行に要した時間や工数に応じて発注者が報酬を支払う履行割合型契約と委託業務の成果に対して報酬が支払われる成果報酬型（成果完成型）契約があります。成果報酬型
は、実務上は従前から用いられてきた類型ですが、新民法において明記されています（民法第 648 条の 2）。報酬の定め方はどちらか一方にすることが義務付けられておらず、複合的に用いることも可能です（一定の指標をクリアしたことに対する加算として成果報酬を定めることなども検討されます）。ただし、成果報酬型契約の場合、契約の性質が請負契約に近づくため、アジャイル開発を選択している趣旨を失わないように注意する必要があります。
なお、民間においては、受注者に対して一定のスキル・知識・経験を持った要員が約束された工数分作業することを求める一方で、部分的に成果物の完成責任も求めるような、請負型と準委任型の性質を併せ持つ契約を行う例もあります。
また、準委任契約において、バックログ管理表や変更管理表を最終成果物として納品させる例もあります。それらに最終的に記載された機能や非機能を実現する作
業が全て完了していることが検収の条件となり、実質的にソフトウェアの品質を受注者が保証することを可能にする例です。

-

17 -

（第３編第６章 調達）

２ 調達の注意事項を理解する【標準ガイドライン関連箇所：第３編第６章第１節】

調達は、契約方式や金額等に応じて調達手続や公示期間等が定められているため、いざ調達の準備を開始しようとした時点で、当初想定していたよりも時間がなかったことに気が付くことが少なくありません。調達の準備の時間が十分に取れないと、資料の準備不足や説明会等の不足から事業者への十分な理解が得られず、入札の不調や不落となりかねません。
このような不測の事態を防ぐために、プロジェクト計画の段階で調達に係るルールを理解し、調達に必要な期間を踏まえて準備を行えるように調達の計画をたてることが重要です。

A. 調達手続の基本的なルールを確認し理解する調達に関する期間等のルールは、政府調達に関する協定や会計法等で調達手順や期間等が定められています。標準ガイドライン解説書「第６章１．調達の計画」に記載している
ルールを確認して、計画を立ててください。
調達手続の流れについて、以下の図に示します。予定価格や案件の規模等により、必要な期間が異なるので、余裕を持った計画を立てるようにしましょう。

図 6-1
ＩＴ調達手続の流れ

また、上の図について、関連する法令等をまとめた図を、以下に示します。

-

18 -

（第３編第６章 調達）

図 6-2
調達に関する法令等

調達の手続については、協定や法令等で定められたルール以外に、各府省で独自のルールを定めている場合もあります。府省のルールによっては、公示のタイミングや期間が変わることもありますので、プロジェクト計画時点で各府省の調達ルールを所管する部署に対して確実に確認するようにしてください。

事例：調達日程表のイメージある省では、調達ごとに調達ルールに従った日程表を作成してプロジェクト内で共有し、イベントや作業締切日等を、調達に係る関係者が確実に把握できるようにして
います。

-

19 -

事例 6-5
調達日程表のイメージ

（第３編第６章 調達）

B. 入札制限を正しく理解する
調達の単位を検討する際には、一部の事業者が有利とならないよう、それぞれの調達案件に対して適切な入札制限を設けて、透明性と公正性を確保する必要があります。また、調達案件の業務内容によっては、他の調達から独立性や客観性を担保するために入札制
限が必要な場合があります。
標準ガイドラインでは、入札制限について、以下のように定めています。

b) 入札制限
透明性及び公正性並びに確実な契約履行等を確保するため、次のｲ）からﾊ）までに掲げる者に対し、入札制限を定めるものとする。
ｲ) 各工程の調達仕様書の作成に直接関与した事業者
各工程の調達仕様書の作成に直接関与した事業者は、透明性及び公正性の確保の観点から、当該調達案件の入札に参加させないものとする。ただし、競争上何ら有利とならないと認められるときは、この限りでない。
ﾛ) 設計・開発等のプロジェクト管理支援事業者
設計・開発等のプロジェクト管理支援事業者（プロジェクトの全部又は一部におけるプロジェクトの管理上生ずる作業について、ＰＪＭＯを支援する事業者をいう。以下同じ。）については、相互けん制の観点から、その管理の対象となる情報システムの設計・開発の作業に関する内容を含む調達案件の入札に参加させないものとする。
ﾊ) 監査対象である情報システムに関与した事業者
監査対象である情報システムに関与した事業者は、監査の独立性及び客観性の確保の観点から、当該情報システムの監査業務に関する調達案件の入札に参加させないものとする。
（標準ガイドライン「第３編第６章第３節 1）ク b)」）

-

20 -

（第３編第６章 調達）

ただし、「ｲ) 各工程の調達仕様書の作成に直接関与した事業者」に関しては、注意が必要です。例えば、調達仕様書の一部となりうる調査研究等を実施した事業者に対しても、その内容が調達内容や調達方法の決定に直接関わるものでなければ、設計・開発工程への入札制限を設ける必要がないと考えることができます。大切なことは、意思決定の責任は発注者にあることを認識し、他の応札事業者に対して、公正性が確保できる（競争上何ら有利とならない）環境を整備していくことです。
入札制限の意図を正しく理解し、透明性・公正性を確保しつつ、過度な入札制限を設けることで競争の機会損失や調達事務の効率性等を損なうことのないよう、調達単位を検討します。

C. 一者応札の状況を改善する
ＲＦＩ等の事前情報収集や事業者との調整をしても、結果的に一者応札になってしまうことはあります。ですが、同じプロジェクトの案件で一者応札が続いてしまうのであれば、競争性を確保する観点から改善方法を考えるべきでしょう。
まず、既存事業者の優位性について考えてみましょう。既存事業者は、情報、要員、保有資料の３点において優位性を持っています。

入札における既存事業者の優位性
情報の優位性
既存事業者は既存システムの設計情報等を保有しているため、関連業務に関して既存の情報を前提とした作業見積を行うことができ、受注後も作業を速やかに実施することが可能になります。
一方、新規事業者は応札に当たってこれらの情報の収集、分析及び習得に時間とコストを必要としますし、情報不足によって見積りミスや仕様の取り違えも起きかねないためリスクを勘案する必要もあり、見積金額が高額になりやす
いと言えます。
要員の優位性
既存事業者は既存システムを開発した要員を確保しており、この要員を次の関連業務に活用することが可能となります。
一方、新規事業者は関連業務を実施するために、情報システムの内部情報等を習得した要員を新たに育成する必要があり、教育の期間とコストを考慮する必要があります。
保有資料の優位性
情報の優位性と似ていますが、提案書作成や見積作成等の提案活動自体についても、保有資料の有無で優位性が異なります。
既存事業者は既存システムに関する設計書や提案書等の資料を電子データで保有しているため、提案活動を効率的に実施できます。
一方、新規事業者は調達仕様書や閲覧資料等の紙面の情報から、ゼロから提案書を作成するため一定の時間とコストを必要とすることになります。

つまり、新規事業者にとっては既存システムの業務の受注にはそもそもコストやリスクが大きく、既存事業者との競争に勝てないと判断した新規事業者は、応札そのものを断念す
ることになります。
逆に言うと、一者応札の状況を是正するには、この既存事業者の優位性を相対的に低

-

21 -

（第３編第６章 調達）

下させ、新規事業者にとっても競争が可能であることを理解頂くことが重要です。
そのための具体的な施策例を紹介します。

一者応札状況を改善するための施策例
十分な準備期間の確保
新規事業者に対し、既存システムに関する技術的調査などを行うための十分な期間を確保します。
例えば、公告前にＲＦＩや公平性等を確保したヒアリングを実施すること、公告期間を調達手続上求められる最小限の日数よりも長く確保することなどが考えられます。
これにより業務内容、情報システムの仕様や稼働状況を把握した上での正確な見積りが可能になり、新規事業者にとってのリスクの低減につながります。
ＲＦＩの実施については「第 3 編第 5 章 Step3-1-A 参考：ＲＦＩ（資料提供依頼）、資料提供招請、意見招請の関係」を、公平性等を確保したヒアリングの実施については「第 3 編第 5 章 Step3-2 公平性等を確保したヒアリングを行う」
をご参照ください。
設計情報等の詳細開示
既存システムの基本設計書や詳細設計書等を、入札時の閲覧資料等として新規事業者が確認できるようにします。
なお、ハードウェア、ソフトウェア、ネットワーク等の構成情報、データの種類やデータ量等は調達仕様書（非機能要件定義書）にも記載しますが、この情報だけでは新規事業者にとってシステムの実態をつかむことは困難です。設計書等を開示することでアプリケーションの構造や特性を詳細に理解できるとともに、ドキュメント等の整備状況についても新規事業者が理解し、実態に合った工数積算を行えるようになります。
運用・保守業務の作業内容や実績情報の開示
既存システムの運用・保守に関連するドキュメント（運用設計書、運用手順書、
運用マニュアル、保守設計書、保守手順書、保守マニュアル等の名称が多い）についても、入札時の閲覧資料等として新規事業者が確認できるようにします。
また、運用・保守業務の実績がわかる資料も重要です。具体的には、サービスレベル実績、障害やインシデントの管理情報、コールセンタやヘルプデスク業
務の対応実績、変更管理実績等の情報です。運用・保守業務の各種報告書（運用報告書、保守報告書、作業報告書等の名称が多い）も、新規事業者にとって参考になる部分があります。
既存事業者が優位となる作業の分離
既存事業者が優位性を持つ作業を委託業務から分離することで、分離後の調達業務の競争性を高めることができます。
例えば、次のようなことを検討することが有効です。
・既存システムを一括で再構築するのではなく、サブシステム単位で分離して新規事業者から参入しやすくする・運用業務から業務アプリケーションの障害対応や修正等を分離し、定常的で手順書に沿った運用業務部分を調達範囲とする
・機器賃貸借業務から、業務アプリケーションに関連する作業（設定変更、修正等）を分離する
汎用的な製品への移行

-

22 -

（第３編第６章 調達）

特定の事業者しか供給できない製品（ハードウェア、ソフトウェア）ではなく、汎用的な製品やオープンソースソフトウェア（OSS）を調達品目とします。現行の業務アプリケーションを汎用製品に適合させるための改修作業は必要になりま
すが、製品を供給できる事業者の選択肢が広がります。
前提条件等の緩和
事業者に求める資格や実績要件を十分に検討した上で、可能な限り仕様を緩和することで多くの事業者の参入を促します。例えば、資格要件の記載について当該資格の保有を絶対条件として求めるのではなく、他の代替可能な資格や能力を含めた要求事項とすることや入札参加等級を緩和することで、多様な事業者の参入を促すことが望ましいです。
【例１】 ISO9001 の認定事業者であること、又は同等の認定を受けていること。
【例２】官公庁における同規模の情報システムの導入実績を持つこと、又は当該業務分野に関する業務や関係法令の知識を持ち同規模の情報システムの導入実績を有すること。
【例３】当該業務分野の情報システムの導入実績を持つこと、又はその情報システムと同程度の難易度、信頼性及び特性を有する情報システムの導入実績を持つこと。
契約期間の複数年度化
運用、保守業務を例にとると、新規事業者は受注後に既存システムの調査、運用保守に関わる知識の習得、作業プロセスの定義、各種連絡票や報告様式の定義等を実施します。この作業に多くのコストを要するため、契約が単年度であれば新規事業者は採算が取れないことがあります。
そのため、契約期間を複数年度にすることで、この初期コストを吸収できる契約形態も考慮することが望ましいです。
委託内容に関する数量情報の開示
作業内容を文章で表現するだけでなく、定量的に数値として示すことで新規事業者が業務の規模を把握しやすくなります。
例えば、システム改修の場合、改修する画面や帳票、データ項目を明確にし、その数量も提示しましょう。運用業務の場合であれば、前年度とほぼ同じ作業になることが多いため、前年度の作業内容や件数、作業量（工数）等を提示することが望ましいです。
次年度の調達を考慮した納品物
次工程や次年度の調達を考慮して、当年度の業務成果をドキュメントとしてわ
かりやすく最新化することが重要です。
特に設計書については、契約単位ごとに分冊として納品されることがあります
が、このような状態では設計内容を理解するために過去の全ての設計書に遡る必要があり、読みこなすことが大変になります。新規事業者も含めて、第三者にとっても読みやすい構成となることを考慮しましょう。
事業者間の引継ぎ期間の確保
開札から作業開始までに、既存事業者から新規事業者への十分な引継ぎ期間を確保することで、新規事業者が参入する上でのリスクの低減につながります。引継ぎ期間が十分に確保できない場合には、調達計画の見直しを検討し
ましょう。

-

23 -

（第３編第６章 調達）

事業者間の引継ぎにおける工夫は、「第 3 編第 7 章 Step6-2 事例：異なる事
業者間で引継ぎをスムーズにする工夫」をご参照ください。

D. 調達の前にリスクを再確認する
第２章 プロジェクトの管理の Step.3 「プロジェクト計画書等の作成」にて洗い出したリス
クについて、調達する前にもう一度振り返りましょう。
リスク管理をせずに安易に調達を行うと、全てのリスクを事業者に負わせることになるた
め、結果として見積もり・入札額が高くなってしまったり、納期遅延を発生させてしまうことがあります。
既存事業者にとって「暗黙のリスク」であっても、新規参入事業者にとっては「見えないリ
スク」があることを理解し、調達仕様書に記載する、調達説明会で説明実施することを心掛
けてください。

-

24 -（第３編第６章 調達）

Step.

3 調達仕様書の作成

調達仕様書は、発注者側の要望（要件）だけでなく、制約となる条件を記載するものです。
実現したいことを書くことはもちろんですが、実現を図っていく過程で守るべき前提条件や制約条件を合わせて書くことで、調達仕様書としての完成度を高めることができます。
この Step では、調達仕様書を作る上で知っておくべき知識・ノウハウをご紹介します。

１ 関連ドキュメントとの関係性を理解する【標準ガイドライン関連箇所：第３編第６章第３節】

調達では、調達仕様書以外にも次のようなドキュメントが存在します。それぞれのドキュメン
トの定義と関係性をあらかじめ理解しておくことが重要です。

図 6-3
調達に必要なドキュメントの関係
図A. 調達仕様書と要件定義書の住み分けを理解する調達案件で満たすべき要件の内容は、調達仕様書の中に全部書いた方が良いのでしょうか？それとも、要件定義書として添付の付属文書にした方が良いのでしょうか？
要件の内容は、様々な内容を取りまとめたものであるため、調達仕様書に直接記載する

-

25 -

（第３編第６章 調達）のではなく、要件定義書を別紙として、調達仕様書に添付することが一般的です。

要件の内容を別文書とした方が良い理由
要件定義の内容は、事業者の提案等を踏まえて、事業者の決定後に発注者との協議を経た上で最終的に決定するものです。つまり、要件定義の内容には変更が入ります。一方で、調達仕様書の内容は、よほどのことがない限り、変更しません。これらに対する変更は明確に分けて管理する必要があり、調達仕様書と要件定義書を分離することで、変更管理が容易になります。
要件定義の内容は、詳細な内容を記載するため量が多くなる傾向があります。調達仕様書の中に全てを記載しようとすると読みにくくなってしまうおそれがあります。
調達仕様書の中に調達に関連する要件のみを記載しようとすると、要件の全体像がわからなくなったり、記載事項が漏れたりする可能性があり、適切な提案や見積りを妨げるおそれがあります。
要件定義書には「こういうシステムがほしい」、調達仕様書には「こういうシステ
ムを作るために何をやってほしい」というように、読み手に伝えたい内容を分けることで可読性が増し、読み手の理解を深めることになります。
これらの内容を踏まえた上で、小規模な調達内容であったり要件の変更の可能性が低
かったりする場合は、調達仕様書の中に要件定義の内容を記載することも可能です。
また、調達仕様書と要件定義書を分けた場合にも、調達仕様書には「要件定義書を満たす旨」のみをただ書けばよいわけではありません。調達単位を分割する場合は、要件定
義書の内容のどの部分が当該調達で満たすべき部分かを指し示す必要があります。要件の中でも提案を求める部分や未確定の部分がある場合は、その箇所を明確にする必要があります。また、調達仕様書に要件定義書の内容のまとめと要件定義書の該当箇所への参照リンクを記載することで、外部事業者の理解を促す工夫をすることも有効です。
ポイントは、外部事業者が要件の内容を漏れなく正確に理解できるか？理解しやすい形式になっているか？です。

B. 付属文書を活用して可読性を上げ機密性を確保する
調達仕様書には、応札等の検討に不可欠な情報を網羅的に示す必要がありますが、調達仕様書の本編に全てを記載することは困難です。無理に記載しようとすると、かえって調達内容が理解しにくいものとなってしまうおそれがあります。それを未然に防ぐため、情報量や粒度に応じて、別文書として準備し、調達仕様書の付属文書とすることを検討すべきです。
また、調達に必要な情報の中には、機密保持の観点から一般に公開できない内容も含まれます。このような内容は、独立した文書として準備し、その文書の閲覧を希望する外部事業者が閲覧手続きを発注者に対して行った上、発注者の立会いの下、執務場所での閲覧等として機密性を確保します。
付属文書は、調達仕様書の「付属文書」の事項にて、事業者が入手又は特別な手続きを経ずに閲覧できる資料一覧として整理し、公開しない文書については閲覧要領にて閲
覧手続き方法を伝えます。

C. 既存情報システムの機能改修を行う場合に準備するドキュメントを
理解する
-

26 -

（第３編第６章 調達）

既存情報システムの機能改修を行う場合には、「Step.3-1 調達ドキュメントとの関係性を理解する 図 6-3 調達に必要なドキュメントの関係図」で示す当該情報システムの要件定
義書とは別に、機能改修の要件を明確にした要件定義書を準備しましょう。

２ 調達仕様書の記載内容を理解する【標準ガイドライン関連箇所：第３編第６章第３節 1)】

この実践ガイドブックには、別添として、設計・開発工程の調達を例にした調達仕様書のひな形を示しています。

様式例：調達仕様書のひな形
調達仕様書のひな形を本章別紙としてまとめています。

このひな形はあくまで例示ですので、調達内容に応じて記載内容を個別に追加、変更して構いません。ひな形を見ると、何をどのようなレベルで書くべきかの参考になると思います。
以降では、調達仕様書を作成するときに、特に注意が必要なポイントについて説明していきます。項目の詳細な説明は、ひな形を参照してください。

-

27 -

様式例 6-１
調達仕様書のひな形

（第３編第６章 調達）

A. 調達の意図や目的を正しく伝える
外部事業者に応札を促してプロジェクトにとって有用な提案を引き出すためには、プロジェクトの背景及び目的、調達に至るまでの経緯、成果物やサービスに期待する効果、プ
ロジェクトの全体像や見通しといった発注者の意図を明確に伝えることがとても大切です。
要件や作業内容を伝えるだけでは、要件どおりの情報システムを構築するために必要な提案は得られるかもしれませんが、プロジェクトの目的や目標をよりよく達成するために十分な効果を発揮する提案を引き出すことができません。
これらは、調達仕様書の「調達案件の概要に関する事項」にて、プロジェクトの背景、調達目的及び調達で期待する効果、業務・情報システムの概要にて記載するとともに、契約期間を含むプロジェクト全体のスケジュールで全体像を示します。

図 6-4
作業スケジュール例

B. 関連する調達、入札制限を伝える
事業者が応札を検討する際に、他の調達案件との関係性を理解してもらうことはとても重要です。事業者によっては後に予定している調達案件への応札を検討していることもありますので、過去や将来の調達案件、それらに係る入札制限も含めて明確に記載します。
今後調達する調達案件の全体像や入札制限の関係については、プロジェクト計画書で明確にした上で、その要点を早期から外部に公開することを推奨します。
もし、これらの関係が明確に示されておらず、事業者がある案件を落札し契約した後で、後続案件に入札できないことが判明すると、大きな問題になってしまいます。
関連する調達や入札制限を明確に記載し早期に公開することで、未然に上記のような事態を防ぐことが重要です。

-

28 -

（第３編第６章 調達）

図 6-5
調達案件及び関連調達案件の調
達単位、調達の方式、実施時期
等の例

C. 作業内容・納品物を関連付けて網羅的に記載する
調達仕様書では、外部事業者の作業内容、納品物をそれぞれ漏れなく定める必要がありますが、設計・開発等の調達では多種多様な作業や納品物があるため、漏れなく記載するのはなかなか難しいものです。
これらを定義する際は、作業内容、納品物を関連付けて定義していくことで、効果的に抜け漏れを確認していくことができます。

図 6-6
作業の実施内容と納品物一覧の確認イメージ

このように作業の実施内容と納品物を関連付けて一覧としてまとめておくと、工程完了時の納品物のチェックにも活用でき、検収時の確認負荷を減らすことができます。
また、中小・スタートアップ企業など、資金繰り面の課題を抱えやすい企業の入札参加が具体的に見込まれる場合、単一年度内に複数回の検収・支払いタイミングを設定することも可能です。RFI や発注者と事業者が対話を通じて相互理解を深めた上で、納品物と納品期日、検収・支払いタイミングを検討しましょう。

D. 外部事業者の具体的な作業内容を明確にする
作業内容の記載から、事業者が実際に何を実施する必要があるのか、わかりにくいケー

-

29 -

（第３編第６章 調達）

スがときどき見受けられます。
例えば、「支援」という言葉は人によって解釈が大きく異なります。「マニュアル作成支援」という作業項目があった際に、職員が元となる原案や素材を用意した上で事業者が体裁を整えるという役割分担も考えられますし、事業者がマニュアルの原案自体を作成して職員が内容を確認するという役割分担も考えられます。このような役割分担の違いによって、事業者が実施する作業範囲や必要工数は大きく変わってきます。
実際に実施する内容が事業者に正確に伝わらない場合、以下のような事態をまねくおそれがありますので、事業者に実施を求める内容は正確に記述してください。

作業内容が曖昧な場合に懸念される事態
必要な人員のスキルや数について、応札希望者等の想定と発注者側の希望や想定とがミスマッチとなる場合、契約した後に業務を完遂できない。
作業を終えることができた場合であっても、成果物の品質（機能性、信頼性、使用性、効率性、保守性、移植性）が著しく低下する。
契約した外部事業者からの問合せや協議等が増加し、発注者側に想定していた以上の作業が発生する。

E. 作業の実施体制を明確にする
調達案件を通じてプロジェクトの活動を円滑に進めていくためには、発注者側であるＰＪ
ＭＯや関係する職員が、体制や役割分担、責任範囲を明確にし、外部事業者と一緒に協働していくことがとても大切です。調達仕様書や要件定義書をしっかり記載して適切な外部事業者を選定することが仮にできたとしても、望んだ情報システムを必ずしも手に入れられるわけではありません。プロジェクトを進めていくと、要件の内容を設計として具体化・詳細化していく中で発注者側が決定しなければならないこと、他の関係者と調整しなければならないことは多く発生しますし、進捗上の課題や問題が発生した場合に発注者側の判断を要する場合もあります。

事例：発注者にも受注者にも遵守しなくてはならない義務がある
プロジェクトは発注者と受注者が協力して実施する必要があります。システム開発の失敗責任を巡って争いとなったケースの判例では、受注者の「プロジェクト管理義務」、発注者の「プロジェクト協力義務」について、それぞれ言及しています。
■ 受注者の「プロジェクト管理義務」についてある地方銀行（以下「銀行Ｇ」という）では、基幹システムの刷新プロジェクトを立ち上げ、大手開発ベンダ（以下「ベンダＸ」という）との間で開発作業の契約を行いました。しかし、プロジェクト開始直後から作業は難航し、数年後にプロジェクト中止という判断に至りました。
発注者側である銀行ＧはベンダＸに対して損害賠償を求め法廷で争うことになりました。裁判の結果、情報システムの専門家であるベンダＸが、提案したシステム方式に関する詳細な内容やリスクを銀行Ｇに十分に説明しなかった点について、プロジェ
クト管理義務違反等に当たるという判断が下され、ベンダＸ側に賠償金の支払が命じられました。
■ 発注者の「プロジェクト協力義務」について

-

30 -

事例 6-6
発注者にも受注者にも遵守しなくてはならない義務がある

（第３編第６章 調達）

また、ある大学病院（以下「病院Ｈ」という）では、病院情報管理システムの刷新を企画し、大手開発ベンダ（以下「ベンダＹ」という）との間で開発作業の契約を行いました。しかし、プロジェクトの開始直後から、発注者側である病院Ｈの現場担当者からの追加要件が相次ぎ、途中追加要件の取り込みについて病院Ｈ及びベンダＹの双方が合意した上で仕様を凍結し、納期も延長することになりました。
しかし、仕様凍結後も病院Ｈの現場担当者からの追加要望は収まらず、開発はさらに遅延し、最終的に病院ＨからベンダＹへ契約解除が通告され、プロジェクトは中止になりました。
ベンダＹは、発注者側である病院Ｈが仕様凍結の合意後において、要件の追加、変更を繰り返したことがプロジェクト中止の原因であるとして、損害賠償を求めましたが、逆に病院Ｈは受注者であるベンダＹが納期を守らなかったことを理由に裁判を起こしました。その結果、病院Ｈが発注者の責任として同院内の現場担当者からの追加要望を調整しなかったことが、プロジェクト協力義務違反に当たるという判決が下され、発注者側に賠償金の支払いが命じられました。
このように、受注者である外部事業者側だけではなく、発注者側にもプロジェクトを完遂させるために守らなくてはならない義務があることを、十分留意しておくことが重要です。

調達仕様書の「作業の実施体制・方法に関する事項」にて、発注者側、外部事業者側、関係者の体制、役割、責任をそれぞれ明確にします。

図 6-7
作業実施体制例

なお、サービス・業務の企画や要件定義のように新しいサービス・業務や情報システムの内容を決定するような活動においては、特に注意が必要です。意思決定の責任は発注者にあることを認識した上で、ＰＪＭＯ以外の関係者も含めて、適切な判断ができる体制を組成して調達仕様書に明示してください。

-

31 -

（第３編第６章 調達）

参考：作業実施体制に関する注意点
作業の実施体制には、受注者側が整備すべき体制、作業要員に求める資格等の要件について記載します。作業の実施体制を適切に定めなかった場合、遂行責任者として受注者内の業務全体を統括する役割は設置されているものの、発注者との一元的な窓口となる役割が設置されておらず、発注者と受注者の間のコミュニケー
ションが煩雑になるなど、適切な体制が採られないおそれがあるため、調達仕様書において役割も含め明確に定めることが必要です。
一方で、要件が過剰な場合もあります。資格要件等は本当に必要なものだけを定めることが重要です。近年は、作業要員にクラウドサービスの認定資格等を求める事
例が増えていますが、要件によっては適切な調達につながらない場合があるため、以下のような点に注意する必要があります。
・ 過度な資格要件
過度な資格要件を設定してしまうことで、資格は保有していないものの経験豊富な事業者が応札できなくなる可能性があります。例えば、資格よりも実績を重視している事業者は、経験や技術力が十分でも資格要件がハードルとなって応札を辞退する場合があります。また、小規模の事業者にとっては、品質マネジメントシステムの規格である ISO9001 の認証を受けることや、設計・開発チームから独立した品質管理者を設置することは負担が大きく、条件を満たせない場合があります。
そのような事業者の中には、クラウドサービス、アジャイル開発等の優れた実績を有している事業者もいることから、本当に技術力の高い事業者に応札してもらえるよう、資格要件は必要最小限のものとすることが望ましいです。高度な資格について
は、必要性を確認する、代替可能な資格や実績があれば特定の資格を保有していなくても応札可能とするなどの対応を検討しましょう。資格要件の緩和については「Step.2-2-C. 一者応札の状況を改善する」の「一者応札状況を改善するための施策例」も合わせて参照してください。
また、体制上のすべての要員に対して一律に資格の保有を求めたために見積りが高額になった事例があります。遂行責任者やチームリーダに適切な資格を求めていれば、作業担当者には必ずしも資格を求める必要はありません。必要な役割を定めるとともに、役割に応じて適切な資格要件を定めることが必要です。役割ごとに求める資格要件を定める例は、本ガイドブック別紙「調達仕様書テンプレート例」の「５(２)作業要員に求める資格等の要件」をご参照ください。
・ 実質的な製品・サービス指定
資格要件を定めることで特定の製品・サービスの指定になってしまう可能性があります。
例えば、調達時点では、どのクラウドサービスを採用するかは定まっていないにもかかわらず、特定のクラウドサービスの認定資格を要件とすることで、実質的に当該クラウドサービスを指定した調達となる懸念があります。
このような場合には、応札者にクラウドサービスを提案させるとともに、当該クラウドサービスを用いた設計・開発の実績や要員の保有資格などを提示させることを検討しましょう。
・ 名義貸し応札者から提示された体制図には優れた経歴の要員が示されているにもかかわらず、業務が始まると、当該要員がプロジェクトに関与せず、実働がないという場合があります。
このような名義貸しの状態にならないよう、発注者は、当該要員に求める役割を調達仕様書で明示するとともに、応札者から、当該要員の稼働率や具体的な関与方法を提案時に示させることが望ましいです。加えて、業務開始後に当該要員が実際に

-

32 -

参考 6-4
作業実施体制に関する注意点

（第３編第６章 調達）

果たしている役割、中間成果物や進捗状況等を確認し、それらが不十分であって、最終成果物の品質に影響が出るおそれがある場合は是正を求めましょう。
逆に、名義貸し状態でも成果物の品質に問題のないような資格要件である場合
は、そもそも調達時にこのような資格要件を求めるべきではありません。

F. 成果物の取り扱いに注意する（知的財産権）
調達案件にて設計・開発した文書やアプリケーションプログラムの知的財産権は、誰に帰属させるべきでしょうか？パッケージ製品を全く改変することなく採用した場合、製品の知的財産権は製品の提供元に帰属するのだろうと類推しやすいのですが、では、その製品を利用して蓄積されたデータはどちらに帰属するでしょうか？また、発注者側の要望に基づいた既成のパッケージ製品を拡張した機能やクラウドサービスの設定等は誰に帰属するのでしょうか？
標準ガイドラインでは、政府情報システムのソフトウェアに関わる知的財産権について
は、産業技術力強化法（平成 12 年４月 19 日法律第 44 号）の趣旨に鑑み、受注者に帰属させることが基本となります。しかし、設計・開発後に行われる情報システムの保守や継続的な機能追加等は、必ずしも設計・開発を行った外部事業者が行うとは限りません。成果物の知的財産権が誰に帰属するかなどを適切に定めておかないと、保守や機能改修、更改等のときに「人質」のようになってしまい、大きな問題に発展するおそれがあります。

事例：知的財産権の帰属先が問題となった例
情報システムを構成する要素は多岐に渡ります。想定していなかったものに対して「まさかこれに知的財産権が？」となり、トラブルになりかけた事例を次に示します。ここにあげた事例は、いずれも最終的には外部事業者との調整で問題を解決しましたが、本来は調達を行う時点でこのような点についても知的財産権の帰属について明
確にしておくことが望ましいといえます。
ある省庁の業務アプリケーションにおいて、アプリケーション本体の知的財産権
は発注者側に帰属していましたが、使用している外字のフォントデータは外部事
業者に帰属していました。このフォントデータがないと、登録した情報を画面や帳票に正しく出力することができません。次期システムの検討に当たり、既存情報システムの開発事業者が外字の知的財産権を主張し、ベンダーロックインになる事態を招きそうになりました。
ある省庁で保有している情報システムでは、データベースからデータを抽出するプログラムは外部事業者が独自に開発したもののため、使用するのであれば別途ライセンス料金が必要と言われてしまいました。

このような問題を防ぐためにも、案件の内容を踏まえて、調達案件中に発生する中間的な成果物も含め、全ての成果物に関して、知的財産についての権利の帰属、移転の可否、第三者への再利用、著作人格権の行使等の取決めを検討し、調達仕様書の「成果物の取扱いに関する事項」に記載します。

G. 再委託に関する事項を定める
情報システムの整備においては、プロジェクトの規模が大きくなるほど、様々な役割が必要となります。特に、設計・開発工程や運用・保守工程では、情報システムの一部を担う特

-

33 -

事例 6-7
知的財産権の帰属先が問題となった例

（第３編第６章 調達）定の技術や専門分野に特化した外部事業者を活用する機会が多く、これらの外部事業者
は、請負契約を締結している外部事業者からの再委託となることもあります。再委託先が担当する作業内容については、委託先の外部事業者（以下「委託先」という）が責任を持って管理することが原則ですが、再委託にまつわる失敗事例も少なくありません。
以下に一般的な例をいくつかご紹介します。

事例：再委託に関する失敗例
委託先が作成した提案内容を評価し、プロジェクトの委託先として選定したにもかかわらず、再委託先が提案内容を遂行するために必要なスキルレベルを十分に持っておらず、成果物の品質低下やスケジュール遅延を招いてしまった。
委託先と再委託先との関係性の悪化や再委託先内の社内事情から、再委託先が要員を引き上げてしまい、再委託先を改めて手配するまでの期間、作業が中断してしまった。
再委託先に所属するプロジェクトのキーマンが、病気や家庭の事情でプロジェク
トから離脱してしまった。委託先の要員が代替となったが、そのキーマンが属人的に持っていた情報やノウハウが委託先には引き継がれていなかったため、代役を担うことができなかった。
委託先が再委託先に利用者との検討や調整等の作業を丸投げしてしまい、要件や仕様の変更を把握しなかったため、工数超過やスケジュール遅延に発展してしまった。
委託先が利用者から得た情報を抱え込んでしまい、再委託先が作業するために必要な情報を提供せず、再委託先が利用者に再度同じ内容に関する説明を求めるという二度手間となり、利用者側との間の関係が悪化し、利用者側からの協力を得ることが難しくなってしまった。

このような問題を未然に防ぐためにも、調達仕様の「再委託に関する事項」にて、再委託の制限及び再委託を認める場合の条件、承認手続、再委託先の契約違反等を定め、再委託時の要員の配置や品質、情報管理等に関する責任の所在を明確にします。また、プロジェクト遂行中に発生した様々な事情により、請負側の体制変更をはかることがあります
が、その際は発注者側と協議の上、請負者の負担と責任において実施することが原則です。
なお、再委託に関する事項は、自府省の情報セキュリティポリシーにおける再委託先における情報セキュリティ対策に係る規定も必ず確認してください。

H. 納品後に不具合が発覚したときの責任を明確にする。(契約不適合責任)「瑕疵担保責任」と「契約不適合責任」の違い
2020 年 4 月に施行される改正民法においては、従来、納品されたシステムに不具合が発覚した際に適用されてきた瑕疵担保責任に関する条項がなくなり、代わりに「目的物が種類、品質又は数量に関して契約の内容に適合しないものであるとき」（契約不適合）についての条項が規定されました。これは、瑕疵担保責任の規定が現代の取引実情に合わな
くなっていたものを解消するための改正であり、様々な点で改正がされておりますが、特に

-

34 -

事例 6-8
再委託に関する失敗例

（第３編第６章 調達）

注意が必要な相違点としては以下が挙げられます（なお、請負契約の場合を前提にしています。）

契約不適合責任への変更による注意点
救済手段の多様化瑕疵担保責任においては、瑕疵の修補、損害賠償の請求及び契約の解除のみしか認められていなかったのに対し、契約不適合責任については、①修補、代替物の引渡し又は不足分の引渡しによる履行の追完の請求、②報酬の減額の請求、③損害賠償の請求及び④契約の解除が可能となり、それぞれについて、要件が整理されました。実際に不具合が発生した際にどの救済手段を取るべきかの判断を適切に行う必要があります。
権利行使の可能な期間の起算点の変更
瑕疵担保責任は、引渡しのとき又は仕事の終了時（通常は検収後）1 年間であり、その後に発見された瑕疵については、いかなる救済手段の権利行使もできませんでした。改正後は、種類又は品質についての不適合は、発注者がその不適合を知ったときから、1 年以内に受注者にそれを通知すれば、救済手段の権利行使をすることができ、数量の不足に関しては、そのような制限はなくなりました。もっとも、消滅時効の改正の影響で、通知した場合であっても、当該権利は、債権者が権利を行使することができることを知った時から 5 年間行使しないときには消滅することになります。

「契約不適合」を契約条項とするときの留意点
IT 開発において検収後に発見される不具合等に新しく創設された契約不適合に関する条項を適用する場合、ベンダ側は、最長で 10 年もの間 (民法 166 条に定める債権の消滅時効期間)、不具合の対応を無償で行うことを求められる余地があり、そのための体制も維持しなければなりません。
このことが大きな負担になることから、ベンダはこの条項の削除を求めたり、長期にわたる体制維持のために、高い見積もりを提示したりする可能性があります。また、こうした条項を嫌って、応札を見送るベンダもあるかもしれません。
こうしたことを避けるためにはベンダに対して、自らの求める仕様、言い換えれば、何を担保すれば契約の内容に不適合にはならないのかを具体的に説明し、合意を得ておく必要があります。
具体的に何を説明するのかについては、個別に異なりますが、主には、①契約の目的に資するもの(※1) が納品されていること、②提示した要件が全て満たされていること、③予定した作業や工程が全て完了していること、④予定していたレビューやテスト等の検証(※2) が全て完了し、設定した合格基準を満たしていることが、これまでの IT 紛争における判例から推測される”システム完成”の基準です。
こうした基準を第三者の客観的な視点でも認識がずれることないように提示(※3) することが、ベンダ側の過度な警戒を回避し、高い見積もりの提示や応札拒否を避けることに有効であると考えられます。

-

35 -

（第３編第６章 調達）※1 契約の目的が、そのまま検収の条件となるわけではありません。システム化によって、職員の作業工数を半減されることが目的とし、それが叶わなかったとしても、客観的に見て、コスト削減に資する機能や性能を具備したシステムが納品されれば、”目的に資する”ものであると考えられます。
※2 請負契約の場合、受入テスト以外の検証については受注者に一任されますが、契約に適合するモノを作っていることを証明するために、敢えてテストやレビューの計
画や実施状況、合格基準と結果等を提示してもらい、その妥当性を委託者側が評価することが有効と考えられます。
※3 第三者が同じ認識を持てるようにするには、各基準を数値化したり、Yes/No で答えられる形式に設定したりすることが有効です。

-

36 -

（第３編第６章 調達）

Step.

4 調達仕様書以外のドキュメント作成

調達を行うためには、調達仕様書以外にも、契約書をはじめ様々なドキュメントが必要となります。ここでは、特に重要となる契約書と総合評価落札方式による調達に必要となる提案依頼書について、説明していきます。

１ プロジェクトに合わせた契約書を作る【標準ガイドライン関連箇所：第３編第６章第３節 2)】

契約書は、会計担当部門等の契約を所管する部門が作るので、ＰＪＭＯはあまり関係がな
い。そう思っていませんか？
そんなことはありません。契約書に記載される内容によっては、プロジェクトの遂行に大きな影響を与えることもあります。契約書の作成に当たっての特に重要な確認・調整のポイントは次のとおりです。

A. 調達仕様書と契約書の整合性を確認する
調達仕様書の記載事項には、場合によって契約書に同様の事項を記載することがあります。これらの内容について調達仕様書と契約書でそごが生じている場合、後々問題となることもあるので、契約書を所管する部署と事前に意識合わせを行い、調達仕様書との記
述の住み分けを決めておくことが重要です。
調達仕様書の中で特に確認すべき事項を以下に示します。

契約書との整合性を特に確認すべき調達仕様書の内容
標準ガイドライン「第３編第６章３．1)キ 成果物の取扱いに関する事項」の知的財産権の帰属、契約不適合責任、検収等に関する内容
標準ガイドライン「第３編第６章３．1)ケ 再委託に関する事項」の再委託の制限
及び再委託を認める場合の条件、承認手続、再委託先の契約違反等に関する内容
標準ガイドライン「第３編第６章３．1)コ その他特記事項」の調達仕様書の変更
手順等に関する事項

２ 提案依頼書の内容を工夫する【標準ガイドライン関連箇所：第３編第６章第４節 1)】

総合評価落札方式で調達を行う場合は、提案依頼書の作成が必要となります。調達案件を確実に、かつ効果的に履行できる外部事業者を選定することは、簡単なことではありません。
しかし、提案依頼書の作成の際に、いくつかのポイントを押さえることで、効果的に適切な外部事業者を選定する審査を行うことができるようになります。特に重要なポイントは次のとお
りです。

-

37 -

（第３編第６章 調達）

A. 具体的な作業計画を評価する
提案書の内容だけでは、応札事業者が本当に調達案件を履行する能力があるかどうかを判断するのは難しいものです。特に大規模な情報システムや関係者が多数いるような情報システムの構築は、プロジェクトの計画能力や管理能力がとても重要になりますが、提案された体制や要員スキル、過去の実績からだけでは、評価が難しいのが現実です。
外部事業者の技術力を適正に評価するためには、具体的な作業計画の案の提出を求めて評価することが効果的です。

事例：事業者の設計・開発実施計画書の作成能力に問題があった例
ある府省の情報システムでは、基本設計で想定した内容の実現性を確認・検証する調査業務を総合評価落札方式で調達しました。提案依頼書では、ＷＢＳの案の提示を求めるとともに、本件調査業務のプロジェクトの実行可能性に関する説明も求めました。
この調達はＥ社の一者応札となり、提案に係る技術審査において、提案されたＷ
ＢＳを審査したところ、明らかな矛盾点や作業の前提の見込み違い等が判明したので、同社に繰り返し確認したものの十分な説明はなされませんでした。しかし、その調達における技術審査委員会での議論の結果、実行可能性を引き続き確認することを条件として、同社への委託を決定しました。
プロジェクト開始後、当初予定を大幅に超過しただけでなく、プロジェクトの経緯確
認及びプロジェクト実行計画書・ＷＢＳ等の作成もできなかったので、実作業の開始に至らず、Ｅ社との契約を解除することになりました。

ＷＢＳ等のプロジェクトで行うべき作業の一覧、それらの順序やスケジュールなどを計画した文書の提出を求めることは、当該プロジェクトの背景や内容に関する応札者の理解度、プロジェクト計画を含む管理能力及び履行能力を示す指標となります。
ＷＢＳの精度については、総合評価落札方式の技術点としても審査することも可能です
し、最低価格落札方式においても入札参加資格の要件の一部としてＷＢＳの案の提示を求めることにより、事前に審査を行うことが可能です。
ＷＢＳの計画の妥当性を判断できる例を次に示します。

ＷＢＳを精査する
ＷＢＳには大きくプロセスベースと成果物ベースの２種類がありますが、基本的には成果物ベースで作成することを推奨します。仮にある情報システムが４つの独立したサブシステ
ムで構成されていたとすると、最後の総合テストはこの４つのサブシステムを統合した状態でテストを行いますが、その手前では４つのサブシステムは各々準備が整い次第、サブシ
ステム内の総合テストを実施します。準備が整い次第とは、その配下の全ての機能における結合テストが完了したことを指します。さらに、結合テストはその配下の全てのモジュールの単体テストが完了次第、逐次結合テストを実施します。そのように考えると、単体テスト、結合テスト、総合テストそれぞれが１つずつのＷＢＳというのではなく、上流テスト工程に向けて徐々に行（タスク）が集約されてゆくようなピラミッドイメージのＷＢＳとなるはずです。
「図 6-7 テスト工程の名称を羅列しただけのＷＢＳ」はネットに転がっているようなテンプレ
ート的なＷＢＳで、こんなものは調達仕様書の中身をよく検討しなくても機械的に割り当てるだけで作れてしまい、ＷＢＳとして「手抜き」以外の何物でもありません。

-

38 -

事例 6-9
事業者の設計・開発実施計画書の作成能力に問題があった例

（第３編第６章 調達）

図 6-8
テスト工程の名称を羅列しただけのＷＢＳ

通常、５～20 程度のサブシステムが存在するようなシステム規模であれば、サブシステ
ム数の 10 倍程度の機能数の結合テストは必要となります。確かに全くモジュール分割されずに１サブシステム１機能１モジュールなら、単体テスト→結合テスト→総合テストが順に隙
間なく並びますが、多くの場合、結合テストは五月雨に始まって順次終了することになります。開発要員が少人数の場合は、プログラマーが希少資源となるので、単体テストは同時
並行ではなくプログラマーの数以上に並列化できません。逆に大規模開発の場合であっても設計者が各サブシステムに固定化されて案件ごとに柔軟に要員を増加できないこともあるので、やはり全てのモジュール、機能が同時に単体・結合テストを開始・終了することはありえないのです。

図 6-9
成果物（＝機能）単位に分解されたＷＢＳ

普通にＷＢＳに分解すると「図 6-8 成果物（＝機能）単位に分解されたＷＢＳ」のようになります。左上１列目がサブシステム、２列目が機能、３列目がモジュール単位です。まずコーディング・単体テストを一緒に実行し（水色のボックス）、機能の下位のモジュールについ

-

39 -

（第３編第６章 調達）て全て完了した後で結合テストを実行し（黄緑色のボックス）、サブシステムの下位の機能について全て完了した後でシステムテスト（オレンジのボックス）を実行します。さらに担当
者によっては１機能が終わった後で次の機能に着手する場合もあり、これらの順次処理を→で表記しています。「テンプレート的な標準ＷＢＳ」である図 6-7 と比べると検討の深さが違い、プロジェクトの実現性が十分担保されています。

ＷＢＳの妥当性が疑われる例
テスト工程を羅列しただけになっている。
単体テスト、結合テスト、総合テストそれぞれが１つずつで、それぞれの関係性がわからない。
開発要員が少人数の場合に、単体テストがプログラマーの数以上に並列化されている。

ＷＢＳの妥当性があると判断できる例
成果物（＝機能）単位に分解されている。
20～200 ぐらいの機能（あるいはこれ以上の数ならサブシステムに分割する。）に切り分けられている。
サブシステムが複数ある場合、結合テストはサブシステム数の 10 倍程度の機能数分ある。
単体テスト、結合テスト、総合テストの関係性がわかる。
多くの場合、結合テストは五月雨に始まって順次終了する計画になる。特に大規模開発の場合、設計者が各サブシステムに固定化されることが多いので、全てのモジュール、機能が同時に単体・結合テストを開始・終了することはありえない。

ただし、これらの評価には専門的な能力が必要となりますので、適正な評価ができる審査体制を組成することを忘れないでください。

B. 加点の配分を工夫する
総合評価落札方式では、公正性・透明性を確保するために、評価基準となる評価事項
ごとの配点を事前に決める必要があります。しかし、やみくもに（例えば均等に）配点すればよいわけではありません。

参考：総合評価落札方式の加点配分について「情報システムの調達に係る総合評価落札方式の標準ガイドライン（平成 25 年７月 19 日調達関係省庁申合せ）」では、以下の(1)から(5)全ての要件を満たす調達については、総合評価落札方式を適用できると示してします。
(1) システム化対象の業務の実施方法や内容が複雑かつ多岐にわたるもの(2) 技術的構造の異なる複数の情報システムと連携するもの(3) 制度・業務の見直し等に伴う頻繁な機能改修を伴うもの

-

40 -

参考 6-4
総合評価落札方式の加点配分について（第３編第６章 調達）(4) 大規模なプロジェクトで多人数の要員への高度な統制力が必要なもの(5) 連携、統合等を行う情報システムや関係組織が多く存在するもの
入札価格に対する得点配分の割合は、全体の四分の一以上（技術点：価格点が３：１以上）としますが、各評価項目に対する得点配分は、その必要度・重要度に応じて定めるものとされています。
ある省庁では、情報システム開発は３：１、プロジェクト管理支援等の役務は２：１、ハードウェアやパッケージ製品等の物品購入は１：１といった、調達する内容によって比率を変えて実施しています。

技術審査を行う際は、当該調達で何を重視するかをよく検討し、重視する項目に対する優れた提案に高い配点がされるように検討する必要があります。配点に関する工夫を次に示します。

配点に関する工夫
基礎点の合計と加点の合計の割合は、基礎点の合計の割合を最低限にして、加点の割合を高くする（基礎点の割合が高い場合、実質の価格競争となる
ため）。
評価事項ごとに均等に配点するのではなく、プロジェクトで重視する評価事項に加点が多くなるように配点する。
一つの評価項目に対しても、評価が高ければ加点が大きくなるよう、加点に傾斜をつける。
なお、審査で重視する項目を設定する場合は、プロジェクトの目的に応じて発注者として期待する内容が応札者に適切に理解された上でそれが応札者の提案に反映されるよう、調達仕様書及び要件定義書とも整合を図ることが大切です。
情報システムの調達では、ライフサイクルコストを評価することが重要です。ライフサイク
ルコストを評価するためには、整備経費だけでなく、運用等経費も考慮する必要があります。調達の対象となる工程ごとに、評価方法を次に示します。
調達の対象が設計・開発工程のみの場合
価格点では整備経費のみを評価せざるを得ませんが、以下の方法により、運用等経費を評価します。
事業者が効率的に運用・保守作業を進める工夫を技術点として加点する
項目を設定することで、経費を定性的に評価する。
運用・保守作業の実施内容と、ライフサイクル全体で見るとどの程度コストを低く抑えられるかを示す想定コストを技術点として加点する項目を設定することで、経費を定量的に評価する。
調達の対象に設計・開発工程だけでなく、運用・保守工程も含まれる場合
整備経費と運用等経費の両方を価格点で評価できます。 ただし、調達の対象となる期間がライフサイクル全体をカバーしていない場合は、前述の設計・開発工程のみの場合と同様に、運用等経費を評価します。

-

41 -

（第３編第６章 調達）

Step.

5 調達手続とプロジェクト管理

調達仕様書等の調達に必要なドキュメント類が完成しました。あとは、実際に調達の手続を進めていくことになりますが、焦らずにここで一呼吸置きます。調達の手続を開始する前にプ
ロジェクト管理の視点で再度確認することで、実際の調達案件の履行の際の管理がより効果的に行えるようになります。
では、調達の手続の前に確認すべきポイントを見ていきます。

１ 調達手続に伴うプロジェクト管理作業とは【標準ガイドライン関連箇所：第３編第６章全般】

政府情報システムの整備に係る調達の手続では、調達に直接係る作業以外に、プロジェク
トを適正かつ効果的に管理・遂行するためにやるべき作業があります。これの作業内容とタイ
ミングを事前に理解した上で調達の手続を進めることで、無駄な作業を減らし、調達案件を円滑に履行することができるようになります。

A. 第一次工程レビューを意識して資料をチェックする
第一次工程レビューは、調達仕様書が完成するタイミングで実施します。
工程レビューの対象は、ＰＭＯが指定したプロジェクトではありますが、通常のプロジェク
トでも同じタイミングで調達仕様書の自己点検を行っておくことで、調達が不落に終わることによる調達事務手続きの手戻り等の無駄を未然に防ぐことになり、効果的です。
特に次の点について留意して、自己点検（工程レビュー対象のプロジェクトの場合は、正式な第一次工程レビュー前）を実施することをお勧めします。

確認の留意事項
各ドキュメントと整合性が取れているか？
Step.3 で示したとおり、調達仕様書は様々なドキュメントと関係性を持ちます。
関連するドキュメントと、プロジェクト及び調達の目的の達成に必要な項目が抜け落ちていたり、矛盾して定義されていたりしないかをチェックすべきです。また、要件定義書とは内容面のチェックを行い、調達仕様書で定義した実施作
業や成果物の内容が、要件定義時の想定と合っているかをチェックすべきです。
他の調達と整合が取れているか？
１つのプロジェクトでは、複数の調達が実施されることがあり、大規模なプロジ
ェクトほど数多くの調達を行う傾向があり、各調達間の認識に不整合が存在す
ると、目標・目的が達成できないおそれもあります。そのため、各調達間（異なる調達や時間経過を経た過去の調達）で、特に当該調達と依存関係があるものについて、その内容の整合性、作業や要件の抜け漏れがないかをチェックすべきです。

-

42 -（第３編第６章 調達）２ 情報システムの調達に特有の注意点【標準ガイドライン関連箇所：第３編第６章全般】

情報システムの整備に係る調達には、情報システムならではの注意点があります。これらを事前に理解せずに調達を進めてしまうと、後々問題となることがあります。これらの事態を未然に防ぐため、事前に情報システムの調達特有の観点を理解し、調達仕様書や契約書等に制約等を適正に盛り込み、ポイントを抑えて調達案件を管理していきましょう。

A. ベンダーロックインを理解し、回避する
Step.3 の「成果物の取り扱いに注意する」で示したように、情報システムの設計・開発を進めてから、その設計情報等が受注者側の人質のようになり、次の作業や調達を行う際に、制約条件となる可能性があります。
その発生原因として、次の３点の要素が考えられます。

ベンダーロックインの発生原因
設計情報が専門的であり、かつ大量に存在するため、作成者以外の第３者が把握して理解するのが難しい。
発注者側が調達仕様書や設計書等のドキュメント類を適切に管理していない
場合には、作成者以外の第３者が正確に仕様を把握することが難しい。
情報システムは作りっぱなしではない。運用に入った後も、社会情勢等の環境変化に伴う様々な要因によって要件変更が発生し、情報システムの機能改修・拡張が発生しやすい。このとき、情報システムの開発当初にある特定ベン
ダのみが権利を有して、排他的な独自技術や開発フレームワーク等が採用されている場合には、その特定ベンダ以外が改修を行うことは難しい。
情報システムに何らかの改修等を行う際、これらが原因となって、設計・開発を実施した
外部事業者以外の応札希望者が情報システムの設計情報等を理解することが難しくなる
ため、必ずその外部事業者を頼る必要が出てきます。
ここで問題となるのは、過度に外部事業者に任せてしまった結果、どの外部事業者でもできるはずの作業が特定の外部事業者にしかできなくなってしまい、追加作業に対して過度な費用を請求される事態に陥ることです。（※Step.3 の「成果物の取り扱いに注意する」
がその１例です。）
そのような事態を未然に防ぐためには、これら特性を踏まえた上で次に挙げる留意事項
に従って対策する必要があります。
なお、過度に制約を入れ過ぎると、応札希望者を減らすことになりますので、作成した調達仕様書に記述した各種条件は、ＲＦＩ等を通じて、外部事業者と透明かつ公正な事前ヒアリングをしておく必要があります。

ベンダーロックインを未然に防ぐための留意事項
情報システムを構成する要素を理解しましょう。
情報システムは、ＡＩや機械学習を応用するような先進的な例を除いて、基本的には人間が定義した命令や処理どおりにしか動作しません。つまり、情報シ
ステムを利用して業務を行う発注者側の各関係者が、それぞれの立場で正し
く業務要件を定めることに始まり、発注者側の各関係者と契約した外部事業者

-

43 -

（第３編第６章 調達）と協働して各要件を詰めていくことが重要です。また、実際に動くプログラム（実行モジュール）とそれを生み出すソースコードだけでは動きません。これら
以外にも例えば以下のようなものが必要となります。
マスタデータ、移行データ、情報システムにより登録されたデータ
パラメータファイル、パッケージやクラウドサービスに設定する設定値
ログファイル、統計情報等の実行情報
コード規約、データ標準、マニュアル等のドキュメント
様々な要素から出来上がっていますが、特にデータについては帰属先が曖昧になりがちですので、注意が必要です。
調達仕様書に成果物の定義と権利関係を明確に記載しましょう。
成果物の定義を明確にした上で、設計・開発で作成される成果物が制限なく納品されるかを確認してください。最低限必要な成果物は、「調達仕様書テンプレート」に成果物一覧として記載してありますので、それぞれが納品されるか確認してください。
また、成果物の権利関係次第では、開示されない設計情報が発生する可能性があります。そういった場合、その後の運用保守改修を進める上で問題とならないかを PMO 等に確認してください。
発注者側で最新のドキュメント類を確実に管理しましょう。
情報システムの整備に係る調達を実施する際に、設計書等から現状の情報シ
ステムがどのようになっているかを確認できるようにしておくことが重要です。運
用・保守に入った後も、調達仕様書や設計・開発で最終確定した設計書等のドキュメント類は適切に管理しましょう。
ドキュメント類は保存しておくだけではなく、適切に管理することが重要です。
ここで言うドキュメントの保存とは、ドキュメントをそのままの状態でフォルダに格納し、記載内容を維持することを言います。一方でドキュメントの管理とは、ドキュメントをそのまま保存するだけではなく、最新の状態に保つことを言います。
情報システムの仕様に変更が入った場合は、ドキュメントの記載内容や変更内
容に矛盾がないことや、必要な情報が抜け漏れなく正確に記載されていることを確認しましょう。加えて、変更管理を確実に実施することが重要です。変更
管理の詳細は、実践ガイドブック「第９章 Step.4-2. 変更を管理し改善活動等の初動を楽にする」を参照してください。
また、ドキュメント類は、わかりやすいフォルダ構成で整理しておくことが重要です。人事異動による職員の交代があった際に、過去のドキュメントがどこにあるのか分からなくなりがちです。ドキュメント種別や年度別等に整理して保存しておくことで、欲しい情報を見つけやすくなり、このような問題が起きにくくなりま
す。

-

44 -

（第３編第６章 調達）

参考：クラウドサービス利用時のベンダーロックインに対する注意点

参考 6-5
クラウドサービス利用時のベンダ
ーロックインに対する注意点

クラウドサービスを利用する場合においても、ベンダーロックインへの注意が必要です。以下では、クラウドサービスを利用する際にベンダーロックイン対策の観点から注意すべき点を例示します。
・閉鎖的なクラウドサービス
クラウドサービス提供者の中には、自社の関連事業者しか利用できないクラウド環境を提供している場合があり、それ以外の第三者が運用・保守事業者として受注した場合に、そのクラウド環境の利用に制約が発生する可能性があります。そのため、クラウドサービスはクラウドサービス提供者及びその関連事業者以外の第三者も利用できるよう要件を定めましょう。
・SaaS におけるアプリケーションやデータの知的財産権
SaaS で提供されるアプリケーションは、あらかじめクラウドサービス提供者が構築したものなので、アプリケーションの知的財産権はクラウドサービス提供者に帰属します。このため、将来的に別のクラウドサービス等へ移行する際に、設計情報やソース
コードを流用することはできず、類似のサービスがない場合には移行にかかる費用が高額となる可能性があります。
また、アプリケーションだけでなく、データレイアウト等は、クラウドサービスの一部として扱われ、クラウドサービス提供者に帰属します。発注者が必要なデータを標準的な形式で出力できるなど、このことが別のクラウドサービス等へ移行する際に障害とならないサービスを選定することが必要です。
・IaaS におけるデータの帰属先
IaaS では、アプリケーションやデータレイアウトは調達対象の業務で新たに構築することとなるため、多くの場合、データは発注者に帰属するとしています。しかし、クラウドサービスにアップロードしたデータをクラウドサービス提供者に帰属させる場合もありうるため、データの帰属先は発注者であることを明確にし、移行に支障がないようにする必要があります。
このような方法によって権利上、データが発注者に帰属したとしても、情報システ
ムからデータを抽出する機能がなかったり、特定の製品でしか読み込めない形式でしか抽出できなかったりすると、別システムへ移行することができません。したがって、これらのデータは標準的な形式で取り出すことができるように、あらかじめ要件として定めておくことが必要です。

参考：ベンダーロックインによる問題を回避するための工夫
ベンダーロックインに陥ると適正な競争が阻害され、調達コストの増加、事業者のサービス品質の低下などの問題が発生する懸念があります。発注者としてこれらの問題を回避するためにどのような工夫ができるでしょうか。
・優れた提案を受けられる環境の整備
ある情報システムは、複数のモジュールに分割して構築すべきところまでモノリシッ
クな構成で構築してしまったため、保守性が低く、既存事業者以外が参入しにくい状
況になっていました。
また、運用・保守に対する既存事業者のサービス品質についても、問合せや依頼事項への対応が遅いなど不満を感じる部分が多く、再三にわたって改善を要望した

-

45 -

参考 6-6
ベンダーロックインによる問題を回避するための工夫

（第３編第６章 調達）

ものの十分に対応されませんでした。
そこで、当該システムの更改に伴い、既存事業者だけでなく新規事業者からも優れた提案を受けられるように、以下のような取組みを実施しました。
【要件の明確化】
発注者側組織の責任者自身が、次期システムの目指す姿、構想、実現方針を明確な文書としてまとめて、関係者へ共有した。
システム利用者に対して既存システムについてのアンケート調査を実施し、現場の声に即して新システムに求める機能要件を整理した。
既存事業者がこれまで対応できなかった改修要望を洗い出し、提案時に加点項目として評価できるように明示した。
【情報提供による競争性の確保】
機密保持契約を結んだ上で、既存システムの設計書等を応札予定の事業者が閲覧できるようにした。
新規事業者でも既存システムについて詳細に把握できるように、既存システ
ムの疑似環境が使える端末も準備し、応札予定の事業者へ貸し出した。
これらの取組みの結果、既存事業者と新規事業者間で競争が働き、発注者の要望への充足度が高い提案を行った新規事業者が落札しました。
なお、これらの取組みを行えた背景としては、発注者側の管理者が、「当該情報シ
ステムの動きを熟知した利用者である職員の意見を仕様策定の中心とする」ことを方針として打ち出し、新規事業者が落札した場合に生ずるであろう発注側作業負担の増大への覚悟を決め、さらに、それに対して情報システム部門の協力が得られた、という要素もありました。
また、別のある情報システムは、既存事業者によるベンダーロックインが発生しており、一社応札が継続していました。そこで、当該情報システムをオンプレミスからクラウドサービスへ移行するタイミングで、この状況の改善を図ることにしました。
発注者は、当該移行業務の調達に先立ち、クラウドサービスへの移行可能性調査を発注しました。これにより、新規事業者が当該情報システムの仕様等を十分に理解でき、クラウドサービスへの移行業務の調達では、既存事業者だけでなく新規事業者も応札しました。その結果、双方の事業者から技術面、価格面で質の高い提案がなされ、既存事業者が落札しました。
上記 2 つの事例では、いずれも発注者が競争性を確保するための工夫を行いました。後者の事例では、既存事業者が落札したことから、一見するとベンダーロックインが発生している状況と変わらないように見えますが、決してそうではありません。事
業者が変わったかという表面的なことではなく、発注者が調達における競争性を適切に確保したことで、より優れた提案を事業者から受けられた点が重要です。
・随意契約時における交渉ある情報システムでは、当初一般競争入札による事業者の調達を予定していたものの、ベンダーロックインが発生しており競争性の確保が難しく、一者応札となる見込みでした。そこで、契約方式を随意契約に変更した上で、発注者が事業者の作業計画等を精査することで発注者と事業者の認識そごの解消を図りました。例えば、不要と思われる会議や報告を削減することでプロジェクト管理工数を削減する、重複感のあるテストを絞り込むなどの対策を実施しました。その結果、当該仕様に基づいた精緻な見積りの作成が可能となり、見積額は当初取得したものと比較して大幅に減額されました。
調達時には、発注者と事業者で仕様書の記載内容に対する解釈にそごが生じ、本来は不要な作業工数が余分に見積もられるなどの理由で、見積額が高額になる場合がありますが、本事例のように随意契約をうまく利用することで、発注者と事業者が協力して仕様を詳細化でき、正確な見積りが可能となります。そのため、随意契約

-

46 -

（第３編第６章 調達）の方が一般競争入札より見積額が低くなることもあり得ます。
公共調達では、競争性及び透明性を確保する観点から、安易に随意契約を行う
べきではありません。しかし、本来は妥当な価格で高い品質のサービスが提供されることが重要であり、これらの事例のように、それが随意契約によるものの場合もあります。随意契約とする理由・根拠が十分にあり、かつ、発注者が事業者と作業内容や実現方法について適切に交渉を行える場合には、調達コスト削減のために随意契約の採用を検討する余地もあります。随意契約の採用に当たっては「Step.2-1-E. 契
約方式を検討する」も参照してください。

B. 入札参加要件を緩和する
情報システムの整備に高い技術やサービスを取り込むためには、多様な事業者の参入を促すことが重要です。例えば、資格や実績要件について高いものを求めてしまうと、参入できる事業者が限定的になってしまうため、求める等級を緩和し、下位の等級に格付けされた事業者からも優れた提案を受けられるようにすることが望ましいです。

事例：総合評価方式の入札参加資格で規模要件を撤廃

事例 6-11
総合評価方式の入札参加資格で規模要件を撤廃

ある府省では、入札の参加要件として求める等級を定めているものの、提案の優劣等を示す指標ではないことから、総合評価方式にて実施する事業すべてについて、原則、等級区分 D の事業者から入札参加を認めています。

C. 入札事務手続きを簡素化する
事業者が応札を検討する際には、入札事務手続きの負担を軽減することがとても重要です。入札事務手続きの煩雑さから入札を見送っている事業者もいることから、多様な事業者の参入を促すためにもデジタル化を通じた入札事務手続きを簡素化することを推奨しています。

参考：デジタル化による入札事務手続きの簡素化
事業者が応札する際に、従来は提案書等の様々なドキュメントを紙で提出することを求めていましたが、近年は電子調達システムの利用を原則としたデジタル化が進んでいます。提案書作成や見積作成等の書面の押印廃止や電子データでの提出を認めている府省庁もありますが、各省庁がもつデータの活用により事業者に求める提出書類を削減することができます。
・入札参加資格申請時の公的書類の削減
入札参加資格申請時において、事業者に提出を求めている登記事項証明書の内容や納税証明書による未納の税額の有無等には、管理する府省への問い合わせや情報提供で確認できるものがあります。必要な情報を持っている府省が明らかな場合には、府省間での情報連携を検討し、電子証明書による本人確認を前提に入札参加資格申請時の提出書類を削減していくことが大切です。
・入札説明会のオンライン化
対面での情報提供は事業者の負担になることから、入札説明会をオンラインで実施しているケースがあります。システム調達においては、オンライン環境が整備されている事業者が多いことから、対面でないと説明責任を十分に果たすことができなくなるおそれがある等の事情がなければ、オンラインでの実施が望ましいです。なお、

-

47 -

参考 6-7
デジタル化による入札事務手続
きの簡素化

（第３編第６章 調達）

資料閲覧にあたっては、秘密保持契約（NDA）を締結する等、機密性の確保に留意すること。
・応札ドキュメント（提案書・機能証明書等）の電子データでの提出や提出書類の削減
応札時の様々なドキュメントの押印を廃止し、電子データでの提出とすることで、事業者の負担となっている紙資料の準備や押印に必要な社内手続き等の時間や手間を削減することができます。また、gBizINFO をはじめとした既存の法人情報データ
ベースで確認できる公的な資格等の情報については、ID 情報を提供してもらうこととし、事業者に求める応札ドキュメントを削減することを心がけてください。

-

48 -

（第３編第６章 調達）

Step.

6 検収

検収は、調達仕様書で定められた納品物が正しく収められているかを確認し、成果物を外部事業者から受け取るという調達の最終盤の作業ですが、ただの儀式ではありません。ここでは検収の際に気をつけておくべきポイントをご紹介します。

１ 検収の位置づけと内容を理解する【標準ガイドライン関連箇所：第３編第６章第８節】

プロジェクトには、その成果物の妥当性や整合性を確認する作業が何種類もありますが、それぞれの作業で確認する観点が異なります。それぞれの確認作業が持つ意味を正しく理解して実施しなければ、成果物の不備や不測を適切なタイミングで発見することができず、トラブルの原因になります。ここでは、検収での確認に関連するポイントを見ていきます。

A. 検収と受入れテストの違いを理解する
検収とは、調達手続の一つとして、調達受注者が納めた成果物が調達時に示した仕様（契約）どおりに納められたかを確認する行為です。
重要なのは、調達開始時の約束事を、受注者が果たしたかどうかという点です。検収の実施者は、発注者側の検収担当者である検査職員です。検査職員は、調達仕様書及び契約書に定められた内容と納品物との突合せを行い、仕様どおりに納品されているのかを確認します。そこには、テストに関するドキュメントも含まれますが、内容が充分かどうかは判断が付きません。
一方、受入れとは、ＰＪＭＯを中心として、納品された成果物が今後のサービス・業務の実現に足るかどうかを判断する行為です。この行為は、テストとしての一連の作業からなり、終端は職員が実施する受入れテストとなります。逆に言うと、受入れテストのみでは、その情報システムが受入れ可能かは判断が付きません。
また、プロジェクト開始時は、調達仕様書の内容に沿って作業が進められますが、様々な調整や追加変更を経て、情報システムは完成します。その際の経緯や、結果としてどうなったかは、契約変更を伴うものは検収でも発見できますが、通常のプロジェクト管理の変
更管理の範囲での内容は、検査職員には認識されていません。
つまり、検収と受入れは異なるものです。検収は手続上の行為として必要であることは前提としつつ、実質の受入れに対して職員が充分に関与しないと、納品されたが機能しないだけでなくプロジェクトの目的の達成に寄与しない情報システムが出来上がることになりかねないのです。プロジェクトの目的の達成に寄与しない情報システムが出来上がった場合には、最悪、その情報システムを利用する職員が行う業務そのものに悪影響を与え、手戻りが発生するなどして手作業での修正を関係者に強いるおそれがあります。

B. 残存する課題（軽微な瑕疵等）の対応を明確にする
スケジュールや優先順位等の関係から、検収の時点で優先度の低い軽微な不具合が残ってしまうことも少なくありません。多くの場合、瑕疵と認められる不具合は契約に基づいて外部事業者が修正することになりますが、契約期間の終了とともに外部事業者側の体制

-

49 -

（第３編第６章 調達）は縮小（又は解消）することが一般的であるため、不具合の改修時期が不明確になることもあります。
このため、検収時点で瑕疵である不具合がわかっている場合は、その不具合に対する改修計画を明確に提出するように求めましょう。各々の不具合に対して、「いつまでに」「誰が」責任を持って「どのように」対応するかを改修計画で明確にさせ、その改修計画が発注者側として受け入れることができるものかどうかを契約期間の終了前に確認し、合意形成を
あらかじめ図ることが大切です。

-

50 -

デジタル・ガバメント推進標準ガイドライン

デジタル・ガバメント推進標準ガイドライン
実践ガイドブック（第３編第７章-

設計・開発）1 -（第３編第７章 設計・開発）

目次
Step.1 設計・開発の全体の流れ ................................. 6
Step.2 設計・開発を開始するための事前準備 ................ 7１ 設計・開発で職員が行うべき事を理解する ..................................... 7
A. 『要件の内容を伝える役割』 ............................................. 7
B. 『要件どおりに情報システムができたかを確認する役割』 ...... 10
C. 『プロジェクトの進捗状況を正しく把握し適切な調整を行う役
割』.............................................................................. 10
２ 設計・開発全体を通して理解すべき点とは ................................... 10
A. 要件を理解した職員の継続的な関与がプロジェクトを安定させる................................................................................... 10
B. 要求とコストと納期のバランスをとる ............................... 11
C. 設計・開発の全体像と流れを理解する ............................... 11
D. 通常シナリオだけでなく、緊急時の対応計画も準備する ......... 16
E. メンテナンス性を考慮した成果物の構成、内容を考える ......... 17

Step.3 設計・開発の計画 ....................................... 19
１ 設計・開発の管理の要点を理解する ............................................ 19
A. 定点観測こそ進捗・品質管理の要（かなめ） ....................... 19
B. 判断に必要な情報を職員が理解できる説明として事業者に求める................................................................................... 20
２ 設計・開発の実施計画を立てる ................................................. 21
A. 2 種類のプロジェクト計画書の相違点を理解する .................. 21
B. 意思決定の手順を明確にする ........................................... 22
C. 当初計画からの変更は、必ず関係者で合意する .................... 22
D. 他の関係者との役割分担の境界線を定める.......................... 23
E. ＷＢＳで作業計画を確認し進捗を把握する .......................... 23
F. ＥＶＭを用いた進捗管理手法を理解する ............................. 24-

2 -（第３編第７章 設計・開発）

３ テストの計画を立てる ............................................................. 30
A. Ｖ字モデルと発注者・委託先事業者の役割分担を把握する ...... 30
B. テストのレベルや種類を理解する ..................................... 31
C. リスクを踏まえてテストの方針を決める............................. 32
D. テストにおける役割分担と必要な環境を明確にする .............. 33
E. テストツールを有効活用する ........................................... 33
F. テスト計画を作成する .................................................... 34

Step.4 設計・開発・テストの管理 ............................ 36
１ 設計内容を確認・調整する ....................................................... 36
A. 基本設計の内容を確実にレビューする ............................... 36
B. 他の情報システムとのデータ連携には細心の注意を払う ......... 38
２ 品質管理の考え方を理解する .................................................... 39
A. 見えない品質を見える状態にする ..................................... 39
３ 単体テスト・結合テストの品質を評価する ................................... 41
A. 単体テストの留意点 ...................................................... 41
B. 結合テストの留意点 ...................................................... 42
４ 総合テストの品質を評価する .................................................... 45
A. 総合テストの留意点 ...................................................... 45
B. 発見できた障害は最大限活用する ..................................... 47
５ 受入テストを実施する ............................................................. 48
A. 受入テストと他のテストとの違いを理解する ....................... 48
B. 受入テストのテスト計画書を作成する ............................... 50

Step.5 見落としがちな活動に注意 ............................ 51
１ どのプロジェクトでも必ず移行を計画する ................................... 51
A. 移行の種類を理解する ................................................... 51
B. リハーサルも考慮した移行計画書を立てる .......................... 52
２ 次の運用・保守は開発と並行して検討する ................................... 53
A. 指標値を運用作業で取得できるように検討する .................... 53
B. 運用・保守の計画を立てる.............................................. 55-

3 -（第３編第７章 設計・開発）

３ 種類を理解し揃えるマニュアルを厳選する ................................... 56
A. マニュアルの種類を理解する ........................................... 56

Step.6 新業務の運営を円滑に行うための準備 .............. 59
１ 本番移行と本番稼働の開始を承認する ......................................... 59
A. 移行判定と稼働判定の違いを理解する ............................... 59
２ 正しく引継ぎを行い、トラブルを減らす ...................................... 61-

4 -（第３編第７章 設計・開発）

事例・参考の一覧
事例：基本設計段階でのコミュニケーション失敗 ......................................8
参考：使い勝手の良いシステムを構築するための工夫 .................................8
事例：ウォーターフォールとアジャイル開発を組み合わせた開発計画 ........... 16
様式例：設計・開発実施計画書、設計・開発実施要領のひな形 ................... 21
コラム：忘れがちな突合作業 .............................................................. 37
事例：テストの目的と業務シナリオを明確にする .................................... 49
様式例：受入テスト計画書のひな形 ..................................................... 50
事例：運用作業での指標値の取得に工数がかかってしまう ......................... 54
様式例：運用計画書、運用実施要領、保守計画書、保守実施要領のひな形 ..... 55
参考：設定と設計は異なる................................................................. 56
事例：異なる事業者間で引継ぎをスムーズに行う工夫 ............................... 61-

5 -（第３編第７章 設計・開発）

Step.

1 設計・開発の全体の流れ

設計・開発は、専門的で内容がよくわからないものだから、専門の事業者に任せておけばよい。そう思っていませんか？
たしかに、情報システムを構築する作業は専門的で多岐にわたり、日々新しい技術が生み出される分野です。だからと言って、作業を事業者に全てお任せ（＝丸投げ）してよいわけではありません。設計・開発を円滑に進めるためには、事業者とＰＪＭＯを中心とする発注者が、二人三脚で作業を進めていく必要があります。
ここでは、ＰＪＭＯが、事業者とともに設計・開発の活動を円滑にトラブルなく進めるために求められる作業や必要となる知識やノウハウについて、要点を押さえて説明します。
本ドキュメントの構成は、次のとおりです。

Step.2 設計・開発を開始するための事前準備
設計・開発を開始する間に、要件を適切に事業者に伝える必要があります。また、ＰＪＭＯが求める情報システムをトラブルなく構築していくためには、仕様の調整や、できた情報シス
テムを適切に検証することが必要となります。ここでは、これら設計・開発の前提知識や心得えを説明します。

Step.3 ブラックボックスにならない設計・開発の計画
設計・開発事業者が決まったら、最初にやることは計画を立てることです。設計・開発の活動は、ＰＪＭＯにとっては、実態が見えにくい活動になりがちで、問題の発覚が遅れて大惨事になることもしばしばあります。ここでは、設計・開発の活動をブラックボックスにしないようにするための設計・開発の計画に係るポイントを説明していきます。

Step.4 設計・開発・テストの管理
設計・開発の大部分の作業は、事業者が行うことになりますが、ＰＪＭＯが適切な関与を行わなければ、良い情報システムを構築することはできません。ここでは、テストを通した品質管理を中心として、設計・開発の実施を管理していくためのポイントを説明します。

Step.5 見落としがちな活動に注意
設計・開発でやらなければいけないことは、情報システムの構築だけではありません。本番で情報システムを稼働させ、サービス・業務の円滑な運営を行っていくためには様々な活動が必要になります。ここでは、設計・開発の活動の中で見落としがちな活動とそれらのポイントを説明します。

Step.6 新しい業務の運営をスムーズに行うための準備
情報システムの開発・テストが完了し、いよいよサービス・業務の開始が迫ってきました。でも、まだ心配事が残っていませんか？ここでは、情報システムを無事に稼働させ、新しいサービス・業務の運営を円滑に行っていくために必要となる最終盤の作業について説明していき
ます。

-

6 -

（第３編第７章 設計・開発）

Step.

2 設計・開発を開始するための事前準備

ＰＪＭＯが、設計・開発の活動に適切に関与していくためには、最低限の知識とＰＪＭＯが果たすべき役割と責任を認識しておく必要があります。これらの内容は、要点を押さえれば、それほど難解なものではありません。
では、設計・開発の活動に必要となる前提知識や心構えを見ていきましょう。

１

設計・開発で職員が行うべき事を理解する【標準ガイドライン関連箇所：第３編第７章第１節】

設計・開発の具体的な活動を行うのは、調達によって選定された事業者です。事業者は、調達仕様書及び附属資料である要件定義書をインプットに、設計・開発工程の活動を計画
し、活動を行います。設計・開発工程の作業は、情報システムを対象とした専門的なスキル・経験が求められます。
では、職員が関与しなくても作業が順調に進むかというとそうはいきません。一般的に、職員の関与が低いほど、設計・開発の成功確率は低下します。
したがって、『専門的』でわかりづらい設計・開発工程の作業において、『職員が関与する』
ことで効果がある作業とは何かを理解する必要があります。
まず、職員が作業に関与するに当たり、基本的な役割を以下に示します。

『設計・開発』を行う際の職員の基本的な役割
要件の内容を事業者に正しく伝える役割
要件どおりに情報システムができたかを確認（テスト）する役割
プロジェクトの進捗状況を正しく把握し、スケジュールや関係者間において発生する調整を適切に行う役割

A. 『要件の内容を伝える役割』
要件は、既に要件定義書としてドキュメントに取りまとめられています。事業者は、その情報を基に『どうやって作るか』を具体化する設計作業を開始し、徐々に詳細化していきます。その作業の過程で、要件定義書だけでは読み取れない発注者側の意図や要望について、発注者側は正しく伝達することが必要となります。また、設計をする中で見えてくる課
題等の対応方法を決めることも必要です。例えば、設計書のレビューにおいて、発注者側の意図とそごがある部分や明確に理解されていないと思われる部分がある場合は、事業者との打合せの場を設け、認識そごを解消する必要があります。また、パッケージ製品等を導入する場合は、設計・開発事業者が提案した製品と業務との Fit&Gap 分析に発注者が主体的に関与し、発注者と事業者の双方で製品と業務の適合性を確認する必要があります。Fit&Gap 分析の結果、要件と乖離（Gap）している点に対しては、カスタマイズを行うこと
で要件に合わせるという選択肢もあります。ただし、カスタマイズ範囲を増やしすぎると、運用保守段階で変更が発生する度に当該機能の動作テストも行う必要があるなど、保守性を損なう可能性もあります。これらの長所、短所を勘案した上でカスタマイズ範囲を検討する

-

7 -

注記
Fit&Gap 分析とは、パ ッケージ
製品の機能が、発注者の要件に適合（Fit）している 点と乖離
（Gap）している点を明らかにし、事業者の提供するパッケージ製
品と発注者が求める要件との適合性を判断する分析手法のこと。
注記
カスタマイズの範囲は、パッケージ製品の設定値の変更から機能改修まで多岐にわたるが、左記の文章におけるカスタマイズは、発注者から提示された要件に応じてパッケージ製品の機能改修を行うことを指す。

（第３編第７章 設計・開発）ことが重要です。
この段階でコミュニケーションが十分にとれないと、いざ運用段階で実際に利用してみると使い勝手が悪かったり、手戻りが発生したりといった弊害を招きかねません。
以下の事例は、実際のプロジェクトで発生してしまった実例です。このような失敗をしな
いように留意してください。

事例：基本設計段階でのコミュニケーション失敗

注記
文書や口頭で丁寧に説明を行ったとしても、伝達ミスや誤認等のコミュニケーションロスを完全に排除することはできない。
このため、Fit&Gap 分析を事業者に一任すると誤った要件の理解に基づいて分析が行われ、誤った結果が導かれる可能性があることから、発注者が主体的に関与することが必要。

過去の設計段階における画面設計にて、以下のような問題が発生しています。利
用者が効率よく、誤解なく正確に使えるように設計段階で留意しましょう。
(1) 固定幅や固定行数で画面が設計されているため、画面の右側や各ブロックの下に空き領域が出てしまうケースがある。
※画面の一覧視認性を高める配置・構成にすべきです。
(2) 大事な情報が横スクロールしないと見られない作りになっている。
※縦スクロールする利用者画面において横スクロールの UI は避けるべきです。
(3) 直感的に使いにくいボタン配置「更新」ボタンが中央付近、「戻る」ボタンが最も右端にあり、操作ボタンが離れている
ボタンレイアウトのトレンドを意識する
例：Web やスマートフォンにおける UI（ユーザインタフェース）では「修正」「更新」「戻る」「進む」「キャンセル」「OK」のように、左側のボタンが後ろ向き操作、右側のボタンが前向き操作とすることがトレンドです。
(4) 否定文を使った確認ダイアログの利用は利用者の迷いや誤操作を招きやすい
例：この操作をキャンセルしますか？「キャンセル」「OK」(5) 開いた Web ページのサイトにおける位置を示すものがない機能構成ツリー
やパンくずリストを設定しないと、利用者に全体像が伝わらない、操作が煩雑になる、あるいは迷子になることが発生します。
(6) エラーメッセージがわかりにくい
どのシステムのどのデータ、どの処理でエラーが起きたかを明示することが望まれます。
(7) インポート機能がない
複数の申請を一括処理するための機能・UI がない※一括申請の利用者の存在と利用頻度を考慮するべきです。
(8) 異常処理系において面倒な運用操作が必要
プルダウンの選択肢を変更しようとした場合に、プルダウン項目を決めている
別の項目設定をいったん空欄にしないと変更できないつくりになっていた。
※親子関係のある設定や選択肢は、子側を変更しようとした際に親側の変更もできるつくりにすべきです。

参考：使い勝手の良いシステムを構築するための工夫-

8 -事例 7-1
基本設計段階でのコミュニケー
ション失敗

参考 7-1
使い勝手の良いシステムを構築するための工夫（第３編第７章 設計・開発）

どのような使い勝手にするかということまで調達仕様書に完全に反映できれば望ましいですが、実際にはそこまでイメージが固まっておらず難しい場合が多いです。そこで、基本設計段階で画面イメージや画面遷移図を作りますが、それらのドキュメントを主体として発注者と受注者で認識合わせをしたとしても実際にできあがったものを試してみると使い勝手が悪いということがあります。利用者にとって使い勝手の良いシステムを構築するためには、どのような工夫をすればよいでしょうか。
以下では、そのような観点から有益な工夫をご紹介します。
実機を用いた認識合わせ思っていた使い勝手と違っている、と受入テスト段階で気がついても、大きな修正は難しいことが多いです。このため、できるだけ早いタイミングでシステムの使い勝手を確認することが重要です。
パッケージ製品を利用するなど動作する環境を事前に用意しやすい場合は、調達前の市場調査時に実機を用いたデモによって使い勝手を確認することができます。ただし、当該製品の基本的な機能を用いたシナリオのデモを確認しても、実際に業務で使用する場合の使い勝手までは確認できない場合があるため、想定した使い
勝手と違っていたと導入後に気づく懸念があります。
このため、当該製品の基本的な機能だけでなく実際の業務における使い勝手を確認することを目的として、調達後における要件定義の内容の調整・確定段階で利用者の業務環境に合わせてパラメータ設定等を行った環境を構築し、利用者がシス
テムを自由に操作できる機会を設けることを要件として定めることも有効です。
一方で、スクラッチ開発のように開発の終盤になるまで実際の動作を確認することが難しい場合には、利用者を巻き込みプロトタイピングにより認識合わせをする、結合テスト段階で実際に開発された画面を用いて動作を確認するといった工夫が考えられます。なお、結合テスト段階における動作確認で使い勝手が違うと気づいたもの
が、要件定義や設計内容を正しく反映していない場合は当然に修正を求めることができますが、仕様変更の場合はこの段階での対応が困難であることが多いことに留意が必要です。そのため、基本設計のような上流工程でプロトタイピング等の手法を使ってしっかりと使い勝手を確認することを推奨します。
また、認識そごを発生させないための上記のような工夫について応札事業者から提案を求めることも有効です。
いずれの場合でも、一度認識合わせをして終わりとするのではなく、それ以降の設計やテストの段階で、できるだけ確認やフィードバックを行うこと、業務で実際に当該
情報システムを利用することとなる職員が主体となって使い勝手を確認することが重要です。
利用者を限定したスモールスタート
ある省庁では、地方自治体の職員が利用するシステムの整備に当たって、緊急性の高さから、現場の業務実態が不明確だったものの、まずは動くシステムを構築し、一部の利用者に限定して運用を開始する方針としました。このスモールスタートによって、例えば、一件ずつ逐次処理するだけでなく複数件を一括処理する必要がある
こと、自治体の規模等によって決裁の仕方が異なり組織形態に合わせた処理が必要であること、職員の負担を減らすために自動化など効率化の余地があることがわかりました。このシステムでは、これらの利用者からの意見を踏まえてシステムをブラッ
シュアップし、使い勝手をより良くしてから本格運用を開始できました。
一部の利用者で小規模に運用を開始するという方法はすべてのシステムで採用できるものではありませんが、利用者にとって使い勝手の良い機能を提供するためには有用な方法です。
また、同じようにスモールスタートを行った事例として、「第 3 編第 4 章 Step.6-2A.事例 4-14：一部地域で試行してから、サービスを全国へ展開」も合わせて参照してください。

-

9 -注記
プロトタイピングとは、情報システ
ムを本格的に構築する前に、試作品（プロトタイプ）を作成し、実物を見ながら要件を具体化していく手法

（第３編第７章 設計・開発）

B. 『要件どおりに情報システムができたかを確認する役割』
構築された情報システムが、伝えた要件を満たすものになっているかを確認するのは職員の役割です。
もちろん、情報システムの様々な処理がきちんと動作できるのかは、職員が確認する前に、事業者がテストで十分に確認していることが前提となります。
テストにおいて職員に求められることは、テストすべき項目（テスト仕様書）をレビューし、内容の正しさをチェックすることと、事業者が実施したテストの結果を確認することです。
テストを実施する作業の中では、テスト項目に従って情報システムが正しく動作しているかどうかを確認していきます。テスト項目とは、情報システムにどう動いてほしいかの要求を詳細化したものです。これが間違えていたり、抜け漏れがあったりすると、情報システムが要求どおりに構築されたとは言えなくなります。したがって、職員は、テスト仕様書に目を通し、要求を反映したテスト項目となっているかを確認することが重要となります。
もちろん、テストには様々な種類が存在し、テストごとに職員の関わり方は異なります。詳細は「Step.3-3 テストの計画を立てる」を参照ください。
通常のテストは上記のとおりですが、受入テストは例外扱いで、職員自らがテストを実施する必要があります。

C. 『プロジェクトの進捗状況を正しく把握し適切な調整を行う役割』
この役割は、発注者側の立場によるプロジェクト管理の一つとして、ＰＪＭＯに求められるものです。
設計・開発工程では、プロジェクト期間が長く、プロジェクト開始時には概要レベルの全
体スケジュールを立案し、詳細な計画は、段階的に作成していくことになります。この作業を進める中で、様々な関係者が登場します。新たな情報システムを導入する際には、ほとんどのケースで業務を見直して、手順や内容の変更を行います。その過程で業務関係者間での調整がうまくいかないことは、プロジェクトの進捗を遅延させる要因となります。
また、プロジェクトには期間と予算の制約がありますので、どんなに良い方法であってもこれらの制約の関係で妥協しなければならないこともあります。
そのため、ＰＪＭＯは、プロジェクトを正常に進めるための調整が重要であることを認識し、その役割を担う必要があります。

２

設計・開発全体を通して理解すべき点とは【標準ガイドライン関連箇所：第３編第７章第１節】

ＰＪＭＯが、発注者として設計・開発を適切に管理していくために、設計・開発の活動全体を俯瞰的に理解しておく必要があります。ここではその内容を説明していきます。

A. 要件を理解した職員の継続的な関与がプロジェクトを安定させる
大規模なプロジェクトの場合、設計・開発工程だけで１年以上の期間が必要となることが多くあります。
要件定義において、多くの職員からの意見を集約し、様々な情報を分析して、新しい業務を決定しましたが、その全体像を理解している職員は、要件定義に関わった職員の中でもごく一部に限定されます。
このような職員は、プロジェクトにとって非常に貴重な存在です。設計・開発工程において、事業者に要件の全体像を説明し、要件追加変更に伴う影響度の調査が行うには、全体を理解していないとスムーズにできないからです。また、要件がどのような背景で発生し

-

10 -

（第３編第７章 設計・開発）決められたのかの経緯を正しく理解していないと、誤った説明や安易な変更を行うおそれがあります。
こういった問題を発生させないためにも、要件定義に関わった発注者側の職員、特に業務を理解している業務実施部門の職員をプロジェクトの体制に参画させ続けられるよう、体制の組成時に調整を行うことは効果的です。

B. 要求とコストと納期のバランスをとる
設計・開発の活動を進めていく中では、要件変更や当初計画からのかい離は、様々な要因により発生します。要因には、政権交代や世の中の情勢変化に伴う方針変更、連携する情報システムの要件変更等のプロジェクト外部で発生する要因や、設計として詳細化していく中で発覚した要件定義の誤りや受入テスト時に発見される要件の抜け漏れ等のプ
ロジェクト内部で発生する要因があります。
このような場合に、「納期は絶対で、追加発注も不可能。でも、変更は受け入れて当初計画どおりに仕上げてください。」と指示を、建設的な議論をせずに行ったとしてもプロジェ
クトはうまく進みません。
事業者は、要件定義の内容、納期・スケジュールに基づいて、コストを見積り、計画を立てます。つまり、「要件（スコープ）」「コスト」「納期（スケジュール）」のいずれかが変更されると、ほかにも必ず影響が発生します。
では、「今年度の計画は変更できないので、追加や変更は全て来年度以降に先送りします」としても、そこに重要な要件が含まれている場合は、今年度出来上がった情報システムがまともに動かないリスクもあります。
これは、要件の変更だけではなく、スケジュールや納期の変更でも同様です。
では、このような場合にどう対処すればよいでしょうか？
これらを適切に管理するための仕組みが「変更管理」です。変更管理は、変更の必要性が発覚した際に、「変更に対する影響の調査」「影響度合いに応じた変更の決定の手続」
等の変更に対する管理方法を定めるものです。まずは計画時に、これらを明確に定め、これに則り設計・開発工程作業中に発生する様々な追加変更を取捨選択していくことが大切です。影響度の判断によっては、当初の要件を諦め、新しく発生した要件と差し替える等、柔軟な対応が求められます。

C. 設計・開発の全体像と流れを理解する
設計・開発の活動は、設計・開発・テスト・移行等のいくつかの作業工程に区切って進めていくことが一般的です。しかし、これらの工程の組み方は多種多様で、それぞれメリット・デメリット、向き・不向きがあります。ＰＪＭＯは、これらを踏まえた上で、事業者が立案した計画を理解して、プロジェクトにあった進め方となるよう、事業者に要望を伝えていきます。
ここでは、事業者の計画を正しく理解し適切な進め方を検討していくことができるよう、設計・開発全体の進め方に係る知識やノウハウを解説していきます。

設計・開発工程に含まれる全ての活動内容を俯瞰的に理解する
設計・開発では、様々な活動が行われます。事業者が作成するスケジュールを確認する
際、まずは俯瞰的に工程の流れを押さえて、大きなそごがないかを見ていきましょう。
情報システムの設計・開発は、大まかに捉えると以下のような流れになります。

-

11 -

（第３編第７章 設計・開発）

図 7-1
工程の全体像

これらの活動ごとの成果物を洗い出し、その成果物を得るために必要な作業を細分化
し、作業にかかる時間や作業順を当てはめていったものがＷＢＳに基づいたスケジュールとなります。ＷＢＳの確認については、「Step.3-2-E. ＷＢＳで作業計画を確認し進捗を把握する」を参照してください。
なお、工程の名称は、事業者によって呼び方が異なります。同じ名称でも、事業者によって捉え方が異なることがあるため、注意が必要です。工程の捉え方を間違えていると、適切な時期に求めたレベルの成果物ができていなかった、というようなことが発生します。
標準ガイドラインの
定義
要件定義

基本
設計

Ａ社

Ｂ社

Ｃ社

要件定義

要件定義

BD：基本
設計
外部設計

設計

FD：機能
設計
詳細
設計

内部設計

DD：詳細
設計
CD：コー
ディング

RD：シス
テム要件
定義
UI：ユー
ザーイン
タフェース
設計
SS：システム構造設
計
PS：プログ
ラム構造
設計

Ｅ社

Ｆ社

要件定義

要件定義

要件定義

外部設計

基本設計

基本設計

内部設計

詳細設計

詳細設計

PG：プロ
グラミング

実装・
単体テスト

コーディ
ング
／テスト

結合テスト

結合テス
ト

IT：結合
テスト

PT：プロ
グラムテス
ト
IT：結合
テスト

総合テスト

システム
テスト

ST：総合
テスト

受入テスト

運用テス
ト

RT：受入
テスト

UT：単体
テスト

Ｄ社

開発

開発/単
体テスト

開発/コ
ーディン
グ
単体テス
ト

統合テス
ト

結合テス
ト

結合テス
ト

ST：システ
ムテスト

システム
テスト

総合テス
ト

OT：運用
テスト・移
行

-

システム
テスト
運用テス
ト
受入テス
ト

運用テス
ト

プロジェクトの特性（新規構築・更改等）によって、作業は異なる
設計・開発で行う作業の内容は、プロジェクトの特性によって異なります。例えば、情報

-

12 -

表 7-1
標準ガイドラインと各社が定義する工程の比較

（第３編第７章 設計・開発）

システムを新規に構築するプロジェクトと既存情報システムの更改のプロジェクトでは、作業の内容が大きく変わります。

プロジェ
クト特性

概要

他の特性との違い

新規構築

新たに情報システムを構築する。

情報システムの構築に係る全ての作業が必要となる。

更改

既存の情報システムを再構築する。
ただし、再構築には様々な方法があり、インフラのみを変更して、新しい環境（ハードウェア・ミドルウェア等）上で既存の情報システムが稼働するようにする
ことや、現在の情報システムをいかしつ
つ機能の改修を行うこと等がある。

更改の方針に応じて、作業が異なる。
また、新規構築と比べ、テストや移行の比重が高くなる傾向にある。
事前検証を行う等、新規構築とは異なる作業が必要となる可能性がある。

表 7-2
プロジェクト特性の概要

また、一から情報システムを構築（＝スクラッチ開発）する場合、クラウドサービスの利用、パッケージ製品等の導入・カスタマイズでは、それぞれ活動の内容が異なってきます。例えば、クラウドサービス（PaaS）の利用では、機能に関する実装・テストよりも運用視点でのテストの比重が増えるかもしれません。
情報システムの更改を行うタイミングは、情報システムの機能を見直すに当たり、またとないチャンスです。現在のサービス・業務運営上の課題や既存情報システムの運用の中で寄せられた要望等を確認し、情報システムの機能改善を検討しましょう。なお、やむを得ない事情により、機能改修を伴わない更改を行うこともありますが、その際には機能の実装・単体テスト等を実施する必要がないかもしれません。このようなプロジェクトの特性に合わせて、作業内容の必要十分性を確認しましょう。
確認に当たっては、「Step.3-2 設計・開発の実施計画を立てる」で解説する設計・開発
実施計画書のひな型を参考にして比較を行い、不足や不明点は事業者に確認して、事前に漏れや誤りをなくすようにしましょう。

プロジェクトの進め方や開発手法により作業内容も異なる
設計・開発の進め方には、様々なものがあります。以前は、情報システムの構築といえ
ば、ウォーターフォール型で進めることが主流でしたが、ソフトウェア開発の過去の失敗事
例等を踏まえて、様々な進め方が考案されています。
標準ガイドラインで定義するプロジェクトは、大きく以下の２つに分類できます。

進め方の種類概要

適用の基準例

通常の開発

定義した要件に基づいて全ての機能を構築してサービス・業務を開始する。その後、必要に応じて機能追加等を行う。

プロジェクト目標に対する具体的な実現方法が定まっており、要件の詳細な定義が可能な場合

実証実験型開発

必要最低限の機能を構築してサービスを開始し、効果をモニタリング
しながら要件を明確にし、段階的に情報システムを構築していく。

プロジェクト目標に対する具体的な実現方法が定まっておらず、要件の詳細な定義が困難である場合

また、情報システムの開発手法も、複数あります。代表的な開発手法には、次のようなものがあります。

-

13 -

表 7-3
プロジェクト全体の進め方の種類

（第３編第７章 設計・開発）

開発手法の種類概要

ウォーターフォール

図 7-1 で示したような工程を時系列に進め、原則として前工程の完了後に次工程を開始する情報システム構築作業の進め方である。
設計・開発の途中で変更が少ないと見込まれる場合に用いる。
工程を時系列で進めることから、計画が立てやすく、進捗の管理がしやす
い。

アジャイル

開発対象となる機能（１～複数）の設計・開発・テストをイテレーション（反復）と呼ばれる短い期間に分けて進め、イテレーションが終了するごとに動く機能が出来上がる情報システム構築作業の進め方である。
設計・開発の途中で変更が多く発生すると見込まれる場合に用いる。
短期間で動く機能が出来上がるため、情報システムの利用者に確認を取
りやすい。

表 7-4
情報システム整備の進め方の種
類とメリット・デメリット

ウォーターフォール型は従来型の開発手法ですが、その工程の中でプロトタイピングをとることも増えてきています。プロトタイピングとは、情報システムを本格的に構築する前に、試作品（プロトタイプ）を作成し、実物を見ながら要件を具体化していく手法です。ウォータ
ーフォールでの開発においても、設計工程の中でプロトタイピングを導入することで、関係者からの意見を聞きながら要件をとりまとめやすくなります。
昨今、開発手法として増えているのがアジャイルです。現時点においては、開発工程全てにわたってアジャイル開発を貫いた事例はまだ少ないですが、部分的に設計工程においてモックアップ画面等を導入して仕様確定を促進するケースは増えてきています。アジャイル開発の進め方は、サービス設計 12 か条にある「何度も繰り返す」、「一遍にやらず、一貫してやる」といった視点に沿うものですので、積極的に導入を検討してみてください。
アジャイルの考え方の規範は、「アジャイルソフトウェア開発宣言」として一般に公開され

注記「アジャイルソフトウェア開発宣言」とは、従来型のソフトウェア開発のやり方とは異なる手法を実践していた開発者・研究者が2001 年に作成した、アジャイル開発を進める上での「マインドセット」が書かれたもの

ています。

図 7-2
アジャイル開発の基本的な進め方

一方で、形式だけでアジャイル開発を採用すると失敗することになりかねません。以下のような形だけのアジャイル開発にならないように気を付けましょう。
投げっぱなしアジャイル
発注者の要件を調達以前の段階で十分に定めず、要件自体を設計工程で決めるというように後送りにする方法。調達する事業者の能力や経験によって、構築できるシ
ステムの機能や品質が大きく変わってしまう。特に、事業者の能力が十分でなかった
際に、要件定義内容を元に改善指摘をすることが難しくなってしまう。
優先度をつけないアジャイル
設計を進める中で出てきた要件について、発注者が優先度の判断をせず、全てを実現することを求めてしまう方法。限られた工数の中で効果の大きい部分を選び出していくことがアジャイルの特徴であり、優先度を判断しないのであれば後出しした要件を

-

14 -

（第３編第７章 設計・開発）

全て実現させるという非合理的な契約形態となってしまう。
なお、アジャイルが適さないと言われているプロジェクトもあります。一般的には、大規模なプロジェクトやミッションクリティカルなプロジェクトはアジャイルに適していないと言われています。ただし、大規模なプロジェクトであっても部分的にアジャイルを適用することは可能です。
開発手法は、必ずしもプロジェクト全体で統一しなくてはいけないわけではありません。メ
リット・デメリットを理解して、特定の機能群についてはアジャイルで進める、というように「良いどこ取り」していくことも大切です。

-

15 -

（第３編第７章 設計・開発）

事例：ウォーターフォールとアジャイル開発を組み合わせた開発計画
ある省において、大規模な情報システムの更改を行うことになりました。既存の情報システムは長期間運用していたこともあり、現場からは多くの要望が上がっていた
ため、更改に合わせて情報システムを刷新することとしました。
現場からの要望は多種多様であったため、早めに実働する情報システムを用いた現場の確認を行わないと、実現イメージがすり合わずに後々変更や追加要望が多発することが予見されました。そのため、設計・開発は、アジャイルで行うことを検討しましたが、大規模な情報システムであるため、全てをアジャイルで構築しようとすると、管理コストが高くなる、要員の確保が難しい等の懸念がありました。
そこで、ＰＪＭＯは、マイルストーンを明確にした上で、アプリケーションをアジャイル
で、インフラをウォーターフォールで開発、構築する計画としました。アプリケーションの設計・開発は、一ヶ月単位で計８回行う計画とし、その都度受入テストを実施します。そして、出来上がったアプリケーションを確認しながら改善要望を収集し、アプリ
ケーションの機能やユーザーインタフェース等を見直していくことにしました。

このような工夫をこらした結果、現場の要望を十分に反映した実用的な情報システ
ムを計画どおりに構築することができました。
また、既存システムには、統計分析を行う基盤となるサブシステムがありましたが、分析の切り口を変える度に、当該サブシステムの改修や運用事業者へのデータ抽出の依頼でコストが掛かっていました。
そこで、更改にあたっては、この情報システムからデータを抽出するインタフェースを整備するとともに、職員自身がデータ分析をできるように BI ツールを導入しました。これによって、複雑なサブシステムがなくなりシステム構成がシンプルになったことで調達時の競争性が向上するとともに、改修費用も抑えることができるようになりました。

D. 通常シナリオだけでなく、緊急時の対応計画も準備する
設計・開発のスケジュールを作成する際に、各工程が順調に進むことを前提とした楽観

-

16 -

事例 7-2
ウォーターフォールとアジャイル
開発を組み合わせた開発計画

（第３編第７章 設計・開発）

的なプランを１つだけ策定してしまうことが多くみられます。
実際にプロジェクトを進行する中では、予想していなかった様々な制約や問題が判明することもあり、スケジュール自体を大幅に見直すことも少なくありません。
このような際に役立つのが、緊急時対応計画（コンティンジェンシープラン）です。
緊急時対応計画の中では、予想していなかった問題が発生した際に後続工程の開始を遅らせたり、工程を分割して同時並行で進めたりするような形で、プロジェクトへの影響を最小限に抑えるための計画を準備します。このような計画を事前に準備しておけば、実際に問題が起こった際にも比較的冷静に正確な判断を行うことができます。
緊急時対応計画は、設計・開発工程だけでなく、情報システムが稼働した後の運用工程でも有効です。災害発生時等の緊急事態に際して、誰がどのように行動し何を優先して作業すべきかを定めます。
なお、緊急時対応計画と業務継続計画は類似する内容となりますが、緊急時対応計画
は災害発生時の対応そのものに焦点を当てていることに対して、業務継続計画は災害発生後に必要となる業務を継続して実施することに焦点を当てているという違いがあります。

E. メンテナンス性を考慮した成果物の構成、内容を考える
プロジェクトで作成される成果物は、調達仕様書でも指定されているとおり、多岐に渡ります。ここでは、その中でも特に重要な基本設計書に関して説明していきます。
システム開発においては、事業者に基本設計以降の工程を委託することが通常の形ですが、「Ｃ．設計・開発の全体と流れを理解する」でも説明しているとおり、事業者は設計の詳細化を行いながらシステム開発を進めていきます。そのような工程において、基本設計
工程は、発注者から示される要件内容を理解し、実際のシステムの設計に落とし込む、という発注者―事業者間のインタフェースとなる工程になります。完成するシステムの良し悪しはこの工程、つまりアウトプットとしての基本設計書の内容により大きく左右される重要な工程になります。本当に要件を正しく反映したシステムができるか、使いやすいシステムができるか、あるいは保守・運用を効率良くかつ長期に維持していくためのシステムができる
か、などまさに「システムの命運を握る設計図」を作成していくということになります。
また、基本設計書は要件を実現するための設計図のみならず、システムを品質良く完成させるためのテストのためのインプットドキュメントであり、保守・運用フェーズにおいては設計変更等の「要」となるドキュメントでもあります。

図 7-3
基本設計書の位置づけ

特に留意する事項としては、
データと機能・処理の連携を含めた全体を俯瞰できるドキュメントになっている

-

17 -

（第３編第７章 設計・開発）

か
データに関する設計・定義事項が一元的に漏れなく記載されるようになっているかなど、要件を反映した全体像の把握とデータ利活用・連携の観点からデータに関する設計・定義状況の把握が容易なメンテナンス性の高いドキュメント構成、内容になっているかということです。
表 7-5 は基本設計書の構成例です。システムの特徴あるいは受託した事業者によって構成や内容は異なることもありますが、おおむね以下のとおりです。全体編、機能編、データ編等まずは全体構成を確認し、その上で観点や考慮点が満たされているか、あるいは分かりやすい目次構成になっているか等を十分に確認していきましょう。

項番

目次

内容

備考

1

全体編

1-1

システム全体図

システム、業務、Ｈ／Ｗ，Ｓ／Ｗ，Ｎ／Ｗ等の各々視点から全体俯瞰す
る資料

1-2

データの流れと機
能構成

データ及びその流れとそれぞれの機能との関係全体を記載

1-3

機能分割

サブシステム構成、機能分割、処理方式など基本的な設計の考え方を記載

マイクロサービス定義及び連携の設計コンセプト
も記載

・・・

・・・

・・・

・・・

2

機能編

2-1

機能・画面・帳票一覧

分割された機能を一覧として記載。
ま た 関 連 する 機能 と 対応 させた 画面・帳票を一覧形式で記載

2-2

画面・帳票フロー画面、帳票と機能の流れ（展開条
件、戻り条件など）を記載

バッチの場合はジョブフ
ローとして記載

2-3

各機能別処理内容

機能毎の処理概要、入出力（データベース、ファイル、画面、帳票など）
関連図、チェック／編集要領など定型標準フォームに記載

オンライン、バッチ、共通機能（ＡＰＩ等）を処理／
提供形態等により分ける。マイクロサービスごとの処理概要を含む。

・・・

・・・

・・・

・・・

3

データ編

3-1

データモデル

要件定義で作成した概念レベルのモデルを詳細化。全てのデータ（データベース、ファイル、テーブル等）を関連づけて記載

3-2

データ一覧、データ
定義／レイアウト

データベース、ファイル、テーブルなどのデータに関する説明（マスターデータ等の分類、標準化レベル等も
記載）

3-3

CRUD

データと機能の処理別マトリックス。
データの生成から更新、参照、消滅までのライフサイクルを記載

・・・

・・・

・・・

全てのデータ項目（コード含む）の意味定義も記
載

・・・

-

18 -

表 7-5
基本設計書の構成例

（第３編第７章 設計・開発）

Step.

3 設計・開発の計画

設計・開発を担う事業者にとって、最初のインプット資料は、調達仕様書や要件定義書です。そのため、その内容には十分な質・量が求められますが、どんなに準備したとしても、要件の不備・不足は発生しますし、作業が進めば当初の計画からのかい離は起こり得ます。これらをＰＪＭＯが早期に察知して適切な関与を行っていかなければ、後々大変なことになりかねないのですが、事業者の活動は、実際の状況が見えづらくブラックボックスになりがちで、対応が遅くなってしまうことが多くあります。
ここでは、事業者の活動を正確に捉えて、設計・開発を円滑に進めて品質の良い情報シス
テムを作り上げていくために、計画時点で理解すべき知識やノウハウを紹介していきます。

１

設計・開発の管理の要点を理解する【標準ガイドライン関連箇所：第３編第７章第１節】

設計・開発を担う事業者の活動状況は、事業者との定例会において共有されますが、専門的な内容が多くなると、説明をただ聞くだけになりがちです。そのような状況でも、管理すべき
管理の要点をしっかり押さえて確認し、不明な部分を事業者から引き出していけば、正しい方
向にプロジェクトを導いていくことができます。
ここでは、設計・開発における管理の要点を見ていきましょう。

A. 定点観測こそ進捗・品質管理の要（かなめ）
もしも、あなたに情報システムの整備に係るプロジェクトの経験がなくても、まずは作業の状況を定量値で管理し、継続してその値を把握してみましょう。そうすると、現場の状況がいろいろな角度から見えてきます。これにより問題が発生する予兆を捉えることができれば、その事象を個別に分析することで、原因を捉え、必要な対策をすることにつながりま
す。

工程
設計

定点観測すべき定量値と確認観点
ＷＢＳに対する進捗率（ＥＶＭのＳＰＩ）にて、予実のかい離と傾向を確認し、予定した作業がスケジュールどおりに完了するか、対策が必要かを確認する。
当初想定した生産性と実生産性のかい離（ＥＶＭのＣＰＩ）にて、予実のかい離と傾向を確認し、予定した作業が完了するか、対策が必要かを確認する。
品質状況（信頼度成長曲線等）にて、適切なレビューが安定的に行えているか、品質に問題がないかを確認する。

開発

ＷＢＳに対する進捗率（ＥＶＭのＳＰＩ）にて、予実のかい離と傾向を確認し、予定した作業がスケジュールどおりに完了するか、対策が必要かを確認する。
当初想定した生産性と実生産性のかい離（ＥＶＭのＣＰＩ）にて、予実のかい離と傾向を確認し、予定した作業が完了するか、対策が必要かを確認する。

テスト

テストの消化数の予実、不具合数等の予実の推移（信頼度成長曲線）にて、予実のかい離と傾向を確認し、最終的に品質基準を満たすことができる見込みか、対策が必要かを確認する。
摘出した不具合から不具合の原因の傾向を確認し、不具合の原因が満遍なく摘

-

19 -

表 7-6
工程別観測定量値と確認観点
注記
ＥＶＭとは、ＷＢＳにより詳細化した各作業項目に出来高計画値（ＰＶ：Planned Value）を設定し、プロジェクトの進捗を出来高実績
値(ＥＶ：Earned Value)として定量化すること。ＥＶＭは Earned
Value Management の略。（EVMの詳細については、Step.3-2F を参照）
注記
ＳＰＩとは、累計の出来高計画値（ＰＶ）に対する累計の出来高実
績値（ＥＶ）の比率のこと。
ＳＰＩは Schedule Performance
Index の略。

（第３編第７章 設計・開発）

工程

定点観測すべき定量値と確認観点
出できているか、対策が必要かを確認する。
プロジェクトリスク管理上の重要な対策として、テストで発見した不具合を修正して再テストするための期間をあらかじめ計画に入れておくこと。

全体

課題の発生数、解決数、解決率を確認し、滞りなく課題が解決できているかを確認し、解決が滞っている課題があれば、対策などを検討する。

注記
ＣＰＩとは、累計の出来高計画値（ＰＶ）に対する累計の出来高実
績値（ＥＶ）の比率のこと。
ＣＰＩは Cost Performance Indexの略。

定量値の観測で大切なことは、事前に進捗率の測り方を明確にしておくことです。作業ステータスのような定性的な情報も、表 7-6 のようにプロジェクトで定めた基準に従って、定量的に管理するべきです。さらに、ステータス管理は、可能であれば作業に応じた成果物（ドキュメントやプログラミング）を捉えて、進捗を計上することをお勧めします。
このようなルールがなく担当者の恣意性に委ねると「進捗率 90%」のまま数週間経つようなことになりかねません。例えば 100 本のプログラムがあって、50 本のコーディングが完了したから「コーディング工程」の進捗率が 50%、そのうち 30 本の単体テストが完了したので「単体テスト工程」の進捗率は 30%というのではなく、100 本の機能の内、進捗率 100%が 30
機能、進捗率 50%が 20 機能というように計上します。ドキュメントについても同様です。

進捗率
0～50%

ドキュメント
事業者の担当者が実作業の進捗に合わせて計上

60%

事業者内レビューの完了

70%

レビュー指摘事項の反映完了

80%

ＰＪＭＯレビューの完了

90%

レビュー指摘事項の反映完了

100%

ＰＪＭＯによる最終確認

なお、コーディングと単体テストを峻別して進捗管理や品質メトリクスをマネジメントすることは、少なくてもユーザ側にとって意味がありません。
テスト駆動開発（テストを先に実装し、それにパスするようにプログラムをコーディングする開発手法）ではコーディングと単体テストが混然として実行されますし、設計されたテスト
ケースどおりではなく単体テスト中に怪しいと感じた箇所を探るような探索的テストによって、コーディングを変更することが推奨される場合もあります。
むやみに作業を細分化して管理するのではなく、現場の行動に即して管理単位が決められているかを確認してください。

B. 判断に必要な情報を職員が理解できる説明として事業者に求める設計・開発の内容は専門的なものであるため、どうしても事業者の資料や説明内容は、職員から見ると専門的でわかりにくいものになりがちです。そのような場合、職員は、事業者が出してきた資料を苦労して読み解こうとしてしまうことがよくあります（もちろん悪いこと
ではありません）が、職員の役割は、問題の本質を正しく捉えて判断することです。そのための近道は、職員が内容を理解できるように、丁寧な説明や資料のまとめ直しをしてもらうことです。内容がよくわからないからといって、事業者からの説明内容をうのみにして判断したり、判断を遅らせたりしてはいけません。
ただし、説明や資料の出し直しの過度な要求には、注意が必要です。進捗の遅延を引

-

20 -

表 7-7
進捗計上ルールのサンプル（ドキュメント）

（第３編第７章 設計・開発）

き起こす要因にもなりますし、事業者との関係悪化の原因にもなります。そのような状況になる前に、ＰＭＯに相談してみてください。設計・開発事業者と「協働して、良い情報システ
ムを作り上げていく」という心構えが大切です。

２

設計・開発の実施計画を立てる【標準ガイドライン関連箇所：第３編第７章第１節】

この実践ガイドブックには、別添として設計・開発の実施計画書と実施要領のひな形を示しています。

様式例：設計・開発実施計画書、設計・開発実施要領のひな形
設計・開発実施計画書、設計・開発実施要領のひな形を本章別紙としてまとめています。

あくまでこのひな形は例示です。プロジェクトの内容に応じて記載内容を個別に追加、変更しても構いません。ひな形を見ると、何をどのようなレベルで書くべきかの参考になると思います。
以降では、設計・開発の実施計画を作成するときに、特に注意が必要なポイントについて説明していきます。

A. 2 種類のプロジェクト計画書の相違点を理解する
設計・開発実施計画書は、設計・開発事業者が作成する「プロジェクト計画書」と同じものでしょうか。これらは、厳密には異なるものです。
設計・開発実施計画書は、当該事業者が担当する設計・開発作業の範囲について、ＰＪ
ＭＯが作成するプロジェクト全体のプロジェクト計画（第３編第２章で示すプロジェクト計画書）を具体化・詳細化したものです。事業者との活動においても、他の関係者とのコミュニ
ケーションや変更に対する管理は、プロジェクト計画に従って行わなければいけません。つ
まり、設計・開発実施計画書は、プロジェクト全体のプロジェクト計画書と整合性が取れている必要があります。
事業者が作成する「プロジェクト計画書」と必ずしも分ける必要はありません。事業者が

-

21 -

様式例 7-1
設計・開発実施計画書、設計・開発実施要領のひな形

（第３編第７章 設計・開発）

プロジェクト計画書を作成し、それらをＰＪＭＯがプロジェクト全体のプロジェクト計画書との整合を確認して確定するという流れでも良いです。もちろん、ＰＪＭＯが設計・開発実施計画書を作成しても良いです。
大切なことは、設計・開発実施計画書、プロジェクト全体のプロジェクト計画書、事業者が作成するプロジェクト計画の整合性が取れており、全ての関係者がそごなく作業を行えることです。

図 7-4
設計・開発実施計画書、プロジェ
クト計画書、事業者のプロジェク
ト計画書の関係性

B. 意思決定の手順を明確にする
設計・開発の実施中には、プロジェクトの内外問わず様々な課題や問題が発生します。
その際に、どのように意思決定を行うかを計画時に明確にしておきます。
通常は、事業者との定例会を設置し、発生した課題や問題はその場で対応を決定していくことになります。しかし、優先度が高く解決が難しい問題を定例会の場だけでやりとりしていると、解決が遅れてプロジェクト全体の遅延につながってしまいます。
したがって、優先度が高い問題、影響が大きい問題が想定外に発生した場合の意思決定の方法をあらかじめ定めておくことが大切です。一般的には、課題や問題の影響範囲や優先度等の基準を定めておき、一定以上の基準の課題や問題が発生した際に、定例会
議以外に、発生した課題を集中的に検討する会議の設置、影響範囲や影響度合いに応じての参加者等を定めておきます。
大切なことは、課題や問題が発生した場合に、それらを事業者やプロジェクトの一部の関係者だけでブラックボックスにせず、影響がある関係者に適切に共有し、共同して解決に向かうことです。

C. 当初計画からの変更は、必ず関係者で合意する
策定時に関係者全体で合意した内容が、いつの間にか当事者だけで変更されてしまうというケースがあります。特に、プロジェクトの目的に直結する重要な事項の変更は、全体関係者及び責任者の承諾なしに変更することは厳禁です。
関連する事例として、実践ガイドブック「第２章事例 2－9. 開発途中の機能追加による目標の形骸化」も参照してください。

-

22 -

（第３編第７章 設計・開発）

D. 他の関係者との役割分担の境界線を定める
設計・開発の計画においては、ＰＪＭＯ、設計・開発の事業者、プロジェクト内の他の事業者、連携する情報システムのプロジェクト等の関係者の役割分担（誰が何を実施するか）を決定し、関係者で合意することがとても大切です。
役割分担でよく問題になるのは、他の情報システムの連携仕様を誰が具体的に定めるのか（要は、具体的なインタフェース仕様書を誰が作成するか、テストにおいて誰が主導してデータやテスト計画を作成するか）です。特に、複数情報システムで共有する連携仕様の場合は、分担が不明確になりがちなので、計画時点で明確に取り決めておきましょう。連携に関するテストを誰がどのように取り仕切るかも同様に決めておく必要があります。

E. ＷＢＳで作業計画を確認し進捗を把握する
ＷＢＳは、設計・開発のスケジュールや進捗を管理する際に一般的に使われるもので、設計・開発の活動ごとの成果物を洗い出し、その成果物を得るために必要な作業を細分化し、作業にかかる時間や作業順を当てはめていったものです。（正確には、縦軸の作業
項目がＷＢＳであり、スケジュールを含めたものはガントチャートと呼びます。）
ここでは、設計・開発の計画や進捗状況を正確に把握するためのＷＢＳに関するノウハ
ウを見てきます。

ＷＢＳの構造を理解して計画や状況を効果的に把握する
スケジュールは、「マイルストーンを明確にする」「概略のスケジュールを立てる」「詳細な作業ごとに、作業にかかる時間と作業間の依存関係を検討し、作業順を決める」という３段階で組み立てられます。

-

23 -

注記
ＷＢＳとは、プロジェクトに必要な作業の全体を細かい単位に分割した上で、全体の構成を示したもの。ＷＢＳは Work Breakdown
Structure の略。

（第３編第７章 設計・開発）

図 7-5
WBS のイメージ。
このイメージはアプリケーション開発に着目した例。運用に関しても、運用設計、運用手順書、総合テスト、運用テストという流れ
で同様に WBS を作成する。

ＷＢＳを確認する際には、この構造を理解し、「マイルストーンにそごや抜け漏れはないか？」「マイルストーンに対して、概略のスケジュールが妥当か？」「各作業の依存関係の誤りや作業の抜け漏れはないか？」「どのアクティビティの経路がクリティカル・パスとなっているのか？」のように段階的にチェックすることで、網羅的な確認をすることができます。
また、「Ｓｔｅｐ3-1-A. 定点観測こそ進捗・品質管理の要（かなめ）」でも述べたように、定例会等で進捗状況を確認していると、「進捗率が 90%で止まっている作業が大量にある」というような状況がよくあります。これは、多くの場合、進捗率の定義が曖昧であることに起因しています。進捗率は、定量的に判断できるように事前に基準を定めましょう。

注記
クリティカル・パスとは、アクティ
ビティの最長経路。この経路に必要な期間が、プロジェクトの最短所要時間となる。クリティカル・パ
ス上のアクティビティが遅延した
場合、プロジェクト期間に影響を与えるため、注意が必要。

F. ＥＶＭを用いた進捗管理手法を理解する
ＷＢＳにより詳細化した各作業項目に出来高計画値（ＰＶ：Planned Value）を設定し、プロジェクトの進捗を出来高実績値(ＥＶ：Earned Value)として定量化するＥＶＭを用いること
で、作業状況を客観的な統一尺度で可視化及び一元管理し、プロジェクトの進捗状況や進捗に係る課題・問題の把握を行い、事前に的確な対応を行うことが可能となります。
ＥＶＭを用いて進捗管理を行う場合、次に示す資料を作成します。

-

24 -

注記
ＰＶとは、計画時に見積もった出
来高値のこと。
ＰＶは Planned Value の略。
注記
ＥＶとは、進捗把握時までに完了した作業の出来高値のこと。
ＥＶは Earned Value の略。

（第３編第７章 設計・開発）(1) ＥＶＭ進捗管理表
ＷＢＳの各作業に対し、出来高計画値（ＰＶ）、出来高実績値（ＥＶ）、投入実績値（ＡＣ）
を記載します。
本様式は各タスクの計画と実績の対比を詳細に示すものであり、進捗管理の基礎情報として用いるものであるため、必ず正確な情報を記載します。

注記
ＡＣとは、進捗把握時までに完了した作業に投入したコストのこと。
ＡＣは Actual Cost の略。

図 7-6
ＥＶＭ進捗管理表

ＥＶＭ進捗管理表
プロジェクト名： ＊＊＊システム設計・開発プロジェクト
開始日
WBS番号
1
1.1
1.2
1.3
1.3.1
1.3.2
1.3.2.1
1.3.2.2
1.3.2
2
2.1
2.2
2.3
2.4
2.5
3
3.1
3.2
3.2.2
3.2.3

作業名

実施主体

進捗管理
WBSの作成出来高計画値（PV)の設定
進捗報告
EVM進捗管理表の作成
進捗報告書の作成
進捗状況の把握・確認
報告資料の作成
進捗報告内容確認・対応策検討
要件定義の確定
要件定義内容の確認
要件定義変更案の整理
要件定義変更案の検討・調整
要件定義変更案の承認
要件定義確定設計
次期システム実現に係る基本的事項の確認
基本設計○○サブシステムの設計△△サブシステムの設計完了日

計画 実績 計画 実績

完了基準

出来高計
画値(PV)

出来高実
績値(EV)

投入実績 投入実績値明細（人日）
値(AC )
20xx年xx月
20xx年xx月

(人日）

(人日）

(人日）

ｘｘ ｘｘ ｘｘ ｘｘ ｘｘ ｘｘ

PJMO
PJMO
設計・開発事業者
設計・開発事業者
設計・開発事業者
設計・開発事業者
設計・開発事業者
設計・開発事業者
PJMO
設計・開発事業者
設計・開発事業者
設計・開発事業者
設計・開発事業者
PJMO
設計・開発事業者
設計・開発事業者
支援事業者
支援事業者
支援事業者
支援事業者

出来高計画値（ＰＶ）
ＷＢＳにより詳細化した各作業項目に対し設定した出来高計画値（ＰＶ）を記載
します。出来高計画値（ＰＶ）の合計は計画総コスト(ＢＡＣ:Budget At
Completion)と必ず一致するように設定します。
出来高計画値（ＰＶ）の作成により、作業コストが多い作業項目や期間が可視化されるため、各期間の作業統制の難易度やリスクが顕在化した際の影響の大きさを判断することが可能となります。
なお、出来高計画値（ＰＶ）はその精度を高めることが必要でありますが、事前に完全一致させる計画を立案することは不可能であり、また、計画外の事態は起こり得るものです。そのため、進捗管理に当たってはＰＶどおりに進めることのみを意識するのでなく、実績と計画の差異を常時把握し、計画どおりに戻すための対策を検討することが重要です。
出来高実績値（ＥＶ）
進捗把握時までに完了した作業の出来高値を記載します。計上方法は表 7-7に示す例を参考にあらかじめ定め、それに基づき計上します。
出来高実績値（ＥＶ）は現状を可視化するための基礎情報であるため、リアル
タイムで、かつ、正確な情報とする必要があります。

方式
固定比率計
上法

説明
作業の開始時と完了時のみに進捗を計上する方法-特徴
前提として詳細な作業分界を行う必要がある。
作業開始時と作業完了時に計上する比率には、0:100、30:70、50:50 等があり、事前に定める必要がある。

25 -

表 7-8
出来高実績値（ＥＶ）計上法

（第３編第７章 設計・開発）

方式
加重比率計
上法

説明
作業の達成率により進捗を計上する
方法

特徴
作業期間が長い場合等、固定比率計上法では進捗を把握するのが難しい場合に有効。
細かくマイルストーンを事前に定め、主観による曖昧さを排除する必要がある。

投入実績値（ＡＣ）
進捗把握時までに完了した作業に対し、実際に投入したコストを記載します。
投入実績値（ＡＣ）は現状を可視化するための基礎情報であるため、リアルタイ
ムで、かつ、正確な情報とする必要があります。
(2) 進捗状況表
ＥＶＭ進捗管理表を集計し、月次の出来高計画値（ＰＶ）、出来高実績値（ＥＶ）、投入実
績値（ＡＣ）、スケジュール効率指数（ＳＰＩ）、コスト効率指数(ＣＰＩ)、予測総コスト（ＥＡＣ）及び残コスト（ＥＴＣ）を記載します。
本様式は、月次の進捗状況の定量分析結果を示すものであり、次に示す例は、スケジュールが遅れている上にコストも超過し、体制強化や品質向上施策等の対応を至急行うべき状況を表すものです。

（様式及び記載例）

注記
ＥＡＣとは、完了時に予測される総コストのこと。
ＥＡＣは Estimate At Completionの略。
注記
ＥＴＣとは、進捗把握時から完了までに予測されるコストのこと。
ＥＴＣは Estimate To Complete
の略。

図 7-7
進捗状況表

記載項目

記載内容

①出来高計画値（ＰＶ）

当月及び当月までの累計の出来高計画値（ＰＶ）を記載する。

②出来高実績値
（ＥＶ）

当月及び当月までの累計の出来高実績値（ＥＶ）を記載する。

③投入実績値（ＡＣ）

当月及び当月までの累計の投入実績値（ＡＣ）を記載する。

-

26 -

表 7-9
進捗状況表の記載項目

（第３編第７章 設計・開発）

記載項目

記載内容

④スケジュール効率指数（ＳＰＩ）

当月までの累計の出来高計画値（ＰＶ）に対する累計の出来高実績
値（ＥＶ）の比率を記載する。
ＳＰＩが１を超えている場合は、スケジュール以上に進んでいることを示し、ＳＰＩが１を下回っている場合は、スケジュール遅延が起きていることを示す。
ＳＰＩが１を下回っている場合は、手順の見直しによるコスト効率の向
上や人員の増加による投入コストの増加によりスケジュール遅延を回復することができる可能性がある。ただし、人員の増加による投入
コストの増加を行った場合は、コスト効率の低下が起きることが多い。

⑤コスト効率指数（ＣＰＩ）

当月までの累計の投入実績値（ＡＣ）に対する累計の出来高実績値（ＥＶ）の比率を記載する。
ＣＰＩが１を超えている場合は、作業効率が高まっていることを示し、ＣＰＩが１を下回っている場合は、作業効率が下がっていることを示す。
ある時点でＣＰＩが１を下回っている場合は、その後の工程で開発手順や開発効率を改善させない限り、完成時において予定コスト内でプロジェクトを終了することは難しいことが多い。

⑥予測総コスト（ＥＡＣ）

当該時点で予測される完了までの総コストを記載する。差異が今までと同様に推移する場合は、計画総コスト（ＢＡＣ）をコスト効率指数（ＣＰＩ）で除算することにより、完了時に予測される総コストについて算定することができる。
ＥＡＣがＢＡＣを超える場合は、計画より多いコストで完了することが見込まれることを示し、ＥＡＣがＢＡＣを下回る場合は、計画より少ないコストで完了することが見込まれることを示す。

⑦残コスト
（ＥＴＣ）

予測総コスト（ＥＡＣ）と投入実績値（ＡＣ）の差を記載する。
ＥＴＣが完了までに投入可能なコストを超える場合は、完了遅延が見込まれることを示す。またコスト差異が今後も発生する場合には、
コスト効率を考慮することも必要である。

(3) ＥＶＭ推移グラフ
ＥＶＭ進捗管理表を集計し、出来高計画値（ＰＶ）、出来高実績値（ＥＶ）及び投入実績
値（ＡＣ）の推移についてのグラフを作成し、予測総コスト（ＥＡＣ）、予測完了時点等を分析します。
本様式は、「(2) 進捗状況表」と合わせて月次の進捗状況の定量分析に用いるものです。次に示す例は、スケジュールが遅れている上にコストも超過し、体制強化や品質向上施策等の対応を至急行うべき状況を表すものです

-

27 -

（第３編第７章 設計・開発）（様式及び記載例）

図 7-8
ＥＶＭ推移グラフ

記載項目

記載内容

①出来高計画値（ＰＶ）

各月の累計出来高計画値（ＰＶ）をグラフ化する。

②出来高実績値（ＥＶ）

各月の累計出来高実績値（ＥＶ）をグラフ化する。
出来高実績値（ＥＶ）と累計出来高計画値（ＰＶ）の差がスケジュール
差異（ＳＶ）となり、グラフ作成時点の作業量前倒し（ＳＶ＞０）／遅延（ＳＶ＜０）を表す。

③投入実績値（ＡＣ）

各月の累計投入実績値（ＡＣ）をグラフ化する。
出来高実績値（ＥＶ）と投入実績値（ＡＣ）の差がコスト差異（ＣＶ）とな
り、グラフ作成時点の計画時点からの作業コストの増加（ＣＶ＜０）／
減少（ＣＶ＞０）を表す。

④予測総コスト（ＥＡＣ）

グラフ作成時点の予測総コストをグラフ化する。
予測総コスト（ＥＡＣ）と計画総コスト（ＢＡＣ）との差が予測総コスト差異（ＶＡＣ）となり、グラフ作成時点の計画時点からの作業総コストの増加／減少を表す。
予測総コスト（ＥＡＣ）と投入実績値（ＡＣ）との差が残コスト（ＥＴＣ）とな
り、グラフ作成時点の作業完了までにかかるコスト見込みを表す。

⑤予測完了時点

グラフ作成時点の予測完了時点をグラフ化する。
予測完了時点と納期の差が納期からの前倒し／遅延の見込みを示す。

(4) 進捗状況分析図
進捗状況表を集計し、スケジュール効率指数（ＳＰＩ）、コスト効率指数(ＣＰＩ)の推移についてのグラフを作成し、スケジュール及びコストの効率の傾向を時系列で分析します。
本様式は、月次の進捗状況の定量分析に用いるものです。次に示す例は、品質悪化が進み、スケジュール変更等の抜本的な見直しが必要な状況を表すものです。

-

28 -

表 7-10
ＥＶＭ推移グラフの記載項目

（第３編第７章 設計・開発）（様式及び記載例）

スケジュール遅延
コストは計画内

計画以上の進捗
コストは計画内

スケジュール遅延
コストは計画超過

計画以上の進捗
コストは計画超過

スケジュール効率指数（ＳＰＩ）
各月のスケジュール効率指数（ＳＰＩ）をグラフ化する。右に行くほどスケジュー
ル効率が高まっていることを示す。
コスト効率指数（ＣＰＩ）
各月のコスト効率指数（ＣＰＩ）をグラフ化する。上に行くほどコスト効率が高まっていることを示す。
上図の例では、7/1 から作業が始まっています。
ところが、9/3 や 9/14 頃には SPI も CPI も１を下回りました。つまり、スケジュール面では計画から遅れ、コスト面でも予定を超過（予定よりもコスト効率が低い）した状態となっています。
その後、10/1 の段階では SPI が 1 に戻りました。つまり、スケジュール面では計画どおりに追いついたということです。一方で、CPI はさらに悪化しています。当初想定以上に要員を投入したのではないかと、読み取ることができます。
(5) ＥＶＭの使い方
ここまで説明したように、ＥＶＭ手法はプロジェクトの進捗度合いを管理していくための有用な手段です。端的に言えば、「進んでいるか遅れているか」をわかりやすく表現することが可能です。ただし、計画に描いたＷＢＳそのものに抜け漏れがあったり、潜在的な課題を見過ごしたりしていれば、ＥＶＭ管理上では問題がなさそうなプロジェクトにおいてもある日
突然進捗が進まなくなることがあります。また、業務関係者の調整とコンセンサスが不十分であれば、開発終盤にどんでん返しのように手戻りが発生する懸念もあります。
こうしたことから、ＰＪＭＯとしてはＥＶＭの指標値を有力な手掛かりとしつつも、継続的にＷＢＳの妥当性や関係者間の業務調整の状況にも気を配っていくことが肝要です。

-

29 -

図 7-9
進捗状況分析図

（第３編第７章 設計・開発）

３

テストの計画を立てる【標準ガイドライン関連箇所：第３編第７章第４節 6)】

情報システムの設計・開発では、品質の管理が重要であり、そのためには十分なテストが必要だ。ということは、よく耳にすると思います。しかし、そもそも「品質の良い情報システム」とは、どういうものでしょうか？また、設計・開発では様々なテストを行いますが、何が違うのでしょうか？
ここでは、効果的なテストを行いながら品質を管理してより良い情報システムを構築していく
ためのテストの計画に関する基本的な考え方、知識、ノウハウをご紹介していきます。

A. Ｖ字モデルと発注者・委託先事業者の役割分担を把握する
現在、ウォーターフォール型の開発プロセスではＶ字モデルが一般的です。開発プロセ
スには各種の国際標準や国内標準もありますが、「標準ガイドライン」の工程定義にのっとると、次のように表現できます。

図 7-10標準ガイドラインの定義に則ったソフトウェア開発プロセスの V 字モデル

直線的に進んでいく工程を、あえてＶ字にしていることには意味があります。同じ高さにある工程が、それぞれ深く関係しています。例えば、総合テストとは基本設計で定めた要件が充足されているかを確認するテストであり、受入テストとは要件定義との充足性を確認するテストということです。
また、工程によって発注者側（ＰＪＭＯ）と委託先事業者の役割は変わりますし、作業の主体も変わります。このことを非常に大雑把に表すと、次のような図となります。

-

30 -

（第３編第７章 設計・開発）

図 7-11
発注者と委託先の関わり度合の変化

多くの人は、図の左側にある要件定義や基本設計は両者で協業して作り上げていく認識を持っています。一方で、図の右側にあるテスト工程については発注者が関与するという認識を持っていないこともあります。
テスト工程において、発注者側にはテスト計画を確認し、テスト実施状況を管理し、テス
ト結果を評価するという重要な役割があります。特に、総合テスト以降の工程終盤になればなるほど発注者側の関与が重要であり、受入テストは発注者自身が実施するものであることを覚えておいてください。

B. テストのレベルや種類を理解する
さて、単体テスト、結合テスト、総合テスト、受入テストの４種類の工程があることを説明しましたが、これらの工程は何が違うのでしょうか。
情報システムのテストは、段階的に進めていきます。個々のプログラムが設計書どおりにできているか？プログラムをつなげて機能としてみたときに、機能の設計を満たしているか？機能同士をつなげてみたときに、要件を満たしているか？要件どおりにできたが、業務が適切に遂行できるか？このように、徐々に確認するレベルを上げていくのです。
これは、まさにＶ字モデルが表していることです。標準ガイドラインで定義しているテスト
工程では、次のように整理しています。

テスト
工程

概要

発注者の関与の仕方

単体テスト

アプリケーションを構成する最小の単位で実施するテストであり、主に機能単位で設計通りに動作するかを事業者（プログラマ）が確認する。

事業者がテストの実施主体ではあるが、発注者もテスト計画を確認した上で、実施状況の報告を求め、報告書に記載されている実施結果に不足、誤り等が発生している場合は、課題等を整理し、指摘
又は指導を行う。

結合テスト

複数の機能を連携させて動作を確認するテストであり、主にユースケース単位で設計通りに動作するかをテスト担
当者が確認する。

（同上）

総合テスト

システム全体が設計の通りに動作す
ることを確認するテストであり、ユース
ケースを組み合わせた一連の業務が行えることを機能面や非機能面の観点からテスト担当者が確認する。

上記に加えて、テストシナリオやテスト評
価方法の妥当性を確認し、過不足を指摘することで抜け漏れの無いテストの内容になるように関与する。

受入テスト

納品されるシステムが要件通りに動作することを確認するテストであり、発注発注者が主体となりテストを実施する。
実際 の利 用者 がテス トに 参加 する こと

-

31 -

表 7-11
テスト工程

注記
ユースケースとは、特定の目的を達成するためにアクタ（ユーザ）が実施する手順等を定義したもの。

（第３編第７章 設計・開発）

テスト
工程

概要

発注者の関与の仕方者が主体となり、事業者と協力して確認する。

で、サービス・業務が円滑に実施できることを確認する。
事前に要件を十分確認できるテストシナ
リオかを確認し、実際にテストシナリオに基づき情報システムを操作し、テスト結果
が要件どおりであることを確認する。

大きな分類は、上記のとおりですが、それぞれのテスト工程の中でも異なる種類のテストを実施します。それらの詳細は、Step.4 で触れていきます。
また、テスト工程とは別に、テスト手法の違いがあります。これらの内容は、事業者がテストの実施方法をＰＪＭＯに説明する際に使用されるため、知識として知っておくと理解しや
すくなります。

テスト
手法
ホワイト
ボックス
テスト

概要
ホワイトボックステストとは、プログラム（ソースコード）の内部構造、論理構造を理解した上でその構造どおりに実装できているかを確認するテストです。中身が見えている状態で行うテストなので、ホワイトボックスと呼んでいます。プログラムを「作る」
人の目線でのテストともいえます。
基本的に、上述のテスト工程のうちホワイトボックステストを実施するのは単体テスト
工程です。
ホワイトボックステストでは、ソースコードがテストされた割合を示す「カバレッジ（網羅率）」が重要な指標となります。しかし、カバレッジには主として３つのレベルがあるので、どのカバレッジレベルを前提としているかについて注意が必要です。
（参考） カバレッジの種類
Ｃ０ 命令網羅率 ： プログラム内の命令文をどの程度網羅したか（単純に、通過したステップ数のカバー率を示す）
Ｃ１ 分岐網羅率 ： プログラム内の分岐をどの程度網羅したか（if 文であれば then と else の両方をカバーしたか）Ｃ２ 条件網羅率 ： プログラム内の条件をどの程度網羅したか（if 文の条件に and や or があれば全ての組み合わせ分）
なお、仕様自体の間違いや機能が備わっていないバグなどはホワイトボックステス
トでは検出できません。また、カバレッジは必ずしも 100%を目指す必要はありません。むしろ、100%に近づくほど等比級数的にコストが増大するので、適切にカバレ
ッジを定める必要があります。

ブラック
ボックス
テスト

ブラックボックステストとは、プログラムの内部構造、論理構造に着目するのではな
く、プログラムの入出力に着目します。つまり、プログラムの外側から見たときに仕様どおりに動作するかを確認するテストです。中身が見えない状態で行うテストなので、ブラックボックスと呼んでいます。プログラムを「使う」人の目線でのテストともいえます。
基本的に、ホワイトボックステストの完了後に、様々な粒度や観点からブラックボック
ステストを実施します。

C. リスクを踏まえてテストの方針を決める
テストの計画を立てる以前に、プロジェクトや情報システムの特性を見極めて、どこに深刻なリスクが存在するかを分析します。
例えば、統計システムと請求支払システムでは端数誤差に対するリスク度合いが異なる

-

32 -

表 7-12
テストの種類（第３編第７章 設計・開発）でしょう。請求支払いシステムでは、１円の誤差でも誤請求として重大な問題になります。このように、リスクを識別することで、初めて機能、性能、セキュリティ、可用性等について当該情報システムがクリアしなければならない重要な要件をあぶり出すことができ、テストを重点的に実施すべき対象を特定できます。
このようなリスク分析は、事業者に丸投げすることはできません。情報システム特性は多様なので、様々な経験・スキル等を持った「人」によってその見え方が異なります。それはデータベースやネットワークという技術要素のことだけでなく、主に過去の障害事例やレアケースを経験しているようなことを指しています。利用者、情報システム運用者、ヘルプデスク等の関係者によって見えてくる風景が異なるので、特に改修案件の場合はこれらの人にヒアリングをして、情報システム特性やリスクを特定してください。

D. テストにおける役割分担と必要な環境を明確にする
他の情報システムと連携を行う場合（特に複数の情報システムがデータを連携する場
合）は、役割分担を具体的に定めることがとても重要です。これらを事前に決めておかないと、いざテストを行う時期になってもめることになり、テストの開始が遅れて十分なテストが行えず、本番稼働を行ってから不具合が多発することにもなりかねません。
他の情報システムと連携を行う場合は、次に示す事柄を計画時点で明確にして、関係者間で合意しましょう。

他情報システム連携に関する計画の注意点
他情報システム連携を確認するテスト（主に総合テスト）の実施主体（誰が音頭を取るか）、各情報システムの窓口となる担当者、計画の作成者を決める。
なお、高度な調整を要する場合は、プロジェクトの対外調整の役目を有するプ
ロジェクト推進管理者が実施することとなる。
どの段階で何を確認するかを明確にする。例えば、結合試験段階では、サン
プルデータを授受し、事前にインタフェースの確認を行う等、段階的に品質を高めていく方法もある。また、連携テストを行う環境の疎通テスト、本番環境の疎通テストはいつ行うか等、環境や観点ごとに漏れなく計画する。
テストデータは、誰がどの範囲のデータを作成するかを決める。基本的には出し元が作成することになるが、どのようなデータのバリエーションのテストが行いたいかは受け側と調整する必要がある点にも注意する。
連携テストはどの環境で行うか。環境ごとの疎通テストの実施有無、実施時期を決める。特に総合テスト以降は、様々なテストが同時並行で行われるため、環境の取決めはしっかり行うことに注意する。

E. テストツールを有効活用する
近年、情報システムの品質を向上させるためのツールは多く登場しています。これらを活用することで、設計・開発の活動を効率的に進めたり、効果的に品質を担保・向上させたりすることができます。事業者とも相談しながら、導入を検討してみてください。

-

33 -

（第３編第７章 設計・開発）

ツールの
種類

概要

メリット

ソースコー
ドの静的
解析ツー
ル

ソースコードから、機械的にコー
ド規模（コード行、スペース行、コ
メント行等）、複雑度、複製度/重複度、正当性、セキュリティ観点からの好ましくない行、パターン等を機械的に抽出するツール。

静的解析ツールは、ソースコードレビュー（インスペクションとも言います）を助け、コード品質の向上、レビューワの負荷軽減、期間短縮に効果を発揮します。
コード特性を可視化することができることから、全体を俯瞰しながら個々の問題や指摘箇所について検討することができます。このため、プログラマはツール結果を見ながら自分で問題点を検討し、修正することもできます。一人では解決できない場合も、レビュー時にレビューワにツール結果を見せることにより、レビューワも問題の特定が容易となり作業負荷の軽減、時間の短縮にもつながります。

自動テスト
ツール

ソフトウェアテストを行うための作業（テストケースの設計、テストの実行と結果の確認、テストの進捗
管理、レポートの作成）又はその一部を自動化するツール。

効率良く自動テストを実行するよう、スケジュー
リングすることで、手動でのテスト工数を削減することが可能です。

継続的イ
ンテグレー
ション

コンパイル・テスト・デプロイといったソフトウェア開発のサイクルを頻繁に繰り返し実行する手法。

短期間で品質管理を行うため、問題の早期発見や開発の効率化が可能です。

タスク管理
ツール

プロジェクト全体のタスクを管理することができ、進捗の見える化や共有化などにより、タスクを管理しやすくするツール。

タスクのツリー構造を定義し、整理することができます。また、タスクの順序や優先度合いを設定し、スケジュール管理をすることができます。
スケジュールや進捗具合を、自動でガントチャートなどのグラフ化で表現でき、直感的に状況を把握することができます。

表 7-13
テストツールF. テスト計画を作成する
前述の A.～E.で検討した内容をテスト計画書にまとめます。テスト計画書は、単体テス
ト、結合テスト等のテスト工程ごとに作成します。
以下にその目次と記載内容の例を示します。
目次
１．はじめに
２．テストの概要

３．テストの実施方針

４．管理方針記載内容
本書の目的と位置付け
テストの目的、概要
対象範囲
テストスケジュール
テストの観点
テスト実施体制、役割分担
テスト実施手順
テスト環境
開始基準、終了基準
使用するテスト自動化ツール
成果物一覧
進捗管理
品質管理
不具合管理

テスト工程別のテスト計画書だけでなく、テスト全体の方針等を定める全体テスト計画書

-

34 -

表 7-14
テスト計画書（テスト工程別）目
次と記載内容（例）（第３編第７章 設計・開発）を作成する場合もあります。
全体テスト計画書は、想定されるリスクや重視すべき要件等を踏まえて、テスト全体を効率的かつ効果的に実施するために作成します。
以下にその目次と記載内容の例を示します。
目次
１．はじめに
２．対象範囲

３．テストの実施方針

４．管理方針記載内容
本書の目的と位置付け対象とするテスト工程
全体スケジュール
対象とするシステム
テストの目的、概要
テストの観点テストの相互関係
テスト環境
開始基準、終了基準
使用するテスト自動化ツール
成果物一覧
進捗管理
品質管理
不具合管理

また、各テストを実施する前に、テスト計画書の内容を踏まえて、テストシナリオ、テスト項
目、使用するテストデータ、合否判定基準等をテスト実施要領にまとめます。なお、ドキュメ
ントの名称は案件によって異なっていても問題はなく、これらの項目を事前に定義していることが重要です。

-

35 -表 7-15
全体テスト計画書 目次と記載内
容（例）（第３編第７章 設計・開発）

Step.

4 設計・開発・テストの管理

設計・開発の実施計画が完成したら、いよいよ設計・開発の作業が始まります。ＰＪＭＯは、事業者との定例会議で進捗状況や課題等を確認していくことになりますが、報告を聞いているだけでは、後々トラブルを招きかねない問題を早期に発見することはできません。
ここでは、問題を早期に発見・対応して品質の良い情報システムを構築していくための知識やノウハウについて説明していきます。

１

設計内容を確認・調整する【標準ガイドライン関連箇所：第３編第７章第５節】

事業者は、設計作業において、要件定義の内容を具体化・詳細化し、設計書を作成します。設計書は、専門的な内容も多く、分量も非常に多くなります。全ての設計書を念入りに確認する時間があればよいですが、なかなかそんな時間は取れないでしょう。しかし、ポイントを押さえて設計書を確認して、必要な指摘や調整を行えば、後々のトラブルを避けて円滑にプ
ロジェクトを運営していくことができます。

A. 基本設計の内容を確実にレビューする
設計書に書かれていることと本来の要件との間にかい離がある場合、その事に気づくのが遅れるほど、修正に要するお金と労力が増えていきます。設計書は、要点を押さえ対象を絞る等の工夫をしながら必ず内容をレビューしましょう。
設計書のレビューは、基本的に「基本設計」で作られた成果物を対象とします。これは、発注者側で用意した要件定義書と事業者の作成する成果物の界面になるからです。基本
設計以降は、基本設計に基づいて詳細設計や実装等が行われるため、それらの整合性を確認するのは基本的に事業者の責任範囲となります。レビューを行う際の観点を以下に示します。

レビューの観点
設計書と要件定義書との整合性、設計書間での整合性が取れているかを確認する。
テスト計画での確認内容と設計書の内容の整合性が取れているか、要件定義で示されている内容がテスト計画で網羅されているかを確認する。

-

36 -

（第３編第７章 設計・開発）

図 7-12
設計レビューの観点イメージ

コラム：忘れがちな突合作業
たくさんの設計会議を経て最終的に設計書を確認するタイミングでは、今まで設計会議で詰めた内容を思い出しながらレビューすることが中心となってしまいがちですが、設計会議で議題にならなかった内容について反映を忘れてしまうことがあります。
当初の要件定義で定めた項目が漏れなく設計書に反映されているか、レビューの大前提として再確認する必要があります。これは、開発等の後工程における要件漏れによる手戻りを防止し、イレギュラーな開発コストの増大を抑えるために極めて重要です。
設計事業者によっては、プロジェクト管理ツール等で要件定義と設計内容の突合作業を実施しているところもあるので、PJMO としてもその内容を必ず確認するようにしましょう。
ツールでなくとも、Excel 等で突合確認することもあります。
実際の突合資料の一部を示します。
下表は RTM(Requirements Traceability Matrix)として整理した例です。下表の左側には要件定義書で記載した項目全てを要件単位で列挙しています。一方右側には作成した設計書案で要件に対応する部分があるかどうかチェックし、要件が正確に反映されていた場合は「反映済」としています。また、要件から変更があったものについては、その変更理由を明確にするとともに、変更することをプロジェクトとして承認したかについても確認します。
このような突合作業を行うと、要件に記載していた事項が設計に反映されていないという「漏れ」に気づくことができます。

-

37 -

コラム 7-1
忘れがちな突合作業

（第３編第７章 設計・開発）

B. 他の情報システムとのデータ連携には細心の注意を払う
情報システムの多くは、他の情報システムとデータ連携を行います。そして、このデータ連携では、高い確率で様々な問題が発生します。以下に、他の情報システムとの連携における代表的な問題を示します。

データ連携における代表的な問題
処理タイミングにずれがあり、データが必要な時点までにデータ連携が間に合わない。
項目、内容、定義にずれがあり、データが連携されても双方でデータ項目に対する認識が異なる。
過去データの扱いに差異があり、最新情報だけが連携されて過去データが連携されない場合がある。履歴データの保持期間が双方で異なる、等。
データ連携は可能であるが、大量データのやり取りに許容範囲を超える処理時間がかかる。
これらの問題を起こさないためには、まずは、他の情報システム側の担当者等との協力体制を築くことが第一です。それを踏まえた上で、次の点に注意して設計・開発を進めていきましょう。

データ連携での問題発生を防ぐために
他の情報システムの担当者や事業者と定期的なコミュニケーションが図れるよ
うに、計画段階で役割を明確化し、情報共有や調整の仕方を定めておく。
データ連携仕様やインタフェース設計については、早期に作成し、関係者と共有し、十分な相互レビューを経て合意する。また、なおこれらの仕様を確定する時期については、重要なマイルストーンとしてスケジュールに組み込み、入念に進捗管理を行う。
既に他の情報システムでデータ連携仕様が決定している場合は、その情報を早い段階で受領する。
他の情報システムとのテストは、早いうちから段階を踏んで実施する。例えば、

-

38 -

（第３編第７章 設計・開発）

データのバリエーション試験は、結合テストの段階で他の情報システムからデータを受領して行う等、工夫する。
また、テストを実施するためには、基本的に本番環境とは別のテスト環境が必要となるので、その準備や調整を早期から行う。

２

品質管理の考え方を理解する【標準ガイドライン関連箇所：第３編第７章第５節】

ＰＪＭＯは、設計が完了した後は、テストを通じて品質を確認していくことがメインになっていきます。テスト工程に応じた品質確認の知識やノウハウは、以降で示していきますが、ここでは、テスト工程全体を通じて大切な品質管理のポイントを説明していきます。

A. 見えない品質を見える状態にする
テストを実施する中では、多くの不具合が発生します。それらの不具合のことを「障害」とし、障害管理を行っていきます。
適切な品質は適切なプロセスによって作り込まれます。信頼度成長曲線は、バグの収束
傾向を見極めるものですが、同時に進捗と品質も見ることで、プロセスも評価します。下図の青の実線は「テストケース残数」、青の点線は「テストケース見込残数」、オレンジの実線
は「障害累計件数」、オレンジの点線は「障害見込件数」、緑の実線は「障害解決累計件数」です。
図 7-13 の青い実線を見ると、きれいな逆Ｓ字カーブでテストケースを順調に消化していたことがわかります。
オレンジの点線（障害見込件数）は、テスト実施前に正確に見積ることは難しいでしょう。
一般的には、単体テストや結合テストではシステム全体での障害摘出（件数／KStep）を過去の経験等から設定し、テスト実施対象のステップ数と掛け合わせることで求めることが多いです。一方、総合テストではテストシナリオ単位で個別の障害見込件数を予測することが難しくなるので、システムの全体規模（KStep）に対して障害見込件数を計算した上で、最終的な収束見込を管理することもあります。

図 7-13
信頼度成長曲線のイメージ

障害累計件数の実績が、計画に対して下振れしていた場合に、考えられることは 2 つあります。1 つは、システムの品質が想定より良いという好ましい状態、もう 1 つは、テストの実
施方法が甘く、十分に障害を摘出できていない状態です。このように両方の解釈が考えられるため、テストの途中段階で計画と実績のかい離に一喜一憂することにはあまり意味がありません。ただし、計画に対して実績が大きくかい離している場合は、テストの実施方法

-

39 -

（第３編第７章 設計・開発）が妥当であるかもう一度検討してみてください。
特に重要なのは、最終的にテストを全件消化したときの障害摘出件数が十分か、そして摘出した障害に対して確実に対応が出来ているかどうかです。信頼度成長曲線では、シス
テム全体での障害件数を合計していますが、一部の機能に障害が残っていても見過ごしてしまう危険性があります。機能単位でどのような障害が発生しているかを評価する方法については、後述します。

図 7-14
信頼度成長曲線（悪い例）

図 7-14 は、最後１週間でテスト消化を駆け込んだように見え、手間が掛かる複雑な条件や異常系テストが不十分な可能性があります。
こういった場合は要注意であると知っておく必要があります。
信頼度成長曲線を見るポイントは、①テストケースがムラなく消化され、②不良が滞留せずに順調に消化され、③終盤には障害累計曲線が寝ている（摘出障害がほとんど増加しない）ことです。

障害原因について、納得ゆくまで説明してもらう発見した障害については、対応状況を確実に追いかけましょう。
対応完了として一度クローズした障害がまた再発することもあるので、障害については一回きりの報告書ではなく、図 7-15 のような継続管理できる一覧表形式とすることが良いでしょう。この一覧表では、障害発生日、環境等に続けて、障害内容、原因（真因）、対応を中心に記述しています。

-

40 -

（第３編第７章 設計・開発）

図 7-15
障害管理一覧表の例（イメージ）「障害原因」については、表層の理由だけでなく、深層の原因（真因）にまで深掘りして調査することが重要です。深掘りしていった結果、アプリケーションの不具合だと思っていた事象が、ＯＳやＤＢ、ミドルウェア、あるいはハードウェア等、異なる領域へ広がっていくことはよくあることです。事業者をまたいで調査することも多く発生しますので、発注者側が対応作業をコントロールし、このような横断調査が円滑に進むように調整することも重要です。
また、必要に応じて、PJMO の職員自身がハードウェアやミドルウェアの製品供給元の会社等から直接に話を聞くことも有益です。障害等の発生原因についてより深い理解を得ることができますし、対応策についても専門的観点から助言を受けることができます。

３

単体テスト・結合テストの品質を評価する【標準ガイドライン関連箇所：第３編第７章第５節】

A. 単体テストの留意点
単体テストは実装（＝コーディング）と一体的に行われるのが実態です。
テスト管理では、過負荷とならないようにマネジメントに留意します。単体テストは開発者が自ら試行錯誤しながら実施するので、不具合件数は過少報告されがちです。その結果、
管理ポイントはむしろ進捗管理であり、品質面ではソース規模とテストケース管理です。不具合報告を正直にあげることには勇気がいるので、くれぐれもそれを非難したりすることのないようにしましょう。
テスト評価では、基本的に単体テストが委託先の責任領域であるため、発注者側が単体テストに対して評価できることは限られています。それでも丸投げとならないよう、①静的解
析ツール、②ソース規模測定ツール、③カバレッジ測定ツールの結果を、メソッドやモジュール単位ではなく、次の結合テストの単位である画面、バッチごとにグルーピングして評価します。また、定量評価の「ゼロ」と「100」も危険です。「バグゼロ」は高品質ではなく、テスト
不十分と考えるべきです。さらにカバレッジ 100％も、通常はソースの中に起こり得ないよう

-

41 -

（第３編第７章 設計・開発）

な異常処理や例外処理などが必ず含まれているので、一旦は疑ってツールの出力結果などエビデンスの提示を求めることをお勧めします。ここで必要なことは、「100％やりました」という字句をそのまま信じることなく、ツールが出力した結果をエビデンスとして確認することです。

単体テストの品質までは、発注者側はチェックできない
単体テストはそもそも、発注者側にとっては把握する必要はありません。それは事業者が掌握すべき事項であり、発注者が認識するのは結合テスト以降が妥当です。発注者側で把握する必要がない理由は、単体テストはプログラマ個人がテストし、かつクラスやメソッ
ド単位で技術的視点に終始しているからです。
さらにアジャイル開発でベストプラクティスとされているテスト駆動開発（テストファースト）では、図 7-16 のようにテストしながらコードを作りこむため、そもそもバグをカウントすること自体が難しくなります。

図 7-16テスト駆動開発（テストファースト）のプロセス

コードカバレッジの確認ポイント
単体テストでは、コードカバレッジの計測が重要視されます。コードカバレッジとは、命令・分岐・条件の網羅率を指す考え方です。ただし、絶対に 100％とする必要は無く、システムの特性と費用対効果を踏まえて、目標カバレッジを設定しましょう。

B. 結合テストの留意点
結合テストは事業者が主体となって実施する工程ですが、発注者もテスト計画、テスト管
理状況、テスト結果等については積極的に確認しましょう。結合テストは、画面単位、ジョブ
単位で機能ごとに結合させてテストします。特にシステム改修の場合は、いきなり画面やジョブに組み込んで「単体テスト」と称する場合があるので、本来やるべき単体テストを飛ばしていないか注意します。一般論として、結合テストの粒度は５～20 個ぐらいの単体モジュー
ルの結合となります。それ以上の単体モジュールを結合テストで一気にテストしようとすると品質評価が難しくなるので、全体規模が大きい場合には次の総合テストの前に「結合テスト２」としてもう一段テスト工程を区切ると良いです。

-

42 -

（第３編第７章 設計・開発）

テスト内容を設計する中では、①正常系だけでなく、②エラー・異常系、③例外的、縮退などの特殊パターンまで含めるようにします。経験上、多くのバグは②エラー・異常系の周辺に偏在しているものです。一方、③例外的、縮退などの特殊パターンはテストが面倒なので、後回しになったり抜け落ちたりしがちなので注視するようにします。また、全ての組み合わせをテストするのではなく、効率的なケース設計を推奨するようにします。これはテスト
工数を削減するためではなく、テスト結果の見落としを防ぐことが目的です。結合テストでは、データベースやファイルへの入出力、ログ出力、暗号化／復号化、同時アクセス・排他制御など、業務目線だけでなくシステム目線の観点についても網羅されているかチェックします。これについてはチェックリストとして整備しておくのが望ましいです。
テスト実施では、始めに結合したモジュール疎通テストを実施後、コンポーネント間のイ
ンタフェースを念入りにテストし、その後、①正常系、②異常系、③特殊パターンの順にテ
ストケースを消化します。
テスト管理では、進捗と品質の両面が重要となる局面なので、信頼度成長曲線で管理することが望ましいです。進捗面では、特に立ち上がり時のケース消化状況と停滞した時の原因を丁寧にヒアリングします。品質面では、「どこに」不具合が偏在しているかと、その箇所に品質強化テストを課す必要があるかを見極めます。「問題なし」というのが一番心配なので、あらかじめ「ワースト順に全体の１割に該当するモジュールは品質強化テストを課す」というようなルールを決めておくと良いでしょう。

結合テストで単体テストと同じことをしてはいけない
単体テストは結合テストの括りで整理し、両方のテスト結果を一覧で比較します。 テスト
ケース数と障害件数のそれぞれについて、単体テストから結合テストへの推移で品質を判断するのがわかりやすいです。図 7-17 で示すテスト品質メトリクス一覧表はテストの種類ごとのテストケース数を示しており、同様のフォーマットで障害件数も記録します。縦軸（サブシステム単位、機能単位）の粒度を揃えることで、横軸の単体テスト、結合テスト、総合テス
トと推移する過程でどこのテストケース数が甘いか、どのレベルで障害が多発しているかがわかります。またこれによってテスト項目密度、障害摘出率をサブシステム間で比較することもできます。

-

43 -（第３編第７章 設計・開発）

図 7-17
テスト品質メトリクス一覧表（テス
トケース数、障害件数）

テスト項目密度と不良密度の確認ポイント
テストの実施状況を機能単位等で詳細に把握するには、それぞれの機能に対するテス
ト項目密度と不良密度を見ます。図 7-18 のように、散布図の形でプロットすると、機能毎のテスト状況を可視化することができます。
テスト項目密度と不良密度の両方が許容範囲に収まっていれば問題ありませんが、テス
ト項目密度が低いもの、不良密度が高いものには注意を払います。図 7-18 の太枠の中に収まっていれば合格です。色のついていない箇所もあまり問題視しませんが、吹き出しのある箇所は念入りにチェックさせる必要があります。ただし、考え方としては、許容範囲から外れたら「不合格」というのではなく、許容範囲に収まっている分には「敢えて説明を求めない」とするのが良いです。例えば、「テスト項目密度・不良密度が下限値を下回っているのは１ＫＬＯＣ未満だから」とか「不良密度が高かったのでテストケースを追加した結果テスト
項目密度も高くなった」とか説明ができれば問題ありません。

図 7-18
テスト密度と不良密度でチェックすべき箇所

なお、不良密度には真逆の解釈が成り立ちます。１つはこの値が低いことを高品質とす

-

44 -

（第３編第７章 設計・開発）

る見方です。もう１つはこの値が低いのはバグが摘出しきれずに潜伏したままだとする見方です。このどちらかの立場から見るかはツールやテスト手法、要員のスキルや組織の成熟度などから総合的に判断するしかないため、上記のようなプロット図を指し示しながら、開発事業者のプロジェクトマネージャや品質管理者からヒアリングするしかありません。
事業者の品質指標は（当然ですが）許容範囲の幅を大きめにしていると考えるべきです。上限値と下限値は、中央値を設定しておおむねそれの±20～25％くらいが適当と考えられますが、全体の 25～75 パーセンタイルに収まるように調整しても問題ありません。テスト項目密度、不良密度とも、単体テストが最も大きく、テスト工程が進むにつれて指標値は小さくなります。
不良密度については、後工程になるほど小さくなります。単体テスト→結合テスト、結合
テスト→総合テストと推移する中で、それぞれ４分の１から５分の１くらいになることが目安の水準といえるでしょう。
最後に重要な点を強調しますが、このような品質管理の指標自体はあくまで目安です。
新規構築時と機能改修時で参考とする指標値は５～10 倍ほど変化することもあります。また、機能改修の場合の母体規模をどのように考えるかは、それぞれのシステム特性もあって一概に言えません。
一番重要なことは、このような指標を発注者自身も確認しながら、気づいた点について
は事業者に確認し、双方で品質を高めていくという活動を継続することです。不具合件数
や不良密度といった定量評価で終わらず、具体的にどういう不具合内容で、その原因は何かを追求します。また、見つかった不具合については、同種の誤りがないか、得られた知見の横展開をどのように行ったかまで、根掘り葉掘り聞いていきます。
できれば、週１回程度のテスト状況報告会議を行い、そこで１週間分の不具合管理一覧表を提出してもらい、その内容について逐次説明を聞くようなやり方が良いでしょう。不具合の内容について発注者側が質問することによって、事業者のプロジェクトマネージャはそれを説明できるように配下のメンバーに質問することとなり、品質改善の PDCA が回り出します。発注者側は、決して「物わかりがいい」ふりをする必要はありません。分からないことは、どんどん質問していきましょう。

４

総合テストの品質を評価する【標準ガイドライン関連箇所：第３編第７章第５節】

A. 総合テストの留意点
総合テストは、システムごとの特性で実施すべき内容も大きく変わります。
総合テストでは、業務観点からのいろいろなシナリオに基づいて機能テストを検証します
が、これに合わせてシステムの性能や信頼性等を検証する非機能テストを行います。非機能テストについては抜け漏れが発生しがちであるため、表 7-14 を参考に確認すべき非機能要件がテストから漏れていないか確認してください。
表 7-16
総合テストの観点とテスト例

観点
機能観点に沿ったテストの例
業務を実施する手順やデータを基に様々なシナリオ・データのバリエーションを作成し、それらを組み合わせに沿って情報システムを用いて業務や機能を確認する。
シナリオ・データには、日常的によく行う業務や取り扱うデータだけではなく、月次や年次等の特定のタイミングでしか発生しないシナリオ
や稀にしか発生しないイレギュラデータも含めて確認する。

-

45 -

注記
パフォーマンステストとは、負荷のかかっていない通常状態で、画面等のレスポンスタイムと、バッチ処理等のスループットを計測するテストのこと。

（第３編第７章 設計・開発）

観点

非
機
能

性能・拡張性

可用性

運用・保守性セキュリティ

移行性

システム環境・
エコロジー

観点に沿ったテストの例
また、正常系だけではなく、異常系のテストも行うことで、ユーザの誤操作や予期しない現象をきっかけとしたシステム障害が起きないことを十分に確認することに留意する。
例）シナリオテスト、業務サイクルテスト等
ユーザ数、データ量、リクエスト数、レスポンス等の性能要件を情報システムが満たしているかを確認する。これらは、現在の想定だけではなく、今後の予想される増加量も含めて、確認する。
例）パフォーマンステスト、等。
処理量や長時間稼働等のシステム限界に関する性能や拡張の要件
を情報システムが満たしているかを確認する。
性能テストや可用性テストと一緒に実施されることもある。
例）負荷テスト（ラッシュテスト、ストレステスト、大容量テスト等）。
ソフトウェア、ハードウェア、ネットワーク等の障害時の振る舞い、復旧
時間、データ復旧ポイント等の可用性要件を情報システムが満たしているかを確認する。
例）可用性（障害）テスト、縮退テスト等。
可用性要件として災害対策が求められる場合、情報システム全体切替えやそれに伴う運用の切替えの手順や実現性を確認する。
例）災害対策テスト等
運用監視、バックアップ、パッチリリース等の運用及び保守を実施す
るために必要な仕組み（ツール・環境等）の確認や、計画停止やリリース等の人手を介する運用業務の手順等を確認する。
例）運用・保守テスト
不正侵入や Web 特有の攻撃、DB サーバへの不正アクセスなどに対する対策、データの持ち出しに対する対策、マルウェア（ウィルス）対策等のセキュリティ要件を情報システムが満たしているか確認する。
例）ペネトレーションテスト、インシデントレスポンステスト、ファジング等。
移行計画に従って、移行ツール、切替えの仕組み、移行手順書等が作成されていることを確認する。
例）移行テスト、移行リハーサル等。
電力消費等のシステムの効率性や設置場所の耐震性等が要件を満たしているかを確認する。他の非機能観点のテストと併せて実施されることが多い。

総合テストの段階はリリースまでの残り日数が少なくなっていて、単体・結合テストと違って数日の遅延が致命的になるので、特に進捗管理には注意を払います。不具合対応による遅延はやむを得ない面もありますが、テスト環境や他システムとの調整など、マネジメント
レベルの抜け漏れはリカバリ不可能なことがあります。

負荷テストには十分な時間を確保する
負荷テスト（ラッシュテスト、ストレステスト、大容量テスト等）やパフォーマンステストには大抵、テストツールを使って、端末からの大量アクセスによる負荷をサーバやネットワーク

注記
ラッシュテストとは、性能要件として想定している最大負荷（同時アクセス数等）に対して、システムの処理能力を確認するテストのこと。
注記
ストレステストとは、性能要件として想定している最大負荷を超える負荷がかかった想定外の状況に対してシステムの挙動を確認するテストのこと。
注記
大容量テストとは、バッチ処理の所要時間やネットワーク性能の十分性等を確認するために想定されている最大容量のデータの送受信等を確認するテストのこと。
注記
縮退テストとは、部分的なハードウェアの故障などに対して、冗長構成への切替えなどが想定どおりに機能することを確認するテス
トのこと。
注記
災害対策テストとは、大規模災
害発生時の対応（マニュアル含む）が的確かを確認するテストのこと。
注記
ペネトレーションテストとは、シス
テムに対して侵入テストを試み、適正にガードされていることを確認するテストのこと。
注記
インシデントレスポンスとは、インシデントが発生したときにどのよ
うなメッセージがあがり、その時の対応（マニュアル含む）が的確かを確認するテストのこと。

等にかけた状態を作り出します。
かける負荷は、ただ大きければよいというものではありません。現実に起きうるケースに近い形となるように負荷のかけかたを計算します。例えば、実際の運用時点で小容量デー
タが多数集中することが想定されるケースで、大容量データ×最大数の負荷をかけることは現実的でありません。ただ、ストレステストについては、このような前提が超えられた時の挙動確認が目的なので、現実に起きうるケースに沿う必要はありません。
このように負荷を事前に計算することにも時間がかかりますが、負荷テストを通すための環境を準備することにも入念な調整が必要です。例えば、本番業務で実施しているネット

-

46 -

注記
ファジングとは、検査対象のソフトウェア製品に「ファズ（英名：fuzz）」と呼ばれる問題を引き起こしそうなデータを大量に送り込
み、その応答や挙動を監視することで脆弱性を検出する検査手法のこと。

（第３編第７章 設計・開発）

ワーク越しに負荷テストを実施してしまうと、他の本番業務に大きく影響が出てしまいます。
とはいえ、本番環境に近い環境で試験しないと意味がありません。そのため、夜間等の影響の少ない時間帯に実施したり、本番環境とほぼ同一のテスト環境を用意したりする等の工夫を行いますが、このようにテスト環境を準備して調整することには時間がかかります。
また、これらのテストは１回で終わるとは想定しないほうが良いでしょう。テストの結果、性能が十分でないことが判明した場合は、システム上で何らかのチューニングを実施した上で、再度同じテストを実施します。場合によっては、何度もチューニングとテストを繰り返すこともあるかもしれません。テスト実施にも十分な時間を確保することが必要です。

機能テストは、データのバリエーションが重要
テスト工程での検証を有意義なものとするためには、検証に用いるデータについて様々な条件を備えたものを用意する必要があります。
まずは、現在動いているシステムが存在する場合は、その本番データにできるだけ近い
データを利用することです。テストケースを考えるときには、それまで検討を重ねてきた要件定義や設計内容がベースになりますが、そもそも要件として認識されていないものが本
番データに含まれている可能性があります。例えば、制度変更時の経過措置で特別に処理したデータや、システム障害や天災に起因したやむを得ない応急措置により例外的で特別なデータが存在することがあります。現行システムで使っている本番データには、このように開発者にとって想定外のデータが存在するので、本番データを使ってテストすることには大きな意味があります。ただし、本番データに含まれる機密性の高い情報は、匿名化等の処理を行うことにも留意してください。
しかし、本番データがあれば十分かというと、実は本番データだけでは万全とはいえません。本番データを使ったテストは、時間とコストがかかるので、せいぜい３～４ヶ月分のデータでしか検証できないからです。そうすると、テストに使う本番データの中には、レアケー
スにより発生するデータが存在していないこともありえます。また、データ移行ミス等により、本来存在するはずのない誤データが潜んでいて、想定外のシステム障害を起こすようなこともあります。
このようなことに対処するためには、本番データを使ったテストだけで安心するのではな
く、それ以外にも例外的なデータが発生することを予期した上で、ブラックボックステストにおけるテストケースをしっかり設定することが重要です。
なお、テスト工程の短期間だけでは検出しにくい障害もあります。例えば、業務運用を継続する中でデータベースのテーブル容量が肥大化していき、そのテーブルを読み取る処
理のレスポンスが悪化し続けるというケースが実際にありました。このようなケースを回避するためには、テスト条件を設定する際に今後のデータ量増加等を見込む等の工夫を行ってください。

B. 発見できた障害は最大限活用する
総合テストでの障害の原因は、基本設計のような上流工程で混入したものが多いはずです。そのため、障害の内容によっては、全モジュールの総点検が必要な事態もあり得ます。障害のきっかけとなった事象がレアケースだからという理由で、パッチワークのような一時しのぎの回避策をとることは危険です。安易に蓋をしてしまったがために、本稼働後に同じ事象をきっかけとする障害が発生するというケースも残念ながら存在します。障害対応を完了としてクローズする際は、慎重に検討するようにしましょう。
回り道に思えるかもしれませんが、たまたま見つかった欠陥を氷山の一角と捉えて積極的に総点検を指示することが、結果的には近道です。
事業者に対しては、類似バグがないかという観点から横展開をしているかを確認しましょ

-

47 -

（第３編第７章 設計・開発）

う。この横展開が形式的なものになってしまわないように、事業者がどの範囲に対してどのように対象を抽出したのかを追検証できるエビデンスを必ず残してもらいましょう。横展開は非常に手間の掛かる作業ですが、たまたま発見された障害を横展開して類似バグを撲滅することは、全てをテストするよりもはるかに効率的で現実的です。
障害管理には、横展開と深掘りの２つのアプローチがあります。総合テスト段階で障害残数が収束していない状況では既知の障害に基づいた「横展開」を優先し、障害残数がコ
ントロール可能な数にまで落ち着いてきてから１件 1 件の事象を「深掘り」した方が良いです。
このように総合テスト段階で障害が発生すると、とにかく面倒くさいが、１つも疎かにせず
障害管理表と向き合って、納得いくまで事業者の説明を求めるべきです。

５

受入テストを実施する【標準ガイドライン関連箇所：第３編第７章第７節】

受入テストは、他のテストと異なり、職員が主体となって行う最終段階のテストです。ここでは、受入テストに関する知識やノウハウを見ていきます。

A. 受入テストと他のテストとの違いを理解する「サービス・業務企画や要件定義で想定したとおりに情報システムができているか？」「構築された情報システムを用いて実際のサービス・業務を正しく実施できるか？」という観点での確認は、事業者ではできません。確認できるのは、職員だけです。これらの業務視点での確認を行うのが、受入テストです。
受入テストに当たっては、次に示す点に注意してください。

受入テストに関する注意点
受入テストの実施期間を十分に確保することが、非常に重要です。設計・開発
工程ではいずれかの工程で遅延が発生することが多く、スケジュール調整の最終手段としてテスト工程を短縮するという方法が選択されがちです。もともと
1 か月間で実施することを予定していた受入テストを 1 週間でやることになってしまうと、受入テストで本来確認すべきことを十分に確認することができません。
あらかじめ受入テストの期間をスケジュールとして確保するとともに、それまでの工程が遅延したとしても受入テストの期間短縮を安易に受け入れないように注意してください。
受入テストを通過すると、基本的に本番リリースに向けた準備が完了したとみなされてしまいます。実際の業務では、正常な処理だけでなく、異常な処理（エラー）も発生しますので、その時になって対処に困らないように、正常系のテストだけでなく、異常系のテストもしっかり実施しましょう。その際、事業者が受入テストの案作成を支援することもありますが、その内容をうのみにするのではなく、業務担当者の目線で内容のチェックをしてください。
受入テストは、職員が主体的にテストを実施する必要があります。その職員とは、ＰＪＭＯの職員だけではありません。システムを実施に利用する業務実施
部門の現場担当者こそ、実業務を一番よく知っています。このような現場担当者を受入テストの実施者として組み込んで、協力を得ることが効果的です。

-

48 -

（第３編第７章 設計・開発）

受入テストに使用したデータが不用意に本番環境に継続されると、システム障
害を引き起こすことがあります。転ばぬ先の杖のつもりで本当に転ばないように気を付けましょう。
受入テストは、総合テストと同様に上流工程の成果を確認するテストです。単にテスト実施者が事業者から発注者に替わるだけで、内容面では似たようなテストとなってしまいがちです。例えば、総合テストで実施したテストケースから「主要な業務」を抜き出し、発注者がその再確認をするだけで終わらせるようなこともあります。あるいは、職員が「モンキーテス
ト」としてその場で思いついた操作をしてみることもありますが、それで何か意味がある（つまり不具合が見つかる）ということはめったにありません。
受入テストは本番運用直前として、できるだけ「①本番データ」、「②本番環境」、「③実際の利用者」、「④実際の運用者」でテストするべきですが、そのためには相当に周到な準備が必要となります。①本番データを使う理由は、開発事業者が想定できていないような「きれいでない」データで試すためです。②本番環境の使用は機器更改のタイミング等でないと現実的ではありませんが、検証環境でテストするよりは、クラウド環境やコンテナ技術が利用できるならそのほうがよいです。③実際の利用者と④実際の運用者でテストすることで、開発事業者が思い付きもしなかったようなケースが出てくるので、異常ではないちょっと「イレギュラーな」実際のケースを思い出しつつテストしてもらうのがよいです。
受入テストでは、プロダクトとしての品質の確からしさより、リリース後の本番準備が十分かを確認しておきます。そこでは、システムマニュアルや業務マニュアルに即してテストする「マニュアルベースドテスト」が有効です。特に、正常時だけでなくエラー・障害やインシ
デントが発生した時、マニュアルの記載どおりで問題ないかは確認しておきます。ここでも、「③実際の利用者」にマニュアル片手でテストしてもらい、ＩＴの専門用語や日本語がおかしくて伝わらないことのないように確認しておきます。
受入テストについては、以下のような工夫をすることで、効率的・効果的なテストを行い、業務視点での品質を高めている事例もあります。

事例：テストの目的と業務シナリオを明確にする
ある省において、既存の情報システムを刷新するプロジェクトがありました。既存の情報システムを構築したプロジェクトでは、ＰＪＭＯの体制が十分でなかったため、受入テストの大部分をプロジェクト管理支援事業者に任せた結果、受入テストの内容が実際の業務シナリオを網羅したものになっておらず、サービス開始後に現場から使いづらさ等の不満が噴出しました。
刷新プロジェクトでは、過去の反省を踏まえて、受入テストにて業務シナリオが現場に即した内容となっているかを網羅的に確認するため、テスト仕様書の内容を次のように分解し、明確に区別して記述するようにしました。
「目的」
テストの目的（＝そのテストで何を確認するのか？）を記述する。
「シナリオ」
業務の実施手順に基づいたシナリオを記述する。基本的な業務のシナリオだけでなく、例外的なシナリオも含めて網羅的に洗い出す。
「シナリオとテスト項目の組合せ」

-

49 -

事例 7-3
テストの目的と業務シナリオを明確にする

（第３編第７章 設計・開発）

シナリオとテスト項目を組合せ、どのシナリオをどのテスト項目で確認するかを明確に記述する。
「テスト項目」
シナリオを細分化し、実施する作業内容、実施条件、確認項目等を記述する。
また、「目的」「シナリオ」はＰＪＭＯが作成し、「シナリオとテスト項目の組合せ」「テスト項目」は、プロジェクト管理支援事業者と分担して作成するルールとすることで、効率的かつ効果的にテスト仕様書を作成できるようにしました。
これらの活動の結果、受入テストにて業務シナリオを網羅的に確認することができ、サービス開始後には、現場で混乱することなく業務を提供することができました。

B. 受入テストのテスト計画書を作成する
この実践ガイドブックには、別添として受入テスト計画書のひな形を示しています。

様式例：受入テスト計画書のひな形
受入テスト計画書のひな形を本章別紙としてまとめています。

あくまでこのひな形は例示です。移行の内容に応じて記載内容を個別に追加、変更してください。ひな形を見ると、何をどのようなレベルで書くべきかの参考になると思います。

-

50 -

様式例 7-2
受入テスト計画書のひな形

（第３編第７章 設計・開発）

Step.

5 見落としがちな活動に注意

設計・開発の活動は、情報システムを構築する作業だけではありません。本番の環境で情報システムを稼働するためには、データの設定、既存サービス・業務や情報システムからの切替え等や運用・保守の作業を行わなければいけません。これらは情報システム自体の設計・開発と同時に検討していくことがとても大切ですが、見落とされがちになってしまうと、後々大変な思いをすることになります。
ここでは、情報システム自体の設計・開発以外に必要な活動についての知識やノウハウについて、紹介していきます。

１

どのプロジェクトでも必ず移行を計画する【標準ガイドライン関連箇所：第３編第７章第８節】

情報システムの移行は、どのようなプロジェクトでも必ず発生します。既存のサービス・業務や情報システムが存在しない場合でも、本番の情報システムの構築、データの設定、切替え、新規業務の開始に関わる業務の変更等は必ず必要です。
ここでは、これらの移行に関するポイントを見ていきます。

A. 移行の種類を理解する「移行」と聞くと、データの移行や情報システムの切替えは思い付くかもしれませんが、移行はそれだけではありません。移行は、大きく分類すると「システム移行」「データ移行」「業務移行」の３種類があります。

移行の種類

概要

システム移行

受入テストが終わったものを本番環境にリリースすることを指す。以下のような観点について検討し、検討結果から発生した必要なプログラムやツールに関して、設計・実装・テストを行う。
検討例
ネットワークやＤＮＳサーバの切替え方式
外部情報システムと連携部分の切替え方式
移行対象となっている設備（Ｈ/Ｗ等）の移行方式
新旧のマスターデータの同期の仕組み
移行失敗時の切り戻し方式
端末又は端末上のソフトウェアの入れ替え方式

データ移行

既存情報システムから新情報システムへデータを適切な形で渡すことを指す。以下の観点について検討し、検討結果から発生した必要なプログラムやツールに関して、設計・実装・テストを行う。
－移行元データ
新規データ作成になるのか、又は現行に元データがあるか？
元データがある場合、どのような形式（ＤＢ、紙、テキスト等）で、どの部分が移行対象となるか？
－実施方法
手作業か又はツール（自動）による方法かどうか？ツールの場合、スクラッチで開発するのか又は既存の製品を利用するのか？
－データ移行処理（マッピング、変換処理、クレンジング）

-

51 -

表 7-17
移行の種類

（第３編第７章 設計・開発）

移行の種類

概要
データ移行を行う際の処理について、以下の観点で検討を行う。
テーブル定義（論理）の項目と移行元データの項目の対応（マッピング）
データ変換やクレンジングなどのデータ処理のロジック

業務移行

各種移行方式を検討した結果を踏まえながら、（所管の）業務や利用者において「移行時に発生する業務」「段階移行/並行稼働中の特殊な作業」について、洗い出しや検討を行う。
検討例：
並行稼働中の業務データの手動保存/移行
アクセスＵＲＬの変更
端末の入れ替え
利用者のログインＩＤ/パスワードの変更 など

特に、業務移行は、ＰＪＭＯが主体となって業務実施部門と調整しながら、進めていく必
要があります。また、業務移行は、事業者が検討するシステム移行やデータ移行の検討結果を踏まえて検討する必要があるため、検討が遅くなりがちですが、サービス・業務に関する新たな制約が後から発覚して、移行作業に大きな影響を与えることも多々あります。
したがって、設計・開発の早い段階から、業務移行も含めて移行の検討を行ってください。

B. リハーサルも考慮した移行計画書を立てる
本番移行は、限られた時間の中での完了が求められ、その結果には正確性が求められます。そのため、手順書を作成して実施に臨みますが、それでも不測の事態が発生することがしばしばあります。このような事態を極力減らし、問題なく本番稼働を迎えるためには、移行手順に則ったリハーサルの実施が必要不可欠です。以下では、リハーサルを行うに当たっての留意点を示します。

リハーサルの留意点
シナリオは本番業務に係る全てを想定して作成する（以下の「シナリオを作る
際の注意点」を参照）。
職員が積極的に関与する。
できる限り本番と同等の環境・本番データを使用する。
時間の測定は必ず行う。
リハーサルの結果から手順等に修正や改善を行う場合、その重要度に応じて、リハーサルで再度検証を行う。
リスクの影響度合い等を踏まえて、切り戻し等の不測の事態に対する対応（＝コンティンジェンシー・プラン）のシナリオもリハーサルで確認する。

-

52 -

（第３編第７章 設計・開発）

図 7-19
シナリオを作る際の注意点

シナリオを作る際の注意点
日々の業務だけでなく、月次、年次、例外時の業務パターンを網羅し、問題なく、かつ迷わず業務が進められるか。
繁忙期の業務量でも想定する作業時間内で実施できるか。
複数の情報システムと連携する場合、連携を含めて想定どおりに業務を進め
られるか。

２

次の運用・保守は開発と並行して検討する【標準ガイドライン関連箇所：第３編第７章第８節】

運用・保守の内容は、運用・保守事業者の調達に間に合うように検討を始めれば大丈夫だ
ろう。そう思っていませんか？
実はそうではありません。運用・保守を考慮せずに情報システムを構築することで、運用・保守に膨大な費用を要する情報システムやサービス・業務の指標値の取得すら困難な情報システムとなってしまうことは少なくありません。
ここでは、そのような状況を引き起こさないためのポイントを見ていきましょう。

A. 指標値を運用作業で取得できるように検討する
情報システムの運用を開始した後には、プロジェクトの目標、ＫＧＩ、ＫＰＩをモニタリング
し、これらを達成できるように継続的な改善を行っていかなければなりません。しかし、情報

-

53 -

（第３編第７章 設計・開発）

システムの設計時には、この観点が抜け落ちてしまうことがよくあります。
継続的な改善を行い、プロジェクト目標を確実に達成するためには、指標値の評価を容易に行えるようにして定期的に確認していくことが必要不可欠です。また、指標値の取得だ
けでなく、分析のためのデータ取得・集計も必要になることも多くあります。設計・開発では、指標値や関連するデータをどのように取得し集計するか？作業にどれくらいの工数がかかるか？を確認し、必要な機能や運用作業を検討してください。

事例：運用作業での指標値の取得に工数がかかってしまう
ある省で行われている業務において、個々の業務の処理時間が長い事が大きな問題となっていました。そこで、その業務で利用する情報システムを更改するプロジ
ェクトでは、処理時間の短縮を目標として、業務ごとの処理時間の指標値を設けました。
プロジェクトでは、対策を検討して業務の見直しを行い、情報システムを刷新する
こととしました。しかし、設計・開発では、業務機能の構築に重点が置かれ、指標の取得方法や運用作業の詳細な検討は不十分な状態でした。
新しい情報システムの運用が始まり、いざ運用作業で指標値の評価のために業務の処理時間のデータ取得・集計を行ってみると、評価のたびに非常に多くの運用作
業工数がかかってしまうことがわかりました。
結局、定期的な指標値評価が必要なことから、さらに新たな予算措置を講じ、データの取得・集計を容易に行うための新しい機能を追加で開発することになってしまいました。

サービス・業務の運営が始まり、モニタリングを行う際に困ることのないよう、設計の段階で以下の内容を確認しておきましょう。

指標に関する確認ポイント
業務要件定義で定めた全ての「管理すべき指標」について、「誰が」「どのように」「どれくらいの工数で」取得できるように設計しているかを事業者に確認する。
取得するデータの形式が定められているか、加工・集計の要否、加工・集計が必要な場合は、誰がやるのか、データはどのように保管するルールとするかを確認する。
運用・保守の作業内容に、各種指標に係るデータの取得が漏れなく含まれているかを確認する。

運用・保守の検討は、実務経験のある担当者と一緒に行う
意外に思うかもしれませんが、情報システムの設計・開発と情報システムの運用では、必要とする技術や知識が大きく異なります。また、設計・開発と運用の両方の経験を十分に持つ技術者は、そう多くはありません。こういった背景もあり、設計・開発を行う事業者が必ずしも良い運用を設計できるとは限りません。
このため、運用・保守計画の案を作成する際は、情報システムの運用・保守管理経験がある職員に参加してもらえるように調整しましょう。運用・保守の管理経験のある担当者から

-

54 -

事例 7-4運用作業での指標値の取得に工数がかかってしまう（第３編第７章 設計・開発）

は、「情報システムを構築するときに、こういう点に注意しておけば良かった」「こういう運用・保守作業を最初から見込んでおけば良かった」という経験やノウハウを聞けるはずです。
もしも、運用・保守経験のある担当者の調整が難しい場合は、ＰＭＯに相談してみてくだ
さい。

B. 運用・保守の計画を立てる
この実践ガイドブックには、別添として運用・保守に係る計画書のひな形を示しています。

様式例：運用計画書、運用実施要領、保守計画書、保守実施要領のひな形
運用計画書、運用実施要領、保守計画書、保守実施要領のひな形を第９章別紙としてまとめています。

あくまでこのひな形は例示です。移行の内容に応じて記載内容を個別に追加、変更して構いません。ひな形を見ると、何をどのようなレベルで書くべきかの参考になると思います。
なお、ここで作成した運用・保守の計画の案は、運用・保守事業者の調達仕様書の付属資料になり、運用・保守事業者の調達後に確定されることとなります。

-

55 -

様式例 7-3
運用計画書、運用実施要領、保守計画書、保守実施要領のひな形

（第３編第７章 設計・開発）

参考：設定と設計は異なる

参考 7-2設定と設計は異なる

情報システムの構築では、ハードウェア、ミドルウェア、アプリケーションのフレームワーク等に対して様々な設定が必要となります。これらの設定には、設定値の決定に十分に検討や調査が必要なものから、他の設計により自明で決まるようなものまで様々な難易度のものがあります。
事業者に見積りを依頼すると、大量の設定に関する設計書が他の設計書の同じよ
うな工数で見積られていることがあります。このような場合は要注意です。たしかに設定に関する設計書は必要ですが、全ての設定に対して機能の設計等と同じだけ工数がかかることは稀です。
このため、見積り精査の際には、設定と設計を区別して、工数を確認するようにしましょう。設定に対する工数割合が大きい場合は、事業者に理由を確認するようにしてください。

３

種類を理解し揃えるマニュアルを厳選する【標準ガイドライン関連箇所：第３編第７章第８節】

サービス・業務を開始するに当たっては、業務実施担当者や利用者向けのマニュアル等の教育資料が必要になります。実は、これらのマニュアルは、利用率、利用者の満足度、業務の浸透度等に大きな影響を与えます。
ここでは、情報システムに係るマニュアルに関する知識やノウハウについて、紹介します。

A. マニュアルの種類を理解する
マニュアルと聞くと、情報システムの操作マニュアルはすぐに思いつくかもしれません
が、ほかにも様々な種類のものがあります。以下に、マニュアルの例を示します。

マニュアル名称

概要

業務マニュアル
業務手順書

業務実施部門の担当者が業務を遂行する上で活用する統一的な手順について詳細に記載されたものであり、人事異動で配属された職員等がこれを読んで理解すれば業務を遂行できるような内容になっている。
したがって、記載内容は情報システムの具体的な操作内容ではなく、また、業務のシーンごとに記載されていることが望ましい。

システム操作マニュア
ル（利用者向け）情報システムにおいて情報入力や帳票出力等、業務遂行時における一連の操作手順が記載されたものである。役割別に分かれる可能性が
ある。

ＦＡＱ

マニュアルを読んでもわからずに利用者からよく来る質問とそれに対する回答を、後から一覧等にまとめて公開している情報 Web サイト。

システム操作マニュアル（管理者向け）情報システムを管理するための機能について、機能及び一連の操作手
順が記載されたものである。

（虎の巻レベルのもの）

情報システムが絡まない場合、統一的な手順が詳細に書かれたものは特になく、部分的な業務遂行ノウハウを記載している。

（ベンダが作るシステ

情報システムの画面単位のマニュアル。業務遂行の観点では書かれて

-

56 -

表 7-18
マニュアルの種類

（第３編第７章 設計・開発）

マニュアル名称

概要

ムマニュアル）

いない。

（ローカルルール）

支所ごとに業務ルールカスタマイズされたもの。

ここで注意してほしいことは、「業務マニュアルとシステム操作マニュアルは異なる」ということです。業務マニュアルは、業務を遂行するために必要となる一連の作業（情報システム
で行う業務以外も含む）の手順やルールを示すのに対して、システム操作マニュアルは、
情報システムの操作に特化した手順やルールを示します。

図 7-20
システムマニュアルと業務マニュ
アルの違い

業務マニュアルは、一般的に職員が作成するものです。業務マニュアルの作成については、実践ガイドブック「第８章 Step.2-2-A.業務マニュアルと他のマニュアルとの違いを理解する」を参照してください。

役に立つシステム操作マニュアルを作成するにはシステム操作マニュアルの作成を事業者に依頼する場合も注意が必要です。事業者に対して、特に詳細を指定せずに「システム操作マニュアルを作成してください」と指示をした
結果、現場になじまないマニュアルが出てきた、ということは少なくありません。事業者にマニュアルの作成を依頼する場合は、サンプル等も活用しながら、作成内容を詳細に指定する必要があります。
また、マニュアルの作成タイミングも気を付けなければいけません。実際にマニュアルを使用する部門が内容を確認しなければ、役に立たないマニュアルになってしまいます。シ
ステム操作マニュアルは、受入テストまでに作成し、それらを受入テスト内で一緒に確認します。
利用者視点のマニュアルを作成するためには、職員側がしっかりチェック（又は作成・修正）する必要があります。マニュアルに係る計画を立てる場合は、これらの点に注意してください。

マニュアル作成に関する検討事項
現場は、どのようなマニュアルを求めているかを、実際に使われているマニュ

-

57 -

（第３編第７章 設計・開発）

アルを踏まえて確認する。使われるマニュアルを作る。
マニュアル作成に関する職員の作業、事業者の作業を明確にする。
マニュアルの作成タイミングに気を付ける。マニュアルはいつ、誰に確認（テスト）されるのか？それまでに、マニュアル作成が完了するように計画する。

-

58 -

（第３編第７章 設計・開発）

Step.

6 新業務の運営を円滑に行うための準備

情報システムのテストが一通り完了し、あとは本番移行を行いサービス・業務を開始するところまで来ました。でも、ちょっと待ってください。本当にそのままサービス・業務を開始して大丈夫でしょうか？
ここでは、サービス・業務を無事に開始し、円滑に運営していくために必要となる設計・開発の活動の締めくくりの作業についてのポイントを見ていきます。

１

本番移行と本番稼働の開始を承認する【標準ガイドライン関連箇所：第３編第７章第８節】

サービス・業務の開始の承認には、本番移行の開始を承認する「移行判定」とサービス・業
務の開始（＝新しい情報システムへの切替え）を承認する「稼働判定」の２段階で行います。
ここでは、移行判定と稼働判定のポイントについて紹介します。

A. 移行判定と稼働判定の違いを理解する
移行判定と稼働判定は、ともに設計・開発の活動の最終盤で行うサービス・業務の開始に係る判定行為ですが、そこで判定する内容や条件等は異なります。次に示す違いの例
を参考に、それぞれの判定において、「いつ」「誰が」「何を判定するために」「どのような条件で」「どのように」判定するかを事前に定めて、関係者と合意しておきましょう。

判定の種類

承認内容の例

タイミングの例

承認条件の例

移行判定

本番移行の開始

受入テス ト、移行リハーサ ル 完了後、本番
移行前

受入テストの完了が承認されている
第三次レビューで妥当と判断される
移行計画書及びリハーサルの結果が適正である

稼働判定

本番稼働の開始
本番移行の完了後又（ 新 し い サ ー ビ ス ・ は完了が確実に見込業務の開始）
まれるとき

本番環境への移行の結果が適正である

その稼働判定でリリースを止められますか
リリース判定と稼働判定には様々なパターンがあります。リリース判定＝稼働判定が最も多いですが、情報システム刷新の場合はリリース判定で次期環境へデプロイ（情報システ
ムの展開・配置）、その後に現行環境を止めて次期環境へデータ移行し、稼働判定会議の結果をもって現行の情報システムから次期情報システムに切り替える場合もあります。同時にデータ移行する場合や先にデータ同期をとっている場合も前者のパターンとなるので、案件によってリリース判定、稼働判定を分けて検討しておきます。

-

59 -

表 7-19
移行判定と稼働判定の違いの例

（第３編第７章 設計・開発）

リリース判定、稼働判定はとかくシャンシャン会議になりがちです。特に、制度改正や機器更改でリリース日が延伸できない場合の判定会議はそのような場となります。そもそもな
ぜ判定会議が必要かと言えば（担当者から管理者への最終判断伺い及び承認行為の意
味合いもありますが）、最後の最後で誤った判断をしないよう発注者側・事業者側双方のプ
ロジェクトマネージャが自ら振り返るためです。発注者側は、状況を正しく認識できるまで事業者に噛み砕いた説明を求めて理解するか、情報システムのことがわかるＰＭＯ・ＰＪＭＯの判断を仰ぐべきです。
そのためには、どういう場合には「ダメ」を出すか、あらかじめ明文化して関係者で共有しておくことが必須です。グループシンク（集団浅慮）に陥らないようにするには、リリース、稼働判定基準は厳密に定めておく必要があります。例えば「重要な障害が未解決でないこと」というのは、厳密な判定基準ではありません。その場合、判定会議直前に残障害の重要度を「軽」にしようとする交渉が巻き起こります。むしろリリース判定、稼働判定の「否認条件」を列挙し、１つでも該当すれば否認することを宣言しておくべきです。
共有する関係者には当然、事業者も含まれています。判定基準をあらかじめ提示し、「ダメ」出しするラインを知らせておくことで、事業者が当然それをクリアした上で判定会議に参加してくることを期待することができます。

情報システムの正しさだけでは不十分
稼働判定は、①開発した情報システムの正しさ、②移行・切替え作業の確からしさ、③稼働後の運用準備状況、の３つの観点が必要となります。ここまでにテストしてきているので①開発システムの正しいのはもちろんですが、それに比べて②移行・切替え作業、③運用
準備は軽んじられる傾向があります。
開発した情報システムの正しさとは「計画した全てのテストケースを消化し、摘出された全ての障害が除去されていること」です。テスト項目密度や不良密度のような品質メトリクス
は「計画した全てのテストケース」の目安の１つにしか過ぎず、それだけで判断してはいけません。「摘出された全ての障害」はまさに字句どおり全て除去すべきで「ワークアラウンド（応急処置）は確立できているので次回リリースまで…」とか「致命的な障害の手当はできているので軽微な障害はこのまま…」というのは許容しないことが必要です。逆からいうと、操作性等の改善事項であって次回リリースに回すことが妥当なものは、障害管理ではなく課
題管理に含めるべきです。
移行・切替え作業の確からしさでは「何も問題ありませんでした」ではなく、きちんとエビ
デンスの提供を求めることが必要です。データ移行についてはレコード件数やハッシュ比
較のような機械チェックで移行結果を検証（特に移行作業が複数拠点の場合）し、その上で移行直後に「本番環境」での疎通テスト程度の確認は完了しておきます。ただし多くの場
合、移行・切替え時には何らかのデータベースのテーブルレイアウト変更が入るので、ツールで現新比較するにはフィルタリングや正規表現等の工夫が必要となります。
運用準備では運用手順書、報告フォーマット、保守連絡先のような運用・保守マニュア
ル類の他、移行直後の切り戻し手順、セキュリティインシデント対応手順、ＢＣＰ等のコンティンジェンシープランの準備を確認しておきます。また、これらのドキュメントに即してテストする「マニュアルベースドテスト」も有効です。正常時の操作・運用だけでなく、エラー・障害・インシデントが発生した際の手順についても確認しておくようにしましょう。さらに案件によっては、エンドユーザあるいはヘルプデスクへの教育・訓練も必要となってきます。特に大規模システム更改などでは、本稼働「直後」に深刻なシステム障害が発生した場合の切り戻し手順が必要でないかを検討しておくことも大切です。

-

60 -

（第３編第７章 設計・開発）

２

正しく引継ぎを行い、トラブルを減らす【標準ガイドライン関連箇所：第３編第７章第９節】

設計・開発に携わった事業者の交代（又は撤退）は、設計・開発の終了時点でやってくるとは限りません。一般的には、設計・開発事業者は情報システムの整備後も運用・保守等で関わることが多いですが、運用・保守の途中で事業者を交代することもあります。このような場合に、設計・開発に関する情報が欠落してしまい、トラブルになることも少なくありません。また、設計・開発の終了や運用・保守が安定したタイミング等で、事業者側の体制の縮小によりキーマンが移動することでも、同じようなことが起こり得ます。
このため、標準ガイドラインでは、設計・開発事業者から運用事業者及び保守事業者への引継ぎを行うように定めています。
引継ぎの際には、成果物についての引継ぎが中心に行われがちですが、絶対に忘れてはいけないのは「課題」の引継ぎです。残存している課題については、保守等を通して今後の対応を検討していかなければいけませんし、既に対処済みの課題であっても、運用作業の制約になっているかもしれません。
課題の引継ぎを求めると、多くの場合は課題一覧が提出されますが、これだけでは不十分な場合があります。課題の一覧には、詳細な経緯、決定事項の理由、課題に係る調査結果
等が完全には含まれていないことが多く、これらを欠落してしまうことで、誤った対応や検討漏れ等を招くこともあります。
したがって、引継ぎに当たっては、課題の一覧を読み合せ等で必ず確認し、経緯の説明や不足する情報を求めるようにしてください。

事例：異なる事業者間で引継ぎをスムーズに行う工夫
設計・開発事業者が作成した運用手順書を用いて運用事業者が運用作業を行う
場合、手順どおりに行ったとしてもうまくいかないことがあります。これは、設計・開発
事業者が作成した運用手順書は、設計・開発時に運用作業を想定して作成されたものであり、実際に稼働している本番環境での運用作業とは異なっていることなどが原因です。
また、運用事業者が運用手順書を作成して運用作業を行っても、やはりうまくいかないことがあります。これは、設計思想などの資料に表れにくい情報があること、設計・開発を行っていない運用事業者が設計の詳細を把握できていないことなどが原因です。
運用段階で、このような問題が生じないよう、スムーズに引継ぎを行うための工夫をご紹介します。
・

設計・開発だけでなく運用作業も調達範囲とするある省庁では設計・開発事業者が自ら作成した運用手順書を用いて１年間の運用作業を行うところまでを調達範囲としています。設計・開発時の想定だけでなく、実際の運用を経て運用手順書を作成することができるため、設計・開発に携わった事
業者が次年度に変更になり引き継いだあとも、作業が円滑に進められるようになります。
・

引継ぎ期間を長く設定する
引継ぎ期間は 1 か月程度を設定するのが一般的ですが、十分ではないケースが多くみられます。
ある省庁では、引継ぎ期間を３か月とり、設計・開発事業者が作成した運用手順書

-

61 -

事例 7-5
異なる事業者間で引継ぎをスムーズに行う工夫（第３編第７章 設計・開発）（案）を、設計・開発事業者と運用事業者が協力してブラッシュアップし、運用手順書を完成させるという旨をそれぞれの調達仕様書に明記しています。そうすることで実際の運用作業中に発見された手順の不備を解消しつつ、設計・開発に関する情報を運用事業者に引き継ぐことができています。
このように、設計・開発事業者を運用の初期段階の実務にも関与させることで、品質の高い手順書が作成され、スムーズな引継ぎができることが期待されます。ただし、事業者間の調整を綿密に行うためには発注者側の負担も相応に増加するので、十分に計画することが重要です。
・

事業者間の協力関係を築きやすくする障害などの問題が発生したときにばかり設計・開発事業者と運用事業者を交えた打合せを行うと、責任の押し付け合いになったり、同席を嫌がったりして円滑に運営できなくなるおそれがあります。
ある省庁では、共通のコミュニケーションツールを導入することで、問題発生時だ
けでなく、平時からコミュニケーションを取りやすい環境を作っています。また、情報システムの円滑な運用を目的とした、設計・開発事業者と運用事業者の双方が出席する会議体を設置するとともに、それを協力して運営することを調達仕様書で求めています。
複数の事業者の協力を得て情報システムを円滑に運用するためには、このように事業者間の協力関係を築く工夫も必要です。

-

62 -

デジタル・ガバメント推進標準ガイドライン

デジタル・ガバメント推進標準ガイドライン
実践ガイドブック（第３編第８章 サービス・業務の運営と改善）-

1 -（第３編第８章 サービス・業務の運営と改善）

目次
Step.1 サービス・業務の運営と改善の流れ ................... 5
Step.2 新しいサービス・業務の事前準備 ..................... 6
１ 運営と改善は、職員主体の作業である ........................................... 6
A. 『サービス・業務の運営と改善』を外部の事業者に丸投げしない 6
B. 『サービス・業務の運営と改善』は他工程の作業と並行で実施する .................................................................................. 8
C. 関連する業務実施部門との責任分担を意識する ...................... 9２ 業務手順書は様々な用途に有効活用できる ................................... 11
A. 業務マニュアルと他のマニュアルとの違いを理解する............ 11
３ リハーサル計画・シナリオは職員目線で ...................................... 12
A. 移行リハーサルを計画・実施する ..................................... 12
B. 業務リハーサルを計画・実施する ..................................... 13
C. サービスの開始や変更を利用者に確実に周知する ................. 14

Step.3 業務の定着と次の備え .................................. 15１ 職員に継続的な教育を行う ....................................................... 15
A. 研修・教育の準備を十分に行う ........................................ 15
B. 研修・教育は１回では定着しない ..................................... 15
２ 定着には利用者への働きかけが必要 ............................................ 16
３ 業務で扱うデータの品質を確保する ............................................ 18
A. 計画どおりにデータを入れないと情報システムの価値はない ... 18
B. 分析しやすいデータ構造でないと、何かするにもカネがかかる 18
４ 業務改善に向け日常業務の事実を蓄積する ................................... 19
A. ＰＪＭＯ・職員が様々な情報を収集し、定常的に管理する ...... 19
B. 情報システムのログ等、運用活動に関わる情報を取得可能にする................................................................................... 20-

2 -（第３編第８章 サービス・業務の運営と改善）

C. 効果測定ができるように、ＫＰＩを自動的に取れるようにしておく ................................................................................ 22
D. 多数のインシデントや要望等の対応の優先度を付ける ........... 23

Step.4 業務の改善 ................................................ 26
１ 日常業務中でも改善できることを理解する ................................... 26
２ 検討の進め方を理解する .......................................................... 27-

3 -（第３編第８章 サービス・業務の運営と改善）

事例一覧
事例：外部委託で業務効率が向上 .......................................................... 7
事例：外部委託でトラブルが発生 .......................................................... 7
事例：利用者からの問合せ窓口が分かりにくくなってしまった例................. 10
事例：利用者への周知が不十分なプロジェクトの顛末 ............................... 13
事例：プロモーション実施・モチベーション向上策の例 ............................ 17
事例：データの信頼性が低いためにシステムが信用されない例 ................... 18
事例：データを出力するだけなのに時間とカネがかかる例 ......................... 18
事例：詳細な調査・分析により運用業務の無駄を削減 ............................... 21
事例：アンケートだけで情報システムの改修要件を定めて 無駄な改修となるおそれがあった例.................................................................................. 24
事例：インシデントの分析結果を利用者へ公開して、利便性を向上 .............. 26-

4 -（第３編第８章 サービス・業務の運営と改善）

Step.

1 サービス・業務の運営と改善の流れ

サービス・業務の運営と改善で行う作業の実施時期や内容をご存知ですか？
サービス・業務を運営することは、職員の皆さんにとって日常的なものであり、イメージが付きやすいと思います。それでは、新しい情報システムを利用することを想定した場合、どのような作業が新たに発生するでしょうか？
ここでは、新しい情報システムを利用するに当たり、準備の段階から利用開始後を含めて、作業を推進していくために必要となる具体的な知識やノウハウについて説明します。
本ドキュメントの構成は、次のとおりです。

Step.2 新しいサービス・業務の事前準備
新しいサービス・業務を始める前に、業務を円滑に進めるために意識しておくべき心構え
や注意すべき点をいくつか説明します。

Step.3 業務の定着と次の備え新しい業務を開始すると、その業務をできるだけ早く現場に定着させ、業務の効率を上げることが求められます。利用者に積極的に使ってもらうための工夫も、定着に向けたカギとなります。
また、データマネジメントの観点を意識しながら、業務で取り扱うデータの品質を維持していかないと、肝心なときに必要な情報が取得できなくなり、業務を効率化できない割に運用・保守コストだけがかかるような、使えない情報システムになりかねません。
それらを意識しながら、日々の業務における様々な情報を把握・分析し、総合的に検討して業務を改善するための進め方について説明します。

Step.4 業務の改善
業務の改善は、日常的に改善できるものと、情報システムや業務そのもの等、時間をかけて見直すものがあります。ここでは、日常的な改善についてポイントを説明します。

-

5 -（第３編第８章 サービス・業務の運営と改善）

Step.

2 新しいサービス・業務の事前準備

今まで行っていたサービスや業務を改め、新しいサービス・業務を開始する前に、理解しておくべき前提知識や心構えについて説明します。

１ 運営と改善は、職員主体の作業である【標準ガイドライン関連箇所：第３編第８章第１節】

新しい情報システムを利用してサービスや業務を実施する際、ＰＪＭＯの職員は情報システ
ムを構築することに意識が行きがちです。一方、利用者にとっては、情報システムが構築直後に「満足な出来」であることは少なく、大なり小なり期待値とのギャップがあります。これを解消するため、利用者からのフィードバックを得ながら、業務と情報システムの双方を改善していく
活動を継続していくことが重要です。
この仕事は、職員が主体となって実施していくこととなります。仮に外部の事業者が極めて優秀かつ良心的であったとしても、やはり業務と情報システムの両輪を相互に調整しながら改善していくマネジメントは、業務を熟知した職員がリードしていくほかありません。
これらの点について、以下に解説していきます。

A. 『サービス・業務の運営と改善』を外部の事業者に丸投げしない
サービス・業務を運営する中では、業務・サービスに関連する日常的なオペレーション
はもちろんのこと、問合せや要望への対応、利用促進のための周知や広報活動等、様々な活動を職員が主体的に実施します。
ただし、一部の作業については、職員が正しく作業を切り出し指示や管理をすることを前提に、外部の事業者に作業を委託できるものがあります。例えば、業務で発生するデー
タの入力業務や、帳票の仕分け業務等です。
では、どのような業務が事業者への委託に向いているでしょうか？一般的には、次の図のような考え方ができるでしょう。

図 8-1
外部委託の向き／不向きの判断
例

-

6 -

（第３編第８章 サービス・業務の運営と改善）

ただ、事業者にサービス・業務を一度委託すると、委託を止めて職員が実施する状態に戻すことは難しくなります。業務実施場所、関連機器等を再度確保する必要がありますし、何より体制を作り直して実際に業務をする職員のスキルを元通りに戻すことに相当の時間がかかるためです。
そのため、外部委託をする場合は、職員による業務実施への回帰や事業者の変更に備え、業務ノウハウが職員にも残るような工夫をすることが重要です。また、事業者に対して適切な指示ができるように、業務概要を理解し、日常的な報告・記録を確保することが重要です。

業務を外部委託する際の注意点
外部委託する業務は、職員が主体的に行う業務に対する支援や補助となる作業であり、それを行うことで職員の業務効率が向上するものであること。
外部委託した業務成果の正誤や品質状況を職員が判断できるように、プロセスの透明化と必要十分な報告・記録を確保すること。
外部委託した業務の実施方法や、事業者が作成する業務マニュアル等の内容を適宜確認し、職員自身も業務の概要を理解し続けること。
特定のサービス・業務について、異なる作業範囲や役割を複数の事業者に外務委託する場合は、緊急時（システム故障やセキュリティインシデント等）に備
えて、できるだけ特定の事業者に業務統制的な役割を定義しておくこと。

事例：外部委託で業務効率が向上

事例 8-1
外部委託で業務効率が向上ある府省では、業務の運営上、日々収集される書類や記録等を、情報システムにデータとして入力する作業が存在していました。この作業は、特別な業務のノウハウが必要ではなく、入力作業の手順さえ守れば、だれでも行
うことができる内容でした。
そのため、職員は入力手順を定めた作業手順書を作成し、このデータ入力業務を外部の事業者に委託することとしました。さらに、作業の実施状況を把握し、作業上の不明点に答えられる管理体制を構築しました。
これにより、外部委託前に比べ、業務の効率を向上させることができました。

事例：外部委託でトラブルが発生ある府省では、新しい情報システムの運営を開始するに当たり、新しく業
務の実施手順をまとめたドキュメント（業務手順書）を作成する必要が発生しました。
そのため、業務手順書の作成を外部の事業者に委託しました。作業するに当たり、新しいサービス・業務の内容が分かるように要件定義書を渡しまし
た。

-

7 -

事例 8-2
外部委託でトラブルが発生

（第３編第８章 サービス・業務の運営と改善）

しばらく後、出来上がった業務手順書を見ると、内容は情報システムの使い方が中心となっており、業務の担当者が意識すべきルールや制約事項等を読み取ることができないものとなっていました。現場の業務担当者からも、利用できないという不満が上がってきました。
結局、業務手順書は改めて、職員が主導で作り直すことになってしまいま
した。

B. 『サービス・業務の運営と改善』は他工程の作業と並行で実施する
次の図（図 8-2）をご覧ください。これは、標準ガイドライン第３編の各章で規定した作業が実際のプロジェクトが９年程度の期間でどう位置づけられるかを表したものであり、第８章の範囲を強調しています。

図 8-2
サービス・業務の運営と改善とその他の工程の関係

これまで紹介してきた、「第４章 サービス・業務企画」から「第７章 設計・開発」までの流
れは、サービス・業務を企画・設計し、必要となる情報システムをどう構築していくか、という作業が中心となっており、この後の章で紹介する、「第９章 運用及び保守」は、新しい情報システムがリリースされた後、どう運用していくか、という作業が中心となっています。
それらを踏まえて、第８章の位置づけを見ると、その全ての期間を通じて作業が発生しています。また、情報システムが構築される前からリリースされた後まで、全ての範囲に関係しています。
第８章で定義した作業と他の工程との関係を、第８章を中心に書いた図で紹介します。
個々の作業の定義は標準ガイドライン解説書を見ていただくとして、ここでは、第８章が１つの作業プロセスとして独立して進められるものではないことを理解しておきましょう。

-

8 -（第３編第８章 サービス・業務の運営と改善）

図 8-3
サービス・業務の運営と改善とその他の工程の関係（詳細）『サービス・業務の運営と改善』作業と他の工程との関係「第８章 １．サービス・業務の運営準備」は、サービス・業務をリリースするまでの準備作業であるため、主に「第７章 設計・開発」で実施される作業と依存関係があり、時間的にも並行で作業を実施します。作業は、「第２章 プロジェクトの管理」や「第４章 サービス・業務企画」の作業の結果を踏まえて行う必要があります。
「第８章 ２．サービス・業務の運営」は、サービス・業務を継続的に運営する作業であるため、主に「第９章 運用及び保守」で実施される作業と依存関係があり、時間的にも並行で作業を実施します。これ以外にも、運営中に発生する課
題や要望を集約し、その対応を判断し、その結果によってその他の章で定義されている作業に振り分けます。（※これはＩＴＩＬが定める問題管理に相当します。）「第８章 ３．サービス・業務の改善」は、他の章で定義された作業とは関係しません。「第８章 ２．サービス・業務の運営」で集約された様々な課題や要望は、その解決のために様々な作業に振り分けられますが、軽微な改善はここで定義された作業で行います。

C. 関連する業務実施部門との責任分担を意識する
複数の組織や情報システムをまたがってサービス・業務を運営する場合は、関連する組
織と、業務の責任範囲を明確にしておく必要があります。これを怠ると、トラブルの発生時に誰がどこまで対応を行い復旧の責任を持つかといった問題がこじれてしまう可能性があるからです。
特に情報システムが関係するトラブルの場合は、発生してから一定時間は、真の原因が不明であったり、本質的な問題解決方法が見いだせなかったりすることがあります。このため、単に責任分界点を定めただけでは「責任の押し付け合い」を招き、解決を遅らせる懸念もあります。
例えば、次の図で示すようなケースを考えてみましょう。１つの情報システムをＡ、Ｂの２つの組織が利用しています。Ａ組織はデータを入力する業務を行っていますが、そこで誤ったデータを入力してしまいました。しかし、そのデータを使うＢ組織は、データの誤りに気

-

9 -

注記
ＩＴＩＬ（Information Technology
Infrastructure Library）とは、1989
年に英国政府のＣＣＴＡによって公表されたＩＴサービスマネジメン
トにおけるベストプラクティスをまとめたもの。2018 年時点ではＶ３である。

（第３編第８章 サービス・業務の運営と改善）

付かず、そのデータを使って業務を実施してしまいました。そして、Ｂ組織で不具合として顕在化してしまいました。
このケースの場合、不具合の責任が A、B のどちらにあるのか、一概には判断することができません。データの正確性を確認する責任が、Ａ、Ｂ、どちらの組織にあったのかが判断のポイントになるでしょう。しかし、あらかじめこのような事態を想定した責任分担を行っていないと、トラブルが発生した後で議論や調整に時間を取られてしまい、速やかな対応がで
きません。

図 8-4
複数の組織が関係するトラブルの例

このような事態を未然に防止するために、サービス・業務の運営を開始する前には、業
務実施分担や責任分担等について、関係する組織と十分に事前調整を行ってください。

事例：利用者からの問合せ窓口が分かりにくくなってしまった例
あるプロジェクトでは、各府省にまたがった業務をワンストップ化するサービスを実現する
ため、各業務の既存システムは残しつつ、利用者視点からワンストップで手続き申請を受け付ける情報システムを構築しました。新しい情報システムは順調に稼働したのですが、利用者からの問合せ窓口については十分に事前調整が行えておらず、既存のコールセン
ターに加えて、新システムのコールセンターを新設する形としていました。

-

10 -

事例 8-3
利用者からの問合せ窓口が分かりにくくなってしまった例

（第３編第８章 サービス・業務の運営と改善）

その結果、利用者からは「どこに問合せしたら良いか分からない」、「コールセンターへ電話したら、違うコールセンターに電話するようにと言われてしまった」など、問合せ方法についての苦情が寄せられてしまいました。
また、各コールセンターにおいても所管外の問合せが数多く発生することになり、問合せ対応の現場が混乱する事態になってしまいました。
業務の役割分担を決める際には、このように利用者からの問合せをどのように受け付け
るかを事前に決定するとともに、利用者に対して問合せ先を分かりやすく周知することが重要です。

２ 業務手順書は様々な用途に有効活用できる【標準ガイドライン関連箇所：第３編第８章第１節】

業務手順書の作成を外部委託しトラブルが発生した事例を前に触れましたが、業務手順
書は、その認識の仕方が人によって異なっていることも多く、同じ名称でも中身が異なることが多くあります。
ここでは、業務手順書を作成することの目的や効果、業務手順書と類似のドキュメントの違い等を説明し、認識を合わせます。

A. 業務マニュアルと他のマニュアルとの違いを理解する
情報システムを用いてサービス・業務を運営するために、様々なマニュアルが存在します。
マニュアルに関する全体的な解説は、実践ガイドブック「第７章 Step.5－3．種類を理解し揃えるマニュアルを厳選する」を参照してください。

業務マニュアル作成時の注意点
業務マニュアルは、同じ業務に携わる担当者が共通の理解を持つために有効ですが、組織や取り扱う情報の種類によっては、同じ業務でも異なるルールが存在する場合があります。いわゆる、ローカルルールと呼ばれるものです。これ

-

11 -

（第３編第８章 サービス・業務の運営と改善）を全て業務マニュアルに記載しようとすると、膨大な量となり、マニュアルの更新が追いつかず、現場とのかい離が発生するおそれがあります。同じ業務内で共通化するものと、組織ごとに個別に定めるものとで分けて業務マニュアルを作成することで、その後の保守性を向上させることができます。

図 8-5
業務マニュアルに載せる範囲

業務マニュアルは、そのまま職員向けの教育資料の一部とすることができます。そのことを念頭に、業務マニュアルの内容・構成を検討してください。
業務マニュアルには、具体的なシステムの操作手順にとらわれず、業務の流れや手順を中心に記述してください。その流れの説明において、情報システムのどの機能を使うのか、がわかれば、使いやすいものになります。情報システ
ムの操作手順や画面説明の詳細はシステムマニュアルに任せることで、マニュアルの品質を上げることができます。
業務マニュアルは業務全体の業務フローを理解している職員が作成、又はレ
ビューしてください。そうすることで、マニュアル上の業務説明が途中で途切れたり、内容の重要性に偏りが出たりすることが防げます。マニュアルが出来上がったら、業務に初めて携わる職員がそのマニュアルを読んで業務が行えるか、という観点でチェックしてください。

３ リハーサル計画・シナリオは職員目線で【標準ガイドライン関連箇所：第３編第８章第１節】

リハーサルとは、新しい情報システムがリリースされる前に、業務の切替え（移行）時の手順
や切替え後の作業内容を職員目線で確認する行為です。業務の切替え（移行）時の確認行
為を移行リハーサル、業務切替え後の作業内容の確認行為を業務リハーサルと呼びます。

A. 移行リハーサルを計画・実施する移行リハーサルでは、現行の業務で使用していた情報を、あらかじめ設計した方法で新しい情報システムに取り込み、想定どおりに動作することを確認します。それに向け、リハーサルの実施計画や実施手順を作成し、計画に基づいて、手順どおりにリハーサルを実施します。
移行リハーサルの計画立案は、情報システム構築事業者に依頼します。ただし、計画上の実施時期や回数、位置づけ等に関するチェックは、ＰＪＭＯが中心になって行います。

-

12 -

（第３編第８章 サービス・業務の運営と改善）

また、移行に際し、気を付けるべきポイント等、職員しか判断できないものについても、Ｐ
ＪＭＯ及び業務実施部門が事前にチェックしてください。チェックの内容には、新しい情報システムに移行する情報について、現行のどの情報をいつのタイミングで抽出するのか。
また、例外的な情報等は、事前に決めたとおりに扱うことになっているか等があります。

B. 業務リハーサルを計画・実施する
業務リハーサルでは、新しい情報システムをリリースした後に、切替え後の業務を円滑に遂行できるよう、職員が主体となって、業務内における職員の役割分担や、情報システムを含む業務の実施手順を確認します。例えば、今までの業務にて担当者間で書類を手渡ししていたような場合、オンライン化によって、誰がどこまで書類のデータをシステムに入力するのか、といった観点の確認や、記載された手順だけで業務が過不足なく実施できることを確認します。
業務リハーサルの手順や実施スケジュールの作成は、業務実施部門の職員が行います。ただし、職員のみで実施が難しい日次処理や月次処理等のバッチ処理の実施タイミン
グの検討や、それらの処理に伴う実施スケジュールの調整、業務リハーサルの実施等については、情報システム構築事業者や工程管理事業者等に支援を依頼して進めます。
業務リハーサルの内容（作業の内容・流れをまとめたもの。シナリオと呼ばれることもある。）は、ＰＪＭＯ及び業務実施部門が中心となってレビューし、過不足が無く、現実的なものかをチェックします。例えば、業務リハーサルを実施する時期と業務の繁忙期との関係や、業務リハーサルを実施する業務実施部門における職員の異動の有無、休日に実施する場合の対象職員の確保等、様々な要素があります。
また、業務リハーサルの実施そのものも、職員が主体となって行うことが重要です。職員が業務リハーサルを実施することで、移行時に発生すると致命的となる問題を発見することができます。これにより､業務ピーク時にも所期の時間内で業務遂行が可能か､移行後の業
務運用において考慮漏れがないか等の検証ができます。

事例：利用者への周知が不十分なプロジェクトの顛末あるプロジェクトでは、業務効率改善のために、業務担当者が今までは情報システ
ムに書類の内容を手入力していた作業を、今後はＯＣＲ（文字認識）ツールを用いて自動読み取りすることで業務担当者の手間を軽減する検討を進めていました。
この情報システムは、構築事業者により順調に改修が進み、機能面についても一部の業務担当者がテストや確認を実施し、問題がないことを確認できました。

-

13 -

事例 8-4
利用者への周知が不十分なプロ
ジェクトの顛末

（第３編第８章 サービス・業務の運営と改善）

しかし、現場を巻き込んだ全面的な業務リハーサルは行いませんでした。情報システム担当が業務担当者の代わりに簡単なリハーサルを行い、業務担当者にはアナウンスのみを行った上で業務の切替えを実施しました。
その結果、リリース直後に業務担当者から、従来の業務の進め方との違いやＯＣＲ
読み取り対象外となる書類の取り扱い等の問い合わせが殺到し、一時的に業務が滞る事態となりました。

その後、業務担当者に対して改めて業務の研修を行い、なんとか混乱を収束する
ことができました。

C. サービスの開始や変更を利用者に確実に周知する
ある日突然、システムの利用方法や画面操作が変更されていると、利用者は戸惑ってしまいます。例えば、事前の告知なく画面に配置された複数のボタンの位置が入れ替わっていると、利用者が使いたい機能を見つけられず不便を感じる可能性があります。さらに、利用者が情報システムの操作に RPA を活用していた場合、RPA が意図した動作を実行できず、業務が滞ってしまう可能性もあります。
リリース直前に連絡しても、十分に周知が間に合わないこともあります。利用者に対しては、計画的にサービスの開始や変更内容を伝えるように留意してください。

-

14 -

（第３編第８章 サービス・業務の運営と改善）

Step.

3 業務の定着と次の備え

新しい情報システムがリリースされると、サービス・業務の運営が始まります。新しいサービ
ス・業務が今までのものと違いがあればあるほど、リリース直後からしばらくの間は様々な問題が発生するかもしれません。業務に関わる職員は、できるだけ早く業務を現場に定着させようと悪戦苦闘しますが、それ以外にも、より良いサービス・業務となるような活動を併せて行う必要があります。

１ 職員に継続的な教育を行う【標準ガイドライン関連箇所：第３編第８章第２節】

ＰＪＭＯは、情報システムの設計・開発のリリースが近づいたところで、それまで準備した研
修教育資料を用いて、実業務を担当する職員に対して教育を実施します。
それではどのような点に注意して進めて行けばよいか、見て行きましょう。

A. 研修・教育の準備を十分に行う
ＰＪＭＯは、研修資料として、ＰＪＭＯ主導で作成した業務マニュアルや、事業者主導で作成した情報システムの操作マニュアル、それらをまとめた研修用資料等を準備します。
また、可能であれば、デモ環境や研修環境なども用意し、情報システムを実際に触ることができる環境を提供することも効果的です。
府省内の広範囲の職員が利用する情報システムにおいては、ＰＪＭＯやヘルプデスクを担当する事業者も、研修・教育の準備期間中に、一般職員と同じ研修を受講しておくことが望まれます。これにより、研修カリキュラムの改善につながることはもちろん、利用者からの問い合わせに的確に対応できるようになります。
情報システム構築の作業進捗状が遅延すると、研修や教育の回数制限、期間の短縮
や、現場担当者が新しい情報システムに触れられる環境の準備が遅れる可能性が出てきます。ＰＪＭＯは研修や教育に最低限必要な期間は必ず確保できるように、構築事業者の進捗管理をチェックし、安易な計画変更を起こさないようにしてください。

B. 研修・教育は１回では定着しない
通常、新しい情報システムのリリース前に行う教育は、開発実施計画を立てる時点でしっ
かり盛り込まれていれば、作業が抜け漏れることなく実施できます。
ただし、この研修や教育は、どのぐらいの頻度で実施すればよいのでしょうか？計画を立てる際に気にしておくべき注意点を以下に挙げます。

現場への研修・教育を計画する際の注意点
大規模システムの場合、全国各地に業務担当者が散らばっていることが多く、実施回数が少ないとそのタイミングで教育を受けられない担当者が発生する可能性が出てくる。
研修・教育の回数が制限されていると、情報システムリリース後、新しく人事異

-

15 -

（第３編第８章 サービス・業務の運営と改善）動で配属された職員が、正しい情報を把握することができなくなる。
教育資料や教育の内容が不十分な場合、そのまま同じように全職員に情報が伝達されても、全体のレベルが上がらない。
この懸念点を払拭するには、次の対策をとることが効果的です。

懸念点への対策研修を実施した後、受講者にアンケートを配布し、研修の内容・難易度に関する意見をもらい、それを基に研修のカリキュラムや資料の内容を見直す。
研修に用いた教材を関係者が閲覧できるようにする、電子ファイルをダウンロードできるようにするなど、研修に出られない人にも研修の内容が伝わるように工夫する。
研修そのものを撮影し、オンラインにてストリーミング配信できるようにする、Ｄ
ＶＤに焼いて配布する等の対策を検討する。

図 8-6
研修・教育の定着化に向けた取り組み

２ 定着には利用者への働きかけが必要【標準ガイドライン関連箇所：第３編第８章第２節】

新しいサービス・業務は、利用者に使ってもらい初めて価値が生じます。
ただし、適切な説明がなされないと、利用者は新しいサービス・業務に気が付かずに、従来どおりの振る舞いをしてしまい、せっかく構築した情報システムも宝の持ち腐れになりかねません。
したがって、ＰＪＭＯは、利用者には新しいサービス・業務の提供を始めたことを周知するプ
ロモーション活動及び新しいサービスを使いたいという気持ちになってもらうために、利用者

-

16 -

（第３編第８章 サービス・業務の運営と改善）のモチベーションを向上させる活動を行う必要があります。
次にあげる事例は、利用者のモチベーション向上を行ったプロジェクトの例です。

事例：プロモーション実施・モチベーション向上策の例【プロモーションの未実施が招いたサービスの利用率低下】ある省では、新しいサービスを国民向けに提供できるように情報システムの整備を進めましたが、サービスの周知はリリース直前のプレス発表のみであったため、利用者がサービスの存在を認識するに至らず、利用率が伸び悩んでいました。
そのため、プロモーションの実施を検討することになったものの、当初に予算措置をしていなかったため、すぐには効果的な対策を打つことができず、サービスの利用率が向上するまでに時間がかかってしまいました。
【報奨金・補助金を活用した利用者拡大の成功例】
一方で、ある省で提供する電子サービスでは、電子申請を実現するに当たり、電子申請を利用するために利用者が IC カードリーダーを購入する必要があったた
め、そのための費用を賄えるように、利用者に金銭的なメリットが発生するように制度自体を再設計しました。
さらに、キャッシュレスサービスの推進において利用者へのポイント還元などの施策を展開した事例もあります。
このように、新サービスの利用率を高めるために利用者のメリットを積極的に訴求する施策も効果的です。

利用者への伝達方法としては、利用者向け Web サイトでのアナウンスや、窓口に来た利用者に対して窓口職員が新しいサービス・業務のメリットを説明する等があります。いずれの場合も、利用者にとって、どんな価値向上があるのかを正しく説明することが大切です。併せて、業務担当者に対しても自分達にどのようなメリットがあるのか、理解してもらうことも重要です。
また、中長期視点では本質的に価値が向上するとしても、新しいやり方への抵抗から移行してもらえないこともあります。そういったときは、事務効率化に見合った利用料の低減や入力支援機能の充実等により直接的な利用者への利益提供を行うことで利用率を向上させ、定着を推進しましょう。

利用者のモチベーションを向上させるための工夫例
窓口より申請時間や申請期間を長くする（土日や夜間等）。
手書きでの申請よりも記入（入力）項目を減らす。（例えば、郵便番号から住所の一部を自動入力できる機能を付ける等。）
前年の申請データを再利用できるようにして、入力の手間を減らす。
キャッシュレス決済に必要な機器の導入費用を国及び決済事業者で負担することで店舗の費用負担を無くした。

-

17 -

事例 8-5
プロモーション実施・モチベーション向上策の例

（第３編第８章 サービス・業務の運営と改善）

３ 業務で扱うデータの品質を確保する【標準ガイドライン関連箇所：第３編第８章第２節】

データマネジメントとは、データをサービスや業務の効率化、高度化のために活用できる状
態で維持し、継続的に改善していく組織的活動を指します。
データマネジメントの不足は、様々な問題を引き起こす可能性があります。
ここでは、そういった問題の発生例をいくつか見て行きましょう。

A. 計画どおりにデータを入れないと情報システムの価値はない

事例：データの信頼性が低いためにシステムが信用されない例

注記「行政におけるデータマネジメント
実践に関する調査研究」報告書
及び「行政機関向けデータマネジ
メント導入ハンドブック」
https://www.iais.or.jp/reports/lab
report/20171201/datamanageme
nt2017/

事例 8-6
データの信頼性が低いためにシステムが信用されない例ある省で、過去の契約実績をデータベース化し、今後の調達を検討する上での基礎情報とするための情報システム整備を実施することになりました。
情報システムの構築は問題なく進み、予定どおり現場にリリースされ運用が開始されました。
ある程度運用後、データを点検したところ、基礎情報として取るべき項目が任意入力項目となっており、異なる部署のデータが並列で比較できないことが分かり、目的としていた省内で共通利用可能な契約実績データとはなっていなことが分かりました。
また、項目は決まっていたものの、職員によって入力するデータの精度が不明確
で、同じ意味ではあるものの、同列に扱えないデータがデータベースに蓄積されていました。
そのため、情報システムが保持すべきデータ項目やデータの構造について、再度見直しのための改修を行うことになりました。

上記のような事例を引き起こす原因は、情報システムの機能的な問題だけではなく、情報システムの中身であるデータの品質にも問題がある場合があります。データ品質が悪く、利用者の目的に沿った分析や活用ができないと、利用者からのシステム離れが発生します。
この状態を改善していくためには、情報システムを構築したからといって、自ずと活用目的に足る品質の高いデータが入ってくる訳ではない事実を認識し、目的に沿ったデータ品
質を維持していく持続的な活動と組織的に利活用を定着化させていくための推進キャンペーンの企画・実行や説明会・ユーザーサポートなどの継続的な活動に取り組むことが必要となります。

B. 分析しやすいデータ構造でないと、何かするにもカネがかかる

事例 8-7

事例：データを出力するだけなのに時間とカネがかかる例

データを出力するだけなのに時間とカネがかかる例

ある省で、業務で利用している情報システムに蓄積されたデータを基に、業務分

-

18 -

（第３編第８章 サービス・業務の運営と改善）析を実施することになりました。
データを取り出す機能が無かったため、保守事業者にデータの出力を依頼したところ、想定を超える費用と作業期間を提示されました。
見積りの根拠を確認したところ、もともとやりたいと考えている業務分析ができるようなデータの構造をしておらず、それを達成するには様々なデータの変換を含むプログラムの開発が必要との回答を受けました。

上記のような事例を引き起こす原因は、データとアプリケーションが適切に分離されていないという情報システムの構造的な問題であると同時に、データの状態遷移や静的・動的
データの取り扱いなどを適切に定義できていないという、“データ”アーキテクチャの問題に起因していることが少なくありません。
既存の大規模システムにおけるアーキテクチャの抜本的な見直しなどはそう簡単には解決できない重いテーマですが、システム更改等のタイミングで、データの構造と振る舞いに着目し、見直しを図ることが解決策の第一歩となります。

４ 業務改善に向け日常業務の事実を蓄積する【標準ガイドライン関連箇所：第３編第８章第２節】

業務の改善は、業務を運営しながら継続的に実施する必要がありますが、事実を正しく把握した上で問題点を抽出し、解決案を考えた上で適用を行わないと、効果的な改善につながりません。
運用当初は問題が無くても、時間の経過とともに利用者のニーズの変化に業務・システムが対応できなくなったり、当初想定していた業務量の予測が大幅に上回ったり（又は下回ったり）する等の事象が発生します。
これらをしっかり把握し、効果的な改善を行う上で注意すべき点をみて行きましょう。

A. ＰＪＭＯ・職員が様々な情報を収集し、定常的に管理する業務を運用している間、ＰＪＭＯには日々様々な情報が集まってきます。この情報には、利用者からの問い合わせや要望、運用・保守事業者から報告される突発的に発生した障害、定常的な監視活動から取得した情報（インシデント記録含む）があります。
これらの情報からは、情報システムが安定稼働しているかどうかを判断することになりま
すが、少し視点を変えて、情報システムの改善余地を探す手掛かりとしても見てみましょう。
例えば、利用者のサービス利用状況等から、利用者の動向を把握し、窓口への訪問やＷｅｂサイトの利用時間帯に対する人数の偏りを把握することで、サービス改善のきっかけをつかむこともできます。
また、大きなプロジェクトでは、専用のコールセンターや問い合わせ窓口から、小さなプ
ロジェクトでは、ＰＪＭＯに直接行われる問い合わせ等からも、利用者の動向やニーズを把握することもできます。
これらは、事業者がまとめた２次資料だけでなく、ＰＪＭＯがそれぞれの内容を具体的に把握し、理解することも重要です。特別なアンケートを改めて取らなくても、既に集まっている情報の分析や追加調査で、サービス・業務にどういった問題・ニーズがあるのかを把握することができます。

-

19 -

（第３編第８章 サービス・業務の運営と改善）

図 8-7
ＰＪＭＯに集まる情報の把握・理解把握した結果に応じて、様々な対応策を考えてみましょう。全てが業務の変更や情報シ
ステムの改修で対応するのが最善とは限りません。例えば、問い合わせが多いものは、ＦＡ
Ｑやマニュアルの改訂等で対応できるかもしれませんし、毎年発生する恒常的な業務イベ
ントについては、過去の事例を参考にして事前に関係者にアナウンスすることで改善するかもしれません。

B. 情報システムのログ等、運用活動に関わる情報を取得可能にする
前出のとおり、業務運営中の情報把握は重要ですが、どうやって情報を集めるのが良いでしょうか？
業務運営中に発生する業務・情報システムに関連する情報は数多くあるため、これらを活用しやすくするためには、可能な限り自動的に情報を取得できる仕組みを作っておきましょう。
対象とする情報源の一つは、情報システムのログやトランザクションデータです。これらのデータから、情報システム利用者の特性やアクセス頻度、滞留時間や入力エラーの発生状況等を把握・分析し、サービス改善に向けた検討材料として、ユーザの動向やニーズ
が、データの積み上げ・根拠に基づいて導き出すことができます。

-

20 -

注記
ログとは、情報システムを利用する際に自動的に作成される動作の記録データであり、トランザクションデータとは、情報システムで日々蓄積される業務に係るデー
タ（○○申請データ、××決裁結果、等）。

（第３編第８章 サービス・業務の運営と改善）

図 8-8
ログ等から特性等を把握

また、データが自動的に取得できない場合でも、様々な活動の記録はデータとして保存
し、後で調査・分析ができるよう復元可能にしておくことも有効です。
そのような場合の具体的な事例として、以下をご紹介します。

事例：詳細な調査・分析により運用業務の無駄を削減ある省で、運用中の情報システムについて、運用作業の一つである設定変更作業
が依頼から実施されるまで時間がかかることが課題として取り上げられました。
原因を特定するため、一連の作業フローを可視化しました。
その結果、依頼を受けた担当者が、依頼に基づいた設定書を作成した後、チームリーダーによるレビューを受け、最終的に会議体において再度レビューされ、承認されるまでの作業の流れが確認できました。レビューには、チェックリストを用いていることも把握できました。

-

21 -

事例 8-8
詳細な調査・分析により運用業務の無駄を削減（第３編第８章 サービス・業務の運営と改善）より詳細な分析を行うため、次の２点の観点で調査を勧めました。
１． 作業時間や作業着手までの滞留時間を詳細化する。
２． レビュー内容（チェックリスト）の内容を確認する。
１． では、関係者へのヒアリングだけではなく、作業の申請・承認をやり取りしていたメールの送受信履歴を取り寄せ、分析を行いました。
２． では、チェックリストを取り寄せ、項目レベルで内容の把握を行いました。
その結果、一連の作業の流れで一番時間がかかっているところは、会議体での承認待ち時間であること、チームリーダーが使うチェックリストと会議体が使うチェックリ
ストの項目が 30%程度同じものであること、が分かりました。
これらの分析結果を基に、チェックリストの項目が重複しないように見直し、会議体の開催頻度を週２日からチームリーダーチェック後の翌日に実施できるようにしました。
これにより、設定作業に要する時間を大幅に短縮することが達成できました。

C. 効果測定ができるように、ＫＰＩを自動的に取れるようにしておく
前で述べたとおり、分析には様々な情報を収集する必要があります。情報システム構築
後に必要なデータを手作業で集める労力を減らすためには、どういった情報を日頃蓄積しておくべきかを、サービス・業務企画から要件定義の間に検討し、情報システムの運用上必要な機能として盛り込んでおく必要もあります。まだ、それらの機能がない現行の情報シ
ステムに対しても、同じ観点で情報が取得できないかは、現行の情報システム事業者に、運用保守の一つとしてデータを取得できないか、相談してみてください。
また、集めるべき情報は、プロジェクト計画時に検討したＫＧＩやＫＰＩを意識すると特定できるものもあります。ＫＰＩを把握するために必要な情報は、１つとは限りません。そのことを踏まえて、収集すべき値を設定しましょう。自動化ができると、モニタリングも容易に行うことができます。

-

22 -（第３編第８章 サービス・業務の運営と改善）

サービス・業務企画や要件定義の段階で、どのような値が必要となるかを限定することは困難です。実践ガイドブック「第９章 Step.2-2-A.参考 9-1」等に記載された指標例を基に、取得できそうな値、取得したら意味がありそうな値は取得対象とし、あとで容易に取り出せるように機能化を検討してください。これは、検討範囲外の値を後から取得しようとすると、最悪の場合、改修などの追加コストが発生するおそれがあるためです。
なお、行政評価等では、評価指標を表す言葉として『アウトカム』や『アウトプット』があります。これらとＫＧＩ／ＫＰＩとの関係は以下のとおりです。

アウトカム/アウトプットとＫＧＩ／ＫＰＩの関係
ＫＧＩ ＝ アウトカム
ＫＰＩ ＝ アウトプット
したがって、サービス・業務の目標・目的（ＫＧＩ・アウトカム）の達成状況は、実際に数値として捉えることができるＫＰＩ・アウトプットを測定して、判断することになります。

D. 多数のインシデントや要望等の対応の優先度を付ける
業務に関する問い合わせやインシデント、要望等を取りまとめていくと、膨大な量になり、全てを対応するのは時間もコストも足りません。そのため、それぞれを整理した上で、優先度をつけて、優先度の高いものから対応していく必要があります。
優先度は、業務遂行上で重要かどうかを判断してつけてください。例えば、画面を複数切り替えないと関連する情報が確認できず件数が多くて作業が非効率ということであれ
ば、情報システムの改善による業務の効率化を検討すべきかもしれませんが、単純に画面レイアウトや操作性等についての要望は、個人の好みに依存することが多く、改善効果は見込めません。また、利用者側が業務を遂行できない、又は多大な事務作業が発生する
不具合に対応できないような場合は、そもそも情報システムの利用を推奨するべきではな
く、業務の見直しも含めた検討が必要になります。
インシデントの優先順については、過去のインシデント分析にて、起こっている問題を詳細に分析することで、クリティカルな部分を優先して対策することが効果的です。インシデ
ント分析としては、一部をサンプリングして全体を理解するのではなく、全数を調査・分析して全体を捉えることが重要です。サンプリングして行う調査・分析は、コストをかけず実行することができますが、サンプリングから漏れる少数の事実が全体に影響を与える場合がある
からです。

-

23 -

注記
インシデントとは、正常なサービス提供を阻害する事象を指す。代表的なものにセキュリティインシ
デントがあるが、利用者の経験不足から発生した操作ミスなどもイ
ンシデントに含まれる。

（第３編第８章 サービス・業務の運営と改善）

図 8-9
インシデント悉皆分析

優先度をつけた結果、対応できないと判断する要望については、ＰＪＭＯ側の都合ではなく、当該業務のステークホルダー（国民、利用者側、法令の主旨等）の立場で納得がいく
ような、代替案や不採用となった理由を説明できるようにしてください。また、不採用とした
要望については、今後の対応予定があるのか、基本的に対応予定がないかといったステータスを明確にしましょう。

事例：アンケートだけで情報システムの改修要件を定めて無駄な改修となるおそれがあった例ある省で、複数の組織で利用される情報システムについて、要望に基づき改修の検討に着手しました。要望はアンケート形式で集計したものであり、金額計算に関わる同じ機能に対しての改修要望が多く、改修対象としました。

改修された機能をリリースしたところ、複数の組織から問題点を指摘されました。詳細を聞くと、組織ごとに金額計算時の端数処理のルールが異なり、同じロジックでは対応できないことが分かりました。

-

24 -

事例 8-9
アンケートだけで情報システムの改修要件を定めて無駄な改修となるおそれがあった例

（第３編第８章 サービス・業務の運営と改善）

ＰＪＭＯは、当初それぞれの組織に対応すべく、機能改修を検討しようとしましたが、一旦作業をストップし、対処案を検討することにしました。
その結果、組織ごとにばらばらなローカルルールを無くすよう、制度改正を行うこととし、情報システムへの改修は行わずに対処を終えることができました。

-

25 -

（第３編第８章 サービス・業務の運営と改善）

Step.

4 業務の改善

業務の改善を進める中で、日常的な改善と、情報システムや業務そのものを見直す場合とがあります。ここでは、日常業務で改善できるポイントを説明します。

１ 日常業務中でも改善できることを理解する【標準ガイドライン関連箇所：第３編第８章第３節】

第８章の活動では、サービス・業務を運営していく中で発生する様々な情報を集め、改善に向けた取り組みに繋げていくことを紹介しました。
その結果、情報システムの見直しが必要なものは、第４章「サービス・業務企画」に立ち戻
り、運用保守の見直しが必要なものは第９章「運用及び保守」に立ち戻ります。
改善として、これに該当しないものは、日常的な改善として対応していく必要があります。それらは具体的には次のようなものに該当します。

日常的に実施する改善事項の例
業務の見直しは、情報システムに影響を与えない範囲であれば、日常的に実施可能なものです。特に、定期的な改善を検討し、その結果は業務手順書などに反映させましょう。
教育・訓練の見直しは、具体的には教育資料の改訂やカリキュラムの改訂に相当します。現状の分析結果を踏まえて、より職員に遡及できるような教育内
容に作り替えを行ってください。
モニタリングの見直しは、日常的に把握すべき指標とその仕組みの見直しに相当します。前出のとおり、ＫＰＩで取るべき指標値は、業務の状況に応じて変更しても構いませんので、それに応じて値の取得方法や内容を見直し、現状を正確に把握できるようにしましょう。
そのほか、利用者からの問い合わせが多い機能や操作等については、マニュアルの改善やＦＡＱに情報を追加・更新することで改善が図れますので、適宜改善を検討してください。

事例：インシデントの分析結果を利用者へ公開して、利便性を向上あるプロジェクトでは、多くの職員が利用する内部事務向けの情報システムを運用していました。
数年間にわたってこの情報システムを運用する中では、利用者から様々な問い合
わせを受けたり、システムの不具合や誤操作等による多種多様なインシデントが発生したりします。それぞれの問い合わせやインシデントについては一次的な対応は完了しているのですが、人事異動等で利用者が変わると、また同じ問い合わせが発生することもありました。

-

26 -

事例 8-10
インシデントの分析結果を利用者へ公開して、利便性を向上

（第３編第８章 サービス・業務の運営と改善）

そこで、今までに蓄積した問い合わせを再分析してみました。すると、この内部事務は特定の時期に特定の業務処理を行うという定期的なイベントが多いこともあり、問い合わせの発生傾向に季節特性が見えました。
このことを受けて、１～２か月に１回程度の頻度で、利用者向けにメールマガジンを発行することとしました。そして、そのメールマガジンの中で、その時期に実施する業務処理や、過去に多く発生したインシデントを紹介しました。また、メールマガジンの内容や体裁についても、どのようにしたら多くの利用者に参照してもらえるかを第一義に考え、アクセシビリティ等の観点から随時改善を行っていきました。
さらに、インシデントを分析した結果を、利用者向けに公開することとしました。それまでも、よくある質問についてはＦＡＱとして Web サイトで公開していたのですが、ここにインシデントとして分析した内容についても掲載することとしたのです。従前のＦＡＱの掲載件数は 1,000 件程度でしたが、段階的にインシデントの掲載を増やしていき、１年後には約 7,000 件にまで掲載件数が増えました。また、FAQ の Weｂサイト
自体についても、多量の情報から目的の情報を探しやすくするため、検索の利便性の向上等の工夫を行いました。このような取り組みの結果、ＦＡＱのＷｅｂサイトへのア
クセス数も大幅に増加し、１年後には３倍以上のアクセスが集まるようになりました。
このように、インシデントの内容に基づいてメールマガジンの発行やＦＡＱ掲載を進めていくことによって、利用者の利便性を向上させると同時に、ヘルプデスクへの問い合わせ件数も減少する傾向となりました。
このプロジェクトでは、今でも継続的にインシデントの分析と公開を続けています。

２ 検討の進め方を理解する【標準ガイドライン関連箇所：第３編第８章第３節】

利用者視点でサービス・業務を企画するためには、既存のサービス・業務や初期の構想で検討した内容にとらわれず、フラットな視点で事実を把握することから始めることが重要です。
この進め方に関して、サービスデザイン思考に則った考え方に「ダブルダイヤモンド」があります。この考え方をサービス・業務企画の活動を当てはめると図 8-12 のようになります。

図 8-10ダブルダイヤモンド-27 -（第３編第８章 サービス・業務の運営と改善）

サービス・業務企画の活動に当てはめると、「把握」→「分析」→「企画内容の検討」の作業を順番に実施して終わりではなく、「把握」→「分析」→「企画内容の検討」を 1 つのサイクルとして繰り返しながら、徐々にサービス・業務の内容を固めていくことになります。
始めは幅広い視点で事実情報を収集し、集まった情報から全体を俯瞰して優先順位を決めながら、さらに詳細な事実を収集して企画内容を詳細化していくという進め方をすることで、事実に基づいた、利用者に寄り添ったサービス・業務を企画することができます。

-

28 -

デジタル・ガバメント推進標準ガイドライン

デジタル・ガバメント推進標準ガイドライン
実践ガイドブック（第３編第９章-

運用及び保守）1 -（第３編第９章 運用及び保守）

目次
Step.1 運用及び保守活動全体の流れ ........................... 5
Step.2 運用・保守を開始するための事前準備 ................ 6１ 「運用と保守」の位置付けを理解する ........................................... 6
サービス・業務をより改善するための活動を行う ................... 6
情報システムの運用と保守の活動を理解する ......................... 7
運用・保守は他の様々な活動と連携し、並行で実施する ........... 9運用・保守に、自動化の仕組みを取り入れる ....................... 10
システム間での運用統合を検討する .................................. 11
２ 作業責任を正しく理解しトラブルを防ぐ ...................................... 12
外部委託事業者へ依頼する作業の内容を明確にする .............. 12
指標の基礎データを誰がどのように集めるかを明確にする ...... 13
業務実施部門を含めた運用体制を確立する .......................... 15
障害発生時の役割分担に注意する ..................................... 16

Step.3 運用・保守の計画 ....................................... 17
１ 運用と保守の計画を作成する .................................................... 17
システムプロファイルに応じた運用・保守レベルにする ......... 18
セキュリティ関連作業を定期的に確実に実施する ................. 18
プロジェクトの目標や指標の評価に必要なデータは必ず取得する................................................................................... 19
非機能要件に関連するデータを網羅的に詳細に取得する ......... 19
会議体は目的を明確にして必要最低限に抑える .................... 20
定例会の報告フォーマットを指定して、効率性を上げる.......... 21
運用・保守の工数を把握し、人件費をモニタリングする ......... 22
運用・保守における変更管理を理解する ............................ 25

Step.4 運用・保守の定着と次への備え ...................... 27-

2 -（第３編第９章 運用及び保守）

１ 運用定例会議を有効活用する .................................................... 27
運用保守定例会議で確認する内容を理解する ....................... 27
２ 変更を管理し改善活動等の初動を楽にする ................................... 31
３ 情報システムで起こった事実を蓄積する ...................................... 31
運用・保守の範囲にとらわれず、意味のある情報を取得する ... 31
情報システムの活用状況を詳細に把握し提供する機能を棚卸しする ................................................................................ 32

Step.5 運用・保守の改善と業務の引継ぎ ................... 36
１ 適切な時期に的確に改善を実行する ............................................ 36
２ 要員の交代で情報が欠落しないようにする ................................... 37-

3 -（第３編第９章 運用及び保守）事例・参考の一覧
事例：調達要件に改善提案業務を明記し、運用開始後の改善活動を円滑に ..... 10
事例：複数システム間でのシステム監視業務統合 .................................... 12
参考：運用契約（要件・仕様検討時）の忘れ物チェックリスト ................... 13
参考：主な指標とデータの関係例 ........................................................ 14
参考：運用・保守だけでは指標を算出できないケース ............................... 15
様式例：運用計画書、運用実施要領、保守計画書、保守実施要領のひな形 ..... 17
事例：定例会の報告フォーマットを統一し報告内容の分析向上 ................... 22
事例：運用・保守の稼働工数を実績に基づいて分析し削減に成功................. 23
事例：ハードウェア保守費を実績に基づいて分析し削減を実現 ................... 24
事例：実際のＰＣ故障率を確認し保守コスト低減に成功 ............................ 27
事例：評価指標の分析結果をユーザ満足度向上につなげる ......................... 28
事例：データの取得粒度を変更したら事象が異なって見えることもある ........ 29
事例：業務運用に貢献するレポート機能の追加 ....................................... 32
事例：機能単位で情報システムの利用状況を可視化 ................................. 32
参考：サービス・業務の視点で取得可能な指標の例 ................................. 34
事例：インシデントの判断基準及び役割分担を見直し ............................... 36
事例：担当者の交代により次年度で必要な作業が漏れてしまった................. 37※事例には当時の役職名やシステム名を使用しているため、現在使用されていな
い名称が記載されている場合があります。

-

4 -（第３編第９章 運用及び保守）

Step.

1 運用及び保守活動全体の流れ

運用・保守は、事業者に任せておけば大丈夫だと思っていませんか？
運用・保守の目的は、情報システムの安定的な稼働を維持していくことのみならず、利用者へのサービスを継続的に改善することや運用コストを低減していくことも含まれます。そのためには、運用・保守の個々のプロセスについて適切なモニタリングを行い、事業者と協働して見直すことにより、改善につなげていくとことが必要不可欠です。
ここでは、運用・保守の専門家ではない職員が、運用・保守を適切に管理し、より良いサー
ビス・業務につながるように改善を推進していくために必要となる具体的な知識やノウハウを説明します。
本ドキュメントの構成は、次のとおりです。

Step.2 新しいサービス・業務に合わせた運用・保守を開始するための事前準備
より良いサービス・業務を提供していくために必要となる運用・保守の前提知識や心構えを説明します。

Step.3 運用・保守の計画
運用・保守を実施する事業者が決まったら、最初にすべきことは契約期間中の実施計画を立てることです。事業者はこの計画に基づいて作業を実施するため、計画が不十分だと後々問題となることがあります。ここでは、トラブルなく効率的に運用・保守を管理していくために必要な計画立案のポイントを説明していきます。

Step.4 運用・保守の定着と次の備え運用・保守のほとんどの作業は事業者が実施することになりますが、ＰＪＭＯが適切な関与を行わなければ、より良い運用・保守に改善していくことはできません。ここでは、ＰＪＭＯが運用・保守の状況を効果的に確認し、適切な改善を推進していくためのポイントをお伝えします。

Step.5 運用・保守の改善と業務の引継ぎ
運用・保守の実施中に判明した課題は、定常的な作業の中で改善ができるものは積極的に改善していきます。しかし、簡単に改善できない課題も少なくありません。ここでは、課題に応じた適切な改善を推進していくためのノウハウを、事業者の引継ぎに関する内容も含めてお伝えしていきます。

-

5 -（第３編第９章 運用及び保守）

Step.

2 運用・保守を開始するための事前準備

情報システムが完成したら、サービス・業務を滞りなく提供していくために情報システムをきちんと運用・保守していかなければいけません。しかし、情報システムの運用や保守は、専門的な内容が多いため、気が付いたら膨大な費用がかかり、プロジェクトの目標も未達成だった、ということもしばしばあります。
でも、安心してください。運用・保守を開始する前に、いくつかのポイントを押さえて事前に計画すれば、このような事態を防ぐことができます。
では、より良い運用・保守を行うための事前準備のポイントを、紹介していきます。

１ 「運用と保守」の位置付けを理解する【標準ガイドライン関連箇所：第３編第９章第１節】

情報システムの「運用」と「保守」はよく耳にする言葉ですが、その目的や違いを知っていますか？また、運用・保守とよく混同する活動に「サービス・業務の運営」や「機能改修」もあります。これらの違いや関連性を理解していないと、責任範囲や実施内容が曖昧になり、効率的で効果的なプロジェクトの運営を行っていくことができません。
ここでは、運用・保守の位置付けを説明していきます。

サービス・業務をより改善するための活動を行う
情報システムの開発と移行が完了して新たなサービス・業務を開始した時点は、プロジ
ェクト当初に掲げた目標・目的を達成するためのスタート地点に立ったにすぎません。また、サービス・業務を支援する情報システムも、その時点で 100％の出来ではなく、発展途
上の状態である場合もあるかもしれません。リリースまでは想定に基づき業務要件、機能要件を定めてきましたが、運用・保守フェーズに入った後は、実際の利用状況等を継続的に
モニタリングして、利用者の行動等を把握することが可能となります。これらをしっかりと把
握して、より効果的・効率的なサービス・業務に改善していくことにより、国民や業務実施部
門をはじめとした政府職員にとって、よりメリットをもたらす情報システムに成長させることができます。
それでは、効果的なサービス・業務を実現するためにはどうすれば良いのでしょうか。効果的なサービス・業務を実現するためには、運用・保守フェーズにおけるヒヤリ・ハット（インシデント）を多く見つけ、改善を繰り返すことが重要です。
労働災害の経験則として、ハインリッヒの法則があります。これは、1 件の重大事故の背景には、重大事故に至らなかった軽微な事故が 29 件あり、更に事故には至らなかったが事故寸前の、ヒヤリ、又はハッとしたインシデント（ヒヤリ・ハット）が 300 件隠れているというものです。また、重大事故を防ぐための考え方として、ドミノ理論があります。ドミノ理論では、重大事故に至るまでの過程をドミノのように連鎖的なものとして考えます。その過程で発生するヒヤリ・ハットを見過ごすことなく、適切な対応策を講じることで、ドミノ倒しの連鎖を止め、重大事故を防ぐことができます。

-

6 -（第３編第９章 運用及び保守）

図 9-1
ハインリッヒの法則

これは情報システムの運用・保守作業においても同じです。例として、情報システムの改修等により操作手順に変更が生じたものに対して、政府職員の操作マニュアル等のドキュメントを適切に管理していなかったために、誤った作業を実施してヒヤリとしたインシデントを考えてみましょう。この時は、業務影響を及ぼすような事故はなかったかもしれません。しかしながら、国民へのサービス提供に関与する作業を実施していた場合は、提供している
サービスに不具合が生じる等、重大事故につながるかもしれません。ヒヤリ・ハットはそのま
まにせず、ドキュメントの構成管理の手順を見直し、類似のインシデントに繋がらないように再発防止策を講じることで、未然に重大事故を防ぐことができます。
情報システムの運用・保守フェーズにおいては、設計・開発フェーズのテスト不足が原因
でインシデントが起こることが多くあります。サービス・業務に影響を与えるような重大事故に繋げないためにも、発生したインシデントを記録し、将来的な機能改修やシステム更改に当たってテストシナリオ等を検討する際のインプット情報にし、テストの有効性を高めましょう。また、サービス・業務の効率化によるコスト削減は、関係する人員削減とイコールではありません。より人間にしかできない業務に人的リソースを振り分けることで、今まで手が回らなかった業務に対応できるようになるため、より良いサービス・業務を実現していくことができます。

運用・保守の心得
運用も保守も、サービス・業務をより良くするための活動の一部。
目標、指標に関連する情報をモニタリングして、改善につなげる。
ヒヤリ・ハットに着目し、改善を繰り返す。
効率化は人員削減によるコスト削減につなげるだけなく、他の活動に活かして
さらなる価値を生み出す。

情報システムの運用と保守の活動を理解する
情報システムの「運用」も「保守」も、根本となる目的は同じです。シンプルに表現すると、稼働している情報システムを「健全に保って活動を続けさせる」ことです。

運用と保守の目的
サービス・業務の提供価値を高め、継続して行えるようにする。
この目的を達成するために情報システムを安定稼働させ、一連の作業が滞り-

7 -（第３編第９章 運用及び保守）なく進むように維持する。
その共通の目的のもと、運用と保守には次のような違いがあります。

運用とは何か運用とは、上記の目標を達成するための「情報システムの機能を利用者に提供し続けるための活動」です。情報システムの稼働状態を維持するための作業が主となりますが、情報システムを相手にするだけではなく、ユーザサポートのように「人」を相手にする作業もあります。作業を大きく分類すると以下に示すものがあります。詳細は、標準ガイドライン解説
書「第９章 運用及び保守」の表 9-1 を参照してください。

作業分類

概要

表 9-1
運用作業の分類

定常時対応
監視作業

情報システムの稼働状況や利用状況、情報セキュリティ、不整合なデータの有無等の監視を行います。異常の発生を即座に、又は事前に検知することで、安定的な情報システム稼働を維持するための活動です。

情報システム維持作業

バックアップや計画停止、プログラムリリース、一括データ処理、不整合なデータの補正等の情報システム維持関連作業とそれらに係る管理を行います。情報システムを長期間安定して稼働させるために必要となる活動です。

ユーザサポート業務

ヘルプデスクやコールセンターの運営、操作研修、利用者の情報メンテナンス等の情報システムの利用者に対するサポートを行います。利用者が正しく情報システムを利用し、円滑にサービス・業務を遂行することに寄与する活動です。

データの収集と報告

作業実績や障害実績等のデータを収集し整理し、ＰＪＭＯに報告する作業です。

障害発生時対応
情報システム維持作業

不具合等のインシデントに対する受付、切り分け、報告等の一連の対応の管理、リリースやバックアップからのきり戻し等の復旧作業を行います。また、時には誤った情報が記録されたデータベースを修復することもあります。

保守とは何か保守とは、「情報システム（インフラ含む）が予定された機能・レベルを提供するように、情報システムそのものを維持するために情報システムに対して働きかける活動」です。作業を大きく分類すると以下に示すものがあります。詳細は、標準ガイドライン解説書「第９章 運用及び保守」の表 9-2 を参照してください。

作業分類

概要

定常時対応
ハードウェアの保守

定期点検、予防保守等、ファームウェアのアップデート等を行います。ハードウェアの異常の確認や予防を行う活動です。

ソフトウェア製品の保守

製品のアップデートファイルの運用事業者への提供、製品への問合せの対応等を行います。

-

8 -

表 9-2
保守作業の分類

（第３編第９章 運用及び保守）

作業分類

概要

システムリソース配分の調整

過去の業務処理記録やこれからの業務処理見通しに応じて、システムのハードウェア（論理的なハードウェアを含む）資源の稼働中プロセスへの配分を見直して、システムの処理能力を向上させます。

保守作業共通の作業システムの利用者と調整して保守作業計画を策定します。また、システム監査に対するヒアリングや情報提供等を行います。

データの収集と報告

作業実績や障害実績等のデータを収集し整理し、ＰＪＭＯに報告する作業です。

障害発生時対応
アプリケーションプログラムの作業

アプリケーションプログラムの不具合に対する原因調査、プログラムの修正・テスト等を行います。

ハードウェアの保守

ハードウェア異常に対する原因調査、ハードウェアの修理や交換等を行います。

ソフトウェア製品の保守

ソフトウェア製品の不具合に対する原因調査、ソフトウェア製
品の修正・テスト等を行います。

運用・保守は他の様々な活動と連携し、並行で実施する運用と保守の活動は他の活動のいろいろな作業と関係しています。最も関係性があるのは標準ガイドライン「第８章 サービス・業務の運営と改善」で、運用・保守とは表裏一体との関係にあります。これらの関係を図 9-1 に示します。

図 9-2
運用及び保守活動と他の活動との関係「サービス・業務の運営と改善」の活動で、ＫＧＩ・ＫＰＩがどの程度満たされたかを判断するための指標を算出する作業を行いますが、この作業に必要な根拠情報を提供するのが、「運用と保守」の重要な作業の一つです。根拠情報には、システムログやトランザクショ
ンデータ等の情報システムで取得可能なものと、サポートデスク等で人が介在して取得するものがあります。そのため、これらの情報取得作業は、運用保守作業の一つとして確実に作業に組み込み、必要な情報が必要なタイミングで取得できるように整備しておく必要があります。

-

9 -（第３編第９章 運用及び保守）

事例：調達要件に改善提案業務を明記し、運用開始後の改善活動を円滑にある府省では、管理している情報システムの一つで、運用保守業務の調達仕様に「年に２回の改善提案」を盛り込んでいます。具体的には、半年間の課題整理、今後の運用・保守業務改善の方向性（事業者の意思表示を含む）及び全体課題と個別課題に係る改善提案について、文書を作成してプレゼンテーションを求めています。

事例 9-1
調達要件に改善提案業務を明記
し、運用開始後の改善活動を円滑に

当初契約締結時には、運用保守事業者側に戸惑いも見られましたが、①提案内容のメリットの大小は問わないこと、②費用がかかる案件であれば別途予算化を検討する
こと、を確認して事業者側の理解を得て進めることとなりました。
改善提案制度の導入によって、職員と事業者に以下のような仕事への取り組み方の変化がもたらされました。
運用保守事業者の考え方が、利用者目線になっていった。すなわち、安定稼働、使いやすさ、丁寧な説明を重視するように変化した。
年２回の改善提案があることで、ＰＪＭＯ職員と事業者のコミュニケーションが活性化した。
ＰＪＭＯ職員の業務と情報システム運用との関係に対する理解が深まったことから、仕事の計画と実施管理の水準向上につながり、情報システムそのものの機能改善
や次期情報システムの企画業務に時間を割く余裕が生まれた。
この事例において、いわゆるＳＬＡ（サービス水準契約）に基づくペナルティやインセ
ンティブは設けていませんが、年２回の改善提案業務をきっかけとして、事業者と職員の協働によるＳＬＭ（サービスレベルマネジメント）が行われています。

上記のような例もそうですが、運用・保守を実施していく中で発生した問題に対して、運用・保守の範囲だけでは解決できないこともあります。そのような場合は、標準ガイドライン「第８章 サービス・業務の運営と改善」に課題を集め、サービス・業務の内容も含めて改善を検討します。（※これはＩＴＩＬが定める問題管理に相当します。）
また、「サービス・業務の運営と改善」で集めた課題に対して、既存の機能の修正や新たな機能の開発が必要になることがあります。これらは「機能改修」と呼ばれます。プログラムに修正が入る点では「保守」と似ていますが、保守における修正は、サービス・業務の開始時点で定められた設計どおりに動作させるためのものである点に注意してください。

運用・保守に、自動化の仕組みを取り入れる
情報システムの運用・保守は、従来は人が目視確認や手作業で実施してきましたが、人による体制で運用・保守を行うと人件費がかさみ、運用保守のコスト増となります。
現在では、通常システム運用管理ツール等を導入して自動化による効率化を図っています。ただ、これらのツールを導入してライセンスを購入したにもかかわらず、実際にはこれらのツールの機能をほとんど使っておらず、結果として人手による運用作業が多く残っているケースも多くみられます。
以下に、より効率の良い自動化を進めるために検討すべきポイントと例をまとめます。

-

10 -

注記
ＩＴＩＬ（Information Technology
Infrastructure Library）とは、1989
年に英国政府のＣＣＴＡによって公表されたＩＴサービスマネジメン
トにおけるベストプラクティスをまとめたもの。2018 年時点ではＶ３である。

（第３編第９章 運用及び保守）自動化を進めるためのポイントと例
手順が定まっている作業の自動化
セキュリティパッチアップデート、プログラム更新、データ更新等を自動的に行うプログラムや設定を準備しておく事で正確かつ実施効率を上げる方法です。
定量的な監視設定と通知・連絡の自動化
アクセス量が制限値を超えた時や、サーバのメモリやディスク容量等があらか
じめ設定した値を超えた時、あるいはネットワークや機器の故障があった際にメールや SMS、電話等で自動的に関係者に通知・連絡する方法です。従来はメールのみによる通知が主でしたが、SMS や電話での通知を取り入れること
で、より素早い連絡とその後の対応ができるようになります。
経験者の目視に頼っていた判断・制御の自動化
アクセス状況やサーバリソースのグラフの異常傾向の検知、不審な大量アクセ
ス等の検知を AI 等の機械学習を利用して実施し、初期判断（運用・保守担当
者へのエスカレーション）に用いる方法です。上記「定量的な監視設定と通知・連絡の自動化」 のような設定値の超過ではなく、時間推移による急激な変化
によるリスクを判断するという「経験者の暗黙知」を自動判断にすることで稼働時間を抑えられるようになります。また、検知後の制御・対応も自動実施することも可能になります。

システム間での運用統合を検討する
各プロジェクトで複数のシステムを運用している場合に、それらの運用業務には重複する作業が多数発生していることがあります。
このような場合に、複数システム間での運用を統合することも検討してみたいですね。
運用経費の総額を減らすということも一つの目的ですが、それだけではなく、個々の職員が運用作業に振り回されている現状を改善できるかもしれません。
運用業務の統合に際しては、なるべく統一したオペレーションが行えるように検討・調整することが大事です。たとえば、ハードウェア、ネットワーク、アプリケーションプログラム等のそれぞれの層ごとに、発生している運用業務を把握してみましょう。
すると、監視内容については各システムでほとんど似通っている一方で、障害を検知した後のエスカレーション先はそれぞれ異なっているなど、共通点と相違点を区別して把握することができます。このように、運用業務の現状を把握できれば、統一したオペレーションへの第一歩を踏み出すことができるかもしれません。
また、統合運用を実現する際に、運用管理システム（ジョブ管理、システム監視、構成管
理等）がばらばらだと共通化できる作業が少なくなってしまいます。運用管理システムを統一することもまた一つの検討事項です。

-

11 -

（第３編第９章 運用及び保守）

事例：複数システム間でのシステム監視業務統合ある府省では複数のシステムを保有しており、それぞれ異なる事業者が同じような監視
内容を異なる監視ツールで個別に監視していました。報告も個々の事業者から別々に受けており、同じような内容でありながらツールの違いから、情報の見え方もそれぞれ異なるため、報告を受ける職員の負担となっていました。また、システムごとにそれぞれの事
業者から報告を受けていて効率的ではありませんでした。
こうした状況を改善するため検討を行った結果、監視ツールを統一し、まとめて監視することにしました。具体的には、それぞれのシステムに共通、固有の監視項目を抽出して網羅性を確保し、監視ツールを１つの製品に統一しました。
その結果、課題となっていた職員の負担や非効率が改善されただけでなく、保有するシステム群全体の状況を横断的に監視できるようになったことで、府省全体のシステム最適化を進めるための基礎情報を得られるようになりました。

２ 作業責任を正しく理解しトラブルを防ぐ【標準ガイドライン関連箇所：第３編第９章第１節】

運用・保守の活動やそれに係る「サービス・業務の運営と改善」等の活動には、様々な関係者が関わります。それぞれの作業内容や責任範囲が曖昧になってしまうと、作業漏れや関係者間の意思疎通が不十分となることによる新たな問題が発生するリスクが増大します。悪くすると、情報システムの安定的な稼働への問題発生、改善活動の停滞などを招き、プロジェ
クトの目標達成に影響が出てしまいかねません。
ここでは、運用と保守に関係する関係者と各々の作業責任内容を定めて、円滑に作業を進めていくためのポイントについて、ご紹介します。

外部委託事業者へ依頼する作業の内容を明確にする「運用」及び「保守」に係る作業は、基本的に外部事業者に委託して実施します。その理由は、内容が専門的であることや、手順に沿った定型かつ大量な作業が多いため、ＰＪＭＯ
や業務実施部門の職員が実施すると、かえって非効率になる可能性があるためです。「餅は餅屋」の言葉どおり、外部事業者と役割を適切に分担することにより、発注者側の職員
は、業務の質の向上やコスト削減等の、本来職員が行う事業者では実施できない作業に、より注力することができます。
外部事業者に依頼する作業や役割は、調達の段階で調達仕様書に明記しておく必要があります。事業者確定後にこれらの詳細を詰めようとすることは、トラブルの原因となりますので、注意してください。
それでは、調達仕様書にはどのような項目を定義すればよいでしょうか？
基本的には、定型的な作業は標準ガイドライン「第７章 設計・開発」において、運用設
計・保守設計として洗い出されているため、それがそのまま調達仕様書の付属資料として、作業要件になります。しかし、次に示すような項目は、重要な内容にもかかわらず見落とされがちなため、明記されているかもう一度確認してみましょう。

-

12 -

事例 9-2
複数システム間でのシステム監
視業務統合

（第３編第９章 運用及び保守）

参考：運用契約（要件・仕様検討時）の忘れ物チェックリスト
大分類
業務管理
関係

中分類
報告内容と書式

作業項目
日報、月報
業務改善提案書
インシデント（基盤・業務ＡＰ、セキュリティ）入館証名簿と手続（名前、所属、住所など）
体制表の提出（真の会社名必須）
要員交代協議・承認手順
シグニチャ、パターンの更新（ウイルスソフトなど）
ＯＳ、ミドルウェア、言語システムの脆弱性解消のためのアップデート（想定頻度も記述）
ブラックリスト・ホワイトリスト登録（ＩＰ、ドメインなど）
バックアップ情報からのシステムリストア
定期作業以外の緊急セキュリティ作業（上述セ
キュリティ関連作業、ログ等の調査）
運用手順書関係のメンテナンス
保守・修理作業結果と履歴管理
基盤工事図書の最新化
アプリケーション構成管理情報の最新化

要員管理

作業要件
関係

情報セキュリティ
関連作業

緊急対応

ドキュメント保守

以下は契約時点で要件化が必要であれば記述を検討してください。
ネットワーク増設・設定変更作業（技術支援、設計、設定工事）
情報セキュリティインシデント時の役割（情報連携作業、ＣＳＩＲＴ報告・支援待機など）
ヘルプデスク、ネットワーク管理事業者、業務システム開発事業者との連絡関係
特に、構成管理については運用を積み重ねる中で、ドキュメント間の不整合が発生しがちです。大規模なシステムでは、このようなドキュメント管理に専門の要員（ライブラリアン）を配置して、ドキュメント管理ルールに則って正確な記載を保つ努力をすることもあります。
ドキュメント間で矛盾した記載にならないか、同じ用語が違う意味で用いられていないか、それらは一見些細な事に見えますが、このような記載の「ゆれ」によって関係者が誤解をした結果、大きなトラブルにつながってしまう事例もあります。
なお、用語の意味や定義をそろえるために用語辞書を整備することもひとつの対策です。ただし、用語辞書を作成した後に内容の更新を怠ってしまわないように、メンテナンスを行う体制を維持することも重要です。
構成管理の品質を高めることに留意しましょう。

指標の基礎データを誰がどのように集めるかを明確にする
指標に用いるデータ取得のための作業は、標準ガイドライン「第８章 サービス・業務の運営と改善」の作業と密接に関連します。サービス・業務の運営と改善では、プロジェクト計画書で定めたプロジェクトの目的・目標が実現できているかに関して、いくつかの指標（ＫＰＩ）
を用いて判断し、業務の改善や見直しを行います。指標（ＫＰＩ）は、基礎値の組み合わせによって、表されます。

-

13 -

参考 9-1運用契約（要件・仕様検討時）の忘れ物チェックリスト

注記シグニチャとは、ウイルス対策ソ
フトやファイアウォール等、コンピュータウイルスの進入を防ぐソフ
トウェアにおいて侵入を検知する
ために識別しているコンピュータ
ウイルスなどに含まれる特徴的なデータの内容や、攻撃者が持つ特徴的な受信データのパターンのこと。
注記
ブラックリスト・ホワイトリストとは、フィルターをかける対象を「リストに記載されていたらＮＧとする」ものがブラックリスト、「リストに記載されているものだけをＯＫとする」ものがホワイトリスト。
注記
システムリストアとは、何らかの原因で不具合が発生した情報システムを、正常に稼働していたある時点の情報システムの状態に戻すこと。
注記
ＣＳＩＲＴとは、シーサート (CSIRT:
Computer Security Incident
Response Team) とは、コンピュー
タセキュリティにかかるインシデントに対処するための組織の総称。
http://www.nca.gr.jp/

（第３編第９章 運用及び保守）

指標（ＫＰＩ）の例
指標の基となる各種データは、種類ごとに、取得先、取得手段、取得頻度等について詳細な検討が必要です。代表的なデータとして、情報システムが稼働している際に作り出されるログやトランザクションデータと呼ばれるものが挙げられます。これらは、職員が自ら取り出せるもの、運用事業者に依頼しないと取り出せないもの等、データの取得には制約が発生します。前者であれば、事前に技術的な経験のない職員でも容易に取得できるように、取得手段が機能化されている必要があり、後者は対象と取得手順が明確に定義されていなければ、定常的な運用作業として継続できません。
これらを踏まえて、取りこぼしが発生しないよう、必要なデータ項目を事前に把握するとともに、外部事業者に取得を求める場合は調達仕様書に明記しておきましょう。

参考 9-2
主な指標とデータの関係例

参考：主な指標とデータの関係例
No

指標名

1

利用者満足度2

相談窓口の平均対応時間
相談窓口における苦情・相談解
決率

34

相談窓口におけるエスカレーシ
ョン件数の逓減率

56

窓口申請に要する費用
オンライン申請に要する費用

7

職員満足度

8

職員苦情・相談件数
職員苦情・相談解決までの平均
時間

9
10

削減業務処理時間

11

削減経費

12

開発経費削減率

13

運用経費削減率

14

保守経費削減率15

業務・サービス委託経費削減率計算式「「満足」とした回答数」／「全有効回答数」
×100
相談窓口の平均対応時間「相談窓口で解決した件数」／「全苦情・相談件数」×100(「前年度エスカレーション件数」－「当該年度エスカレーション件数」)／「前年度エスカ
レーション件数」×100
窓口申請に要する費用
オンライン申請に要する費用「「満足」とした回答数」／「全有効回答数」
×100
職員苦情・相談件数
苦情・相談解決までの平均時間「現行業務処理時間」－「業務・サービス改
革実施後の業務処理時間」「業務・サービス改革実施前の経費」－「業務・サービス改革実施後の経費」(「基準開発経費」－「当該開発経費」)／「基準開発経費」×100(「基準年度年間運用経費」－「当該年度年間運用経費」)／「基準年度年間運用経費」
×100(「基準年度年間保守経費」－「当該年度年間保守経費」)／「基準年度年間保守経費」
×100(「基準年度年間委託経費」－「当該年度年間委託経費」)／「基準年度年間委託経費」
×100

単位
％
分／回
％
％／年
円
円
％
件
分／回
時間
円
％
％

％

％

指標は、いざ算出しようしたときに、算出根拠となる基礎情報が不足していることが判明し、その情報を追加入手するためには想像以上に困難であることに気付くことがあります。
特に、ある分析結果からより多角的な分析が必要になった場合、特定の情報の付加情報として「区分」や「属性」等、より詳細な情報が求められることがあります。このような情報は、事前に取得・保管する仕組みが備わっていなければ、その時点から遡ってデータを取得することが不可能なこともあります。また、取得可能だったとしても、多くの手間を必要とする場
合もあり、そのようなデータは頻繁なモニタリングが敬遠され、結果として指標が適切な時期に算出できず、対策が遅れてしまうことにもつながりかねません。
運用・保守を開始してからトラブルとならないよう、事前に具体的なモニタリングの方法や

-

14 -

（第３編第９章 運用及び保守）

役割分担を検討し、事業者に依頼する場合は調達仕様書に作業内容を明記してください。
また、平均値を指標とするときは、集計対象の種類や内容が同種のもので平均値を算出するようにし、異なる性質のものを混合して値を算出しないようにしましょう。

参考 9-3
運用・保守だけでは指標を算出できないケース

参考：運用・保守だけでは指標を算出できないケース
設定した指標値
指標名
オンライン利用率計算式
オンライン申請件数／総申請等件数×100

単位％

このように設定された指標では、申請全体に対するオンライン申請の割合が把握できます。一方で、効果的な改善活動に資する活動として例えばオンライン申請率を向上させようとした場合、このオンライン申請を実際に実施したユーザの区分（本人・代理人の区分、個人・法人の区分等。）ごとの割合を分析して、区分に応じた対策を講じる必要があります。
ユーザ区分ごとの申請件数は、「オンライン申請件数」は、申請情報にあらかじめユーザ区分を加えておけば、運用作業で取得できますが、「総申請等件数」は業務実施部門から取得するかもしれませんし、全ての申請を管理している別の情報システムから取得しなければいけないかもしれません。また、取得先全てにおいてユーザ区分の情報を持たせ、かつ、ユーザ区分の種類を統一する必要もあります。

業務実施部門を含めた運用体制を確立する
情報システムの各種テストが完了し、後は本番リリースを迎えるだけという状態に準備が整い、運用・保守フェーズをお任せする事業者が確定したら、サービス・業務を利用者に提供するまであと一歩です。運用・保守フェーズでは、最初に司令塔となるＰＪＭＯを含んだ運用統制を行うチームを構築し、プロジェクトを管理していくことになりますが、円滑な運営を進めるための注意点があります。
それは、業務実施部門（主に当該情報システムの業務統括部門）とのコミュニケーションと役割分担です。
業務実施部門には、情報システムを用いて実際に業務を行う職員が集まっています。この多くの職員には、プロジェクトの目的・目標を理解してもらうことは、標準ガイドライン「第８章 サービス・業務の運営と改善」で触れたとおりですが、運営に入ってからは次の点に気を付けて実施してください。

業務実施部門との役割分担・コミュニケーションで気をつける点
ＰＪＭＯには、業務実施部門の担当者が参画するよう、組織を組成する。運用・保守に関わる定期報告会では業務実施部門の担当者（代表者）が参加した上で、常に情報を共有できるようにする。
日常的に、現場業務で発生した問題や状況に関する情報がＰＪＭＯに伝わる
よう業務実施部門の担当者とのコミュニケーションルールを明確にしておく。
業務実施部門とＰＪＭＯとの関わりについては、プロジェクト立ち上げ時のＰＪＭＯの組成

-

15 -

（第３編第９章 運用及び保守）にまで遡ります。そこでは、基本的にＰＪＭＯには制度所管部門及び情報システム部門とともに、業務実施部門の担当者が参画することが望ましいことが言及されています。
これまでは、新しいサービス・業務の要件を定めるために、業務実施部門の職員から意見・要望を収集することが主でしたが、サービス・業務の運営フェーズになると、コミュニケーションの流れが、収集だけではなく、業務実施部門からの情報提供が加わります。
利用者からの意見や要望を把握するためには、最も接点が多い業務実施部門の職員
からの情報提供が欠かせません。また、運用・保守で発生した報告内容には、利用者からの問い合わせや発見した不具合、不具合修正に伴う情報システムの稼働停止連絡等、様々な情報が含まれます。これらを業務実施部門と共有することにより、業務実施部門の中で必要な調整や対策を行い、今後問題を引き起こすリスクを低減させることが可能となります。
そのためにも、プロジェクトの情報が集まるＰＪＭＯへの参画、定期報告会への必要な人員の出席、代表者から業務実施部門の関係者全員への情報伝達手段などを、運用及び保守が開始する前に取り決めておきましょう。

障害発生時の役割分担に注意する障害が発生しない情報システムは、ほぼありません。大切なのは、障害が発生した際に適切な対応を取ることで被害を最小限に留め、暫定対策から恒久対策を実施し、将来にわたって同じ又は同じような障害を発生させないようにすることです。そのためには、障害対応という急を要する状況の中でも、ＰＪＭＯ、運用の事業者、保守の事業者、その他の関係者が適切な役割分担の下に協働して対応を進めていくことが必要になります。運用と保守の事業者が異なる場合や運用・保守それぞれを複数事業者で分担して実施する場合もあり、役割や責任が曖昧になることで対応が遅くなってしまうことや被害が拡大してしまうことも少なくありません。
まずは、障害発生時における運用と保守の基本的な役割分担を理解しましょう。この考え方を踏まえた上で、プロジェクトの体制や特性を踏まえて、詳細を決めていきます。
極端な例ですが、ＰＪＭＯの体制が１名の場合は、24 時間 365 日稼働するサービスへの対応は十分にできません。どのようなタイミングで障害が発生するかは予想できないからです。深夜や休暇取得中等、ＰＪＭＯが対応できない状況が存在することを前提に、運用事業者・保守事業者と役割分担を検討する必要があります。

図 9-3
障害発生時の運用と保守の役割
分担の例

-

16 -

（第３編第９章 運用及び保守）

Step.

3 運用・保守の計画

運用・保守を担当する事業者が決まったら、事業者とともに調達仕様書で示した内容から、運用・保守の詳細な作業内容や実施方法等を検討し、計画書と実施要領として明文化します。これらは、運用・保守の作業はこの計画に基づいて実施することとなるため、作業が漏れたり不十分だったりすると後々問題を引き起こすこともあります。
ここでは、運用・保守をトラブルなく円滑に進めていくための計画策定のポイントを、紹介していきます。

１ 運用と保守の計画を作成する【標準ガイドライン関連箇所：第３編第９章第１節 2)】

この実践ガイドブックには、別添として、運用計画書、運用実施要領、保守計画書、保守実
施要領のひな形を示しています。

様式例：運用計画書、運用実施要領、保守計画書、保守実施要領のひな形
運用計画書、運用実施要領、保守計画書、保守実施要領のひな形を本章別紙としてまとめています。

-

17 -

様式例 9-1
運用計画書、運用実施要領、保守計画書、保守実施要領のひな形

（第３編第９章 運用及び保守）

このひな形はあくまで例示ですので、運用の内容に応じて記載内容を個別に追加、変更して構いません。ひな形を見ると、何をどのようなレベルで書くべきかの参考になると思います。
以降では、運用計画書・運用実施要領を作成するときに、特に注意が必要なポイントについて説明していきます。項目の詳細な説明は、ひな形を参照してください。

システムプロファイルに応じた運用・保守レベルにする
運用や保守の体制や作業は、サービス・業務の内容や重要度等によって、適切なレベルを設定し、適切な費用で効果的な運用・保守となるように心掛けましょう。しかし、適切なレベルとはなんでしょうか？
運用や保守のレベルの基準となるのは、要件定義書で定められた「システムプロファイル」です。
サービス・業務を開始した直後から運用や保守が安定するまでの一定期間は、予期せぬ障害に備えて手厚い運用・保守体制をとることがしばしばあります。この手厚い体制を維持する期間は情報システムによって様々ですが、システムプロファイルで示した運用・保守レベルを維持できる最低限の体制を基準として、プロジェクトの状況に応じて定期的に見直しを行い、徐々に適切なレベルの保守・運用にしていくように調整していきましょう。

セキュリティ関連作業を定期的に確実に実施する
セキュリティ管理に関する要件は、非機能要件で示され、運用・保守フェーズでは、その方針に沿ってアプリケーションやインフラでの対策が講じられている状態にあります。昨今のセキュリティに対する脅威は日々増大しており、運用・保守フェーズでは、設計どおりの対策が維持できるよう、日々確実に作業を続ける必要があります。
以下に定期的に実施すべき作業の例を挙げます。
セキュリティインシデント発生時の記録、対応、影響範囲の把握
脅威と修正パッチ適用計画の立案・調整
シグニチャ、ブラックリスト（ホワイトリスト含む）更新
ＯＳ及びプラットフォーム等の緊急修正計画の立案・調整
セキュリティ向上のための業務改善と利用規制検討
中長期的プラットフォーム改善に向けた、システム構成要素のリスク評価

-

18 -

注記
システムプロファイルとは、「標準ガイドライン 別紙５ システムプ
ロファイルに係る定義について」に基づいて定義する情報システ
ムの信頼性の水準のこと。

（第３編第９章 運用及び保守）

プロジェクトの目標や指標の評価に必要なデータは必ず取得する
Step.2-2 の「指標の基礎データを誰がどのように集めるかを明確にする」のとおり、目標や指標値を定期的にモニタリングできるよう、運用作業として取得しなければいけないデー
タについては、以下の観点で運用の計画書と実施要領に明確に記載しましょう。

記載箇所

記載内容

運用計画書
１．作業概要データ取得作業として、取得するデータの種類、取得の条件、集計や加工の方法等を記載します。

３．スケジュールに関する事項

いつ、どのタイミングでデータ取得作業を行うかを記載します。月次や四半期の期末月のように定期的に取得し、運用保守定例会議等で報告とデータの提出を求めます。

運用実施要領３．作業管理報告の形式や報告の仕方を記載します。

運用作業で取得したデータは、標準ガイドライン「第８章 サービス・業務の運営と改善」
で使用する以外にも、今後の機能改修やサービス・業務の見直し時の分析データとして使用できるよう、報告資料だけではなく、データ自体を加工や集計が可能な形式で受け取る
ようにしましょう。そのためには、運用計画書及び運用実施要領に記載された内容から、要員に依存せずにデータを取得できるよう、データ取得手順書の作成を運用事業者に求めてください。
また、これらのデータを保存する手段や期間に関する考慮も重要です。数年に渡る傾向
分析等に必要な情報は長期間保存が必要ですが、週次で集計値を算出した後は不要となる詳細データは、無闇に保管するとストレージ等の無駄が生じます。クラウドサービスを利用している際はデータ保存量がコストに直結する場合もあるため、迅速かつ頻繁に参照
したいデータは取り出しやすい媒体に保存し、緊急性のないデータは外部媒体に保管する等の工夫を行いましょう。

非機能要件に関連するデータを網羅的に詳細に取得するサービス・業務を円滑に運営するためには、標準ガイドライン「第５章 要件定義」で定めた非機能要件に従って、情報システムを安定的に稼働させ続けることが必要になります。
このためには、現時点で情報システムが非機能要件で定めた指標値を満たしているかを確認することはもちろんですが、将来的に要件を満たせない、維持コストが増大する等のトラブルが発生する予兆を捉えることが、とても大切です。また、日次や月次等の定点的な観測だけではなく、確認したい内容ごとにどのような間隔でデータを取得するかを検討し、取得できる仕組みを設け、必要な情報が必要な粒度で取得できるように備えておきましょう。
非機能面のチェックは様々な観点がありますが、次にあげるポイントはとても重要ですので、必ず確認できるように、運用作業に持ち込んでください。

非機能要件に関連するデータの確認ポイント
データ量
データベースやファイルシステムの使用率等を時系列で確認し、傾向から将

-

19 -

表 9-3
運用計画書、運用実施要領におけるデータ取得に関する記載内容例

（第３編第９章 運用及び保守）

来容量が枯渇するおそれがないかを確認します。
処理時間
機能単位、時間単位等の複数の視点からレスポンス時間等の処理時間を確認することにより、安定的に処理を行えているか、処理が遅くなる傾向等が見られないかを確認します。また、バッチ処理時間も時系列で確認し、将来的に完了予定時刻に遅れる予兆等がないかを確認します。
リソース状況
ＣＰＵやメモリ等が異常な状態になっていないか（高負荷状態が続いている、
ほぼ使用していない等）を確認します。これらも、サーバ単位、時間単位で詳細に取得して、傾向を確認します。
これらのデータを蓄積していくことで、情報システムを更改する際に、サーバの構成・スペック等の精査が簡単に行えるようになります。また、クラウドサービスに求めるサービスレベルの検討にも活用できます。これらの情報についても、報告資料だけではなく、データ自体の提出を求めるようにしましょう。

会議体は目的を明確にして必要最低限に抑える
運用・保守フェーズは、複数の職員や事業者が関わるため、会議体の種類がどうしても多くなる傾向があります。中心的な役割を担うＰＪＭＯの職員や事業者の担当者は、会議出席に拘束されてしまい、本来行うべき作業に手が回らないという状況に陥りがちです。
そのような状況にならないために、会議体の目的を整理し、必要な出席者を事前に選抜するようにしましょう。以下に主要な会議体の種類と主な目的を示します。

会議名称

主な目的・内容

定例会議
日次会議（朝会
夕会を含む）

関係者同士の作業確認、段取り打ち合わせ
シフト間（夜間から日中等）引継ぎを既定のシートをベースに行う

月次会議

事業者が発注者に対して行う報告など
事業者同士の情報連携及び業務手順改善（例：基盤運用事業者、ＡＰＰ保守事業者、センターオペレーション
事業者、ヘルプデスク事業者及び発注者の５者運用調整会議）

セキュリティ対策
会議（月次～四半期）

インシデント発生状況の共有
脅威と修正パッチ計画の調整
シグニチャ、ブラックリスト（ホワイトリスト含む）更新調整
ＯＳ及びプラットフォーム等の緊急修正計画調整
セキュリティ向上のための業務改善と利用規制検討・承認業務・システム運
用改善会議（１～２回／年）

上級マネージャ出席（発注者側、事業者側双方）の下で、業務及びシステム運用についての協議を行う。
業務仕様に「改善提案」を盛り込んであれば、この会議体で提案する。
職員側と事業者側の幹部を出席者とする「ステアリング・コミッティ」とすることも可能。

非定例会議
個別課題について解決するための会議

一般的には発生都度開催することが多いが、当該業務及びシステ
ムの価値に関わる重要テーマがあれば、そのテーマを冠として分科会形式で開催することが望ましい。
例）「システムサービス改善運動」を冠テーマとして、「利用者サービス向上分科会」、「業務ミス根絶分科会」、「マニュアル・手順書改善分科会」」

-

20 -

表 9-4
会議体と主な目的・内容例

（第３編第９章 運用及び保守）

会議名称

主な目的・内容等を適宜開催。

システム移行会議

業務システム全体を改修する場合、基盤を乗せ換える場合、一部出先事
務所（又は事業所）にシステムを導入する場合等で実施。

次年度リソース
計画会議

システム基盤リソース及び保守運用に係る人的リソースの検討を行う。利
用実績や実測レスポンス、定例処理の時間等のエビデンス情報に基づ
き、今後の必要リソースを算出していく。

会議体選択の考え方
日次会議は、情報や状況把握の正確性確保と関係者間の問題解決事案の引継ぎが主目的である。短時間で効率的に実施することが肝要である。この会議
では、運用状況・保守作業状況及び問題解決の進行状況が取り上げられるので、できる限りＰＪＭＯが参加することが望まれる（毎日出席はできなくても週に１回ランダムに出席することを推奨する）。
月次の定例会議は、できる限り開催する。ＰＪＭＯ側と事業者側の双方の責任者が出席し、マネジメントレベルの状況判断、方針及び約束等をオーソライズする場とする。できれば、調達時点で必須報告事項を仕様として提示することが望まれる。
セキュリティ対策会議は、インシデント事案の最終評価・対応方針の周知、確実な脆弱性対策実施及び運用上の懸念事項の吸い上げが目的である。目安として利用者が数百人以上のシステムにおいては、四半期に１度程度は開催することが望まれる。
業務・システム運用改善会議は、運用関連業務の受託事業者が「仕様書：改善提案業務」の成果発表を行う位置づけとすることを推奨する。この会議では、事業者から出てくる改善提案にＰＪＭＯが誠実に対峙し、協働して前向きな改善に持ち込めるかどうかが重要。
その他非定例会議は、必要の都度開催することとなる。ポイントとしては、事前に会議の目的と到達目標、テーマ及び各参加者の役割を周知しておくとことが望まれる。

定例会の報告フォーマットを指定して、効率性を上げる
運用や保守を行う事業者は、多くの場合、独自の報告フォーマットを持っています。「自社フォーマットを使用することで効率的に運用・保守の報告を行える」という主張は理解できますが、ＰＪＭＯが報告してほしい情報がそのフォーマットに含まれていなかった場合、その情報を把握できない可能性があります。また、複数の情報システムを有する大規模プロ
ジェクトにおいて、複数の運用・保守事業者が活動を行う場合に、それぞれの報告フォー
マットが異なったらどうなるでしょうか？横並びでの確認が困難になりますし、分析が非常に難しくなり改善の妨げになるかもしれません。
これらを防ぐために、事業者からの報告フォーマットはＰＪＭＯが指定したものを使用する
よう、調達仕様書であらかじめ方針を示しておきましょう。運用・保守事業者の決定後、詳細な報告項目について更に調整を行います。この際、報告書作成に特定のツールを利用しているため、指定したフォーマットで報告することが著しく非効率になる等の場合は、ＰＪ
ＭＯが求めた内容が必ず含まれるよう、事業者にフォーマットを確認し、盛り込むべき内容

-

21 -

（第３編第９章 運用及び保守）を合意してください。

事例：定例会の報告フォーマットを統一し報告内容の分析向上
ある府省の情報システムには、複数の運用・保守事業者が関わっており、効率的な運用保守定例会の運営が課題となっていました。
そこで、他の情報システムや過去の報告書等を参考に、発注者側で報告フォーマットを検討し、各事業者にはそのフォーマットに沿った報告を求めました。
一部の事業者は、既存の報告書を作成するツールが存在していたため、難色を示しましたが、報告項目や単位を揃える方針で調整を行い、合意しました。
その結果、各事業者からの報告内容が同じ軸で効率的に比較・分析できるようになりました。

運用・保守の工数を把握し、人件費をモニタリングする
情報システムに係る経費は、情報システムを構築するまでの費用よりも、運用・保守フェーズ期間にかかる費用の方が多いことがよくあります。運用や保守のどの作業にどの程度の工数がかかっているかを定期的に把握していなければ、費用はかかったが求めた内容があまりできなかった、という結果にもなりかねません。
運用・保守フェーズの作業はとかく事業者にお任せになりがちで、報告内容もざっくりと「作業一式」で済まされてしまうこともありますが、管理に必要となる詳細な報告を求めましょう。事業者は個別のエンジニアの工数管理は労務管理上実施しているはずですので、求めれば応じられる管理情報は持っています。
実際の工数を正確に把握していれば、的外れな対策を行うリスクもなく、効率的にコスト削減を行うことができます。低コストで効果的な運用・保守に改善していくためにも、作業ごと、要員ごと等の詳細な工数データを取得できるよう、事前に事業者と調整し、運用の作業の一部として計画に盛り込み、運用保守定例会議で報告を受けるようにしましょう。

-

22 -

事例 9-3
定例会の報告フォーマットを統一し報告内容の分析向上

（第３編第９章 運用及び保守）

事例：運用・保守の稼働工数を実績に基づいて分析し削減に成功ある府省で、情報システムの運用・保守費の見直しを行うことになりました。作業区分
ごとに工数の確認を進めようとしたところ、運用報告書に記載されている作業内容は、
記載レベルが大まかで計画値もなく、実績値との比較分析が困難な状況でした。
このため、運用報告書で報告する作業内容を詳細化し、それぞれ計画と実績工数を明示するよう変更しました。
この結果、項目ごとに実際に必要な工数が明らかになり、過剰な工数を削減することができました。

運用・保守フェーズに入る前は、実績値がないため想定の値で工数を見積りますが、稼働２年目以降は実績値が取得できるため、計画工数と実績工数の比較を通して適切な工数を確保するよう調整しましょう。

この事例のような考え方は、運用・保守フェーズで実施する機能改修にも応用できます。
例えば、機能改修を行う際に、改修による影響度を調査した上で、発注者と受注者でテストのスコープや実施方法等の方針を協議することで、効率化又は削減できる作業を特定できるようになり、工数を削減することができる場合があります。 特に、運用・保守フェーズ
では、障害発生時に次回以降同じ障害を繰り返さないためにテスト項目が追加されたり、改修を行わない部分に対するリグレッションテストを大量に実施することでテスト項目が増加したりして、多大なテスト工数が必要となる場合があります。その対策として、過去のテス
トシナリオの再利用やテストの自動化等を行うことで、テストの効率性を高めることができます。加えて、機能改修の特性を踏まえて、見積りの精査、不要と思われるテスト項目の除外、機能改修による影響範囲の特定などを実施する ことで、過剰な工数を削減することができます。
また、改修規模や機能改修にかかった実績工数を報告させるようにすることで、次回以降に同様の規模の機能改修を行う際に、その工数の妥当性を確認し、工数削減につながる場合があります。

-

23 -事例 9-4
運用・保守の稼働工数を実績に基づいて分析し削減に成功（第３編第９章 運用及び保守）事例：ハードウェア保守費を実績に基づいて分析し削減を実現
ある府省の利用者が全国にわたる大規模情報システムにおいて、業務・システムの見直しを行うプロジェクトを実施しました。このプロジェクトでは、見直しの目的にシステ
ム経費の削減を掲げ、まずは現状調査を詳細に行いました。
従来のサーバ構成指針は以下に示す内容でした。
個別業務の継続性を重視し、サーバを機能ごとに分散させ、十分な冗長性を持たせる。
将来の大幅な需要拡大予測に基づきシステム規模を設計
業務ピーク時を含めた最大ＣＰＵ使用率が 50%となるように設計
現状調査の結果、ＣＰＵ使用率が低調なサーバが存在することが明らかになり、保守ノウハウの蓄積により、一定程度のサーバ削減を行っても安定稼働が担保されると判断し、以下に示す対策により、サーバ台数の大幅削減を実現し、見直し後の情報システム
において大きな成果を上げました。

この調査の過程で、メモリ使用率はピーク時に 90%近くに達することがある一方で、

-

24 -

事例 9-5
ハードウェア保守費を実績に基づいて分析し削減を実現

（第３編第９章 運用及び保守）

CPU はピーク時でも 10%台と低位にとどまっていることがわかりました。
そこで、システム更改後にサーバ構成を見直すだけでなく、現時点においても見直しが行えないか検討を行いました。具体的には、ほとんどのサーバは 2CPU 構成となっていたため、稼働中のサーバから CPU を１つずつ取り去ることのコストメリットを検討しました。
その結果、ソフトウェアの保守体系が CPU 単位での課金となっており、CPU を撤去することで、撤去作業のための経費を考慮しても、現在の保守料金を大きく減額できることが判明しました。また、業務要件に照らし合わせて CPU を一部撤去しても業務上の影響は発生しないことが確認できたため、実際に CPU を一部撤去し、見直し後の情報システムの稼働を待たずに、稼働中の情報システムのソフトウェアの保守料金を削減することもできました。

運用・保守における変更管理を理解する
運用・保守フェーズでは、基本的にはその時点で提供しているサービス・業務を変えることなく、情報システムを維持し続ける活動を行います。現状を維持するためには、変えないことが最も安全な方法で、何か変更するということは、何らかのリスクを伴います。現状維持するだけであっても、最低限必要となる変更作業は存在するため、その作業を適切に管理し、安定運用を継続する「変更管理」の活動は、とても重要です。
運用と保守で行う変更管理の対象は、大きく２種類に分かれます。

変更管理の対象の分類作業に係る情報への変更管理
運用の要件定義書、調達仕様書、運用計画書、運用実施要領、作業手順書等。
情報システムを構成する資産等に対する変更管理
設計書、ソースコード、マニュアル等。ライブラリ管理と呼ばれることもある。
特に、後者については、運用と保守で管理する内容が重複することもあり、混乱しがちですが、以下のような違いがあります。

運用と保守の変更管理の違い
運用の変更管理では、誰が修正するかに限らず、情報システムを構成する全ての資産とそれに対して行われる全ての変更を管理する。つまり、これを確認すれば、情報システムに対して行われた全ての変更について、「いつ」「誰が」「何の理由で」「何を」変更したかを確認することが可能。
保守の変更管理では、保守事業者の保守対象となる設計書やソースコード等に関する変更を管理する。
運用の変更管理は、情報システムの全ての変更情報を管理する必要があるため、保守事業者が複数いる場合であっても、統一的に管理する必要があります。そのため、変更フローを明確に定めて、情報システムに変更を行う可能性のある全ての事業者に対して、周知徹底する必要があることに注意してください。
以下に、参考として、変更管理のフローの例を記載します。

-

25 -

（第３編第９章 運用及び保守）

図 9-4
変更管理のフローの例

-

26 -

（第３編第９章 運用及び保守）

Step.

4 運用・保守の定着と次への備え

運用・保守の事業者とともに計画の策定が終わりました。あとは事業者にお任せしていれば大丈夫。・・・ということはありません。運用・保守を行っていく中では、日々様々な問題が発生しますし、当初計画した内容では足りないことや改善が必要になることもあります。これらの情報を事業者から適時吸い上げ、改善につなげていくには、いくつかのポイントがあります。
この Step では、運用・保守の作業を効果的に管理していくことで、サービス・業務をより良いものへ導いていくためのポイントについて解説していきます。

１ 運用定例会議を有効活用する【標準ガイドライン関連箇所：第３編第９章第２節 1)ア】

運用・保守フェーズで、ＰＪＭＯが情報システムの状況を確認・把握する場面は、主に運用・保守を実施する事業者が参加して状況を報告する運用保守定例会議が中心となります。しかし、会議に出席して漫然と事業者の報告を聞いているだけでは、事実を捉えて改善を推進
していくことはできません。ここでは、運用保守定例会議を有効活用していくためのポイントを見ていきます。

運用保守定例会議で確認する内容を理解する
運用保守定例会議では、運用・保守の計画で定めた報告フォーマットに従って、事業者
から基本的には毎回同じ項目の報告を受けることになります。そこでは、外部委託事業者
からの報告を受け取るだけではなく、その内容を把握・分析し、根拠が不明なもの、報告が不十分なものは、指摘・再提出も求め、改善活動に繋がる課題や改善点を報告内容から
見出し、発注者側がプロアクティブに定点観測する事が大切です。
事業者が「問題なし」と報告している内容でも、「問題あり」に近い「なし」や、状況を把握していないために「なし」と報告しているような場合もあるため、少しでも疑問を感じたら事業者に説明を求めましょう。
また、毎回同じ項目が定期的に報告されるという特徴から、長期間にわたる推移を把握することも可能です。事業者はある時点で切り取った報告を行いますが、その情報を線でつなげて分析し改善に活用しましょう。
いくつかの事例を見ていきましょう。

事例：実際のＰＣ故障率を確認し保守コスト低減に成功ある府省では、職員が使用するＰＣの故障に備えて、機器の保守事業者と高額な数
年単位の定期保守契約を締結していました。
ある年度において、運用・保守コストの削減を行うため、ＰＣ故障時に保守事業者を利用した回数について運用保守定例資料を過去から遡って確認しました。その結果、故障率は低く、年間数回しか保守対応を利用していないことが判明したため、定期保守契約の終了を契機に、スポット対応の保守契約に変更し、大幅な保守費用の削減を実現しました。

-

27 -事例 9-6
実際のＰＣ故障率を確認し保守コスト低減に成功（第３編第９章 運用及び保守）

この事例では、定期保守に加入していた場合、保守事業者を利用する回数が多くても少なくてもコストには影響がないため、運用保守定例資料でその回数が報告されていたとしても、あまり注目はされません。しかし、別の視点でその数字を分析することにより、異なる目的で活用できることがわかります。

運用保守定例会議では、情報システムのハードウェア、ソフトウェアに関する報告だけではなく、ヘルプデスク等の「人」を対象にした運用に関する報告も行われます。

事例：評価指標の分析結果をユーザ満足度向上につなげる
ある府省の情報システムでは、ヘルプデスクの評価指標に従来の問い合わせ件数や期限内回答率に加え、回答に至る経緯をオペレーターがその場で即答した「自己解決」と管理者へのエスカレーションを経由した「折り返し連絡による回答」に分類して、サポートデスクの質の評価を行っています。

サービス開始当初の運用保守定例会議で報告された自己解決率は 60%程度でしたが、ヘルプデスクへその数値を共有し、エスカレーションされた 40%の内容を分析した結果を基にマニュアルへの追記やＦＡＱへの掲載、オペレーターの教育等の対策を行うことにより、現在の自己解決率は 90%程度まで向上しました。

-

28 -

事例 9-7
評価指標の分析結果をユーザ満
足度向上につなげる（第３編第９章 運用及び保守）

ヘルプデスクの自己解決率が向上したことで、利用者からの様々な問い合わせにも即時に回答できるようになるとともに、ヘルプデスクからのエスカレーションを受けて、調査等を行っていた職員の負荷も軽減することができました。

事例：データの取得粒度を変更したら事象が異なって見えることもある
日中はオンラインサービス、夜間はバッチ処理が中心というある省の業務システムにおいて、夜間のＤＢサーバとバッチ処理を行っているサーバのＣＰＵ使用率が、高い状態となる日が頻繁にあると報告されていました。（下図）80.0%

瞬間ピークは
70%程度

70.0%
60.0%

実質的なピークは
30%程度

大きな差

50.0%
40.0%
30.0%
20.0%
10.0%

23:30:00

23:00:00

22:30:00

22:00:00

21:30:00

21:00:00

20:30:00

20:00:00

19:30:00

19:00:00

18:30:00

18:00:00

17:30:00

17:00:00

16:30:00

16:00:00

15:30:00

15:00:00

14:30:00

14:00:00

13:30:00

13:00:00

12:30:00

12:00:00

11:30:00

11:00:00

9:30:00

10:30:00

9:00:00

10:00:00

8:30:00

8:00:00

7:30:00

7:00:00

6:30:00

6:00:00

5:30:00

5:00:00

4:30:00

4:00:00

3:30:00

3:00:00

2:30:00

2:00:00

1:30:00

1:00:00

0:30:00

0:00:00

0.0%

この情報システムは、安定運用のために、十分な余力を確保して複数台のサーバを稼働させており、サーバのＣＰＵ使用率の報告からも、適切なサイジングがされているものと捉えていました。ただし、潤沢なサーバ構成としていたために、高い維持コストが課題となっており、見直しが可能か検討することとなりました。
そこで、日単位の平均とピークのみで報告されていたＣＰＵ使用率を、１分単位のヒートマップで分析を行ったところ、特定の時間で数分程度ＣＰＵ使用率が上昇している
ものの、大半の時間の使用率は 10%未満であることが把握でき、ピーク時の負荷の分散を検討しました。（下図）

-

29 -

事例 9-8
データの取得粒度を変更したら事象が異なって見えることもある（第３編第９章 運用及び保守）

一分単位の詳細な単位でＣＰＵ使用率を把握した結果、ＣＰＵ使用率がピーク近くになるのは、ごく僅かな時間帯にすぎないことがわかりました。また、この時間帯に動いている処理は、運用等を目的としたバッチ処理であり、処理時間が多少長くなっても業務への影響が全くないことがわかりました。
この分析により、サーバ構成についてもっと踏み込んだ削減が可能であることが判明
し、コスト削減に寄与することができました。

これらに共通していることは、「プロジェクトの目標を達成する」「サービス・業務をより良くする」という視点に基づいて、それらの判断や改善に必要となる事実を正しく理解する。という姿勢です。
以下に確認のポイントをまとめます。

運用保守定例会議での確認のポイント
指標値等の基準を明確にし、基準を満たしているのか、満たしていないのか、
今後どうなる見込みなのかを確認する。
定常どおりの内容よりも、特筆すべき事項を事業者から引き出す。
定点観測だけでは問題を見落とす可能性がある。時間軸を変えたり、集計の仕方を変えたりする等、様々な視点から状況を捉える。
根拠が不明なもの、主観的なものには注意が必要。エビデンスを求める。
ピーク性や今後のイベント等を踏まえて、リスクを確認する。
発生した課題だけではなく、累積している課題に対する対応状況も確認する。
ライセンスや保守期限等を確認し、次年度以降の予算要求に備える。

-

30 -

（第３編第９章 運用及び保守）

２ 変更を管理し改善活動等の初動を楽にする【標準ガイドライン関連箇所：第３編第９章第２節】

情報システムを長期間運用していると、運用・保守の作業や機能改修によって、情報シス
テムにたくさんの変更が行われます。これから改善活動や機能改修を検討しようとしたときに初めに行うことは、設計書等から現状の情報システムがどのようになっているかを確認することです。しかし、その設計書は本当に最新の情報システムを反映したものでしょうか？
Step.3-1-H．「運用・保守における変更管理を理解する」で説明したとおり、最新の設計書
や情報システムがどのような理由でいつ変更されたかは、運用の変更管理の作業で管理されます。
なお、変更管理の方法には様々なものがありますので、プロジェクトの事情に合わせて、効率的に管理できる方法を検討してください。

変更の管理方法に関する検討ポイント
設計書やソースコード等は変更管理ツールでバージョン等を一元管理することが一般的である。それらの変更管理ツールを、発注者側で管理するか、運用事業者が管理するかは検討する。ライブラリ管理チームを組んで管理することも効果的である。
環境の事情等で発注者側が最新の変更管理ツールにアクセスできない場
合、最新の設計書等の授受方法やタイミングを明確に定める。
設計書やソースコード等のバージョンと変更の事由や本番環境への反映記録
等の一貫して追跡できるように記録をつける。これらを一貫して管理するツール等も存在するため、導入を検討する。

３ 情報システムで起こった事実を蓄積する【標準ガイドライン関連箇所：第３編第９章第２節】

運用・保守作業により事業者からデータを収集できました。そのデータを目の前にして、どうしたらよいか困っていませんか？改善を検討するに当たって、本当にその情報だけで十分でしょうか？ここでは、改善を検討する際のデータ収集に関するノウハウを見ていきます。

運用・保守の範囲にとらわれず、意味のある情報を取得する
利用者からの問合せは、実際に対応する人やその結果も様々だと思いますが、どんな問い合わせが、いつ、どこから発生し、どのような結果となったかの一連の流れを記録することを推奨します。これにより、あとで集計したり、分析したりすることが可能となり、どういった問題・ニーズがあるのかを、アンケート等で再収集しなくても取ることができます。
これは、運用・保守業務として、運用・保守事業者に求める業務とは異なります。こちらはシステム側面での問い合わせ・問題・インシデント管理であり、先に挙げたものは業務側面でのものです。
相互に連携する部分もあるため、運用・保守業務の管理情報も併せて収集して、一貫して記録し、集計・分析することで効果をあげることができます。また、分析結果から得られた情報を、利用者が参照できるＦＡＱへ追加し、業務マニュアル等の改訂に活用することも可能です。改善を検討する際は、定点の情報だけでなく、一連の流れに沿った視点も分析してみてください。

-

31 -（第３編第９章 運用及び保守）

事例：業務運用に貢献するレポート機能の追加

事例 9-9業務運用に貢献するレポート機
能の追加

実践ガイドブック「第４章 Step.4 業務の現状把握」で、ある経費積算業務における時間を要している処理業務の、原因分析に関する事例で紹介した「へび図」の作成方法にも一工夫しています。
当初この情報システムには、分析するために必要なデータを抽出する機能が存在せず、職員が手作業で１件ずつ確認しながら資料を作っていたため、非常に煩雑で手間が掛かっていました。
そこで、業務の作業実績の分析は今後も継続的に必要と判断し、情報システムを改修して、必要な情報が記録され、かつ、１ボタンでデータが取得できる「へび図抽出機能」を追加しました。
その結果、この業務の一連の処理状況が、職員に負荷をかけることなく、ほぼ毎
月正確に把握できるようになりました。

情報システムの活用状況を詳細に把握し提供する機能を棚卸しする
情報システムは、提供する機能数が多く・複雑なほど、運用・保守コストが増大する傾向があります。特に、長く運用している情報システムでは機能の追加・改修を重ねられていることが多く、その傾向が顕著に現れます。
このことを防ぐためには、定期的に機能の棚卸しをすることにより、肥大化を防ぐことが有効です。
棚卸しをするに当たり、利用者へのアンケート等で業務における利用状況を把握する方法があります。さらに、機能ごとの利用ログを情報システムから取得し、分析することでより厳密に利用状況を把握することも可能です。
これらの情報を踏まえて、機能の廃止・縮小対象の検討がより具体的に行えるため、定期的な棚卸しを行うようにしてください。

事例：機能単位で情報システムの利用状況を可視化
運用フェーズにおける各府省が共通で利用する政府情報システムの機能が、実際の業務において、どの程度活用されているか把握し、情報システムの見直しを行う

-

32 -

事例 9-10
機能単位で情報システムの利用状況を可視化（第３編第９章 運用及び保守）ことになりました。
そこで、情報システムが提供している機能を全てリストアップし、府省ごとに利用状況の調査を行い、当該機能を利用して「業務を全て遂行」「他の手段も併用」「全く利用していない」の３段階で回答するよう依頼しました。
回答結果を、機能、府省単位で色分けして可視化したところ、全く利用されていな
い機能や、ばらつきのある機能などが明確になりました。

この調査結果と、情報システムから取得した利用ログの集計結果の値を用いて、「全く利用していない」機能は廃止の検討を、「他の手段も併用」は、機能改善検討の対象として効率的に抽出することができました。

情報システムのログやトランザクションデータから改善のための情報を取得できるようにする
情報システムのログやトランザクションデータは、「情報システムが何をいつどのように処理したか」を記録として残すことに主眼がおかれがちですが、指標値や改善を検討するための情報を残すという視点も必要です。この視点がないと、運用や保守の作業で分析するための情報を取得することがとても大変になったりします。

-

33 -

（第３編第９章 運用及び保守）

図 9-5
目標・指標・データの関係性のイ
メージ

しかし、要件定義や設計・開発の時点では、機能を提供することに目が行きがちで、実績に基づいたモニタリングまでを意識した検討ができている情報システムが多くないのが現実です。
運用や保守の作業でデータが取得できない場合やデータ取得に工数が膨大にかかるような場合、情報システムでデータ取得が容易にできないかを検討してみましょう。これらの検討は、標準ガイドライン「第８章 サービス・業務の運営と改善」での検討を踏まえて決定します。
情報システムから正確で詳細なデータを手に入れたことで、効果的な改善を行えた例がたくさんもあります。
なお、サービスや業務の目線で、ログから判別できる指標には、次のようなものがあります。これらを参考に、情報システムで取得できるデータがないかを見直してみてください。

参考：サービス・業務の視点で取得可能な指標の例
ログからデータ取得できるが、機能単位等の集計が難しいもの。これらは、機能ＩＤ等の判別情報をログに付加することで、集計や分析が容易になる可能性があります。
期間（滞留状況）
頻度（業務ピーク、業務効率）
利用件数、利用率
情報提供数
嗜好等を含むため、通常の情報システムで取得が難しいもの。これらを取得する
ためには、アンケート機能等のデータ取得用の機能が必要になります。
選好（Ａ/Ｂ分析）
ニーズ分析（相関）
満足度

-

34 -

参考 9-4
サービス・業務の視点で取得可能な指標の例

（第３編第９章 運用及び保守）

設計時に考慮が漏れがちなもの。何をどのように記録するかを検討し、記録する機能を作成します。
不正防止（個人情報は指定された用途以外に記録してはいけません）
オープンデータ の利用数

情報システムを長期間運用していくと、データ量が増大したり、アクセス数が変化したりすることによって、情報システムのパフォーマンスが悪化することがあります。例えば、デー
タベースの性能一つをとっても、チューニングの良し悪しでレスポンスは何十倍も変わることがあります。
このような場合に、日常的な保守業務の一環としてレスポンスやバッチ処理時間の性能指標を測定して、悪化傾向が見えた場合は、それがシステム障害として顕在する前に対策を行うことが重要です。

-

35 -

（第３編第９章 運用及び保守）

Step.

5 運用・保守の改善と業務の引継ぎ

運用保守定例会議等で出た課題や運用・保守事業者から取得したデータから見えてきた
改善点は、運用・保守業務の範囲内で解決が可能なものは、積極的に改善を進めていきます。しかし、運用・保守が安定していれば改善を行う余裕があるかもしれませんが、リリース直後やサービス・業務が定着していない時期では、日々の作業が多く改善が難しいことも多々あります。
ここでは、事業者の引継ぎも含めて、改善に係るノウハウをお伝えしていきます。

１ 適切な時期に的確に改善を実行する【標準ガイドライン関連箇所：第３編第９章第３節】

運用・保守の改善は、Step.3 で把握した事実とその分析結果に基づいて、継続的に実施
していきます。改善の内容には定常的な作業の範囲内で実施できるものもあれば、契約更新
や事業者の交代、ライセンスの切れ目やハードウェアの交換でしか対応ができないもの等、様々なものがあります。
これらは、対応できるタイミングが同一にはなりませんので、以下の点に留意して、確実に改善につなげるようにします。

改善を管理するポイント
運用・保守の定常的な作業内で解決が難しい課題は、標準ガイドライン「第８章 サービス・業務の運営と改善」内の問題管理として、どのタイミングで対応するかを明確に管理する。
事業者の交代やライセンスの切れ目で改善が可能なものは、それによって必要となる変更内容（受注者側の体制、作業項目、工数等）も記録しておく。

事例：インシデントの判断基準及び役割分担を見直しある府省では、この数か月に起きたシステム異常（いわゆるインシデント）において、見かけ上似たような状況にもかかわらず原因が全く異なるという状況に遭遇していました。これにどのような運用・保守態勢で対応していくかについて悩みを抱えていました。
具体的には、機器の障害が２件、ミドルウェアの不具合１件、情報セキュリティ上の問題２件、アプリケーションソフトのバグが１件。これらはいずれも業務処理性能を著
しく低下させる現象を引き起こし、見かけ上はほとんど同じような状況を引き起こしていました。
基盤運用担当のチーフエンジニアにそれぞれのケースを分析させたところ、原因の切り分けには、いくつかの事業者に分かれた重要ポイントをチェック（システムリソ
ース、ネットワーク、セキュリティシステムログ、アプリケーション実行状況等々）し、そ

-

36 -

事例 9-11
インシデントの判断基準及び役割
分担を見直し（第３編第９章 運用及び保守）

れらを統合的に把握・判断する必要があることが明らかになりました。
ＰＪＭＯと関係業者で協議した結果、夜間休日を含めて基盤運用担当事業者、セキュリティシステム運用事業者及び業務保守・運用事業者が協働してチェックする手
順プロセスを確立しました。この過程において、各業者の役割分担の見直しも行い、
オペレーション上の権限範囲も見直しました。合わせて「機器・ＯＳミドルウェア障害」「ネットワーク障害」「アプリケーション障害」「情報セキュリティインシデント」の監視と対応の態勢を見直して、以下の情報連携態勢を構築しました。
インシデント共通の情報連携ネットワーク（運用状況ポータルＷＥＢ、電話、メー
ル、ビジネスチャット）を構築した。これによりＰＪＭＯ、ヘルプデスク、基盤運用事業者、ネットワーク管理事業者、セキュリティシステム運用事業者、業務運用事業者及び業務システム保守事業者がインシデント情報を共有することが可能となった。
各インシデントの深刻度評価を動的に管理することとし、指示連絡ライン（一次対
応指示のリーダーは 24Ｈの基盤管理事業者のチーフエンジニア）を一本化した。また、原則として評価値によって行動優先度や夜間休日の対応をコントロー
ルしていくこととした。評価値は、「０」、「０＋」、「１」、「２」、「３」の５段階※とし、事態が流動的な状況では各関係業者のエンジニアが宣言した値のうち最大のものを採用することとした。（※おおよその目安として、「０」と「０＋」は被害なし。「１」はシステム被害、「２」と「３」は業務及び第３者被害発生。）

緊急時（上記の評価値「１」以上の時）には、一定の範囲内で各業者担当範囲外の実施権限（抜線、コマンド投入など、ＰＪＭＯには事後報告で可）を付与することとし、順次担当業者から別の業者に実施方法を伝えていった。
四半期に１度、緊急性評価値の見直しや緊急対応手順の改善について、職員と関係業者で話し合って、継続的に対応力の強化を図っている。その結果、徐々に各業者エンジニアが判断可能な対応範囲が拡がってきている。

２ 要員の交代で情報が欠落しないようにする【標準ガイドライン関連箇所：第３編第９章第４節】

運用・保守フェーズでは、人事異動による職員や様々な事情による事業者の交代が発生することがあります。交代が職員、事業者のいずれであっても、担当していた期間が短けれ
ば、持っている情報も多くないため影響は少なくなりますが、特定の人物が長期間担当していた場合、ノウハウや情報がその担当者の頭の中だけに記憶され、引き継ぐべき情報が欠落してしまうというケースが散見されます。
運用・保守作業には、数年先などの適切な作業時期が到来しないと実施できないものや、細かい作業のため見落としてしまうものもあります。運用・保守フェーズに発生する膨大なタス
クを抜け漏れなく管理するためには、ツールの導入等も検討し、職員や運用・保守事業者が交代しても確実に継承されるような工夫が必要です。

事例：担当者の交代により次年度で必要な作業が漏れてしまった
ある府省の運用・保守フェーズにある情報システムの運用・保守定例会議において、運用・保守事業者より、あるサーバのＯＳのバージョンアップに伴い、ミドルウェアにパッチ適用が必要になるという報告がありました。ただし、そのＯＳのバージョンアッ

-

37 -

事例 9-12
担当者の交代により次年度で必要な作業が漏れてしまった

（第３編第９章 運用及び保守）

プは次年度以降の予定という情報のみで、具体的な時期については未確定のため、パッチ適用の具体的な作業時期は確定できない状況でした。報告を受けたＰＪＭ
Ｏである職員Ａさんは、ＯＳのバージョンアップ時期が確定した段階で、改めて対応を検討することにしました。

その後、職員Ａさんは異動することになり、職員Ｂさんが後任となりましたが、年度が変わっても同一の運用・保守事業者が継続することになったため、職員ＡさんはＢ
さんへの引継ぎは重要なポイントに絞って行いました。
年度が変わってしばらく経過した後、あるサービスが停止してしまいました。そのサービスを提供しているアプリケーションが稼働しているサーバのミドルウェアが起動しなくなったのが原因でした。更に調査したところ、トラブルの前日にサーバのＯＳをバージョンアップする作業を行っていたことが判明しました。本来はこのバージョンアップに伴い、前任のＡさん担当時に報告されていたミドルウェアへのパッチ適応作業が必要だったのですが、対応が漏れてしまいました。

前任のＡさん担当時に報告された時点で、パッチ適用作業について、運用・保守
事業者に継続調査事項として管理するよう指示し、作業が完了するまで関係者が認識できるように記録した上で状況を確認するようにしておけば、このような重要な作業の抜け漏れは発生しませんでした。

事業者が交代するとノウハウやドキュメント化されていない情報が抜け落ちてしまうことで作業効率が下がるリスクがあります。また、場合によっては、事業者が情報を持ち逃げするリスクもあり、持ち逃げされた情報を取り戻すために費用が発生するような事例すらあります。
このような事態を避けるためにも、職員や運用・保守事業者の交代時には、以下の点に注意して、情報が抜け落ちてしまうことを防ぎます。

-

38 -

（第３編第９章 運用及び保守）

職員や事業者の交代の際に気をつける点
計画時点で作業に対する成果物を明確化する。作業を実施する場合は、基本的に作業手順書を作成し提出するよう、合意する。
中間成果物となるようなドキュメント・コンテンツは、維持が必要なもの、維持が必要ないものを明確にしていく。
運用・保守作業に関係する事項は、職員や事業者の特定の担当者が抱え込
むことなく、必ずその作業を担当する事業者が管理するドキュメントに記載し管
理する。

-

39 -

デジタル・ガバメント推進標準ガイドライン

デジタル・ガバメント推進標準ガイドライン
実践ガイドブック（第３編第１０章-

システム監査）1 -（第３編第１０章

システム監査）目次
Step.1 システム監査の全体の流れ .............................. 4
Step.2 システム監査の理解....................................... 5
１ システム監査とは何かを理解する................................................. 5
監査の種類を理解する ..................................................... 5システム監査は問題解決の近道となる ................................. 5システム監査基準・システム管理基準を理解する ................... 6
２ システム監査の全体像を理解する................................................. 7３ 適切な監査が行える体制を作る ................................................... 8

Step.3 システム監査計画と監査実施計画 ................... 10
１ 複数年の監査計画を立てる ....................................................... 10
２ システム監査実施計画書を作る ................................................. 11
監査範囲が局所的にならないように注意する ....................... 12
監査実施方法に注意する ................................................ 12

Step.4 システム監査の実施..................................... 14
１ 予備調査を踏まえ監査手続を具体化する ...................................... 14
監査手続書を作成するまでの流れを掴む............................. 14
２ 根本原因を究明し改善点を発見する ............................................ 16
インタビュー時には情報を上手に引き出す .......................... 16
改善提案は報告の場で具体例を混ぜながら行う .................... 17
システム監査報告書の様式を把握する ............................... 18

Step.5 指摘事項を踏まえた改善 ............................... 19
１ 改善計画を立て改善を行う ....................................................... 19-

2 -（第３編第１０章 システム監査）

事例・参考の一覧
参考：経済産業省 システム監査基準・システム管理基準 ........................... 6
事例：職員が中心となりＣＩＯ補佐官の助言を得ながら監査する................... 9
様式例：システム監査実施計画書のひな形 ............................................. 11
事例：変更管理の妥当性を監査する手続を検討する ................................. 14
事例：ある省でのシステム監査の効果向上への取り組み ............................ 17
様式例：システム監査報告書のひな形 .................................................. 18※事例には当時の役職名やシステム名を使用しているため、現在使用されていな
い名称が記載されている場合があります。

-

3 -（第３編第１０章 システム監査）

Step.

1 システム監査の全体の流れ

ＰＪＭＯの皆さんは、プロジェクトの目標達成に向けて、日々課題やリスクの管理をしていることでしょう。しかし、日々のプロジェクト管理等に忙殺されると、そもそもの管理方法が適切かどうか、といった観点での改善まで至らない、又は気づかないことが多いのも実情です。
システム監査は、各プロジェクトの取り組みが、その目標達成に正しく向かっているのか、
プロジェクトの各フェーズでの実施プロセスは適切か、仕様どおりに機能しているか、目的に照らして適切な仕様となっていたのか、といった観点から現状を調査し、改善すべき点がないかを第三者の視点で客観的に点検・評価する活動です。システム監査を行うことにより、プロジェクトの目標達成を阻む様々な問題が抽出され、種々のリスクへ適切に対応できるようなり、結果としてプロジェクトの成功（プロジェクトの目的達成）への近道になります。
ここでは、システム監査に向けた準備や実施に際して必要となる作業について説明します。
本ドキュメントの構成は、次のとおりです。

Step.2 システム監査の理解
システム監査を行う前に、理解すべき監査の目的・活動や、必要な事前準備の内容について説明します。

Step.3 システム監査の実施計画
監査体制は、府省全体のシステム監査計画を基に対象のプロジェクトを監査するための実
施計画を立案しますが、立案において気をつけるポイントについて説明します。

Step.4 システム監査の実施
監査体制は、システム監査実施計画に則りシステム監査を実施しますが、具体的にどのよ
うに進められているかを実際の事例を基にご説明します。

Step.5 指摘事項を踏まえた改善
ＰＪＭＯは、ＰＭＯ等、監査実施者からのシステム監査報告書の指摘を踏まえて改善を行いますが、改善の際に気をつけるポイントについて説明します。

-

4 -（第３編第１０章

Step.

システム監査）2 システム監査の理解「システム監査」と言われても、携わったことのない方にはどのようなことをするのかイメージが湧きにくいかもしれません。ここでは、標準ガイドラインで扱うシステム監査の目的や全体像と、監査する側の準備について、説明します。

１ システム監査とは何かを理解する【標準ガイドライン関連箇所：第３編第１０章第１節】

監査の種類を理解する「監査」と聞くと、会計検査院が実施する会計検査や、会社法、金融商品取引法に基づく財務諸表監査を思い出す人も少なくないと思います。これらは、会計監査に当たります
が、標準ガイドラインで扱うシステム監査は、業務監査の一部に位置付けられます。また、監査人が誰かにより監査が分類されることもありますが、その分類においては内部監査に当たります。
また、システム監査と混同しがちな監査に、情報セキュリティ監査があります。情報セキュ
リティ監査は、元々はシステム監査における監査テーマの一つであり、近年、情報漏えい等の多くの情報セキュリティに関する事件・事故が多発してきた結果として、情報セキュリテ
ィに特化した監査として定着してきているものです。
これらの関係を示せば、次のようなイメージとなります。

図 10-1
一般的な内部監査における各監査の関係性では、システム監査は何のために行うものでしょうか？

システム監査は問題解決の近道となる標準ガイドラインでは、システム監査の目的を次のように示しています。

ＰＭＯは、プロジェクトの目標を達成することを目的として、所管する情報システム
にまつわるリスクに適切に対処しているかを客観的に評価するために、内部又は外部からの支援を得て、次のとおり監査を行うものとする。
（標準ガイドライン「第３編第１０章 システム監査」）-

5 -（第３編第１０章

システム監査）システム監査は、プロジェクトの目標を達成するための活動です。日々のプロジェクト管理作業に追われていると、近視眼的に作業効率を重視するあまり、本来の目的を見失ってしまい、当初の目的から外れた活動（手段が目的化してしまう等）になったりしてしまうことが少なくありません。これらを是正せずに作業を続けた場合、情報システムが意図したとおりに構築・改修されない、不必要な機能構築や人件費の積算、不適切な業務・システムの運用の定着、情報漏えい等の様々なリスクが顕在化することにより、プロジェクト目標が達成されないおそれがあります。これらを未然に防止するために、客観的な視点からプロジェクトの活動を点検・評価し改善していく活動がシステム監査です。ＰＤＣＡサイクルにおける「Ｃ」チェックに相当します。
そのため、システム監査では、例えば、「不具合が多く発生しているから問題である」という現象を評価するのではなく、不具合を発生させている原因についての言及する、例えば「不具合を収束させるためのプロセスや体制に問題がある」、「不具合が組み込まれやすい
プロセスになっている」というような評価をすることになります。
なお、どのような目的で監査を行うか、何を評価するかは、ＰＭＯが定め、システム監査の府省全体の計画である「システム監査計画書」としてまとめます。監査の対象となるプロ
ジェクトもこの中で定められます。
監査対象に選ばれたプロジェクトは、本システム監査が問題解決のきっかけになります
ので、監査結果による指摘への対応を含め、ぜひ前向きに捉えて取り組んでください。
システム監査の準備や実施には、監査する側も受ける側も、ともに時間を要します。効率的にシステム監査を進められるよう、ＰＭＯ等の監査実施者の求めに応じ、監査対象となったプロジェクトの皆さんの協力が必要となります。例えば、システム監査の実施計画を立案するために必要な日程・関係者等の調整や、必要な資料の提供、インタビューへの出
席、質問への回答等がありますので、監査対象のＰＪＭＯは積極的に協力してください。

システム監査基準・システム管理基準を理解する「システム監査基準」及び「システム管理基準」は、経済産業省が策定・公表した、システ
ム監査を適切に行うための基準です。
「システム監査基準」とは、システム監査の品質を確保し、有効かつ効率的に監査することを目的とした、監査体制（監査責任者及び監査実施者）の行為規範及び監査手続の規則等を規定したものです。この基準は、様々な視点での監査をカバーし、また様々な組織が利用できるよう、汎用性のある内容になっています。
「システム管理基準」とは、監査の効率的･効果的遂行を可能にする判断の尺度を規定したものです。この基準は、情報システムの管理において共通して留意すべき基本的事項を体系化･一般化したものですので、対象となるプロジェクトの目的や業務の特性、情報シ
ステムの特性等に照らして適切な項目の取捨選択や対応内容を修正するなどを適宜行いながら活用してください。

参考：経済産業省 システム監査基準・システム管理基準
このドキュメントは、以下のＵＲＬで公開されています。
http://www.meti.go.jp/policy/netsecurity/sys-kansa/h30kaitei.html-

6 -参考 10-1
経済産業省 システム監査基準・
システム管理基準

（第３編第１０章

システム監査）２ システム監査の全体像を理解する【標準ガイドライン関連箇所：第３編第１０章第１節】

システム監査には、いくつかの役割が存在します。大きく分類すると、監査計画・報告に関する承認（合議制機関（府省の情報化推進委員会等）など）、監査の指示（ＰＭＯ）、監査の実
施主体（監査体制）、監査対象（ＰＪＭＯ）の４つに分かれます。
以下の図にてシステム監査の体制と関係を示します。

図 10-2
システム監査の全体体制

ＰＪＭＯが監査を指示する場合であっても、監査を行う監査体制は、ＰＪＭＯとは独立した体制とすること（客観的な評価が行えること）がとても大切です。監査体制については、「３ 適切な監査が行える体制を作る」で詳しく触れます。
次に、監査のおおまかな流れをご紹介します。

-

7 -（第３編第１０章 システム監査）

図 10-3
システム監査の流れ

具体的な内容は、以降で触れていきますので、ここでは、システム監査の大まかな流れをつかんでいただければ結構です。

３ 適切な監査が行える体制を作る【標準ガイドライン関連箇所：第３編第１０章第１節 1)】

監査体制は、監査対象となるプロジェクトの体制や進め方を客観的に点検・評価する趣旨
から、原則として、そのプロジェクトの利害に関係しない及びしたことがない者で構成されることが望ましいです。これは、利害関係者が関与した場合、問題点の抽出や見直しを客観的に実施できない可能性があるためです。場合によって、一部の作業を外部事業者に委託し、監査を実施することも可能です。
さらに、監査体制には、業務に詳しい者とＩＴに詳しい者の両者が必要となります。監査は、その実施に当たり、情報システムの目的すなわち、情報システムを活用した業務で達成すべき目的あるいは目標が実現されているかが主要な観点となるため、業務の視点からの課題の抽出、助言の実施は欠かせないものとなります。また、当然にＩＴに関する知見がないと、情報システム上の課題や助言ができない事になりますので、どちらかの視点が欠けても、課題の-8 -（第３編第１０章 システム監査）

抽出や提示する改善案の内容の網羅性（業務及び情報システムの両方の視点）を網羅、担保できない可能性が高くなります。
なお、監査体制に政府デジタル人材、高度デジタル人材が加わることも有効です。政府デジタル人材、高度デジタル人材が持つ様々な知見から、効果的な確認観点の抽出や効率的な実施方法の選定等をスムーズに行うことができます。

事例：職員が中心となりＣＩＯ補佐官の助言を得ながら監査するある省では、ＩＴガバナンス強化のため、管理プロセスの標準ガイドラインに対する準拠性と費用対効果の妥当性を評価することを目的としたシステム監査を実施する
ことにしました。その省には監査を専門とする部署がなかったため、ＰＭＯは、プロジ
ェクトとは直接関係のない部署の職員で監査体制を組織することで、客観的な評価が行えるようにしました。
しかし、監査を担当する職員の中には、システム監査や情報システム開発に関する理解度が高くない職員も見受けられたことから、正確な評価を行うことができず、形だけの監査になってしまう懸念がありました。
そこで、ＰＭＯは、監査に先立って、監査手続書のひな形やチェックリスト等を整備し、確認漏れを防止し、適切な監査手順で評価が行えるようにしました。また、ＣＩ
Ｏ補佐官が監査体制をサポートできるようにし、特に費用の妥当性評価等の専門的なＩＴ知識が必要な場面で監査体制に助言を行いました。
結果、監査体制は、適切な評価や改善提案を行うことができ、翌年度以降も同様の仕組みで継続的に監査を行っています。

システム監査に必要な人員が確保できない場合、監査体制そのものをＰＪＭＯが担うこともあります。ただしそのような場合でも、これまでの説明の趣旨に則り、できる限り、客観的な評価ができるよう心掛けてシステム監査を実施してください。

-

9 -事例 10-1
職員が中心となりＣＩＯ補佐官の助言を得ながら監査する

（第３編第１０章 システム監査）

Step.

3 システム監査計画と監査実施計画

システム監査を実施するには、監査の目的、監査の方針、監査の範囲やスケジュール、実施方法等を事前にしっかり計画しておく必要があります。ここでは、システム監査を実施するための計画の立案について、説明します。
システム監査の計画には、当該年度の監査の段取りを記載した監査実施計画と、複数年度にわたり組織としての監査方針を示す監査計画があります。
複数年にわたる監査方針を示した監査計画は、第２編第８章に「ＰＭＯは、毎年度、監査対象の追加等のシステム監査計画書の見直し（次の３か年分の計画の作成）を行うものとする。」との記載があるとおり、３か年程度の監査計画を立てることになります。

１ 複数年の監査計画を立てる【標準ガイドライン関連箇所：第３編第１０章第１節 2)】

監査計画を立てるには複数の考え方があります。経済産業省の「システム監査基準」にも記載されているとおり、システム監査には様々な視点があります。一方、省内には複数のプロジェクトがあり、その目的やプロジェクトの状況も異なります。１年で全ての監査項目を全てのプロジェクトで実施することは現実的ではありません。したがって、各年度で監査テーマあるいは監査対象を絞って監査を実施していく必要があります。そのため、複数年にわたる監査計
画を策定する必要があります。
具体的な監査計画の策定に当たっては、年度ごとに思いつきで監査対象や監査項目を選定したのでは、ＩＴガバナンスを構築できているとは言えません。したがって、省内のプロジェ
クトの数や規模、進捗等の状況に応じ、解決したい課題や問題意識を議論し、監査に対する一定の方針を立てる必要があります。
例えば以下のような例が考えられます。
予算、重要性ともに大規模プロジェクトが開始されるため、プロジェクトを滞りなく進捗するために、プロジェクトの各フェーズでリスクを最小化したい。この場合は、当該プロジェクトのフェーズに着目し、プロジェクトのライフサイクルに応じて監査を実施するように計画することになります。
省内複数のプロジェクトにおいて運用経費が増加しつつあり、システム予算の多くの部分が運用費となっているという問題意識があるとすれば、運用フェー
ズのプロジェクトを選択し、複数年にわたり複数のプロジェクトに対して同じ監査項目（運用におけるサービスレベルの妥当性や、業務内容と運用役務の妥
当性など）に着目して横並び比較や推移分析を行う監査を実施するべく計画を立てる。
ＰＭＯのＩＴガバナンス強化のために、監査基準にある一通りの監査項目を複数年で実施するために、省内のシステムの改修等のロードマップと監査項目を鑑み、複数年で対象システムと監査項目を変えるように計画する。
そのほか、各省の状況に応じた方針が考えられます。
本ガイドライン第３編２章で記載されている「プロジェクト工程レビュー」も PMO が指定した

-

10 -

（第３編第１０章 システム監査）

プロジェクトに着目し、プロジェクトの進捗に応じた監査項目により監査を実施している、シス
テム監査の一つと捉えることができます。
さらに、監査を実施する目的は、当該プロジェクトの継続的な改善活動を支援すること（ＰＤＣＡのＣに相当）ですから、一度だけ監査を行い、不備事項を指摘して終わり、というわけではありません。指摘事項を改善するための取り組みについてフォローアップして初めて実効的な監査となるわけです。したがって、複数年の監査計画には、必ずフォローアップの実施という項目が必要となることに留意が必要です。
ここで、監査計画を作成する際には、前述の監査の方針に加え、具体的な監査の観点等が必要となってきます。監査計画作成に当たっての具体的な事項等については、「システム監査基準」（経済産業省 平成 30 年 4 月 20 日改訂）を参照してください。なお、当該システ
ム監査基準では、監査計画を「中長期」「年度」｢個別｣の３種類の監査計画を策定するとされ注記「システム監査基準」（経済産業省 平成 30 年 4 月 20 日改訂）ていますが、本ガイドラインは「中長期監査計画」が「監査計画」、「個別監査計画」が「監査実施計画」に相当するものとして記載しており、「年度監査計画」については特に述べていません。しかし、各年度で実施する具体的な監査目的、対象、観点、スケジュール等の事項につては、「監査計画」あるいは「監査実施計画」に必要に応じて記載する事が望ましいと考えます。これは、「年度監査計画」を個別に作成することを妨げるものではありません。
具体的な監査計画の策定に当たり、実際の監査でどのような項目に着目して監査を実施
するかについて検討し、監査方針を決定していく事が必要です。そのためには、より具体的な監査項目について理解する必要があると考えます。その際には、「システム管理基準」（経済産業省 平成 30 年 4 月 20 日改訂）に記載されている、システムライフサイクルにおける管理項目が参考になります。また、この「システム管理基準」に記載されている管理項目につい注記「システム管理基準」（経済産業省 平成 30 年 4 月 20 日改訂）ては、監査実施計画を策定する際の監査項目として利用できます。監査で確認する具体的な項目は、システムのライフサイクを通じ不変なものと、ライフサイクルの各段階で異なってくる項目があります。具体的に監査実施計画を策定する場合には、両者を意識して監査項目を設定する必要があるでしょう。

２ システム監査実施計画書を作る【標準ガイドライン関連箇所：第３編第１０章第１節 2)】

監査体制の監査責任者は、監査計画に基づき、当該年度のシステム監査対象のプロジェクトに対して実施する監査の段取りを記載した監査実施計画を立案します。立案した監査実
施計画は、監査実施計画書として取りまとめ、監査者と被監査対象者で内容を共有します。
当該年度に複数の監査対象に監査を実施する場合は、原則監査対象ごとに監査実施計画書を作成することになります。この実践ガイドブックには、別添としてシステム監査実施計画書のひな形を示しています。

様式例：システム監査実施計画書のひな形
システム監査実施計画書のひな形を本章別紙としてまとめています。

-

11 -

様式例 10-1
システム監査実施計画書のひな形

（第３編第１０章

システム監査）飽くまで、このひな形は例示ですので、内容に応じて記載内容を個別に追加、変更して構いません。ひな形を見ると、何をどのようなレベルで書くべきかの参考になると思います。
以降では、システム監査実施計画書を作成するときに、特に注意が必要なポイントについて説明していきます。

監査範囲が局所的にならないように注意する
監査対象となるプロジェクト、監査目的、監査範囲となる工程等は、ＰＭＯが作成する府
省全体の計画である「システム監査計画」で示されます。個別の監査を実施するに当たっての監査範囲の設定は、個別監査の計画書である「システム監査実施計画」で記載します。そこでは、「システム監査計画」の項目の中で記載された監査範囲を、対象プロジェクトに合わせて具体化し記載します。
監査範囲を定義する際、監査範囲が局所的にならないように注意することが必要です。
監査範囲は、監査の目的に則ったものでなくてはなりません。特に、プロジェクトの中に複数の情報システムやサブプロジェクトがある場合は、注意が必要です。
例えば、監査目的が費用対効果の妥当性検証のような場合、システム監査計画で対象
工程や対象組織が定められている場合でも、プロジェクト全体で評価する必要があるかもしれません。そのような場合は、関連する他の情報システムやサブプロジェクトも監査の対象範囲として含める必要がないかを検討し、ＰＭＯと相談して対象範囲を決めてください。

監査実施方法に注意する
システム監査実施計画を立てる際に、特に気をつけるべき項目は、「監査実施方法」です。表面的なインタビューや資料の収集だけでは、プロジェクトが抱える問題にたどり着くことができません。そのプロジェクトの関係者はどのような人がいるのか、現在はプロジェクトがどのような工程にあるのか、といった情報を正確に把握するために、対象プロジェクトのプロジェクト計画書を入手した上で、ＰＪＭＯへのヒアリング・調整を実施し、誤った情報や誤

-

12 -

（第３編第１０章 システム監査）解に基づく判断とならないよう、必要な調査と評価の基準・方法を決めてください。その内容に基づき、全体のスケジュールを立案することが有効です。

-

13 -

（第３編第１０章

Step.

システム監査）4 システム監査の実施

監査体制の構成員である監査責任者及び監査実施者は、Step.3 にて立案した監査実施
計画に基づき、予備調査及び監査手続書にて具体的に決定した上で監査を行い、その結果について監査調書及び監査報告書を作成し、ＰＭＯに報告します。
ここでは、システム監査の実施について、説明します。

１ 予備調査を踏まえ監査手続を具体化する【標準ガイドライン関連箇所：第３編第１０章第１節 3)】

監査実施計画書にて大まかな進め方や評価の方針等を定義しました。その計画書に基づ
き、予備調査を行いながら、監査項目、監査を行うために必要な証拠、実際の監査の方法、
サンプリング数等を具体的に決め、監査手続書としてまとめていきます。
予備調査では、監査実施者が監査対象を理解するため、プロジェクト計画書や業務分析
資料、要件定義書等の各種文書を確認して現状を把握し、監査の内容や方針を決定するための情報を収集します。

監査手続書を作成するまでの流れを掴む
ここでは、ある省のシステム監査の様子を見ながら、どのように監査手続を決めていくかを具体的に見ていきます。

事例：変更管理の妥当性を監査する手続を検討するある省では、過去に起きた失敗事例等から、運用・保守業務において、ＰＪＭＯが主体的に変更管理を行っていないことで、設計書等のドキュメント類と実際のシステ
ム構成、運用業務内容等に不整合が生じてインシデント発生時への対応の遅れが発生することや、発注者が承認していない設定変更により障害を発生させる要因となることを大きなリスクとして捉えていました。
そこで、ＰＭＯは、システム監査として、変更管理の妥当性を中心に確認することとしました。監査で確認する内容は次のようなものです。

-

14 -

事例 10-2
変更管理の妥当性を監査する手続を検討する（第３編第１０章 システム監査）

項番
①
②

③

④

確認観点
変更作業に係る管理及び報告が要件として求められているか
調達仕様書・要件定義書の各要件が抜け漏れなく実現できるものとなっているか
ＰＪＭＯの承認の上で作業が進められているか
承認後の変更は、再度の承認の上で行われているか作業等は設計書等のルールに基づいて実施されているか（作業員のその場の判断で変更がされていないか）
変更が含まれる作業を実施する場合はＰＪＭＯの承認の上で設計書等の変更が適切に行われているか
改修に伴う設計書等の更新が、ＰＪＭＯの承認の上で適切に行われているかあるプロジェクトの監査を行うことになった担当者は、監査内容の決定に先立って、そのプロジェクトが現在どのような状況か、どのような関係者・体制でプロジェクトを運用しているか、変更管理のプロセスはどうなっているか、どの程度の変更が発生しているかを知るために、予備調査として次のようなことを行いました。
【予備調査の内容】
プロジェクトの内容、全体の計画、体制がわかる資料（例：プロジェクト計画書）を
ＰＪＭＯより提出してもらい、内容を確認
保守・運用の具体的な内容がわかる資料（例：運用・保守計画書、運用・保守設
計書）をＰＪＭＯより提出してもらい、内容を確認
変更管理のルールがわかる資料（例：運用・保守管理要領）をＰＪＭＯより提出してもらい、内容を確認
昨年度・今年度の変更実績がわかる資料（例：変更管理簿）をＰＪＭＯより提出してもらい、内容を確認
予備調査の結果から、そのプロジェクトが運用・保守で変更を行う際に、次のような手続で変更管理を行っていることがわかりました。
1. 変更が必要になった場合は、運用・保守定例で起案し、ＰＪＭＯから変更内容の承認を受ける。承認されたら、変更管理簿に記載する。
2. 変更に関する設計書等の修正が完了したら、ＰＪＭＯに机上でのレビューを依頼する。
3. 変更に関する検証（テスト等）が完了したら、ＰＪＭＯに結果を本番反映の計画も含めて運用・保守定例で報告し、ＰＪＭＯの承認を受ける。承認を受けたら、変更管理簿に記載する。
4. 変更が完了したら、ＰＪＭＯに報告し、変更管理簿を更新する。
予備調査の結果を受けて、監査の担当者は、監査手続を作成しました。以下に、システム構成の変更管理に係る監査チェック項目の具体例をご紹介します。
【監査チェック項目例】
監査内容
変更発生
時の内容、
承認者等
必要な事
項が抜け

監査項目
（起案時）
ＰＪＭＯによる承認が行われており、承認者、承認日等が記録されている
か。

-

監査証拠
議事録等の運用・保守定例での承認記録がわかる資料
変更管理簿

15 -

監査技法
資料精査
インタビュー
定例会の観察（第３編第１０章

漏れなく記
録されてい
るか。

変更内容
について
妥当性の
評価は行
われている
か。

システム監査）（設計完了時）ＰＪＭＯによるレビューが行
われ、承認が行われていること。

メール等のレビューのやり取り及び承認したことがわかる資料
変更管理簿

資料精査
インタビュー（検証完了時）ＰＪＭＯに検証内容を説明
し、承認を受けていること。

運用・保守定例での検証内容の説明資料
議事録等の運用・保守定例での承認記録がわかる資料
変更管理簿
メールや議事録等のＰ
ＪＭＯに報告したことがわかる資料
運用・保守定例でＰＪ
ＭＯに変更内容を説明した資料
議事録等の質疑内容がわかる資料
メール等のレビューのやり取り及び承認したことがわかる資料
変更前後の設計書
レビュー指摘表等のＰ
ＪＭＯがレビューした
内容がわかる資料
運用・保守定例での検証内容の説明資料
議事録等の質疑内容がわかる資料議事録等の運用・保守定例での承認記録がわかる資料

資料精査
インタビュー
定例会の観察（本番反映後）ＰＪＭＯに報告が行われて
いること。
（起案時）
起案者がＰＪＭＯに変更内容を適切に説明しているか。
（設計完了時）ＰＪＭＯがレビューを適切に行っているか。
起案者が、指摘内容が適切に修正されているか。

（検証完了時）ＰＪＭＯが検証内容を確認しているか。

資料精査
インタビュー
定例会の観察
資料精査
インタビュー
定例会の観察

資料精査
インタビュー

資料精査
インタビュー
定例会の観察監査体制は、この監査手続書に従って、資料精査やインタビュー、観察等の実地調査を進めていきます。

なお、工程レビューを実施しているプロジェクトを監査する場合は、工程レビュー時に提出を求めた資料や自己点検の内容を予備調査に活用することができます。

２ 根本原因を究明し改善点を発見する【標準ガイドライン関連箇所：第３編第１０章第１節 3)】

監査手続書の作成が完了したら、実地調査を実施し、評価結果をシステム監査報告書としてまとめます。ここでは、監査の実施に関するノウハウをご紹介します。

インタビュー時には情報を上手に引き出す
実地調査でＰＪＭＯにインタビューをする際には注意が必要です。システム監査を受ける
ＰＪＭＯは、システム監査で指摘を減らしたいために、当たり障りのない回答をして実情を隠そうとすることもあります。目に見える問題における表面的な原因はすぐにわかりますが、的確に改善を行っていくためには、問題を深掘りして根本的な原因を見つけることが大切で
す。

-

16 -

（第３編第１０章

システム監査）そのため、インタビューでは、次の点に注意してください。

インタビュー時の注意点「はい」、「いいえ」で答えられる質問のみにしない
曖昧な解答で済ませない。重要な事項については質問を深掘りする
複数の人からの回答を得る
回答しやすい環境を作る

インタビュー時の心得
一度にたくさんの質問をしない
曖昧な質問をしない
誘導的な質問をしない
監査実施者が長く話さない（できるだけ回答者に長く話させる）
相手の話の腰を折らない（回答者の話をしっかりと聞く）
相手の答えに対して批判しない
相手と議論しない
横柄な態度やいらいらした姿勢をとらない
卑屈な態度をとらない
わかっていないのにわかったと言わない（わからないことは聞く）

改善提案は報告の場で具体例を混ぜながら行う
実地調査が完了し監査報告書をまとめた後は、多くの場合、ＰＪＭＯに指摘内容を共有します。システム監査は問題解決によりプロジェクトの目標達成に近づくことが目的ですの
で、ＰＪＭＯが指摘内容の改善を検討する際に表面的な解決にとどまることなく、より効率的かつ効果的な管理となるような助言を心掛けましょう。
そのためには、監査を実施する際に、例えば、「ルールを逸脱しているかどうか」だけではなく、「なぜルールどおりにやっていないのか」の原因を探ることが、とても大切です。そう
してつかんだ根本原因に対して、他のプロジェクトの好事例等を踏まえながら具体的に提案を行うことが効果的です。

事例：ある省でのシステム監査の効果向上への取り組み
ある省では、プロジェクトの管理プロセスが標準ガイドライン及び省で定めたルールに準拠しているかを評価するシステム監査を実施しています。
過去のシステム監査では、ＰＪＭＯのシステム監査に対する理解が低いことやプロジェクトが多忙であることから、監査に前向きではなく、指摘に対しては表面上の改善が行われるだけ、というようなことが散見されました。
そこで、ＰＭＯは、次のような取り組みを行いました。

-

17 -

事例 10-3
ある省でのシステム監査の効果向上への取り組み

（第３編第１０章

システム監査）【改善提案の工夫】
この監査では、監査結果報告書にてルールに対する不適合を指摘することとなりますが、改善提案では単なる是正にとどまらず、現状よりも効率的かつ効果的な管理となるような提案とすることを心掛けます。ＰＪＭＯとの監査結果の共有の場では、Ｐ
ＪＭＯが改善案をイメージできるよう、他のプロジェクトのやり方や改善施策等を具体的に伝えたり、ＣＩＯ補佐官等の持つ知見を伝えたりすることで、ＰＪＭＯが前向きな改善を行えるようにします。
【報告ルートの明確化】
ＰＪＭＯに対して、監査結果の報告先が府省ＣＩＯや情報化推進委員会等であることを明確にします。これは、監査責任者を通して現場の課題感を直接幹部に伝えられるという点で、ＰＪＭＯにとってもメリットがあります。
また、上記以外にも、研修等を通して、ＰＪＭＯにシステム監査の必要性や効果を伝えるよう努めています。

システム監査報告書の様式を把握する
システム監査報告書の様式を使用して、作成の時間を削減しましょう。各府省で様式が提供されている場合はそれを使用し、提供されていない場合は、以下の様式を活用してください。

様式例：システム監査報告書のひな形
システム監査報告書のひな形を本章別紙としてまとめています。

-

18 -

様式例 10-2
システム監査報告書のひな形

（第３編第１０章

Step.

システム監査）5 指摘事項を踏まえた改善

ＰＪＭＯは、システム監査報告書で指摘された内容を踏まえて改善計画を立て、改善を進
めていきます。
ここでは、システム監査の改善に関わるノウハウを、紹介していきます。

１ 改善計画を立て改善を行う【標準ガイドライン関連箇所：第３編第１０章第１節 4)】システム監査報告書には、指摘事項が記載されています。そこには、ＰＪＭＯの皆さんが気付いていない問題点もあれば、気付いていたものの、なかなか解決に至らない問題点もある
かもしれません。報告書には、指摘事項に対して改善提案も記載されていますので、その内容を踏まえて改善計画を立てましょう。
システム監査が運用・保守業務を対象とする場合、システム監査の指摘だけでなく、運用・保守で発生している他の問題も含めて対応の優先順位を検討する必要があります。以下の図では、運用・保守業務を対象としたシステム監査と他の章との関係を示します。

図 10-4
運用・保守業務を対象としたシス
テム監査と他の章との関係改善計画を立てる際は、もし、監査報告書の改善提案よりも有効な改善策があれば、必ずしも改善提案に記載されているとおりに計画する必要はありません。
なお、内容によっては、改善が定着するまで時間がかかる可能性がありますので、それらを踏まえた改善計画を立て、定着の度合いも継続的にモニタリングする必要があります。改善の内容に応じて、プロジェクト計画書の見直しも実施してください。
ＰＪＭＯは、改善計画や改善結果、改善状況について、監査責任者及びＰＭＯに報告してください。報告内容をＰＭＯが確認・評価し、ＰＪＭＯはＰＭＯより的確な助言等を受けることが
できます。

-

19 -