inFablic | Fablic, inc. Developer's Blog.

フリマアプリ ラクマを運営する Fablic の公式開発者ブログです。Fablic のデザイナー・エンジニア・ディレクターが情報発信していきます。

自社ブログinFablicを盛り上げる仕組みづくり

こんにちは。shobyです。 今回は、自社ブログinFablicを皆で盛り上げ、記事の執筆数を2年で約4.5倍に増やした仕組みづくりについてご紹介します。

概要

  • 背景
  • 目的の再定義とルールの明文化
  • レビューの任意化と簡易化
  • ご褒美の導入
  • カジュアル投稿の推奨
  • 執筆の直接依頼とサポート

背景

Fablicの自社ブログinFablicは2015年に始まりました。 inFablicという名前には、エンジニアに限らず、あらゆるFablicのメンバーがアウトプットをする場であるという意味が込められています。

in.fablic.co.jp

こちらのinFablic、公開当初は気合の入った良質な記事が定期的に投下されていたのですが、 徐々に投稿頻度が減っていきました。

振り返ると、直接的な原因があったわけではなく、様々な複合的な要素が影響し、頻度の低下が起こったように思えます。

その後、Fablicではアウトプットが得意なメンバーが中心となり、様々な改善を繰り返しながらブログを盛り上げる仕組みづくりをしてきました。

結果として、以下のように毎年、着実に記事の執筆数を伸ばすことができています。

  • 2015年:19記事
  • 2016年:28記事
  • 2017年:86記事

今回は、実際に行った主な取り組みをご紹介します。

目的の再定義とルールの明文化

inFablicというブログの目的を再度定義し直し、曖昧だったルールを明文化した上でQiita Teamで公開しました。 これにより、記事執筆に関する見えない不安を取り除くことができました。*1

具体的には、inFablicが盛り上がって採用に結びつくのがゴールであり、inFablicは「会社の知見」を「社外に共有する」場であるということが明記されました。

また、記事の執筆は業務の一部であり、業務時間を使って書いて良いというルールが明文化されました。

この明文化により、組織としてブログの執筆を推奨し、情報発信力を高めようとする思いがあることがメンバーに伝えられ、執筆に関する心理的なハードルを軽減することができました。

レビューの任意化と簡易化

必須だった記事のレビューを任意化し、レビュー方法も下書きプレビューを共有する方法に簡易化しました。 これによりエンジニアのみに偏りがちだった投稿を他の職種にも広げることができました。*2

inFablicは以前は記事公開にGitHubを使ったレビューが必須でした。 これには、ブログの立ち上げがエンジニアを中心に行われたため、使い慣れたツールでのレビューが採用されたという経緯があります。

この方法は、技術書の編集などではよく使われている方法で、編集履歴もバージョン管理でき、文言等も行レベルで細かく指摘できるため、細かいチェックには優れた方法です。

しかし、ブログでは、そのような細かな指摘は不要です。 会社のブランドイメージを毀損するようなことが書かれていないか、技術的に明らかに間違った内容が書かれていないか、といった最低限のことがチェックできればよく、GitHubの利用と細かな指摘はオーバースペックで、執筆の抵抗感を生む要因の一つになっていました。

そのため、レビューは任意とし、内容が不安な場合には、はてなブログの下書きプレビュー機能を使い、公開前に記事を簡単にレビューしてもらう、という運用に変えました。

これにより、エンジニア以外のメンバーの記事執筆のハードルを下げることができました。

ご褒美の導入

多くのシェアを集めた記事を書いた人には、賞賛とご褒美が与えられる仕組みが作られました。 これにより、記事執筆のきっかけとなる緩やかな外発的モチベーションが作られました。*3

ブログを書くことに対して報酬が与えられるのは賛否両論があると思いますが、Fablicではこの制度はうまく機能しています。

ご褒美の判定基準となるシェア数は、閾値が厳しめに設定されているため、読み手に需要があり、良い記事を書かなければ達成できません。 そのため、報酬欲しさに内容の薄い記事を書いても意味がなく、より良い記事を書こうと努力する人に報酬が与えられるようになっています。

そのような記事が出た場合には、週次の振り返りミーティングでご褒美の贈呈式が行われ、盛大に祝われるため、 本人も周囲もブログを書くモチベーションが生まれるようになっています。

カジュアル投稿の推奨

一部のメンバーが中心となり、率先してカジュアルな投稿を繰り返すことで、カジュアル投稿を推奨し、投稿に関する敷居を下げました。

例えば「気軽に投稿しても良いよ」と言われても、実際に気軽に投稿するのはなかなか勇気がいる行動です。 そのため、実際に一部のメンバーがカジュアルに記事を投稿するという行動で示すことにより、記事執筆の敷居を下げていきました。*4

具体的な例として、勉強会の参加レポートなども積極的に公開するようになりました。

in.fablic.co.jp

これにより投稿の敷居が下がり、社内で「それinFablicに書いてみたらどう?」といった会話が生まれるようになりました。

執筆の直接依頼とサポート

Advent Calendarなどの機会を利用し、記事を執筆したことがないメンバーに記事の執筆を直接依頼しました。 また、記事を書く際のコツを伝えるなど、直接サポートを行いました。*5

inFablicは特定の職種に限らず、Fablicのメンバーが記事を書くためのブログとして運用されていますが、 どうしても記事を書きなれているエンジニアやデザイナーの記事が集中するようになってきました。

そのため、Advent Calendarという機会を利用し、まだ記事を執筆したことがないメンバーに直接口頭で依頼をするようにしました。 また、記事執筆に関するサポートを行い、初めての記事公開までの手順をお手伝いしました。

結果として、Fablic Advent Calendarでは、全社を巻き込み、エンジニア、デザイナー、人事、総務、CS、ファウンダーというバラエティ豊かな顔ぶれで記事執筆を行うことができました。

qiita.com

まとめ

Fablicでは、自社ブログであるinFablicを盛り上げるべく、様々な改善を行ってきました。

目的の再定義とルールの明文化を行い、組織としてブログの執筆を推奨することを伝え、 レビューの任意化と簡易化を行い、エンジニア以外の投稿に関するハードルを下げ、 ご褒美の導入により、良い記事を執筆する外的なモチベーションを作り、 カジュアル投稿を推奨することで、投稿の敷居を下げ、 執筆の直接依頼とサポートをすることで、新しいメンバーに記事を投稿してもらいました。

これからのinFablicの投稿にぜひご期待ください。

*1:こちらはwariemonが中心となって行われた取り組みです。

*2:こちらはtakejuneが中心となって行われた取り組みです。

*3:こちらはyutadayoが中心となって行われた取り組みです。

*4:こちらはshobytommyが中心となって行われた取り組みです。

*5:こちらはshobyが中心となって行われた取り組みです。