Tech Blogの体制

オールアバウトTech Blogは、開発部内でTech Blog編集部を立ち上げて運営をしています。
現在メンバーは3人で全員エンジニアです。
他社様の運営の話を聞いてみると人事や広報の方がメンバーとして入っていることもあるようなのですが
オールアバウトのTech Blogは運営メンバーが全員エンジニアです。
Tech Blogの編集メンバーは主業務の他に持ち回りで記事の校正やネタ出し、執筆依頼など運営作業を行っています。
編集部を立ち上げた理由としては以下になります。

Tech Blogは会社の名前を出していることもあり記事の質を担保したかった。
業務で使用している技術でどんなことがブログに掲載できるのか、どんなネタを書けばいいのか。という点はエンジニアでないと難しい。
ブログを作ったので自由に記事を書いて公開して下さい。という形式だと、なかなかネタが出ず長続きがしない。

編集会議

2週間に1回、30分程度編集会議を行っています。編集会議では

前回投稿した記事のKPI確認
ブログのネタ出し
持ち込みネタのチェック

を行っています。
KPIに関してはGoogle Analyticsを使用してPV数を取得しています。
ブログのネタ出しに関しては、外部公開が出来そうなネタや流行りそうなネタを整理して、
実際に業務で使用した人や得意な人にお願いして執筆してもらっています。
ネタ出しを編集部が行うことで会社として取り組んでいる技術を打ち出すことができます。
また、あまり自信がない人でも編集部からプッシュすることで自信をもって書いてもらうことができています。
基本的には編集部から依頼して執筆をしている形になるのですが、
公募制でこういう記事を書きたいという人からのネタに関してもチェックをしています。

記事の書き方

オールアバウトTech Blogでは、各自好きなMarkDown Editorを使用してMarkDownで執筆を行ってもらっています。
記事を書く際には、outline draft publishの3ステップで行っています。

outlineステップ

outlineステップではどのような記事を書いていくか見出しを作ってもらっています。
タイトルを頂いただけでは執筆者と編集者の間で認識のズレが生じてしまいます。
outlineで見出しを作ってもらうことで認識ズレがないようにしました。

draftステップ

draftステップでは公開前の記事本文のチェックをしています。
werckerというCIツールでcommit毎に自動でtextlintを実行し、細かい"てにをは"や表記ゆれのチェックをしなくても大丈夫なように行っています。
werckerはコンテナベースなので、textlintを使えるように準備したDockerImageをGoogle Container RegistryにPushして、それを使うようにしています。
wercker.yamlにdraftディレクトリに入っている.mdファイルのみtextlintをかけるようにしているため、 draft記事がtextlintかけられる事になります。図に示すと以下のようになります。
f:id:allabout-techblog:20161116122607p:plain

書いた文章がルールに従っていないと以下の用に警告がでます、

f:id:allabout-techblog:20161109121253p:plain

ルールにはWEB+DB PRESSで使われている用語に合わせるルールと、JTF日本語標準スタイルガイドを一部カスタマイズして使用しています。

github.com github.com

werckerに関しての詳しい説明は過去の記事をごらんください。

allabout-tech.hatenablog.com

また、ブログガイドラインを作成しガイドラインを守るように執筆してもらうことで執筆者・編集者の負担を減らしています。
ブログ開設直後はブログガイドラインが無いためどう書けばいいかわからず執筆者の負担となっていました。
編集者も主業務があるためなかなかチェックが出来ず双方の負担となっていました。
outlineで見出しを書くこととブログガイドラインを作成することで両者ともに負担が少なく執筆・編集作業ができています。

publishステップ

publishステップでは、執筆した内容をはてなブログにコピーして公開作業を行っています。

はてなブログの選定理由

テックブログを開設しようとすると、自分たちで作成するのかブログサービスを使うのかの選択が必要になります。
以前もオールアバウトテックブログは開設(※4年前)しており、自分たちで作成していたのですが、運用負荷が高く閉鎖してしまいました。
そのような反省点もあり、今回は外部のブログサービスを使うこととしました。
ブログサービスは種々ありますが、以下の理由からはてなブログを選定しました。

MarkDown形式で執筆ができる。QiitaなどでMarkDown形式に慣れており書きやすかった。
MarkDownで執筆できるので、Bitbucketでの管理と相性が良かった。
他社様のテックブログや他の技術ブログを見てもはてなブログの採用率が高かった。

今回は情報を発信するという点に注力したかったため、外部のサービスを使用しましたが新しい技術の導入のサンドボックスとしてテックブログを運営するというのもいい考えだと思います。
外部サービスを使用するか自分たちで作成するかはどこに力を入れていきたいかで変わってくると思います。

記事公開時の編集作業

記事を公開する前に記事公開予定日を選定します。
できるだけ多くの人に読まれるように、大きめなカンファレンスや新製品の発表がある時を避けて記事公開予定日としています。
一部例外があり、カンファレンスの内容と記事の内容がマッチする場合は同じ日付で公開をしています。
公開日予定日が決定し予約公開するぞ前に編集者は大事な作業が残っています。

記事のタグ付け
タグ付けに関しては編集者が実際に記事を読んで記事にあった内容のタグを2-3個ピックしてつけています。
サムネイル画像の選択
各SNSで拡散されたときに見栄えがいい画像を記事中の画像からピックしてサムネイル画像としています。

こうして記事が公開された後には、Zapierを使い記事を公開されたことをSlackに自動で流しています。
理由は2つあります。

正しく公開されたかリマインダー的な扱い。
外部の人に読んで貰う前に自分たちでも興味を持って読んでもらいたいという思いから。

こうして記事が公開されています。
編集会議のネタ出しから執筆・編集を経て公開まで1記事約1か月かかっています。
(並行して何記事か執筆・編集している状態です)

半年間上手く行った理由

以前(4年前)テックブログを運営していたときは更新が滞りがちでした。
この半年では記事の執筆が滞ることも少なく5月~9月までは月平均2記事出すことができていました。
この理由としては、Qiita TeamやQiita Organizationなどで外部に情報発信をする文化が根づいてきたことや、週に1回ワークショップを行っており、アウトプットの意識が向上してきているからだと思います。
しかしながら、外部勉強会で発表を行うことは敷居が高く感じているエンジニアが多くおり、そのようなエンジニアでもアウトプットができる場として機能していたのが大きいと思います。
PVやはてなブックマーク数などでユーザの反響がダイレクトにわかるためそれがモチベーションになる人もいますし、
半年に1回ベストブログアワードを選出して表彰するようにしているため、賞を狙うという点で燃えている人もいます。
最終的には編集者が執筆の催促をすることで書かなきゃ…という気持ちにさせているというのも大きいと思います。
このように書くことによって得られるメリットやモチベーションを保ちつつ気持ちよく執筆してもらうというのが大切だと考えています。

今後運営としてやりたいこと

ブログの運営としては手動で行っているところが多くあります。
今後は手動で行っている作業の自動化や効率化もしていきたいなと思います。
例えば記事の内容を解析して機械学習で自動タグ付けを行ったり、
bitbucketでマージされたらはてなブログへ自動pushする仕組みを作るなどです。
更にPV数やはてなブックマーク数を執筆者にKPIとして通知するのも現状手動なので自動化したいと考えています。
上記改善ができましたら、またブログで報告したいと思います。

まだオールアバウトTech Blogは開設半年です。
今後も長く運営を続けていけるように努力して行きたいと思います。
また、役に立つ技術内容を毎月お届け出来るようにしていきたいと思います。
今後もオールアバウトTech Blogの投稿にご期待下さい！