エンジニアが100%技術力を活かすための、伝わる文章を書く方法。『エンジニアのための伝わる書き方講座　文章嫌いではすまされない！』

• 書名：エンジニアのための伝わる書き方講座　文章嫌いではすまされない！
• 著者名：開米瑞浩／著
• 出版者：技術評論社

本書『エンジニアのための伝わる書き方講座　文章嫌いではすまされない！』は、ITエンジニアが技術を活かすための、伝わる文章を書く方法を学べます。
あなたがあらかじめ予想して警告したにも関わらず、会社が聞いてくれなかった。
そして予想通り「困った事態」が起きてしまい、残念な思いをした。
そんな経験はありませんか？
周囲に認められるべき存在である、本物の技術力を持ったITエンジニアにこそ、おすすめしたい１冊です。

なぜITエンジニアの声は、経営者を動かせない？

Windows XPに限らず、こういうケースはよくあります。
２年も前から警告していたのに、ITエンジニアの声が経営者（上司、他部署、顧客）に届かない。
問題が大きくなり、直前になって慌てふためく。。
ITエンジニアと経営者は、前提となる知識、常識が異なります。
例えば経営者の前提知識は、事務用PCの耐用年数だけです。
「パソコンが使えなくなる？　何を馬鹿なことを言ってるんだ、パソコンなんて５年は使えるのが普通だろうが！　どうしていきなり使えなくなるんだよ？」
一方ITエンジニアは、セキュリティリスクの大切さも知っています。
でも未だ起こっていないリスクの大きさを伝えることは、案外難しいです。
実際Windows XP問題でも、多くのITエンジニアが事前にリスクの大切さを伝えても、理解してもらえませんでした。
結果、割増料金を支払い急遽PC買い替えをする企業が続出し、ちょっとした特需が生まれたほどです。
なぜこのような特需が生まれてしまったのでしょうか？
人間は、わからないものには価値がないと判断し、知らないものを恐れるものです。
基本的に嫌いな相手の話は聞きませんし、不愉快な言い方をされると理屈が正しくても拒否したくなります。
だから解決策がいかに論理的に正しくても、それだけでは提案が受け入れられません。
ITエンジニアは、とても論理的です。
論理的であるがゆえに、伝え方を誤れば、相手は「やりこめられた」と思ってしまいかねません。
そこまでではないにしても、伝わらなければ価値がないのと同じです。
100%技術力を生かすためには、ITエンジニアに「伝える力」が必要です。
経営者などからすれば、プログラムを見ても技術力がどれくらい高いかはわかりません。
完成した商品のを除けば、報告書、説明書、提案書、仕様書などから技術力を判断するほかありません。
だからこそ、報告書などの他人に伝える文章は、「目に見える技術力」になるのです。

報告書などの文章は、「見ることができる」技術力。

本書『エンジニアのための伝わる書き方講座　文章嫌いではすまされない！』は、ITエンジニアが技術を活かすための、伝わる文章を書く方法を学べます。
本書で学べる内容は以下になります。

• ITエンジニアが躓く、基本的な文章の書き方
• ITエンジニアではなく、顧客や同僚がわかりやすい書き方
• システム仕様の説明書や障害報告書の書き方
• 製品マニュアルや教育資料の書き方
• 仕様書の正しい読み方、書き方
• 箇条書きや文章で書かれた情報を元にして、そのイメージがわかる図解をする方法
• 現場と経営層の意識の違いを埋め、組織を動かす文章の書き方
• 製品紹介プレゼンで、興味を引き付ける書き方
• 技術の細部を説明せずに、当社の技術力がどう役に立つかを整理して伝える方法

相手に合わせて、誤解の無いよう過不足なく、わかりやすく書く方法がわかります。
誤配送連絡からApache設定ファイル、SSID、インシデント説明といった、１７個の書き方事例は参考になります。
人間の認知情報処理モデルの観点が含まれているので、対応する相手によって文章スタイルを変えれるのも良いですね。

「なるほど！」と思った中からピックアップ。

文章の価値は、書く前の準備で決まる。

どれだけ準備したかで勝負が決まるように、文章も書く前が重要です。
ポイントは以下６つ。

• 分類してラベルをつける
• 意味のある順番で並べる
• 数量化してグラフを使う
• メッセージを入れる
• 相手の価値観を考える
• 情報量を減らす

伝えたい内容を分解・分類・整列・ラベリングします。
わかりにくい文章は、あっちに飛んで、こっちに飛んでと内容がバラバラです。
要素をグループにわけることから始めます。

新聞や雑誌の記事はお手本にならない。

必要なのは「文章」ではなく「情報」です。
例えば、「寝不足→居眠り→交通事故」の因果関係を文章にするとします。
B．は文章を書きなれているように見えますが、誤解を招きやすいです。

1. 彼は昨夜寝不足だった。その結果運転中に居眠りをしてしまった。その結果、交通事故を起こした。
2. 彼が運転中に居眠りをして交通事故を起こしてしまったのは、昨夜寝不足だったからだ。

雑誌や書籍などの商業メディアの記事は、「読者が興味を持って楽しく読んでくれる」ための書き方です。
システム開発の文章は、「必要な情報が短時間で正確に伝わる」ために書きます。
「楽しませる」文章テクニックは、不要どころか有害です。

ITエンジニアの仕事は、「上司から言われたことを言われた通りにやること」だけではない。

ITエンジニアだけに限りませんが、言われたことをやるのは基本です。
自分の担当領域において「問題」を見つけ、何をするべきかを提案するのも仕事です。
それには「状況把握」→「方針立案」→「行動提案」というワークフローを経ます。
「方針立案」はロジカルに問題解決を考える工程。
「行動提案」は関係する人間を説得する工程です。

「行動提案」は一連のストーリーにする。

スムーズに受け入れてもらえるよう、相手にわかる言葉で順番に説明します。

1. 関心：相手に関係する話題を振る。
2. 問題点：理想と現実のギャップを見せる。
3. 課題：こうしよう、こうすべきだという内容を説明する。
4. 解決策：具体的な解決策を提示する。
5. 効果：成功した場合のメリットを説明する。
6. メッセージ：最後に言いたいことをまとめる。

人間の脳内情報処理は、同時処理型、継次処理型がある。

• 同時処理型：全体像を把握してから細部を位置づける。
• 継次処理型：細部を順番にたどる。

どちらの型かを判断するには、例えば昨日の飲み会で何を食べたかを聞きます。

• 同時処理型：テーブルの映像を思い出す。
• 継次処理型：食べた時系列で思い出す。

文章は継次処理型に適した表現手段です。
同時処理型の人には、図で説明する方が効果的です。

「専門用語ばかりでわかりにくい」＝「あなたが嫌いorあなたを信用していない」。

人間はえてして「知らない人の話」は警戒して聞き、「嫌いな奴の話」は低い評価をします。
「相手が自分への配慮をしてくれていない」と感じると、不愉快になります。
「よくわからない専門用語を使って説明をする人」は、「こいつ、嫌い」という感情を呼びやすいです。
でもビジネスの現場で「こいつ、嫌い」という感情を出すことはないため、「専門用語がわからない」という言葉に変換されて表現します。
一方専門用語を使わずに説明すると、「こんなこともわからない馬鹿だと思っているのか」と怒られてしまうかもしれません。
有効な対策は、「短時間・多頻度コミュニケーション」。
同じ時間話すのでも、1時間を１回よりも、5分を12回の方が好かれます。

まとめ：ITエンジニアこそ、文章を書けるようになりたい。

ITエンジニアは、本来多くの富を作り出しています。
けれど、ITの技術は目に見えません。
実際にプログラミング経験のある人以外には、大変さもわかりません。
わからないものには、価値が無い。
この法則は、ITエンジニアにも適応されます。
だからこそ、わかってもらうためのツールである文章力を磨くことが大切になります。
『エンジニアのための伝わる書き方講座　文章嫌いではすまされない！』は、ITエンジニアのための、伝わる文章を書く方法を学ぶ本です。
新聞や雑誌はお手本にならないというだけに、Webライターや小説家には向かないかもしれません。
でもITエンジニアになら、きっと役に立つ１冊です。
以上、
エンジニアが100%技術力を活かすための、伝わる文章を書く方法。『エンジニアのための伝わる書き方講座　文章嫌いではすまされない！』
でした。
ぜひ、手に取ってみてください♪