はじめに

🦌この記事は Colorful Palette アドベントカレンダー 12/24 の記事です 🎅

こんにちは、株式会社Colorful Palette でクライアントエンジニアをしているまるじゅんです。
アドベントカレンダー(以降、アドカレ)では 12/18 の記事も書かせていただいて、チーム内の文化について触れているので、ぜひ読んでいただければと思います。

さて、今年 Colorful Palette(以降、カラパレ)では初のアドカレを実施しています。
ご覧いただいているみなさん、本当にありがとうございます！！

実はこのアドカレは自分が提案して実施まで至ったものになっており、運営は私とめりささんと広報チームとで行っています。
(めりささんには、アドカレの土日の記事を書いていただいていますので、ぜひご覧ください！)

入社間もない自分がちらっとアドカレを提案しても「やっていいよ！」と言って本当にやらせてもらえるのは、カラパレらしいところだなと思います。

アドカレも残り2日ということで、この記事では初めてのアドカレ実施に向けて行ったことや工夫したこと、失敗したことなどをお伝えし、今後同じように初めてアドカレを実施する方のお役に立てればと思います。

行ったこと

目的を決める

アドカレを始めるにあたって最初に考えたのは、目的を何にするかでした。

例えば今回のアドカレでいえば、「エンジニアにColorful Palette Tech Noteへ記事を投稿する経験をしてもらう」ということを目的にしていました。
※ Colorful Palette Tech Note とは？の説明は、以前のこちらの記事をご参照ください。

Colorful Palette Tech Note は以前からあったものの記事の投稿はあまりできておらず、今後更新していくにしても、まず記事を投稿する経験がないと、ハードルが高いままになってしまうと考えていました。
また、ブログ記事を投稿する経験自体が少ない方もいたため、まずは一度経験してもらうことが大事だと考えました。
そういう意味では、アドカレは技術的な記事以外にもゆるい記事も許される(？)ような雰囲気があり、且つ多くの人数が参加できるので、ちょうどいいタイミングだったと思います。

当たり前ですが、この目的の部分は各社で異なると思います。
すでにアドカレを毎年継続できているような会社であれば、会社の知名度アップであったり採用へつなげていくことが目的になるかもしれません。

レビューフローの整備

会社でアドカレをやる上で、記事内容のレビューは外せないかと思います。
どこを重視してレビューするかといったレビュー内容を考えることも大事ですが、
ここでは、参加者が記事をレビューに出してから完了になるまでの「レビューフロー」を考えることについて、話をします。

アドカレが始まると、参加者がそれぞれのタイミングで記事を書き出し、それぞれのタイミングでレビュー依頼が出されます。
公開まで余裕がある場合もあれば、公開当日にレビュー依頼がくる場合もあります。
また、一度でレビューが通ればいいですが、なにか修正を依頼する場合もあり、各記事が今レビュー修正中かどうかも把握しておく必要があります。
さらには、今回のアドカレでは、

という体制で行ったため、今が開発レビュー中なのか、広報レビュー中なのか、ということも把握する必要がありました。

考えるステータスが多く、白目をむいてしまいそうですね。。 。

このステータス管理を円滑に進めるため、今回 Notionで以下のような表を作り、各記事のステータス管理を行うようにしました。

準備した各ステータスと意味は以下の通りです。

• Not started : 未着手

• In progress : 記事執筆中

• In dev review : 開発側でのレビュー中

• In 広報 review : 開発レビューが通り、広報レビュー中

• Approve : 広報レビュー通過

• Done : 公開完了

記事を書き出したら「In progress」へ参加者に変更してもらい、書き終わったら「In devレビューへ変更してもらいます。
「In devレビュー」のものを開発側でレビューし、通過したら「In 広報レビュー」にします。
それも通ったら「Approve」にし、公開されたら「Done」になります。

このように各ステータスを表にしたことで、各記事のステータスが一覧でわかり、なんとか混乱せずに進めることができました。
また、この表を全員の見えるところに置いてあったので、In dev review の記事を気が向いた人がレビューしていくなど、運営と参加者が相互に関われるようになったと思います。

Qiitaアカウントの用意

アドカレといえば、Qiita や adventar.org にカレンダーを作って行うことが多いと思います。
カラパレは今回Qiitaのアドベントカレンダー上にカレンダーを作って実施しました。

Qiita 上で行う場合、アカウント周りでいくつか考慮しないといけないことが出てきます。

まず、 Organization アカウントについてです。
Qiita上でカレンダーを作る際、個人で作成する他に、カレンダーを「Organizationアカウントと紐づける」ことができます。
紐づけることで、以下のようにカレンダー上に Organization の名前やアイコンなどを表示することができ、会社の宣伝などに使うことができます。
また、そのOrganizationに属している人しか記事をカレンダーへ登録できない、という制限もつきます。

Organization と紐づけた方が、会社でアドカレを実施している雰囲気がでてよさそうではあるものの、Organization アカウントを作るために、「アイコン画像」、「ヘッダー画像」、「会社説明文」などを用意する必要があります。
テンプレートとして使えるものがあればよいですが、なければ一から考える必要が出てくるため、ある程度時間の余裕が必要です。

次に、個人アカウントについてです。
前述したように、カレンダーをOrganizationアカウントと紐づけている場合、カレンダーへの記事リンクの紐付けのために各参加者のQiitaアカウントが必要になります。
また、各参加者のQiita アカウントを Organization へ事前に招待する必要もあります。
元々Qiitaアカウントを持っていなかった人はこの機会に作ってもらうなどの対応が必要になるため、意外とここも大変なポイントになります。

下書き環境と公開環境の差分の把握

これはマイナーなケースかもしれませんが、今回のカラパレのアドカレでは、「Notion で下書きを書き、note へコピーして公開する」というフローを取りました。

Notion は普段使っているツールであるというのと、コメント機能もあり記事レビューがしやすいというメリットがありました。
しかし、実際にアドカレが始まり、記事をnote側へコピーした際、2つのツールにできる表現(機能)の差があることに気づきました。

Notion と note では、見出しの階層や表を作れるかなどといった点で差異があり、度々参加者へ note での表現に合わせた修正をお願いすることとなってしまいました。

せっかく書いていただいた記事の構成を変えてもらったり、画像の容量を変更してもらったりなど、細かいところで参加者の時間を奪うこととなり、本当に申し訳ない気持ちでいっぱいでした。

この反省を踏まえ、もし下書きと本番公開を別のツールで行う際は、本番公開用のツールの仕様を事前に調べて、執筆時に加味できるようにしておくと良いと思います。

開始準備には最低でも2か月かかる

前述してきたようなこと以外にも、そもそもの参加者の確保が必要だったり、記事のヘッダー画像はどうするか、Twitterでの告知頻度はどうするかなども考える必要があります。
これらを決め、参加者を集め共有し、いざ実施へ…とやっていると、案外時間がかかるものです。

今回のアドカレでは、自分の提案のタイミングが遅かったこともあり、この準備が1か月もないくらいで進行しましたが、正直時間が足りませんでした。
特に、12/1 と 12/2 の記事を担当された方へはかなりな負担をかけてしまったと思います。

なので、アドカレの準備には最低でも2か月は見ておいた方がいいと思います。
(2回目以降の実施の際は、前回の情報を使えるのでこれより短くできると思います。あくまで初回は考えることが多いので時間がかかるということです)

おわりに

アドカレ運営を初めてやってみての、工夫や反省点について書いてみました。
振り返ってみると、事前に本番公開用のツールの仕様を調べるというのは当たり前でしょ…と思うのですが、なかなかその場では思いつけませんでした。

自分が調べたときは、こういったアドカレ運営に関する知見の記事はあまり見当たらなかったので、この記事が、今後アドカレを初めて実施することになった方のお力になれていたら幸いです。

明日はついに Colorful Palette アドベントカレンダー 最終日ですね！自分と同じくアドカレ運営に携わっているめりささんによる記事です！
いい話な予感がするので、お楽しみに！