↑に収録されている「なぜエンジニアは文章が下手なのか（以降、該当記事）」を読んで大切だなと思ったことを、自分の理解を織り交ぜながら整理したメモです。
文章を上手になった方がいい理由
自分の知識や技術力を最大限に活かすためです。
システムを企画/設計/実装/運用していくためには様々な文章を書く必要があります。システム自体はプログラムで動きますが、そのシステムを使う人間を動かすためには文章が必要になります。
誰しも一度は他エンジニアが書いた文章をわかりにくい、と感じたことがあるのではないでしょうか？
「文章が下手」について考える
「文章が下手」とは具体的にどういうことなのでしょうか？
該当記事では、文章力（文章の表現技術）と「異文化コミュニケーションの問題」を挙げています。後者の問題は、文章に限ったことではなく、人対人のコミュニケーション全般に対して言えることであり、文章力以前の課題として位置付けられています。なので、本記事ではより重量な後者について説明します。
具体的には、以下が紹介されています。
- 知識のギャップ
- 目的のギャップ
- 責任転嫁の誘惑
それぞれ見ていきましょう。
知識のギャップ
読み手が知らないことを知っている前提で書くことを指します。
典型的なのは、読者が知らない専門用語を使ってしまうケースです。例えば、エンジニアにとっては日常用語であっても、ユーザにとってはそうではないことが挙げられます（逆も然り）。専門用語に加えて、一般的な用語を特定の世界（業界や企業、部署など）では特別な意味で使っているケースもあります。
目的のギャップ
読み手の目的を認識していないことを指します。
例えば、経営層にツール導入の打診することをイメージしてみましょう。その場合、相手の関心は「社内の適切な業務環境をコスト低く維持すること」である場合が多いです。いくらそのツールの機能（技術的な細部）を説明しても、経営層が判断するための情報を提示しないと意味がありません。
責任転嫁の誘惑
読み手が一方的に「書き手の問題」として捉えることを指します。
例えば、エンジニアとユーザについて考えてみましょう。両者には、IT知識と業務知識のギャップが存在します。その知識ギャップによって起こるわかりづらさに対して、「この説明文を理解できないのは、前提知識がなくてもわかるように書かれていないから」つまり「自分は悪くない、相手が悪い」と捉えてしまうと、問題は一向に解決しません。理想としては、お互いの知識ギャップを埋めるために、意思疎通を図る必要があります。
文章を使わない
もう一つ文章力以外の観点で気を付けることがあります。
それはそもそも文章で表現するべき内容なのか？ということです。
システムを企画/設計/実装/運用していくためには様々な文章を書く必要があります。システム自体はプログラムで動きますが、そのシステムを使う人間を動かすためには文章が必要になります。
冒頭で上記のように書きました。実は該当記事では「文章」ではなく「文書」と書かれています。「文章」と「文書」の違いは何なのでしょうか？
該当記事では、以下のように説明されています。
- 文章：文字だけで書かれている
- 文書：文章に加えて図表を含めて書く
つまり、ある内容を図表で表現するか検討する余地があるということです。全てを文章で表現しなければならないわけではありません。
文章と文書の違いは単純なものですが、適切に使いこなせていますか？ 無意識のうちに文章だけで書いてしまっているケースが多いのではないでしょうか？
基本的に「枝分かれのある情報」を「文章」で表現するのは不向きです。複雑な概念や仕組みであれば尚更です。その論理構造に応じて、表現手段を使い分ける必要があります。
実践する内容について整理する
ここまで挙がってきた問題点への対応を整理すると、以下になります。
今回対象としている部分を赤枠で囲みました。
それぞれ詳しく見ていきましょう。
双方の成長を促すための基本姿勢を示す
この問題において大事なのは「相手のことを理解しようとする姿勢」になります。
具体的には、2つのメッセージを送る必要があります。第1のメッセージとして「私はあなたの世界のことをよく知りたいと願い、行動してます」と送ります。その結果、相手は「この人は私たちのことをわかってくれる、少なくともわかろうとしてくれる人だ」と認識します。その上で、第2のメッセージとして「こちらの世界のことをも知ってください、役に立ちますよ」を送ります。
前提として「外の人間」と思っているため、自分の理解力のなさを棚に上げて責任転嫁という発想をするようになります。上記ができると、相手は自分にとって「仲間」になります。「仲間」は自分ができないことをやってくれる貴重な存在であり、責任転嫁の対象ではなくなります。
「誰が何のために読むものか？」を考える
誰が読むのかに応じて、その人の関心事（目的）を考え、それに応えるような情報を含めます。
具体例を挙げてみます。
- 仮にIT予算の増加に悩んでいる経営層向けであれば、ツールによりIT予算に対してどのようなインパクトがあるのか
- 機器故障によるダウンタイムに悩んでいる運用管理者向けであれば、ツールによりシステム全体の可用性にどのようなインパクトがあるのか
では、具体的にどのようなことを意識すればいいのでしょうか？
該当記事で紹介されているのは、機能（function）と利益（benefit）を区別することです。
意識するべき型は、「サービスが対象に機能をもたらし、その結果ユーザに利益をもたらす」という関係です。
例えば、「サーバ性能計測ツール（サービス）がサーバ（ターゲット）に性能の数値化（機能）をもたらし、将来の性能変化を精度良く予測できることで、サーバの増強計画を精度良く立案でき、結果コストダウン（利益）をもたらします。
エンジニアは「機能がどのような仕組みで成り立つのか」という機能をより深く掘り下げる方に意識が向きがちです。一方で、ユーザ側の人間に対しては、「利益から話をすると通じやすい」のです。
また、目的の違う複数の読者を想定する場合は、文書の構成を把握しやすいように見出しをつけます。そうすることで。読み手が自分の関心のある部分を素早く見つけられるようになります。複数の意味合いが混ざっている場合にはそれらを分離して明記しておくべきです。例えば、見出しの組み合わせとしては「機能」と「利益」、「操作」「意味」などです。
使う用語を注意深く選択する
用語リストを作る方法が紹介されています。
まずテーマを決めたら、そのテーマを説明するために必要な用語のリストを作ります。その用語について、想定する読者が知っていそうかをチェックします。用語リストを作って「この用語はあの人に通じるかな？」と考えていきます（実際に想定する読み手に確認できる場合はそうしましょう）。
その用語の解説が必要なのか、そもそも用語の見直しが必要なのか確認してきます。相手が目的を達成するために必要な情報は何か、という視点で考え直します。厳密な用語ではなくても適切な用語を選べることがあります。
次に、用語を使う適切な順番を考えます。自分の知らない用語が説明されない状態で、話が進行していくと「この用語の意味は何だろう」と不安を抱えたまま先を読むことになり、理解を妨げてしまいます。不安を感じながら読む区間が長いほど読み手の負担は大きくなります。そうしたことを避けるために、適切な順番で説明をしていきましょう。
また、専門用語の解説が必要である場合には、脚注に外出しすることを検討します。解説説明を入れながら主文を書いていると、どうしても本題の趣旨が把握しづらくなります。重要なのは「主文が大事で、脚注は必要に応じて読めばいい」ということを表現してあげることです。
適切な表現手段を使う
文章を書き始める前に、まず伝えたい情報を整理分析し、論理構造を見極めて、最も適切な形で表現しましょう。
では、具体的に何をすれば良いのでしょうか？
ここでは「既存の文章を図解していくこと」を想定して説明していきます。
次に大まかな流れのイメージを載せます。
整列というのは、簡単に言うと「ストーリーを作ること」です。人間はストーリーがあると内容を理解しやすいです。文章の場合そのストーリーが曖昧になっている（把握しづらい）ケースがあるため、自然なストーリーになるよう整列します。
ラベリングは、分類した情報に見出しを付けることです。自分の経験上、「ラベリング」は「分類」の時点で済んでしまうことが多い印象なのですが、該当記事の内容に沿っています。
何となくイメージできたでしょうか？
例えば、情報セキュリティの概念について図解してみましょう。
機密性 機密性（Confidentiality）とは、許可された者だけが情報にアクセスできるようにすることです。許可されていない利用者は、コンピュータやデータベースにアクセスすることができないようにしたり、データを閲覧することはできるが書き換えることはできないようにしたりします。
完全性 完全性（Integrity）とは、保有する情報が正確であり、完全である状態を保持することです。情報が不正に改ざんされたり、破壊されたりしないことを指します。
可用性 可用性（Availability）とは、許可された者が必要なときにいつでも情報にアクセスできるようにすることです。つまり、可用性を維持するということは、情報を提供するサービスが常に動作するということを表します。
この流れはあくまで自分の理解です（皆さんもぜひやってみてください）。
分解では、それぞれの概念を個別に分けて考えます。
分類では、各概念において力点が置かれているキーワードを挙げてみます。機密性は「利用者」、完全性は「保有する情報」、可用性は「アクセス」に関する内容であることがわかります。
整列では、上記のキーワードを一直線に並べるとしたらどういう順番が適切か考えます。自然に理解できる並びとしては、「利用者」が「保有する情報」に「アクセス」する流れが考えられます。
ラベリングでは、上述のキーワードが出ているため、特に不要な理解です。
結果としては、次の図が出来上がるイメージです。
文章で説明されるよりも理解しやすいですね。
その他ノウハウ
書籍・雑誌、ブログなどの執筆経験豊富なエンジニアからのノウハウが紹介されていました。ここまで対象としていた文書とは少し違う印象を受けましたが、文書であることに変わりはないので役に立ちそうです。印象に残っているものを紹介します。
プログラミングとの共通点
プログラミングと文章を書くことには、いくつかの共通点があります。
これらを意識することで、両スキル向上の相乗効果が期待できます。また、文章を書くことに対する認識が改まって、モチベーション向上にも繋がると思います。
読みやすさ
まず成果物について共通点があります。
読みやすさによって、その価値が大きく変わってきます。わかりにくく伝わりにくい文章が好まれないのと同様に、見通しが悪く何をやっているのか理解しにくいコードは、読んでいる人を不快にさせ、バグの温床となります。
作業過程
その作業過程にも共通点があります。
一度動作するようになったコードをリファクタリングしていくのは楽しい作業です。一方、完成に程遠い状態で細かなリファクタリングばかりしていると、いつまでも仕事が終わらないように思えてストレスを感じます。文章も同じことが言えます。一通り文章を書き終え、読み手の立場になって推敲していくのは楽しいことです。一方、まだ全体の一部しか書けていないのに細かい表現を直して読み返してを繰り返していると、同じようにストレスを感じます。
また、自分の思考過程を目に見える形へ落とし込みながら、物事を考えていく点も同じです。脳の短期記憶だけではアイデアがすぐ揮発してしまうところを、自分が考えたことをテキストとして外部に永続化し、それを足がかりにまた次の思考を始めます。漠然としかイメージできなかった文章の構成が、書いているうちに少しずつ見えてくる、という経験は誰しもあるのではないでしょうか？
スキル向上
上手になるための過程も共通点があります。
プログラミングにおけるテクニック（例. デザパタ）は、実際に使いながらその使い所を学んでいきます。文章についても同じことが言えます。構成の仕方であったり、用語の使い方は、実際に文章を書く中でその使い方を身に付けていきます。
良い文章を書くためには、ただ漠然と書くのではなく、良い文章を書くことを意識することが大切です。「良い文章とは何か」を具体的にした上で取り組みます。例えば「読み手の思考を邪魔しない論旨が明確な文章」などテーマを決めてみましょう。
そして、より多くの文章を書くことに尽きます（そして可能であればレビューしてもらいましょう）。プログラミングと同じように、文章も書くことで慣れて、短い時間でスラスラ書けるようになっていきます。
文章を書くときのステップ
ブログなどの記事を書くときのステップとして、以下が紹介されていました。
- テーマ決め
- まずは書きたいテーマについて決めます
- 思いつくことのリストアップ
- テーマに関連することを、思いつくだけ洗い出します
- 全体の構成を決める
- 思いついたことをどのような構成で書くかを考えます
- とりあえず終わりまで書く
- 細かい表現は後で見直すことにして、まずは終わりまで文章を書き上げます
- 推敲
- とりあえず文章が出来上がった後は、細かい表現や構成・分量の調整を行います
自分は何かしら記事を書くときには、上記のステップに倣っています。
特に、大事だなと思っているのは「とりあえず終わりまで書く」です。頭の中で思考を巡らしているだけであったり、細かい部分に目を奪われていると、あっという間に時間が過ぎていきます。とりあえず手を動かして記事を書き切ると（眠くならない笑）、目に見える形で成果物ができます。それさえできれば、その内容をベースにして、思い描いていたイメージとのギャップが確認できるし、進捗が実感できるのでモチベーション維持にも繋がります。
終わりに
実はこの本は新卒1,2年目の時に上司から読むよう勧められたものでした。たまに読み返すことはあったけれど、当時はその真意を理解できていなかったように思います。今もその余地はあると思うけれど、大分整理できた実感があるので実践していきたいです。
