フォルシアの技術広報チームではこれまで、自社エンジニアが社内外へ発信しやすい環境を作るため、試行錯誤を繰り返してきました。
今回はその中でも、「企業の技術ブログを無理なく継続的に続けていくための仕組み」 について、現時点で私たちがベストプラクティスだと感じている方法を記事にしました。
「会社で技術ブログを運営しているが、なかなか執筆してくれる人がいない」「同僚・チームメンバーにももっと発信してほしい」と感じているエンジニアや広報の方にとって、なにかひとつでも参考になれば幸いです。
フォルシアの技術記事
フォルシアでは月2～3本の技術記事を継続して公開しています。
（2023/03よりZennのpublicationで、それ以前は自社ブログFORCIA CUBEにて公開してきました）
エンジニアは全体で約60名おり、その中の有志が記事を執筆しています。記事の内容には特に縛りはなく、執筆者の興味関心に委ねられています。
- 最近気になっている技術を触ってみた
- 使っている技術・フレームワークの紹介
- 具体的なTipsや課題解決の実例
- 技術教育・勉強方法
- 開発フロー・チームビルディングetc
継続するためのコツ
さて、記事を書くのは思いのほか労力がかかります。アウトプットのメリットはたくさんありますが、それがわかっていても大変なものは大変ですよね。
ましてや、企業の技術ブログとして発信するとなると、公開までのステップが増えてしまいがちです。
また、企画の運営は有志の技術広報チームが担っており、業務負荷によってはほとんどリソースが割けない時期もあります。
広報はその性質上、地道に長く続けていくことが重要ですが、有志のメンバーの馬力「だけ」に頼ってしまうと、その活動が途絶えてしまいかねません。
そこでたどり着いたコンセプトは、「月15分、みんなで技術広報」 です。
「無理なく」「無駄なく」続けるために、減らせるコストを減らした上で「これぐらいならできるかな」という協力を多くの人からいただくことで、特定個人に頼りすぎない持続可能な発信を続けることを目指しています。
ここからは、そのための具体的な方策を4つ、ご紹介します。
1. 執筆フローの自動化
フォルシアでは、記事管理用のGitリポジトリを用意しており、以下のような流れを経て公開されます。
- 執筆者がローカルで執筆し、GitLabにpushしてMerge Request(MR。GitHubでいうPull Request)を作成
- CIで執筆ブランチがプレビュー環境に自動でデプロイされる
- textlint + Reviewdogにより自動で日本語校正（詳細は以前こちらの記事で紹介）
- レビュー会(後述)で、MRに対してコメント
- コメントを受けて修正し、masterブランチへマージ
- Zennへの連携用GitHubリポジトリへミラーリング
- Zennの連携機能により、公開日になると自動公開
この流れで執筆者が行うことは、「アウトプットをGitLabに置いてレビューをもらい、修正してマージする」ことです。
つまり、執筆作業を普段の開発環境/フローと同じインターフェースで行うことができます。ブログ専用のファイルを作ったり、社内チェックを受けるために別のツールを使ったりする必要もありません。
また運営面においても、GitLabのカンバンボードによる記事のステータス管理、GitLab CIの活用やZennとの連携によって、定常コストを軽減できています。ひとつの記事について削減できる手間は小さいものですが、長い目で見ると馬鹿にならないものです。（ZennのGitHub連携機能にはとても助けられています！ありがとうございます！）
こうした自動化は、エンジニア自身が技術広報に携わるメリットでもありますよね。
2. 月刊企画（アドベントカレンダーの年間化）
フォルシアではもともとアドベントカレンダー(12月に毎日持ち回りで記事を書く)企画を行っていました。アドベントカレンダーは技術記事が大幅に増えるというメリットがあるほか、執筆への心理的なハードル低下や、お祭り感・一体感の醸成にも寄与していました。
一方で、アドベントカレンダー企画には以下のような課題がありました。
- 技術記事が12月に集中し、それ以外の時期が極端に減ってしまう
- ブログにアクセスするユーザーから見ると、ほとんどの時期では技術記事の更新頻度が低く見える
- 12月に業務が忙しくなる人は書く余裕がない
- (技術広報の)運営負荷が高い
- 締切管理や校正が一時期に集中
- 埋まり切らなかった枠を埋めるために記事ネタを考えて執筆を打診する
- 有志でレビューしてもらおうにも人が集まらず、結局運営メンバーで技術レビューするケースも
そこで、2022年からは思い切ってアドベントカレンダー企画を廃止しました。そしてそれに代わる企画として、「月刊企画」と称して記事の枠を1年に分散するようにしました。
毎月2枠を作っておき、アドベントカレンダーと同様に、書きたい時期の枠に名前を埋めてもらうスタイルを取っています。企画枠は以下のようなイメージです。
| 枠 | 名前 | 内容 | 執筆締切 |
|---|---|---|---|
| 4月① | Kさん | SREユニットの紹介 | 4/11 |
| 4月② | Tさん | フォルシアのDBへのこだわり | 4/11 |
| 5月① | Hさん | Next関連のなにかかく | 5/9 |
| 5月② | Kさん | なにかかく | 5/9 |
| 6月① | 6/6 | ||
| ... | ... | ... | ... |
「月刊企画」によって、以下のようなメリットを得ることができています。
- 技術記事の発信頻度を恒常的に高く保つ
- 12月集中からの脱却
- 枠を作ってあらかじめ埋めることで、完全に任意とするよりも安定して発信できる
- 執筆者は好きなタイミングを選んで執筆ができる
- 運営負荷の時期的な分散
- （アドベントカレンダー同様に）枠を取ってしまうことで、後回しにしがちなアウトプットに期限を設けて締切効果を得る
3. ユニットリレー企画
さらに、月刊企画のサブ企画として、今年は「ユニットリレー」を実施しています。
技術のユニット(組織図上の最小単位)で持ち回りで記事を書いていくという企画ですが、本質は 「チームでの執筆」 という点です。
最大の狙いは「記事のテーマを考える」というタスクの負荷分散です。
以前社内のエンジニアにとった技術ブログに関するアンケートでも、「なにを書いてよいかわからない」「外部に発信できるような内容が思いつかない」という意見が一定数ありました。
しかし実際には、傍目に見るととても勉強になることをやっているにも関わらず、本人にはそんな認識はないというケースも多々あります。チーム内でブレストしてアイディアを持ち寄ったり、ひとりでは拾えなかったネタを拾ったりすることで、少しでもテーマ選びがやりやすくなればと考えています。
また、今年はユニット持ち回りで社内LTを行う「ニクの日」という企画も実施されており、そのLT内容を書き起こして記事にしてもらう"省エネ"も社内には推奨しています。
その他にも、アドベントカレンダーに代わるイベント感の醸成や、執筆を「チームのタスクのひとつ」として捉えてもらうことで、「レビュー会(後述)に加えてユニットメンバーに重点的にレビューしてもらえる」「個人で書くよりもリソース面で考慮してもらいやすくなる」「チームへのオンボーディングに活用できる資産化」といった副次効果もひっそりと期待しています。
4. 全エンジニアによるレビュー会
個人で書く技術ブログとは異なり、企業が運営するブログでは「社外公開に問題がないか・機密情報が含まれないか」「技術的な誤りが含まれていないか」などのチェックが必要です。
こうした公開判断や品質担保に協力してくれる人を募るのも、記事の募集と同じくらい大変です。
フォルシアでは週1回1時間、全エンジニアが集うtechミーティングがあります。
これは各自が業務での経験などを持ち寄って知見を共有するための会なのですが、書きあがった技術記事があるときはこのミーティングの時間を10分ほどもらい、記事のレビュー会を実施しています。
目的は、品質担保の負荷分散と記事へのフィードバックの充実化です。
レビュー会の設計上のこだわりは
- 「技術ブログのためにわざわざ集まる」のではなく、すでにある場を借りることで、参加の手間を減らす（会議にそのまま残るだけで参加できる）
- レビュワーが記事を読む時間もレビュー会の中で取ることで、自分で時間を見つけて読む手間を減らす
- 一方で、いたずらに時間が伸びると参加が負担になってしまうため、必要最小限の時間設定を心がける
- 記事がMR形式で出されるので、普段のコードレビューと同じインターフェースでレビューできる
- 「指摘」に限らず「感想」コメントも歓迎し、「思いつかなければ👍を押してください！」とすることでフィードバックへのハードルを下げる
- 広報への貢献を認知してもらえる&記事への反応を多く受け取ることができ、執筆者のモチベートにもつながる
寄せられる感想の例
Dockerの記事にはクジラがついていました（かわいい）
ポイントは、「敷居を低くして、参加のハードルを徹底的に下げること」 です。
「アドベントカレンダーのレビューしてもらえませんか？」と言われて手を挙げるのはちょっと億劫でも、「いつもの会議のラスト10分で、公開前の記事を読んでスタンプ押してもらえませんか？」だと「やってもいいかな」という気になりますよね。
実際に、運用開始後の社内でのアンケートでも
「多くのエンジニアが参加する場でのレビュー会で、多種多様なフィードバックを受けられて有意義でした」
「これまで新着記事の社内告知を見落とすこともあったが、techミーティングで読む時間が設けられたことで、普段なかなかかかわらない技術を知る機会ができた」
「記事に多くの関心が集まり、たくさんのレビューをもらえて嬉しかったです」
「みんなで参加している感覚がとても良い」
といったポジティブな反応をたくさんもらえています。
まとめ・「みんなで続ける技術ブログ」
フォルシアでは継続的に技術記事を発信するため、執筆者の負担を「みんなで分担する」仕組みを構築してきました。
具体策として、執筆フローの自動化/定型化、月刊企画、ユニットリレー企画、全エンジニアによるレビュー会の4つをご紹介しました。
これによって、以下のような環境づくりを目指しています。
- 「ブログのためだけの作業」を減らす
- 恒常的に記事を発信する枠組みを作り、組織として習慣化する
- 記事になりそうなアイディアをチームで考える
- レビューに参加しやすい環境を整え、品質担保しつつフィードバックを増やす
結果的に「技術記事をきっかけにフォルシアを知り応募しました」という例もこのところ増えてきています。
一方で、レビュー会の時間設定や社外からのFBの集め方、執筆そのものの負荷軽減など、まだまだ課題も感じています。
「企業の技術ブログとして、量と質の両方を保ちながら発信を続ける」という難しい命題に、技術広報チームではこれからも粘り強く向き合い、地道に気長に改善を続けていきます。
フォルシアの技術広報については、以下の記事でも紹介しているのでよければぜひご覧ください。
この記事を書いた人
谷井 嶺太
新卒5年目エンジニア。自社SaaSプロダクト「webコネクト」の改善開発を担う。
2019年の発足当初より技術広報チームに参加し企画・運営を担当、昨年より同チームリーダー。
最近はハイラル王国でひたすら洞窟と井戸を探しています。
Discussion