LINE社内で大評判のテクニカルライティング講座で説明した内容をあらためてブログにまとめてみた
LINE株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。 LINEヤフー Tech Blog こんにちは、Developer Contentチームの矢崎です。LINE株式会社でテクニカルライターとして働いています。今日は、私が1文を書くときに気をつけていることや手法についてお話しします。 そして、この書き出しは、6月にmochikoさんが書いた「LINEの社内には「テクニカルライティング」の専門チームがあります」という記事のオマージュになっています。mochikoさんが書いた記事ですごいpvをたたき出したそうなので、人のふんどしで相撲を取ってみようという作戦で始めてみました。 この記事ではLINE社内で私が講師を務めた「LINE社内で大評判のテクニカルライティング講座」に沿って、わかりやすい1文を書くコツを紹介していま
テクニカルライティングの基本を学べます。サイボウズの新入社員向け研修資料です。業務マニュアル、報告書、仕様書、技術解説書などのドキュメントを書く機会がある方向け。 Twitter：https://twitter.com/naoh_nak 2023年度のアップデート版もあります：https://speakerdeck.com/naohiro_nakata/technicalwriting2023
はじめに エンジニアにとって、仕様書などの技術的な文章を書くこと（テクニカルライティングとも言います）は避けて通れません。ただ20年来多くのエンジニアの方々と同僚として接してきて思うことは、エンジニアの方の中には「文章を書く」ということに苦手意識がある方が一定数いるということです。 でもこの「テクニカルライティング」のスキルは、才能というよりは一種の「技能」だと思うんです。ある一定の原理原則を理解して実践を繰り返すことで、必ず一定レベルで習得できるものだと著者は信じています。 もしこのテクニカルライティングの原理原則をまだ体系的に学習したことがない、または過去学習したが改めて再学習したいという方に、お勧めのコンテンツを見つけたのでご紹介します。 https://developers.google.com/tech-writing Every engineer is also a write
テクニカルライティングの基本を学べます。業務マニュアル、報告書、仕様書、技術解説書などのドキュメントを書く機会がある方向け。 サイボウズの2023年度 新入社員向け研修の資料です。 Twitter：https://twitter.com/naoh_nak 2022年版（初版）：https://speakerdeck.com/naohiro_nakata/technicalwriting
相手に誠実に、わかりやすい文章を書くための心がけをまとめました。 どういう思考プロセスからどんな表現が生まれるのか、参考として実例を紹介しています。実際に読み比べ、SmartHRの従業員として何かを伝えようとするときの、参考にしてください。 伝わる文章のガイドライン何を伝えるかによって、必要な情報の量や説明の粒度は異なります。 情報が不足していたり、逆に情報が多すぎたりすると、読者が意図を読み取れないことがあります。 読み手となる相手の状況（読む場面、事前知識など）を踏まえ、言葉にする内容や表現を厳選することが大切です。 目的に合わせて情報を取捨選択する読者の目線に立ち、コンテンツの目的に合わせて情報を取捨選択しましょう。 実例1：法律や業務に関わる記事目的業務に関係する「厚生年金保険」について正確に知りたいと思っている人に、わかりやすく内容を伝える。 Before日本の年金制度は、全国民
こんにちは、Choimirai School のサンミンです。 【主要なアップデート】 （2023.10.01）ベゾス氏がパワポを禁止した理由を語った動画を追加 （2020.05.11）Blitzscaling、ビル・ゲイツのコメントと英語版リンクを追加 （2020.05.11）知的生産の技術に関するコメントを追加 0 はじめに ▲アマゾンの社内プレゼンテーションで、パワーポイントの使用が禁止されているのは、かなり有名な話。 会議では、冒頭のおよそ15～20分間、参加者全員にドキュメントを読むための時間があてられる。ドキュメントは６ページと長い場合も多く静まったミーティングルームで参加者が黙々とドキュメントを読む雰囲気はかなり緊張感が漂っている。
スケベ小説を書くときの参考書・ツールまとめ
喚く狂人 @wamekukyouzin コミケで「スケベ小説を書くにあたって使っている参考書」みたいな話をしてたら、「それTwitterに書いてまとめたら？」という話になったので、色々紹介していきます。 2022-01-01 23:31:21 喚く狂人 @wamekukyouzin 文が読みづらいと「使いづらい」ので、なるべく分かりやすくしたいです。そこで本田勝一「日本語の作文技術」。 修飾語の順序であったり句読点の使い方について体系だって解説するベストセラーです。エロに限らず趣味で小説を書くなら是非読むとよいと思います。 ただし例文の政治的思想が強いです。 2022-01-01 23:31:42
『理科系の作文技術』を久しぶりに読み返し、とにかく「6 はっきり言い切る姿勢」「7 事実と意見」だけは絶対にみんな読んだ方がよい、と思った - Magnolia Tech
理科系の作文技術（リフロー版） (中公新書) 作者:木下是雄発売日: 2016/10/14メディア: Kindle版 いまさら紹介するまでもないけど、とりあえず作文方法を学びたい時は、まずはこの「理科系の作文技術」を読むことをお勧めする。 最近ブログのエントリをざっと書いてそのまま公開してしまうことが多かったので、少し反省し、それを直すためにこの本を改めて読み直した。そうしたら、タイトルで全部言い切っているのだけど、とにかく「6 はっきり言い切る姿勢」「7 事実と意見」だけは絶対にみんな読んだ方がよい、と思った。 日常的にメールや、ブログの記事など、それなりの量の文章を書くことが多いけど、論文や雑誌の記事など、きちんと他人の目を通した上で公開される文章を書くことは、まずない。一度だけ、雑誌の記事原稿を書いたとき、自分なりにかなりの推敲を重ねたつもりでも、プロの編集の方から見れば言葉使いや、
こんにちは、Developer Contentチームの矢崎です。LINE株式会社でテクニカルライターとして働いています。先日、このLINE Engineering Blogで「LINE社内で大評判のテクニカルライティング講座で説明した内容をあらためてブログにまとめてみた」というタイトルで、1文を書くときに気をつけていることや手法について紹介しました。 前回の記事を簡単にまとめると「たくさんの文案を書いて、一番良さそうなものを選択することがとても大切です」という話を多くの例文を使って説明しました。まだ読んでいない方はぜひ読んでみてください。 今回の記事は、第2弾です。次のステップとして「1文では説明が終わらない文章をどのように組み立てていくとわかりやすいか」という話を、以下のような文章を例に説明していきます。 ここでは、このくらいの情報量の文章を「トピック」と呼びます。 第2弾を最後まで読む
文章は、「これで伝わるだろう」という淡い期待を簡単に裏切ります。伝えたいことを期待通りに伝えられるようになりたいのなら、「表現の質」を高めるための推敲の技術の習得が不可欠です。 この記事では、大切ながら手間のかかる推敲を「効率的に」実施する方法を紹介します。ほとんどはじめて論文を書くことになった学生さんが、論文原稿（卒論・修論）の価値を飛躍的に向上させるうえで役にたちます。また、論文に限らず、「正しく、詳しく、丁寧に伝えたい」という気持ちで文章を書こうとする場合には、さまざまな場面で使えるはずです。 この記事で紹介する推敲の手段は、「切り分ける・並び替える・繋ぎ方を変える・削り落とす・一貫させる・まとめる・明確にする・限定する・やさしくする」の９種類です。この９種類さえ自由自在に駆使できれば、論文の文章を劇的に良くすることができます。この９種の推敲を、「まず工事して、片付けて、最後に気遣い
こんにちは。壮（@sew_sou19）と申します。 メガベンチャー企業でエンジニアとして働いています。 エンジニアにジョブチェンジした当初は、ドキュメントの書き方なんてこれっぽっちも分かりませんでした。読みやすいドキュメントを書くことが本当に苦痛だったのですが、考えて、試行錯誤し続けた結果、以下のような評価を得るに至りました。 リーダーから「君は情報の整理が上手でドキュメントが本当に読みやすい。チーム全体の能力向上に繋げたいからドキュメント書く際のポイント共有してほしい」と言われたので、意識していることを言語化しつつテクニカルライティングの本でインプットしてるけど、学びが多い。ついでにnoteにもまとめてる — 壮 (@sew_sou19) November 28, 2022 そこでこのnoteでは、僕がドキュメントを作成するときに、特に意識して実践している7つのことを書きます。（本当は2
短いメッセージを書くことはできても、まとまった文章を書くのに苦労している人は多いのではないでしょうか。 この記事では、まとまった文章を作るときの技術を学ぶことができる記事や学習コンテンツを紹介します。新人エンジニア向けです。 文章の「型」を学ぶ まとまった文章を書くには、「型」が必要です。頻繁に使うものは、「型」を覚えてしまいしましょう。 バグレポートの書き方を学ぶ エンジニアとして書く文章の代表例が、バグレポートです。 バグレポートでありがちな失敗として「何が問題だと思っているのか」が伝わらないというものがあります。 これを防ぐために、「期待する結果」「実際の結果」「再現手順」の3つを必ず書くようにしましょう。 質問の書き方を学ぶ エンジニアが扱う技術は、最初はわからないことだらけです。 それを解決するために、質問の文章を作成する技術が必要となります。 概ね下記の4つの情報があれば、良い
システム開発にドキュメントは欠かせません。ドキュメントが得意になれば活躍の幅が大いに広がりますよね。 この記事では、まず冒頭でドキュメントの作成に求められると思うことを整理した上で、そのスキル獲得に役立つと思われる記事や書籍を集めてみました。もちろん他にもあると思うので、もしお薦めのものがあれば是非コメントで教えて下さい 更新履歴 ・2021/04/16：文章術系にリンクを追加しました。 ・2020/11/28：文章術系にリンクを追加しました。 ・2020/07/24：文章術系にリンクを追加しました。 ・2020/05/24：文章術系にリンクを追加しました。 ・2020/05/14：スライドデザイン系にリンクを追加しました。 ・2020/04/29：スライドデザイン系にリンクを追加しました。 ・2020/04/17：文章術系にリンクを追加しました。 ・2020/04/12：関連するTwit
今日はぼくの企業秘密的な話をします。 ぼくの文章はたまに「わかりやすいです」とか「気づけば最後まで読んじゃいました」などと言ってもらえるのですが、自己分析では、そこまで文章がうまいとは思っていません。 じゃあ何が違うのかというと、「パワーワード」というものを巧みに使えているからなんじゃないかと思っています。タイトルはもちろん、見出しや文章の随所に「パワーワード」を入れることで、読み手を惹きつけることができているのではないか。 パワーワードという言葉はどうやら「意味がわからないけど強い言葉」という意味で使われていたこともあるそうですが、ここでは単に「人を惹きつける力のある言葉」という意味で使います。 パワーワードは「香辛料」パワーワードは香辛料に似ています。 チーズとソースだけのプレーンなピザは、ずっと食べていると飽きてしまいます。でも途中でタバスコをかけると飽きずに食べられますよね？ 素う
文章を書く前にやることよい文章を書くには、実際に文章を書く前に、読者は誰か、どういう悩みを解決するのかを企画することが大切です。また、それを元にアウトラインを書いておきます。 このふたつを元に文章を書くことで、読みやすい開発ドキュメントにつながります。これについては、次の記事をご覧ください。 開発ドキュメントを書く前に決めるべき3つのこと【企画編】開発ドキュメントにおけるアウトラインの書き方開発ドキュメントの書き方企画とアウトラインの作成が終わったら、実際に文章を書いていきます。文章を書くときは、次の9つを意識して書きます。これだけで、読みやすさ、分かりやすさが大きく向上します。 一文を短く切る結論を先に述べる指示語を使わない主語を明確にする、述語との距離を近づけるひらく・閉じるを統一する再現条件を示す前提を揃える見出しや箇条書き、表などを適切に用いる読者に伝わる用語を使うひとつずつ説明し
私はウンザリしています。 「○○対応」は曖昧なのでやめてください。「○○を修正した」の方が直接的です。 こんな指摘を新人が入ってくるたびにコードレビューやドキュメントレビューで繰り返しています。どうも、プログラマー（と言うか理系？）には独特の言語文化があり、みんな同じような分かりにくい表現をしてしまうようです。 「レビューを依頼する前にこれを読んどいて！」と言える記事なり本なりがあれば良かったのですが、良いものが見つけられなかった（ご存知なら教えてください）ので、とりあえずレビューでよく指摘する日本語の文章の問題点や変な表現ポイントを列挙しました。 なお「コメントは必要十分な量を書く」「チケット番号やWikiのURLを書く」といった、良く知られた・日本語に限定されない話題は省略しています。 （※コメント欄などの指摘を受け「補足」を追加） （※タイトル変更。「コードレビュー前に直して欲しい日
技術広報のしゅーぞー(shuzon__)です。 今日は「文章を書くことはプログラミングに似ている」という話をします。 参考書籍はこちら。論理が伝わる世界標準の「書く技術」 @soudai1025からのリクエストで社内ブログを一部編纂し公開しています。 文章を書くことはプログラミングに似ている。 文章を書くことはプログラミングに似ている。 なぜならば、抽象化すると、一連のトピックに対する意味のあつまりを区切り、扱う行為だからだ。 意味ごとに構造化する行為と思えば非常に似ている。 パラグラフ・ライティングは関数に似ている ここでパラグラフ・ライティング を紹介しよう。 パラグラフの構造 パラグラフ・ライティングは関数に似ている。 パラグラフ・ライティングは段落の先頭に「その段落が持つトピックの結論」を書く。 その後、前述の事実を用いた補足とロジックが続きトピックを補足する。 段落の最後に、議論
プログラマーに贈る、わかりやすい文章を書くための技法 - LIVESENSE ENGINEER BLOG
これは Livesense Advent Calendar 2022 DAY 8 の記事です。 転職ドラフトでエンジニアをしている verdy_266 です。 僕の2022年を振り返ると、採用広報チームでの活動を無視することはできません。転職ドラフトの開発を行う傍ら、昨年末に採用広報チームにジョインし、記事の執筆や校正に多くの時間を割いてきました。 今まで記事を投稿したことがなかったこちらのブログにも共作含め5記事を投稿し、11月には Software Design への寄稿の機会をいただくこともできました。文章を書くことが思った以上に好きなんだなと発見があった年でもありました。 made.livesense.co.jp made.livesense.co.jp made.livesense.co.jp made.livesense.co.jp made.livesense.co.jp 弊
オペレーション部 江口です。 先日、社内でビジネスライティングについてオンラインで講義する機会があったので、その資料を公開しておきたいと思います。 いわゆる技術文書というよりは、メールやSlackなど、相手とやり取りを行う際の文章作成を主に考えた資料となっていますので、その点ご承知おきください。 背景 講義を行ったのは、アカウント周りの作業を行うアカウントチームに対してでした。チームの業務内でメールでの顧客とのやり取りやSlackでの社内でのコミュニケーションなど、文章を作成する機会が多く、その際の書き方に課題を感じている方が多いようだったので、少しでも助けになればと思いこの講座を企画しました。 私は別に人に自慢できるほど文章がうまいわけではないですが、約20年のエンジニアのキャリアで顧客とのやり取りや技術文書の作成などをそこそこの数こなしてきました。先輩や上司などからいろいろな指摘を貰い
こんにちは、リファクタリングが大好きなミノ駆動です。 この記事は READYFORアドベントカレンダー2021 、初日の記事です。 なにこれ？ 苦労して執筆した技術記事は、伝えたい人にしっかり伝えたいですよね。 また、最後まで読んでもらいたいですよね。 一方で、構成などに課題があって、伝えたい人になかなか伝わらないことがあります。 この記事は、伝わる記事の書き方について、私の個人的なノウハウを書き記したものです。 これからアドベントカレンダーの記事を執筆される皆さんにとって、少しでもお役に立てられれば幸いです。 この記事のゴール 以下の理解を得ることをゴールとします。 以下2つの要件を踏まえた記事構成を心がけること。 構成要件①：技術を紹介する上で最低限説明の必要な内容を網羅すること。 特に課題をしっかり伝えること。 構成要件②：読み手が段階的に理解しやすい順番になっていること。 告知の仕
これは「文章を書く人に伝えたい50のこと」のセカンドシーズン（実践編）Vol.01です。全連載終了後に消去して有料になります。読むなら無料のうちに。よく、「文系だから」「理系だから」となんでもザクザク分割して考える人がいるけど、まあ、頭悪いなーといつも思う。そういった分類はあくまでも大学入試だとかのシステムの問題であって、実際にはそうはいかない。 そもそも、そういった「理系」「文系」という分類が仮に有効だとしても、それらの世界の奥深いところにいけばいくほど、理系の世界では文系的素養が大切だし、文系の世界でも理系的素養が大切だとすぐに気が付く。入口からちょっと入ったところで気が付いてしまう。 実際にはそういった「文系」「理系」なんて分断はあり得ないことだが、この回の文章では分かりやすくするためにあえてそれらを使って論じてみる。 例えば、文章を書くという行為は、きわめて文系的素養だと思われがち
録画：https://www.youtube.com/watch?v=49CzhFGqvD8 概要： 何かの技術、商品、サービスや機能など、モノや概念を人に説明しなければならない場面は多くあります。 伝えなくてはならないことはいっぱいあるけれど、何からどんな順番で伝えたらいいのかわからず、時間だけが過ぎて焦ってしまう、そんな経験はありませんか？ テクニカルライターが情報をどう整理して構造化しているかをお伝えします。
私は安田峰俊。プロのルポライターをやっている者だ。この年末年始、20代の後輩ライターに原稿の書き方を教える機会があったり、別の場でかなりヤベえ水準の新人の原稿を読まされる機会があったりしたので、思ったのである。ちょっと文章術を世間に伝えてみようと。 第1回記事で書いた通り、私は大学院修了後に就職に失敗してから、1文字1円以下のウェブライター→コンビニ売りの怪しい500円ムックの執筆者→裏モノ・実話誌ライター→ブログ本作者→週刊誌記者→微妙な中国ライター→わりと有名な賞の受賞歴を持つノンフィクション作家（わざと「ルポライター」を名乗っているが）、というクラスチェンジをおこなった。 ゆえに、これまでに詩と長編小説以外ならば、学術論文を含めてたいがいの文章を書いた経験がある。過去14年間の寄稿先は、倒産直前に天然水の販売に手を出していたイケていない編プロが作る無料冊子から、アカデミックな中国通の
出ない神本より出るクソ本 〜『読みやすい技術書を書く技術』の第1章と頒布情報〜 #技術書典 - 憂鬱な世界にネコパンチ！
『読みやすい技術書を書く技術』は、読みやすい文章を書くための「校正環境」を構築する本です。この本では、CircleCIを使って継続的に文章を校正する仕組みを整えます。技術書のような長い文章を書く人には、特に有益です。技術書典7で頒布予定なので、ぜひチェックいただければ幸いです。 techbookfest.org CIで校正チェックすることに興味はあるけど、そこまで手が回らないんだよな〜と思っている人いませんか。この本はあなたのために書きました。この本を読めば誰でも、CircleCIで最高の校正環境が構築できます。 この本を読むことで学べること 『読みやすい技術書を書く技術』では、次のようなことを習得できます。 校正ツール「prh」「RedPen」「textlint」の使い方 「CircleCI」の基礎知識と校正ツールの組み込み方 「reviewdog」による校正チェック結果のGitHubへ
追記: この記事は「人が一生懸命書いた記事を読んでイライラする人間」を擁護するつもりは一切ありません。 追記: この記事は「自分の記事ではイライラさせたくないな」と思う人向けに執筆したのであって、この記事のあることをQiitaにあるすべての記事に矯正したいという思想のもとで執筆したものでは有りません。 はじめに こんにちは Qiitaやnoteといった情報共有に向いたサービスがどんどん普及しており、知識量に関係なく誰でも情報が発信できるいい時代になりましたね。 しかし、投稿されているすべての記事が良いと思えるわけではないのは確かです。タイトルに書いてあるものとは違う内容が書いてあったり、問題解決まで達していない結論で終わってたり。記事中の動かないコードを調べるために、そこから別の記事をはしごをして、それを繰り返していた結果業務時間が終わっていたり。 あまり私も人のことは言えませんが、いろん
こんにちは。Developer Contentチームの矢崎です。LINE株式会社でテクニカルライターとして働いています。LINE社内で大評判のテクニカルライティング講座をブログにまとめてみたシリーズも第3弾になりました。（第1弾、第2弾もぜひ読んでください！） 今回の記事では、以下のようにトピックが多く集まったときに「自分が書いたトピックを（その情報が不要な人に）読ませないためのコツ」を説明します。具体的には、順番に気を配ったり、情報の分類を気をつけたり、タイトルを工夫したり、という話をします。 全部読んでもらおうとしていませんか？ おそらくほとんどの人は、ほかの人の文章を読むときに、必要そうな文だけピックアップして読んだり、タイトルだけで内容を判断したつもりになったりすると思います。検索エンジンで検索したときに、表示された内容だけで、文章の内容を推測して読むか読まないか決めますよね。そう
こんにちは、hachi8833です。はっと気がつくと、私が運営している日本語エラーチェックサイト「enno.jp」を開始してからもう8年が経過していましたので、たまには振り返ってみたいと思います。 サイト: 日本語の文章のタイポ/変換ミス/誤字脱字エラーをチェック/校正 | enno.jp enno.jpより 使い方はあきれるほど単純です。チェックしたい文章をフィールドに貼り付けてボタンを押すだけ。 enno.jpは、自分で作って自分で使い、自分で常にパターンを追加/更新しています。いわゆるドッグフーディングというヤツです。当然この記事もenno.jpでチェック・修正しました。 参考: ドッグフーディングとは:意味/解説 - シマウマ用語集 今年1月に突然enno.jpがバズッて自分でもびっくりしました。広めていただきありがとうございます🙇。 「外出自粛要請」が文章校正に引っかかってワロ
記事を書くときの自分ルール
この記事は アウトプットはいいぞカレンダー 2022 の 15 日の記事です。 はじめに 記事を書くのは結構好きで、Qiita や Zenn にごそごそと書き続けてたら計 100 記事をとっくに超えてました。今知りました。 「はえ〜そんなにあったのか」って気持ちです。 ちなみに 7 年ほど前の初投稿は、「こういうときはこうすると楽だぞ」ってドヤ顔でコード書いたやつで、数行しか書いてないくせにバグってました。 公開後に即コメント通知が来て、恐る恐る見たら何人かバグ指摘をしてくれてました、懐かしい。 「いんたーねっとこわい、けどやさしい」って思った思い出の記事です。 それから時は経ちある程度は書き慣れて、ここ数年はそれなりに一貫した自分ルールみたいなものができてきています。 気にすることが定まっていると書くとき楽なので、ちょっと整理して晒してみたいと思います。 ネタにしつつあわよくば自分ルール
あなたの文章が伝わらない原因は“書きすぎ”。橋口幸生×田中泰延『言葉ダイエット』刊行記念トークイベント | AdverTimes.（アドタイ） by 宣伝会議
田中：橋口さんは昨年末に『言葉ダイエット メール、企画書、就職活動が変わる最強の文章術』を出版されたわけですが、これだけは覚えて帰ってください。この本は読むところしかない。いや、文字で書いてあるんだから当たり前や（会場笑）。間違いないです。今日はそんな橋口さんの非常にタメになるお話をうかがおうと思います。 今回、文章術の本を出すきっかけは何だったのですか？ 橋口：ある1本のメールです。内容を簡潔に言えば、現場がOKを出した企画に社長がNGを出したので再考してくれという内容なのですが、これが非常に長々と、しかも遠回しに書いてあり、わかりづらかった。私は新卒で広告会社に入社したのですが、今までこのメールに限らず数多くの読みにくい文章を見てきました。 田中：あー、この人、悪い人じゃないんですよね。真面目で真剣で礼儀を尽くさなくてはいけない、人を怒らせてはいけないと思っているから長く読みづらい文章
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
テクニカルライティングの基本
Google社のテクニカルライティングの基礎教育資料がとても良かったので紹介したい - Qiita
テクニカルライティングの基本 2023年版
伝わる文章 | 基本要素 | SmartHR Design System
Amazonの従業員が学ぶ伝わる文章構成の極意｜Sangmin Ahn
LINE社内テクニカルライティング講座第2弾！1文では説明が終わらない文章を書くコツ
果てしない文章推敲を「３ステップ」で効率的に終わらせる方法｜石原尚（大阪大学教員）｜note
読みやすいドキュメントを書くために今日からできる7つのこと｜壮｜Masato Tanaka
伝わる文章作成の基本を学ぶための記事・学習コンテンツのまとめ - Qiita
ドキュメント作成スキル向上を目指す人向けおすすめ記事まとめ - Qiita
読んでもらえる文章にするための「パワーワード」の作り方｜竹村俊助／編集者
開発ドキュメントの書き方！9つのコツ【エンジニア】
レビュー前に直して欲しい日本語の問題点８つ - Qiita
文章を書くことはプログラミングに似ている。 - CARTA TECH BLOG
社内で行ったビジネスライティング講座資料を公開します | DevelopersIO
伝えたい人に届ける技術記事の書き方 - Qiita
文章を書くことは数学の証明問題を解くのと同じ｜pato｜note
モノや概念をわかりやすく伝えるテクニック
片手間で教える文章講座1 「ユニバーサル日本語」の書き方｜安田峰俊
読み手をイライラさせない技術記事などを書くために最低限守ったほうがいいこと - Qiita
LINE社内テクニカルライティング講座第3弾！不要な人に社内文書を読ませないコツ
日本語エラーチェックサイトenno.jpを作った理由｜TechRacho by BPS株式会社