LASSIC Media らしくメディア

監修・編集責任者：牛尾 昭昌（株式会社LASSIC 執行役員）

リリースの日が近づき、テストの消化を急ぐために開発要員を加えた。ところが、何をもって出してよいとするのかが決まっておらず、判定の会議では残った不具合の重さをめぐるやり取りが続く——。開発の現場では、こうした場面が起こりがちです。リリース前の品質確認とは、本番に出す前に、テストの結果、移行の結果、稼働した後の運用の準備がそろっているかを確かめ、出してよいかを判定することを指します。

判定の基準を先に決めておけば、加わった開発要員にも何を確かめればよいかを伝えやすくなります。ただし万能ではなく、基準の書き方があいまいだと、判定の直前に解釈をめぐって揉めることになります。本記事では、開発を預かるマネージャーに向けて、デジタル庁の実践ガイドブックをもとに、2つの判定の違い、稼働判定で見る観点、否認条件の書き方、受入テストで社内が確かめること、開発要員に任せる作業、つまずきやすい点、そして外部に委託するときに確認しておきたい点を整理します。

リリース前の品質確認とは

手がかりにするのは、デジタル庁の「デジタル・ガバメント推進標準ガイドライン 実践ガイドブック」（DS-120）です。政府の情報システムを担う職員に向けて、プロジェクトを進める実務のノウハウや事例を記した参考文書で、2026年6月12日に改定された版が公開されています。^*2 第3編第7章「設計・開発」の終盤に、本番の開始をどう承認するかが書かれています。民間の会社に従う義務はありませんが、判定の項目を考えるたたき台になります。確かめる対象はテストの結果にとどまらず、移行の手順や稼働した後の運用の準備まで含みます。

ガイドブックは、サービス・業務の開始の承認を2段階で行うとしています。本番移行を始めることを承認する「移行判定」と、新しい情報システムへの切替え、つまりサービス・業務の開始を承認する「稼働判定」です。そのうえで、それぞれの判定について「いつ」「誰が」「何を判定するために」「どのような条件で」「どのように」判定するかを事前に定め、関係者と合意しておくよう求めています。^*1

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

ガイドブックは、2つの判定の違いを表7-20「移行判定と稼働判定の違いの例」にまとめています。意味を変えずに短く言い換えると、次のとおりです。^*1

移行判定は、品質確認の結果をまとめて見る場です。加わった開発要員の作業がどの条件の材料になるのかを、この表に沿って割り振れます。

呼び名は会社によって違います。ガイドブックは、リリース判定と稼働判定を同じものとして扱う形が最も多いとしています。そのうえで、情報システムを刷新する場合には、リリース判定で次期の環境に配置し、その後に現行の環境を止めてデータを移し、稼働判定の会議の結果をもって切り替える形もあるとしています。自社の案件でどの判定を何回行うのかは、案件ごとに分けて決めておきます。

稼働判定で見る3つの観点

ガイドブックは、稼働判定には3つの観点が要るとしています。開発した情報システムの正しさ、移行・切替え作業の確からしさ、稼働後の運用準備の状況です。そして、テストを重ねてきた1つ目に比べ、2つ目と3つ目は軽んじられる傾向があると指摘しています。^*1

正しさについて、ガイドブックは「計画した全てのテストケースを消化し、摘出された全ての障害が除去されていること」としています。テスト項目密度や不良密度のような品質メトリクスは、計画したテストケースの目安の1つにすぎず、それだけで判断してはいけないとしています。^*1 数値が目標の範囲に収まっていても、計画したケースが残っていれば、正しさの条件は満たされません。

見つかった障害の扱いも厳しめです。応急処置ができているから次回のリリースまで待つ、致命的な障害は手当てしたので軽微なものはこのままにする、といった扱いは許容しないことが必要だとしています。一方で、操作性の改善のように次回のリリースに回すのが妥当なものは、障害の管理ではなく課題の管理に含めるべきだとしています。

移行・切替え作業では、何も問題がなかったという報告で済ませず、エビデンスの提供を求めるよう書かれています。データ移行はレコード件数やハッシュ値の比較のような機械的なチェックで結果を確かめ、移行の直後に本番環境で疎通を確かめる程度のテストを済ませておく、という流れです。^*1

運用準備では、運用手順書、報告の様式、保守の連絡先といったマニュアル類に加え、移行直後の切り戻し手順、セキュリティインシデントへの対応手順、事業継続のための計画などの準備を確かめるとしています。

判定基準は否認条件で書く

ガイドブックは、リリース判定や稼働判定は、とかく形だけの会議になりがちだとしています。特に、制度改正や機器の更改でリリース日を延ばせない場合の判定会議はそうなりやすいと書いています。判定の会議を開くのは、最後に誤った判断をしないよう、発注者側と事業者側の双方のプロジェクトマネージャーが自ら振り返るためだと位置づけています。^*1

そのための手段として挙げているのが、どういう場合に「ダメ」を出すかを前もって文章にし、関係者で共有しておくことです。例えば「重要な障害が未解決でないこと」は厳密な判定基準ではなく、判定会議の直前に、残った障害の重要度を「軽」にしようとする交渉が起きるとしています。むしろ判定の「否認条件」を列挙し、1つでも該当すれば否認すると宣言しておくべきだとしています。^*1

否認条件は、表7-20の承認条件を裏返すと書きやすくなります。次は、承認条件をもとに書いた否認条件の例です。

ガイドブックは、判定基準を共有する関係者には事業者も含まれるとしています。基準を先に示しておけば、事業者はそれを満たしたうえで判定会議に臨むことが期待できる、という理由です。加えた開発要員にも同じ否認条件を見せておけば、テストの途中で何を優先すべきかの判断がそろいます。

受入テストで社内が確かめること

移行判定の前に行う受入テストについて、ガイドブックは第3編第7章 Step.4の「受入テストを実施する」で扱っています。想定したとおりに情報システムができているか、実際の業務を正しく行えるかという業務の視点での確認は、事業者にはできず、職員にしかできないとしています。^*1 民間の会社なら、システムを使う部門の社員が担う確認です。

進め方として、ガイドブックは、総合テストのケースから主要な業務を抜き出して発注者が確かめ直すだけで終わる例や、その場で思いついた操作を試すだけの例を挙げ、それでは意味のある結果になりにくいとしています。できるだけ本番データ、本番環境、実際の利用者、実際の運用者の4つでテストするべきだとし、本番データを使うのは、開発側が想定していない「きれいでない」データで試すためだと説明しています。^*1

受入テストでは、プロダクトとしての品質の確からしさより、リリース後の本番の準備が十分かを確かめるとしています。その方法として、システムや業務のマニュアルに沿ってテストする「マニュアルベースドテスト」を挙げ、正常時だけでなく、エラーや障害が起きたときにマニュアルの記載どおりで問題ないかも確かめるよう書いています。

ほかにも、正常系だけでなく異常系のテストも行うこと、事業者が受入テストの案づくりを支援する場合も内容をうのみにせず業務担当者の目線で確かめること、受入テストで使ったデータを本番環境に残さないことに注意を促しています。^*1

開発要員に任せる作業

受入テストの作り方には、分担の手がかりになる事例があります。ある省が既存の情報システムを刷新したとき、テスト仕様書を「目的」「シナリオ」「シナリオとテスト項目の組合せ」「テスト項目」に分けて書き、目的とシナリオは発注側のプロジェクト推進組織が作り、組合せとテスト項目は支援の事業者と分担して作るルールにしたというものです（事例7-5）。^*1 何を確かめるかは社内が決め、それを確かめる手順の書き起こしは加わった人と分ける、という線の引き方です。

これに沿って、リリース前に加えた開発要員に任せる作業と、社内に残す判断を分けると、例えば次のようになります。

開発の作業そのものを委託している場合も、考え方は似ています。ガイドブックは調達の章で、請負契約では受入テスト以外の検証は受注者に一任されるとしつつ、テストやレビューの計画と実施状況、合格基準と結果を提示してもらい、その妥当性を発注側が評価することが有効だとしています。第三者が同じ認識を持てるよう、基準を数値にしたり、YesかNoで答えられる形にしたりすることも有効だとしています。^*1 否認条件を件数や有無で書いておくのは、この考え方とも合います。

つまずきやすい点

一つめは、品質の数値だけで判定してしまうことです。テストの密度や不具合の密度が目標の範囲に入ったことを理由に判定を通すと、計画したケースが残っていても見過ごされます。数値は計画の妥当性を見る目安として使い、判定はケースの消化と障害の除去で行います。

二つめは、判定の直前に不具合の重さを付け直すことです。リリース日が動かせないほど、残った障害を軽微なものに分け直したくなります。障害か課題かの区分は判定の会議の前に締め切り、区分を変えるときは理由と承認した人を記録に残しておきます。

三つめは、移行と運用の準備を後回しにすることです。加えた開発要員をテストの消化だけに充てると、移行リハーサルの記録や手順書が判定の前日まで揃いません。表7-20の承認条件それぞれに担当と期限を付けておくと、偏りに早く気づけます。

外部に委託するときに確認しておきたい点

リリース前に開発要員を加える前に、移行判定と稼働判定をいつ、誰が、どの否認条件で行うかを書き出しておきます。そのうえで、表7-20の承認条件のうち、どれの材料づくりを任せるのかを決めれば、求める経験もはっきりします。

テストの終了基準とリリースの判定の関係はリリース前のテスト要員と開発要員の違い、分ける作業と判定で扱っています。

移行計画に書く項目は業務委託エンジニアと進めるクラウド移行、移行計画に書く6つの項目に、リリース時に企業が実施している確認の調査結果はリリース前の確認事項、移行計画やリハーサルなど6つの項目にまとめました。

まとめ：品質確認で確かめておきたい3つの点

開発要員を加えてリリース前の品質確認を進めるうえで、確かめておきたい点は3つに整理できます。第一に、移行判定と稼働判定をいつ、誰が、どの条件で行うかを先に決め、テストの消化だけでなく移行と運用の準備も確かめる対象に入れること。第二に、判定の基準は否認条件として列挙し、開発要員や委託先とも事前に共有すること。第三に、テスト項目の書き起こしや移行リハーサルの記録は任せても、受入テストの業務シナリオ、障害か課題かの区分、2つの判定は社内に残すことです。この3点を踏まえておけば、「リリース日は守れたが、移行の確認と手順書が足りず、稼働した翌日から現場が混乱した」という事態を避けやすくなります。任せる作業に合う人の探し方に迷いがあれば、外部の手を借りるのも一つの選択肢です。

よくある質問

出典

1. *1　参考：デジタル庁「デジタル・ガバメント推進標準ガイドライン 実践ガイドブック（DS-120）」2026年6月12日（PDF）（https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/e2a06143-ed29-4f1d-9c31-0f06fca67afc/0af5ce68/20260715_resources_standard_guidelines_guideline_05.pdf）。出典：第3編第7章 Step.4-5「受入テストを実施する」（事例7-5を含む）、Step.6-1「本番移行と本番稼働の開始を承認する」（表7-20を含む）、第3編第6章 Step.3-2 H の「契約不適合」を契約条項とするときの留意点（※2・※3）を参照（確認日2026年10月6日）（2026年10月確認）
2. *2　参考：デジタル庁「デジタル社会推進標準ガイドライン」（公開ページ）（https://www.digital.go.jp/resources/standard_guidelines）。実践ガイドブック（DS-120）の現行版として上記のファイルが案内されていることの確認として（確認日2026年10月6日）（2026年10月確認）

Tweet