--- type: guideline title: Point.1 実践ガイドブックの概要 source: デジタル庁 ds_code: ds-120 category: government-system updated: 2025-06-19 source_url: https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/e2a06143-ed29-4f1d-9c31-0f06fca67afc/9ab95eed/20250619_resources_standard_guidelines_guideline_06.zip --- # Point.1 実践ガイドブックの概要 この実践ガイドブックには、実際にプロジェクトを進める職員の視点で、具体的なノウハウ、進め方、注意点、ひな形等を記載しています。多くの内容を盛り込んだ結果、全体で約350ページと、なかなかボリュームのあるドキュメントとなっています。 基本的には、冒頭の吉川君と中山室長のやりとりにもあったように、プロジェクトを進める中でわからないことがあったら、その部分を辞書的に参考にするような使い方を想定しています。ということも含めて、まずは実践ガイドラインの全体像や読み方等について説明します。 ## 本書の読み方 本書は、「デジタル・ガバメント推進標準ガイドライン」の通称「三部作」の１つです。 本編には、政府情報システムの整備や管理に際して守るべきルールを書いています。様々なプロジェクトで発生する多様な状況に対して正確に実施すべき内容を伝えるという性格を持つドキュメントであるため、正確さを優先して、いささか固めの表現となっています。 解説書は、そんな本編の内容を補足するものです。逐条解説という体裁で、本編で示したルールについて、その趣旨を説明したり、解釈方法の例示を行ったりしています。本編よりは固い表現ではないものの、やはり読みやすさよりは正確さを優先した表現となっています。 そこで、読みやすさや実用性を重視したのが、本書、実践ガイドブックです。 - 図1-1 デジタル・ガバメント推進標準ガイドライン ![](../assets/ds-120-ch01-image1.png) つまり、本書に書いている内容は、守るべきルールではありません。本書の記載を読んで、使えると感じた部分は使って頂きたいですし、使えないと感じた部分は無視して頂いて構いません。 また、本書の要点を短時間で確認したい人に向けて、サマリーを用意しました。この後の「３　本書の概要」で、各章で記載している内容のポイントをまとめています。 実際の業務で活用しやすいように、チェックリストも作成しました。「Point2 チェックリスト」をご覧ください。 ## 本書の対象読者 本書では、主として次の読者を直接的な対象として想定しています。この他、地方公共団体や独立行政法人の職員の方等にも活用いただける内容となっているため、是非ご参照ください。 - 各府省のＰＪＭＯ（ProJect Management Office）として情報システムに関連する企画、調達、開発、運用等の実務に携わる職員（特に、冒頭に記載した吉川君のように業務の進め方に慣れていない職員） - 各府省のＰＭＯ（Portfolio Management Office）として、府省内のＩＴ施策に関する全体管理を行う職員 - デジタル統括責任者、副デジタル統括責任者 - デジタル庁の各職員 - 政府情報システムの企画、調達、開発、運用等を協働して実施する事業者の方々 - 参考1-1 目の前の仕事に忙殺されていると感じたときに

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

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

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

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

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

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

![](../assets/ds-120-ch01-image2.png)

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

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

過去には、「一歩」を踏みとどまることができず、失敗と言われてしまうプロジェクトもありました。これから進めるプロジェクトの中では、少なくても同じ失敗をすることは避けたいですね。
## 本書の概要 本書の第２章以降では、標準ガイドライン本編の章立てに沿って、具体的な進め方やノウハウ等を説明します。 ### 第２章　プロジェクトの管理 プロジェクトの立上げ時に、目標を安易に設定してしまうことがあります。第２章の冒頭では、悪い目標設定例を題材にした上で、現場で発生している事実をつかみながら利用者が本当に困っていることを分析して、利用者が実感できる効果を目標に設定する方法を説明します。 また、機能するプロジェクト体制を作ることが重要です。制度所管部門、業務実施部門等を含めた組織的体制で、ＰＪＭＯにも十分な要員を確保する方法を具体例とともに示します。 プロジェクトを実行する段階においては、ＰＪＭＯ自身によるモニタリングを行います。目標、経費、進捗、品質等を確認し、場合によっては抜本的改善のプロセスに入ることもあります。 様式のひな形　　　　プロジェクト計画書、プロジェクト実施要領、 **デジタル庁によるレビューでの説明前提事項** ### 第３章　予算及び執行 予算要求に関連する作業の年間スケジュールを示し、十分な準備期間を確保することの重要性を強調しています。そして、予算要求に必要となる主要資料のそれぞれがどの工程の検討成果物であるかを示した上で、関係者に対してわかりやすい構成となるように、「全体から詳細につながる」といった資料作成のポイントを示しています。 また、情報システムのコスト削減のポイント、事業者から入手した見積りの精査ポイントについて、具体的に解説しています。 様式のひな形　　　　（特になし） ### 第４章　サービス・業務企画 サービスデザイン思考という言葉や、サービス・業務改革（BPR）という言葉を聞いたことがあっても、いざ自分が担当したときに何をどう検討すればよいのかわからないかもしれません。 まず、サービス設計１２か条の内容に基づいて、検討への心構えと視点を説明します。そして、利用者の立場からの分析を行うために、ペルソナ分析やジャーニーマップといった手法を説明します。また、サービス・業務の現状把握のために、どのように調査を行い、どのような資料を集め、どのように分析するかを詳細に解説します。事例を交えた解説の中で、平均や合計での分析だけでは不十分であること、時間と期間を区別すること等、本当の事実をつかむための分析の着眼点や注意点を示しています。 このような検討を通して作成した企画案について、様々な方向から見直せるように、見直しの観点も多数示しています。 様式のひな形　　　　現状分析結果報告書、要件定義書（業務要件定義） ### 第５章　要件定義 これまでの検討で作り上げた業務要件を実現するために、情報システムに求める要件を具体化します。 まず、RFIや事業者からの情報収集といった活動を通して、市場にあるサービス、海外や国内の類似事例、新たな技術の動向や製品のライフサイクル、概算の予算規模、スケジュール等について把握を行います。 その上で、機能要件と非機能要件を明確にします。機能要件では、機能、画面、帳票、データ、外部インタフェース等について、非機能要件ではユーザビリティ、システム方式、規模、性能、信頼性、情報セキュリティ等について記載します。記載項目のそれぞれについて、記載する目的、作成するドキュメントのイメージ、注意点等を説明しています。 様式のひな形　　　　要件定義書 ### 第６章　調達 要件定義までの工程で情報システムに求める全体機能は明確になりましたが、この内容をどのような単位に分けて調達を行うのかは重要なポイントです。分離調達を行うことのメリットとデメリットを説明し、調達の単位をうまく定めて調達計画を作成する方法を示します。 調達仕様書についてはひな形を示した上で、調達目的の正確な記載、作業内容と納品物を紐づけた明確化、実施体制や発注者としての役割について考え方や注意点を記載しています。また、総合評価落札方式で事業者の提案を評価する際に、評価点の配分の留意点や、事業者からWBSとして示される作業予定内容の精査のポイント等について説明しています。 様式のひな形　　　　調達仕様書 ### 第７章　設計・開発 設計・開発を事業者に丸投げしては、良い情報システムは作れません。要件を事業者に正しく伝え、関係者間の調整を行い、進捗状況を正しく把握し、情報システムの出来具合をテストするのは発注者である職員自身です。設計・開発において、職員自身が実施することにフォーカスして、業務内容を説明しています。 例えば、テストについても、結合テスト、総合テスト、受入テストといった工程の中で、機能面（シナリオテスト、業務サイクルテスト等）はもちろんのこと、非機能面（負荷テスト、セキュリティテスト、縮退テスト等）をそれぞれ確認します。職員自身がテスト計画やテスト結果について正しく判断できるように、テストの内容と確認ポイントについて説明しています。また、移行、リハーサル、運用・保守の準備、マニュアル等、重要なのに見落とされがちな作業について、計画の立て方、ドキュメントの作成方法、注意点等を示しています。 様式のひな形　　　　設計・開発実施計画書、設計・開発実施要領、 　　　　　　　　 受入テスト計画書 ### 第８章　サービス・業務の運営と改善 業務を実施する中でも、うまく外部委託を活用します。作業量が多く定期的に発生する作業は外部委託に向いていますが、業務上の専門知識を必要とする作業や品質確認が必要な作業は外部委託にはあまり向いていません。役割分担のコツについて説明します。 また、日常の業務の中で、利用者からの要望、インシデント、ログ情報等、様々な情報が蓄積しますが、それらの情報はサービスや業務を改善するための宝の山です。これらの情報を蓄積し、分析するための手法として事例等を紹介しています。 様式のひな形　　　　（特になし） ### 第９章　運用及び保守 運用及び保守の目的は、情報システムの安定的な稼働を維持することだけでなく、利用者へのサービスを継続的に改善することや運用コストを低減していくことも含まれます。 そこで、まず運用及び保守で実施する代表的な作業項目を説明しています。これらの作業は、事業者に実作業を依頼する比率が高くなるため、作業分担を明確にすることが重要です。運用契約の「忘れ物チェックリスト」等を含めて、注意点を記載しています。 また、運用工程では複数の事業者が関わるため、会議体の種類が多くなる傾向があります。代表的な会議体の種類と目的を示すとともに、定例会議における報告内容についても注意点を記載しています。 そのほかにも、変更管理、ログ等の蓄積、指標管理、運用業務の改善方法等、職員が主体的に運用・保守業務を管理するための具体的な知識やノウハウを説明しています。 様式のひな形　　　　運用計画書、運用実施要領、運用報告書　　　　　　　　　　　　　保守計画書、保守実施要領 ### 第１０章　システム監査 システム監査は、各プロジェクトの取り組みがその目標達成に正しく向かっているのか、プロジェクトの各フェーズでの実施プロセスは適切かといった観点から、現状を調査し、改善すべき点がないかを第三者の視点で客観的に点検・評価する活動です。 まず、各省ＰＭＯが複数年単位での監査計画を立て、どの情報システムを監査対象とするかを決めます。実際の監査の中では、監査責任者が監査実施計画書を作成し、監査目的、監査範囲、スケジュール、監査体制、実施方法等を定めますので、その記載方法等を示しています。また、予備調査の進め方、インタビューの実施方法、監査報告書の作成方法、監査後の改善の進め方等について解説しています。 様式のひな形　　　　監査実施計画書、監査報告書 - 参考1-2 WBS

参考：ＷＢＳ

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

![](../assets/ds-120-ch01-image3.png)