金曜の夜、翌朝にストアへ提出するビルドの最終確認をしていると、Antigravity の画面の隅にアップデートの通知が出ました。
公式の変更履歴を開くと、10 月 12 日にアプリ v2.23.0 が出て、翌 13 日に v2.23.1 が続いています。2.23.0 ではメッセージ欄に権限ピッカーが加わり、画像や動画の全画面ビューア、.zip やフォルダの添付にも対応しました。2.23.1 は、サインイン時のライセンス選択が長いとボタンが隠れる問題の修正です。
押したい気持ちと、押してはいけない気がする気持ちが、同時に来たのは、締切が近いせいかもしれません。
先送りしてよい日と、先送りできない日
結論から言うと、私は 納期の前日は、原則として上げません。ただし、それは「新しい版が怖い」からではありません。
道具の更新そのものより、更新で生まれる「確かめ直す作業」が納期前には贅沢だからです。以前、リリース前夜に開発環境を更新して、署名まわりの設定を直すのに半日を使ったことがあります。更新自体は悪くありませんでした。ただ、その半日は、本来なら最終確認に使うはずの時間でした。
一方で、先送りできない日もあります。サインインできずに作業が始められない、いま使っている版に既知の不具合があって手が止まっている、といった場合です。このときは、上げないことのほうが納期を危うくします。
先送りか更新かは、気分ではなく問いで決めるようにしています。そのほうが、疲れている夜でも判断がぶれないのです。
決めるための三つの問い
私が通知を見たときに自分へ投げているのは、次の三つです。
| 問い | 確かめること | 先送りに傾く答え |
|---|---|---|
| 1. 明日の作業に触れるか | 変更履歴の見出しを読み、自分がいま使っている機能の名前があるか | 使っている機能が変更対象に入っている |
| 2. 戻せるか | 更新前の状態に自分の手で戻れる手段があるか | 戻し方が分からない／戻すのに時間がかかる |
| 3. 上げなかったら何を失うか | 現行版で止まっている作業が実際にあるか | 失うものがない（今夜は困らない） |
三つとも「先送りに傾く」なら見送ります。逆に、1 が「触れない」で、2 が「戻せる」なら、納期前でも上げる余地があります。
今回の例に当てはめてみます。2.23.0 の権限ピッカーと添付の対応は、私の明日の作業（提出前の最終確認）には直接かかわりません。2.23.1 のサインインの修正も、すでにサインインできている状態では恩恵がありません。1 は「触れない」、3 は「失うものがない」でした。
ここで 2 の「戻せるか」が決め手になります。
「戻せるか」は、更新前に確かめておく
通知が出てから戻し方を調べるのでは遅いので、私は更新の候補にしている版のあいだに、次の三点だけ見ています。
- 現行版のインストーラや配布元に、自分でたどり着けるかを確かめます。
- 設定やルールのファイルが、アプリの外にも控えとして残っているかを見ます。
- 作業中のリポジトリが、いつでも元に戻せる状態かを確認します。
設定ファイルの置き場所は、OS や版によって違います。私は自分の環境で一度だけ場所を確かめて、そこを控えの対象にしています。皆さまも、一度ご自分の環境で確認しておいていただければと思います。
三つ目のリポジトリは、コマンド数行で整えられます。
# 何を解決するか: 更新で作業ツリーが乱れても、直前の状態へ戻れるようにする
git status --short # 未コミットの変更がないか見る
git switch -c wip/before-editor-update # 退避用のブランチを切る
git add -A
git commit -m "WIP: before editor update"
git push origin wip/before-editor-update退避ブランチを切る理由は、更新後に「いつもと違う挙動」が出たとき、それが更新のせいか自分の変更のせいかを分けて考えられるからです。切り分けの材料が一つあるだけで、夜の焦りはずいぶん減ります。
上げると決めたときの、五分の手順
三つの問いを通って「上げる」になったときは、次の順で進めます。
- 退避ブランチを切って push します（上のコマンド）。
- 設定とルールのファイルを、別の場所へ複製します。
- 更新して、サインインとプロジェクトの読み込みだけ確かめます。
- 普段いちばん使う操作を一つ実行して、いつもの挙動かどうか見ます。
ここまでを五分で終え、4 で違和感があれば、その場で手を止めます。原因を探り始めないのがコツです。納期前に原因究明を始めると、そこで夜が終わってしまうのです。
見送った夜に、実際にしたこと
更新を見送ったからといって、通知を放っておいたわけではありません。変更履歴の見出しを三行だけ読み、気になった点を手元のメモに一行ずつ書き留めました。
たとえば権限ピッカーは、エージェントに任せる範囲を画面上で絞れるようになる変更のようです。ただ、私の運用ではこれまで設定ファイル側で範囲を決めていたので、画面側の仕組みと食い違わないかは、更新した日に確かめたい点でした。こうしてメモを残しておくと、翌日の自分が「何を見ればいいか」で迷わずに済みます。
もう一つ、見送った夜に決めたのは「いつ上げるか」です。通知を無視するのと、日を決めて見送るのとでは、似ているようで気持ちの重さがまるで違いました。日を決めておけば、先送りは放置ではなく予定の一つになります。そのときの私は、少し肩の荷が下りたように感じていました。
私の線引き
今回は、問いに沿って更新を見送りました。提出を終えた翌日、土曜の昼に、退避ブランチを切ってから更新しています。サインインのボタンが隠れる不具合は、私の環境では出ませんでした。
出ない環境もあれば、出る環境もあるのでしょう。だから変更履歴の一行は、自分の事情に翻訳して初めて意味を持つのだと、このとき気づきました。
更新の価値は、版の新しさではなく、戻れる状態で受け取れるかどうかで決まります。 この線引きだけは、疲れた夜でも守るようにしています。
次に通知が出たら、まず変更履歴の見出しを三行だけ読んで、表の「1. 明日の作業に触れるか」に答えるところから始めてみていただければ幸いです。