第１章実践ガイドブックの構成

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

実践ガイドブック

2019年（令和2年）3月31日

内閣官房　情報通信技術（ＩＴ）総合戦略室

〔標準ガイドライン群ＩＤ〕

1010

〔キーワード〕

ＩＴマネジメント、プロジェクトの管理、予算要求、サービス・業務企画、要件定義、調達、設計・開発、サービス・業務の運営と改善、運用及び保守、システム監査

〔概要〕

デジタル・ガバメント推進のためのサービス・業務改革並びにこれらに伴う政府情報システムの整備及び管理について、プロジェクトを運営する職員の視点に立って実務的なノウハウ、実例、ひな形等を記載した標準ガイドライン参考文書。

改定履歴

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

１　背景と目的

情報システムの整備及び管理は、多岐にわたる活動から構成され、専門的な内容が多く含まれるため、前提知識や経験のない職員にとって、全体像が理解しづらいものとなっている。

このため、本章ではＩＴマネジメントの活動について、事例やドキュメントひな形等の紹介を含めて、プロジェクトを進める職員の立場から実践的な進め方を示すことで、プロジェクトを着実に推進し、利用者が実感できる効果を達成することを目的としている。

２　適用対象

本方針の基本的な適用対象は、デジタル・ガバメント推進標準ガイドラインが適用されるサービス・業務改革並びにこれらに伴う政府情報システムの整備及び管理に関する事項を想定している。

ただし、本書はルールを示したものではなく参考文書であるため、適用対象の事項であっても本書の記載に従う義務はない。

３　位置づけ

本書は、「デジタル・ガバメント推進標準ガイドライン」、「デジタル・ガバメント推進標準ガイドライン解説書」を上位ドキュメントとしている。

「デジタル・ガバメント標準ガイドライン」は、政府情報システムを整備及び管理する際の共通ルールである。そのため、政府情報システムを整備及び管理する際には、この内容に準じることが求められる。

「デジタル・ガバメント標準ガイドライン解説書」は、「デジタル・ガバメント標準ガイドライン」の記載内容について逐条解説を行っているものであり、参考文書である。

本書「デジタル・ガバメント標準ガイドライン実践ガイドブック」は、上位ドキュメントの主要な構成に沿って、プロジェクトを進める職員の立場から実践的な進め方を示すことを目的とした、参考文書である。

４　用語

本書において使用する用語は、本書に別段の定めがある場合を除くほか、原則として標準ガイドライン群用語集の例による。ただし、本書は職員にとって読みやすくわかりやすい構成とすることを重視しているため、厳密な用語を使うと可読性を損なうと考えた部分については日常的に使う表現を優先している部分もある。

なお、参照しやすいよう用語集と同様の定義を記載する場合がある。そのほか専門的な用語については、民間の用語定義を参照されたい。

実践ガイドブックの全体像

第１章実践ガイドブックの構成

本書の想定読者は、こんな人です

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 要件定義終了後の対応

第６章調達

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 指摘事項を踏まえた改善

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

実践ガイドブック

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

本書の想定読者は、こんな人です

入省４年目の若手職員、吉川君（男性職員）は、ある日、上司の中山室長（女性職員）に呼ばれました。あるデータベースシステム開発の企画から要件定義、調達、開発、運用まで全てを担当してほしいとのことです。

「僕がですか？ＩＴなんてまるで知りませんよ。」

そう。文系の大学を出て、入省後もＩＴとは無縁の仕事をしてきた吉川君には、データベースシステムを導入するなど、どこか遠い世界の話で、そもそも何をどこからやれば良いのか、まるで知識がありません。

それでも室長は、この仕事を是非、吉川君にと言います。

「今の時代、役人だって、ＩＴ知らないじゃ通用しないわ。勉強のつもりでやってみてよ。」

吉川君は、不安に首を少しだけ傾げます。

「でも、本当に大丈夫ですかね、僕で。」

「周りの先輩達だって、みんなやってきたことよ。吉川にだって、できないことはないはず。」室長の顔に迷いはありません。生来、真面目な吉川君は、傾げたままの首を二、三回縦に振りました。

「わ、わかりました。まあ、これまでの調達仕様書とか見て、発注さえすれば、あとはプロであるＩＴベンダがやってくれるわけですからね。」吉川君の言葉に室長の目が少し厳しくなりました。

「ダメよ。ＩＴに、そんなお客様気分は通じない。ＩＴ導入を行うなら、どんな業務を実現するために、システムにどんな機能や性能を持たせるのかを自分で考えなきゃいけないわ。そこをいい加減にやってプロジェクトが失敗して、発注者側が裁判でも負けたなんて例もあるんだから。」

「システム開発の失敗が客の責任になっちゃうんですか？」

「それに仕事は発注までじゃない。ベンダの作業中も、その進捗とか課題をしっかり観察して、場合によっては、こっちから是正指示をしなきゃいけない場合だってあるのよ。」

室長の言葉に吉川君は唇を尖らせました。

「それじゃあ、システムが本当に作り終わるまで、こっちは気が抜けないじゃないですか。ただでさえ忙しいのに。」

中山室長は一旦、腕組みをしてから、ゆっくりした口調で言います。

「でもね、吉川。さっきも言ったけど、こういうＩＴの発注は、これからの公務員が、どうしても避けて通れないことだと思わない？公務員のコスト削減や働き方改革だって、今、政府がやろうとしている重要な政策は、どれもＩＴ抜きには考えられない。自分の頭の中にある構想を具現化するとき、どんな情報システムを作るかを考えて実現する力がどうしても必要だし、逆に、そういうスキルをつけることは、吉川自身の将来にとっても大事なことだと思う。」

「それは、まあ、そうかもしれないですけど。」

これからはＩＴ抜きで仕事なんてできないし、その知識を得ておくことは、公務員にとっても必須と言うことは吉川君にもわかります。吉川君は尖らせた口を元に戻しました。でも、傾げた首は、まだそのままです。必要だと言うことはわかっても、そもそも何から始めたら良いのかすら、よくわかりません。

「でも、ＩＴの発注って何をどうすれば良いんだか・・・」質問する吉川君に、今度は中山室長が首を傾げます。

「政府ＣＩＯポータルに載ってる、デジタル・ガバメント推進標準ガイドラインと解説書、読んだんでしょ？」

「いや、それは読みましたけど。。。」吉川は言葉に詰まってしまいました。室長の言うドキュメントは、確かに一度読んだことがあります。ＩＴ導入で発注者側である公務員がやるべきことや考え方が、一通り書いてあったのは覚えています。ただ、それらは、どちらかと言うと、基本的な考え方やルールが中心で、読んでいても、いまひとつ、自分がなすべき作業の実感がわかないと言うのが正直なところでした。

「読むには読みましたけど、イマイチ、リアリティが持てなくて。例えば、要件定義で決めるべき事柄は分っても、実際、そのために、どんなドキュメントをどう作るのかとか、何に気をつけないと、どんな危険があるかとか、そう言うリアルなことが良くわからなくて。」

室長は小さく頷きました。

「そうよね。私もそう思う。」そう言いうと、室長は自分のパソコンを吉川君の方に向けました。

「こういうのが出たの知ってる？」

「デジタル・ガバメント推進標準ガイドライン実践ガイドブック」

そう題されたＰＤＦファイルが画面いっぱいに表示されていました。

「君が言うとおり、標準ガイドラインや解説書は、正しいことを正しく書いてはいるけれど、本当に職員が何をすべきか、何に気をつけるべきかってことに関して、実感を持って伝えるものじゃない。だから、そう言うこと、つまり、実際に役人がすべきこと、作るべきものについて、実例なんかを元に具体的に書いたのがこれよ。」

「ちょっとすみません。」

吉川君は、そう言うとパソコンを自分の方に引き寄せ、表示されたＰＤＦファイルを数ページ進めて見ます。ＩＴ導入において、実際に作るべきドキュメントの例や、失敗から得た知見などが、工程ごとにまとめられている。確かに、これなら、各工程で自分が成すべきこと、注意すべきことが、リアルに実感できそうです。

「これを見ながらやれば、ＩＴ素人の吉川でも、なんとかやっていけるんじゃない？」中山は微笑んだが、吉川は、まだ少し首を傾げたままだ。

「内容はいいですけど、でも、これ全部読むんですか？何百ページもありますよ。」

「馬鹿ね。こんなもの最初っから最後まで読み通す必要はないのよ。そもそもそんなことしたって、頭に入らない。」

「ですよね。」

「これはね。”辞書”なの。自分が作業をしていてわからなくなったら、その部分だけを見ればいい。調達仕様書って何を書くのか、プロジェクト管理って何をするのか、疑問にぶつかった時に、その部分を参考にする。だったら、そんなに手間もかからないでしょ？」

「そう言うことですか。」吉川君は、再びＰＤＦファイルを眺めて、やがて大きく頷きます。

「わかりました。やってみます。」吉川の首が、初めて真っ直ぐに戻りました。

こうして吉川君は、慣れないＩＴ導入の仕事に取り組むことになりました。さて、読者の皆さんは、いかがでしょうか？もしかしたら、吉川君と同じようにＩＴに関する知見に自信のない人も多いかもしれません。この「デジタル・ガバメント推進標準ガイドライン実践ガイドブック」は、標準ガイドラインに従って、ＩＴ導入の仕事を進めるとき、具体的に何をすべきかと言うことを、必要な部分だけ拾い読みできるように構成しています。ＩＴ導入でわからないことがあったときには、是非、このガイドブックから必要な部分を参照しながら、円滑なＩＴ導入の役に立ててください。

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

この実践ガイドブックには、実際にプロジェクトを進める職員の視点で、具体的なノウハウ、進め方、注意点、ひな形等を記載しています。多くの内容を盛り込んだ結果、全体で約350ページと、なかなかボリュームのあるドキュメントとなっています。

基本的には、冒頭の吉川君と中山室長のやりとりにもあったように、プロジェクトを進める中でわからないことがあったら、その部分を辞書的に参考にするような使い方を想定しています。ということも含めて、まずは実践ガイドラインの全体像や読み方等について説明します。

１本書の読み方

本書は、「デジタル・ガバメント推進標準ガイドライン」の通称「三部作」の１つです。

本編には、政府情報システムの整備や管理に際して守るべきルールを書いています。様々なプロジェクトで発生する多様な状況に対して正確に実施すべき内容を伝えるという性格を持つドキュメントであるため、正確さを優先して、いささか固めの表現となっています。

解説書は、そんな本編の内容を補足するものです。逐条解説という体裁で、本編で示したルールについて、その趣旨を説明したり、解釈方法の例示を行ったりしています。本編よりは固い表現ではないものの、やはり読みやすさよりは正確さを優先した表現となっています。

そこで、読みやすさや実用性を重視したのが、本書、実践ガイドブックです。

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

つまり、本書に書いている内容は、守るべきルールではありません。本書の記載を読んで、使えると感じた部分は使って頂きたいですし、使えないと感じた部分は無視して頂いてかまいません。

また、本書の要点を短時間で確認したい人に向けて、サマリーを用意しました。この後の「３　本書の概要」で、各章で記載している内容のポイントをまとめています。

実際の業務で活用しやすいように、チェックリストも作成しました。「Point2 チェックリスト」をご覧ください。

２本書の対象読者

本書では、主として次の読者を直接的な対象として想定しています。

・各府省のＰＪＭＯとして情報システムに関連する企画、調達、開発、運用等の実務に携わる職員（特に、冒頭に記載した吉川君のように業務の進め方に慣れていない職員）

・各府省のＰＭＯとして、府省内のＩＴ施策に関する全体管理を行う職員

・各府省のＣＩＯ、副ＣＩＯ及び政府ＣＩＯ補佐官

・内閣官房ＩＴ総合戦略室、総務省行政管理局の各職員

・政府情報システムの企画、調達、開発、運用等を協働して実施する事業者の方々

参考：目の前の仕事に忙殺されていると感じたときに

多くの人は、目の前の仕事に忙殺されます。

例えば、新制度の導入に伴い、情報システムを作ることになったとしましょう。あなたは、そのプロジェクトの担当者です。来年度にはシステム開発に着手する必要があるので、急いで予算要求のための資料を整えます。制度概要の説明資料を作り、事業者に対して見積を依頼し、何とか予算要求の資料を整えました。予算を確保して安堵するのもつかの間、今度は調達に向けた準備です。他の事例を参考に見様見真似で要件定義書を作成し、目の前の仕事をこなし続けて、なんとか予定どおりに調達手続きに入ることができました。本当におつかれさまでした。

さて、この後、どのようなことが起こるでしょうか。調達を経て、事業者が決定してから、問題が次々に起こります。システム設計を進める中で、現場の職員からブーイングの嵐が巻き起こります。多様な業務をこなすための機能を考慮できていなかったからです。ただ、既にシステム開発事業者と契約締結済なので仕様追加は困難です。やむを得ず、目の前の仕事として情報システムの完成を優先します。

何とか情報システムが出来上がり、稼働を開始しました。しかし、情報システムを使っていてはかえって業務が非効率なので、現場の職員は別の方法で業務を実施します。情報システムを利用する人はほとんどいなくなりました。皮肉なことに、使われない情報システムはシステム障害を起こすこともないため、外見的には順調に情報システムが動いているように見えます。しかし、実態的には、価値のない情報システムに、延々とコストだけがかかっています。

どうして、こんなことになってしまったのでしょう。

参考1-1 目の前の仕事に忙殺されていると感じたときに

目の前の仕事を進めながらも、一歩、踏みとどまることが重要だと考えています。

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

過去には、「一歩」を踏みとどまることができず、失敗と言われてしまうプロジェクトもありました。これから進めるプロジェクトの中では、少なくても同じ失敗をすることは避けたいですね。

３本書の概要

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

第２章　プロジェクトの管理

プロジェクトの立上げ時に、目標を安易に設定してしまうことがあります。第２章の冒頭では、悪い目標設定例を題材にした上で、現場で発生している事実をつかみながら利用者が本当に困っていることを分析して、利用者が実感できる効果を目標に設定する方法を説明します。

また、機能するプロジェクト体制を作ることが重要です。制度所管部門、業務実施部門等を含めた組織的体制で、ＰＪＭＯにも十分な要員を確保する方法を具体例とともに示します。

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

様式のひな形　　　　プロジェクト計画書、プロジェクト実施要領

第３章　予算要求

予算要求に関連する作業の年間スケジュールを示し、十分な準備期間を確保することの重要性を強調しています。そして、予算要求に必要となる主要資料のそれぞれがどの工程の検討成果物であるかを示した上で、関係者に対してわかりやすい構成となるように、「全体から詳細につながる」といった資料作成のポイントを示しています。

また、情報システムのコスト削減のポイント、事業者から入手した見積りの精査ポイントについて、具体的に解説しています。

様式のひな形　　　　（特になし）

第４章　サービス・業務企画

サービスデザイン思考という言葉や、サービス・業務改革（BPR）という言葉を聞いたことがあっても、いざ自分が担当したときに何をどう検討すればよいのかわからないかもしれません。

まず、サービス設計１２か条の内容に基づいて、検討への心構えと視点を説明します。そして、利用者の立場からの分析を行うために、ペルソナ分析やジャーニーマップといった手法を説明します。また、サービス・業務の現状把握のために、どのように調査を行い、どのような資料を集め、どのように分析するかを詳細に解説します。事例を交えた解説の中で、平均や合計での分析だけでは不十分であること、時間と期間を区別すること等、本当の事実をつかむための分析の着眼点や注意点を示しています。

このような検討を通して作成した企画案について、様々な方向から見直せるように、見直しの観点も多数示しています。

様式のひな形　　　　現状分析結果報告書、業務要件定義書

第５章　要件定義

これまでの検討で作り上げた業務要件を実現するために、情報システムに求める要件を具体化します。

まず、RFIや事業者からの情報収集といった活動を通して、市場にあるサービス、海外や国内の類似事例、新たな技術の動向や製品のライフサイクル、概算の予算規模、スケジュール等について把握を行います。

その上で、機能要件と非機能要件を明確にします。機能要件では画面、帳票、情報・データ、外部インタフェース等について、非機能要件ではユーザビリティ、システム方式、規模、性能、信頼性、情報セキュリティ等について記載します。記載項目のそれぞれについて、記載する目的、作成するドキュメントのイメージ、注意点等を説明しています。

様式のひな形　　　　機能要件定義書、非機能要件定義書

第６章　調達

要件定義までの工程で情報システムに求める全体機能は明確になりましたが、この内容をどのような単位に分けて調達を行うのかは重要なポイントです。分離調達を行うことのメリットとデメリットを説明し、調達の単位をうまく定めて調達計画を作成する方法を示します。

調達仕様書についてはひな形を示した上で、調達目的の正確な記載、作業内容と納品物を紐づけた明確化、実施体制や発注者としての役割について考え方や注意点を記載しています。また、総合評価落札方式で事業者の提案を評価する際に、評価点の配分の留意点や、事業者からWBSとして示される作業予定内容の精査のポイント等について説明しています。

様式のひな形　　　　調達仕様書

第７章　設計・開発

設計・開発を事業者に丸投げしては、良い情報システムは作れません。要件を事業者に正しく伝え、関係者間の調整を行い、進捗状況を正しく把握し、情報システムの出来具合をテストするのは発注者である職員自身です。設計・開発において、職員自身が実施することにフォーカスして、業務内容を説明しています。

例えば、テストについても、結合テスト、総合テスト、受入テストといった工程の中で、機能面（シナリオテスト、業務サイクルテスト等）はもちろんのこと、非機能面（負荷テスト、セキュリティテスト、縮退テスト等）をそれぞれ確認します。職員自身がテスト計画やテスト結果について正しく判断できるように、テストの内容と確認ポイントについて説明しています。また、移行、リハーサル、運用・保守の準備、マニュアル等、重要なのに見落とされがちな作業について、計画の立て方、ドキュメントの作成方法、注意点等を示しています。

様式のひな形　　　　設計・開発実施計画書、設計・開発実施要領、
受入テスト計画書

第８章　サービス・業務の運営と改善

業務を実施する中でも、うまく外部委託を活用します。作業量が多く定期的に発生する作業は外部委託に向いていますが、業務上の専門知識を必要とする作業や品質確認が必要な作業は外部委託にはあまり向いていません。役割分担のコツについて説明します。

また、日常の業務の中で、利用者からの要望、インシデント、ログ情報等、様々な情報が蓄積しますが、それらの情報はサービスや業務を改善するための宝の山です。これらの情報を蓄積し、分析するための手法として事例等を紹介しています。

様式のひな形　　　　（特になし）

第９章　運用及び保守

運用及び保守の目的は、情報システムの安定的な稼働を維持することだけでなく、利用者へのサービスを継続的に改善することや運用コストを低減していくことも含まれます。

そこで、まず運用及び保守で実施する代表的な作業項目を説明しています。これらの作業は、事業者に実作業を依頼する比率が高くなるため、作業分担を明確にすることが重要です。運用契約の「忘れ物チェックリスト」等を含めて、注意点を記載しています。

また、運用工程では複数の事業者が関わるため、会議体の種類が多くなる傾向があります。代表的な会議体の種類と目的を示すとともに、定例会議における報告内容についても注意点を記載しています。

そのほかにも、変更管理、ログ等の蓄積、指標管理、運用業務の改善方法等、職員が主体的に運用・保守業務を管理するための具体的な知識やノウハウを説明しています。

様式のひな形　　　　運用計画書、運用実施要領、運用報告書　　　　　　　　　　　　　保守計画書、保守実施要領

第１０章　システム監査

システム監査は、各プロジェクトの取り組みがその目標達成に正しく向かっているのか、プロジェクトの各フェーズでの実施プロセスは適切かといった観点から、現状を調査し、改善すべき点がないかを第三者の視点で客観的に点検・評価する活動です。

まず、各省ＰＭＯが複数年単位での監査計画を立て、どの情報システムを監査対象とするかを決めます。実際の監査の中では、監査責任者が監査実施計画書を作成し、監査目的、監査範囲、スケジュール、監査体制、実施方法等を定めますので、その記載方法等を示しています。また、予備調査の進め方、インタビューの実施方法、監査報告書の作成方法、監査後の改善の進め方等について解説しています。

様式のひな形　　　　監査実施計画書、監査報告書

参考：ＷＢＳ・開発イベントマップ

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

また、理解しづらい情報システムの設計・開発に関わる7章及び関連する8章・9章の作業について、作業の期間や前後関係を理解しやすくするために、登場する作業を時系列で示した資料として、 開発イベントマップを別紙に用意しています。

Point.2 チェックリスト

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

１新サービス企画時のチェックリスト

プロジェクトの立ち上げ、初動
1 目標とする成果が正しく定められているか	第 2 章 Step2 1
2 サービスを改善するための十分な体制を組んだか	第 2 章 Step2 3
利用者視点でのニーズ把握
3 サービスの利用者の種類や人数を把握したか	第 4 章 Step3 1
4 利用者の立場でサービスへのニーズを把握したか	第 4 章 Step3 2
業務の現状把握
5 業務の現場へ行って業務実態を詳細に把握したか	第 4 章 Step4 1 B,C
6 業務で生まれる各実績データを収集して分析したか	第 4 章 Step4 2
7 業務の制約条件及び前提条件を洗い出したか	第 4 章 Step5
8 業務のリスクアセスメント（リスク特定、リスク分析、リスク評価）を実施したか	第 4 章 Step5
サービス・企画内容の検討
9 エンドツーエンドの視野での企画案になっているか	第 4 章 Step5 2 C
10 自分で作りすぎず、シンプルな企画案になっているか	第 4 章 Step5 2 H
11 システムを作る前に、業務を標準化したか	第 4 章 Step5 2 D
12 一遍に全てを実現するのでなく、段階案を検討したか	第 4 章 Step5 2 G
プロジェクト計画書
13 プロジェクト計画書の段階的な改定を行ったか	第 4 章 Step6 2

２予算要求前のチェックリスト

予算要求の事前準備
1 予算要求に向けた活動計画を立てたか	第 3 章 Step2 1
2 コスト削減に向けた検討を計画的に行ったか	第 3 章 Step2 3a
予算要求に必要な資料の準備
プロジェクトが目標とする成果の詳細化・具体化を行っているか予算要求対象だけでなく全体像を説明しているか	第 3 章 Step3 1
業務の現状把握
4 予算要求の目的とプロジェクトの目標とで整合性はとれているか	第 3 章 Step3 1
5 見積り依頼前に、制約条件、前提条件、リスク及び問題点を考慮して要件を精査したか	第 3 章 Step4 1
6 一式ではなく、詳細な見積り内訳を把握したか	第 3 章 Step5 全体
7 人件費について工数の妥当性を精査したか	第 3 章 Step5 1
8 ハードウェア等について経費の妥当性を精査したか	第 3 章 Step5 2
プロジェクト計画書
9 プロジェクト計画書の段階的な改定を行ったか	第 3 章 Step7 2

３調達実施前のチェックリスト

調達の事前準備
1 プロジェクト全体の調達計画を立てたか	第 6 章 Step2 1
2 リスクの対応方針を検討したか	第 2 章 Step3
3 プロジェクトが目標とする成果で求める品質又は成功基準を検討したか	第 2 章 Step2 1
要件定義書の作成
4 実現する機能の優先順位を検討したか	第 5 章 Step4 2
5 機能、画面、帳票等の機能要件を明確にしたか	第 5 章 Step5 1
6 実施頻度の低い機能も含めて漏れなく要件化したか	第 5 章 Step5 2
7 規模、性能、信頼性等の非機能要件を明確にしたか	第 5 章 Step6 1
8 プロジェクトが目標とする成果で求める品質又は成功基準を検討したか	第 5 章 Step5 1 E
9 要件定義の全体内容を関係者に共有したか	第 5 章 Step7 1
調達仕様書の作成
10 調達の目的を正しく伝えているか	第 6 章 Step3 2 A
11 作業内容と納品物を関連付けて定義しているか	第 6 章 Step3 2 C
12 事業者の実施事項、役割を明確に定義しているか	第 6 章 Step3 2 D、E
13 ベンダロックインの構造を理解し回避しているか	第 6 章 Step5 2
現状の把握・分析結果の確認（現行の業務、システムがある場合）
14 現行の業務、システム、データ及び運用の状況を分析したか（現状分析結果報告書）	第 4 章 Step5 1
プロジェクト計画書
15 プロジェクト計画書の段階的な改定を行ったか	第 2 章 Step3 1

４設計・開発時のチェックリスト

設計・開発を開始するための事前準備
1 プロジェクトの目標・目的と機能要件、非機能要件などがそれぞれ紐づけ管理できているか	第 5 章 Step4 1
2 設計・開発で職員が担うべき役割を理解したか	第 7 章 Step2 1、２
設計・開発
4 完成後のサービス提供・業務利用を想定して課題管理、リスク管理を行っているか	第 6 章 Step6 1
4 工程の進捗を定点観測しているか	第 7 章 Step3 1 A
5 事業者任せではなく自分で理解して判断しているか	第 7 章 Step3 1 B
6 ガントチャートやEVMで進捗実態を把握しているか	第 7 章 Step3 2 E、F
7 他システム連携の内容に細心の注意を払ったか	第 7 章 Step4 1 B
テスト
8 様々なテストのレベルと種類を理解したか	第 7 章 Step3 3 B
9 テスト実施に向けた職員側の体制を確立したか	第 7 章 Step3 3 A
10 負荷テスト試験、セキュリティテストなどの非機能試験テストを十分に実施したか	第 7 章 Step4 4
11 現場に即したシナリオで受入れテストを実施したか	第 7 章 Step4 5
移行、リハーサル
12 システム移行、データ移行、業務移行を計画したか	第 7 章 Step5 1 A
13 本番稼働前に切り戻しのルール及び手順、コンティンジェンシープランを作成したか	第 7 章 Step5 1 B
14 本番稼働前にリハーサルを入念に行ったか	第 7 章 Step5 1 B

５サービス実施時のチェックリスト

業務の実施、改善
1 職員への研修・教育を継続的に実施しているか	第 8 章 Step3 1
2 業務で扱うデータの品質を維持しつつ適切なライフサイクル管理を行ってしているか	第 8 章 Step3 3
3 業務の実績データや利用者要望を分析できているか	第 8 章 Step3 4 A、B、D
4 プロジェクトの目標達成状況を確認しているか	第 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
プロジェクト計画書
10 プロジェクト計画書の段階的な改定を行ったか	第 2 章 Step3 1

第２章　プロジェクトの管理

第１章 実践ガイドブックの構成