私が第一特集「なぜエンジニアは文章が下手なのか」のうち30ページを書いた、Software Design 誌12月号が発売されました！



ざっとこんな話を書いています。
↓

Part.1　エンジニアは本当に文章が下手なのか？
　「文章力」で解決することとしないことがある
　　　その１：知識のギャップ
　　　その２：目的のギャップ
　　　その３：責任転嫁の誘惑
　根本的に分かりにくい文書はどうしても残ります
　　　「Simple is best」を盲信するなかれ

Part.2　それは「文章」で書くべき情報なのか？
　「文章」で書くことにそもそも向いていない情報も多い
　　　まず論理構造を考えてから表現方法を決める
　「データバックアップのすすめ」文例を構造化してみる
　　　「文章」は、「複雑な構造」を表現するのには向かない
　時代遅れの国語教育に引きずられるな
　文章を書くな！
　　一定の配置と注釈で論理構造を表現する

Part.3　「誰が何のために読むものか？」をまず考える
　ファンクションとベネフィットを区別する
　文書の目的によって構成ポイントが違ってくる
　　　OKかNGの判断をもらうための提案書
　　　目的と目標を区別する
　　　トラブルの経緯を説明する報告書
　　　手順への理解を得る説明書
　「わかりやすさ」至上主義の落とし穴
　　　教育用テキストでは「わかりにくい」フレーズを使う

Part.4　使う用語を注意深く選択しているか？
　「専門用語を使うな」という指針は正しいか？
　　　目的を達成するために必要な情報を考える
　　　解説が必要ならば覚悟を決めてとことん書く
　　　専門用語解説が長くなったら脚注に追い出す
　その用語は共通の意味で通用するか？
　　　「用語リスト」を作って順番を考える
　　　読者の知らない用語を2つ溜めてはいけない
　　　用語に気を使うことで、相手への理解が進む
　論理的関係を明確に示す接続詞を積極的に使うべし
　　　文学系の文章ノウハウは参考にならない
　　　「文末の表現が似てしまう」悩みを解決するには

Part.5　図解の作業は分解・分類・整列・ラベリング
　1日3分・3行ラベリングのすすめ
　　　複雑な記号を覚える必要はない
　　　「整列」とは、ストーリーを作ること
　　　適当にキーワードを拾って一直線に並べてみる
　「背景・問題・理想・現実」パターン
　　　抽象度の高低に注目する
　継続は力なり！　1日3分、ラベリング！

★　★　★　

ぜひぜひ読んで！　買って！　くださいませませ！！
以上よろしくお願い申し上げます。