稼働判定チェックリストのテンプレート
稼働の1週間前になると、どのプロジェクトでも同じ会話が始まります。「このまま行って大丈夫でしょうか」「たぶん大丈夫だと思います」。この「たぶん」を、判断できる形に変えるのが稼働判定チェックリストです。
この記事では、稼働（本番リリース）の可否を決めるためのチェックリストのテンプレートを紹介します。大事なのは項目の数ではなく、必須条件と望ましい条件を先に分けておくことと、判定結果を3つに限ることです。記入例は、事例集の「加美乃フーズ（架空）の生産管理システム刷新」に当てはめています。
■ 1. 背景・よくある課題
よくある状態 | 何が起きるか |
|---|---|
判定の基準が決まっていない | 稼働の直前に「これは必須か」を議論し、その場の空気で決まる |
項目が「〜できていること」の羅列になっている | 誰が見ても同じ答えにならず、○を付ける人によって結果が変わる |
判定結果がGoとNo-Goの2つしかない | あと一歩の状態でも、延期か強行かの二択になる |
切り戻しの項目が入っていない | 戻せない状態で稼働し、問題が起きたときに逃げ場がなくなる |
判定会議が稼働の前日に開かれる | ×が見つかっても、もう挽回する時間がない |
誰が決めるかが決まっていない | 全員が「自分は反対しなかった」と思う状態で稼働する |
稼働の判定でいちばん怖いのは、×が見つかることではありません。×かどうかを判断できないまま当日を迎えることです。判断できていない状態で稼働すると、問題が起きたときに「戻すべきか、このまま進むべきか」も判断できません。
■ 2. テンプレート作成の目的
目的 | 具体的にどうなることか |
|---|---|
判定の基準を先に決める | 焦っていない時期に、必須と望ましいを分けて合意しておく |
誰が見ても同じ答えになる項目にする | 「〜できている」ではなく、数字や成果物で判定できる形にする |
あと一歩の状態に答えを用意する | 「条件付きGo」という選択肢を置く |
戻る道を確保しておく | 切り戻し手順と判断期限を、判定項目に入れる |
決める人を明確にする | 判定会議の議長と、最終決定者を決めておく |
■ 3. テンプレートの全体像
部品 | 役割 | 作る時期 |
|---|---|---|
① 判定基準表 | 6分野の項目を並べ、必須／望ましいに分ける | 稼働の2か月前 |
② チェックリスト本体 | 項目ごとに○×と、判定の根拠（数値・成果物名）を記入する | 2週間前（仮）／1週間前（本番） |
③ 判定記録シート | 判定結果、条件、出席者、決定者、日時を残す | 判定会議の当日 |
④ 切り戻し判断シート | 戻す条件、判断する人、判断期限、所要時間 | 1週間前までに確定 |
①の判定基準表は、6つの分野に分けて作ります。
項目の数は全部で30前後が目安です。多すぎると当日に確認しきれず、少なすぎると抜けが出ます。そしていちばん省かれやすいのが⑥切り戻しです。「戻すことは考えたくない」という気持ちが働くため、手順だけ書いて所要時間を測っていないことがよくあります。測っていない手順は、当日には使えません。
■ 4. 各項目の説明
チェックリストの1行は、次の形で書きます。
列 | 記入する内容 | 書き方のコツ |
|---|---|---|
No.／分野 | 通し番号と、6分野のどれか | ― |
判定項目 | 何が満たされていれば○か | 「〜できている」ではなく、数値か成果物名で書く |
区分 | 必須／望ましい | 2か月前に決め、判定の当日には変えない |
確認者 | ○×を付ける人（個人名） | 分野ごとに1人。全員で確認しない |
判定 | ○／×／N/A | 「△」は作らない。△があると判定が曖昧になる |
根拠 | 判定の裏付け（数値、文書名、実施日） | 「確認済み」ではなく「第3回リハーサル（12/21）差異0件」 |
×の場合の対応 | 誰が・いつまでに・何をするか | 条件付きGoの「条件」になる欄 |
コツは「判定項目を、数値か成果物名で書く」ことに尽きます。
書き方 | |
|---|---|
△ 避けたい | データ移行の準備ができている |
○ 望ましい | 本番相当データでの移行リハーサルを実施し、件数・金額の差異が0件であること |
△ 避けたい | 利用者への周知ができている |
○ 望ましい | 対象者128名の研修受講率が100%であること（受講記録で確認） |
左の書き方だと、確認する人の主観で○にも×にもなります。右なら、誰が確認しても同じ答えになります。
■ 5. 判定のタイムラインと、3つの判定結果
判定会議を1週間前に置くのがポイントです。前日だと、×が見つかっても挽回できません。1週間あれば、多くの項目は○に変えられます。そのうえで前日に15分だけ、条件付きGoの条件が満たされたかを確認します。
判定結果は3つだけです。「たぶん大丈夫」は判定結果ではありません。
判定 | 条件 | その後にすること |
|---|---|---|
Go | 必須条件がすべて○ | 望ましい条件の×は、稼働後のTODOとして登録する |
条件付きGo | 必須条件のうち、前日までに確実に○にできるものだけが× | 「誰が・いつまでに・何をするか」を記録し、前日に再確認する |
No-Go | 前日までに解消できない×が必須条件にある | 延期後の日程と、その日までにやることを同じ場で決める |
■ 6. 記入例（架空企業：加美乃フーズ）
惣菜・冷凍食品メーカーの加美乃フーズ（年商185億円・従業員640名）が、3工場の生産管理システムを刷新したプロジェクトです。工場のラインは止められないため、関東（5ライン）→中部（4ライン）→九州（2ライン）の順に切り替える段階展開を選びました。
最初の拠点である関東工場（2025年1月6日稼働）の判定会議（2024年12月26日）の記録です。
分野 | 判定項目 | 区分 | 判定 | 根拠 |
|---|---|---|---|---|
機能・品質 | 受入テストが完了し、重大（A）不具合の未解決が0件 | 必須 | ○ | 受入テスト830ケース、検出15件、A級0件 |
機能・品質 | 受入テストの不具合密度が0.25件/KStep以下 | 必須 | ○ | 0.11件/KStep（15件÷138KStep） |
データ移行 | 本番相当データのリハーサルで差異0件 | 必須 | ○ | 第3回リハーサル（12/21・4時間50分）差異0件 |
データ移行 | 移行の所要時間が作業枠（8時間）に収まる | 必須 | ○ | 4時間50分。予備時間3時間10分 |
利用者の準備 | 対象者の研修受講率が100% | 必須 | ○ | 関東工場 対象86名／受講86名 |
利用者の準備 | ハンディ端末の実機練習を全ラインで実施済み | 望ましい | ○ | 5ライン×2回（12/16〜12/20） |
運用・体制 | 稼働後2週間の並行運用の体制が確定 | 必須 | ○ | 当番表確定。現地にベンダー2名が常駐 |
切り戻し | 切り戻し手順が文書化され、所要時間を測定済み | 必須 | ○ | 手順書v1.2。第3回リハーサルで2時間15分を実測 |
切り戻し | 切り戻しの判断者と判断期限が決まっている | 必須 | ○ | 生産管理部長が、稼働3営業日後の1/8 17時までに判断 |
インフラ | 現場端末の通信が全エリアで安定している | 望ましい | × | 冷凍倉庫内の2か所で電波が弱い。中継器の手配は1/20着 |
判定結果はGoでした。×が1件ありますが、区分が「望ましい」であり、かつ回避策（該当2か所は紙の伝票で記録し、事務所で入力）が用意できていたためです。中継器が届くまでの運用を決め、稼働後のTODOとして登録しました。
なおこのプロジェクトでは、9月末の時点でSPI 0.91・CPI 0.95まで落ちています。原因は、現場のハンディ端末が想定どおりに使えないことが結合テストで判明したことでした。10月に現場での実機検証を3日間行い、そこから立て直しています。この経験があったからこそ、判定項目に「実機練習を全ラインで実施」「通信が全エリアで安定」という現場寄りの項目が入りました。
3拠点の結果は次のとおりです。
拠点 | 稼働日 | ライン数 | 並行運用 | 稼働後2週の問い合わせ | 本番障害 |
|---|---|---|---|---|---|
関東工場 | 2025/1/6 | 5 | 2週間 | 214件 | 2件 |
中部工場 | 2025/2/3 | 4 | 1週間 | 96件 | 1件 |
九州工場 | 2025/2/17 | 2 | 1週間 | 41件 | 0件 |
問い合わせが214件から96件へ減ったのは、関東での質問内容を分類して手順書に反映したからです。特に多かった上位3項目を、中部の研修資料の冒頭に移しました。段階展開をするなら、判定チェックリストも拠点ごとに更新していくのが効果的です。
■ 7. 運用ルール
ルール | 内容 | 理由 |
|---|---|---|
基準は2か月前に決める | 必須と望ましいの区分を、焦っていない時期に合意する | 当日に議論すると、その場の空気で決まる |
判定会議は1週間前 | 前日ではなく、挽回できる時期に開く | 前日だと、×が見つかっても手が打てない |
「△」を作らない | 判定は○・×・N/Aの3つだけ | △があると、判定そのものが曖昧になる |
根拠を必ず書く | 数値・文書名・実施日のいずれかを記入する | 「確認済み」だけでは、後から検証できない |
確認者は分野ごとに1人 | 全員で全項目を見ない | 全員の責任は、誰の責任でもなくなる |
決定者を1人決める | 最終的にGo／No-Goを言う人を決めておく | 合議だと、誰も止められなくなる |
もうひとつ、No-Goを言いやすい空気を作っておくことも運用の一部です。判定会議の冒頭で「今日はNo-Goを出すための会議です。Goは結果であって目的ではありません」と伝えるだけでも、×が正直に出てくるようになります。
■ 8. 活用シーン
場面 | 使い方 |
|---|---|
システムの本番稼働 | そのまま使う。2か月前に基準、1週間前に判定 |
段階展開（拠点ごとの切り替え） | 拠点ごとに判定を行い、前の拠点の学びを項目に追加する |
大きな機能リリース | 分野を①機能・品質、③インフラ、⑥切り戻しの3つに絞って使う |
業務の切り替え（システム以外） | ④利用者の準備と⑤運用体制を厚くして使う |
ベンダーとの合意 | 判定基準表を契約の別紙にし、検収の条件と揃える |
稼働後の振り返り | 実際に起きた障害が、どの項目で防げたかを確認し、次に活かす |
■ 9. よくある失敗と直し方
失敗 | 起きること | 直し方 |
|---|---|---|
項目が「〜できている」の羅列 | 確認する人によって判定が変わる | 数値か成果物名で書き直す |
判定の当日に区分を議論する | 「今回は必須じゃないことにしよう」となる | 区分は2か月前に決め、当日は変更しない |
切り戻しの所要時間を測っていない | 当日、戻す判断ができなくなる | 移行リハーサルのときに、切り戻しも実測する |
判定がGo／No-Goの2択 | あと一歩の状態でも、延期か強行かになる | 「条件付きGo」を用意し、条件と期限を記録する |
項目が100件を超える | 当日に確認しきれず、形だけの確認になる | 30件前後に絞る。細目は各分野の別紙へ |
決定者が決まっていない | 全員が「自分は反対しなかった」と思って稼働する | 最終決定者を1人決め、判定記録に署名欄を置く |
■ 10. 導入効果
観点 | チェックリストが無いとき | チェックリストを使ったとき |
|---|---|---|
判定の材料 | 「たぶん大丈夫だと思います」 | 30項目の○×と、その根拠となる数値・文書名 |
×が見つかる時期 | 稼働の前日、あるいは稼働後 | 2週間前の仮判定（挽回する時間がある） |
あと一歩の状態の扱い | 延期か強行かの二択 | 条件付きGoで、条件と期限を明確にして進める |
稼働後に問題が起きたとき | 戻すかどうかを、その場で議論する | 判断者と期限が決まっており、所要時間も分かっている |
加美乃フーズの結果 | ― | 3工場すべてで予定どおり稼働。本番障害3件、製造ライン停止0件 |
この案件でいちばん重い条件は、「製造ラインの停止に至る障害0件」でした。ラインが1時間止まると、その分の生産量がそのまま失われます。「障害を減らす」ではなく「ラインを止めない」を目標に置いたからこそ、判定項目も現場寄りのものになりました。何を守りたいかを先に決めると、チェックリストの中身も決まります。
■ まとめ
稼働判定チェックリストは、稼働を止めるための道具ではありません。判断できる状態を作るための道具です。×があっても、区分と回避策が分かっていれば進めます。逆に全部○に見えても、根拠が「確認済み」だけなら、それは判断できていない状態です。
これから作るなら、まず6分野それぞれに3〜5項目を書き出し、必須と望ましいに分けるところから始めてください。作業としては半日で終わります。そして⑥切り戻しの欄を、忘れずに入れておいてください。