こんにちは。「株式会社オープンワーク」ではなく「オープンワーク株式会社」の生永です。
文章を書くにあたって、タイポはもちろんのこと、組織内において定められている表記ルールに則さないことばを書いてしまったという経験をお持ちの方は少なくないのではないかと思います。
冒頭の挨拶も弊社の表記ルールに則ったもので、「株式会社オープンワーク」ではなく登記の商号に登録している「オープンワーク株式会社」が正式なものです。
表記ルールの徹底はなかなか難しいです。レビューによるチェック体制やルールの周知をしても、運用努力ということになり組織拡大に伴って増大する半永久コストになっていきます。
そこで今回、textlintの活用を試みました。まだ本運用ではありませんが、textlintの紹介と弊社内のその運用展望についてまとめます。
textlintとは
textlintとは自然言語向けのJavaScript製リンタープラグインツールです。
JavaScript/TypeScriptでいうESLint、PythonでいうFlake8やRuffのようなものの自然言語版です。
ファイル内の自然言語に対して静的解析を行い、設定したルールに合わせてエラー表示、また修正まで実施してくれます。
textlintの最も大きい強みのひとつにその拡張性があります。
textlintはルールと適用対象ファイルフォーマット、またその運用に対して拡張性を持っています。
textlintのルール
textlintで設定できるルールはtextlintのプラグインとして公開されています。それらを組み合わせて、自前の表記ルールを作成します。
日本語向けのルールも充実しており、一文中の読点「、」の数の制限ルールや「ですます」調と「である」調の混在チェックルールなど日本語特有の校正ルールが公開されています。
もちろんカスタムルールプラグインの作り方も公開されているため、自身でまだ見ぬルールを作成、公開することも可能です。
textlint-rule-prh
様々なルールがある中、社内用語など独自で定めている用語のチェックに使用できるルールの「textlint-rule-prh」をご紹介します。
これは元々prhという校正ライブラリをtextlintのルールとして使うことができるプラグインです。
英字の大文字小文字全角半角の統一、想定される誤用パターンから正しい使い方の統一が可能です。
誤用パターンは正規表現も使うことができるため、ある程度の表記ゆれも簡単に統一可能になります。
例えば以下のようなルールです。
前株、後株のルール設定や正規表現による英字表記ルールです。
OpenWorkはたまにオープンワークス(OpenWorks)と間違えられてしまいますが、こういったミス防止もルール設定可能です。
expected: オープンワーク株式会社 pattern: 株式会社オープンワーク expected: OpenWork pattern: /[Oo][Pp][Ee][Nn][Ww][Oo][Rr][Kk][Ss]?(?<!OpenWork)/ specs: - from: OpenWork to: OpenWork - from: openwork to: OpenWork - from: OPENWORK to: OpenWork - from: openworks to: OpenWork - from: OPENWORKS to: OpenWork - from: OpenWorks to: OpenWork
ファイルフォーマットについて
自然言語はどのファイルフォーマットにも含まれる可能性があります。そのため、適用できるファイルフォーマットもプラグインによる拡張性を持たせてくれています。
デフォルトで.mdファイルと.txtファイルに使えます。その他、.htmlファイルや.jsxファイルなどにも適用できるプラグインが公開されています。
こちらもルール同様にカスタムプラグインの作り方が公開されています。
ファイルフォーマットを適用させなければならない理由として、リンターとして自然言語として処理する前にファイル内の文字列をファイル特有のタグやコード、文字列とそれ以外の言葉を正しく整理をしなければならないためです。textlintのルールの中には文章というまとまりの中でチェックを走らせている場合があり、そういったルールを使用したい場合はこのプラグインによるファイルフォーマットの適用は必須です。
一方で「textlint-rule-prh」のように文章単位のチェックでない場合は不要です。適するプラグインがなくてもtextlint設定ファイルの.textlintrcに以下のように記載することで対応は可能です。
この記載でプラグインがなくとも.pyと.vueファイルもtextlintのルール走査だけはすることができます。ただし、読点の数チェックなどのような文章単位チェックは正確性を失うことになるため注意が必要です。
大人しくプラグインを探すもしくは作成するのが良いでしょう。
{ "plugins": { "@textlint/text": { "extensions": [ ".py", ".vue" ] } } }
現在の運用
弊社では、ルールは「textlint-rule-prh」のみで、まだ個人のチェックでのみの活用に留まっています。
各自が修正ファイル内でミスがないかをコマンド実行でのチェックや各種エディタのtextlintプラグインでのチェックに活用しています。
ちなみに2024年4月現在公開されている各種エディタのtextlintプラグインのうち、IntelliJ用プラグインではあらゆるファイルフォーマットやルールをエディタ上でチェック可能ですが、vscode用プラグインではいくつかのファイルフォーマットにのみ制限がかかっています。
今後の展望
ルールの充実化のためには弊社内で使用しているファイルフォーマットに合わせたプラグインの整備が喫緊の課題になっています。
ちなみに運用の展望についても触れておきたいと思います。
textlintは以下のような柔軟な運用ができるようになっています。
textlintのルール設定の再活用
textlintのいくつかのルールをまとめてプリセットという単位で再活用ができるようになっています。
組織ルールとして用意して複数のプロジェクトで使いまわしたい場合などに使うことができるようになっています。npmパッケージとして公開することも可能です。
chromeプラグインも公開されている
textlintはchromeプラグインとしても公開されており、textlintの設定を一つのリポジトリとして管理し、それを適用することでブラウザ上でも校正ができるようになります。
メールのようにエディタを使わないテキストも容易にチェックできるようになって便利になります。
ciに組み込む
各エディタのプラグインでのチェックのみだとプラグイン起因の動作不良で十分なチェックができない場合があります。 github actions等のci上の直接的なコマンド実行で動作させることでそれらのリスクを回避しつつ、より安定運用ができるようになります。
オープンワークでは開発周りも自分たちで改善をしていっています。サービスとともにより良い開発体験に向けて一緒に開発をしていただけるエンジニアを募集中です。ご興味があればぜひ求人を見てみてください。