Qiitaエンジニアフェスタで38記事？だったっけ、埋めようと思って頑張っていたので、デイリーで38記事（少なくともアドベントカレンダーで25記事）埋めれるならWeeklyで50なんて楽勝でしょ！
というので始めたセルフ企画の話をします。

（追記）なお、投稿時点では24週まで継続できているので信頼性はそこそこある方法、だと思っています。
当然ですが、あくまでも本稿の手順は記事投稿のサポートという位置づけであり、この方法を使えば必ず継続性が生じるというものではありません。

やったこと

QDD(Qiita Driven Development)を提唱します。Qiitaに記事を書くためだけにやる。
Zennを使っている人はZDDですね。noteならNDD。好きなxDDを作りましょう。

今回はQiitaの記事を書く事を目的にせず、Qiitaの連続投稿Weeklyバッジをもらう事を目的に、しかたなーく記事を毎週投稿します

1. 【モチベーション管理】公開リポジトリにIssueとProjectsのタイムラインで可視化する

口で言うのは簡単ですが、なんでも「続けるぞ」という強い意志がないとどこかで飽きますし、ダレます。
誰も見てないかもしれないけど、誰でも見える場所に置いておく事は自分を奮い立たせられます

2. 【記事管理】下書きをいくつかストックする

重要なのは記事を公開することではなく、毎週１記事以上を書く事です。
必要があって先出しすることはありますが、１記事以上を継続して書き続けられるなら問題ないです。
どうせアドベントカレンダーもある（見送ればだいぶ楽になるのですが、Qiitaのアメニティが欲しいのでがんばります）ので、記事のストックはあればあるほど良い！

なお、記事のネタに困ったら生成AIがアツいので、色々なユースケースを考えて実践しましょう。
記事自体をAIに書かせるには？というテーマで試行錯誤するだけで記事が書けます。まさにQDD！

3. 【スケジュール管理】投稿日を見える化する

下書きを書いても、毎週投稿しないと意味がありません。
一番いいのは予約投稿をすることですが、残念ながらQiitaのWebエディタにはそんな機能はありません。
アドベントカレンダーの時期なら予約投稿を限定公開を使うと実現するのですが、平時は残念ながらないので別の方法を使うしかないです。

これを解決する方法を考えてみましょう。

一番楽に対応するならカレンダーアプリ

私の場合は、運用として必ずGitHubプロジェクトをTODOにするというやり方をしています。最初はGoogleカレンダーに書いていたのですが、スケジュールがビッシリ埋まって逆に見づらくなったので廃止しました。GitHub Issueの日付を取ってきてGoogleカレンダーにも登録する、という仕組みを考えたのですが、Issueを書いたら容赦なくバンバンGoogleカレンダーに登録するようになってしまったのも設計ミスです。
特定のタグをIssueに設定しておき、それらを判別してカレンダーに登録する方法もありますが、もう面倒くさくなって廃止しました。

QiitaCLI＋Cronを使う

※Windowsでもできます。

これらを組み合わせる方法です。
なお、WindowsユーザーでもWSLが使えるならそちらでやっても良いです。

要は、予約投稿したい記事をいつ投稿するか日付管理しておき（日付管理のルールは任意で作りましょう）投稿予定日を判別しながらpublicフォルダに移動して npx qiita push するようにしておくだけです。コンフリクトが起こると面倒なので、 npx qiita pull も同時に実施できると良いでしょう。

4. 【投稿管理】投稿が確実にされたことを確認する

QiitaCLIが使えるなら npx qiita pull の結果を追いかければ良いです。全ての記事から当日ないし前日の投稿を探して、見つかればOKフラグを立てるようにテストプログラムを書けば確認の手間すら省けます。

QiitaCLIは投稿キャンペーンに対応できない

Webエディタを使えば投稿した直後に投稿ページに飛んで内容が確認できるため、投稿方法によってはCLIを使うより素直にWebエディタを使う方が楽かもしれません。
特にキャンペーン情報はQiitaCLIからは設定できないため、どうしても投稿キャンペーンとの紐付けはWebエディタを使用する前提になってしまいます。

色々考えると、毎週一回はQiitaの投稿画面を開いて記事をコピペした方が（期日忘れのリスクはあれど）楽な気がしてきます。

このやり方でもなんとなく続いてます

お察しかと思いますが、本稿も記事を書いている日と投稿日はズレるはずです。
というかズレます。
作成日と投稿日のズレがイコールストックの量と考えることもできますが、重要なのはそこじゃない。
ちゃんと目的やいくつかの運用上で対処可能な気付きを作って習慣化すれば続くよ！という事が言いたい事でした。システム屋としては「なんでそんなリスクを背負ってやってるの？」と思わなくもないのですが、業務ではなく個人目標なので時間と目的がブレなければ色々やっていいと思うんですね。
ということで、仕組みを考える事はやってみて、既に私はQiitaに投稿するという習慣がしっかり根付いているのでそこまでやらなくても出来るな、という確信のようなものを持っているのですが、なかなかアウトプットの習慣がつかないのであれば、本稿のやり方は一つの気付きにできそうな気がしました。

今まさに運用中であるため「この方法でうまくいきました！」と断言するのが難しいのですが、この方法でうまく行っているので大きくは外れないんじゃないかと思っています。