技術ブログを(だいたい)1年続けた背景と成果

このドワンゴ教育サービス開発者ブログを開設してから2年が経ちました。 特に2021年3月からおよそ1年の間、技術ブログの運用体制を整え、定期的に記事を投稿してきました。

この記事では、技術ブログ運用の背景と現在の運用体制、成果と課題についてまとめます。

背景:教育事業の成長のために

私達は教育を生業とすることもあり、学習や知見の共有は大事な業務のひとつです。 そのような活動の場のひとつとして技術ブログを開設していましたが、有志の手によって不定期に更新される程度で、効果的に活用できていませんでした。

そのような中で、さらなる事業成長のために組織の拡大とエンジニア採用が重要な課題となりました。 教育事業はN高等学校・S高等学校が順調に生徒数を伸ばしており、今後会社の中心的な事業の柱となることが期待されています。 採用背景の詳細は過去の記事をご覧ください。

エンジニア採用にあたって私達が抱えていた課題のひとつは、教育事業の知名度の低さです。 ドワンゴはニコニコ動画やニコニコ生放送といったニコニコサービスの事業主体としてご存知の方が多いです。 N高のことを知らない方や、N高のことは知っていてもそれにドワンゴが関わっていることはご存知ない方とお会いすることが度々ありました。

こういった状況の原因のひとつは、そもそも私達からの情報発信が少ないことでした。 技術ブログの更新頻度は少なく、その他の情報発信も取り組めていなかったのでやむをえない結果です。 採用活動をしているかどうか以前に、ドワンゴが教育事業においてアプリケーション開発していることを認知できる機会が非常に限られていました。

エンジニア採用においてエンジニア主体で情報を発信し教育事業と採用活動について広く知ってもらうため、そして積極的に知見を共有してより社会やコミュニティに貢献するために、技術ブログを組織的に運用していくことに決めました。 そのために、運用体制の構築と定期的な記事更新を目標に掲げました。

運用:編集部体制の構築

定期的な記事更新のため、技術ブログ編集部を立ち上げました。 技術ブログ編集部は執筆フローの設定や執筆サポートを役割としています。 記事更新の頻度は、編集部立ち上げ当初は月1回としていましたが、その後運用が軌道に乗ったことから現在は月2回を目標としています。

執筆フロー

技術ブログの現在の執筆フローは次のとおりです。

  1. 執筆者のアサインとテーマの決定(1週間)
  2. 記事構成・目次の作成(1週間)
  3. 初稿の作成(2週間)
  4. 完成稿の作成(1週間)
  5. 社内公開と公開日の調整(1週間)
  6. 公開

1つの記事を執筆するのに6週間のスケジュールを標準としています。 といっても、6週間丸々を執筆に使えるわけではなく、主業務と並行しての執筆になるため、余裕があるというほどではありません。 もちろん、執筆することが決まったら業務の調整など組織としては配慮します。

執筆者のアサインとテーマの決定

最初に、執筆者とテーマを決定します。 執筆者を先に決めるよりは、テーマを先に決めてそれに合わせて執筆してもらうことが多いです。

テーマは GitHub の issue で管理しています。 自薦他薦問わず、このテーマはおもしろい取り組みで記事になりそうと感じたものは issue にしています。

執筆者は週1回の定例に招待されます。 そこで編集部からの進捗確認や投稿した内容のレビューを受けます。 締切とそれを意識させる存在というのは大事で、編集部の大きな仕事です。

定例では GitHub Project を見ながら進捗を確認します。

進捗管理
進捗管理

記事構成・目次の作成

最初に、記事構成や目次を作成します。 いきなり原稿本体にとりかかると、論理構成や話の流れに指摘が入ったときの手戻りが大きいです。 この段階で全体の構造の合意をとり、後から大きな手戻りが発生しないようにします。

具体的には、この記事の記事構成はこのような形でした。 この後で、課題や今後の展望についても記載する旨のレビューを受けて、その後の作業に続いています。

この記事の初期記事構成・目次
この記事の初期記事構成・目次

エンジニアが記事を書く場合には、この記事構成・目次の作成のタイミングで PR ベースでの作業に移ります。 普段の業務と変わらない、 Markdown の差分を見ながらのコミュニケーションです。

一方、 git に親しくないメンバーが記事を執筆する場合には、Google Docs を利用しています。 Google Docs の提案モードを活用することで修正提案やレビューコメントをつけられます。 全体の流れや方針は issue 上でコミュニケーションしつつ、具体的な箇所は Google Docs 上で議論します。

初稿の作成

初稿では、記事構成や目次を具体的な文章に落とし込みます。 基本的にこの段階で文章自体はできあがります。 画像リソースの挿入であったり、議論中の内容に基づく文章は完成稿を待つことになります。

この初稿を書く段階に最も時間がかかりますので、スケジュール上も2週間を確保しています。 全体の流れは記事構成・目次を作成する段階で合意済みですが、執筆中に話の流れ上記事構成を一部変更することもあります。 また、具体的な文章がでることで詳細な部分の表現や流れをレビューできるようになります。 レビューやその対応にもまとまった時間がかかります。 初稿作成以後、レビュー対応を繰り返して文章をブラッシュアップします。

完成稿の作成

完成稿の作成では、コンテンツ自体は外部に公開しても問題ない程度に記事を仕上げます。 基本的に文章自体は初稿の作成以後のレビューを通していますので、画像の挿入や文章とのバランスなどが検討されます。

完成稿に近づいてきたら、技術ブログ上で公開するための下書き記事を作ります。 このブログははてなブログを利用していますので、その下書き機能を利用します。 基本的には文章や画像を流し込むだけですが、文章のヘディングやキャプション、OGPといった流し込み後に修正される部分もあります。

社内公開と公開日の調整

完成稿ができたら、記事公開に向けた前段階として、社内公開と公開日の調整をします。 社内公開は下書き記事を部内に共有しています。 記事執筆のフローは社内で完全にオープンではありますが、自分が直接関与しない記事の進捗詳細を普段の業務の傍らでキャッチアップするのは難しいです。 このタイミングでいつごろどんな記事が公開されるかを周知しています。

公開日には、火曜または水曜の11時を選ぶことが多いです。 水曜が編集部の定例がある都合上、水曜か前日の火曜を選んでいます。 前日の火曜に公開できた場合には、水曜の定例で反響を確認できます。 時間帯を11時としている理由は、お昼前後のタイミングでアクセス数が増えるためです。 この判断にはZOZO社の記事も参考にさせていただきました。 日時を決めたら予約投稿を設定しておきます。

公開

予約投稿が無事機能して公開後、最後にいくつかの作業があります。

まず、社内全体での記事共有をします。 記事公開前は部内限定でしたが、このタイミングで全社に告知します。 ドワンゴには #engineer という「エンジニア的な人たちが話をする場所」(チャンネルtopicより)があります。 多くのエンジニアがこのチャンネルにいるため、ここで告知しています。

記事公開の社内告知
記事公開の社内告知

社内全体での記事を共有することで、全社的にも教育事業を知ってもらうこともできます。 ドワンゴは大きな企業で、事業部をまたぐと現場レベルでどんなことをやっているかというのはどうしてもお互い見えづらくなります。 教育事業について知ってもらうためのひとつの、身近な窓口として記事を共有しています。

記事の公開後、最初の編集部定例で記事の反響を確認します。 具体的には記事のはてブ数やアクセス数、カジュアル面談や採用ページへの流入数です。 この確認と感想をもって執筆作業は終了となり、定例からも抜けます。

成果

採用での成果

技術ブログの採用面での成果として、第一に、技術ブログでの記事から採用に繋がった事例ができました。 エンジニア採用には様々なアプローチ手法がある中で、具体的な実績として事例ができたことは、今後の長期的な運営の継続にあたってもとても大きなことです。

第二に、直接は採用に繋がらないまでも、事前の情報収集に活用いただけています。 カジュアル面談の際にも、事前に教育事業について知っていただいている方が増えました。 技術ブログ以外の媒体では、Wantedly で情報発信しているため、そちらを読んでくださっている方が多いです。 当初の情報発信としての目的にも貢献できています。

第三に、技術ブログ以外の採用広報においても活用できるようになりました。 例えば、カジュアル面談の際に事例紹介や疑問への回答として記事を紹介しています。 それ以外にも広報の場で記事にまとめた内容を中心としてお伝えできるようになりました。

総じて、1年の活動を通じて一定の成果を残すことができました。

副次的な効果

技術ブログには採用以外の面でも副次的な効果が生まれました。 それは部内・全社の情報共有に活用できることです。

部内向けには、記事をオンボーディング資料や歴史を知る資料として活用できました。 もちろんオンボーディング資料はあったのですが、対外向けの資料としてまとめられたブログ記事で補完できるところもありました。

全社的には、前述のとおり事業部をまたいだ活動の共有ができました。 現場レベルの取り組みの共有手段のひとつとして、今後も活用していきます。

課題と今後の展望

技術ブログの今後の課題は、第一に、継続的に記事を提供するためのテーマを選定する仕組みづくりです。 現状は「気付いた人が issue にする」という気付けるかどうかにかかったテーマ選定になってしまっています。 各チームで日々様々に技術的な取り組みをしていて、テーマの種はあるはずです。 それをうまく技術ブログのテーマとして昇華、選定できるようにレールを敷くことで、不安定さを解消していきたいです。

第二に、執筆者の拡大です。 記事を書くことは、執筆者自身にも成長の機会があります。 というのも対外的な記事を書くにあたっては関連する取り組みや正確な情報の調査が必要になるためです。 論文執筆というと大げさかもしれませんが、それに類する作業を通じて能力を獲得できます。 広く多くの人に記事を書いてもらうことで成長のひとつの機会にしてもらいたいです。

私は教育事業に携わるエンジニアとして、ドワンゴ教育事業は自身の技術的な研鑽だけでなくコミュニティの成長にも貢献できるような組織でありたいと考えています。 前述の課題の解決も通じて、定常的かつ安定的に情報発信できるような体制を構築していきます。

We are hiring!

株式会社ドワンゴの教育事業では、一緒に未来の当たり前の教育をつくり技術知見をコミュニティに還元するメンバーを募集しています。 カジュアル面談も行っています。 お気軽にご連絡ください!

カジュアル面談応募フォームはこちら

www.nnn.ed.nico

開発チームの取り組み、教育事業の今後については、他の記事や採用資料をご覧ください。

speakerdeck.com