下書きと完成版を別の箱で管理することにした話
このサイトの記事は、下書きを少しずつ書き溜めて、レビューを通したものから順に公開していく運用にしています。
最初は、できかけの下書きも、レビュー済みのものも、公開済みの記事も、全部同じ場所に置いていました。ファイルを置いておくクラウドの倉庫を一つ用意して、その中にまとめて入れていたのです。
これが地味に混乱の元でした。今日はその切り替えの話を書きます。
ひとつの倉庫に全部入れていた頃
ひとつの倉庫にまとめていた頃の困りごとは、こんな感じでした。
- 公開サイトの変更履歴に、まだレビュー前の下書きが混ざる。
- レビュー待ちかどうかを、ファイルがどこに置かれているかだけで判別しないといけない。
- 新しい下書きが、公開に近い倉庫に直接置かれる構造になる。
- 下書きをまとめて整理したいとき、公開コードと一緒に触らないといけない。
特に最後の「整理しづらさ」がじわじわ効いてきて、ある日「これはファイル名や置き場所の工夫じゃなくて、構造そのものの問題だ」と気付きました。
倉庫をふたつに分けた
そこで、倉庫をふたつに分ける構成に切り替えました。
ひとつは公開用の倉庫。公開済みの記事と、公開待ちの行列に並んでいる記事を置く場所です。
もうひとつは下書き用の倉庫。レビューが終わっていない下書きを、ひたすら溜める専用の場所です。
新しい下書きは下書き用の倉庫にだけ追加する。レビューを通したものを、公開用の倉庫の公開待ち行列に移す。
役割をくっきり分けただけの、すごくシンプルな構成です。
最初はゆるく、増えてから整理した
下書き用の倉庫には、いろんなジャンルの記事が混ざります。制作記、お金まわりの話、その他もろもろ。
最初は、ジャンルごとにファイル名の頭に短い印を付けて、全部一つのフォルダにフラットに並べていました。本数が少ないうちは、それで「今レビュー待ちは何本、どのジャンルが多いか」がパッと把握できて十分だったのです。
ところが本数が増えてくると、フラットだと見渡しづらいジャンルが出てきました。なので、本数が多いジャンルだけ専用のフォルダに分けて、本数が少ないジャンルはフラットのまま、という使い分けに自然と移っていきました。
最初から完璧な構造を狙わず、運用しながら必要に応じて足していく。これが自分には合っていたようです。
「ストックがいくつ残ってる？」をどう数えるか
下書きは、「ストックが少なくなったら補充する」というゆるいルールで増やしています。
ここでちょっと頭を使ったのが、ストックをどうやって数えるかでした。下書き用の倉庫にあるレビュー待ちと、公開用の倉庫の公開待ち行列。この両方を足したものを「今のストック」としています。
これで、レビューが滞って下書きが溜まっているときは新しく書かないし、公開ペースが速くて行列が減っているときはちゃんと補充する、という需給に応じた挙動になりました。
レビューと公開を気持ちの上で切り分けられる
倉庫をふたつに分けてみて、思わぬ副産物がありました。レビューと公開を気持ちの上で切り分けられるようになったのです。
下書き用の倉庫の中身は、何度書き直してもいいし、ボツにしてもいい。私の頭の中の「整理途中の部屋」みたいなものです。
一方、公開用の倉庫の公開待ち行列に移した時点で「公開を承認した」とみなす。そういう暗黙のルールが自然に成り立ちました。
手を触れる場所と、気持ちの上での責任が一致しているので、迷いが少ない。これは思っていた以上に楽でした。
気をつけているのは、同期忘れ
ふたつの倉庫を使い分けると、当然「片方が古いまま」という事故が起きやすくなります。
特に怖いのが、レビュー後に下書き用の倉庫からファイルを消し忘れること。そのままだと、ストックを数える時に「まだ余裕がある」と誤って判断してしまいます。
なので、公開用の倉庫に移す処理の中で、下書き用の倉庫の削除と公開用の倉庫の追加をひとまとめで行うようにしています。
これで片方だけ更新されて中途半端になる、という事故をだいぶ減らせました。
振り返って思うこと
「最初からふたつに分けるべきだったか？」と聞かれたら、そうとは思いません。本数が少ないうちは、ひとつの倉庫で十分機能していました。
ストックが増えて、レビューする側の負担が見えてきたタイミングで構造を見直す。この順番が、個人で続けていく開発には合っている気がします。
最初から作り込みすぎず、運用しながら構造を育てていく。これが今のところの自分のスタイルです。
← 他の制作記を見る ｜ トップ ｜ お問い合わせ