概要

文書作成でお悩みですか？　ビジネスで使う文書を作るのに，文筆家が書くような「うまい文章」の書き方を修得する必要はありません。エンジニアに必要なのは，難しくなりがちな内容を相手に理解してもらうための「わかりやすい文書」の書き方です。

著者の開米氏は，文書作成能力を向上させるための企業研修を2003年から請け負っています。さまざまな悩みの相談を受けてきた経験から得られた「わかりやすく書くためのポイント」が，本書にはロジカルにまとめられています。自分の悩みに近いものから実践し，毎日数分の練習を続けることで，コミュニケーション能力の高い，頼れるエンジニアになりましょう！

本書の要旨

• 文書を作成する前に考える，基本となる6つのポイントを押さえる
• 「図解」と「文章」でわかりやすい「文書」になる
• 構造を図解するための典型的な型を知る
• 文書の役割をワークフローから考える
• ITエンジニアに馴染みのある豊富な例文から，自分の仕事に近いもの見つけて学べる

こんな方におすすめ

• 自分の書いた文書が，自分の思ったように相手に伝わっていないと感じたことのある方
• 受け取った文書の内容を，しっかり理解できているか不安に思うことのある方

著者から一言

（本文より） 「技術力」を活かすためには，あなたの技術的知見からどんなことが言えるのかを周囲に理解してもらわなければなりません。また，あなたが技術を持っていることをほかの人に知らせることが必要です。それができないと，せっかくの技術力が活かされずに埋もれてしまいます。そのために役立つのが「わかりやすく書く力」なのです。

そしてその力は毎日数分ずつでかまわないので，意識してトレーニングすることで意外に短期間で向上します。食わず嫌いにならずに，ぜひチャレンジしてみてください。そのためのやさしい手引き書になるように，ということを意図して私はこの本を書きました。

目次

第1章　この本の使い方

• 1.1　「文書が書けない」悩みも人それぞれ
• 1.2　悩み別・本書の使い方ガイド
• 1.3　「紙を書く」ことを馬鹿にする者に未来はない
• 1.4　技術力を活かすためにも，書く力を身につけよう

第2章　事例で探る「わかりやすく書く」ための6ポイント

• 2.1　技術者といえども「ドキュメント」を避けては仕事ができない
• 2.2　「文章のテクニック」に走る前にやるべきことがある
• 2.3　「文章を書く前にやるべき9割」とは何か？
• 2.4　最も基本的なポイントは6つ
• 2.5　事例 次世代ストレージ・システムの意義
• 2.6　［ポイント1］分類してラベルをつける
• 2.7　［ポイント2］意味のある順番で並べる
• 2.8　［ポイント3］数量化してグラフを使う
• 2.9　［ポイント4］メッセージを入れる
• 2.10　［ポイント5］相手の価値観を考える
• 2.11　［ポイント6］情報量を減らす
• 2.12　図解の元になった文章はどうする？
• 2.13　難解なテクニックは不要だが覚えただけでは使えない

第3章　「書く力」向上作戦の進め方

• 3.1　まず何から始めればいい？
• 3.2　一番手軽で応用が効く方法は「とりあえず分割してみる」こと
• 3.3　分割に困ったときこそ，成長のチャンス！
• 3.4　分割することはイコール分類すること
• 3.5　自分の理解を要約したラベルをつける
• 3.6　分割で悩むような文章は捨てて手っ取り早く成果を出そう
• 3.7　さらに3段構えで「書く力」のパワーアップ作戦を考える
• 3.8　［ステップ1］動機を確認する
• 3.9　［ステップ2］型を真似る
• 3.10　［ステップ3］引き出しを増やす
• 3.11　必要なのは「情報」であって「文章」ではない
• 3.12　「良い文章」はかえって読者を誤解させやすい
• 3.13　新聞や雑誌の記事をお手本にするのは大きな勘違い

第4章　ワークフローの中での文書の役割を考える

• 4.1　エンジニアの声が経営者を動かせないのはなぜ？
• 4.2　ビジネスの基本は状況把握・方針立案・行動提案の3段階
• 4.3　使うタイミングを間違えていませんか？
• 4.4　「状況把握」段階では情報量の削減をしてはいけない場合がある
• 4.5　「方針立案」段階では典型的な「型」がある
• 4.6　「行動提案」は，方針を相手の受け取りやすい形に整えること
• 4.7　状況把握の「型」は千差万別
• 4.8　「Simple is best」が常に正しいわけではない
• 4.9　現実をありのままに表現した図が必要なときもある

第5章　IT関連ドキュメント構造化事例集

• 5.1　見て，真似て，考えて，身につけよう
• 5.2　［事例1］誤配送連絡
• 5.3　［事例2］クラスタリング技術の結集
• 5.4　［事例3］システム構成テンプレート化構想
• 5.5　［事例4］ファイルサーバー性能測定ツール
• 5.6　［事例5］電池の持ち時間をグラフで表す
• 5.7　［事例6］パソコン用インタフェース
• 5.8　［事例7］通信機器の障害防止策
• 5.9　［事例8］Apacheの設定ファイルに関する説明文（1）
• 5.10　［事例9］Apacheの設定ファイルに関する説明文（2）
• 5.11　［事例10］Apacheの設定ファイルに関する説明文（3）
• 5.12　［事例11］Apacheの動作に関する説明文
• 5.13　［事例12］SSIDとは
• 5.14　［事例13］マルチSSID機能
• 5.15　［事例14］インシデント対応活動
• 5.16　［事例15］機密性・完全性・可用性
• 5.17　［事例16］ウイルス，スパムメール対策
• 5.18　［事例17］個人情報保護法ガイドライン

第6章　ドキュメンテーション作業チェックリスト

• 6.1　文書作成中に悩んだら，いつでも確認！
• 6.2　対象者・ワークフロー・表現の3分野でチェックする
• 6.3　「対象者確認」…誰がいつ何のために読むものか？
• 6.4　「ワークフロー確認」…状況把握，方針立案，行動提案
• 6.5　「表現調整」…用語の選択，概念のまとまり，数値表現

第7章　人間の認知情報処理モデルの観点から

• 7.1　人の脳内には2種類の情報処理回路がある
• 7.2　同時処理型・継次処理型はそれぞれ「得意技」が違う
• 7.3　「文章」は継次処理型に適した表現手段
• 7.4　ネットワーク型の構造は図解でなければ表現できない
• 7.5　ネットワーク型情報を図解するときは継次処理型向けの手を加える
• 7.6　図解に決まった手法はない

第8章　ドキュメントだけではコミュニケーションは改善しない

• 8.1　「コミュニケーション」って何だろう？
• 8.2　『カッツの3能力』から「コミュニケーション」を考える
• 8.3　テクニカル・コミュニケーションでは「文書」情報の山ができる
• 8.4　ヒューマン・コミュニケーションでは短時間・多頻度の顔合わせが重要
• 8.5　「ヒューマン」ができていないと「テクニカル」にも支障が出る
• 8.6　「目標をイメージさせる」のがコンセプチュアル・コミュニケーション
• 8.7　コンセプチュアル・スキルの核は価値観，抽象化，語彙
• 8.8　お互いに切磋琢磨するコミュニティに属していますか？
• 8.9　ドキュメントだけではコミュニケーションは改善しない

サポート

現在サポート情報はありません。