Step.6 新業務の運営を円滑に行うための準備

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

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

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

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

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

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

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

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

• 表7-20

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• 事例7-7

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

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

実践ガイドブック

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

目次

事例一覧