1. リード
「そろそろ 1.0 では？」という言葉は、プロジェクトのあちこちで聞こえる。聞こえるたびに、私は一度だけ深呼吸した。1.0 は、気合いの数字ではない。説明できる完成の宣言だ。説明できないまま上げた Version は、ただの祝杯になる。祝杯のあと、朝の確認は変わらない。
Kagoshimaniax OS は、Step48 で Version 1.0.0-rc1 を置いた。Release Candidate。正式版 1.0.0 そのものではない。だが、ここまでの道のりを、一つの区切りとして名乗れる地点だ。名乗れるとは、足したい気持ちを一度止められることでもある。
2. 背景
Vol.01 から振り返ると、起点は単純だった。朝の確認がつらい。バラバラの画面を行き来し、昨日と比べられず、改善の優先順位が付けられない。MCP、SQLite、Connector Platform、Dashboard、Human Approval——手段は増えた。増えた手段が、目的に収束したかを問う段階に来ていた。
Version 1.0 の Must は、仕様書に書いてあった。サイト分析と保守の一元化。Human Approval 付きの安全な改善操作。10 接続、日次 4 系統、Dashboard 8 画面——数字は、地図の目盛りだ。目盛りが揃っても、中身が空なら意味がない。中身を確認する週が、RC の前に要った。
3. 今回のテーマ
テーマは、Step48 で 1.0.0-rc1 を凍結し、Must を確認した道のりだ。
新機能を足さない。既にあるものが、約束どおり動くかを見る。テストを走らせ、Known Limitations を隠さず書く。Dogfood Before Deploy——自分で先に使い、本番の前に違和感を拾う。RC は、ゴールではなく、検証の開始地点だ。
4. 実際の出来事
Step47 で Version 1 のマイルストーンを整理した。何が Must で、何が 1.1 以降か。AI 分析の本体は 1.1 へ送る。SEOPress や Imagify の書き込みは、ロールバック方針が固まるまで待つ。待つ判断は、遅れではない。含めない勇気だ。
Step48 は、追加ではなく確認の Step だった。Connector 10 件——WordPress、SEOPress、WP Rocket、Imagify、GA4、Search Console、Clarity、Metricool、GitHub、Obsidian——を Must の観点で点検した。SQLite には必須テーブルと行がある。system_connector_runs に実行履歴が残っている。Dashboard には 8 画面が登録されている。
Human Approval は、単体テストで「承認なしでは実行できない」ことを確認した。Obsidian の create-note、WP Rocket の retest-page-insights——Green でも承認を挟む設計が、テストで固定されている。固定は、安心の形式だ。
テストは 141 件 OK。数字は、全部を証明しない。だが、壊れている箇所を早く赤くする。赤くできると、RC を出す勇気が増える。
Release Notes docs/releases/v1.0.0-rc1.md を書いた。含むもの、含まないもの、Known Limitations——隠さないことが、RC の誠実さだ。Sidebar には 1.0.0-rc1 と表示される。表示は小さい。だが、毎日開く画面に Version があると、自分への約束が見える。
失敗談: RC の前に「あと一つだけ」と言いかけた機能があった。ダッシュボードの細かい改善、文言の調整、便利そうなショートカット——どれも悪くない。だが凍結を破ると、確認の軸がずれる。ずれた軸で Must を点検すると、何が 1.0 かが曖昧になる。曖昧な 1.0 は、運営 OS ではない。
もう一つの失敗は、RC を完璧と勘違いすることだ。RC は完璧の証明ではない。これ以上足さない期間の宣言だ。宣言を守らないと、RC は単なるタグになる。
三つめは、Known Limitations を恥じることだ。恥じて隠すと、あとで信頼を失う。AI 改善提案の自動書き込みはしない。一部の Red Action は未配線——書いておくと、期待値が整う。期待値が整うと、使う側が楽になる。
Dogfood Before Deploy は、RC の直前に効いた。自分の朝のルーティンで Dashboard を開き、コネクタの最終実行を見る。Actions で承認フローを触る。触れないものは、文書どおり未開放だと確認する。確認は、テストの補完だ。テストが通っても、使わなければ分からない違和感がある。
タグ v1.0.0-rc1 と GitHub Pre-release を置いた。Pre-release という言葉は、祝杯の音量を下げる。下げた音量の方が、次の検証に集中できる。
Must チェックリストを一つずつ潰していく作業は、地味なゲームのようでもあった。WordPress が healthy、SEOPress が healthy、WP Rocket が healthy——チェックが付くたびに安心する。だが安心は、見落としを生む。見落としを防ぐために、SQLite に行があるか、Dashboard が import エラーなく開くか、まで見た。見るという行為自体が、非エンジニアのレビューだ。
Imagify は warning 付きで OK だった。完璧な緑だけが OK ではない。warning を許容するかどうかも、仕様の一部だ。仕様に書いてあれば、慌てない。Metricool は SQLite に 8 行、認証ディレクトリの存在まで確認した。数字は小さいが、動いた証拠として十分だ。テスト 141 件の報告を見たとき、安堵と同時に冷めた。テストは過去の約束を守る。未来の運営を守るのは、これからの検証週だ。
5. 考えたこと
RC までの道のりは、直線ではなかった。何度も戻り、用語を揃え、書き込みを止め、Connector を増やし、承認を挟んだ。直線に見せたい衝動が、一番危ない。直線は、振り返りを殺す。
1.0.0-rc1 は、「作り終えた」ではなく「この形で一度、現実に出す」だ。出すことで、初めて運用のフィードバックが取れる。フィードバックは、コードより残酷なことがある。残酷だから、先に凍結が要る。凍結がなければ、フィードバック一つでまた全体が揺れる。
非エンジニアが RC まで来たのは、機能をたくさん実装したからではない。Must を絞り、文書で縛り、テストで固定し、足さない週を選んだからだ。選べること自体が、成熟のサインだと思う。
RC という言葉に慣れるまで時間がかかった。Release Candidate——候補、という響きは、最初は「まだ未完成？」と感じさせた。だが使っていくうちに、候補であることの誠実さが分かってきた。完璧を装わない Version は、運営者に優しい。優しいとは、期待値を正しく設定することだ。Version 0.1 から 0.3、0.5、そして 1.0.0-rc1——番号は飛ぶ。飛ぶのは、途中で仕様が成熟したからだ。番号の連続性より、説明の連続性の方が大事だ。CHANGELOG と ADR が、その連続性を支えた。
Security の確認も Must に含まれていた。.env や .auth が Git に載っていないこと。監査ログに認証情報を出さないこと——地味だが、漏れると全てが終わる。終わるリスクは、機能の派手さとは無関係だ。無関係だからこそ、チェックリストに載せた。載せた項目を人が見る——それも Human Approval に近い責任だ。
6. 学び
- Version 1.0 は気合いではなく、説明できる完成の宣言
- RC は新機能なしの凍結と Must 確認のステップ
- 141 テストは万能ではないが、壊れを早く赤くする
- Known Limitations を書くことは、弱さではなく誠実さ
- Dogfood Before Deploy は、テストを補完する
- 足さない決断が、Version に意味を与える
7. 次回予告
次は、RC を置いたあと——ここで終わらない——という話を書く。シリーズの区切りと、すでに始まっている運用検証の話だ。
シリーズ情報
| 項目 | 内容 |
|---|---|
| Season | 1 |
| Vol | 09 |
| 現在の開発 Version | 1.0.0-rc1 |
| GitHub | https://github.com/boraemon2000/kagoshimaniax-os/tree/main/docs/qiita |
次回予告
Vol.10「ここで終わらない」
Season 1 の終わりと、Step49 運用検証週のはじまりを書きます。