本稿はコミュニティメンバー向けの啓蒙記事です
アドベントカレンダーへの参加方法を考える
団体の部
Organizationで記事を書く機会がなかったのでどうしようかと悩んでいるのですが、内部で盛り上げたいなと。
少なくとも、特定のテーマについて一人で25記事書き上げる自信はないですし、Organizationってそういうものじゃないよね、とも思ってます。
できる人がやればいい、というのは業務であればその方が良いこともある（ただし、必ずしも良いとは言えないのもポイントです）んですが、コミュニティベースなので「上手い下手」ではなくて「やりたいかどうか」を重視すべきと考えてます。
個人の部
私はこちらがメインです。本来はLinuCの話とかもしたいんですが、LinuCばっかりやっているわけではないので結構いろんなことを書いていきます。
書くテーマがいつも悩みがちなのですが、今年を振り返ってみて25記事なので、極端ですが1月に2記事書くネタがあればなんとかなるなと。
というのをコツコツやってたんですが、6~7月にエンジニアフェスタがあり、こちらのストックも必要になったというオチでした。悔やんでも仕方ないので、来年に向けて今から頑張ります。
記事を書く悩み
テーマに対して、ネタ出しがつらい
先の話に関連しますが、厳密に言えば6月からはQiitaエンジニアフェスタがあって、そちらの記事を書いたりする場合はこの限りではないのですが、アウトプットをどれだけ出せるかを一つの目標にするのはアリだと思います。
たとえばLinuCレベル１の内容でも試験範囲はかなり広いので、１トピックに２〜３記事ぐらいは書けそうな気がします。
ボリュームが多すぎたので、ある程度の部分（今日かけた範囲）で公開して、続きを翌日に書いて続きものにしちゃう方法もあれば、学んだ内容と追加学習した部分と、試験対策や実務（やってみての）での違いを比較してみたりとか、探せば結構出てきそうな気がします。
何を書けばいいかわからない！という場合は、普段からアウトプットしている人にネタの絞り出し方を聞いてみる・相談してみて、我流の方法を見つけ出すというのも一つの方法かもしれません。
書く時間がない
AIを使えるところは使っていこう
AIに丸投げはしない。できるところはやってみよう
ゼロからイチを書くのが本当に大変です。
が、いったんは叩き台ということでほぼ100に近い内容をAIに大まかに書いてもらって、その中で自身の見解を書いてみたりするのはアリなんじゃないかなと。
とはいえ、前提としてAIは嘘をつくし、嘘だと気付きにくいやり方をするので、人間で言うところのいわゆる「覚え間違い」があります。専門用語では「ハルシネーション」と言いますが、要は間違いを間違いだと気づかない、気付きにくいやり方でそれっぽく言うんですよね。
そういった部分を監修するだけでもアウトプットはともかく、スキルアップにはつながります。
効果的かどうかは一旦置いておきますが、AIが書いている内容を自分でも書けるように「見学」という形で研鑽を積んでいきましょう。
書き方がわからない
※書きたい内容が決まっている前提でのお話です。
書く練習をする場合、まずは何も考えずマークダウンを覚えるのが手っ取り早いかなと。
マークダウンを覚えると、見出しやリストなど見た目に変化が一発でわかるし、書きやすいのでちょっとだけ真面目に覚えようとすれば自然と習得できていきます。
特殊な記法をマスターすると他の環境で使えない、なんてこともあるのでのめり込みすぎ注意ですが、多くの書き方は他の場所やサービスでも使えるので、よくわからない場合は「他の場所で使えない書き方もあるんだな」と認識する程度でよく、具体的にどの書き方がQiitaオリジナルだとかはまだ気にしなくていいと思いますよ。
大枠を考えるのはAIに任せて、細かい書き方を自分でやってみると言うのは案外良いアプローチだと思っています。
もちろん、AIにマークダウンで書いて、と言えばその形で生成しちゃうので、どこから自分の練習や勉強のつもりでやるかは考えるべきですね。
プロンプトエンジニアリングが重要になってきそうです。
参加の仕方がわからない
さっそく個人のアドベントカレンダーの参加登録をしたので、手順をまとめておきます。
https://qiita.com/advent-calendar/2024/calendars/new
カレンダー作成ページを直接置いておきます。
見ればわかるぐらいにシンプルな設定項目しかないので説明は省略。
カレンダーを作成したら、いつも通り記事を書きます。
11月の時点ではまだ期間中ではないため、12月まで下書き状態か限定公開で置いておきましょう。
12月になると、記事編集ページの公開設定ボタンから参加するアドベントカレンダーを選べるようになるはずです。
12/3追記 Organization用の記事を書く場合は一手間が必要
限定公開記事はQiita Organizationに登録できません。
事前に予約投稿する場合は、後ほど手動登録をすることでOrganizationに登録できます。
コミュニティ向けに書いた記事（後で編集が必要になったもの）はこれが初めてだったので気付くのが遅れたんですが、そもそも限定公開記事はQiita Organizationに登録できないようです。
実際の例を見てみましょう。
これは昨日の記事が公開された後のスクリーンショットです。
記事投稿画面の公開設定の次の画面です。
ポイントになるのが、この記事は既に限定公開の状態ではなくなっている（一般公開の記事）であることです。
この状態になると詳細設定欄よりOrganizationの紐づけができます。
あるいは、最初から予約投稿を使わずに公開する場合は気にしなくてよいです。
そして、以下は予約投稿を想定した限定公開の記事です（つまり、公開前の時点のこの記事です）
ご覧の通り、限定公開の記事では諸々の設定ができません。
厳密に言うと、アドベントカレンダーには予約しておくのでアドベントカレンダーの設定ができないことは問題ではありません。
が、Organizationに設定できないという問題は解決できません。
事前に予約投稿する場合は、後ほどOrganizationを手動登録をする事をお忘れなく！
参加すると何が嬉しいか？
詳しくはプレゼント企画のページをどうぞ
一言で言うと、Qiita特性Tシャツがもらえる可能性があります！
とはいえ、そもそも賞を目的にアウトプットをする事が自己啓発の観点から良いのか？というのはありますが、どうせやるなら賞を狙いたいよね！というのは私も分かります。
ので、以下は「やるからには〜」という前提で話しますね。
実際、アウトプットは継続的に続けつつ、公開時期だけコントロールしています。
コントロールと言いつつ、実際は思い立ったら記事を書き溜めつつ（どうせ誰もみてないでしょ、と思う事は結構大事）Qiitaのバッジをもらえるように公開設定をするぐらいなので大した事はやってないです。
サボると投稿をする事自体を忘れてしまうため、バッジを獲得するためにやる習慣をつける事を目的にするのが良いのかもしれません。
はじめての参加の場合は、プラスはじめてのアドベントカレンダー企画の対象にもなるはずです。
アウトプットの内容だけでなく、品質も気にしていくという形でステップアップしていくと良いでしょう。
（12/3追記）
はじめてのアドベントカレンダーに参加表明をするのが一番手っ取り早いですね。
アドベントカレンダーを作るというのもなかなか勇気がいるので、書きなれてから作っていくのが良いでしょう。
今日言いたいのはここまでなのですが、以下でお節介したいおぢさんを発揮していきます。
「散発的に言いたい事を書いているコーナーを開閉してみる」
モチベーションコントロールの仕方（提案）
頑張りすぎるのは当然苦しいのでおすすめしませんが、やらなくなるのも良くないです。
「ほどほどな負荷量」という抽象度が高すぎて数値化できないパラメータであるため、人によって異なるためうまく調整する必要はあります。
今回はアドベントカレンダーという機会があるのでアウトプットの機運を高める方面で話をしていますが、そもそもアウトプットは一時的に集中させるより定期的かつ長期でやった方が良いことが多いです。
その中でもアウトプットを集中的にしたい事もある（特に大量のインプットを入れたタイミング）ので、そういった時は短期でまとめる事もあります。
「書かなければならない」というプレッシャーを感じるとネタが出てこなくなりとてもつらいので、後述のやり方を考えるというのが上級テクニックです。
ネタを生み出す仕組みを作ろう
単純に技術理解をするだけなら勉強すれば良いです。
テキストの内容を写経してみるとか、それこそQiitaなりZennに良い記事が書いてあるので、その内容を踏襲してみたりなどを手元で動かしてみたり、という方法があります。
とはいえ、実態としてHello world的な内容が多いため、実際にその内容を理解したかどうかは別の話です。
（これはセミナー・カンファレンスあるあるですね）
そこで、実際に自分で運用してみてどうか？というところまでやってみましょう。
導入部分の記事は多くあれど、運用してみた話はなかなか出てきません。見つかったとしても、たとえば大型のカンファレンスで事例紹介として触れられる程度の内容レベルです。
本当に欲しいのは「それを使ってみて、運用してみてどのようになったか」です。
- 具体的な課題・解決方法・その方法を実施してみてどうだったのか？
- うまくいった・失敗したに関わらず成果は？
- もう一度やるならどうしたいか？
運用したからこそのPDCAの中身を知りたい、また価値があると感じるのです。
この「運用する」が大事で、うまくいっていないことを一旦書いてみる、その後に追記するというのは非常に良いアプローチです。
色々な勉強を積み重ねていくと生じる課題
これを増やしていくと「TODOをまとめたり管理する仕組みが欲しい」という要望がうまれてきます。
まずは自分のタスクが膨大になった、というより「いつかやらなければならないが、今はできない」という内容が徐々に積もっていくので、これを一覧・検索できる仕組みが必要になってきます。
そして、これらに期限を設ける場合は期限を可視化する仕組みが欲しくなる。
これがプロジェクト管理ツールが生まれた理由なのだろう、と感じることができます。
重要なのは学ぶ方法として「体感する（経験する）」ということをやっています。
ここでの例として、分かりやすくプロジェクトっぽくしましたが、シンプルにセミナーセッションでまとめたノートと、当該ノートに対応するローカル環境などでのハンズオンを紐づけて、それらの内容や手順などを集約・一元管理できる仕組みを作っておくのも重要です。