ヘルプの校正をtextlint・prh・CircleCIを使って自動化する

boardのヘルプは、Githubで管理し、プルリクエストを使って編集・校正を行っています。

ざっくり以下のような運用になっています。

これについては、以前詳しく書いたので、興味がある方は下記をご覧ください。

実際に運用していて、この仕組みはとても気に入っているのですが、せっかくここまで仕組みができたので、もう一歩進めて、機械的にチェックできるところは、編集者の時間を使わずにチェック・修正をしたいなと考えました。

文章の場合、機械的にチェックできるのは、たとえば、以下のようなものです。
・「とくに/特に」のように漢字・ひらがなの表記
・「ブラウザ/ブラウザー」のように長音の有無

編集者（@note103）がCS（サポート）として入社したことをきっかけに、ヘルプやサポートの中で使う表記を統一していこうという話をしていて、彼にそういったルール作りしてもらう予定でした。

今回、それを自動化しようという取り組みです。

エンジニア的にはrubocopやeslintなどがあるので、それの日本語版ですね。

最初は自前でそういう仕組みを作ろうと思っていたのですが、textlint・prh (proofreading helper)というものがあることを知ったので、これを使うことにしました。

textlint・prhを使います。

textlintには様々なプラグインがあるのですが、すでにヘルプだけでも350記事ほどある状態なので、まずは最低限の表記揺れのチェックから始めることにしました。

表記揺れのチェックはprhを使います。@note103に定義を作ってもらい、それに違反したものは、下記のようにエラーになります。

  25:25  ✓ error  予め => あらかじめ  prh
  36:4    ✓ error  例えば => たとえば  prh
  67:24  ✓ error  全て => すべて  prh

eslintと同じように、--fixで自動修正も可能です。

手元でtextlintを実行しても良いのですが、それだと忘れがちだし、問題ないことを保証できません。

以前のブログで紹介したように、ヘルプはGithubで管理しているので、ソースコード同様、プッシュしたらCircleCI上でtextlintを実行するようにしました。

違反しているものがあれば、エラーになって通知が来るので気づくことができますし、Githubのプルリクエスト上でもCircleCIが通ったかどうかの確認ができます。

CircleCIでtextlintが通るところまでは、プルリクエストを出す人の責任範囲として運用しています。

ヘルプやお知らせ記事など合わせて約650記事あったので、まずはそれらを全て通す必要があり、後からこういう仕組みを入れると、これが面倒なんですよね・・・。

幸い、自分の普段の書き方と@note103のルールが似ていたのと、textlintの自動修正がきれいにできたので、さくっと修正できました。

また、masterブランチへマージすると自動的に本番環境へ反映するようになっているので、反映の手間もかからず、この辺の仕組みを整備していてよかったなあという感じです。

文章を書くにあたって、ルールを整備しておくことで、読みやすさや統一感というのはもちろん、書く人が迷わずに済むメリットもあります。

そのため、元々ルールを整備したいとは考えていたのですが、今回、自動化までできたので、表記揺れなどの機械的なルールは一切考える必要がなくなりました。

また、そういったことに編集者の頭を使う必要がなくなり、「読みやすくてわかりやすい文章や説明」に注力することができます。

社内に編集者がいるとはいえ、本業はサポートなので、編集の仕事ばかりやってもらうわけにはいかず、編集の仕事は1日1時間としています。

そのため、こういった自動化のメリットはとても大きいです。

「10人の会社で1万社が使うサービスを目指す」のブログに書いたように、人数をどんどん増やしていくつもりはないので、自動化できるところは自動化していくというのは、システムに限らず、取り組んでいきたいと考えています。

ヴェルク - IT起業の記録