--- type: guideline title: Step.2 新しいサービス・業務の事前準備 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 --- # Step.2 新しいサービス・業務の事前準備 今まで行っていたサービスや業務を改め、新しいサービス・業務を開始する前に、理解しておくべき前提知識や心構えについて説明します。 ## 運営と改善は、職員主体の作業である 【標準ガイドライン関連箇所：第３編第８章第１節】 新しい情報システムを利用してサービスや業務を実施する際、ＰＪＭＯの職員は情報システムを構築することに意識が行きがちです。一方、利用者にとっては、情報システムが構築直後に「満足な出来」であることは少なく、大なり小なり期待値とのギャップがあります。これを解消するため、利用者からのフィードバックを得ながら、業務と情報システムの双方を改善していく活動を継続していくことが重要です。 この仕事は、職員が主体となって実施していくこととなります。仮に外部の事業者が極めて優秀かつ良心的であったとしても、やはり業務と情報システムの両輪を相互に調整しながら改善していくマネジメントは、業務を熟知した職員がリードしていくほかありません。 これらの点について、以下に解説していきます。 ### 『サービス・業務の運営と改善』を外部の事業者に丸投げしない サービス・業務を運営する中では、業務・サービスに関連する日常的なオペレーションはもちろんのこと、問合せや要望への対応、利用促進のための周知や広報活動等、様々な活動を職員が主体的に実施します。 ただし、一部の作業については、職員が正しく作業を切り出し指示や管理をすることを前提に、外部の事業者に作業を委託できるものがあります。例えば、業務で発生するデータの入力業務や、帳票の仕分け業務等です。 では、どのような業務が事業者への委託に向いているでしょうか？一般的には、次の図のような考え方ができるでしょう。 - 図8-1 外部委託の向き／不向きの判断例 ![](../assets/ds-120-ch08-image1.png) ただ、事業者にサービス・業務を一度委託すると、委託を止めて職員が実施する状態に戻すことは難しくなります。業務実施場所、関連機器等を再度確保する必要がありますし、何より体制を作り直して実際に業務をする職員のスキルを元通りに戻すことに相当の時間がかかるためです。 そのため、外部委託をする場合は、職員による業務実施への回帰や事業者の変更に備え、業務ノウハウが職員にも残るような工夫をすることが重要です。また、事業者に対して適切な指示ができるように、業務概要を理解し、日常的な報告・記録を確保することが重要です。 業務を外部委託する際の注意点 - 外部委託する業務は、職員が主体的に行う業務に対する支援や補助となる作業であり、それを行うことで職員の業務効率が向上するものであること。 - 外部委託した業務成果の正誤や品質状況を職員が判断できるように、プロセスの透明化と必要十分な報告・記録を確保すること。 - 外部委託した業務の実施方法や、事業者が作成する業務マニュアル等の内容を適宜確認し、職員自身も業務の概要を理解し続けること。 - 特定のサービス・業務について、異なる作業範囲や役割を複数の事業者に外務委託する場合は、緊急時（システム故障やセキュリティインシデント等）に備えて、できるだけ特定の事業者に業務統制的な役割を定義しておくこと。 - 事例8-1 外部委託で業務効率が向上

事例：外部委託で業務効率が向上

ある府省では、業務の運営上、日々収集される書類や記録等を、情報システムにデータとして入力する作業が存在していました。この作業は、特別な業務のノウハウが必要ではなく、入力作業の手順さえ守れば、だれでも行うことができる内容でした。

そのため、職員は入力手順を定めた作業手順書を作成し、このデータ入力業務を外部の事業者に委託することとしました。さらに、作業の実施状況を把握し、作業上の不明点に答えられる管理体制を構築しました。

これにより、外部委託前に比べ、業務の効率を向上させることができました。
- 事例8-2 外部委託でトラブルが発生

事例：外部委託でトラブルが発生

ある府省では、新しい情報システムの運営を開始するに当たり、新しく業務の実施手順をまとめたドキュメント（業務手順書）を作成する必要が発生しました。

そのため、業務手順書の作成を外部の事業者に委託しました。作業するに当たり、新しいサービス・業務の内容が分かるように要件定義書を渡しました。

しばらく後、出来上がった業務手順書を見ると、内容は情報システムの使い方が中心となっており、業務の担当者が意識すべきルールや制約事項等を読み取ることができないものとなっていました。現場の業務担当者からも、利用できないという不満が上がってきました。

結局、業務手順書は改めて、職員が主導で作り直すことになってしまいました。
### 『サービス・業務の運営と改善』は他工程の作業と並行で実施する 次の図（図8-2）をご覧ください。これは、標準ガイドライン第３編の各章で規定した作業が実際のプロジェクトが９年程度の期間でどう位置づけられるかを表したものであり、第８章の範囲を強調しています。 - 図8-2 サービス・業務の運営と改善とその他の工程の関係 ![](../assets/ds-120-ch08-image2.png) これまで紹介してきた、「第４章 サービス・業務企画」から「第７章 設計・開発」までの流れは、サービス・業務を企画・設計し、必要となる情報システムをどう構築していくか、という作業が中心となっており、この後の章で紹介する、「第９章 運用及び保守」は、新しい情報システムがリリースされた後、どう運用していくか、という作業が中心となっています。 それらを踏まえて、第８章の位置づけを見ると、その全ての期間を通じて作業が発生しています。また、情報システムが構築される前からリリースされた後まで、全ての範囲に関係しています。 第８章で定義した作業と他の工程との関係を、第８章を中心に書いた図で紹介します。個々の作業の定義は標準ガイドライン解説書を見ていただくとして、ここでは、第８章が１つの作業プロセスとして独立して進められるものではないことを理解しておきましょう。 - 図8-3 標準ガイドライン本編におけるサービス・業務の運営・改善とその他の工程の関係 ![](../assets/ds-120-ch08-image3.jpeg) 『サービス・業務の運営と改善』作業と他の工程との関係 - 「第８章 １．サービス・業務の運営準備」は、サービス・業務をリリースするまでの準備作業であるため、主に「第７章 設計・開発」で実施される作業と依存関係があり、時間的にも並行で作業を実施します。作業は、「第２章 プロジェクトの管理」や「第４章 サービス・業務企画」の作業の結果を踏まえて行う必要があります。 - 「 - 注記 ＩＴＩＬ（Information Technology Infrastructure Library）とは、1989年に英国政府のＣＣＴＡによって公表されたＩＴサービスマネジメントにおけるベストプラクティスをまとめたもの。2023年時点ではITIL4が最新バージョンである。 第８章 ２．サービス・業務の運営」は、サービス・業務を継続的に運営する作業であるため、主に「第９章 運用及び保守」で実施される作業と依存関係があり、時間的にも並行で作業を実施します。これ以外にも、運営中に発生する課題や要望を集約し、その対応を判断し、その結果によってその他の章で定義されている作業に振り分けます。（※これはＩＴＩＬが定める問題管理に相当します。） - 「第８章 ３．サービス・業務の改善」は、他の章で定義された作業とは関係しません。「第８章 ２．サービス・業務の運営」で集約された様々な課題や要望は、その解決のために様々な作業に振り分けられますが、軽微な改善はここで定義された作業で行います。 ### 関連する業務実施部門との責任分担を意識する 複数の組織や情報システムをまたがってサービス・業務を運営する場合は、関連する組織と、業務の責任範囲を明確にしておく必要があります。これを怠ると、トラブルの発生時に誰がどこまで対応を行い復旧の責任を持つかといった問題がこじれてしまう可能性があるからです。 特に情報システムが関係するトラブルの場合は、発生してから一定時間は、真の原因が不明であったり、本質的な問題解決方法が見いだせなかったりすることがあります。このため、単に責任分界点を定めただけでは「責任の押し付け合い」を招き、解決を遅らせる懸念もあります。 例えば、次の図で示すようなケースを考えてみましょう。１つの情報システムをＡ、Ｂの２つの組織が利用しています。Ａ組織はデータを入力する業務を行っていますが、そこで誤ったデータを入力してしまいました。しかし、そのデータを使うＢ組織は、データの誤りに気付かず、そのデータを使って業務を実施してしまいました。そして、Ｂ組織で不具合として顕在化してしまいました。 このケースの場合、不具合の責任がA、Bのどちらにあるのか、一概には判断することができません。データの正確性を確認する責任が、Ａ、Ｂ、どちらの組織にあったのかが判断のポイントになるでしょう。しかし、あらかじめこのような事態を想定した責任分担を行っていないと、トラブルが発生した後で議論や調整に時間を取られてしまい、速やかな対応ができません。 - 図8-4 複数の組織が関係するトラブルの例 ![](../assets/ds-120-ch08-image4.png) - 事例8-3 利用者からの問合せ窓口が分かりにくくなってしまった例 このような事態を未然に防止するために、サービス・業務の運営を開始する前には、業務実施分担や責任分担等について、関係する組織と十分に事前調整を行ってください。

事例：利用者からの問合せ窓口が分かりにくくなってしまった例

あるプロジェクトでは、各府省にまたがった業務をワンストップ化するサービスを実現するため、各業務の既存システムは残しつつ、利用者視点からワンストップで手続き申請を受け付ける情報システムを構築しました。新しい情報システムは順調に稼働したのですが、利用者からの問合せ窓口については十分に事前調整が行えておらず、既存のコールセンターに加えて、新システムのコールセンターを新設する形としていました。

![](../assets/ds-120-ch08-image5.png)

その結果、利用者からは「どこに問合せしたら良いか分からない」、「コールセンターへ電話したら、違うコールセンターに電話するようにと言われてしまった」など、問合せ方法についての苦情が寄せられてしまいました。

また、各コールセンターにおいても所管外の問合せが数多く発生することになり、問合せ対応の現場が混乱する事態になってしまいました。

業務の役割分担を決める際には、このように利用者からの問合せをどのように受け付けるかを事前に決定するとともに、利用者に対して問合せ先を分かりやすく周知することが重要です。
## 業務手順書は様々な用途に有効活用できる 【標準ガイドライン関連箇所：第３編第８章第１節】 業務手順書の作成を外部委託しトラブルが発生した事例を前に触れましたが、業務手順書は、その認識の仕方が人によって異なっていることも多く、同じ名称でも中身が異なることが多くあります。 ここでは、業務手順書を作成することの目的や効果、業務手順書と類似のドキュメントの違い等を説明し、認識を合わせます。 ### 業務マニュアルと他のマニュアルとの違いを理解する 情報システムを用いてサービス・業務を運営するために、様々なマニュアルが存在します。 マニュアルに関する全体的な解説は、実践ガイドブック「第７章Step.5－3．種類を理解し揃えるマニュアルを厳選する」を参照してください。 業務マニュアル作成時の注意点 - 業務マニュアルは、同じ業務に携わる担当者が共通の理解を持つために有効ですが、組織や取り扱う情報の種類によっては、同じ業務でも異なるルールが存在する場合があります。いわゆる、ローカルルールと呼ばれるものです。これを全て業務マニュアルに記載しようとすると、膨大な量となり、マニュアルの更新が追いつかず、現場とのかい離が発生するおそれがあります。同じ業務内で共通化するものと、組織ごとに個別に定めるものとで分けて業務マニュアルを作成することで、その後の保守性を向上させることができます。 - 図8-5 業務マニュアルに載せる範囲 ![](../assets/ds-120-ch08-image6.png) - 業務マニュアルは、そのまま職員向けの教育資料の一部とすることができます。そのことを念頭に、業務マニュアルの内容・構成を検討してください。 - 業務マニュアルには、具体的なシステムの操作手順にとらわれず、業務の流れや手順を中心に記述してください。その流れの説明において、情報システムのどの機能を使うのか、がわかれば、使いやすいものになります。情報システムの操作手順や画面説明の詳細はシステムマニュアルに任せることで、マニュアルの品質を上げることができます。 - 業務マニュアルは業務全体の業務フローを理解している職員が作成、又はレビューしてください。そうすることで、マニュアル上の業務説明が途中で途切れたり、内容の重要性に偏りが出たりすることが防げます。マニュアルが出来上がったら、業務に初めて携わる職員がそのマニュアルを読んで業務が行えるか、という観点でチェックしてください。 ## リハーサル計画・シナリオは職員目線で 【標準ガイドライン関連箇所：第３編第８章第１節】 リハーサルとは、新しい情報システムがリリースされる前に、業務の切替え（移行）時の手順や切替え後の作業内容を職員目線で確認する行為です。業務の切替え（移行）時の確認行為を移行リハーサル、業務切替え後の作業内容の確認行為を業務リハーサルと呼びます。 ### 移行リハーサルを計画・実施する 移行リハーサルでは、現行の業務で使用していた情報を、あらかじめ設計した方法で新しい情報システムに取り込み、想定どおりに動作することを確認します。それに向け、リハーサルの実施計画や実施手順を作成し、計画に基づいて、手順どおりにリハーサルを実施します。 移行リハーサルの計画立案は、情報システム構築事業者に依頼します。ただし、計画上の実施時期や回数、位置づけ等に関するチェックは、ＰＪＭＯが中心になって行います。 また、移行に際し、気を付けるべきポイント等、職員しか判断できないものについても、ＰＪＭＯ及び業務実施部門が事前にチェックしてください。チェックの内容には、新しい情報システムに移行する情報について、現行のどの情報をいつのタイミングで抽出するのか。また、例外的な情報等は、事前に決めたとおりに扱うことになっているか等があります。 ### 業務リハーサルを計画・実施する 業務リハーサルでは、新しい情報システムをリリースした後に、切替え後の業務を円滑に遂行できるよう、職員が主体となって、業務内における職員の役割分担や、情報システムを含む業務の実施手順を確認します。例えば、今までの業務にて担当者間で書類を手渡ししていたような場合、オンライン化によって、誰がどこまで書類のデータをシステムに入力するのか、といった観点の確認や、記載された手順だけで業務が過不足なく実施できることを確認します。 業務リハーサルの手順や実施スケジュールの作成は、業務実施部門の職員が行います。ただし、職員のみで実施が難しい日次処理や月次処理等のバッチ処理の実施タイミングの検討や、それらの処理に伴う実施スケジュールの調整、業務リハーサルの実施等については、情報システム構築事業者や工程管理事業者等に支援を依頼して進めます。 業務リハーサルの内容（作業の内容・流れをまとめたもの。シナリオと呼ばれることもある。）は、ＰＪＭＯ及び業務実施部門が中心となってレビューし、過不足が無く、現実的なものかをチェックします。例えば、業務リハーサルを実施する時期と業務の繁忙期との関係や、業務リハーサルを実施する業務実施部門における職員の異動の有無、休日に実施する場合の対象職員の確保等、様々な要素があります。 また、業務リハーサルの実施そのものも、職員が主体となって行うことが重要です。職員が業務リハーサルを実施することで、移行時に発生すると致命的となる問題を発見することができます。これにより､業務ピーク時にも所期の時間内で業務遂行が可能か､移行後の業務運用において考慮漏れがないか等の検証ができます。 - 事例8-4 利用者への周知が不十分なプロジェクトの顛末

事例：利用者への周知が不十分なプロジェクトの顛末

あるプロジェクトでは、業務効率改善のために、業務担当者が今までは情報システムに書類の内容を手入力していた作業を、今後はＯＣＲ（文字認識）ツールを用いて自動読み取りすることで業務担当者の手間を軽減する検討を進めていました。

この情報システムは、構築事業者により順調に改修が進み、機能面についても一部の業務担当者がテストや確認を実施し、問題がないことを確認できました。

![](../assets/ds-120-ch08-image7.png)

しかし、現場を巻き込んだ全面的な業務リハーサルは行いませんでした。情報システム担当が業務担当者の代わりに簡単なリハーサルを行い、業務担当者にはアナウンスのみを行った上で業務の切替えを実施しました。

その結果、リリース直後に業務担当者から、従来の業務の進め方との違いやＯＣＲ読み取り対象外となる書類の取り扱い等の問い合わせが殺到し、一時的に業務が滞る事態となりました。

![](../assets/ds-120-ch08-image8.png)

その後、業務担当者に対して改めて業務の研修を行い、なんとか混乱を収束することができました。
### サービスの開始や変更を利用者に確実に周知する ある日突然、システムの利用方法や画面操作が変更されていると、利用者は戸惑ってしまいます。例えば、事前の告知なく画面に配置された複数のボタンの位置が入れ替わっていると、利用者が使いたい機能を見つけられず不便を感じる可能性があります。さらに、利用者が情報システムの操作にRPAを活用していた場合、RPAが意図した動作を実行できず、業務が滞ってしまう可能性もあります。 リリース直前に連絡しても、十分に周知が間に合わないこともあります。利用者に対しては、計画的にサービスの開始や変更内容を伝えるように留意してください。