私が編集するときに考えていること（2019）

 (evaparish.com)
2 ポイント 投稿者 GN⁺ 2024-04-07 | 1件のコメント | WhatsAppで共有
  • 編集とは、文章を整える前に、その文章が実際に何を伝えようとしているのか、そして読者は誰なのかを確認する作業であり、メール・文書・ブログ・小説にも同じ 基本原則 を適用できる
  • 文章の最初と最後で要点をもう一度押さえ、this/that のような指示語だけでなく名詞を添えると、読者が文脈を見失いにくくなり 明確さ が高まる
  • 不要な語を減らし、指示文は命令形にし、長い文や of/for 構文を分解すると、意味がより早く伝わる
  • 受動態・副詞・専門用語・決まり文句は、行為者や正確な意味、読者の想定範囲を曖昧にしうるため、具体的な動詞や説明に置き換えるほうがよい
  • 良い編集とは、規則を盲目的に守ることではなく、伝えたいメッセージに合わせて 言葉の選択 を意識し、不要な表現を取り除くこと

まず、文章が実際に何を言っているかを定める

  • 文単位の編集に入る前に、その文章が意図したことを実際に述べているかを先に確認する必要がある
  • 文章ごとに個人用の プリアンブル（preamble） を書いておくと、編集の基準ができる
    • 中心となる問いは「主な要点は何か」「誰のために書くのか」である
    • この情報を文書のいちばん上に書いておき、執筆・編集中に実際の内容と照らし合わせる
  • ブログ記事の要点を1〜2文で要約できないなら、一貫した文章を書くのは難しい
  • Writers Studio の創作講座では、課題ごとに意図した話者、トーン、雰囲気を含むプリアンブルを書き、評価は好みよりも 技法 と意図の達成に焦点を当てる

反復は読者をつなぎ止める仕組み

  • 要点が十分に明確に思えても、文章の最初と最後で言い直すことで、読者は論旨をより追いやすくなる
  • ドキュメントのチュートリアルは、たいてい何をするのかを紹介し、手順を示し、そのあと正しくできたかを確認する構成がよい
  • ブログ記事も、扱うテーマを紹介し、本文で展開し、最後に短い要約を置く形が適している
  • 言語レベルでも反復は必要である
    • 指示代名詞 である this、that だけを使わず、何を指しているのか名詞を添える
    • To solve this より To solve this shortage のほうが明確である
    • That will take you to the home screen より Successfully authenticating will take you to the home screen のほうがはっきりしている
  • 書き手には反復に感じられても、読者にとっては文章を追いやすくする 明確化 になる

単純化: 意味のない語をそぎ落とす

  • 編集でもっとも重要な作業は、意味に貢献しない語を取り除くことである
    • You will need to run this script は Run this script にできる
    • You can aid in readability by making sure... は Make sure... にできる
  • 特別な理由がない限り、できるだけ早く要点に到達すべきであり、過剰な語や装飾的な文構造の中に意味を埋もれさせるべきではない

  • 指示文は命令形にする

    • 指示文では You should X、You can X を動詞の 命令法 に変えるほうが簡潔である
    • You should save the file to your home directory は Save the file to your home directory になる
    • この変更は語数を減らし、読者をすぐに行動へ導く

  • of と for の構文を減らす

    • of や for が続く構文は、名詞の前に情報を置くように書き換えると、より効率的である
    • The manager of the team responsible for marketing は The marketing team’s manager になる
    • 並べ替えた文は、読者が句ごとに理解を修正しなくても、より速く意味をつかめるようにする

  • 長い文を分けることとコンマ

    • 長い文は、複数の短い文に分けたほうがよい
    • Acme プロジェクトの例では、1文の中に milestone、サーバー環境、ビルド時間の改善、XYZ plan との比較がすべて含まれており、修正版ではそれを3文に分けている
    • 修正版では、non-staging サーバーが Foobaz 環境で動いていること、ビルドが10分未満に短縮されたこと、XYZ plan では以前1時間以上かかっていたことを分けて伝える
    • 適切な位置にコンマを加えると、読者は前半を処理してから残りを読める
    • If you’re looking for me, I’ll be in my office
    • Due to the fog, our flight was delayed
    • 文頭に従属節が来るときはコンマが必要であり、このコンマは読解を助ける 処理点 になる

行為者と意味を曖昧にする表現を減らす

  • 受動態をなくす

    • 受動態は、誰が、あるいは何がその行為を行ったのかを隠してしまう
    • 受動構文を能動態に変えると、読者は行為を適切な人物や対象に結びつけられ、文がより明確になる
    • The fire alarm was pulled and the building was evacuated は、The fire marshal pulled the alarm and the employees evacuated the building のように行為者を示せる
    • Millions of dollars were embezzled from the company は、Two executives embezzled millions of dollars from the company のように誰が行ったかを明らかにできる
    • システム説明で An alert is triggered and the job is started と書くと、どのサービスがアラートをトリガーし、どのコンポーネントがジョブを開始するのかがわからない
    • 技術文書で行動の主体を示さないと 精密さ が落ちる

  • 副詞の代わりに具体的な動詞や描写を使う

    • 副詞は、ほとんどの場合、より具体的な動詞や説明に置き換えられる
    • He laughed loudly の loudly は、笑い声の大きさや感じを読者に推測させてしまう
    • 実際の意図が「店中が振り向くほど大声で笑った」ということなら、その状況を直接描写するほうが具体的である
    • Basically、Essentially のような副詞はヘッジとして使われることが多いため、削除して言いたいことを直接述べるほうがよい

読者の知識やトーンを決めつけない

  • 略語と概念の説明

    • よく知っているテーマについて書くと、読者が知らない前提を忘れやすい
    • 略語や頭字語は最初に出てきたときに正式名称を書き、括弧内に略語を入れ、その後は略語だけを使えばよい
    • TTFB は最初に time to first byte (TTFB) と書く
    • 概念が初めて出てくるときに短い説明を加えると、読者は追いやすくなる
    • TTFB は、ユーザーが HTTP リクエストを送ってから、ブラウザーが最初のバイトを読み込むまでにかかる時間を測る
    • Web サイトの応答性を示す指標として使われる
    • 必要であれば time to first byte (TTFB) metric のような追加学習用リンクを提供できる

  • トーンの一貫性

    • 文章のトーンは、口語的でもフォーマルでも、どちらかに決めて一貫して保つべきである
    • ある文がとても口語的に始まったのに学術的な表現に切り替わると、読者を混乱させたり、言いたい内容から注意をそらしたりすることがある
    • 例文は、「新しいフレームワークに最初は熱狂したが、欲しかった指標は得られなかった」のように一貫したトーンへ直せる

専門用語、決まり文句、視覚的構造を整える

  • 専門用語や決まり文句を避ける

    • ビジネスの専門用語には deep dive、low-hanging fruit のような表現があり、ほかの文章では野球の比喩のような決まり文句もよく使われる
    • 専門用語は、読者がその表現を使う内輪の集団に属していることを前提にしている
    • 英語を母語としない読者や、野球文化に親しみのない読者にとって、専門用語や決まり文句は文章を追いにくくすることがある
    • tl;dr, if you can hack something together by EOD... には略語と技術スラングが含まれており、依頼のようにも聞こえない
    • Can you deliver a prototype by the end of today? は、必要な成果物と期限を直接尋ねる 明確な依頼 になる

  • 余白と形式を活用する

    • 余白は技術文書で重要であり、ブログ記事やメールでも効果がある
    • 長い段落は、とくにコンピューター画面では読みにくく、読者が集中を失いやすい
    • 視覚的にページを区切ると、要点を見つけやすくなる
    • 長い段落は、複数の短い段落に分ける
    • 役に立つ 小見出し で構造を作り、読者が興味のあるセクションへ飛べるようにする
    • 関連する項目はリストにする
    • 参照ドキュメントのように多くの情報を伝える場合は、リストより 表 のほうがよいこともある
    • 流し読みする読者が要点をつかめるよう、太字を使う

編集哲学

  • 編集哲学は2つに要約できる
    • 副詞、専門用語、決まり文句、ヘッジに頼らず、自分が正確に意味していることを述べる
    • 不要な語をすべて取り除く
  • この2つの原則は、自分の文章を直すときにも、他人の文章を評価するときにも枠組みになる
  • 練習を重ねるうちに自分なりのスタイルや好みが生まれ、理由を理解しているなら、いくつかの推奨から外れても問題ない
  • 編集の目的は、ルールに無批判に従うことではなく、言語使用を意識し、伝えたいメッセージに合った選択をすることである

関連記事

1件のコメント

 
GN⁺ 2024-04-07
Hacker News のコメント

  • この記事を書いた本人です。多くの方に響いたようで、うれしく光栄です。記事を書いたあと、好奇心の赴くままに自分でソフトウェアエンジニアになり、数年働いてみると、文章を書く比重の大きい役割が恋しくなりました。 優れたテクニカルライター、デベロッパーアドボケイト、またはコミュニケーションの専門性と技術力を組み合わせる役割を探しているなら、知らせてください。ウェブサイトのフォーム（https://evaparish.com/contact）または LinkedIn で連絡できます。

    • この記事から本当に多くのものを得ました。より簡潔で明確に書き、よりよく理解してもらえるようにする助けになりそうです。 ただ、「I really got a lot out of the article.」と書いたあと、この文が不要なのか、明確なのか、意図したことを正確に言えているのか考えました。結局、まさに言いたかったことですし、次の文で詳しく説明したのですが、どう見えるか気になります。
    • Jean-luc Doumont の講演／ワークショップ Clear, accurate, concise writing で聞いた文章術の助言をいろいろ思い出します。
    • 例の中で HTTP を説明なしに使っていたのがかなり面白かったです。意図したジョークだったのか気になります。

  • 技術文書を読んでいて最も気になることの一つは、読者にまだ紹介されていない略語が出てくる場合です。プロジェクト文書のあちこちでこれが繰り返され、数年のうちに担当者が変わると、特定の略語が何の略なのか誰も知らない状況にまでなります。 実際、あるチームが ABC という名前のサービスを開発・保守しているのに、チームメンバーの誰も ABC が何の略なのか知らない、という奇妙な状況を何度も見ました。そういうときは、新しい名前を選んで関連文書をすべて更新する作業を避けるため、ABC を固有名詞のように扱って済ませることになります。 架空の例: CDIS 用のアクセストークンを取得するには、 の DMC に移動し、左サイドバーの「CDIS」項目をクリックして「Generate Access Token」を押し、トークンをコピーする。 むしろこう読みたい: Customer Data Indexing Service（CDIS）用のアクセストークンを取得するには、 の Data Management Console（DMC）に移動し、左サイドバーの「CDIS」項目をクリックして「Generate Access Token」を押し、トークンをコピーする。