|
| 1 | +--- |
| 2 | +title: "『読み手につたわる文章 - テクニカルライティング』を読んだ" |
| 3 | +tags: ["読書ログ"] |
| 4 | +keywords: ["読書ログ"] |
| 5 | + |
| 6 | +cover: "https://blog.kyu08.com/cover.png" |
| 7 | +description: "" |
| 8 | +date: 2024-06-06T00:21:05+09:00 |
| 9 | +author: "kyu08" |
| 10 | +authorTwitter: "kyu08_" |
| 11 | +draft: false |
| 12 | +showFullContent: false |
| 13 | +readingTime: true |
| 14 | +hideComments: false |
| 15 | +color: "" |
| 16 | +--- |
| 17 | + |
| 18 | +技術書典で購入した『読み手につたわる文章 - テクニカルライティング』を読んだので学びになったトピックについて書く。 |
| 19 | + |
| 20 | +## 「知らない」と書けない(P14) |
| 21 | + |
| 22 | +> こんなふうに、自転車という対象物に対する知識があれば、パーツの位置をすべて暗記していなくても自ずと正しい自転車の絵が描けるようになります。 **必要なものは絵心やセンスではなく知識なのです。** 逆に言えば、対象物を知らないと上手な絵は描けません。 |
| 23 | +> |
| 24 | +> そして自分が対象物を思っていたより「知らない」ということに、我々は気付いていないことが多いのです。上手な絵は、対象物のことを知らないと描けません。それと同じように、分かりやすい実用文は、文章力のあるなし以前に **対象物をよく知らないと書けない** のです。 |
| 25 | +
|
| 26 | +文字にすると当たり前のことのように感じるが、ブログを書いているとよく実感する。 |
| 27 | + |
| 28 | +<!-- textlint-disable ja-technical-writing/no-doubled-joshi --> |
| 29 | +<!-- textlint-disable ja-technical-writing/ja-no-weak-phrase --> |
| 30 | +技術的な内容であれば、当然対象を理解していないと書けないし、自分の考えでさえもいざ言語化しようと思うとなかなか筆が進まないことが多い。 |
| 31 | +<!-- textlint-enable ja-technical-writing/ja-no-weak-phrase --> |
| 32 | +<!-- textlint-enable ja-technical-writing/no-doubled-joshi --> |
| 33 | + |
| 34 | +そうした場合にはまず自分が何を言いたいのかを整理して理解するようにしている。 |
| 35 | + |
| 36 | +## いつまでに何をしてほしいのか書こう(P25) |
| 37 | +<!-- textlint-disable ja-technical-writing/ja-no-successive-word --> |
| 38 | +> 何の食べ物だか言わずにいきなり「食べて! ほら食べて!」とスプーンを差し出されると、「え、怖い。なになになに?」となって、とても素直に口を開く気にはなれませんし、食べたところで猜疑心で味もよく分かりません。そんなときは「初めて作ったプリンが思いのほか美味しくできたので一口食べて感想を教えてほしい」というように、どういう意図で読み手に何をして欲しいと思っているのかを先に説明してあげる必要があります。 |
| 39 | +<!-- textlint-enable ja-technical-writing/ja-no-successive-word --> |
| 40 | +
|
| 41 | +引用部分の前に書かれていた例示のエピソードがわかりすぎて無限に頷いてしまった。認知負荷が高い文章を読むのはいつだって辛い。 |
| 42 | + |
| 43 | +報告なのでただ把握だけしておいて欲しいのか相談がしたいので意見を求めているのかなど、読み手に求めるアクションを明示すると読み手の認知負荷が低くて良さそう。 |
| 44 | + |
| 45 | +結局伝えたいことが伝わらないことには意味がないので書いて満足、ではなくドキュメントを書くことの目的を見失わないようにしていきたい。 |
| 46 | + |
| 47 | +## 文書構造や文章量が適切だと分かりやすい |
| 48 | +### 2.2.1 大枠から始めてだんだん細かくしていこう(P26) |
| 49 | + |
| 50 | +> 文章で何かを説明するときには、先に大枠を理解してもらい、それから段々細かい 内容にしていくという順番を意識しましょう。 |
| 51 | +
|
| 52 | +以前上司にレビューで指摘してもらって以来意識するようになった。 |
| 53 | + |
| 54 | +コンテキストを共有していない人とコミュニケーションを取る時は特に重要だと感じている。自分と相手が持っている情報の差分を埋めるように情報を提示できるとスムーズにコミュニケーションを取れる印象がある。 |
| 55 | + |
| 56 | +### 既知から未知に繋ごう(P28) |
| 57 | +> 文章を書くとき、「大枠から詳細へ」の他に意識すべきもう1つの順番は「既知から未知へ」です。 |
| 58 | +> 技術ドキュメントを読んでいても、最初から知らない単語や知らない概念ばかりが次から次へと出てくると、「知らないことについて説明してくれているけど、その説明がまず分からない」という状態になります。 |
| 59 | +
|
| 60 | +あまり意識したことがなかった。 |
| 61 | + |
| 62 | +一度にまとまった情報量を記述したい時にはこのあたりまで意識して書くと認知負荷が減ってよさそう。 |
| 63 | + |
| 64 | +## 再利用しやすい文章にする |
| 65 | +### 2.4.2 並列はナカグロ(・)で書かない(P34) |
| 66 | +> 文章の中で並列を表そうとして「ホーム・検索・マイページ・ヘルプのタブは非表示にできません」のようにナカグロ(・)を使っていると、再利用されて箇条書きになったときに、次のような見た目になることがあります。 |
| 67 | +> |
| 68 | +> ``` |
| 69 | +> 着せかえの設定時、以下の機能は非表示にしたり、見た目を変更したりできません。 |
| 70 | +> ・ホーム・検索・マイページ・ヘルプのタブ |
| 71 | +> ・トレンドワード機能 |
| 72 | +> ・ID連携機能 |
| 73 | +> ``` |
| 74 | +
|
| 75 | +対策として、最初から箇条書きにしておくか、読点を使うといいとのこと。 |
| 76 | +
|
| 77 | +<!-- textlint-disable --> |
| 78 | +いつもどう書くか迷っていたが`・`で並列関係を表現すると上記のデメリットがあるので読点を使うようにしてみようと思う。 |
| 79 | +<!-- textlint-enable --> |
| 80 | +
|
| 81 | +### 2.4.4 リンクテキストを「こちら」にしない(P35) |
| 82 | +リンク切れになったときやテキストだけコピーされたときにリンク先がどこを指しているのかわからなくなるため、以下のようにどういったページなのかも含めて書くのがいいとのこと。 |
| 83 | +
|
| 84 | +> また「詳しくは[Shops APIのAPIリファレンス](/BankCodeAPI/reference/)をご覧ください」 |
| 85 | +
|
| 86 | +また、読み手としてもリンクを踏む前にどんなページへ飛ばされるのかわかるというメリットも紹介されていた。 |
| 87 | +
|
| 88 | +## まとめ |
| 89 | +具体的な知見が理由とセットで書いてあってとても勉強になった。[^1]チームで仕事をする上で認知負荷を下げる工夫の重要性を日々感じるのでこれから意識的に実践していきたい。 |
| 90 | +
|
| 91 | +紹介したトピック以外にもたくさんの知見が紹介されていたので気になった方はこちらからぜひ購入してみてください。 |
| 92 | +
|
| 93 | +[読み手につたわる文章 - テクニカルライティング - 技術書典マーケット](https://techbookfest.org/product/3t8AGqtB65jsPtPhx6m5fr) |
| 94 | +
|
| 95 | +[^1]: 余談だがちゃんと理由まで書かれているとスムーズに理解できるのでちゃんと背景や理由を説明するのは重要だと感じた。 |
0 commit comments