---
type: guideline
title: Step.6 新業務の運営を円滑に行うための準備
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.6 新業務の運営を円滑に行うための準備

情報システムのテストが一通り完了し、あとは本番移行を行いサービス・業務を開始するところまで来ました。でも、ちょっと待ってください。本当にそのままサービス・業務を開始して大丈夫でしょうか？

ここでは、サービス・業務を無事に開始し、円滑に運営していくために必要となる設計・開発の活動の締めくくりの作業についてのポイントを見ていきます。

## 本番移行と本番稼働の開始を承認する

【標準ガイドライン関連箇所：第３編第７章第８節】

サービス・業務の開始の承認には、本番移行の開始を承認する「移行判定」とサービス・業務の開始（＝新しい情報システムへの切替え）を承認する「稼働判定」の２段階で行います。

ここでは、移行判定と稼働判定のポイントについて紹介します。

### 移行判定と稼働判定の違いを理解する

移行判定と稼働判定は、ともに設計・開発の活動の最終盤で行うサービス・業務の開始に係る判定行為ですが、そこで判定する内容や条件等は異なります。次に示す違いの例を参考に、それぞれの判定において、「いつ」「誰が」「何を判定するために」「どのような条件で」「どのように」判定するかを事前に定めて、関係者と合意しておきましょう。

- 表7-20

移行判定と稼働判定の違いの例

<table style="width:97%;">
<colgroup>
<col style="width: 13%" />
<col style="width: 21%" />
<col style="width: 23%" />
<col style="width: 39%" />
</colgroup>
<thead>
<tr>
<th>判定の種類</th>
<th>承認内容の例</th>
<th>タイミングの例</th>
<th>承認条件の例</th>
</tr>
</thead>
<tbody>
<tr>
<td>移行判定</td>
<td>本番移行の開始</td>
<td>受入テスト、移行リハーサル完了後、本番移行前</td>
<td><ul>
<li><p>受入テストの完了が承認されている</p></li>
<li><p>第三次レビューで妥当と判断される</p></li>
<li><p>移行計画書及びリハーサルの結果が適正である</p></li>
</ul></td>
</tr>
<tr>
<td>稼働判定</td>
<td><p>本番稼働の開始</p>
<p>（新しいサービス・業務の開始）</p></td>
<td>本番移行の完了後又は完了が確実に見込まれるとき</td>
<td><ul>
<li><p>本番環境への移行の結果が適正である</p></li>
</ul></td>
</tr>
</tbody>
</table>

#### その稼働判定でリリースを止められますか

リリース判定と稼働判定には様々なパターンがあります。リリース判定＝稼働判定が最も多いですが、情報システム刷新の場合はリリース判定で次期環境へデプロイ（情報システムの展開・配置）、その後に現行環境を止めて次期環境へデータ移行し、稼働判定会議の結果をもって現行の情報システムから次期情報システムに切り替える場合もあります。同時にデータ移行する場合や先にデータ同期をとっている場合も前者のパターンとなるので、案件によってリリース判定、稼働判定を分けて検討しておきます。

リリース判定、稼働判定はとかくシャンシャン会議になりがちです。特に、制度改正や機器更改でリリース日が延伸できない場合の判定会議はそのような場となります。そもそもなぜ判定会議が必要かと言えば（担当者から管理者への最終判断伺い及び承認行為の意味合いもありますが）、最後の最後で誤った判断をしないよう発注者側・事業者側双方のプロジェクトマネージャが自ら振り返るためです。発注者側は、状況を正しく認識できるまで事業者に噛み砕いた説明を求めて理解するか、情報システムのことがわかるＰＭＯ・ＰＪＭＯの判断を仰ぐべきです。

そのためには、どういう場合には「ダメ」を出すか、あらかじめ明文化して関係者で共有しておくことが必須です。グループシンク（集団浅慮）に陥らないようにするには、リリース、稼働判定基準は厳密に定めておく必要があります。例えば「重要な障害が未解決でないこと」というのは、厳密な判定基準ではありません。その場合、判定会議直前に残障害の重要度を「軽」にしようとする交渉が巻き起こります。むしろリリース判定、稼働判定の「否認条件」を列挙し、１つでも該当すれば否認することを宣言しておくべきです。

共有する関係者には当然、事業者も含まれています。判定基準をあらかじめ提示し、「ダメ」出しするラインを知らせておくことで、事業者が当然それをクリアした上で判定会議に参加してくることを期待することができます。

#### 情報システムの正しさだけでは不十分

稼働判定は、①開発した情報システムの正しさ、②移行・切替え作業の確からしさ、③稼働後の運用準備状況、の３つの観点が必要となります。ここまでにテストしてきているので①開発システムについては十分に確認できているでしょうが、それに比べて②移行・切替え作業、③運用準備は軽んじられる傾向があります。

開発した情報システムの正しさとは「計画した全てのテストケースを消化し、摘出された全ての障害が除去されていること」です。テスト項目密度や不良密度のような品質メトリクスは「計画した全てのテストケース」の目安の１つにしか過ぎず、それだけで判断してはいけません。「摘出された全ての障害」はまさに字句どおり全て除去すべきで「ワークアラウンド（応急処置）は確立できているので次回リリースまで…」とか「致命的な障害の手当はできているので軽微な障害はこのまま…」というのは許容しないことが必要です。逆からいうと、操作性等の改善事項であって次回リリースに回すことが妥当なものは、障害管理ではなく課題管理に含めるべきです。

移行・切替え作業の確からしさでは「何も問題ありませんでした」ではなく、きちんとエビデンスの提供を求めることが必要です。データ移行についてはレコード件数やハッシュ比較のような機械チェックで移行結果を検証（特に移行作業が複数拠点の場合）し、その上で移行直後に「本番環境」での疎通テスト程度の確認は完了しておきます。ただし多くの場合、移行・切替え時には何らかのデータベースのテーブルレイアウト変更が入るので、ツールで現新比較するにはフィルタリングや正規表現等の工夫が必要となります。

運用準備では運用手順書、報告フォーマット、保守連絡先のような運用・保守マニュアル類の他、移行直後の切り戻し手順、セキュリティインシデント対応手順、ＢＣＰ等のコンティンジェンシープランの準備を確認しておきます。また、これらのドキュメントに即してテストする「マニュアルベースドテスト」も有効です。正常時の操作・運用だけでなく、エラー・障害・インシデントが発生した際の手順についても確認しておくようにしましょう。さらに案件によっては、エンドユーザあるいはヘルプデスクへの教育・訓練も必要となってきます。特に大規模システム更改などでは、本稼働「直後」に深刻なシステム障害が発生した場合の切り戻し手順が必要でないかを検討しておくことも大切です。

## 正しく引継ぎを行い、トラブルを減らす

【標準ガイドライン関連箇所：第３編第７章第９節】

設計・開発に携わった事業者の交代（又は撤退）は、設計・開発の終了時点でやってくるとは限りません。一般的には、設計・開発事業者は情報システムの整備後も運用・保守等で関わることが多いですが、運用・保守の途中で事業者を交代することもあります。このような場合に、設計・開発に関する情報が欠落してしまい、トラブルになることも少なくありません。また、設計・開発の終了や運用・保守が安定したタイミング等で、事業者側の体制の縮小によりキーマンが移動することでも、同じようなことが起こり得ます。

このため、標準ガイドラインでは、設計・開発事業者から運用事業者及び保守事業者への引継ぎを行うように定めています。

引継ぎの際には、成果物についての引継ぎが中心に行われがちですが、絶対に忘れてはいけないのは「課題」の引継ぎです。残存している課題については、保守等を通して今後の対応を検討していかなければいけませんし、既に対処済みの課題であっても、運用作業の制約になっているかもしれません。

課題の引継ぎを求めると、多くの場合は課題一覧が提出されますが、これだけでは不十分な場合があります。課題の一覧には、詳細な経緯、決定事項の理由、課題に係る調査結果等が完全には含まれていないことが多く、これらを欠落してしまうことで、誤った対応や検討漏れ等を招くこともあります。

したがって、引継ぎに当たっては、発注者、設計・開発事業者、運用事業者及び保守事業者等の関係者で課題の内容を確認し、必要に応じて経緯の説明や不足する情報を求めるようにしてください。

- 事例7-7

異なる事業者間で引継ぎをスムーズに行う工夫

<table style="width:97%;">
<colgroup>
<col style="width: 96%" />
</colgroup>
<thead>
<tr>
<th><p>事例：異なる事業者間で引継ぎをスムーズに行う工夫</p>
<p>設計・開発事業者が作成した運用手順書を用いて運用事業者が運用作業を行う場合、手順どおりに行ったとしてもうまくいかないことがあります。これは、設計・開発事業者が作成した運用手順書は、設計・開発時に運用作業を想定して作成されたものであり、実際に稼働している本番環境での運用作業とは異なっていることなどが原因です。</p>
<p>また、運用事業者が運用手順書を作成して運用作業を行っても、やはりうまくいかないことがあります。これは、設計思想などの資料に表れにくい情報があること、設計・開発を行っていない運用事業者が設計の詳細を把握できていないことなどが原因です。</p>
<p>運用段階で、このような問題が生じないよう、スムーズに引継ぎを行うための工夫をご紹介します。</p>
<ul>
<li><p><strong>設計・開発だけでなく運用作業も調達範囲とする</strong></p></li>
</ul>
<p>ある省庁では設計・開発事業者が自ら作成した運用手順書を用いて１年間の運用作業を行うところまでを調達範囲としています。設計・開発時の想定だけでなく、実際の運用を経て運用手順書を作成することができるため、設計・開発に携わった事業者が次年度に変更になり引き継いだあとも、作業が円滑に進められるようになります。</p>
<ul>
<li><p><strong>引継ぎ期間を長く設定する</strong></p></li>
</ul>
<p>引継ぎ期間は1か月程度を設定するのが一般的ですが、十分ではないケースが多くみられます。</p>
<p>ある省庁では、引継ぎ期間を３か月とり、設計・開発事業者が作成した運用手順書（案）を、設計・開発事業者と運用事業者が協力してブラッシュアップし、運用手順書を完成させるという旨をそれぞれの調達仕様書に明記しています。そうすることで実際の運用作業中に発見された手順の不備を解消しつつ、設計・開発に関する情報を運用事業者に引き継ぐことができています。</p>
<p>このように、設計・開発事業者を運用の初期段階の実務にも関与させることで、品質の高い手順書が作成され、スムーズな引継ぎができることが期待されます。ただし、事業者間の調整を綿密に行うためには発注者側の負担も相応に増加するので、十分に計画することが重要です。</p>
<ul>
<li><p><strong>事業者間の協力関係を築きやすくする</strong></p></li>
</ul>
<p>障害などの問題が発生したときにばかり設計・開発事業者と運用事業者を交えた打合せを行うと、責任の押し付け合いになったり、同席を嫌がったりして円滑に運営できなくなるおそれがあります。</p>
<p>ある省庁では、共通のコミュニケーションツールを導入することで、問題発生時だけでなく、平時からコミュニケーションを取りやすい環境を作っています。また、情報システムの円滑な運用を目的とした、設計・開発事業者と運用事業者の双方が出席する会議体を設置するとともに、それを協力して運営することを調達仕様書で求めています。</p>
<p>複数の事業者の協力を得て情報システムを円滑に運用するためには、このように事業者間の協力関係を築く工夫も必要です。</p></th>
</tr>
</thead>
<tbody>
</tbody>
</table>

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

実践ガイドブック

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

目次

[１ 運営と改善は、職員主体の作業である [6](#運営と改善は職員主体の作業である)](#運営と改善は職員主体の作業である)

[A. 『サービス・業務の運営と改善』を外部の事業者に丸投げしない [6](#サービス業務の運営と改善を外部の事業者に丸投げしない)](#サービス業務の運営と改善を外部の事業者に丸投げしない)

[B. 『サービス・業務の運営と改善』は他工程の作業と並行で実施する [8](#サービス業務の運営と改善は他工程の作業と並行で実施する)](#サービス業務の運営と改善は他工程の作業と並行で実施する)

[C. 関連する業務実施部門との責任分担を意識する [9](#関連する業務実施部門との責任分担を意識する)](#関連する業務実施部門との責任分担を意識する)

[２ 業務手順書は様々な用途に有効活用できる [11](#業務手順書は様々な用途に有効活用できる)](#業務手順書は様々な用途に有効活用できる)

[A. 業務マニュアルと他のマニュアルとの違いを理解する [11](#業務マニュアルと他のマニュアルとの違いを理解する)](#業務マニュアルと他のマニュアルとの違いを理解する)

[３ リハーサル計画・シナリオは職員目線で [12](#リハーサル計画シナリオは職員目線で)](#リハーサル計画シナリオは職員目線で)

[A. 移行リハーサルを計画・実施する [12](#移行リハーサルを計画実施する)](#移行リハーサルを計画実施する)

[B. 業務リハーサルを計画・実施する [13](#業務リハーサルを計画実施する)](#業務リハーサルを計画実施する)

[C. サービスの開始や変更を利用者に確実に周知する [14](#サービスの開始や変更を利用者に確実に周知する)](#サービスの開始や変更を利用者に確実に周知する)

[１ 職員に継続的な教育を行う [15](#職員に継続的な教育を行う)](#職員に継続的な教育を行う)

[A. 研修・教育の準備を十分に行う [15](#研修教育の準備を十分に行う)](#研修教育の準備を十分に行う)

[B. 研修・教育は１回では定着しない [15](#研修教育は１回では定着しない)](#研修教育は１回では定着しない)

[２ 定着には利用者への働きかけが必要 [16](#定着には利用者への働きかけが必要)](#定着には利用者への働きかけが必要)

[３ 業務で扱うデータの品質を確保する [18](#業務で扱うデータの品質を確保する)](#業務で扱うデータの品質を確保する)

[A. 計画どおりにデータを入れないと情報システムの価値はない [18](#計画どおりにデータを入れないと情報システムの価値はない)](#計画どおりにデータを入れないと情報システムの価値はない)

[B. 分析しやすいデータ構造でないと、何かするにもカネがかかる [18](#分析しやすいデータ構造でないと何かするにもカネがかかる)](#分析しやすいデータ構造でないと何かするにもカネがかかる)

[４ 業務改善に向け日常業務の事実を蓄積する [19](#業務改善に向け日常業務の事実を蓄積する)](#業務改善に向け日常業務の事実を蓄積する)

[A. ＰＪＭＯ・職員が様々な情報を収集し、定常的に管理する [19](#ｐｊｍｏ職員が様々な情報を収集し定常的に管理する)](#ｐｊｍｏ職員が様々な情報を収集し定常的に管理する)

[B. 情報システムのログ等、運用活動に関わる情報を取得可能にする [20](#_Toc129617499)](#_Toc129617499)

[C. 効果測定ができるように、ＫＰＩを自動的に取れるようにしておく [22](#効果測定ができるようにｋｐｉを自動的に取れるようにしておく)](#効果測定ができるようにｋｐｉを自動的に取れるようにしておく)

[D. 多数のインシデントや要望等の対応の優先度を付ける [23](#多数のインシデントや要望等の対応の優先度を付ける)](#多数のインシデントや要望等の対応の優先度を付ける)

[１ 日常業務中でも改善できることを理解する [26](#日常業務中でも改善できることを理解する)](#日常業務中でも改善できることを理解する)

[２ 検討の進め方を理解する [27](#検討の進め方を理解する)](#検討の進め方を理解する)

事例一覧