技術をわかりやすく伝えるためテクニカルライティング

by Naohiro Nakata

Slide 1

Slide 1 text

技術をわかりやすく伝えるためのテクニカルライティング Developers Summit 2023 2月10日 17:45- 仲田尚央@cybozu 1

Slide 2

Slide 2 text

2 仲田尚央 Nakata Naohiro @naoh_nak サイボウズテクニカルライターとローカライズの職能マネージャーお仕事の内容： ⚫ サイボウズ製品のUIテキストを書く ⚫ 製品のマニュアルやヘルプを書く ⚫ それらを他の言語に展開する（ローカライズ）複業としてライティング講習もしています 5歳と2歳の子供がいます

Slide 3

Slide 3 text

はじめに、おことわり ⚫ 本セッションは、サイボウズのエンジニア向け研修を編集したものです ⚫ 公開資料と内容が一部重複します 3 https://blog.speakerdeck.com/2022-most-viewed-decks/

Slide 4

Slide 4 text

技術を伝えるということ ⚫ エンジニアには、知識や学びを共有しあう素晴らしい文化があります ⚫ しかし、いかに深い技術も、整理されないままでは読者に伝わりません ⚫ うまく整理されていても、それが適切に文章構成に反映されていなくては、情報の価値は下がってしまいます 4

Slide 5

Slide 5 text

本講の流れ 1. テクニカルライティングの基本的な考え方を知る 2. 情報を適切に整理するためのコツを知る 3. 文章の構成を組むためのコツを知る 4. わかりやすい文章を書くためのコツを知る 5 ✓ 本講では、文章の書き方だけでなく、情報をどう整理するかにも重点を置いています。

Slide 6

Slide 6 text

エンジニアは「ドキュメント」を書く機会が多くあります。 6

Slide 7

Slide 7 text

⚫ 仕様書を書く ⚫ 作業手順書を書く ⚫ 技術ブログを書く ⚫ 業務マニュアルを書く ⚫ リリースノートを書く ⚫ … 7

Slide 8

Slide 8 text

ドキュメントの前提1 - 求める情報が人によって違う 8 業務マニュアル作業Aの手順を知りたい。入社したばかりで何もわからん。今度担当することになった業務Bについて、一通り全部知っておきたい。インストールが必要なツールを知りたい。・・・

Slide 9

Slide 9 text

ドキュメントの前提2 - 情報の探し方も違う 9 業務マニュアル作業Aの手順を知りたい。入社したばかりで何もわからん。今度担当することになった業務Bについて、一通り全部知っておきたい。インストールが必要なツールを知りたい。・・・知りたいことが明確知りたいことが曖昧網羅的に知りたい

Slide 10

Slide 10 text

ドキュメントの前提3 – 一意に伝わる必要がある 10 ✕ ✕ ✕

Slide 11

Slide 11 text

ドキュメントの前提4 – 一部しか読まれない 11

Slide 12

Slide 12 text

テクニカルライティングの要素 12 Effectiveness 必要な情報を正しく得られる Satisfaction 不快さがなく、肯定的に受け止められる Efficiency 効率よく理解できるユーザビリティーの定義（ISO 9241-11）から

Slide 13

Slide 13 text

それぞれの要素に対して取る手段 13 Effectiveness 必要な情報を正しく得られる Satisfaction 不快さがなく、肯定的に受け止められる Efficiency 効率よく理解できる • 曖昧さを排し、明確に書く • できるだけ具体的に書く • 誤解なく読める文章で書く • 情報を適切に整理、構造化する • どこに何が書いてあるかをわかりやすくする • 簡潔で読みやすい文章で書く • 必要な情報だけを書く • 肯定的な表現で書く • ですます調で書く（過剰な敬語にはしない）

Slide 14

Slide 14 text

それぞれの要素に対して取る手段 14 Effectiveness 必要な情報を正しく得られる Satisfaction 不快さがなく、肯定的に受け止められる Efficiency 効率よく理解できる • 曖昧さを排し、明確に書く • できるだけ具体的に書く • 誤解なく読める文章で書く • 情報を適切に整理、構造化する • どこに何が書いてあるかをわかりやすくする • 簡潔で読みやすい文章で書く • 必要な情報だけを書く • 肯定的な表現で書く • ですます調で書く（過剰な敬語にはしない） “ユーザビリティーの高いドキュメント”を書けるようになる

Slide 15

Slide 15 text

テクニカルライティングの進め方 15 テーマ見出し段落文章 ①伝える情報を整理する ②見出し単位でアウトラインを作る ③段落単位で文章の骨組みを作る ④わかりやすく、簡潔な文章で書く

Slide 16

Slide 16 text

Step①：伝える情報を整理する 16

Slide 17

Slide 17 text

ドキュメントの階層ドキュメントは階層構造が基本 ⚫ 1つのドキュメントで、1つのテーマを ⚫ 1つの見出しで、1つのサブテーマを ⚫ 1つの段落で、1つのトピックを 17 メインテーマ見出し段落＝トピック段落＝トピック段落＝トピック見出し段落＝トピック段落＝トピック段落＝トピックサブテーマサブテーマ伝える情報を階層構造に整理する

Slide 18

Slide 18 text

整理の鉄則 18 概要から具体へまたは全体から部分へ

Slide 19

Slide 19 text

19 伝えるテーマテーマ1 テーマ1-1 テーマ1-1-1 テーマ1-1-2 テーマ1-2 テーマ2 テーマ2-1 テーマ2-2 概要全体具体部分具体例で分解構成要素で分解

Slide 20

Slide 20 text

書籍や文書の場合 20 伝えるテーマテーマ1 テーマ1-1 テーマ1-1-1 テーマ1-1-2 テーマ1-2 テーマ2 テーマ2-1 テーマ2-2 章節項

Slide 21

Slide 21 text

Webの場合 21 伝えるテーマテーマ1 テーマ1-1 テーマ1-1-1 テーマ1-1-2 テーマ1-2 テーマ2 テーマ2-1 テーマ2-2 カテゴリーページ見出し

Slide 22

Slide 22 text

全体から部分へと分解する 22 CI/CD CI/CDとは継続的インテグレーションビルド統合テスト継続的デリバリー継続的デプロイ CI/CDの実践バージョン管理システム CI/CDパイプライン実行環境

Slide 23

Slide 23 text

概要から具体へと分解する 23 スマートフォン Android Pixel Xperia Galaxy ・・・ iOS iPhone Pro Max iPhone Pro iPhone mini ・・・

Slide 24

Slide 24 text

順に説明を展開していく 24 スマートフォン Android Pixel Xperia Galaxy ・・・ iOS iPhone Pro Max iPhone Pro iPhone mini ・・・段階を追って知識を付け加えていくことが、わかりやすさに繋がる

Slide 25

Slide 25 text

情報を適切に分解すると、読者が情報を探しやすくなる 25 スマートフォン Android Pixel Xperia Galaxy ・・・ iOS iPhone Pro Max iPhone Pro iPhone mini ・・・前知識がない人は、最初から読み、興味を持った項目へと進む特定の知識が欲しい人は、その項だけを読むさわりだけを知りたい人は、概要だけを読むどこに何が書いてあるかがわかるよう、適切なタイトルと見出しを付けよう

Slide 26

Slide 26 text

分解には複数のやり方がある 26 スマートフォンコミュニケーション・・・・・・ニュース・・・・・・買い物ナビゲーム・・・

Slide 27

Slide 27 text

情報の適切な分解って？ 27 NG：きれいに分解できる OK：読者の目的に合わせる

Slide 28

Slide 28 text

28 スマートフォンを買う Android Pixel Xperia Galaxy ・・・ iOS iPhone Pro Max iPhone Pro iPhone mini ・・・初めてのスマートフォンどれを選べばいいの？種類が多すぎて… スマートフォンをOSや機種の具体例で分解

Slide 29

Slide 29 text

スマートフォンを使いこなすコミュニケーション・・・・・・ニュース・・・・・・買い物ナビゲーム・・・ 29 スマートフォン買ったよ！使いこなしたいスマートフォンを用途の具体例で分解

Slide 30

Slide 30 text

スマートフォンスマートフォンを買う Android iOS スマートフォンを使いこなすコミュニケーションニュース買い物ナビゲーム 30 分解方法は、サブテーマごとに異なってもいいただし、同じ枝の同階層での混在はダメ OSや機種の具体例で分解用途の具体例で分解

Slide 31

Slide 31 text

Step②：アウトラインを作る 33

Slide 32

Slide 32 text

アウトラインとは ⚫ アウトラインとは：物事のあらまし。大筋。概略。 ⚫ ドキュメントにおけるアウトラインとは、章・節・項などの見出しを階層的に設定、表示したもの ⚫ 2つの役割を持つ： ⚫ あらかじめ説明の流れを読み手に掴ませ、心の準備をさせる役割 ⚫ 必要とする情報がどこに書かれているか、探しやすくする役割 34

Slide 33

Slide 33 text

読み手の予想通りに文章を展開する ⚫ 読み手の予想通りに文章を展開することで、読み手は一読で文章を理解できるようになる ⚫ そのために、先に概要や全体像を伝えたあとで、そこで述べた順番のままに、詳しい説明を展開していく 35 CI/CDとは、です。CI/CDには、継続的インテグレーション、継続的デプロイ、継続的デリバリーの3つの要素があります。継続的インテグレーションとは継続的デプロイとは継続的デリバリーとは

Slide 34

Slide 34 text

記事の基本構成 ⚫ タイトルで、そのページのテーマを伝える ⚫ リード文で、これから何を述べるのかを伝える ⚫ 次に、概要や全体像を伝える ⚫ さらに、サブテーマごとの詳細へと展開していく 36 タイトル（≒テーマ）概要・全体像見出し（任意）見出しサブテーマ1 見出しサブテーマ2 リード文 ✓ 1つの記事の中でも階層構造をとるポイント

Slide 35

Slide 35 text

アウトラインを作る流れ 1. 記事で伝える情報を書き出す 2. 書き出した情報を整理する 3. 見出しを決める 37

Slide 36

Slide 36 text

38 CI/CD CI/CDとは継続的インテグレーションビルド統合テスト継続的デリバリー継続的デプロイ CI/CDの実践バージョン管理システム CI/CDパイプライン実行環境ココを1記事として書いてみよう

Slide 37

Slide 37 text

記事で伝える情報を書き出すテーマ： CI/CDとは伝えることを書き出した例： ⚫ CI/CDの概要 ⚫ なぜCI/CDが必要なのか ⚫ CI/CDのメリット ⚫ アジャイル開発との関係 ⚫ CI/CDツールの紹介 ⚫ CI/CDパイプラインの流れ ⚫ 継続的インテグレーションとは ⚫ 継続的デリバリーとは ⚫ 継続的デプロイとは 39 ✓ テーマを分解してできた要素に加えて、記事で伝えるべきことを書き出す ✓ この段階では、順番や言葉の表現などの細かいことは気にしない ✓ 粒度もバラバラでOK ✓ 情報を漏れなく洗い出すことを重視するポイントテーマを分解してできた要素

Slide 38

Slide 38 text

書き出した情報を整理する伝える情報を整理した例： ⚫ CI/CDの概要 ⚫ なぜCI/CDが必要なのか ⚫ アジャイル開発との関係 ⚫ CI/CDのメリット ⚫ CI/CDのプロセス ⚫ 継続的インテグレーション ⚫ 継続的デリバリー ⚫ 継続的デプロイ ⚫ CI/CDパイプラインの流れ ⚫ CI/CDツールの紹介 40 ✓ 書き出した情報を階層化する ✓ 同じ階層は同じ粒度になるように ✓ 順番も意識する ⚫ 重要度で並べる ⚫ 時系列で並べる ⚫ 既知から未知へと並べるポイント

Slide 39

Slide 39 text

見出しを決める見出し構造（＝アウトライン）の例： ⚫ CI/CDとは ⚫ CI/CDが必要になる背景 ⚫ アジャイル開発との関係 → 段落に ⚫ CI/CDのメリット → 段落に ⚫ CI/CDの3つのプロセス ⚫ 継続的インテグレーション ⚫ 継続的デリバリー ⚫ 継続的デプロイ ⚫ CI/CDパイプラインの流れ → 段落に ⚫ CI/CDに必要なツール 41 ✓ 見出しを見るだけで読者が次の情報を読み取れる言葉にする： ⚫ 説明の流れ ⚫ 見出しに続く本文に何が書かれているか ⚫ どのようなときに読む必要があるのか ✓ 書く内容が少なければ、見出しを外し、段落へと格下げするポイント

Slide 40

Slide 40 text

Step③：段落単位で文章の骨組みを作る 42

Slide 41

Slide 41 text

トピックを意識する ⚫ 文章を書き始める前に、段落単位で文章の構成を組む ⚫ 1つの段落が1つのトピック（話題）になる ⚫ 1つの段落は3文～8文程度 ⚫ Webでは2文～5文程度が目安 ⚫ 短過ぎると、主張の根拠が不足する ⚫ 長過ぎると、読みづらくなる 43 トピック1 見出しトピック2 トピック3 見出しトピック1 ・・・

Slide 42

Slide 42 text

トピックを意識する効果 ⚫ 読み手 ⚫ 順序立てて話題が進むので、頭に入りやすい ⚫ 段落単位で読み飛ばしができる ⚫ 書き手 ⚫ 書くべきトピックが決まっていると、書きやすい ⚫ 情報の過不足が視覚的にわかる 44

Slide 43

Slide 43 text

テーマ > トピック > 文章の流れ 1. テーマをトピックに分解する 2. トピックごとの関係を考える 3. 各トピックの詳細（文章）を書く 45

Slide 44

Slide 44 text

テーマをトピックに分解する 46 ⚫ テーマ CI/CDのプロセス ⚫ トピック ⚫ 継続的インテグレーションについて ⚫ 継続的デリバリーについて ⚫ 継続的デプロイについて ⚫ テーマ CI/CDが必要になる背景 ⚫ トピック ⚫ 現代のソフトウェア開発では、複数の開発者による並行開発が必要になること ⚫ 複数の開発者がソフトウェアに同時に変更を加えると、変更が競合する可能性があること ⚫ CI/CDは、そのようなリスクを低減すること

Slide 45

Slide 45 text

⚫ テーマ CI/CDが必要になる背景 ⚫ トピック ⚫ 現代のソフトウェア開発では、複数の開発者による並行開発が必要になること ⚫ 複数の開発者がソフトウェアに同時に変更を加えると、変更が競合する可能性があること ⚫ CI/CDは、そのようなリスクを低減することトピックごとの関係を考える 47 並列のトピック順列のトピック ⚫ テーマ CI/CDのプロセス ⚫ トピック ⚫ 継続的インテグレーションについて ⚫ 継続的デリバリーについて ⚫ 継続的デプロイについて

Slide 46

Slide 46 text

並列のトピックを詳細へと展開する継続的インテグレーションは、変更があったコードを自動的にビルド・統合・テストし、ソフトウェアの品質を安定的に保つ開発プロセスです。ビルドからテストまでのサイクルを継続的に実行することで、開発中に発生するバグを迅速に改修します。継続的デリバリーは、継続的インテグレーションに続くプロセスとして、テストされたソフトウェアをテスト環境に自動的にデプロイするプロセスのことを言います。実際に触って使えるソフトウェアを継続的に提供することで、ソフトウェアの更新を、お客様に提供する前に検証できます。継続的デプロイは、テストされたソフトウェアを本番環境にまで自動的にデプロイするプロセスです。開発者による最新の変更を顧客が使用できるようにします。継続的デリバリーと継続的デプロイの違いは、本番環境への適用に手動での承認を必要とするか否かという点です。 48 並列の情報は同じ表現で書くトピック① トピック② トピック③

Slide 47

Slide 47 text

順列のトピックを詳細へと展開する 49 順列の情報は既知から未知へと順を追って理解できるように書く現代のソフトウェア開発では、複数の開発者が複数の機能を並行開発していくことが一般的になっています。ソフトウェアが大規模化し、求められる開発スピードも増しているからです。複数の開発者がコードを追加したりライブラリーを追加したりすると、それらの変更が競合したり、依存関係が発生したりすることがあります。開発者のローカルでの開発が長く続けば続くほど、コードをマージしたときに競合や不具合が発生するリスクが高まります。このようなリスクを低減するため、CI/CDと呼ばれる開発プロセスでは、開発者は共有リポジトリーに継続的にコミットします。コミットのたびにビルドとテストを自動的に実行することで、コードの品質を安定的に保ちます。多くの場合、1日に複数回もの高頻度でビルドとテストのサイクルを回します。トピック① トピック② トピック③

Slide 48

Slide 48 text

トピックの展開トピックを展開していく代表的なパターン： ⚫ 詳細を述べる「つまり、～ということです。」 ⚫ 具体例を挙げる「たとえば、～があります。」 ⚫ 理由を述べる「その理由は、～です。」 ⚫ データを出す「次のデータは、～を示しています。」 50 現代のソフトウェア開発では、複数の開発者が複数の機能を並行開発していくことが一般的になっています。ソフトウェアが大規模化し、求められる開発スピードも増しているからです。主張理由

Slide 49

Slide 49 text

Step④：わかりやすく、簡潔な文章で書く 51

Slide 50

Slide 50 text

書くときの心構え ⚫ 重要なことから書く ⚫ （自分ではなく）読者の視点で書く ⚫ 読者の行動をイメージしながら書くどんな人が、どんな情報を、どのように探すか ⚫ 簡潔に、できるだけ短文で書く 52

Slide 51

Slide 51 text

重要なことから書く 53 ⚫ Before（理由 → 主張の順）ソフトウェアが大規模化し、求められる開発スピードも増しているため、現代のソフトウェア開発では、複数の開発者が複数の機能を並行開発していくことが一般的になっています。 ⚫ After（主張 → 理由の順）現代のソフトウェア開発では、複数の開発者が複数の機能を並行開発していくことが一般的になっています。ソフトウェアが大規模化し、求められる開発スピードも増しているからです。 ✓ ドキュメントは、一部しか読まれないことを前提に書く ✓ 情報に優先度を付けて、優先度が高いことを先に書く ✓ たとえば、主張（伝えたいこと）は理由よりも前に書くポイント

Slide 52

Slide 52 text

読者の視点で書く 54 ⚫ Before GitHubでのプルリクエストの作成をトリガーにして、コードの自動テストを実行します。 ⚫ After GitHubでプルリクエストを作ると、書いたコードが自動的にテストされます。 ✓ 読者の視点で書くことが、読みやすさと、わかりやすさに繋がる ✓ システムが主語になっていると、自分視点に置き換えながら読まなくてはならなくなるポイント

Slide 53

Slide 53 text

能動態と受動態を使い分ける 55 ⚫ Before GitHubでプルリクエストを作成すると、コードの自動ビルドと自動テストを実行します。 ⚫ After GitHubでプルリクエストを作成すると、コードの自動ビルドと自動テストが実行されます。 ✓ 読者の視点で書くと、読者の操作は能動態、システムの動作は受動態になるポイント能動態受動態読み手の視点システムの視点

Slide 54

Slide 54 text

一文一義で書く ⚫ Before ソフトウェアが大規模化し、求められる開発スピードも増しているため、現代のソフトウェア開発では、複数の開発者が複数の機能を並行開発していくことが一般的になっています。 ⚫ After ソフトウェアが大規模化し、求められる開発スピードも増しています。そのため、現代のソフトウェア開発では、複数の開発者が複数の機能を並行開発していくことが一般的になっています。 56 ✓ 1つの文には、1つの事柄だけを書く ✓ 1文に複数の事柄が詰め込まれていると、内容を整理しながら読まなくてはならなくなるポイント

Slide 55

Slide 55 text

一文を短くする 57 ⚫ Before 継続的インテグレーションを導入することで、ソフトウェアの品質を安定的に保つことができ、また、ソフトウェアのリリースに掛かる時間を短縮することができます。 ⚫ After 継続的インテグレーションを導入することで、ソフトウェアの品質を安定的に保つことができ、保てます。また、ソフトウェアのリリースに掛かる時間を短縮することができます。も短縮できます。 ✓ 簡潔、短くを常に意識する ✓ 「したがって」「また」などの接続詞も、不要なことが多い ✓ 「（文の）わかりやすさと長短とは本質的には関係がない」（『日本語の作文技術』 12刷, 本田勝一, P.194）が、書き慣れていない人は「1文を短く」を常に意識すべきポイント

Slide 56

Slide 56 text

主語と述語の対応に気をつける 58 ⚫ Before 継続的デリバリーは、開発者によるアプリケーションへの変更に対して、バグがないか自動的にテストし、リポジトリにアップロードします。 ⚫ After 継続的デリバリーは、開発者によるアプリケーションへの変更に対してバグがないか自動的にテストし、リポジトリにアップロードするプロセスです。 ✓ 主語と述語が一致しないと、意味が通らない文になる ✓ 文が長くなると起こりがちなミスなので、意識して気を付けるポイント

Slide 57

Slide 57 text

修飾する側とされる側を近づける 59 ⚫ Before Dockerイメージは、docker buildコマンドを実行すると、Docker fileというファイルで指定した命令に従ってビルドされます。 ⚫ After docker buildコマンドを実行すると、Docker fileというファイルで指定した命令に従ってDockerイメージがビルドされます。 ✓ 文が長くなるときは、修飾する側（主語や目的語）と修飾される側（述語）を近づけると、読みやすくなるポイント

Slide 58

Slide 58 text

修飾部が複数あるとき 60 docker buildコマンドを実行すると、Docker fileというファイルで指定した命令に従って Dockerイメージがビルドされます。 Docker fileというファイルで指定した命令に従って Dockerイメージがビルドされます修飾する側修飾される側 ✓ 修飾部が複数あるときは、長い修飾部から順に書くポイント

Slide 59

Slide 59 text

読点を適切に打つ 61 ⚫ Before コードがマージされると、アプリケーションのビルドと単体テストと統合テストが自動的に実行されます。 ⚫ After コードがマージされると、アプリケーションのビルド、単体テストと、統合テストが自動的に実行されます。 ✓ 読みやすさのために、読点は特に重要 ✓ 読点を適切に打つことで、係り受けや並列関係がはっきりし、文章が読みやすくなるポイント

Slide 60

Slide 60 text

読点のパターン 62 例説明 Webサーバーにより、出力されるヘッダは異なります。係り受けを明確にするために打つコードがマージされると、アプリケーションのビルド、単体テストと、統合テストが自動的に実行されます。並列関係を明確にするために打つ docker buildコマンドを実行すると、Dockerイメージがビルドされます。理由・条件・目的などを明確にするために打つ AブランチをBブランチに、CブランチをDブランチにマージします。句の区切りを明確にするために打つなお、モノリシックなアプリケーションにはこの設定は不要です。接続詞の後ろに打つ（任意）

Slide 61

Slide 61 text

並列の情報には箇条書きを使う 63 ⚫ Before コードがマージされると、アプリケーションのビルド、単体テストと、統合テストが自動的に実行されます。 ⚫ After コードがマージされると、アプリケーションに対して次の処理が自動で実行されます。 ⚫ ビルド ⚫ 単体テスト ⚫ 統合テスト ✓ 並列の情報を並べるときは、箇条書きを活用すると、並列関係が視覚的にわかりやすくなるポイント

Slide 62

Slide 62 text

できるだけ具体的に書く 64 ⚫ Before 例1：ビルドからデプロイまでのサイクルを素早く回します。例2：メール通知の設定を確認してください。 ⚫ After 例1：ビルドからデプロイまでのサイクルを、少なくとも1日 1回、できれば1日複数回の頻度で回します。例2：メール通知が有効になっていることを確認してください。 ✓ 曖昧な表現は、書き手の意図通りに伝わらない ✓ 具体的に書く努力をポイント

Slide 63

Slide 63 text

肯定形で書く 65 ⚫ Before マージしたブランチは、残したままにしないでください。 ⚫ After マージしたブランチは、削除してください。 ✓ 否定表現は意味を曖昧にする ✓ 肯定形で表現できる場合は、なるべく肯定形を使うポイント

Slide 64

Slide 64 text

二重否定を使わない 66 ⚫ Before ビルドが終わらないと、ロールバックできません。 ⚫ After ビルドが終わると、ロールバックできます。 ✓ 否定表現は、1つの文に1つまで ✓ 二重否定は文章をわかりづらくし、読者の混乱を招くポイント

Slide 65

Slide 65 text

「～の」は1文に2つまで ⚫ Before GitHubのGUIからのPull RequestのRevertにより簡単にロールバックを行うことができます。 ⚫ After GitHubのGUIからPull RequestをRevertするだけで、簡単にロールバックできます。 67 ✓ 「～の」が続くと読みづらくなる ✓ 「～の」は、1文に多くて2つまでポイント

Slide 66

Slide 66 text

チェックシート ✓ 冒頭に概要を書いていますか？ ✓ 一文一義で書いていますか？ ✓ 読者の視点で書いていますか？ ✓ 重要なことから書いていますか？ ✓ 文はこれ以上短くなりませんか？ ✓ 曖昧な表現はありませんか？ ✓ 係り受けは明確ですか？ ✓ 否定文は肯定形で書けませんか？ ✓ 修飾する側とされる側が離れ過ぎていませんか？ 68

Slide 67

Slide 67 text

ご清聴ありがとうございました本セッションが皆さまの情報発信に役立つことを願っています！ 69