O slideshow foi denunciado.
Utilizamos seu perfil e dados de atividades no LinkedIn para personalizar e exibir anúncios mais relevantes. Altere suas preferências de anúncios quando desejar.

技術系文書作成のコツ

社内の講習会用に作成したものです。

  • Entre para ver os comentários

技術系文書作成のコツ

  1. 1. 技術系 文書作成のコツ 2014/06/12 株式会社オープンストリーム 寺田英雄
  2. 2. はじめに  仕事で作成する文書の一番の読者であるお客様や上司は、仕様書や報告書など を大量に読まなければならず、また読み慣れてもいます。  世の中では、定番の文章構成や書き方というものがあり、彼らはそれに慣れている ので、そこからずれた文書を見せられると、読みにくくて非常に困惑します。最悪の場 合は読んでもらえなかったり、内容が間違って伝わったりします。  したがって、この定番を理解して使いこなすことが大切です。  仕事の文書は文学作品ではないので、個性的な表現や独創的な構成を考える必 要ありません。定番のパターンに沿って文書を作成することで、作成側・読者側双方 にとって労力が減り、時間の節約にもなって生産性が上がりますので、ぜひコツを身 につけて下さい。    
  3. 3. 余談:チャーチルのメモ(1/2) 1940年、破滅寸前のイギリスの首相に就任したチャーチルは、 すぐに政府各部局長にメモを送った。  『われわれの職務を遂行するためには大量の書類を読まねば ならぬ。その書類のほとんどすべてが長すぎる。時間が無駄だ し、要点を見つけるのに手間がかかる。  同僚諸兄とその部下の方々に、報告書をもっと短くするように ご配慮願いたい。』 チャーチルは文章の才能があり、後に ノーベル文学賞を受賞している。 引用元: 「理科系の作文技術」 (木下是雄著、中公新書)
  4. 4. チャーチルのメモ(2/2) 1. 報告書は、要点をそれぞれ短い歯切れのいいパラグラフにまとめて書け。 2. 複雑な要因の分析にもとづく報告や、統計にもとづく報告では、要因の分析や統 計は付録とせよ。 3. 正式の報告書でなく見出しだけを並べたメモを用意し、必要に応じて口頭でおぎ なったほうがいい場合が多い。 4. 次のような言い方はやめよう:「次の諸点を心に止めておくことも重要である」、 「・・・を実行する可能性も考慮すべきである」。この種のもってまわった言い回し は埋草にすぎない。省くか、一言で言い切れ。 5. 思い切って、短い、パッと意味の通じる言い方を使え。くだけすぎた言い方でも かまわない。 この勉強会で伝えたいことは、ほぼこれに書いてある通りです。
  5. 5. 文章構成について
  6. 6. 基本は「結論ファースト」 ● 技術文書において「起承転結」型はダメ ○ 起承転結は物語・文学的な構成。結論まで読むのに時 間がかかるのが欠点。 ● 結論ファースト型が正しい ○ 読者はまず結論を知りたがっている ○ 最初に結論を書く ○ 結論 → 理由説明という流れが基本 ○ 重要な情報ほど前に。細かい話は後ろに。
  7. 7. 読者に熟読させない ● 内容が目に飛び込んでくるように書く ○ 箇条書きを効果的に使う ○ 見出し・番号を効果的に使う ■ 新聞の見出しのように、短く要点を伝える言葉 ● 熟読しなくても概要が伝わるようにする ○ 形式と論理の流れが一致するように ○ 形を見ればどこに何が書いてあるかだいたい分かるよう に ○ 結論→理由・論拠の流れを守る
  8. 8. ◯◯◯◯調査結果とお願い事項 □□□様 いつもお世話になっております。・・・です。 お問い合わせいただいた、◯◯◯◯の件ですが、下記のような調査を行った結果から、 原因はXXXにある可能性が高いという結果が得られましたので、ご報告申し上げます。 タイトル イントロ あいさつ 結論 記: (1)調査1:***の通信速度  ******* (2)調査2:***に作成されるデータファイルの種別  *******  ただし、***の場合は**** (3)調査3:  ******* 以上 つきましては、お手数ですが再確認のため御社の環境にて△△△△の設定値を 確認いただき、結果を弊社担当**までご連絡いただきますようお願いいたします。 相手にやってほしい アクション 結論を支える 論拠、証拠 データなど (事実) 構成例1
  9. 9. 内容と表現方法
  10. 10. 内容を厳選しよう ● 必要なことは漏れ無く書く ● 必要でないことは1つも書かない
  11. 11. 事実と意見をごっちゃにしない ● 事実の例: ■ 変数の値は5だった。 ■ 〜したらファイルは消えていた。 ■ 〜したらエラー番号103が発生した。 ■ Aさんが「◯◯について了解した」と発言したと議事 録にある。 ● 意見の例: ■ なんだかバグっているようです。 ■ 〜するべきです。 ■ 〜と思われます。
  12. 12. 事実と意見:悪い例 どこがおかしいでしょう? 『近頃の若者は整った文章を書く能力がないという 声をよく聞くが、私はこれは主にITエンジニアに関 して言われていることだと思う。ITエンジニアがキ チンとした文章を書けないことに不思議はない。彼 らの本業は文学ではないからである。』
  13. 13. 事実と意見:悪い例 どこがおかしいでしょう? 『近頃の若者は整った文章を書く能力がないという 声をよく聞くが、私はこれは主にITエンジニアに関 して言われていることだと思う。ITエンジニアがキ チンとした文章を書けないことに不思議はない。彼 らの本業は文学ではないからである。』 第1文では筆者の意見だったのに、 第2文では、それが事実であるかのように表現されて いる。論理のすり替えである。
  14. 14. 1つ文のをあまり長くしない ● 長々と複文・重文を書かない。 ○ 単文化を心がける
  15. 15. 修飾語の使い方に注意 ● 修飾語の位置に注意 ○ 例1 ■ 『大きな皿の上のケーキ』 ■ 『皿の上の大きなケーキ』 ○ 例2 ■ 『ゆっくりと回転するモータの温度が上昇した』 ■ 『回転するモータの温度がゆっくりと上昇した』 ○ 基本は、修飾先の語に一番近くなるように。 ● 誤解を避ける方法→分割 ○ 『皿があり、その上に大きなケーキが載っている。』 ○ 『モータはゆっくりと回転する。それに伴って温度が上昇する。』
  16. 16. 定量的に書けるものは定量的に書く ● 定量的=数値+単位 ● 5人 ● 38kg ● ◯月X日 17:00 まで
  17. 17. 根拠の無い価値判断を含めない ● ☓:「ちょっと大きいです」、   「結構速いです」 ● ◯:「大きさは◯cmです。」   「速さは◯◯の5倍です」 なぜそう言える?
  18. 18. 二重否定など、回りくどい表現を使わない ● 例1 ○ ☓:『〜と言えないこともないと考えたりもします』 ○ ◯:『〜と言えます。』 ● 例2 ○ ☓:『〜は検討してみても良いのではないでしょうか。』 ○ ◯:『〜を検討ください。』
  19. 19. 相手にやってほしい動作は明確に ● 例 ○ ☓:『ファイルAを保存し、送付します』 ○ ◯:『ファイルAを保存し、お客様から◯◯宛にX日までに 送付願います。』
  20. 20. タイトルの「情報量」を意識しよう ● 『<名詞>の件』というタイトルをよく見かけるが、これではほとんど情報が伝わ らない。 ● 最低限『<名詞>の<状態・様子・結果>の件』としたい ○ ☓:避難訓練の件 ◯:避難訓練の開催スケジュール決定の件 ○ ☓:うどんの件 ◯:うどん納品日のお知らせ ○ ☓:停電の件 ◯:停電前に実施願いたい作業について ● ラベルを使うと便利 ○ 依頼:◯◯実施のお願い ○ 報告:◯◯セミナーレポート公開しました ○ 会議依頼:◯◯検討会に参集ねがいます
  21. 21. Q&Aの文章
  22. 22. Q&Aでは、質問と答えの形が合うこと ● 質問の意図を正確に理解し、形式を守って正確に打ち返す こと。
  23. 23. YES/NO 型質問には 最初にYES/NOを答える ● YES/NOで答えられる質問には、まず YES/NOを答える。 補足等があるなら、その後に述べる。 ○ 質問者:『**は完了しましたか?』 ○ 回答☓:『**にはまずAまたはBが必要でして、Aを試 したのですがうまくいかず、Bは外部業者Xに依頼しまし たが、見積もり金額で揉めたので、Y社にも声を掛けた のですが回答が遅いので・・・』 質問者:『で、結局完了したの?』(イラっ!) ○ 回答◯:『いえ、未完了です。状況は・・・です。』
  24. 24. 量・程度の質問には、 最初に量・程度を答える ● 量や程度を尋ねる質問には、まず量や程度を答える。補足 等があるなら、その後に述べる。 ○ 質問者:「モデル**は何GHzですか?」 ○ 回答☓:「**は新型の加速管を採用しており他社に比 べて飛躍的に動作が速くなっております。X社を始め数 社に採用実績があって、ご好評をいただいております。」 質問者:「で何GHzなんですか?」 ○ 回答◯:「**は、50GHzです。従来品との違いは、 ・・・」
  25. 25. 『もし』、『タラ・レバ』は 誤解の頻発地帯。要注意! ● 場合分けや条件付きの回答になるときは、長々と続けず、 分解して箇条書きにする。 ○ ☓:「もし〜ならば**ですが、しかし〜〜のときは ***とも考えられ、一方〜〜でないときは****の 可能性もあります。」 ○ ◯: ■ もし〜ならば→**を行います。 ■ もし〜〜ならば→***を確認してください。 ■ もし〜〜〜ならば→****を実施ください。
  26. 26. 余談: スケジュール調整メールのコツ ● ☓ ○ A:『来週都合の良い日はいつですか?』 ○ B:『火曜日と、木曜日が空いています』 ○ A:『火・木はふさがっています』 ○ B:『ではその翌週の月曜日は』 ○ A:『OKです。』 ● ◯ ○ A:『来週都合の良い日はいつですか?当方は火・木以 外なら大丈夫です。』 ○ B:『では月曜日でお願いします』 ○ A:『承知しました』 最初から出せる情報は出しておき、無駄な メールの往復回数を減らす。
  27. 27. 余談: 『ニナリマス』は丁寧語ではない。 ● ☓ ○ 『こちらが説明書になります。』 ○ 『金額は◯◯円になります。』 ● ◯ ○ 『こちらが説明書でございます。』 ○ 『金額は◯◯円です。』 ● ニナリマスは、一連の動作を経てある状態に変 化した場合 ○ 『調査結果は、別紙報告書のようになります。』 ○ 『総計でお買い上げ金額は◯◯円になります。』
  28. 28. まとめ
  29. 29. まとめ:技術系の作文の手順 1) この文書で一番伝えたいこと=結論を決める 2) 結論を書く 3) その結論の説明・理由を書く 基本は箇条書き(見出し付きが望ましい) a) 説明の根拠となる事実(エビデンス)を添える b) 見解や推察は、事実と事実を結ぶ、無理のない論理的 なストーリーになっていること 4) (オプション):補足説明など 5) (オプション):今後の予定、次のアクションなど
  30. 30. 文書におけるカスタマーファースト ● 自分が何を言いたいかではなく ● 相手に伝えたいこと、読み取らせたいことは何 かを中心に考える ○ 相手に行間を読ませない。 ○ 相手に時間を掛けさせない。 ○ 「なんとなく、わかってほしい」 「だいたい分かるだろう」は甘え。 ○ 誤解されたら作者の責任。
  31. 31. 頭がごちゃごちゃしてまとまらない時 ● 一度、要素を全部書きだそう ● マインドマップ等を使おう ○ XMind(フリー)が便利です ● 悩んだら誰かに相談してアドバイスをもらおう
  32. 32. 以上

×