なぜ技術ブログを作り直したのか

eyecatch

こんにちは、ギフティでエンジニアをやっている中屋(@nakaryo79）です!普段は eギフトの発行基盤的なアプリケーションの開発をやっています。

最近発売されたドラクエ3のリメイクを買い、20年ぶりぐらいにゾーマを成敗しました。感無量です。

はじめに

リメイクといえば、弊社の技術ブログもリメイクをし、少し前に「技術ブログリニューアルのお知らせ」という記事を書きました。

その記事の中でリニューアルの背景についても軽く触れましたが、詳細なところまでは書けなかったので、この記事ではより詳しい経緯や思いを書きたいと思います。

ことの始まり

弊社の技術ブログは2019年に作られ、この5年間で様々な情報を発信してきました。

当時の、今より限られたリソースの中で0からブログの立ち上げを行い、軌道に乗せたのはもちろん凄いことなのですが、それを継続する体制やシステムがうまく構築されておらず、熱意のある執筆者が頑張って更新するという状態が続いていました。個人的にもあまり活発に書かれてないなという印象を持っており、実際、月に1本書かれるかどうかといった具合の時期が長く続いていました。

本来であれば、事業の拡大に伴い社内のシステムはどんどん複雑になっていっているし、エンジニアの人数も増えているので、記事が出されるペースが上がっていてもおかしくないのですが、中々うまくはいかず、時にはチームに執筆ノルマが課されたりしてみんなが嫌な思いをする、なんてこともありました。

この状況を鑑みると、そもそも書くモチベがある人がいないのであれば別に無理して記事を増やす必要性もないのでは？とも思えます。書くこと自体が目的化してしまっては元も子もないですし。

一方で、弊社には「知見を贈り合う」という素敵なエンジニアバリューがあります。それは、ギフトの会社として、技術コミュニティへギフトを返せる組織でありたいと考えているという思いがあるからです。弊社のプロダクトは Ruby や Ruby on Rails をはじめ、多くの OSS に支えられて成り立っています。そうしたものの恩恵を受けっぱなしになるだけでなく、我々もまた技術コミュニティに知見を還元するという知見の循環が大事だと捉えています。

value

知見の還元、つまり世の中へのアウトプットのあり方は多々ありますが、技術ブログはそのようなバリューの発揮を推進するための一つの効果的なツールだと思います。社員の中には、何かしら対外的なアウトプットをしたいけど環境が整っていないためにそれを行うハードルが高い、と感じている人もいるかもしれません。そうした機会損失は会社としてもマイナスなので、何かしらテコ入れをする余地があります。また、ギフティはユニークなドメインに立ち向かっており、開発内容としても興味深いトピックが色々あるんだから、そうした情報がもっと外から見えるようになっていると面白いのになあ、という思いもありました

そうした背景があって、技術ブログをもっと有効活用するために何かできるんじゃないか、を真剣に考え始めたのが最初のきっかけでした。

課題の特定と方針策定

なんとなくうまくいってないのでは、というフワッとした状態から、より具体的に状況を捉えるために、まずは現状把握から始めました。

現行の技術ブログの機能的な問題点をリストアップしたり、どのような内容の記事がどのぐらいのペースで出されているのかなどの定量的な情報と合わせて、社員に技術ブログに関するアンケートを取ってみて、現場のみんながどのように感じているのかという定性的な情報を収集したりしました。

その結果、明確な課題がいくつか見えてきました。

ブログ自体の管理者がおらず、執筆フローも整備されていない
- 誰にとってもすぐに、簡単に書き始められる状態になっていない
- メンテナが不在で、ブログとしての機能拡充ができていない
- 記事の検索機能やカテゴリ機能、X ポストの埋め込み表示など、ブログに必要な基本的な機能がない
- ブログを書こうと思った際のサポートも仕組み化されていない
技術ブログを書く意義が明文化されておらず、「なぜやるか」が各々にとって明確ではない
- 業務の時間を使って書くのであればそれなりの意義の理解が必要だが、そう言ったものがないのでブログを書く優先度が上がらない
- ブログを書いて公開しても執筆活動や記事自体へのフィードバックがなく、達成感が得られない
ブログの位置付けや執筆フローがあまり周知されていなかったため、そもそも書き方がわからない、会社のブログを書くものなんだ、という意識づけができていない
- アンケートを取ってみた結果、半数以上の人が会社の技術ブログの書き方を知らない、という結果に
書くネタがない
- ネタがない！！

一点目の「ブログ自体の管理者がおらず、執筆フローも整備されていない」に関しては、既存のブログは当時の勢いでガッと構築したものの、その後そんなに活発にメンテがされているわけでもなく、業務の片手間でとなると改修の優先度も上がりづらくなっていました。ブログ SaaS サービスは使っておらず、Gatsby を使って構築したサイトを Netlify 上でホスティングしていたので、自分たちでコードを書いて修正しないと機能が拡充されない状態でした。実際に当時の構築を担当していた社員も「他のプラットフォームに乗り換えてもいいかもね...」というようなことを言っていました。

技術ブログ自体を自分たちで作るか、SaaS サービスを使って構築するかは割と悩みどころかと思いますが、現状ブログのメンテナンス自体に高いモチベーションを持ってる社員もおらず、そこに時間を割くのは賢明でないと判断し、ブログ専用の SaaS サービスを使う方針としました。作るより買えというやつですね。SaaS サービスを使えば、ブログ自体の機能拡充は SaaS サービス側に任せることができます。また、いいねやスターなどのフィードバック機能があるものが多く、第三者からの反応があることで貢献した実感がある程度可視化されるというのも大きなメリットです。

また、二点目、三点目の「書く意義が明確でない、意識付けができていない」に関しては会社側としての定義づけやサポートが不足しているということで、まずは書く意義をしっかりと言語化し、周知する必要性を感じました。

四点目の「書くネタがない」に関してはある意味あるあると言いますか、正直一番難しいポイントかなと思います。三点目まではお膳立てである程度解決できる部分もありますが、ネタに関しては執筆者本人の中から出てくるもので、急にどこかから湧き出てくるものでもありません。しかし、会社でエンジニアとして日々開発をしていて、全くアウトプットする内容がないということもないのではと思います。本人はそう思っていなくても実は世に出して意味のあるネタというのが意外と転がっているかもしれません。この辺りは本人頼みだけではなく、客観的な目線でサポートをしていくといいのかなと思っています。具体的には slack 上のやり取りや社内ドキュメントへのアウトプット、社内 LT などをウォッチして、「これブログに書きませんか？」みたいな声がけをするという、地道な草の根活動をしていく感じです。

ということで、まずはブログ専用のサービスにプラットフォームを移行しつつ、並行で執筆フローや運用を整備しようという方針に決まりました。その上で、ネタ探しや執筆のサポートをしていけるとなお良さそうです。

プラットフォーム移行

プラットフォーム検討

プラットフォームを移行するにあたって、どのサービスを使おうかという話になり、はてなブログ、Zenn、note、Medium などいくつか比較し、最終的にはてなブログを使うことに決めました。

Zenn は最近技術ブログ用の機能拡張に力を入れており、レビュー機能があるのが非常に魅力的ではあったのですが、見た目のカスタマイズ性が低く、良くも悪くも企業ブログ感が出ないのがネックでした。 note は会社の採用広報のチャネルとして既に使われており、会社としてツールを統一できるメリットはありましたが、マークダウンとの相性が良くなかったり、Git との連携ができないので不採用としました。その点、はてなブログはテック界隈ではかなり存在感があり、長らく運用されてきた歴史もあり、外さない選択肢かなと思いました。

ちなみに、プラットフォーム乗り換え時の観点として以下のような要素を特に考慮していました。

値段
- ちょうど良い契約プランがあるか
運用性
- レビューできるのか、マークダウンで書けるのか、とかとか
  - 公開するまでの手順が多いと書くのが面倒になるかも
データ取得性
- GA 入れられるか
- PV、いいね、滞在時間、流入チャネルなどが取得できるか
カスタマイズ性
- UI にある程度の自由度があるか
- URL でカスタムドメインが使えるか
持続可能性
- ホスティングサービスがサ終しないか
記事の import/export しやすさ
- どのように既存の記事をインポートするか
コードスニペットの読みやすさ
- 技術ブログでは結構大事
プラットフォームの母集団の大きさ

はてなブログには はてなブログfor DevBlog という技術ブログ専用のプランがあり、お値段もそこそこで必要な機能は大体揃っています。カスタムドメインも使えますし、自分で CSS を書けばデザインも柔軟にカスタマイズすることができます。また、ホットエントリーや以下のようなキュレーションページもあり、良い記事を書けばより露出が増えやすいという点も魅力的でした。

https://hatena.blog/dev

GUI で書く場合にレビュー機能がないのが痛いのですが、エンジニアの多くは Git を使って記事を作成するフローを取るだろうと思い、その場合はプルリクエスト上でレビューが行えるのでそこまで問題ではないと判断しました。

移行作業

はてなブログのアカウントを取得して、ブログを開設して未公開の状態で作業を進めます。

GUI だけでなく Git で執筆するフローをサポートしたかったので、まずはそれを実現するにあたって技術検証を行いました。と言っても、はてなブログを Git で運用している事例は既に多数あり、はてなさんの公式ライブラリまで存在しているので、あまりハードルはありませんでした。実際、そこまで特殊なことはしていなくて、ライブラリを使ってマニュアル通りに構築しています。

そのほか、新規にドメインを取得したり、デザインを作ったりといった準備を整えて、これで良さそうだねという確証が得られたあと、既存記事の移行を行いました。

記事の移行作業に関しては自動化することも考えましたが、幸いそこまで分量がなかったのでスクリプト書くより手でコピペした方が早そうだ、ということで一つ一つ手でコピーしていきました。既存のブログ記事は GitHub で管理されていたため、新規リポジトリに画像ファイルを全てコピーし、記事もマークダウンのままコピーして画像へのパスは機械的に置換して、という感じです。中には、マークダウン記法の解釈の違いによって、旧ブログでは正常に表示されていても、はてなブログでは表示が崩れていたりする箇所もあったりしました。せっかく社員の努力によって執筆されたコンテンツなのですから、その内容には敬意を払って、移行前後で不要な差異がないように全て目視で内容をチェックするなど、丁寧にことを運びました。

記事の移行が終わったら、最後にリダイレクトの構築をします。旧ブログの URL へアクセスが来た際に、新規ブログの URL にリダイレクトするようにします。リンクを引用したり、ブックマークしていただいている方もいるかもしれないので、急にリンク切れを起こさないようにするためです。これは記事単位で行なっています。

あとはブログ自体を公開状態にすれば完了です。

ブログを書く意義の明文化

CTO 交えて、会社のブログを書く意義を策定しました。実際に出来上がったものをほぼそのまま載せてみます。

弊社には以下のように「知見を贈り合う」という行動指針があります
ギフトの会社として、技術コミュニティへギフトを返せる組織でありたいと考えています。そのため、社内外問わず積極的な知見の共有を行なう、受ける、そして得られた知見をプロダクトへと活用していくことを大切にしていきます。

我々の開発は Ruby をはじめとした多くの OSS やハウツー記事に大きく頼っています

それらは誰かが商業的に作っているものではなく、コミュニティの発展を通して世界の発展に寄与するために無償で開発、公開してくれているものです

我々はそうしたものの恩恵を受けっぱなしになるのではなく、コミュニティに知見を返せるようなマインドを大切にしています

技術ブログは社員がコミュニティに対して情報を発信（還元）するための一つのチャネルとなることを期待しています

他にも対外的なアウトプットをすることの提供価値を組織目線、広報目線、執筆者本人目線でそれぞれ言語化し、会社としてアウトプットを後押しする意思があるぞ、ということがわかるようにしました。

あまりガチガチにやってもよくないのですが、会社の技術ブログにコントリビュートするという行為はともするとボランティアになりかねないので、会社としてそうした行為が大切だと思っているというのが示されているというのは一定意味があるんじゃないかと思います。

執筆サポート

ブログのプラットフォーム移行や意義の明文化はゴールではなくいわばスタートラインです。場を提供しただけでは不十分で、アウトプットを促進するために、記事執筆の呼びかけやサポートを行なうことでよりドライブをかけていきます。記事が公開されたらエンジニア全体共有の場で周知を行い、slack 上でのフィードバック/リアクション、執筆者を称賛する雰囲気の醸成、企業 X アカウントでのポストなど、できることはなんでもやっていきます。

対外的なアウトプットに慣れてない人はそもそもどういう内容を書いたらいいかわからない、となりがちなので、ネタの発見や記事の構成を一緒に考えたりなど、より細やかなケアをしていけるといいのかもと思っています。

成果

この記事を書いているタイミングではまだリニューアルから2ヶ月、成果を語るのはこれからかなと思います。今時点では社内では概ねポジティブな反応を得られており、順調に記事数が増えています。また、今までブログを書いたことがなかった人も執筆してくれており、大変良いムーブメントができつつあります。

それから、記事にスターやブクマがつくことで、フィードバックが可視化されるというのもやはり良いものです。読まれているという実感があれば、それが次の記事を書くモチベーションになります。

最後に

この記事では技術ブログという切り口で話しましたが、技術ブログ自体は How の一つでしかないので、そこにとどまらず様々な形でのアウトプットを通して社員が技術コミュニティに貢献していけるといいなと思っています。

ちなみに、このプラットフォーム移行および執筆推進のサポートなどは技術ブログタスクフォースとして自分含め有志のエンジニア3人がボトムアップ的にやっているものです。目的が説明されていれば後の How は自由にやらせてもらえるという裁量の大きさがギフティにはあります。官僚的にならないように、今後も現場主導で色々やっていけたらと思っています。アウトプット自体も、やりたくてやっているという状態が大事ですからね。

会社として改めてアウトプットのスタートラインに立ったという気持ちで、より一層、知見の循環を推進していければと思います！