未着手の計画を進行中と書かない理由

1. リード

正式リリースが終わると、次の話も前に進んでいるように見せたくなる。私もそうなりやすい。だが 2026-07-26 時点の Current Context には、公開版リポジトリ切り出しの安全な計画と、新Versionの機能実装は 未着手 と明記されている。ここを曖昧にしないこと自体が、Kagoshimaniax OS の運営ではかなり重要だった。

PROJECT_RULES にも、将来予定を実現済みの事実として書かないこと、Version を前倒ししないこと、不明な事実は本文へ入れないことが並んでいる。今回のテーマは、「まだやっていない」をそのまま残すことが、開発の遅さではなく信頼の管理だったという話だ。

2. 背景

Current Context の現在地ははっきりしている。v1.0.0 は正式リリース済み、v1.1.0 も正式リリース済み。そのうえで、未着手として残っているのは「公開版リポジトリ切り出しの安全な計画」と「新Versionの機能実装」だ。つまり、このプロジェクトは何でも止まっているのではなく、終わったことと、まだ始めていないことを分けている。

Qiita の記事づくりでは、ここが難しい。連載が続いていると、読者にも書き手にも「次はこう進むはずだ」という空気が出やすい。だが PROJECT_RULES では、未実装機能を書くこと、将来予定を実現済みとして扱うこと、推測で穴を埋めることが明確に禁止されている。勢いより先に、線を守る必要があった。

3. 今回のテーマ

テーマは、未着手の計画を「進行中」と書かないことで、公開情報と正本のずれを防いでいたということだ。

非エンジニアの立場では、未着手と書くのは少し怖い。進んでいないように見えるからだ。だが実際には逆で、まだ始めていないことを始めていないと書ける方が、あとで強い。どこまでが事実で、どこからが期待かを分けられるからだ。

4. 実際の出来事

Current Context では、現在の開発状況に「未着手」がそのまま残されている。公開版リポジトリ切り出しは安全な計画の段階で止まっていて、新Versionの機能実装も未着手だ。同じファイルの「今やってはいけないこと」には、未着手計画を既成事実化すること、Version 1.0 / 1.1 に新機能を混ぜて書くことも明記されている。

PROJECT_RULES でも同じ方向が繰り返されている。未実装機能を書かない。Release 前の内容を完成形として扱わない。GitHub の正本と異なる情報を書かない。不明な事実は本文へ入れず、執筆メモで止める。この繰り返しを見ると、Qiita 側で強いのは「先の話をうまく作ること」ではなく、正本で確定したことだけを出すことだと分かる。

この整理は、Season 2 の現在地とも噛み合っている。v1.1.0 で完了したのは Dashboard UI 改善で、新 Connector、DB / SQL / スキーマ変更、AI 要約、自動提案、新しい書き込み Action はやっていない。つまり「次に何をやるか」より先に、「今回は何をやっていないか」を明記している。ここまで書いておくと、記事側が未来を先回りしにくい。

もう一つ大きいのは、読者向けだけでなく、書き手自身の錯覚も防げることだと思う。連載を書いていると、メモにある計画がすでに走り始めているように感じる瞬間がある。だが Current Context の「未着手」は、その錯覚にブレーキをかける。まだ始まっていないなら、書き方もまだ始まっていない形に戻せる。

ここで効いているのは、未来を語らないことではなく、未来を事実として語らないことだ。計画があることと、計画が進行中であることは違う。安全な計画が必要だと分かっていることと、その計画が動き始めていることも違う。Current Context はその差を曖昧にしていない。この差を残すだけで、あとから記事を読み返したときに「当時どこまで決まっていたか」がかなり見やすくなる。

PROJECT_RULES が強いのは、禁止事項が単発ではなく、情報源の優先順位まで決めていることだ。GitHub のコードとドキュメント、docs/chatgpt/、CURRENT_STATUS.md、Release、Issue / Milestone の順に見る。逆に言うと、会話の流れや「そろそろ始まりそう」という感覚は、この優先順位には入っていない。ここまで明確だと、記事側が未来を物語として補完しにくい。

Qiita 側が独立プロジェクトになっている理由も、ここで効いてくる。記事を読みやすくするために、つい未来の線をなめらかにつなぎたくなる。だが OS 本体と分離されているから、本体の未着手状態を記事都合で書き換えずに済む。書きやすさのために正本を動かさない。この順番が守られているから、未着手も未着手のまま残せる。

さらに、Current Context の「今やってはいけないこと」ともつながっている。そこには、未着手計画を既成事実化すること、Version 1.0 / 1.1 に新機能を混ぜて書くことが並んでいる。つまり未着手の記録は、単に静的なメモではない。今この時点で記事が踏み越えてはいけない線として使われている。未着手をはっきり残しているからこそ、その線もはっきり引ける。

この線引きがあると、正式リリース済みの範囲も逆にはっきりする。v1.0.0 は正式 Go、v1.1.0 は Dashboard UI 改善まで完了、と言い切れるのは、それ以外の話を混ぜていないからだ。もし未着手の計画まで「進行中」に見せていたら、今どこまでが完了済みかもにごりやすい。やっていないことを残すのは、完了済みの事実を守るためでもあった。

5. 考えたこと

私は以前、未着手と書くのは後ろ向きな印象を与えるかもしれないと思っていた。だが今はむしろ、その表現が一番誠実だと思っている。進んでいないことを隠すと、あとで読者も自分も困る。どの段階で何が決まっていたのかが、振り返れなくなるからだ。

AI と一緒に進めるほど、この線は重要になる。提案はすぐ出るし、文章もすぐ整う。だからこそ、整った文章がそのまま事実を追い越しやすい。PROJECT_RULES が将来予定の前倒しや創作を明確に禁じているのは、その危険を分かっているからだと思う。

Human Approval の考え方とも少し似ている。できることと、やってよいことを分ける。思いつけることと、書いてよいことを分ける。未着手を未着手のまま残すのは、その境界を文章側でも守るやり方だった。

ここには読者への誠実さだけでなく、開発チーム側の防御もある。いったん「進行中」と書いてしまうと、その後の会話も判断も、その前提に引っ張られやすい。実際には動いていない計画が、文章の上だけ先に走り始める。そうなると、あとで戻すときに説明コストが増える。最初から未着手のまま残しておけば、そのコストを抱えずに済む。

私は最初、未着手の記録は単に慎重なだけだと思っていた。だが今は、それが運営 OS の信頼を守るための能動的な判断だと思っている。先の話をきれいにつなげるより、まだ始まっていないことをそのまま止めておく。その止め方があるから、正式リリース済みの事実や v1.1.0 の完了範囲が逆に強く見える。

6. 学び

• 未着手の計画を未着手と書くことは、進捗の弱さではなく情報管理の強さになる
• Current Context と PROJECT_RULES の両方で未来の前倒しを禁止しているのは、記事の創作防止に効く
• 「やったこと」だけでなく「やっていないこと」を明記すると、Version の境界がぶれにくい
• AI と一緒の執筆では、整った文章ほど事実を追い越しやすいので境界線が要る
• 読者向けの説明だけでなく、書き手自身の錯覚を止める意味でも 未着手 は重要だった

7. 次回メモ

この続きで書くなら、公開版リポジトリ切り出しのように「まだ書いてはいけない話」をどう管理するかにつながる。進め方が確定するまでは、題材より境界管理の方が重いからだ。