【うひょ氏】技術発信や登壇資料づくりに。記事の隙をなくして理解度を上げる文章テクニック

皆さんこんにちは。前回は、私の技術発信の遍歴をご紹介するとともに、私の考える、技術発信に必要な能力や考え方をご紹介しました。

今回は、より具体的なテクニックやその背景をご紹介します。すでに技術発信をしている方や、これからやろうと思っている方はぜひ参考にしてみてください。文章のテクニックと、登壇（登壇資料）のテクニックをあわせてご紹介します。

• keyboard_arrow_down 記事の正しさを担保する
• keyboard_arrow_down 分かりやすい記事を書くために
• keyboard_arrow_down 登壇資料のテクニック
• keyboard_arrow_down まとめ

前回の連載でも少し触れたように、私は記事の正しさをとても重要視しています。これは自分のこだわりという側面もありますが、記事を通して自分の評判を築くために、正しさは重要です。技術発信でのし上がりたいと思う方は、ぜひ正しさに気を遣っていただきたいと思います。

記事の正しさには、いくつかの面で意味があります。ひとつは、筆者は正確な知識を持っているぞというアピールです。正確な知識を持つ人として読者に認知されることで、筆者自身への評価や、その人が書いた他の記事の内容に対する信頼も向上します。

特に、マニアックな内容になると読み手が自分で記事の正確性を判断するのも難しくなってきます。そのような場合に記事を読んでもらえる（記事の内容が正しいと信じてもらえる）かどうかは、これまでの信頼の積み重ね次第でしょう。

次に、ある種当たり前ではありますが、細部までこだわって正しい内容の記事とすることで、読者が新しい知識を得る機会を増やすことができます。結局、技術記事の最大の目的は読者が新しい知見を得ることですから、その可能性を上げることは重要です。

ただ、細部の正しさはマニアックさと表裏一体です。やりすぎると、細かすぎて読むのが疲れる記事になってしまいます。記事のテーマや対象読者、自分の目指す方向性に合わせて調整しましょう。

最後に、記事の正しさにこだわることは、記事の隙をなくすことに繋がります。些細なことでも間違った記述があると、批判の的になってしまいます。記事の瑕疵を攻撃的なふるまいの材料にしてしまう人もいますから、書き手の精神衛生の面でもそもそも間違いを書かないに越したことはありません。指摘を受けたら真摯に対応すればよいとはいえ、それにも精神力が必要です。

正しさにこだわった書き方

例えば、JavaScriptを想定して、次のような記述があったとしましょう。

// 書き換え前
const result = obj.a + obj.a + obj.a;
// 書き換え後
const result = obj.a * 3;

この記述は一見正しそうですが、実はエッジケースがあり、厳密に言えば正しさの面で穴があります。

次のように注釈を付けることで、隙の無い記述となります。

しかし、言いたいことよりも注釈が長くなってしまいました。記事の雰囲気によってはこれでも構いませんが、正直まともに取り合わなくてもいいエッジケースのために記事の読みやすさを損なってしまうのは望ましくありません。

そのような場合は、次のような記述でごまかすのも手です。

このように、「例外がある」とだけ言っておいて最低限、嘘ではない状況を担保します。記事の本題と関係ない場合はこれでも十分でしょう。もし「エッジケースって何ですか？」と聞かれたら答えてあげましょう。

別のパターンとして、そもそも筆者自身が断言してもよいかどうか自信が無いという場合もあります。その場合は、断言を避けたほうがよいと思います。断言できるだけの知識が筆者側に無いのに断言してしまうのは、記事の内容にほころびを生む恐れがあり危険です。一例としては次のように書きます。

この文例では、「あるかもしれません」という言い方で断言を避け、かつ「エッジケースがあったとしても本筋には関係ない」という主張で記事の本筋を支えています。

基本的には、知識が無くて断言できない場合や推測が混じる場合には、「推測ですが」などと正直に書くのがおすすめです。そのほか、この文章でも実際に使われているテクニックですが、「と思います」のように客観的な事実ではなく筆者の考えであると明示することも有効です。

断言するために検証する

断言すべきところでちゃんと断言するために必要なのは知識ですが、細かな情報を全て完璧に把握するのは並大抵のことではありません。

そのため、重要なのは自分の言っていることを検証し、裏を取ることです。その具体的な方法は技術領域によってさまざまですが、JavaScriptであれば仕様書を参照する、TypeScriptであれば公式ドキュメントを参照する、あるいは高度な情報に関してはGitHubのissueやPRを見るのがよいでしょう。具体的なプログラムの挙動に関してなら、実際にプログラムを動かして確かめるのも有効です。

いずれにせよ、断言したことについては、その根拠を示せるとベストです。「仕様書によれば、～」や「手元のGoogle Chrome上で実際に動作させたところ、～」といった記述をしましょう。なぜ筆者がそれを断言できたのかを明確にすることで読者の信頼を得られるとともに、自分でさらに調べたい読者や、そもそも情報収集の方法を知りたい読者にも価値を提供することができます。

メリハリを意識する

内容の正確を期すことはとても重要ですが、そのための記述ばかりで記事が読みにくくなってしまうと本末転倒です。当たり前のことにもいちいち根拠を付けて回るのは、（対象読者のレベルにもよりますが）メリットがありません。

極端な話、前述の「思います」を使いすぎて記事の内容が推測だらけになってしまうと、読者が得るものが無くなってしまいます。記事の要所ではしっかりと断言できるように知識を付けるのが基本路線です。

うまく正確性と冗長さのバランスを取らなければなりません。さらに、裏取りは労力がかかります。記事を書く際に、本文を書くよりもその前の調べ物のほうが時間がかかるのは日常茶飯事です。そのため、むやみに労力をかけ過ぎないことも重要です。

考え方としては、メリハリを意識するとよいでしょう。記事の本題に関わる重要な主張はビシッと決めて、重箱の隅のようなささいな所や余談のような所は、正確性を損なわない範囲で労力をかけずに流します。このように記述にメリハリがあると、読む側としても記事のどこが本筋の主張なのか分かりやすくなるという効果も期待できます。

前回述べたように、分かりやすい記事を書く能力は、技術発信において大きな力となります。その具体的なやり方として論理的な文章を書くということを前回解説しました。

記事の分かりやすさのためには、中身以外に文章の読みやすさも重要です。読みやすさに気を遣うことで記事のクオリティを向上させることができます。そのために役立つテクニックを見ていきましょう。

読みやすさがどう活きるのか

特にマニアックな題材を扱う記事の場合は、読みやすさに特段の注意を払うべきです。技術的な中身の理解に読者の思考リソースが割かれていますから、中身と関係ないところで余計に消耗させないようにしなければなりません。

読みにくいところがあると、読者が読むのを諦める理由付けになってしまい、結果として「難しくてよく分からなかった」という感想をもらってしまうかもしれません。読みにくいところが記事の隙となり、読者が「難しい」「分からない」と結論付ける理由付けを与えてしまうのです。

読者は、記事が難しい・分からないと思ったとき、なぜそう思ったのか詳細に自己分析してくれるとは限りません。技術的な内容が難しすぎたのか、それ以外の部分で引っかかったのか等にかかわらず、「読んでも分からない記事だった」という漠然とした評価が残るだけです。

そして、同じ著者の記事でそのような体験が続けば、著者に対する評価が下がることになります。逆に、「難しい内容だけど理解できた」のような成功体験を読者に与えることができれば、著者のイメージアップにも繋がります。また、技術的なところで理解できない読者がいるのは仕方がないとしても、どこが分からなかったのかを読者自身が理解できるように支援してあげることで、読後感を良くする余地があります。

技術的なところ以外で読者からの好評価を逃すのは勿体ないことです。以下に紹介するテクニックを使って、読者が本題に集中できるような記事作りを目指しましょう。

アカデミックライティングの技術

実は、私が書く文章の基礎を成しているのは、大学時代に学習したアカデミックライティングです。アカデミックライティングとは、大学など学術的な場面で書かれる文章のスタイルを指す言葉です。技術記事が全てこのような形式である必要はないでしょうが、私が書くような技術記事を書きたい場合には、アカデミックライティングのスキルが力になってくれるでしょう。

Google検索で「アカデミックライティング」で検索すると一番上に出てきた「アカデミック・ライティング力を磨こう」には、アカデミックライティングの特徴について次のように記述されています。

第一の特徴は「分かりやすい文章」です。（中略）第二の特徴は「科学的な文章」です。アカデミック・ライティングでは主張を裏付ける根拠の提示が求められます。

これはまさに、前回から今回にかけてよい技術記事の特徴として説明してきたことそのままです。アカデミックライティングの技術を活かせば、（私のやり方ではですが）記事の質を向上させられるのは間違いありません。

とはいえ、技術記事でそこまで厳密にアカデミックライティングに従う必要があるわけでもありません。アカデミックライティングは「厳格なルール」と説明されることもありますが、技術記事はもっと気楽なものです。分かりやすい記事という目的のために、取り入れられそうなところを取り入れればよいでしょう。

私がアカデミックライティングのテクニックの中でも普段から意識しているのは、パラグラフライティングです。詳細については調べていただきたいのですが、「各段落の最初の一文だけを繋げて読んでも意味が通る」やつとして知られています。

つまり、各段落の構成を揃えて最初の一文に主張を置き、2文目以降はそれに付随する補足を並べます。次の主張をしたくなったら、別の段落にします。この記事でも、完璧ではないにせよできる限りこの構成を意識しています。確かめてみましょう。

引用を活用する

学術的な文章においては、引用が重要です（quotationではなくcitationのほうです）。つまり、文章中に出てくる説明が自分で考えたものではなく他人のアイデアならば、それが誰のアイデアなのか、引用元を明記するのです。論文では、適切な引用を怠ると、剽窃として大問題になります。

技術記事においても、このように引用を行うのは有効です。論文ほど厳密に行う必要性はありませんが、他の人が言っていることを紹介するならば元の記事にリンクを張ったほうがよいでしょう。そうすることで、元の記事に敬意を払うことができますし、読み手も知識を繋げることができます。

前述の「正しさの担保」という観点でも引用は有効です。「Xである」と断言できるかどうか怪しい場合でも、「XであるとAさんが言っていた」ならば断言できることもあります。それが記事の主題であれば自ら検証したほうが良いでしょうが、本題ではなかったり、前提知識や文脈だったりするときは深入りせずに流すのもよいでしょう。

ちなみに、100%正しいか分からないことを前提条件に置くのは構いません。その場合「これが正しいということを前提にこの記事では話を進めます」という立て付けになります（正しくない確率が結構あるようなことを前提に置く場合は、このような注意書きを明記するとよいでしょう）。

その前提の上で議論を展開して記事を書いて、前提そのものが間違っていたとしても、それは記事が正しくなかったということにはなりません。数学的に言えば、Pが偽だったときでもP → Qという命題は真になるという話に相当します。ただし、前提が違った場合は記事の意義が薄れてしまいます。不確定な未来の動きを先取りして議論する場合などにこの考え方が有効です。

表現や文体を調整する

記事執筆の際、原稿ができた後に見直して推敲するのは重要なことです。私は早く記事を出したいときは見直さずに、書き終わった瞬間に投稿してしまうこともありますが、自信作の記事や特に注目してほしい記事の場合は見直して記事のクオリティ向上に努めます。私の経験上、見直せばちゃんと記事の質は上がります。

私が書きあがった記事を手直しするときに行うのは、実は細かい表現の修正がほとんどです。不自然な言い回しがあれば修正する、係り受けが分かりにくいところがあれば単語を並び替えて分かりやすくするなど、細かい表現の調整を行っています。

私の経験上、このような細かな調整にも効果はあります。見直しをしっかり行った記事というのは、それだけ中身にも自信がある記事だからという理由もありますが、読者から好評を得やすいと感じています。

他に、単語をいつ漢字で書き、いつひらがなで書くのかということも意識します。これは本当に一般的な「日本語の書き方」のような話になりますが、例えば前の文では「事」ではなく「こと」と書いていますね。これは絶対の正解ではないにせよ、広く知られているルールです。

別に漢字で書いてもよいところを、敢えてひらがなで書いている場合もあります。例えば、前の文は「書いても良い」ではなく「書いてもよい」となっていますね。

これは明確なルールに従ってやっているわけではありませんが、文体の硬さを調整する意図があります。漢字をひらがなに直すだけではなく、やわらかい印象を与える語彙を使うこともあります。「行っている」ではなく「やっている」と書くのもその一環です。ただし、ひらがなばかりになるととても読みにくいので、その場合の調整にも気を遣います。今回の場合、「ひらがなばかりになるととても」は許容範囲を超えて読みにくいので、「ひらがなが多く続いてしまうと非常に読みにくい」のように直せそうですね。

どれくらいの硬さの文章にすればいいのかは自分の目指すスタイルや記事の中身によります。私も、いろいろな硬さの文体を使い分けています（この記事は中くらいの、普段の文体です）。

ただ少なくとも、ひとつの記事の中では文体（硬さ）は統一したほうがよいと思います。読者がスムーズに記事を読むのを阻害する要素はすべて排除しましょう。なお、雑誌などの媒体の場合は、媒体側で文体や漢字の使い方が統一されることもあります。ありがたいですね。

フィーリングで決めてもよいので、「普段の文体」を何となく決めてそれに寄せていくことで、いつのまにか文体が個性になります。読みやすい文章づくりを心がけつつ、文体という形で自分のブランドを育てていきましょう。

次に、登壇資料（スライド）を作る際に私が気を付けていることを紹介します。

私が登壇資料を作る際に気を付けていることも、実は大学時代に指導されたことに由来しています。私の指導教員はしっかりと指導してくださる人だったので、最初資料を作ってみせて「何もかもだめ」と言われて考え直すのが恒例でした。そのような経験が今も活きています。

登壇資料の2つの側面

エンジニア向けの登壇資料に限って言えば、登壇資料は2つの異なる側面を併せ持っています。ひとつは、発表時に投影され、トークを補助するものという側面です。もうひとつは、のちのち資料単体で公開・拡散され、技術記事のように単体で閲覧されるという側面です。

厄介なことに、この2つの側面は相反するところがあります。単体で閲覧される資料という側面を重視するならば、言いたいことを全部文字に起こしてスライドに書いておく必要があります。一方で、トークの補助に徹するならば、極論、文字を一切使わずにトークに合わせた図が表示されるだけでも成り立つでしょう。

どのようなトークを行いたいかによっても資料の中身は左右されます。学会発表ならば言うべきことをスライドに全部書いておいて、それを（書いてあることをそのまま読み上げるのは良くありませんが）口で説明するだけでも十分成り立つでしょう。一方で、エンジニア向けの勉強会などでは、もっとエンターテイメント性を含んだ発表をする人もたくさんいます。そのような発表のための資料はインパクトや絵面といったものが重要になってきます。

私が作る資料は、どちらかと言えば「学会発表」寄りです。提供したい情報は基本的に全部スライドに書いておいて、発表時は書いてあることを説明します（資料に書くほどでもない補足を口頭のみで入れることもあります）。これは、私のバックグラウンドがそちら側に寄っているという理由もありますし、発表終了後も資料が参照され続けるという側面を重視した結果でもあります。

そのため、以降の内容は、登壇資料にどう情報を書くのかという話が多くなります。あなたの発表スタイルによっては当てはまらない点もあるかもしれませんがご勘弁ください。

「正しさに気を付ける」など、中身については技術記事と同じことが当てはまります。引き続き気を付けましょう。以降では、登壇資料に特有の話を見ていきます。

登壇資料とアクセシビリティ

登壇資料を作る際に気を付ける点を挙げろと言われたら、私がまず挙げるのは「文字の大きさ」です。文字の大きさが小さすぎてはいけません。

資料をスクリーンに投影するとき、文字が小さすぎると観客が文字を読めません。基本的なことですが、文字が読めないということが起こらないように気を付けています。登壇の場においては資料は補助的なものであるとはいえ、わざわざスクリーンに文字を映したということは、それを読めという意味になります。それなのに読めないというのは良い体験ではありませんから、何としても避けましょう。

一時期、オンライン勉強会が主流になった時期は登壇資料の文字が小さくなる傾向があったように思います。自分の画面で資料を見るので、実際の会場で見るよりも文字が読めない問題が起きにくかったからでしょう。最近はオフラインの勉強会が増えてきましたから、文字の大きさには気を付ける必要があります。

また、後から資料を読む際も、スマートフォンから見るときに文字が小さいと結構つらいです。このような場合の読みやすさも考慮してあげるのが吉です。

私は普段PowerPointで資料を作っていますが、文字の大きさは32を基本として、注釈用の小さめの文字は24にしています。どうしても文字が多くなってしまうときは28と20～22に調整する場合もあります。さらに小さい文字は出典の表記やニッチな補足に使い、無理に読まなくてもよいという位置づけにしています。

また、色覚多様性の観点から、色の使用にも気を付けています。色のみで何かを区別することを読者に求めないことを原則として、例えば文の一部を強調する場合は色を変えるだけでなく、太字とセットにしています。色の適切な使用は理解を促進するのに有用ですから、色は適宜使いつつも、色がなくても資料の理解に必要な情報は揃っているという状態を目指しています。

文字の大きさや色の話は「アクセシビリティに配慮する」としてまとめることができます。特にフロントエンドエンジニアの方は、普段活用しているアクセシビリティの知識が資料作りにも役に立つはずです。

スライドの構成

スライドの特徴は、ページ型のメディアであることです。文章は（適宜見出しで区切られるとはいえ）読み手の体験は連続的なものになります。一方で、スライドはページ単位で離散的に推移します。

文章と同様のテクニックを活用しつつ、スライドの特徴に合わせた構成にする必要があります。

スライドの構成において私が最も重視しているのは、1スライド1メッセージにすることです。パラグラフライティングでは1パラグラフにひとつの主張を置きますが、それと同様と考えてもよいでしょう。例えば、先ほどの図のスライドのメッセージは「ECMAScriptではモジュールは3種類に分類される」です。

どうしても読者はスライド単位で話を理解しようとします。そのため、複数スライドにまたがってひとつの話をしたり、逆にひとつのスライドで複数の話を混ぜたりすると読者は理解してくれなくなります。

また、私が大学のときに受けた教えに「聴衆の記憶領域はスライド1枚分」というものがあります。つまり、特に実際にトークをしている最中においては、聴衆は今の1個前のスライドの話は覚えているが、2個前の話はもう覚えていないということです。そのため、2つ以上前のスライドの記憶を要求するような話は理解してもらえない可能性があります。そのため、1〜2スライドという細かい単位で読者に納得を繰り返してもらい、文脈を蓄積するのが理想的です（これを厳守するのは相当難しく、まさに理想論ではありますが）。

この延長線上にある考え方として、全体→各論という流れで話を進めたり、頻繁にアウトラインを表示して話の現在地を思い出してもらったりというテクニックがあります。

特に、スライドでは読者にアウトラインを認識してもらうための構成を意識的に行う必要があります。文章では見出しさえ付ければ自然に読者にアウトラインを意識させられますが、スライドではそうもいきません。意識的にそのような機会を作らないと、階層構造が感じられず抑揚のないスライドとなり、読者が話に付いてこれなくなります。

どこで話の区切りがついて、どこで話が切り替わったのかということを明確にして、読者が振り落とされるのを防ぎましょう。しつこいくらいにアウトラインと現在地を表示するのが愚直ながら簡単な方法です。もう少しおしゃれにやる方法もいろいろあります。例えば、まずQ（問題）を提示したスライドを表示し、そのあといくらか解説を行い、最後にQを再掲しつつA（答え）を提示すれば、その問題に関する話題がどこから始まってどこで終わったのか明確になります。

スライドの文体

私の考えではありますが、スライドに含まれる文はなるべく簡潔にするべきです。主語と述語が揃った完全な文にする必要もありません。省略、体言止め、箇条書きといった手法を駆使して文字数を減らしましょう。

前述の図でも、メインのテキストは「ECMAScriptでは3種類に分類される。」となっており、主語がありません。この場合、主語が「モジュール」であることはスライドタイトルや文脈から分かるので省略しています。

他には、スライドが変わることで自動的に区切りが付くので、「また、」や「さらに、」といった語調を整えるための接続語は必要ありません。それよりも簡潔さを優先したほうがよいでしょう。

一方で、「しかし」など逆接の接続語については普段より強調しないと、逆接という文脈が伝わらない恐れがあります。前述の「アウトラインを認識してもらうための構成」にも繋がる話ですが、スライドが切り替わって離散的に進むという特性上、順接以外の進み方をする際は明示的にやらないと読者の理解が漏れてしまいかねません。読者の注意を引くために、「しかし……」だけ書いたスライドとか、前のスライドにバツを乗せたスライドとかを用意して丁寧に話題を転換するのも効果的です。

ちなみに、私はスライド中のテキストに句点（。）を使用していますが、これは珍しいかもしれません。あまり一般的な作法ではなく、句点を全く用いないのが主流です。私は何となく句点がないと締まりがないと感じるので、標準的なやり方から外れることを承知で句点を付けています。

一応、メインのテキストのみに「。」を付けて、箇条書き部分など補助的なテキストには付けないことによって、スライド中のメインのテキスト（言わばトピックセンテンスですね）を強調するという効果も期待しています。まあ、一般的なやり方ではありませんので参考にしなくても構いません。

今回は、私が技術記事や登壇資料を作成するときに考えていることを思いつく限りご紹介しました。

技術記事に関しては「正しさ」と「分かりやすさ」の2つの軸で、クオリティが高く隙のない記事を書くための考え方を解説しました。

登壇資料（スライド）の特別注意すべき点についても合わせて解説しました。スライドというメディアの特性に合わせて書き方を考えましょう。

資料の質は書く人の技術力に左右される部分が大きいというのは避けられない前提です。しかし、それ以外のテクニックで補える面もあります。質の高い資料を作るために、技術力以外でもやれることはやることを心がけましょう。