毎日デプロイの記録を数字に変える――作業時間・確認漏れ・やり直しから操作盤を軽くする
毎日デプロイの操作盤を作ると、作業開始から公開後確認までの順路が揃います。
ところが、使い始めると別の問題が見えてきます。
- チェック項目が増えすぎて、読むだけで時間がかかる
- 毎回同じ場所でAIとのやり取りをやり直す
- プレビュー確認はしたが、スマートフォン表示だけ漏れる
- デプロイ成功後、本番URLを開くまでに中断が入る
- 45分で終える予定が、毎回90分を超える
- 日次記録は残るが、翌週に何を直せばよいか分からない
この状態で「もっと丁寧に確認しよう」とすると、操作盤はさらに重くなります。
必要なのは、すべての作業を細かく監視することではありません。すでに残している日次記録から、次の3つだけを見えるようにします。
- どの段階に時間がかかったか
- どの確認が漏れたか
- どこでやり直しが起きたか
この3つが分かると、不要なチェックを減らし、よく詰まる場所だけを改善できます。
この記事では、非エンジニアでも表計算ソフトや専用ダッシュボードを作らず、Markdownの記録から毎週30分で操作盤を軽くする方法を説明します。
測定の目的は人を評価することではない
最初に、何のために数字を見るかを決めます。
作業時間が長い人を責めるためではありません。チェック漏れを失敗点として数えるためでもありません。
見る目的は、次の問いへ答えることです。
どこで情報を探しているか
どこで判断材料が足りないか
どの確認が毎回必要か
どの確認は条件付きでよいか
どの段階を小さく分けるべきか
たとえば、GitHubの差分確認に20分かかった日が続いたとします。
原因は「確認が遅い人」ではなく、AIの変更範囲が広すぎる、プルリクエストが大きすぎる、目的外の整理が混ざる、といった作業設計かもしれません。
数字は人ではなく、作業の詰まりを見つける手がかりとして使います。
最初に記録するのは7項目だけ
詳しい操作ログをすべて保存すると、記録すること自体が負担になります。
1日1件、次の7項目に揃えます。
## 2026-11-08
- 目的：空欄時の案内を分かりやすくする
- 合計時間：52分
- 最長の段階：プレビュー確認 14分
- 確認したこと：正常入力、空欄、390px幅、本番URL
- 確認漏れ：タブレット幅
- やり直し：1回。AIの変更範囲が広く、依頼を分割
- 結果：公開完了
- 次回の改善：依頼時に変更ファイルを2つまでと指定する
「最長の段階」を1つだけ書くのがポイントです。
全工程を秒単位で記録する必要はありません。まず、最も時間を使った場所がどこか分かれば十分です。
作業を6段階に分ける
時間を比較するには、毎日同じ区切りを使います。
1. 開始準備
2. AIへの依頼と修正
3. GitHubの差分確認
4. プレビュー確認
5. 本番反映とデプロイ確認
6. 公開URL確認と記録
1. 開始準備
今日の目的、変更範囲、停止条件、最後の正常地点を決める時間です。
2. AIへの依頼と修正
AIへ指示し、結果を受け取り、範囲外変更や不足を修正する時間です。
3. GitHubの差分確認
変更ファイル、削除、設定変更、テスト結果を確認する時間です。
4. プレビュー確認
正常操作、失敗しやすい操作、スマートフォン表示などを確認する時間です。
5. 本番反映とデプロイ確認
人間の承認後、本番反映を行い、デプロイの完了を確認する時間です。
6. 公開URL確認と記録
利用者と同じ入口で本番を操作し、結果と未確認事項を残す時間です。
段階名は、自分の操作盤に合わせて変えて構いません。ただし、週の途中で頻繁に名前や境界を変えると比較できなくなります。1週間は同じ区切りを使います。
時間は「長い・普通・短い」の3段階でもよい
開始と終了を毎回計るのが負担なら、最初は3段階で記録します。
| 判定 | 目安 | 意味 |
|---|---|---|
| 短い | 5分未満 | 迷わず進めた |
| 普通 | 5〜15分 | 想定内 |
| 長い | 15分超 | 改善候補として確認 |
例：
開始準備：短い
AI依頼：長い
差分確認：普通
プレビュー：普通
本番反映：短い
公開後確認：短い
この記録を5日分並べると、AI依頼だけ「長い」が続いている、と分かります。
数字を細かくするのは、改善候補が見つかってからです。
確認漏れは「未実施」と「不要」を分ける
チェックが空欄でも、すべてが確認漏れではありません。
実施：確認した
未実施：必要だったが確認しなかった
対象外：今回の変更には必要なかった
保留：今は確認できず、条件を決めて後で行う
たとえば、文章だけを変更した日にデータベースの書き込み確認をしなかった場合、それは対象外かもしれません。
一方、スマートフォン用ボタンの配置を変えたのに、スマートフォン幅を見なかったなら未実施です。
この区別がないと、操作盤はすべての変更で全項目を確認する重い手順になります。
日次記録では次のように書きます。
## 確認結果
- 正常入力：実施
- 空欄：実施
- 390px幅：未実施
- データ保存：対象外
- 実利用者1人の操作：保留。翌日午前に確認
未実施が続く項目は、注意力ではなく配置を見直します。
- 確認項目が使う画面から離れていないか
- 名前が曖昧ではないか
- いつ確認するか決まっているか
- 合格条件が分かるか
- 対象外にできる条件がないか
やり直しは回数と戻った段階を記録する
やり直しとは、同じ操作を単に2回行ったことではありません。
一度進んだ段階から、前の段階へ戻ったことを指します。
プレビューで表示崩れを発見
→ AIへの依頼へ戻る
差分確認で範囲外変更を発見
→ 依頼を分割して再作成
本番確認で問題を発見
→ 復旧手順へ切り替える
記録するのは次の3つです。
回数：何回戻ったか
戻り先：どの段階へ戻ったか
理由：何が不足していたか
例：
- やり直し：2回
- 差分確認 → AI依頼：目的外のファイル整理が混ざった
- プレビュー → AI依頼：空欄時の表示がスマートフォンで重なった
やり直しが多いこと自体を悪いと決めません。
プレビューで問題を見つけて本番前に戻れたなら、安全機能が働いた結果です。見るべきなのは、同じ理由が繰り返されているかです。
1週間を1枚にまとめる
週末に、5日分を次の表へまとめます。
| 日 | 合計 | 最長の段階 | 未実施 | やり直し | 結果 |
|---|---|---|---|---|---|
| 月 | 52分 | プレビュー | 1 | 1 | 完了 |
| 火 | 38分 | AI依頼 | 0 | 0 | 完了 |
| 水 | 91分 | 差分確認 | 2 | 2 | 保留 |
| 木 | 46分 | AI依頼 | 0 | 1 | 完了 |
| 金 | 43分 | 公開後確認 | 1 | 0 | 完了 |
ここから、次を数えます。
最長になった回数が多い段階
未実施が2回以上あった確認
同じ戻り先へ戻った回数
90分を超えた日
公開できなかった日
上の例なら、水曜日だけを「失敗」と見るのではなく、AI依頼と差分確認に改善余地があると考えます。
3つの数字で操作盤を診断する
1. 中央の作業時間
平均ではなく、5日分を短い順に並べた真ん中の値を見ます。
38分、43分、46分、52分、91分
中央：46分
平均は、91分の1日に引っ張られます。まず普段の作業がどのくらいかを見るなら、中央の値が分かりやすいです。
2. 確認漏れ率
必要だった確認のうち、未実施だった数を見ます。
必要な確認：25件
未実施：3件
確認漏れ率：3 ÷ 25 = 12％
対象外は分母へ入れません。保留は、期限までに確認できたかを別に見ます。
3. やり直し率
作業日数に対して、何回前段階へ戻ったかを見ます。
作業日：5日
やり直し：4回
1日あたり：0.8回
回数だけで良し悪しを決めず、理由を組み合わせます。
同じ理由で3回戻っているなら、操作盤かAIへの指示を変える候補です。
数字から改善先を決める
見える化の目的は、グラフを作ることではありません。翌週に1つ変えることです。
AI依頼が毎回長い
考えられる原因：
- 目的が1文で書けていない
- 変更範囲が広い
- 完了条件が曖昧
- AIが毎回プロジェクト構成を探している
改善例：
START_HEREに対象ファイルを記載する
変更は1つの価値に絞る
許可ファイルと変更禁止領域を先に渡す
差分確認でやり直しが多い
考えられる原因：
- AIへ「ついでの整理をしない」と伝えていない
- プルリクエストが大きい
- 設定変更と表示変更が混ざっている
改善例：
目的外の整理は別提案にする
変更ファイル数の上限を決める
表示と設定を別の作業へ分ける
スマートフォン確認が漏れる
考えられる原因：
-
DAILY_CHECK.mdが別タブにある - 確認する画面幅が決まっていない
- プレビュー確認の完了条件に含まれていない
改善例：
プレビューURLの直後にチェック表を開く
390px幅で3画面を見る
未確認なら本番反映へ進まない
公開後確認に時間がかかる
考えられる原因：
- 本番URLを毎回探す
- 確認する3操作が決まっていない
- 公開直後に別作業を始める
改善例：
本番URLをSTART_HEREへ置く
トップ・変更箇所・主要操作の3つに絞る
公開後確認が終わるまで新しい作業を始めない
操作盤から削除してよいもの
毎週項目を追加すると、操作盤は必ず重くなります。
削除候補は、次の順で探します。
同じ内容の重複
START_HERE.mdとDAILY_CHECK.mdに同じ説明があるなら、入口にはリンクだけを残します。
すでに存在しない対象
閉じたプルリクエスト、削除したブランチ、使わないURLを外します。
条件付きでよい確認
環境変数を変更した日だけ必要な確認を、毎日の共通項目から分けます。
行動につながらない記録
毎日書いているが、4週間一度も判断に使わなかった項目は、目的を確認します。
ただし、秘密情報、データ消失、本番停止、Human Approval、復旧に関する境界は、使わなかっただけで削除しません。
操作盤を「共通」と「条件付き」に分ける
チェックを軽くする最も分かりやすい方法は、毎回行うものと、変更内容に応じて行うものを分けることです。
毎回行う共通チェック
[ ] 今日届ける価値が1文である
[ ] 変更範囲と触らない場所がある
[ ] 実際の差分を確認した
[ ] 戻るコミットが分かる
[ ] 人間が本番反映を承認した
[ ] 公開URLで主要操作を確認した
表示変更時だけ
[ ] スマートフォン幅
[ ] 長い文字列
[ ] 文字の重なり
[ ] ボタンの押しやすさ
データ変更時だけ
[ ] 正常な保存
[ ] 空欄・重複・上限
[ ] 既存データへの影響
[ ] 復旧方法
設定変更時だけ
[ ] 変更前の値を記録
[ ] 本番とプレビューを区別
[ ] 値を画面・ログ・AIへ貼っていない
[ ] 反映後の動作
毎日の共通チェックが短くなり、必要な安全確認は変更別のカードに残ります。
AIに集計を任せる方法
5日分の日次記録をAIへ渡し、集計を手伝ってもらえます。
以下は今週5日分の毎日デプロイ記録です。
1. 各日の合計時間、最長の段階、未実施数、やり直し回数、結果を表にしてください。
2. 同じ段階が最長になった回数を数えてください。
3. 同じ理由の確認漏れとやり直しをまとめてください。
4. 操作盤から削除・条件付き化できる候補を最大3件示してください。
5. 記録にない原因は推測せず、「判断に必要な情報」として分けてください。
6. ファイルや外部サービスは変更せず、提案だけを返してください。
AIは、表の作成、回数の集計、似た理由の分類が得意です。
一方、どのリスクを残すか、どの確認を削るか、本番反映を止めるかは人間が決めます。
集計結果に「この確認は不要」と書かれても、自動で手順から削除しません。
改善は1週間に1つだけ反映する
数字を見ると、直したい場所が多く見つかります。
しかし、同時に5つ変更すると、翌週どの改善が効いたか分かりません。
次の順で1つ選びます。
1. 秘密情報・データ消失・公開停止につながる問題
2. 本番で利用者が操作できなくなる問題
3. 同じ理由で2回以上やり直した場所
4. 3日以上「長い」が続いた段階
5. 毎回5分以上の探し物
改善記録：
## 来週の変更
- 対象：AIへの依頼
- 根拠：5日中3日で最長、範囲外変更によるやり直し2回
- 変更：許可ファイルと変更禁止領域を依頼文の先頭へ移す
- 変えないもの：Human Approval、差分確認、公開後確認
- 来週見る数字：AI依頼が最長になった日数、範囲外変更の回数
「変えないもの」も書くと、効率化のために安全境界まで外すことを防げます。
改善前後を比べる
翌週も同じ3つを見ます。
中央の作業時間
確認漏れ率
やり直し率と理由
例：
| 指標 | 改善前 | 改善後 | 判定 |
|---|---|---|---|
| 中央の時間 | 52分 | 44分 | 短縮 |
| 確認漏れ率 | 12％ | 4％ | 改善 |
| 範囲外変更のやり直し | 2回 | 0回 | 改善 |
時間だけ短くなり、確認漏れが増えた場合は成功ではありません。
反対に、時間が少し増えても、本番後のやり直しがなくなったなら価値があります。
平均点を出さず、3つを別々に判断します。
数字を増やしすぎない
毎日デプロイの改善で、次のような項目まで集め始めると記録が続きません。
- AIとのメッセージ数
- クリック数
- 開いたタブ数
- 変更行数
- すべての待ち時間
- すべてのテスト件数
- 細かな感情スコア
これらが必要な調査もありますが、最初から常時記録しません。
新しい数字を追加する条件は次のとおりです。
判断に使う問いがある
1分以内に記録できる
翌週に行動を変えられる
2週間後に不要なら外せる
問いがない数字は、見栄えのよいダッシュボードを作るだけになりがちです。
最初の2週間の進め方
1週目：測るだけ
操作盤を変えず、時間、未実施、やり直し、結果を記録します。
途中で気づいても、重大な安全問題でなければ、まず5日分の傾向を見ます。
1週目の週末：1つ選ぶ
同じ詰まりが繰り返された場所から、翌週に変えるものを1つ選びます。
2週目：1つだけ変える
チェックの位置、AI指示の先頭、条件付きカードへの分離など、1つだけ反映します。
2週目の週末：同じ数字で比べる
時間、確認漏れ、やり直しがどう変わったか確認します。
改善しなければ、人の努力ではなく、原因や置き場所を見直します。
週次レビューの完成形
# 毎日デプロイ操作盤レビュー
## 今週の結果
- 作業日：5日
- 公開完了：4日
- 保留：1日
- 中央の作業時間：46分
## 詰まり
- 最長が多い段階：AI依頼 2日
- 確認漏れ：スマートフォン幅 2回
- やり直し：4回
- 同じ理由：範囲外変更 2回
## 来週変えること
- AI依頼の先頭へ許可ファイルと変更禁止領域を移す
## 変えないこと
- GitHubでの差分確認
- Human Approval
- 公開URLでの確認
- 復旧カード
## 来週見る数字
- AI依頼が最長になった日数
- 範囲外変更の回数
- 確認漏れ率
これで、週次レビューが感想ではなく、次の操作盤を変える判断材料になります。
よくある失敗
時間だけを短くする
確認を飛ばせば時間は短くなります。確認漏れとやり直しを一緒に見ます。
すべてを細かく計測する
記録に時間がかかり、毎日のデプロイが重くなります。最長の段階だけから始めます。
対象外を漏れとして数える
変更と関係ない確認まで未実施にすると、チェックを減らせません。実施、未実施、対象外、保留を分けます。
本番前のやり直しをすべて失敗扱いする
プレビューで問題を発見して戻れたことは、安全な運用の結果です。同じ原因が繰り返されているかを見ます。
AIの提案をそのまま削除へ反映する
集計と提案はAIへ任せられますが、安全境界を削る判断は人間が行います。
改善を一度に増やす
どの変更が効いたか分からなくなります。1週間に1つだけ反映します。
まとめ
毎日デプロイの操作盤は、項目を増やすほど安全になるわけではありません。
実際の日次記録から、時間がかかる場所、確認が漏れる場所、前段階へ戻る場所を見つけ、必要な部分だけを変えることで軽くできます。
今回の要点は次のとおりです。
- 日次記録は目的、時間、最長段階、確認、漏れ、やり直し、結果へ揃える
- 作業を6段階に分け、最も時間がかかった場所だけ記録する
- 空欄を未実施、対象外、保留へ分ける
- やり直しは回数、戻り先、理由を記録する
- 週次では中央の時間、確認漏れ率、やり直し率を見る
- 操作盤を共通チェックと条件付きチェックへ分ける
- AIには集計を任せ、削除と停止の判断は人間が持つ
- 改善は1週間に1つだけ反映し、同じ数字で比べる
最初の一歩は、今日の作業が終わったときに「合計時間」「最も時間がかかった段階」「やり直した回数」の3つだけ書くことです。
次回は、操作盤の改善を続けても減らない作業を見つけたとき、その作業を自動化するか、人が続けるか、やめるかを判断する基準を整理します。