ライティングの修行に終わりはないので、なにがしかを読み続けている。問題意識があるというよりも、下手だという自覚がある。そうすると、読むほどにこれだったのか、という穴がわかる。何度も読み返し、紙漉きのように積み重なって形になるものが、本書から得られたものとなる。

ロジカル・ライティングは一旦休止し、次はリーガル・ライティングへ。

 

p.16

自分では当たり前の言葉が、相手にとってはなじみがなく、意思疎通がしにくいことはめずらしくありません。本質を伝えるためには、相手がわかる言葉や表現を駆使して伝える必要があります。つまり、問題が高度化・複雑化すればするほど、相手の立場に立った伝え方を磨く必要があり、わかりやすい文書の作成はますます難しくなってきているのです。

p.18

IT時代におけるビジネス文書作成の要件をまとめると以下のようになります。

■要件その1 大量の情報洪水に埋もれないわかりやすさを持つこと

■要件その2 高度な内容の本質を相手の言葉で伝えること

■要件その3 ツールに頼らず本質を際立たせること

■要件その4 圧倒的なスピードを付加価値にすること

p.21

1つ目は、書いてあることの意味がわかること文字どおり「意味を理解する」ということです。2つ目は、意味を理解した上でその意義がわかる=「意義を納得する」ということです。

p.22

もう1つの「意義を納得する」の「わかった状態」は、文書で伝えているメッセージの重要性が腑に落ちて、よしやろうと行動を起こすことを決意している状態を指します。この「わかった状態」は、なぜそうしたほうがよいのかという根拠、重要性、すべきこと(すべきではないこと)、選択基準などを相手が理解し納得しているというとても高いレベルなのです。

p.26

まずメッセージですが、平たく言えば「言いたいこと」です。そこには含まれていないといけないものがあります。それは「主張」と「根拠」です。言い換えると、「Aだから(根拠)、Bすべきである (主張)」ということです。

p.27

根拠が欠けていて主張だけしかない場合、相手は「なぜ?」と聞いてきます。英語で言えば「Why?」 です。逆に、根拠だけあって主張がない場合には、相手は「それで言いたいことは?」 (「So what?」) と聞いてきます。

p.31

まず「共有」の文書ですが、すでに相手が行動をとることを決めている状態に対して、事実情報や行動の手順を伝えるものです。具体的には、議事録、イベント告知などの案内文書です。ガイド、マニュアルなども共有文書に含まれます。

次の「報告」の文書は、相手がこれからどのような行動をとるべきかを判断したいという状態に対して、事実情報を取りまとめて分析し、示唆や見解を加えて行動をうながすものです。 市場調査などの報告書や、プロジェクトや事業・営業活動などの進捗・成果報告があげられます。障害報告書なども含まれます。

「依頼」の文書は、こちらがとってもらいたい行動を相手にお願いするものです。アンケートや点検作業など簡易な行動をお願いする文書や、講演など仕事の依頼、紹介・推薦など協力を依頼する文書などがあります。相手にとってメリットがある場合はよいのですが、そうでない場合には、意義の理解に加え、行動のとりやすさを工夫することが必要になります。

p.32

「提案」の文書は、相手にとって大きな意思決定や意識行動変革を求めるもので、行動をうながすためにはもっとも難易度が高いものです。具体的には、企画書や提案書、啓蒙要素の強い講演や研修の資料などです。事業や購入してもらいたい商品・サービスの意味と意義をともに理解してもらうためには、相手目線で論理を組み立てなくてはなりません。 ビジネス文書の中でも、もっとも取り組みがいがあるものと言えます。

 

図表 1-3 4つの文書タイプ

相手に行動をとってもらう難易度

   文書タイプ     概要         文書例

 低 共有文書   事実情報や行動の手  議事録、案内文書、 ガイ

          順を伝える。     ド、マニュアルなど

   報告文書   事実情報を取りまと  調査報告書、プロジェク

          めて分析し、示唆や  ト・活動の進捗・成果報

          見解を得て伝える。  告、障害報告書など

   依頼文書   相手にとってもらい  作業依頼文書、仕事依頼

          たい行動を伝える。  文書、 協力依頼文書

   提案文書   意識・行動変革の必  ソリューション提案書、

          要性を伝え、説得す  企画提案書、 啓蒙的研修・

 高        る。         講演文書など

 

p.36

私がビジネス文書作成の研修や部下の指導などの際に言うのは、「まずパソコンを閉じて、ノートに目的とメッセージを手書きで書いてください」ということです。手書きで書こうとすると、体裁は取り払われ、本質的なメッセージしか書けません。だからこそ、まず紙に実際に書いてみて、本質的なメッセージは何なのかを確認することが大事なのです。そうすると、自分がどう考えているのか、もしくはそもそもまだ文書を作れるほどの材料がないのかがわかります。

p.37

文書を作るときには、ネットワーク環境を遮断するくらいでちょうどよいくらいです。特に、文書の設計書であるストーリーや構成までは、ネットワークに接続できない環境で紙に手書きするというアナログな作り方をおすすめします。

まず「目的」を設定しましょう。 「何のために文書を作ろうとしているのか」、文書の作成目的と達成すべきゴールを明確化することで、文書作成のスタート地点に立てます。

ビジネス文書は、相手に何らかの行動をとってもらうために作成するものです。目的の明確化とは、第1に「相手にどんな行動をとってもらいたいのか」を明らかにすることと言えます。

p.38

目的設定② そのために何を理解してもらいたいのか

次に、「その行動をとってもらうために、何を理解してもらいたいのか」を明らかにします。

まず目的設定①のとってもらいたい行動を明らかにして、そのために何を理解してもらわなければならないのかという紐づけ作業を行います。非常に多忙な相手に対して、取捨選択されていない、もしくは論理的に加工されていないデータを提供することは、時間泥棒とも言える罪です。そのためにも、行動から必要な理解すべきことを洗い出しましょう。

p.41

図表 2-1 目的設定

1. どんな行動をとってもらいたいのか (ゴール)

例① 次のプロジェクトの予算を承認してもらいたい

例② 研修で得たテクニックを業務で適用し、 効果を出してもらいたい

2. そのために何を理解してもらいたいのか

例① プロジェクトが成功した場合の効果

例② 実践可能な具体的かつ応用可能なスキルやテクニック

3. そのためにどのような状態にするべきか

例① プロジェクトに対して好意を持ち、 サポーターの気持ちになってもらう

例② 「自分もやってみたい」という気持ちになってもらう

p.53

図表3-3 プロファイリングシート

ターゲット  ① メインターゲット ② サブターゲット

プロファイル   人物像       期待

       ①各ターゲットの   「どうしてほしいか」

        役割や関心

         情報        理解

       ①保有情報の広さと   「どのくらい理解しているか」

       ②深さ

仮説      「何をどうやって伝えるか」 という方針

p.58

依頼文書などは大前提の確認・強調から入って、徐々に詳細な依頼情報を伝えていくと受け入れられやすいでしょう。

p.59

まず「Why」は、「なぜそれをやるべきか」という情報についてです。もしここが「L」、つまり「必要性がわかっていない」という場合には、背景、根拠を中心に話を進める必要があります。次に「What」は、相手に求める行動や提案したい内容そのものについての情報です。3つ目の「How」は、「Why」 の情報、「What」の情報、すなわち「なぜそれをやるべきか」「何をすればいいか」がわかっている場合、あとは具体的に「どうしたらいいのか」という情報です。

あらためて相手が何を知っていて何を知らないのかを認識することは、わかりやすい文書作りにはとても重要です。 まず、相手が知らないテーマに対しては、比喩を用いたり、具体例を出したりするなど、相手がわかりやすい表現を心がける必要があります。次に知っている(と思っている)テーマに対しては、その理解が正しいのかどうか、自分の意図と違う場合にはどうやって認識を変えてもらうかを考えていきます。

p.75

ピラミッドを構成するにあたりもっとも考慮すべき点は、相手の論理で展開することです。

p.76

同じ「対応しない」ということを伝えるメッセージなのに、受け入れやすさが違うと思いませんか? 人はついつい自分の論理で考えがちですが、文書はあくまでも相手にメッセージを伝え、動いてもらうもの。相手の論理で表現しなくては、動く気になれないのです。

p.77

伝えるべきメッセージが明確になったら、相手が理解しやすいように情報の順番を決めて、ストーリー仕立てにします。 そのためのツールがストーリーボードです。

ストーリーボードは、文書の全体像を示した設計図です。 箇条書きや文章でストーリーを考えることも可能ですが、ストーリーボードは全体のボリュームや構成が一目で把握できるのでおすすめです。頂点にメインメッセージ、その下にサブメッセージを配したピラミッド構造、さらにその下にセクション、いわゆる文書の章立てを作っていきます。

メインメッセージとサブメッセージからなるビラミッド構造がそのまま資料の構成になると思われることが多いのですが、そうではなく、これとは別にセクション (章立て)を作ります。メインメッセージを効果的に伝えるためには、メインメッセージからサブメッセージへと展開する方法もあれば、サブメッセージを個別に説明したあとで、メインメッセージに上げていくほうが適した場合もあるからです。

p.78

プロファイリングシートをベースに、そのターゲットやシチュエーションに合わせて章立てを考えていきましょう。

相手へ説明することを思い浮かべながら、セクションを立てていきましょう。

実際にはストーリーボードを作る人はわずかで、パソコンで文書を作成しながら章立てを考える人がほとんどでしょう。しかし、経験上、スピードという点では、ストーリーボードまで手書きしてからパソコン作業に入るほうが圧倒的に速いと言えます。

p.90

議事録フォーマットは、日時、参加者、議事内容、決定事項、ToDo(やるべき事項) 

p.96

論点ごとに結論と経緯を整理して書くことが求められます。

p.99

図表 5-1 議事録のフレームワーク

項目       内容

A. 基本情報   会議名・日時・場所・参加者・議題一覧(アジェ

        ンダとも言います)・使用資料作成者・承認者

        などの会議の基本情報

B. 目的 ゴール  何を決めるために集まったのか

C. 議事内容   議題・議論の流れ 結論 合意の有無

D. 決定事項   最終合意事項、 ToDo

p.109

図表 5-4 告知文書のフレームワーク

項目        内容

A. 発信者 受信者  誰から誰に伝えるのか

B. 告知情報    大前提として伝える、告知することの内容

         相手にとっての意味

C. 詳細情報    例外や補足など

p.120

〈情報収集〉

告知文書の情報収集として必要なことは、意外と多くあります。告知事項そのものはシンプルなものが多いのですが、それに関連したさまざまな事項について情報を集めなくてはなりません。問い合わせや例外事項への対応方針まで決めておく必要があるからです。場合によっては本文に含めておくべきこともあり、この情報収集と取捨選択を誤ると、あとから問い合わせ対応に忙殺されることになります。過去に類似の告知をした際に起きたことなどを、あらかじめ聞いておくことで回避できることもあります。

p.120

活動報告書が果たす要件の1つ目は、責任がまっとうできているかどうかが理解できることです。プロジェクトの目的やゴールが達成できているのかどうか、また、途中の進捗報告であれば、その時点の目標達成状況がわかることが基本です。ここがわからないと、前述の活動記録になってしまうのです。やったことではなく、成し遂げたことが何かがわかること基本の要件です。

2つ目は、その活動が続行か変更かという投資判断ができることです。すべての企業活動は資金や人材を投資しているものですので、その投資方針が正しかったのかどうか、今後もその方針で活動を続けられるのかどうかが判断できる必要があります。 研修や視察、出張も投資ですから、この要件を満たす必要があります。

p.121

報告書の根底に必要な心がけは、前述のとおり相手が自分に抱いている期待を認識し、それに応えようという意識です。

もう1つ必要なのは、感謝の念を込めることです。

p.122

報告書に含める内容は、以下のフレームワークで考えます。何を目指したのか(A 目的)、どうなったのか(B 成果・進捗)、何をしたのか(C 活動)、なぜそうなったのか(D 総括)、次はどうすべきか(E課題と予定)の5つです。

p.123

図表 6-1 報告文書のフレームワーク

項目            内容

A. 目的         ・何を目指したのか

            ・具体的なゴール (目標)

B. 成果 ・ 進捗     ・どうなったのか

            ・得られたもの、 目標に対する進捗

            ・活動内容に応じて詳細なフレームワークを用い

             て表現する

C. 活動         ・何をしたのか

            ・実際の活動

D. 総括         ・なぜそうなったのか

            ・評価、反省、所感

E. 課題と予定      ・次はどうすべきか

            ・活動を受けての今後の計画や課題

p.133

調査報告書に含める内容は、以下のフレームワークで考えます。 どのような仮説を検証するための調査なのか(A 目的)、どのように検証したのか(B方法)、何が実証されたのか(C結果)、今後どうするのかという示唆 (D結論)です。詳細な調査結果はすべて必要なわけではありません。

p.134

調査報告書では、情報をどのように収集するかが非常に重要です。 その際に役立つ考え方が「MECE」 です。 MECEとは、 「Mutually Exclusive, Collectively Exhaustive」 の略で、抜け漏れなくダブりなく要素を洗い出し、検討過程で論理的に物事を「分解する」作業で、「論理の幅」を担保する上で重要な考え方です。

p.137

図表 6-5 情報を MECE に分ける方法

手法             説明            例

2つに分ける     対立 / 対局概念を探し    ●社内・社外

           出し、物事の構成要素を   ●変動・固定

           2つに分解する (「A」    ●男・女

           と「not A」 に分ける)

数値で分ける     分類する数値軸を設定    ●年齢 10代、20代、                       

           し、スケーリングする     30代......

           ことで分解する       ●年収 (万円): ~ 500、

                          500〜750....

                         ●時間帯:10:00-、

流れ順序で分ける   手順 (時間軸)を洗い     ●提案、見積もり、                

           出し、 物事を順序立て     受注、請求

           て分解する         ●調査、分析、 実行

                         ●実施前、 実施中、 

                          実施後

既存の要素で分ける  既知の分類やフレーム    ●学校分類 : 小学校

           ワークを用いて分類す     ・中学校 高校 大学

           る             ●季節分類: 春夏秋冬

           (完全に MECE ではな    ●5W1H

           い場合もある)        ●3C

数式で分ける     計算式を導き出し、 物   ●売上=数量×単価

           事を加減乗除で分解す   ●利益 =売上一費用

           る

p.138

相手が必要とするのは調査の結論ですから、調査概要はできるだけ短めにし、詳細な調査方法や対象は別紙としましょう。その上で、特筆すべき検証結果はハイライトとして、表現もインパクトのあるものにします。 せっかく時間と労力をかけた調査結果が、単なる想定どおりではなく、貴重な示唆が得られたということを示すためにも、「ここを見てほしい」という検証結果は、ストーリーの中で早めに「調査のハイライト」として持ってきましょう。最後の最後に出てきても印象は薄いですし、そこまで読んでもらえる可能性は必ずしも100%ではないからです。

p.152

何かを頼まれると、とっさに面倒と思うのが人の心です。共有の告知文書の項で相手意識と立場意識が必要と述べましたが、依頼文書では、それ以上に相手の立場に立つことが求められます。仕事は自分一人で完結することは稀で、社内外のさまざまな人との共同作業によって成り立っています。仕事を完結するにあたり、依頼するということは避けて通れません。

依頼の仕方によっては、仕事の成果につながらないばかりか、トラブルに発展することもありえます。

p.153

ビジネス文書としての体裁が整っていても、表現に気遣いがない場合には、実際の仕事が始まったときに、トラブルとは言わないまでも不愉快な思いをする可能性があると直感が働くのです。

p.154

依頼文書の要件は3つあります。 「相手が何を依頼されているのかがわかること」「依頼されている理由が妥当であること」「気持ちよく依頼を受けたいと思える配慮がされていること」です。

まず、「依頼事項がわかる」と聞くと当たり前のように思えますが、自分にとっては明確でも、相手にとっては何を頼まれたのかが具体的にわからないことはままあります。特にIT関連の作業依頼などは、依頼しているほうは専門家ですが、依頼される側は素人であることがほとんどであり、何を依頼されているのかがわからないことが多いのです。また、「確認をお願いします」と書かれていたときに、「確認」が具体的な行動として何を意味するのか、認識が異なることもあります。

次の「理由が妥当であること」は異論はないでしょう。 よくある状況は、理由を説明されて納得できないというよりは、理由自体が明記されていないために、「なぜこれをしなくてはいけないのか?」「なぜ(ほかの人ではなく)私なのか?」という質問のやりとりに発展するケースです。質問が来た時点で、相手はいらだっているのです。初めから妥当な理由が書かれていれば、相手に余計な疑念を抱かせることはありません。

p.155

最後の「気持ちよく依頼が受けられる配慮がされていること」という要件が満たされていないケースとしては、理由は納得できたが、頼むにもやりようがあるのではないか、という状況です。煩雑な手順が必要だったり、配慮が欠けていたりすると、理由は理解できても、実際には気持ちが動きません。

p.160

図表 7-3 依頼文書のフレームワーク

項目           内容

A. 依頼要約        依頼内容を短く端的にまとめたもの

B. 依頼理由        なぜ依頼するのか?

C. 依頼詳細        具体的にやってもらいたいこと

D. ベネフィット      ・やった場合のベネフィット (良いこと)

 またはリスク      ・やらない場合のリスク (悪いこと)

E. 確認          相手の意思や行動を確認する方法

 

A 依頼要約は、「○○のお願いです」という具合に、できるだけ短い言葉で何を依頼しているのかを述べます。

B 依頼理由ですが、相手の疑問にきちんと答えるものであるかを確認しましょう。

C 依頼詳細は、長い場合には別添にしますが、なるべく短いものにしたほうがよいでしょう。

D ベネフィット(良い点)またはリスクは、相手目線で考えます。

E 確認は依頼を受けたことや実施が完了したこと、不明点などの問い合わせ方法など、確実に依頼を実施してもらうための確認の方法です。

p.162

前述のフレームワークに沿って情報収集をします。 次に必要なのは、相手からの想定質問を洗い出すことです。依頼するほうは当然のことでも、相手にはさまざまな「なぜ?」が浮かんできます。

依頼する内容を、前後の作業を含めて行動レベルで書き出します。 

全体の文章のトーンは、マインドのところでも書きましたが、礼を尽くす気持ちが表現されているべきでしょう。

p.181

もう1つは、細かなプロセスを見せることです。細部がしっかりしていることは、強い信頼感を抱かせます。 「この場合にはこうする」「ここではこのようなリスクが想定されるが、こうして回避できる」など、事細かな手順や留意点が出てくると実績があるのだと認識されます。

p.182

3つ目の主体的信頼性は、メッセージ発信者の信頼性です。「この人だったらだったら間違いない」という信頼を勝ち取っていれば、提案はとても通りやすくなるでしょう。

p.188

図表8-7 オズボーンの視点切り替えリスト 「SCAMPER」

オズボーンのチェックリストは、頭文字をとってSCAMPER 法とも呼ばれている。 視点の切り替えリストに従って発想する。 ゼロベースよりも、既存アイデアの改善策・ 打開策を考えるのに向いている。

・ Substitute: 代用してみたら?

・Combine:組み合わせてみたら?

・Adapt:応用/適用してみたら?

・Modify:変形/修正してみたら?

・Put: 置き換えてみたら?

・Eliminate:削除してみたら?

・Rearrange:再調整してみたら?