明日のLTで話せる限り触れます、という宣伝

スライドも公開しておく（公開時点では、一応検索回避のため限定公開記事としているが、後日一般公開にする）
https://qiita.com/nomurasan/private/cf405580ce9f3ae8749b

今回の予定と実績

11月時点の仮題	実際の記事	誤差	日付移動	12月までに脱稿したか	備考
1. アドカレの所信表明、2023との違いや意気込みなどを語る	アドカレ2024やるので、所信表明と2023との違いや意気込みなどを語りたい	実質ない	-	○	他の記事を書いた後に見直して調整
2. 運用してわかった、GitHubのIssueとDiscussionを個人利用でのベストプラクティス・バッドノウハウ	（同左）	-	-	○	これは早い段階で決めていた
3. QiitaのWebエディタのシステムを知ってアドベントカレンダー完走を目指そう！	（同左）	-	-	○	これは早い段階で決めていた
4. ToC未経験リスキリング講師をやる時の準備〜初回登壇編（集合研修）	【初心者向け】アドベントカレンダーに参加してみよう！	廃止・書き直し	-	❌	元々の想定はお蔵入りになった記事の書き直しだったが、コミュニティメンバーの需要が高いこちらを採用した。
5. Issueを「- [ ] タイトル」で作成時にCIを使って特定の条件だけ自動で設定させたい	（同左）	-	-	○	これは早い段階で決めていた。前の記事を差し替えたが順番に影響なし
6. アドカレもWeeklyバッジも継続可能にするIssueの書き方と運用	チートシート：mermaidで書くフローチャート・シーケンス・クラス図・ガントチャート・ER図・Gitグラフ	書き直し	8日	❌	受講生からの要望があり、ついでに一般公開
7. 現役エンジニア兼新卒・リスキリング研修講師がAIを使ってCIを作ってみた	【研修資料】AIを使ってCIを作ってみた	体裁だけ変更	-	△	AI研修をやった資料をタイトルに合わせてアレンジ
8. 私とDevOpsとDevRelと	アドカレもWeeklyバッジも無理をなるべく排除してシステマチックに継続可能にするIssueの書き方と運用	-	6日	❌	私がやっていることはDevRelなのか？といういつもの自問自答で解を失ったため取り下げた
9. （別日とダブっていたため空欄）	「連続投稿 Weeklyを完走（50個）する」をTodoリストに入れて管理＋投稿し続ける仕組みの考察	新規	-	○	元々の予定を直前で廃止したためネタは決めてなかったが、書きたいテーマが出てきたのでその日対応
10. フリーランスエンジニアが知っておくべき税金の話	そろそろマークダウンに慣れてきた？Qiitaでアウトプットの質を高めるなら他にもできることはあるよ！	差し替え	-	×	コミュニティメンバーフォローを優先
11. MacStudioを買ったので、既存環境から移行した話（ハード・ソフト・データ）	MVCモデルを飛ばしていきなりMVTモデルの解説が必要になった時にテンプレートをサクッと動かしてデモしたい	差し替え	-	○	受講生用の補助教材だが、ほぼノンプログラマーがサーバーインフラを体感しやすい良い資料だと思ったので公開
12. 【来年度新入社員向け】自分にとって使いやすい日報の書き方と管理の仕方	（リマインド・イベントレポート）エンジニアに“アウトプット”がなぜ重要なのか	差し替え	-	❌	コミュニティイベント用の記事を一般公開
13. 現場社員向け：昨今の新人教育の現場では何をやっているのか？	12/7 OSC福岡参加レポート	差し替え	-	❌	コミュニティイベント記事に差し替え。元記事は差し迫った時に公開
14. 情報系に進路希望されている方向け：IT講師の「覚えなくていい」の本当の意味を知ろう	（業務デモ・体験）ITパスポート研修～エンジニアが言う「覚えなくてよい」の意味と程度の例～	タイトルのみ	-	〇
15. 2024年・私のコミュニティ活動記録	【失敗談】Google NotebookLMのソースを自動更新できないか色々やってみた【考察】	差し替え	-	〇	この辺りから「もう限定公開にする必要はないけど出すタイミングないな」という記事の供養を優先していく
16. 【考察】デジタルスキル標準と「デジタルスキル標準を身につける」とは？	（イベントレポート・ハンズオンの例）PowerBIセミナー	差し替え	-	〇	同上
17. どのようにして2023年のアドカレを完走し、2024年のアドカレを完走しようとしたか？	（同左）	-	-	❌	ここまでやってみて「これでええんか？」感が出てきたため、自己反省
18. 私的、2024年のAI事情と傾向分析（来年度の研修とか）	【入門者向け】条件分岐を図解で学ぼう	差し替え	-	❌	供養と、過去記事で限定公開を想定していたことで本記事がリンクに乗っていたので慌てて変更
19. 新卒講師の私が、アルゴリズムの練習でシミュレーションゲームをおすすめする理由	（供養）【入門者向け】繰り返し処理を図解で学ぼう	差し替え	-	❌	同上。補足だが、本日記事の解説部分だけを取り出そうとしたのがこの３日間の記事の供養である。
20. 機械学習やAIにも興味がある人が、エンジニアの学習におすすめしたい無料教材	（供養）【入門者向け】配列・連想配列・クラスーオブジェクトを図解で学ぼう	差し替え	-	❌	同上
21. 結局、AI検索でRAGを使うならどのような使い方が良いのか？	未公開下書き・限定公開ページを整理しよう	差し替え	-	❌	事前に書いていた記事が、バージョンアップ・技術刷新により微妙感が出てきたので廃止
22. 2024年に参加した勉強会総括レビュー・ピックアップ	[2025年版] ブラウザのサイドパネルも活用しながらブックマーク管理とタブの固定化に依存しない運用を考える	差し替え	-	〇	直前にパソコンを買ったので、その時の備忘録に差し替え
23. コミュニティ向け：会社員からフリーランスへ、フリーランスから法	（イベントレポート例）社内トレーナー導入成功のコツ	差し替え		❌	税務署に相談に行ったら漏れ抜けが分かったため。タイミング的に間に合わずなくなく没に
24. 2024年に読んだ本の紹介	（イベントレポート）地獄のAI	差し替え	-	❌	紹介したいイベントだったので急遽変更
25. アドカレ2024を完走した感想	（同左）	-	-	❌	25記事更新時に随時追加。イベントレポートをリアルタイムで書いてある時のやり方をアドカレでやってみた

なぜ差し替えの記事が多いのか？

9/25（誤差の新規を含み、ほぼないものは「ない」でカウントしている）

結論から言うと「その時書きたいものを優先した」ことと「ウィークリーバッジを安定的に獲得するために週一投稿を続けた結果、週2以上で記事を書くやり方がすでに定着していた」からだろう。
一部公開するつもりのなかった非公開記事にリンクをつけてしまった事を失念していて、優先順位を上げたものもあるが、これも含む。

よく考えたらウィークリーバッジもこの手法で古い記事が溜まった結果、結局公開するタイミングを見失う、という事態になった反省が部分的に活きなかった結果になった。
特にAI系は寝かせた記事が陳腐化してしまう（そのままでも部分的に通用するが、もっと良い方法が出てきたり発掘されたりする）という想定外のトラブルがあり、急遽何とか解決しようとしていたりもしている。

これがいいか悪いかは一旦置いておくとして、

誤差となった記事

そもそも、仮題も相当頑張って捻り出した感があり、ワンパターンな記事を置き換えているように見える
また、記事を書いていたら筆が乗って長尺になったり、タイトルから脱線したのでスピンアウトしたものもあれば、限定公開記事を複数にわたって書いていたものをうっかり１記事だけ公開したことに気付いたパターンや、当時は良かったが後から見直すと微妙になって急遽差し替えたものなど、こうしてみると半分近くは無駄になってしまった感がある。
エンジニアフェスタとかに回すか、ウィークリーに回す案もまだあるので、これらの記事が出てくる事は十分に考えられる。

なお、準備が過ぎて12/2の時点でこうなった

単純計算で残り23日（当日含まず）で6記事＋アルファ（たとえば25日の振り返り記事＝これは、これらの内容を書きながら追記していくスタイルにしているため含む）分を対応すればよいので相当に楽。
なんなら、限定公開記事（下書きを整理したもの）も使える

タイトルだけなら公開できる限定記事たち。一部アドカレに投稿済みのものもある

と、このように未投稿状態で放置していた下書きを限定公開に置いただけで25記事以上あり、簡単にクリアできてしまったため、単純にQiitaに書いて公開していない記事を整理するために活用した感すらある。
とはいえ、下書き当時の内容はそのまま使えない（＝リアルタイムイベントレポートを寝かせたもの以外が該当する）ので、最新の状態に更新した上で投稿しているのは最低限の礼儀だ。

が、やはり普段から意識的に記事を書くくせがついているので、早く公開したい記事が出てきた場合などは元々の予定を結構簡単にひっくり返してしまっているのも私らしい。
（普段記事を書くときにAIを使わないのは非効率的だ、と自らを戒めようとは思っているが…）

今年のエンジニアフェスタが38記事だったので、その想定はあったかも知れない。
ここで在庫を掃いてしまったことで、また38記事分のストックを考える＋ウィークリー１記事ずつ分をこなす必要があるわけだが、ネタは無限に上がってくる（元々の気質的に、そして機会を作ったり運用メモ＝ナレッジが多い）ので実は困っていなかったりする。

書いたIssue（リポジトリ自体が非公開のため、スクショのみ）

設計だけをGitHubプロジェクト化して、投稿管理はディスカッションを使おうと思ったが12月に入ってからは直接Webエディタ・アドベントカレンダー側で管理した方が良いことに気付いて実装・レビュー・公開プロジェクトは作らなかった（作ったけど、すぐにクローズした）
最初はGitHubプロジェクト１つで設計から実装・公開まで包括的に管理しようとしたものの、ステータスが煩雑になりすぎたのでプロジェクトを分けて運用した経緯がある。
GitHubプロジェクトだから駄目だ、というのではなく、ステータス管理ツール全般に言えるのが「管理自体が複雑になりすぎる」という問題は結局解消が難しいんだな、という体験を得られた。
これが自分以外のユーザーが発生するものであれば、例えばRedMineなりJIRAなりといった管理に強いツールでタスク管理を検討するし、多少複雑になろうが導線整備をするが個人のプロジェクトの場合は毎日集中的に見るのではなく、今日ちょっとやったら２か月後にもう一回見る、という運用なので「見方を忘れる」という前提でのプロジェクト管理をしなければならない。

となると、今までのプロジェクト管理の手法は全く通用しない、という事を体験で理解した。という意味では成長か。

アドカレ26日目の記事（スライド資料）も作る

今やっと書き終わった。実質2日分の記事を今日一日で仕上げた形になった（関係ご各位、遅くなってごめんなさい）

品質を気にするとやっぱり難産になるね、と改めて思ったので強調しておきたい。

結局やってしまった。
品質を気にする＝誰かに見られる前提で記事を書こうとすると負荷がとんでもなく上がるので、いいねをクレクレすることはあっても、質問系のコメントは「アドベントカレンダー期間中において」見ないし、対応もしない方が精神衛生上良いのかもしれない。

リアルタイムに更新・追記していく記事のゴールを考える

アジャイル開発の問題点と大体同じことが起こる。ゴールを決めておく。クオリティなのか文字数なのか期日なのか。
少なくとも、本稿は25日に投稿すれば何でも良いので、できる限り粘って品質を上げていく方に舵を切った。
おかげでめちゃくちゃな難産になった。書いた記事をAIレビューを受けて校正する、なんて事をやり始めたら延々と終わらなさそうなので、本稿のみならず本アドベントカレンダーを通じて結局AIを入れることは一度もなかった。
せっかくAIを使おうという話をしていたので、AIを使った記事を作ってみて「こんな感じだよー」とデモしたかったのだが、いかんせん自分でも書きたい話とか、考えていることをきちんと伝えたい！というこだわりが邪魔してAIを介在する余地を作らなかったのだと思う。
決してAIを入れることで記事の品質が落ちる、という事は言いたくないが、自分が書きたい事を100%に近いところに持っていくなら、AIを入れてしまうと100%から離れてしまうのは仕方がないことで、それが結果的に「自己満足を基準に見た時の品質が低い」と感じてしまうことになる。
結局はお気持ちでしかないが、自分の記事ぐらい自分で書いてスッキリ締めたいね、という感覚が伝われば良いか。

アドカレorエンジニアフェスタ2025（未来の自分）に向けてメッセージ

どんなに記事を用意して、万全を期したとしてもその場の思いつきで書き換えるだろうなので「準備は150%用意して、そのうち50%も要らなかったね」という結論になる上で、

どのような準備が効果的だったか
どのような準備が結果的に不要だったか

を分析するつもりでやるのが良さそうだ。