LoginSignup
0
0

初めてアドベントカレンダーを運営してみた感想

Last updated at Posted at 2024-01-13

私が所属している Kyash 社では2019年から毎年アドベントカレンダーを開催していて、2023年も無事に完了しました。

カレンダーの作成者が私になっていることから分かるように、2023年のアドベントカレンダーは私が運営していました。

この記事では、運営した感想として以下のことを話します。

  • 経緯
  • 運営を担当した理由
  • 25枠を埋める
  • 遅延無く記事をレビューし公開する
  • 費用対効果を考える
  • 今後の予定

経緯

2023年4月に Android エンジニアとして入社して7ヶ月目 - 10月下旬のある日、私は気がつきました。

弊社は毎年アドベントカレンダーをやっているが、今年はやるべきだろうか。

会社の発信活動は採用文脈で行われることが多いと思います。しかし会社の状況は VPoE Konifar のこちらの記事から引用すると

事業と開発組織の状況を鑑みて一時的に正社員の採用から業務委託の追加に方針変更をしました。

とあるようにエンジニアの正社員採用のヘッドカウントがほぼ無い状況です。

そのときの上司も Konifar だったので 1on1 で聞いてみたところ

  • 長期的に採用を止めるわけではない
  • 発信活動はメンバーの自信につながる

といった理由でやりましょうという話になり、私がその運営に立候補して、その場で実施が決まりました。

運営を担当した理由

前職に居たときからアドベントカレンダーをやってみたかったからです。しかし前職は比較的小規模な開発組織だっため、25枠を埋めることは無理と考え、特に提案などは行いませんでした。

ところでその前職ですが、今年は全7枠の開始日を12月19日とし、それを1日目と呼んで運営していました。

私は柔軟性が足りなかったです。

25枠を埋める

2023年のアドベントカレンダーでは私が3枠担当したり、2枠担当が4人居ることから分かるように、25枠埋めることは困難がありました。

25枠埋めることが困難だった理由

2022年のアドベントカレンダーは1人1枠で25枠を埋めていました。今回それが出来なかった理由としては、採用文脈の弱さから理由付けが弱いというのもありますが、前回執筆者の半数以上が退職済みというのもあります。また Konifar の記事から引用すると、

実は事業状況の変化もあり退職が続いてしまうことがありました。

という状況です。去年やって頂いたので今年もお願いしますだけでは半分も埋まりません。
一方、私のように2023年に入社した人も居ます。その結果、ある時点では社員のエンジニアが全員1記事執筆すれば25枠をギリギリ埋められる状況でした。

業務委託の方の参加、1人2記事の提案

「社員のエンジニアが全員参加しないと枠が埋まらない。業務委託の方の参加があればその限りでは無い」とグループメンションでぼやいたところ、業務委託の方に2名参加して頂きました。また、埋まらなかったら2記事書くと言ってくれた先輩も居て、必ずしも1人1記事である必要は無いことに気がつきました。この件についても私は柔軟性が足りなかったです。

偉い人枠

次に困難では無かった偉い人枠を紹介します。
2019年からの伝統として25日と24日はプロダクト部門から見て No.1, No.2 の人が担当します。今年は社長と事業責任者になります。
適切な話の持って行き方は VPoE Konifar が教えてくれたため、その通りにお願いして、すんなり担当して頂きました。

参加者の集まり方

全社チャンネル、グループメンション、個別メンションの順番で執筆者を募りました。

その結果、以下の内訳で19人に参加して頂きました。

参加経緯 人数
全社チャンネル、グループメンションで参加 10人
個別メンションで参加 7人
偉い人 2人

職種の内訳はこうなりました。

職種 人数
エンジニア 13人
PdM 3人
デザイナー 1人
偉い人 2人

個別メンションの内容

アドベントカレンダーへの参加をお願いする個別のメンションは、その時点で参加していないエンジニアの社員全員に送りました。このように記事の例の提案も含めました。


お疲れさまです。アドベントカレンダーが11枠開いているのですが昨年と同様に参加して頂けると嬉しいです。

記事の例

  • Autify やめました 1 2
  • サーバサイド開発環境を EC2 3 から近年の Docker の性能改善を踏まえて Docker Compose に移行しています

結果として Docker Compose によるサーバサイド開発環境の記事を書いて頂けました。


お疲れさまです。最近どうですか。というのも、アドベントカレンダーに参加して頂けると嬉しいのですが、omotani=san についてはこの記事を書くのがよいと思います的な話が思い浮かばないです。Payment チームに異動したといってもNDA関連があって書けることが少なそうな気がしています。EMについても内情が特殊 4 で書きにくいような気がしています。もし何か書けることが思いついたらお願いしたいです


結果として EM と全銀フォーマットの記事を書いて頂けました。

社歴1年未満でエンジニア全員のことを知っているわけでは無いので、以下の情報源から各メンバーの担当やバックグラウンドを調べた上で行いました。

  • 組織図
  • 社内ポータルの自己紹介記事
  • 私の所属部署(Mobile)の先輩へのヒアリング

この活動は丁寧な対応だったという感想を諸先輩方から頂きました。

遅延無く記事をレビューし公開する

アドベントカレンダーなので期日までに記事を公開する必要があります。
また弊社公式の発信ということになるので、2回のレビューが必要です。

  • 1次レビューは部署内のレビューで、技術的な正しさや誤字脱字を確認する。
  • 2次レビューはPR担当のレビューで、主に会社的に問題が無いかを確認する。

PR担当の方に相談したところ、1人しか居なくて前日の依頼は困るとのことでしたので、3営業日前までに1次レビューを完了して2次レビューを依頼するように執筆者に案内しました。

しかし3営業日前になっても1次レビューが行われていないケースがあり、その人にリマインダーを送ったり、間に合わなそうならば、早めに2次レビューを完了した人と担当日を入れ替えたりして対応しました。

私の反省点としてはリマインダーが遅れて、PR担当への2次レビュー依頼が前日になってしまうことがあったため、Google カレンダーや Slack の使い方を工夫する必要があると思いました。

採用チーム X アカウントの運用

公開された記事は株式会社Kyash 採用チーム X アカウントで紹介しましたが、それも中の人は私で、140文字に収まる要約文を私が考えていました。

費用対効果を考える

大層なセクション名を付けてみましたが、何円かけたら何人採用できたという数字を出す話ではなく、やって良かったかぐらいの話です。

今回のアドベントカレンダーの運営は参加者集めやレビュー、リマインダーなどにある程度時間をかけています(厳密には計測してない)。その結果、ユーザーから見える新機能や機能改善の開発が遅れることはありませんでしたが、技術的負債の解消などコードベースの改善活動 5 の進行はスローになっていました。また参加者も執筆に時間を使っています。専門業務型裁量労働制なので、それで残業代が増えることは無いですが、本来の開発の時間を削ったかもしれません。

いったんは上司良ければすべて良しの精神で運営していましたが、この記事ではそれとは独立して費用対効果を考えてみます。

採用への効果

2024年にエンジニアのヘッドカウントが増えれば費用対効果は十分と考えます。私がこれまで2度転職した感想として、発信が多い会社はそこで働くイメージが沸きやすく入社に際しての安心度が高いです。Kyash 社についてはこの辺の情報をほぼリアルタイムに仕入れていたので、昔からよく知っている会社という認識での入社でした。

また先輩からは PdM とデザイナーの合計4人が執筆したことで自社サービスらしさが出て良いという感想を頂きました。

執筆を通した技術力向上

ある執筆者からは執筆を通して対象技術について理解がより深まったという感想を頂きました。確かに私も記事を書くときは間違いがあると大変なので、できる限り公式の資料で裏付けしたりなどして、よく調べます。話は少しそれますが、それが登壇となると質疑応答もあるので、想定される質問への回答を事前に準備するために、さらに調べます。執筆を通した技術力向上はプロダクトの品質やユーザ体験の向上につながるため、やって良かったと考えます。

他部署に対して理解を深める

他部署や他プロジェクトの人が何を考えてどのような仕事をしているかを、アドベントカレンダーの記事を通して理解が深まったという感想を頂きました。確かに私も担当外のプロジェクトである Kyash コインや組織図的に遠いセキュリティマネジメント、コーポレートエンジニアについても記事を通して理解を深めることができました。

他部署や他プロジェクトを理解したからと言って、それが直接、生産性や品質につながるわけでは無いと思いますが、全社集会や年度末パーティーで Kyash メンバーが集合した時には会話のネタになり、微力ながら Kyash の行動指針である One Team の醸成に貢献できたと考えます。

今後の予定

2023年は3枠担当1人、2枠担当4人でどうにか25枠を埋めることができ、2019年からの伝統は守りました。しかし2020年から2022年は1人1記事で25枠を埋めていたので2020年からの伝統は破壊してしまいました。やっぱり1人1記事の方が多くの人が活躍している感じがして採用におけるイメージが良いと思います。しかし前節で紹介した通り、グループメンションでアドベントカレンダーに参加しなかった社員のエンジニア全員に個別に参加お願いのメンションを送りましたが、15人中9人には参加して頂けなかったです。

ネタ帳 Slack チャンネルの運営

2024年も実施し私が運営するとは限りませんが、できだけ多くの方に参加して頂けるようにと考えています。前提として発信活動に興味ない人を無理矢理巻き込むことは考えないです。主にネタ切れをケアしようと考えています。私もネタ切れで Qiita 投稿の間が開くことがあります。

そのために上司との1on1でも話し合いましたが、発信のネタを投稿し、議論する専用の Slack チャンネルを開設、運営しようと考えています。アドベントカレンダーや採用ヘッドカウントの追加などで発信の必要性が増したときに、過去投稿からネタをピックできるようなものを考えています。今後、上手くワークしたか否かなど、適当なタイミングで経過を報告できればと考えています。

まとめ

この記事では過去4回アドベントカレンダーを開催している会社に入社して7ヶ月で、始めてアドベントカレンダーを運営してみた感想を紹介しました。先人が残した資料や Konifar をはじめとした諸先輩方の助言のおかげで無事に完走することができました。2022年のアドベントカレンダーとは状況が異なり25枠を埋めることは困難がありましたが、個別メンションで記事の例を付けてお願いして、最後は私が3枠担当しつつ他の参加者には2枠担当することをお願いするというパワープレイで乗り切りました。そして担当が決まったら適時リマインダーを送り無事に完了させることができました。採用ヘッドカウントが増えないことには採用への効果は分かりませんが、発信を通した技術力向上はプロダクトの品質とユーザ体験に寄与すると思います。

  1. Autify for Mobile をやめた経緯は Konifar の記事にあります。私は Autify のことを応援しています。UI 操作によるリグレッションテストの自動化には関心があり、前職では MagicPod と比較検討したり営業の方と話したりしました。

  2. タイトルの元ネタは DroidKaigi 2023 の「Material 3 やめました」です。

  3. ローカル開発環境をAWSへ移行して爆速にした

  4. 「内情が特殊」とは EM の記事を引用すると 評価制度の見直しが入り の部分を指しています。

  5. 弊社内では Mobile Klean と呼ばれています。語源は Kyash + Clean (たぶん)

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0