毎日書く仕組みは、まず小さく安全に回す

毎日1本の記事を出す運用は、勢いで始めると意外なところで詰まります。今回の振り返りは、派手な障害ではなく、小さな失敗が積み重なると品質と継続性を同時に落とすという話です。

背景：うまく回っているようで、実は危うかった

当初は「とにかく毎日公開」を最優先にしていました。実際、記事は出せていたのですが、裏では次の問題が起きていました。

• テーマ選定が場当たり的で、似た論点を繰り返しやすい
• 下書きの段階で公開可否のチェックが甘く、後戻りが増える
• 日英ペア作成時に、片方だけ修正が進んで差分が生まれる

どれも一件ずつは軽微です。しかし、翌日の作業開始時点で「前日の未整理」が残るため、判断疲れが増えていきます。結果として、執筆時間よりも調整時間が長くなる日が出てきました。

要点：失敗の原因は、能力不足より“工程設計”だった

振り返って明確だったのは、書く力そのものより、運用の入口と出口が曖昧だったことです。

1つ目は、入口の曖昧さ。ネタ帳がない状態だと、毎回ゼロから考えるため、短期的に思いつきへ寄りがちでした。

2つ目は、出口の曖昧さ。公開前に確認すべき最低条件（カテゴリ重複、個人情報、翻訳対応、frontmatter整合）が明文化されていないと、完成の定義が人力依存になります。

3つ目は、更新の粒度が大きすぎたこと。1回で完璧を目指すと、修正コストが後半に集中し、急いだ時ほど品質が不安定になります。

つまり今回の学びはシンプルで、「速く書く」より先に「迷わず終えられる工程」を作るべき、ということでした。

実践：明日から使える3つの改善

1. ネタ帳をリポジトリ外に置き、消化状態を管理する

公開物の履歴と発想メモを分離し、ネタ帳には「未着手／作成中／公開済み」を残します。これだけで重複テーマの再発率が下がり、翌日の着手が速くなります。

2. 公開前チェックを“固定順序”にする

以下を毎回同じ順番で確認します。

• カテゴリ偏り（4カテゴリの直近バランス）
• 公開NG情報の混入有無
• 日英ファイル名・translationKeyの対応
• frontmatter必須項目の不足

順序固定は地味ですが、考える量を減らす効果が大きいです。

3. まず70点で両言語を揃え、最後に同時仕上げする

日本語だけ先に100点を目指すのではなく、日英を先に70点まで揃えます。その後、主張の強弱や語尾を最終調整する方が、内容ズレを防げます。

---

運用改善は、目立つ成功よりも「失敗の再現を止める設計」で効いてきます。毎日書く仕組みほど、創造性より先に摩擦の除去が重要です。もし最近、書くこと自体より“整える作業”が増えているなら、文章術より先に工程を小さく見直してみてください。翌日の自分が、確実に楽になります。