イノベーションセンターの小林です。普段は、ある日は部内情シス、ある日は情報セキュリティオペレーションをやっています。以前の開発者ブログに寄稿したこともあり、今回の開発者ブログリニューアルにもかかわりました。
今回のリニューアルにあたっては、各記事に対する社内レビューと記事公開のプロセスを「いい感じ」にしたいよねとの声があり、現時点ではそれなりに満足いくものを作れました。その中身を少しご紹介します。
レビュー
以前の開発者ブログの頃から、寄稿された記事は有志によるレビューを通してから公開するようにしていました。主に見ていたのは文法的な間違いがないか、NTT Comの統一表現を使っているか、明らかな事実誤認や錯誤がないか、といったポイントです。このレビューの仕組み自体は、リニューアルにかかわった面々とのディスカッションを踏まえて、今回のリニューアル後も引き続き行うことにしました。
かつてのレビューは、Google DocsやWordなどで寄稿者がまとめた原稿に、レビュワーがコメントをつけて寄稿者に戻し、寄稿者が内容を修正した後ブログプラットフォームへ投稿する流れになっていました。このプロセス自体は一応動くには動くものの、開発者ブログの中身としてはあまり「いい感じ」の状態ではないね、との話はずいぶん前からありました。
どうしたか
今回のリニューアルに際し、次のような仕組みを作りました（説明のため一部割愛しているところがあります）。
簡単な流れはこうです。
寄稿者にはMarkdown形式で原稿を書いてもらい、画像（あれば）とともにGitHubにコミットします。そのコミットをpull requestにしてもらいます（図中の1）。
レビュワーは従来通り内容をチェックし、問題なければマージします（図中の2）。
マージをきっかけにGitHub Actionsによるデリバリプロセスがスタートし、原稿と画像を読み込んでブログプラットフォームのAPI経由で記事を送信、最終的に公開される仕組みです（図中の3と4）。
図中では表現していませんが、1でpull requestをオープンした時点でもGitHub Actionsが起動し、Linterによる文法・表現のチェックを行うようにもしました。記事が長いと見落としがちな表記揺れにも気づきやすくなります。
得られたこと
GitHubのpull request機能に備わっているコメント機能（ソースコードの行を指定してコメントがつけられる）を使えるようになったこと、また変更前後の差分をすぐ引き出せるようになったことが大きいです。Google Docsでも任意の箇所にコメントをつけたり、修正を提案する機能もありますが、解決済みとしたコメントや修正を受け入れた箇所を後から探すことには困難が伴います。
また、ブログプラットフォーム本体の、投稿権限を持つユーザーをいたずらに増やさなくて済む点も挙げられます。投稿したい人はGitHubへのアクセスさえあればよく、プラットフォーム側のユーザー管理にかかる手間が削減できます。寄稿者にしてみても、エンジニアにとっては使い慣れた道具であるGitHubでライティングができることは、新たな学習コストをかける手間が省けます。
今後
GitHubとGitHub Actionsを中心としたエコシステムでは、まだいろいろできることがありそうです。
- 画像の適切なリサイズ、記事サムネイルの生成など画像に関する処理
- 表現チェックの自動化（textlintを使うなど）
- 社内Slackに新着投稿の通知を出して、コミュニティを盛り上げる……などなど
寄稿者、レビュワーほか開発者ブログにかかわる人にとって「いい感じ」のプラットフォームにしていければいいなとも思います。
もちろん読者の皆様にもメリットがある話だと思っています。「簡単に書ける」ことがNTT Com内に知れ渡れば、きっと隠れた寄稿者がどんどん出てきて、皆様にもどんどん新しい記事をお届けできる、はず。
今後の開発者ブログのコンテンツにもご期待ください！
