1. リード
7日も使ったのに、まだ Go と言えない。以前の私なら、そこでがっかりしたと思う。だが RC 検証週の Day 7 で 一時 No-Go を選んだことは、失敗というより、運営 OS としての誠実さだった。テストが通っていても、毎朝の無人運用に不確定要素が残るなら、正式 v1.0.0 とは呼ばない。その線を引けたこと自体が、この週の成果だった。
Go / No-Go は、派手なイベントではない。むしろ静かな判断だ。新機能を足さない。使って、確かめて、まだ足りないなら止まる。止まる勇気がなければ、Version の数字は飾りになる。
2. 背景
Kagoshimaniax OS は v1.0.0-rc1 を置いたあと、2026-07-11 からの 7 日間を運用検証週に使った。コード追加禁止。毎日同じように開き、Dashboard を見て、Connector の実行状況を確かめ、違和感を記録する。Vol.10 で書いた「ここで終わらない」は、その入口の話だった。
この時点で正式 v1.0.0 は未リリースだった。Version は 1.0 RC のまま。やることは単純で、現実の朝に耐えるかを見るだけだ。だが「耐える」の判定は、テストの件数だけでは決まらない。手動でなら動くものが、無人で毎朝動くとは限らないからだ。
Vol.10 では Vol.11 の予告を置かなかった。それでもこの判断を残すのは、Season 1 の補遺としてではなく、RC 検証週で実際に引いた境界線そのものに価値があるからだ。正式版へ進まなかった理由が言語化されていないと、後から見る人が同じ迷いを繰り返す。
3. 今回のテーマ
テーマは、171 Green でも Day 7 で一時 No-Go を選んだ理由だ。
テストが Green であることは重要だ。最新コミット時点で 171 Green という事実は、壊れている箇所が広く露出していないことを示してくれる。だがそれは、正式リリースの十分条件ではない。RC 検証週で見ていたのは、毎朝 06:30 の日次実行が本当に続くか、Human Approval を挟む境界が実運用でも保てるか、運用者の朝の確認を本当に短くできるかだった。
4. 実際の出来事
Day 7 の時点で、完全に止まっていたわけではない。むしろ改善は進んでいた。ネットワーク再試行が加わった。Metricool の非対話 OAuth 更新も追加された。Mac の idle sleep 対策も入った。どれも「使ってみたから見えた摩擦」に対する修正だった。
ここだけ切り取ると、Go に見えるかもしれない。実際、表面的には前進している。だが運用検証週で大事なのは、追加した対策が、無人の朝に最後まで通るかだ。Current Context にあるとおり、Day 7 の段階では LaunchAgent の再インストールと無人実行の再検証が未完了だった。Issue #11 / #12 も、無人再検証待ちだった。
つまり「改善は入ったが、改善が毎朝の実運用として十分に確認できたとはまだ言えない」という状態だった。ここで Go を出すと、Version の説明が崩れる。崩れると、次に不具合が出たとき「なぜ正式版にしたのか」を説明できなくなる。
一時 No-Go は、悲観ではなく保留だ。Current Context では、再評価条件を満たして Go となった場合のみ正式 v1.0.0 へ進むと整理されている。正式リリースを諦めたのではない。まだ確証が足りないので、RC の責任範囲にとどめただけだ。
この判断は、Human Approval の思想ともつながる。本番の書き込み操作だけに承認が要るのではない。Version を上げる判断にも、同じ種類の責任がある。動いてほしいという期待と、動いたと説明できる事実は別物だ。別物として扱えないと、承認は儀式になる。
もう一つ重要だったのは、No-Go の理由が曖昧ではなかったことだ。「なんとなく不安」ではなく、Issue #11 / #12 の無人再検証待ち、LaunchAgent 再インストール後の確認未完了、無人運用としての裏取り不足という、止まる理由が言語化されていた。言語化されていると、次にやるべき確認も明確になる。
止まる理由が明確だと、No-Go は後ろ向きの判定ではなくなる。何が済んでいて、何が済んでいないかが見えているからだ。見えていれば、次の朝に確認すべき項目も、正式版に進むための再評価条件も共有できる。共有できる判断は、個人の気分ではなく運用のルールに近づく。
5. 考えたこと
一時 No-Go を選ぶと、前に進んでいないように見える。だが本当は逆だと思っている。前に進んでいないプロジェクトは、止まれない。止まれないから、曖昧なまま正式版にしてしまう。曖昧な正式版は、朝の不安を減らさない。
非エンジニアが AI と一緒にプロダクトを作るとき、進捗は実装量で測られがちだ。だが運営 OS では、進捗のかなりの部分が「出さない判断」にある。今は RC まで。今は正式版ではない。今はまだ検証中。その線を文書で残し、実際の判断にも反映することが、運営の品質になる。
Day 7 の一時 No-Go は、きれいな成功談ではない。むしろ「171 Green でも足りなかった」という、少し気まずい記録だ。だが気まずい記録ほど価値がある。気まずさを書かないと、あとから見る人は「テストが通ったのになぜ正式版にしなかったのか」を再学習することになる。再学習のコストは高い。
私は Go / No-Go を、完成か失敗かの二択ではなく、説明責任のスイッチだと考えるようになった。説明できるなら Go。まだ説明し切れないなら No-Go。感情より先に、その順番を守る。守れたことが RC 検証週の学びだった。
もう一つ大きかったのは、No-Go を出してもプロジェクトが壊れなかったことだと思う。もし No-Go が「失敗宣言」と同義なら、誰も正直に止まれない。だが RC という枠があったことで、止まること自体が想定内の運用になっていた。想定内の停止は、後退ではなく品質の一部だ。
非エンジニアの立場では、ここにかなり救われた。技術の細部を全部説明できなくても、「まだ正式版と呼ぶには確認が足りない」とは言える。言えるためには、日々のログ、Issue、Current Context のような補助線がいる。補助線があるから、判断を感覚だけで抱え込まずに済む。
6. 学び
- 171 Green は重要だが、正式リリースの十分条件ではない
- 改善を入れたことと、無人運用で確認し切れたことは別物
- Day 7 の一時 No-Go は失敗ではなく、説明責任を守る判断
- Issue と未完了項目が言語化されていると、止まる判断が強くなる
- RC は「正式版の一歩手前」ではなく、現実の運用で確かめる期間
- 非エンジニアの品質判断は、実装量より境界線の引き方に出る
- 止まる理由を共有できると、次の再評価も速くなる
7. 次回メモ
次に続けるなら、Step49.1 の事実パケットである「動くConnectorと、毎日動く仕組みは別だった」を候補にできる。ただし正式 v1.0.0 未リリースのため、どの記事でも完成形としては書かない。
シリーズ情報
| 項目 | 内容 |
|---|---|
| Season | 1 |
| Vol | 11 |
| 現在の開発 Version | 1.0.0-rc1 |
| GitHub | https://github.com/boraemon2000/kagoshimaniax-os/tree/main/docs/qiita |
次回メモ
Vol.12 候補「動くConnectorと、毎日動く仕組みは別だった」
Step49.1 の Daily Connector Automation を、あくまで当時確認できた事実だけで続ける。