「テストGreen」でもGoにしなかった理由

1. リード

テストが Green だと、安心する。私もそうだった。だが RC 検証週では、Green の数が増えるほど、逆に別の問いが強くなった。その Green は、明日の朝 06:30 の運用まで保証してくれるのか。この問いに「はい」と言い切れなかったから、Go は急がなかった。

Day 7 の時点で 171 Green が確認されていた。さらに 2026-07-24 の Current Context では 178 Green になっている。それでも状態は No-Go 継続で、Issue #11 / #12 の運用フォローアップが残っている。今回は、その「通っているのに進まない」判断の話だ。

2. 背景

Vol.11 では Day 7 の一時 No-Go を書いた。あの記事で中心に置いたのは、171 Green でも正式版の十分条件ではない、という線だった。今回の Vol.16 は、その線をもう少し広げている。

Current Context には、今の状態がはっきり書かれている。Version 1.0 は No-Go 継続。現在の論点は Issue #11 / #12 の運用フォローアップ。直近の最小修正として --wait-for-user-active が追加されたが、DarkWake 中の起動問題は無人実機確認が未完了だ。つまり、テストは伸びているが、朝の条件確認はまだ終わっていない。

3. 今回のテーマ

テーマは、テスト Green は「壊れていない」の強い証拠だが、「正式版として説明できる」の十分条件ではなかったということだ。

この違いは、非エンジニアの私にはかなり大きかった。テストが多いほど、もう前に進んでよい気がする。だが RC 検証週では、コードの正しさだけでなく、時間どおりに動くこと、無人で続くこと、止まる理由が説明できることまで見ていた。

4. 実際の出来事

Day 7 の記録では、171 Green という事実があった。それは大きい。広く壊れていないこと、過去に決めた約束がかなり守られていることを示してくれる。さらに 2026-07-24 の Current Context では、テストは 178 Green に増えている。ここだけ見れば、前進は明らかだ。

だが同じ Current Context には、Go を止める理由も同じ強さで書かれている。Issue #11 / #12 の運用フォローアップが残っている。DarkWake 中の launchd 起動は検証中で、修正は入ったが無人実機確認は未完了。今やってはいけないこととして、新機能追加、認証方式変更、v1.0.0 tag、Issue 自動クローズも明示されている。

ここで見えてくるのは、テストと運用判断の役割の違いだ。テストは「この変更で既知の約束を壊していないか」を強く見てくれる。一方で Go / No-Go は、「正式版として世の中に説明できるか」を見る。説明には、無人運用の確認、残 Issue の扱い、Version を上げる理由まで含まれる。

RC 検証週で特に重要だったのは、Go を感情で決めなかったことだと思う。171 Green から 178 Green へ増えても、未確認項目があるなら止まる。改善が入っていても、実機の朝でまだ裏が取れていないなら止まる。この順番を守れたから、Green の数字を飾りにしないで済んだ。

ここで支えになったのは、止める理由が曖昧な不安ではなく、文書として並んでいたことだった。Issue #11 / #12 の運用フォローアップ、DarkWake 中の起動問題、--wait-for-user-active を足したあとの無人実機確認未了。どれも「たぶん気になる」ではなく、確認待ちの論点として置かれていた。だから Green の数が増えても、どこを見て止まっているのかを言葉で説明できた。

この整理は、数字を軽く扱うためではない。むしろ Green を正しく重く扱うための線だったと思う。171 や 178 という数字は、かなり多くの約束が守られていることを示してくれる。だからこそ、その数字に含まれない論点を別で持っておかないと、安心材料がそのまま判断のショートカットになってしまう。RC 検証週で守りたかったのは、Green を強い事実として使いながら、Green だけで Go を決めないことだった。

もう一つ大きかったのは、最小修正が入ったあとも「だからもう大丈夫」とは言わなかったことだ。--wait-for-user-active が追加されたのは前進だ。だが前進したことと、朝の運用条件が十分だと裏取りできたことは別だ。この切り分けがないと、修正の存在そのものが完成証明のように見えてしまう。完成を急がないためには、修正と検証を別に扱う必要があった。

5. 考えたこと

テストが Green なのに止まるのは、最初は少し気まずい。前に進んでいないように見えるからだ。だが今は、そこで止まれたことが品質だったと思っている。止まれないプロジェクトは、Green を免罪符にしてしまう。免罪符になった瞬間、数字は説明責任から切り離される。

非エンジニアの立場で言うと、テストは「もう安心していい」という鐘ではなく、「ここから先は別の確認へ進める」という合図に近い。コードの土台が崩れていないからこそ、次に朝の運用を見られる。逆に言うと、朝の運用確認を飛ばす理由にはならない。

Human Approval の思想とも似ている。承認が要る操作では、実行できることと、実行してよいことを分けていた。Go / No-Go も同じで、Green であることと、正式版にしてよいことは分けて考える必要がある。その分離があるから、Version は単なる記念日にならない。

私は最初、Green の数が増えるほど「もう止まる理由を探しているだけではないか」と少し疑っていた。だが今は逆で、止まる理由を言語化できるからこそ Green が意味を持つのだと思っている。もし残論点を曖昧にしたまま Go を出していたら、171 や 178 という数字はあとで都合よく使われるだけだったかもしれない。数字を守るには、数字の外にある条件も守らないといけない。

毎朝の運用を前提にすると、この差はさらに大きい。テストは同じ条件で何度も確かめられる。一方で朝 06:30 の無人実行は、時間、睡眠状態、ネットワーク、認証、外部サービス遅延が絡む。その違いを無視して「テストが通ったから十分」と言う方が、むしろ雑だった。RC 検証週の Go / No-Go は、コード品質を疑うためではなく、運用品質を別枠で見切らないための判断だった。

だからこの時期の学びは、「Green を増やすこと」より「Green の意味を取り違えないこと」にあった。数字を積み上げる努力は必要だが、それを正式版の宣言へどうつなぐかは別の責任になる。非エンジニアでもここを言い分けられるようになると、安心材料に流されずにプロジェクトを守りやすくなる。その線を引けたこと自体が、RC 検証週の大きな収穫だった。

6. 学び

• テスト Green は強い安心材料だが、正式版の十分条件ではない
• Day 7 の 171 Green と、2026-07-24 時点の 178 Green は前進の証拠だが、未確認項目を消してはくれない
• Go / No-Go はコード品質だけでなく運用品質と説明責任も含めて決める
• 残 Issue や無人確認未了を抱えたまま Version を上げない方が、あとで強い
• Green の数字を免罪符にしないことが、RC 検証週の価値になる

7. 次回メモ

この続きで書くなら、無人実行でネットワーク障害にどう向き合ったか、という話につながる。朝の運用では、成功率より先に切り分け方が重要になるからだ。