伝わる文章作成の基本を学ぶための記事・学習コンテンツのまとめ - Qiita
短いメッセージを書くことはできても、まとまった文章を書くのに苦労している人は多いのではないでしょうか。 この記事では、まとまった文章を作るときの技術を学ぶことができる記事や学習コンテンツを紹介します。新人エンジニア向けです。 文章の「型」を学ぶ まとまった文章を書くには、「型」が必要です。頻繁に使うものは、「型」を覚えてしまいしましょう。 バグレポートの書き方を学ぶ エンジニアとして書く文章の代表例が、バグレポートです。 バグレポートでありがちな失敗として「何が問題だと思っているのか」が伝わらないというものがあります。 これを防ぐために、「期待する結果」「実際の結果」「再現手順」の3つを必ず書くようにしましょう。 質問の書き方を学ぶ エンジニアが扱う技術は、最初はわからないことだらけです。 それを解決するために、質問の文章を作成する技術が必要となります。 概ね下記の4つの情報があれば、良い
LINE社内テクニカルライティング講座第2弾！1文では説明が終わらない文章を書くコツ
こんにちは、Developer Contentチームの矢崎です。LINE株式会社でテクニカルライターとして働いています。先日、このLINE Engineering Blogで「LINE社内で大評判のテクニカルライティング講座で説明した内容をあらためてブログにまとめてみた」というタイトルで、1文を書くときに気をつけていることや手法について紹介しました。 前回の記事を簡単にまとめると「たくさんの文案を書いて、一番良さそうなものを選択することがとても大切です」という話を多くの例文を使って説明しました。まだ読んでいない方はぜひ読んでみてください。 今回の記事は、第2弾です。次のステップとして「1文では説明が終わらない文章をどのように組み立てていくとわかりやすいか」という話を、以下のような文章を例に説明していきます。 ここでは、このくらいの情報量の文章を「トピック」と呼びます。 第2弾を最後まで読む
LINE社内で大評判のテクニカルライティング講座で説明した内容をあらためてブログにまとめてみた
LINE株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。 LINEヤフー Tech Blog こんにちは、Developer Contentチームの矢崎です。LINE株式会社でテクニカルライターとして働いています。今日は、私が1文を書くときに気をつけていることや手法についてお話しします。 そして、この書き出しは、6月にmochikoさんが書いた「LINEの社内には「テクニカルライティング」の専門チームがあります」という記事のオマージュになっています。mochikoさんが書いた記事ですごいpvをたたき出したそうなので、人のふんどしで相撲を取ってみようという作戦で始めてみました。 この記事ではLINE社内で私が講師を務めた「LINE社内で大評判のテクニカルライティング講座」に沿って、わかりやすい1文を書くコツを紹介していま
Design Docs at Google
One of the key elements of Google's software engineering culture is the use of design docs for defining software designs. These are relatively informal documents that the primary author or authors of a software system or application create before they embark on the coding project. The design doc documents the high level implementation strategy and key design decisions with emphasis on the trade-of
執筆・編集のためのGit（GitHub）ワークフローを考えてみた
まとまった量の文章を執筆・編集するのにバージョン管理システムを使うことは、少なくとも技術文書においては特別なことではなくなりました。 原稿が汎用のテキストファイルの場合には、バージョン管理システムとして、GitやMercurialなどのソフトウェア開発用のツールを使いたいことが多いと思います。 実際、GitHubやGitBucketを利用して技術書やドキュメントの原稿を共同執筆するという話はとてもよく聞きます（知っている世間が狭いだけかもしれないけど）。 とはいえ文章の執筆・編集という作業には、プログラムのソースコードを開発する作業とは違う側面もいっぱいあります。 そのため、ツールとしてはソフトウェア開発用のバージョン管理システムを利用する場合であっても、そのワークフローについては、執筆・編集ならではの工夫が多少は必要なのかなと考えています。 もちろん、同じソフトウェア開発でもプロジェクト
最近はこんな書き方で書いているーフレームド・ノンストップ・ライティング
時間がない人のための要約 １．フォーマットを細分化して、〈ここでは何を書くべきか〉を示すフレームを作っていく ２．フレームごとに、このトピックについて書けることを、順不同／思いつくだけ止まらずに書く（フレーム内で殴り書き） ３．２のなぐり書きを読み返し重要そうなところに下線を引き、下線部を一文にまとめる。 ４．殴り書きできない（足りない）フレームについては、要調査、要発想のタグをつけておいて、まとめて処理する （クリックで拡大） 〈書きべきこと〉と〈書けること〉 文章を書くには、正反対の方法が二つある。 一つは書くべきこと（NTW: need to write）を先に定めるアプローチである。 何を書くべきかを細部に至るまで決めることができれば、究極には、文章を書くことは穴埋め作業に還元される。 そこまでいくのは現実的には無理でも、多くの文章には、どんな順序で何を書けばいいかを示す大まかなフ
PREP法とは? 文章構成力を上げる3つの方法。SDS法・穴埋め文章作成法も | 次々に読まれる文章とは？
次々読まれる文章の「文章構成」の実践編として、今回は具体的な3つの「文章構成のテンプレート」を紹介していきます。 テンプレートは、当てはめるだけで目的に沿った文章の流れができる「文章構成の型」です。構成が決まっていると、安心して「内容（メッセージ）」に集中できますので、あなたの文章クオリティアップにつながります。 テンプレートを具体的に解説する前に、テンプレートを効果的に活用するために必要な前提を共有させてください。 文章を書けなくしている「思い込みの罠」「文章は始めから、順番通りに書かなければならない」という思い込みは、ありませんか？ もし、その思い込みを少しでもお持ちなら、すぐに捨ててください。「書き始め」から順番に書かなければならないと思っていると、手が止まり、文章自体が書けなくなってしまいます。 まず、ここで大前提としてお伝えしたいのは、「文章はどこから書いてもいい」ということです
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
