はじめに
PRのコメントや設計レビューの返答を書いていて、読み返したときに「なんか読みにくいな」と感じることはないでしょうか。
情報は足りている。伝えたいことも明確。でも、一文の中で何がどこにかかっているのかわかりにくい。自分で書いた文章なのに、読み返すと引っかかる。
自分もそうでした。特に設計書のコメントで「こういう理由でこの方式にしました」と書くとき、理由と結論と補足が一文に混ざってごちゃごちゃになりがちです。書いた後に校正していると、「言いたいことは合ってるけど、なんか読みにくい」という文がよく出てきます。試しに語順を入れ替えてみると、同じ内容なのに急に読みやすくなる。
この「読みにくさ」の正体は何なのか。『日本語の作文技術』を読んで、それが修飾語の並べ方、つまり語順の問題だと気づきました。
本記事では、修飾語の語順の原則と、エンジニアの日常文書でどう活かせるかを書きます。
修飾語の語順の原則
『日本語の作文技術』では、修飾語の並べ方について4つの原則が示されています。本記事ではその中でも特に効果が大きい2つを紹介します。
原則1: 長い修飾語を先に、短い修飾語をあとに
複数の修飾語がひとつの言葉にかかるとき、長いものを前に、短いものを後ろに置きます。
たとえば、こんな文を書いたとします。
新しい認証方式に既存のユーザー情報を使って段階的に移行する計画を検討しています。
読めなくはないですが、一読で意味が取れるかというとちょっと引っかかります。「新しい」はどこにかかるのか。「既存のユーザー情報を使って」は何にかかるのか。「段階的に」は「移行する」と「検討しています」のどちらにかかるのか。
修飾語が複数あって、それぞれのかかり先が曖昧になっています。ここで長い修飾語を前に出してみます。
既存のユーザー情報を使って新しい認証方式に段階的に移行する計画を検討しています。
「既存のユーザー情報を使って」という長い修飾語を前に出しただけです。内容は同じですが、かかり先の曖昧さが減っています。
長い修飾語が後ろにあると、途中まで読んだ時点で「これはどこにかかるんだろう」と読者が迷います。長いものを先に消化してしまえば、後ろに残った短い修飾語は自然とすぐ近くの言葉にかかるので、迷いにくくなります。
もうひとつ例を見てみます。
開発コストが高いリアルタイムの複雑なデータ同期処理を実装する必要があります。
これを長い順に並べ替えると、
開発コストが高い複雑なリアルタイムデータ同期処理を実装する必要があります。
「開発コストが高い」が一番長いので先頭に。「複雑な」が次に来て、「リアルタイム」は「データ同期処理」とくっつきます。修飾語の長さ順に並べるだけで、何がどこにかかるかが見えやすくなります。
原則2: 節を先に、句をあとに
「節」は述語（動詞）を含む修飾語です。「〜した」「〜している」のように、動詞が入ったかたまり。「句」は述語を含まない修飾語で、「新しい」「昨日の」のように動詞が入らないかたまりです。節のほうが長くて複雑なので、先に置きます。
白い昨日届いた分厚い封筒を開けた。
「昨日届いた」は節（動詞「届いた」を含む）、「白い」「分厚い」は句です。節を先に出すと、
昨日届いた白い分厚い封筒を開けた。
「昨日届いた」が「封筒」にかかることがすぐわかります。元の文だと「白い」が何にかかるのか一瞬迷いますが、節を前に持ってくるだけで解消されます。
エンジニアの文書でも同じことが起きます。
古い毎日深夜に自動実行されるログ削除バッチを停止しました。
「毎日深夜に自動実行される」（節）を先に出すと、
毎日深夜に自動実行される古いログ削除バッチを停止しました。
かかり先が明確になります。
この2つの原則は要するに「重いものを前に」ということです。長い修飾語、述語を含む複雑な修飾語を前に持ってきて、短くて軽いものを後ろに残す。それだけで、かかり先の曖昧さはかなり解消されます。
エンジニアの文書で試してみる
実務でありそうな文を使って、語順を変えてみます。
PRコメント
ユーザーから報告があった本番環境で発生している決済エラーの原因を調査して修正しました。
「ユーザーから報告があった」「本番環境で発生している」「決済エラーの」と修飾語が連なっていて、それぞれのかかり先が見えにくいです。長い修飾語を整理すると、
本番環境で発生している決済エラーについて、ユーザーから報告があった原因を調査して修正しました。
「本番環境で発生している決済エラー」をひとまとまりにして、「について」で区切ることで構造が見えます。
Slackでの報告
昨日相談した件ですが、パフォーマンスの問題がある現行のAPIを新しいエンドポイントに段階的に切り替える方針で進めようと思います。
変更点は小さいですが、「パフォーマンスの問題がある現行のAPI」で一度区切ると読みやすくなります。
昨日相談した件ですが、パフォーマンスの問題がある現行のAPIについて、新しいエンドポイントに段階的に切り替える方針で進めようと思います。
「パフォーマンスの問題がある現行のAPI」をひとまとまりとして区切ることで、後半の「新しいエンドポイントに段階的に切り替える」が「方針」にかかることが明確になります。
設計ドキュメント
ユーザーが入力したメールアドレスの形式を確認する既存のバリデーションロジックに加えて、重複チェックを行う新しい処理を追加します。
「重複チェックを行う新しい処理」は、「新しい」が「処理」と「重複チェック」のどちらにかかるか一瞬迷います。「新しく」を「追加します」の近くに移すと、
ユーザーが入力したメールアドレスの形式を確認する既存のバリデーションロジックに加えて、重複チェックを行う処理を新しく追加します。
「追加する行為が新しい」ことが明確になります。
どの例も、情報は変えていません。語順を入れ替えただけです。一文が長くなって「なんか読みにくい」と感じたら、修飾語の語順を疑ってみてください。それだけで改善することは多いです。
読点の打ち方
修飾語の語順とセットで意識したいのが、読点（テン）の打ち方です。
『日本語の作文技術』では、読点について明確な原則が示されています。長い修飾語が2つ以上並ぶとき、その境界にテンを打つ。「なんとなく息継ぎで打つ」のではなく、修飾語の境界を読者に示すために打つ、という考え方です。
先ほどの例でいうと、
既存のユーザー情報を使って新しい認証方式に段階的に移行する計画を検討しています。
この文に読点を入れるなら、「既存のユーザー情報を使って」と「新しい認証方式に」の境界です。
既存のユーザー情報を使って、新しい認証方式に段階的に移行する計画を検討しています。
読点ひとつで、修飾語のまとまりが見えやすくなります。
正直に言うと、自分はこの原則をまだ十分に実践できていません。書いている最中に読点の位置まで意識するのは難しく、校正の段階で「ここにテンを打った方が読みやすいかも」と気づく程度です。ただ、「読点は構造を示すもの」という考え方を知っているだけで、迷ったときの判断基準にはなっています。
おわりに
「読みにくい」の原因は、語彙力でも文章力でもなく、語順という技術的な問題であることが多いです。
修飾語を長い順に並べる。節を句より先に置く。それだけで、同じ情報量の文が読みやすくなります。
特にPRコメントやレビューの返答のように、説明しようとして一文に情報を詰め込みがちな場面で効果があります。書いた後に読み返して、修飾語の語順を確認する。小さな習慣ですが、「なんか読みにくい」が減るのを実感できると思います。
参考
- 『〈新版〉日本語の作文技術』本多勝一（朝日文庫）