監視を育てよう！ /「入門 監視」を読んだ

今年1月に出版された「入門 監視」を読んだ．出版前から予約をしていたけど，他に積読もあり，読み始めるのが少し遅れてしまった．評判通り素晴らしく，特に「監視」というテーマをうまく言語化している本だと感じた．目次を見るとわかる通り，「あれも監視！これも監視！」という幅の広さに気付くことができる．本書は1人で読んで終わりにするのではなく，チームで輪読会をしてディスカッションをするなど，改善に繋げるために継続的に読むと良さそう．さらに本書で学んだ内容に Dive Deep するために他の書籍も併読するべきだと思う．今回は関連する書籍も紹介しようと思う．

入門 監視 ―モダンなモニタリングのためのデザインパターン

目次と正誤表

• 1章 : 監視のアンチパターン
• 2章 : 監視のデザインパターン
• 3章 : アラート、オンコール、インシデント管理
• 4章 : 統計入門
• 5章 : ビジネスを監視する
• 6章 : フロントエンド監視
• 7章 : アプリケーション監視
• 8章 : サーバ監視
• 9章 : ネットワーク監視
• 10章 : セキュリティ監視
• 11章 : 監視アセスメントの実行
• 付録A : 手順書の例：Demo App
• 付録B : 可用性表
• 付録C : 実践 監視 SaaS

正誤表は以下にある．今回「第1刷」を読んでいて誤植に気付いたけど，今から買えば直ってそう．

www.oreilly.co.jp

動いているかどうかを監視しよう

1章「監視のアンチパターン」の中で，「チェックボックス監視」に依存するのではなく「動いているかどうかを監視しよう」という内容がある．CPU Utilization など，コンポーネント個別のメトリクスを監視することも重要だし，障害になる予兆を検知できる可能性もあるけど，1番重要なのは「ユーザ影響」であり，まず「動いているかどうか」を監視するべきということを改めて認識できた．個人的に経験のあるシチュエーションとしては「営業担当（など）がサービスの障害に1番に気付く」ことで，インフラ側のアラートは出ていなかったりする．これこそ「ユーザ影響」を監視できていないのでは？と考えさせられた．

「アラート」と「オンコール」

3章「アラート、オンコール、インシデント管理」は個人的に必読だと思う内容だった．サービスを運用していると深夜にアラートが出る場面も多く，変にアドレナリンを発生させながら障害対応をしていたけど，定期的に続くと生活に支障が出る場合もあった．本書では最初にベストプラクティスが6点紹介されていて，どれも「ウッ！」と刺さる項目になっていると思う．さらに後半には「オンコールローテーション」の話題があり，チームでディスカッションをするネタになると思う．

• アラートにメールを使うのをやめよう
• 手順書を書こう
• 固定の閾値を決めることだけが方法ではない
• アラートを削除し，チューニングしよう
• メンテナンス期間を使おう
• まずは自動復旧を試そう

「リアルユーザ監視」と「シンセティック監視」

6章「フロントエンド監視」の中で，アプローチとして2種類「リアルユーザ監視 (RUM : Real User Monitoring)」と「シンセティック監視 (Synthetic Monitoring)」があると書かれている．重要なのは「動いているかどうか」だけではなく「パフォーマンス良く動いているかどうか」という観点で，フロントエンド監視を考えさせられる内容だった．本書では「シンセティック監視」の代表例として WebPageTest が紹介されていたけど，シンプルな外形監視なら Uptime Robot もあり，僕は Uptime Robot を使ってブログを監視している．

www.webpagetest.org

uptimerobot.com

あと Navigation Timing API などは「超速本」を読むと良さそう．個人的に1番詳しく載っている書籍だと思う．

超速! Webページ速度改善ガイド ── 使いやすさは「速さ」から始まる (WEB+DB PRESS plus)

関連書籍

監視に関連する書籍だと，2012年に出版された「Effective Monitoring and Alerting」が好きで，July Tech Festa 2017 に登壇したときにも引用した．また現在は技術講師をしているため「モニタリングは2種類あるんです！」という話をすることもある．今後は本書「入門 監視」も合わせて紹介しようと思う．

Effective Monitoring and Alerting: For Web Operations (English Edition)

July Tech Festa 2017 の資料は以下にある．DevOps の事例として見て頂ければと！

kakakakakku.hatenablog.com

他には，2016年に出版された「ソフトウェアエンジニアのための ITインフラ監視[実践]入門」もある．

kakakakakku.hatenablog.com

Monitoring is Dead

本書の1ページ目に「監視の定義」として「Monitoring is Dead」が紹介されている．資料も動画も公開されているけど，これは是非動画を見て欲しい．本当におもしろい．内容としては「モニタリングとはシステムやコンポーネントの振る舞いを観察するものである」という主張で，本書でも繰り返し出てきた「ユーザ視点での監視」と同じと言える．

vimeo.com

付録 C「実践 監視 SaaS」

本書を読むなら @songmu さんの「付録 C」も必読と言える．Mackerel を代表例として「監視 SaaS」をどのように選定するか？など，詳しくまとまっている．「ハッカビリティを備えているか」という観点も良い．特に後半にある「監視を育てる」という話が好きで，過去に @songmu さんが発表した「運用・監視もコード化する。開発者が監視まで考える方法論」の中にある「監視とはシステムに対する高速健康診断である」という名言を思い出した．当時僕はこの名言に刺激を受けた．

songmu.github.io

まとめ

• 「入門 監視」を読んだ
• 「監視」というテーマをうまく言語化している
• チームで輪読会をしてディスカッションをするなど，改善に繋げるために読むと良さそう

入門 監視 ―モダンなモニタリングのためのデザインパターン

関連記事

2016年に「監視を育てる」ために改善した内容をまとめている．実践的な事例として見て頂ければと！

kakakakakku.hatenablog.com

ajitofm で「入門 監視」の出版秘話を聞ける．「テスト駆動開発」の文脈を知らない人だと「付録 C」が「フロクシー」に聞こえてそうw

ajito.fm

Mackerel アンバサダー

「監視」繋がりだと，実は今年2月に「Mackerel アンバサダー」にノミネートして頂いた！

mackerel.io

2ヶ月に1回を目標に Mackerel 関連の記事を書きながら貢献していく予定．Trello にもタスクを作ってある．よーし！監視を育てるぞ！

ドキュメントにある「リンク切れ」を検知できる「textlint-rule-no-dead-link」

textlint のルール「textlint-rule-no-dead-link」を使うと，ドキュメントにある「リンク切れ」を検知することができる．最近とあるドキュメントをレビューするときに，比較的リンクが多く，作業を効率化するために導入した．インストール手順は GitHub に書いてある．

github.com

正常

以下のようにREADME.md を準備する．

- https://kakakakakku.hatenablog.com

リンク切れはなく，正常に実行できる．

$ textlint --rule textlint-rule-no-dead-link README.md
$ echo $?
0

異常 (404 Not Found)

以下のようにREADME.md を準備する．意図的に誤ったリンクを追加している．

- https://kakakakakku.hatenablog.com
- https://kkkkkkkkkkk.hatenablog.com

実行すると，リンク切れを検知できる．これは便利！

$ textlint --rule textlint-rule-no-dead-link README.md

README.md
  2:3  error  https://kkkkkkkkkkk.hatenablog.com is dead. (404 Not Found)  no-dead-link

✖ 1 problem (1 error, 0 warnings)

$ echo $?
1

異常 (301 Moved Permanently)

以下のようにREADME.md を準備する．意図的にリダイレクトになるリンクを追加している（http → https）．

- https://kakakakakku.hatenablog.com
- http://kakakakakku.hatenablog.com

デフォルト設定だとリダイレクトもエラーになる．後述する設定を有効化すると，リダイレクトを許可することもできる．

$ textlint --rule textlint-rule-no-dead-link README.md

README.md
  2:3  ✓ error  http://kakakakakku.hatenablog.com is redirected to https://kakakakakku.hatenablog.com/. (301 Moved Permanently)  no-dead-link

✖ 1 problem (1 error, 0 warnings)
✓ 1 fixable problem.
Try to run: $ textlint --fix [file]

$ echo $?
1

自動修正 (--fix)

リダイレクトを検知した場合，実行時に --fix オプションを指定すると自動的に修正することもできる．

$ textlint --fix --rule textlint-rule-no-dead-link README.md

README.md
  2:3  ✔   http://kakakakakku.hatenablog.com is redirected to https://kakakakakku.hatenablog.com/. (301 Moved Permanently)  no-dead-link

✔ Fixed 1 problem

設定

「textlint-rule-no-dead-link」は現時点だと計5種類の設定をサポートしている．

• checkRelative : 相対 URI を確認するかどうか（デフォルト true）
• baseURI : checkRelative と組み合わせて使う基底 URI を設定するかどうか（デフォルト null）
• ignore : 除外する URI を設定するかどうか（デフォルト []）
• preferGET : HEAD メソッドではなく GET メソッドで確認するかどうか（デフォルト []）
• ignoreRedirects : リダイレクトを除外するかどうか（デフォルト false）

.textlintrc を以下のように書くと，設定を有効化できる．

{
  "rules": {
    "no-dead-link": {
      "checkRelative": true,
      "baseURI": null,
      "ignore": [],
      "preferGET": [],
      "ignoreRedirects": false
    }
  }
}

UserAgent は？

「textlint-rule-no-dead-link」の実装を読むと，実際に HTTP リクエストを飛ばしていたため，どんな UserAgent なのかを確認した．ローカル環境に nginx を起動して，Markdown に http://localhost を追加したところ，以下のような UserAgent だった．UserAgent を指定できる設定があっても良さそう．

HEAD node-fetch/1.0 (+https://github.com/bitinn/node-fetch)
GET  node-fetch/1.0 (+https://github.com/bitinn/node-fetch)

Method に関しては，基本的に HEAD を使って，エラーになった場合に GET にフォールバックする実装になっている．また .textlintrc で preferGET を有効化した場合は最初から GET になる．

まとめ

• textlint のルール「textlint-rule-no-dead-link」を使うと「リンク切れ」を検知できる
• ドキュメントレビューを効率化できる
• デフォルトだとリダイレクトもエラーになる
  • リダイレクトを自動的に修正できる --fix オプションもある

楽しく成長できるモビングを目指そう /「モブプログラミング・ベストプラクティス」を読んだ

2月に出版された「モブプログラミング・ベストプラクティス」をさっそく読んだ．僕はモブプログラミングの経験があり，例えばインフラ構築など，プログラミング以外の場面でも「モブ」のエッセンスを取り入れてタスクを進めることも多いけど，本書の目次を見て興味を持った部分もあり，読むことにした．本書の読者層は非常に多岐にわたると思う．モブプログラミング未経験者は是非読むべきだと思うし，モブプログラミング経験者でも新たな気付きが得られると思う．日本語で読める貴重な1冊！

モブプログラミング・ベストプラクティス ソフトウェアの品質と生産性をチームで高める

目次

• 第1章 : なぜモブプログラミングなのか
• 第2章 : モビングの始め方
• 第3章 : モビングと人
• 第4章 : モビングの軌道修正
• 第5章 : 定期的なモビングのための仕事場の改造
• 第6章 : モビングを定着させるためのチームへの働きかけ
• 第7章 : フロー重視の考え方
• 第8章 : モビング定着後の長期的な展望

モブプログラミング関連本

モブプログラミング関連本だと，過去に「Getting Started with Mob Programming」を読んで，書評を書いた．しかし，現在「Getting Started with Mob Programming」は出版停止になっていて，著者の Mark Pearl 氏は新しく「Code with the Wisdom of the Crowd」を出版している．今回読んだ「モブプログラミング・ベストプラクティス」の原著は「Code with the Wisdom of the Crowd」となる．

pragprog.com

よって，本書は「Getting Started with Mob Programming」と同じ内容もあり，部分的に重複するため，以前の書評記事も合わせて読んでもらえればと思う．今回は新たに学ぶことができた点を中心に書評を書きたいと思う．

kakakakakku.hatenablog.com

成功をどのようにして計測するか

第1章に「成功をどのようにして計測するか」という内容があり，重要なのは「短期的にベロシティは下がる可能性がある」ことを理解することだけど，具体的に定量的な指標が紹介されていた．個人的な経験だと，GitHub の Issue など，開発タスクのリードタイムを計測すると，確実に短くなっていることを可視化できた．さらに定量的な計測は難しいけど，モブプログラミングを導入して，プロジェクトがうまく回るようになると，メンバーの表情も大きく変わると思う．デイリースタンドアップのときにメンバーの表情を見渡して，モチベーションを感じるような雰囲気であれば，ある意味では「成功」と言えると思う．

• マージコンフリクトの解決にかかる時間の短縮
• 本番システムに入り込む欠陥の数の減少
• チーム内の経験の浅いメンバーの学習度の上昇
• チームがモブプログラミングの導入を改善と感じているかどうか

タイムボックス付きの探求

第4章では，新しい技術スタックを採用して，チームにエキスパートがいない状態など，ある程度手探りでモブプログラミングを進める場合に「タイムボックス付きの探求」というテクニックが紹介されていた．今までの経験上，モブプログラミング中に一部のメンバーが調査をすることもあったけど，内容によっては調査が長くなり，モブセッションから離脱したような状況になってしまうこともあった．そこで「モブセッションを調査のために使う」ことにより，全員でドキュメントを読んだり，プロトタイプを実装したりして，気付いた情報を共有することにフォーカスできる．今後「タイムボックス付きの探求」を試してみたいと思う．

リソース効率とフロー効率

第7章では，モブプログラミングの価値を理解するために必要な「リソース効率」と「フロー効率」の説明もある．フロー効率の重要さを説明している本はあまり見たことがなく，素晴らしいと思う．去年にプロジェクトリードの事例で登壇したときにも話したけど，無理に1人1人にタスクを分割していたり，今すぐ必要ではないタスクに着手していたりすると，もしかしたら「リソース効率」を優先している可能性がある．

「さぁ！今すぐプロジェクトリーダーに立候補しよう」の登壇資料は以下にある．

kakakakakku.hatenablog.com

さらに第7章には，個人的に考えさせられる以下の記載がある．

リソース効率を重視すると、スペシャリストとボトルネックが作られるのに対し、フロー効率を重視すると、ゼネラリストが作られ、機能を早く市場に送り出すことに力を入れられるようになる。

観点によっては「モブプログラミングだとスペシャリストを目指せなくなる」と言われる可能性もあるけど，必ずしもそうではなく，スペシャリストは目指せると思う．モブセッション中はメンバー全員のスキルをボトムアップで伸ばしつつ，メンバーごとの得意領域をさらに伸ばせるように新しい技術スタックの採用などを任せるなど．過去には「スキルマップ」を運用したことがある．

「プロジェクトをリードする技術」の登壇資料は以下にある．

kakakakakku.hatenablog.com

デイケアモブ

第8章には「デイケアモブ」の話題も少し入っている．個人的には「デイケアモブ」という表現はあまり好きではないけど，重要なのは「エキスパートがビギナーの教育にフォーカスしすぎていて，本来のスキルを発揮できていないのでは？」ということで，モブプログラミングに限らず，よくある場面だと思う．良し悪しではなくバランスだと思うけど，メンバーが増える場面など，意識しようと思う．

タイマー

第2章にモブプログラミングで使うタイマーアプリが2個紹介されていた．

• You're using an old link. | Jahed Ahmed
• GitHub - pluralsight/mob-timer: A mob programming application

ただ過去に紹介記事を書いた Mobster もあるし，単純にポモドーロとしてタイムボックスを決めるならウェブタイマーを使えば良いと思う．個人的には複雑なことはせず，ウェブタイマーを使うようにしている．

• Tomato Timer
• Timer | fvstr.jp

kakakakakku.hatenablog.com

オススメ YouTube

「A day of Mob Programming」を観ると，モブプログラミングを実施しているチームの1日の流れを知ることができる．2012年に既にモブプログラミングを実施しているなんて素晴らしすぎる！

www.youtube.com

さらに4年後の2016年に公開された「A day of Mob Programming 2016」も観ることができる．モブプログラミング環境の参考にもなるし，オフィスの様々な場所で並行してモブプログラミングが実施されていることがわかる．壁にある物理カンバンも気になる！

www.youtube.com

モブプログラミングで有名な Woody Zuill 氏の講演も非常に刺激になる．なぜ「Working Together」が必要なのか？など，モブプログラミングの解説もあるし，様々な会社でモブプログラミングを実施している風景の紹介もあるし，参加者との質疑応答もある．オススメ！

www.youtube.com

まとめ

• 2月に出版された「モブプログラミング・ベストプラクティス」を読んだ
• モブプログラミング未経験者／モブプログラミング経験者など，本書の読者層は非常に多岐にわたる
• モブプログラミングに興味があるなら是非読んでみると良いのでは！

モブプログラミング・ベストプラクティス ソフトウェアの品質と生産性をチームで高める

関連記事

モブプログラミングの事例は去年「ランサーズ開発ランチ」でも登壇させて頂き，登壇資料を公開している．

kakakakakku.hatenablog.com

Jupyter Notebook に環境変数を設定する

最近 Jupyter Notebook を使って Python コードを実装しているときに，設定値を直接コードに書くのではなく，環境変数から取得する必要があった．小ネタとして「Jupyter Notebook に環境変数を設定する方法」をまとめておく．結論として，今回は direnv を使うことにした．

jupyter.org

Shell 変数を設定する

サンプルとして，環境変数 BLOG_URL を設定することにする．1番お手軽に実現する場合は，Shell 変数を設定して Jupyter Notebook を起動する．設定する環境変数が少なければ，Shell 変数でも良さそう．

$ BLOG_URL='https://kakakakakku.hatenablog.com' jupyter notebook

export で環境変数を設定する

設定する環境変数が多くなる場合は，事前に export してから Jupyter Notebook を起動する．

$ export BLOG_URL='https://kakakakakku.hatenablog.com'
$ jupyter notebook

direnv を使う

繰り返し実行する場合は，自動的に export したくなる．今までもよく使っていたけど，direnv を使うと環境変数の管理が楽になる．もし direnv を使ったことがない場合は，brew から簡単にインストールできる．

$ brew install direnv
$ direnv --version
2.19.2

github.com

今回は .envrc に環境変数を設定した．なお .envrc には認証情報などを設定する場合が多く，誤って GitHub などに push しないように .gitignore に追加しておくこと．他にも awslabs/git-secrets を使うなど，防御策もある．

$ cat .envrc
export BLOG_URL='https://kakakakakku.hatenablog.com'

direnv を使う場合は，そのまま Jupyter Notebook を起動する．

direnv: loading .envrc
$ jupyter notebook

Jupyter Notebook Config に設定する

以下のコマンドを実行すると ~/.jupyter/jupyter_notebook_config.py に Jupyter Notebook 自体の設定ファイルが自動生成される．デフォルトでは全てコメントになっている．

$ jupyter notebook --generate-config

jupyter-notebook.readthedocs.io

Jupyter Notebook の起動時に実行されるため，例えば以下のように書いておくと，環境変数を設定できる．jupyter_notebook_config.py はデフォルトだとホームディレクトリに自動生成されるけど，Jupyter Notebook を起動するディレクトリに置くと優先される．ただし，あくまで Jupyter Notebook 自体の設定ファイルなので，コードのための環境変数を設定する用途は適切ではないと思う．

import os
os.environ['BLOG_URL'] = 'https://kakakakakku.hatenablog.com'

まとめ

今回は「Jupyter Notebook に環境変数を設定する方法」をまとめた．direnv を使うことにしたけど，要件によっては Shell 変数で十分な場合もあると思う．よって，以下のように Python コードで環境変数から設定値を取得できるようになった．

import os
os.environ['BLOG_URL']

せっかくサンプルとして BLOG_URL を取得できるようになったので，Selenium を使って「kakakakakku blog」のトップページをキャプチャして，Jupyter Notebook に表示できるようにして遊んだ．Jupyter Notebook 本当に便利！

ブログ記事のクオリティに悩む人に読んで欲しい /「理科系の作文技術」を読み直した

2017年12月から「ブログを楽しく習慣化して書く」ことを支援するために「ブログメンタリング活動（完全無料）」をしている．既に1年以上継続していて，現在メンタリング中のメンティを含めると，計20名を超えている．「ブログを楽しく習慣化して書く」ことを支援するとは言え，メンタリング希望者は経験値によって違う課題意識を持っている．例えば「習慣化したい」というライフスタイルに課題意識を持っている人もいれば，「もっと多くの人にブログを読んで欲しい」という自己ブランディングに課題意識を持っている人もいる．その中でも特に多いのが「ブログ記事のクオリティを上げたい」という課題意識だったりする．

「ブログ記事のクオリティ」とは？

ブログ記事に「正解」はなく，誰が書いても違った良さがある．むしろ，ブロガーとしてオリジナリティを追求することも大切だと思う．さらに「ブログ記事のクオリティ」という言葉も定量的に表現しにくく，例えば PV などを指標にすることはできるけど，適切とは言えず，悩ましくもある．そこで「ブログ記事のクオリティ」を「情報を適切に伝えられること」と仮に定義するならば，「理科系の作文技術」を読むべきだと思う．現在の何倍もブログ記事のクオリティを上げることができる．

僕がはじめて「理科系の作文技術」を読んだのは，大学時代に論文（情報処理学会など）を書いていた2006年で，当時所属していた研究室の先輩に紹介してもらった．既に10年以上も経過しているけど，今でも定期的にパラパラと読んでいる．そして，今まで本書の書評記事をブログに書いていなかったことに気付き，今回改めて読み直した．よって今回は「ブロガー目線として」書評を書くことにした．

理科系の作文技術 (中公新書 (624))

目次

• 第1章 : 序章
• 第2章 : 準備作業（立案）
• 第3章 : 文章の組立て
• 第4章 : パラグラフ
• 第5章 : 文の構造と文章の流れ
• 第6章 : はっきり言い切る姿勢
• 第7章 : 事実と意見
• 第8章 : わかりやすく簡潔な表現
• 第9章 : 執筆メモ
• 第10章 : 手紙・説明書・原著論文
• 第11章 : 学会講演の要領

「理科系の人が書く仕事の文書」とは？

第1章「序章」では，そもそも「理科系の人が書く仕事の文書」として，大きく2種類の分類が紹介されている．本書の出版は1981年で，当時は「ブログ」という言葉がなかったと思うけど，個人的にはブログは「B 類」に該当すると考えている．特に「B-4」や「B-7」などはブログの特性と似ている．よって，ブロガーにとって本書が有用であると言える．

• A 類 : 自分だけが読むもの
  • A-1. メモ，手帳の類
  • A-2. 実験ノート，野帳（野外観察用の記録帳），仕事日記の類
  • A-3. 講義や講演を聞いてつくるノート，文献のぬき書き
  • A-4. カード類
  • A-5. 講義や講演をするためのノート
• B 類 : 他人に読んでもらうもの（仕事の文書）
  • B-1. 用件の手紙やメモの類
  • B-2. （所属機関内の）調査報告，出張報告，技術報告の類
  • B-3. 仕様書の類
  • B-4. 答案，レポート
  • B-5. 研究計画などの申請書
  • B-6. （学会誌などへの）原著論文，総合報告
  • B-7. その他の論説，解説，著書の類
  • B-8. 構造説明書，使用の手引

目標規定文

第2章「準備作業（立案）」では，文書を書く前に準備をする必要性が書かれている．特に重要なのが「目標規定文」で，これは「何を目標に文書を書くのか？」を事前に整理することを意味する．目標規定文を準備せずにブログ記事を書いてしまうと，書きながら軸がブレてしまう可能性がある．僕はブログ記事を書く前に，目標規定文（もしくは代替となるマインドマップ）を準備して，Trello タスクに記載するようにしている．さらに目標規定文を準備しておくと，ブログ記事の顔とも言える「タイトル」を決めるときにも役立つ．

パラグラフ

第4章「パラグラフ」では，文章の構成要素として，どのように「パラグラフ」を分割するべきか？という内容が書かれている．本書にはパラグラフの目安として「200-300字」と書いてあるけど，重要なのは「パラグラフの中で何を伝えたいのか？」であり，パラグラフを要約した文章を「トピック・センテンス」と言う．

「トピック・センテンス」を意識することにより，長くなったパラグラフに気付くことができたり，短すぎて不要なパラグラフに気付くことができる．また「トピック・センテンス」はパラグラフを要約した文章と表現することもでき，「目標規定文」と組み合わせることにより，必要最低限な文章構造を築くことができる．「パラグラフ」と「トピック・センテンス」を意識しながらブログ記事を書くと，文章が引き締まる．

ブログ記事を声に出して読む

第8章「わかりやすく簡潔な表現」は，本書の中で特に好きな章で，個人的にも1番意識している．章立ては以下となっている．

• 8.1 : 文は短く
• 8.2 : 格の正しい文を
• 8.3 : まぎれのない文を
• 8.4 : 簡潔
• 8.5 : 読みやすさへの配慮
• 8.6 : 文章の中の区切り記号
• 8.7 : 私の流儀の書き方

まず「格の正しい」とは，言葉の繋がりが適切な文章のことを言う．以下の例文（本書から引用）を見るとわかる．正しそうに見えるかもしれないけど，文末に「私は」に対応する「と思う」を追加しないと，文章として成り立たない．句読点が続く長文を書いてしまったり，主語が曖昧な文章を書いてしまうと，このように「格の正しさ」が失われる傾向が強くなると思う．

私は，この点を考えると○○氏の提出したモデルは現象を単純化しすぎている（と思う）．

次に「まぎれのない」とは，曖昧な修飾を避けた文章のことを言う．以下の例文（本書から引用）を見るとわかる．「黒い」や「きれいな」など，どこを修飾しているのかが曖昧で，読み間違えてしまう可能性がある．ある程度は文書のコンテキストによって明確になるとしても，できる限り曖昧な修飾を避けないと，読みにくくなってしまう．

黒い目のきれいな女の子がいた

第8章では，他にも以下の内容なども記載されている．個人的には漢字は積極的に使っていて，本書に書かれているような「字面の白さ」は意識していない（「普通 → ふつう」など）．

• 並記（箇条書きを活用する）
• カッコ（強調をするなど適切に使う）
• 漢字（字面を白くするために一部の漢字を平仮名にする）

本書にも書いてある通り，レビュー時に実際に文書を声に出して読むと，違和感に気付けるようになる．僕はブログ記事を公開する前に何度も読み直し，何度も声に出して読んでいる．すると，より良く書き直すことができる．

textlint-rule-preset-ja-technical-writing

「理科系の作文技術」とは直接関係はないけど，textlint を使っているなら textlint-rule-preset-ja-technical-writing を合わせて使うと，文書を読みやすく維持できる．例えば，読点の個数を制限することもできる．

github.com

まとめ

「ブログ記事のクオリティ」を「情報を適切に伝えられること」と仮に定義するならば，「理科系の作文技術」を読むべきだと思う．今回紹介した内容以外にもたくさん意識するべき内容が書かれている．そして，個人的には「ブログ記事を声に出して読む」ことをオススメする．名著を吟味しつつ，さぁ！今週もブログを書くのだ！

理科系の作文技術 (中公新書 (624))

Podcast

ブログメンタリングに関しては Podcast でも話してるので，興味があれば是非！

fukabori.fm