テクニカルライティングの基本
テクニカルライティングの基本を学べます。サイボウズの新入社員向け研修資料です。業務マニュアル、報告書、仕様書、技術解説書などのドキュメントを書く機会がある方向け。 本資料をもとにした書籍も発売中です：https://amzn.asia/d/2hQNEk2 Twitter：https://twit…
テクニカルライティングの基本を学べます。サイボウズの新入社員向け研修資料です。業務マニュアル、報告書、仕様書、技術解説書などのドキュメントを書く機会がある方向け。 本資料をもとにした書籍も発売中です：https://amzn.asia/d/2hQNEk2 Twitter：https://twit…
大学や大学院で論文の書き方を鍛え上げた人たちには遠く遠く及ばないが、僕の様なはぐれもの1でも最近は Amazon 社内で文書の質が高いと評価してもらえるまでにはなった。Software Engineer として、コードでのアウトプットはもちろん大事だけど、文書のアウトプット(およびそれによって得られた実際のアウトプット)は同じだけ重要である2。今回は自分が最近どういうところに気をつけて技術文書を書いているのか、ということについて数年後の自分が忘れてないことを確かめられる様にまとめておく。 そもそも文書とは？ 英語だと document。ここで指す(技術)文書とは、人間が読む文体で書かれた技術に関連する情報、といったものだ。具体的に言うと以下の様なものを想定している: 新しいプロジェクトの骨子を説明する資料 会議の叩き台となる 1 枚ペラ 本番環境に変更を加えるにあたっての包括的な情報や具体
社内のプチ発表に使った資料です。 文章のコツ 前置き フルリモートでは、文章でのやり取りがメインになる。 なので、文章がヒドいと「この人と仕事するのキツイ」と思われちゃう😢 そう思われないための色々思ったことを自戒メモ。 なるべく箇条書きにする
一番しんどかったと振り返る「コンサル転職して1～2ヶ月ごろに書いたメモ」、どれも命令形で修羅場感があるがコンサルの「スライドづくり」の鉄則が書いてある
総合コンサルに入社したねこ @MOJITOmojo1 コンサル転職して1-2ヶ月頃に書いていたメモ(上司からの指摘一覧)が出てきた。笑 とにかくこのときが1番しんどかったな… pic.x.com/kLtP9h8cpg 2025-07-22 20:37:37
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 0 本記事の最重要ポイント 本記事がストックの墓場に行ってもいいように、本記事の最重要ポイントだけ先に伝えておきます。 質問に答える時は、聞かれたことにシンプルに答える。 事実と解釈を分けて話す。 1 本記事で伝えたいメッセージ 1-1 コミュニケーション能力の苦手意識はノウハウで解決する ITエンジニアの裾野が広がるにつれて、SNSでも「コミュニケーション能力の低いITエンジニア」の話題をちらほら見かけるようになりました。いわく「これからはITエンジニアにもコミュニケーション能力が求められる」「プログラミングができるだけでは生き残れな
テクニカルライティングの基本を学べます。業務マニュアル、報告書、仕様書、技術解説書などのドキュメントを書く機会がある方向け。サイボウズの2023年度 新入社員向け研修の資料です。 本資料をもとにした書籍も発売中です：https://amzn.asia/d/2hQNEk2 Twitter：http…
相手に誠実に、わかりやすい文章を書くための心がけをまとめました。 どういう思考プロセスからどんな表現が生まれるのか、参考として実例を紹介しています。実際に読み比べ、SmartHRの従業員として何かを伝えようとするときの、参考にしてください。 伝わる文章のガイドライン何を伝えるかによって、必要な情報の量や説明の粒度は異なります。 情報が不足していたり、逆に情報が多すぎたりすると、読者が意図を読み取れないことがあります。 読み手となる相手の状況（読む場面、事前知識など）を踏まえ、言葉にする内容や表現を厳選することが大切です。 目的に合わせて情報を取捨選択する読者の目線に立ち、コンテンツの目的に合わせて情報を取捨選択しましょう。 実例1：法律や業務に関わる記事目的業務に関係する「厚生年金保険」について正確に知りたいと思っている人に、わかりやすく内容を伝える。 Before日本の年金制度は、全国民
技術文書の書き方
howto-tech-docs.md 技術文書の書き方 このメモは、私（@ymmt2005）が長年にわたってソフトウェアプロダクト開発に関わってきて 2022年現在こうしたほうが良いと考えているベストプラクティスです。 科学的な分析等に基づくわけではない経験則であるため、今後も随時見直すことがありますし、 ここに書いてあることが常に正しいわけでもあらゆるソフトウェア開発に適するわけでもありません。 しかしながら、実務経験が豊富で、モダンな技術スタックに明るいエンジニアの経験則は一定の 役に立つのではないかと考えて記します。 技術文書とは ここでは、ソフトウェア開発で技術者が書くべき文書ということにします。 ソフトウェアエンジニアにも役割がいろいろあり、アーキテクトと independent contributor では書く文書が違うということはあるでしょうけれど、ここではごっちゃにします。
ドキュメントに固執せよ - gfnweb
どうして人間集団はこんなにも知見の共有を円滑にできないのか？ 改善にはドキュメントにまつわる各個人の心構え・制度設計・技術的解決の全部が必要だという話をしたい． ここでテーマにしているのは，著名OSSなど世の中にいくらでも知見が転がっている対象ではなく，特に企業内の十数人のチームでクローズドに開発しているなどして集合知に頼れない状況下でのドキュメントについてである． 非常に乱暴な言い方をするなら，「コードとか大部分は誰でも書けるようになるものなんよ，そんなところにマッチョイズムとか感じなくてええねん，我々の知的体力や組織性が真に試されるのはドキュメントちゃうんか」という気持ちです — 画力・博士号・油田 (@bd_gfngfn) June 3, 2022 ドキュメントに書く内容の必須項目或るシステム（ソフトウェアなど）について，そのシステムのことを全く知らない人を想定読者としたドキュメント
社内ドキュメントはなぜ更新されないのか？情報の鮮度を最小限の運用負荷で維持する「イミュータブルドキュメントモデル」のススメ - KAKEHASHI Tech Blog
はじめに こんにちは。カケハシの各プロダクトを支えるプラットフォームシステムの開発チームでテックリードを担当しているkosui(@kosui_me)です。 プロダクト開発の世界では、明瞭な社内向けドキュメントを書くための方法が数多く提案されてきました。読者の中には、製品要求を明瞭にするためにPRD (Product Requirements Document、製品要求仕様書) を書き、プロジェクトの背景から全体の設計やその代案について明瞭にするためにDesign Docsを書き、アーキテクチャに関する意思決定の記録を明瞭にするためにADR(Architecture Decision Record) を書いてきた方も数多くいらっしゃると思います。 しかし、どんな素晴らしいドキュメントも、何故か更新されなくなります。新メンバーへのオンボーディングのためにインフラ構成図を検索したあなたが見つけた
インフラエンジニア向けの書籍を取り上げ、著者と出会い、楽しく本を知り、仲間を作る場所である「インフラエンジニアBooks」。ここで、『ユーザーの問題解決とプロダクトの成功を導く エンジニアのためのドキュメントライティング』の翻訳を担当した岩瀬氏が登壇。まずは、本書籍の概要について話します。 本セッションの対象者と、セッションのゴール岩瀬義昌氏：ご紹介いただきました、岩瀬と申します。よろしくお願いします。『ユーザーの問題解決とプロダクトの成功を導く エンジニアのためのドキュメントライティング』は、もともと『Docs for Developers: An Engineer’s Field Guide to Technical Writing』という洋書だったんですが、その翻訳をして、今回この機会をいただいています。 余談ですが、APC（株式会社エーピーコミュニケーションズ）さんが「カプセルトイ
DK @game_sennin とある大学で２０年以上、各種シナリオの研究と教育に携わってきた人。 Twitter(X)にて、独自の創作論を展開したりしなかったり。 皆様のスタイル・スタンスに合わせて、部分的にでも役立てたら幸いです。 DK @game_sennin ここ数日「地道にやるしかない」みたいな話をし過ぎた気がする。 じゃあ「その地道なことってなんだよ」と考えてみたが、私がすすめるなら、人気作や感銘受けた作品のストーリーを簡潔にまとめる事と、ストーリー構成を抽出することかな。 そうしてインプット、自作にアウトプットする地道な繰り返し。 pic.twitter.com/zYmnXFXnA2 2023-08-01 19:06:37
伝わりやすいスライド資料の作り方。資料作成の流れからデザインのコツ、デザイン初心者さんにおすすめの本まで紹介｜Fuyuna Blog
繰り返しますが、センスは必要ありません！ デザインのコツをひとつずつ確認しながら、ご自身の資料をレベルアップさせていきましょう。ちょっとした工夫でグッとよくなるはずです。 1. 位置・大きさ・形などを揃えるまずは要素の位置・大きさ・形などを「揃える」ことを意識します。 文字を揃える最初は文字の揃え方から見ていきましょう。 箇条書きや文章が長いスライドは「左揃え」が読みやすく、情報がきちんと整理されているように見えます。文字の先頭が揃っていると、見た目もキレイです。 また、強調したいメッセージのスライドでは「中央揃え」にするとインパクトが出せます。ただし文字の量が多いと読みにくくなってしまうため、本当に伝えたいことだけを書くようにしましょう。 さらに中央揃えのスライドは「メリハリ」をつけることで、よりインパクトが出ます。 どうでしょう？ほかのスライドと背景色を変えたり、文字のサイズに差をつけ
学校で配布された「どくしょかんそう文のかきかた」というプリントが、「私の学生時代もこんなのが欲しかった」「読書感想文ってこういうこと書けばよかったのか」と話題を呼んでいます。 話題になっているのは小学1・2年生向けに配られているプリント。 話題のプリント 冒頭では「よみたい本をえらぼう」と読書感想文のテーマの選び方を指南しており、「のりものやきかいの本」「ものがたりの本」「ゆうめいな人の本（でんき）」「どうぶつやしぜんの本」と4つのジャンルの魅力を紹介しています。。 続く「どくしょかんそう文のくみたてを考えよう」では、「本をえらんだわけ」「あらすじ」「こころにのこったところ」「じぶんだったらどうするか」と順序だてて感想文を書く方法をアドバイス。具体的な例を出しながらの説明は年齢を問わず、わかりやすい内容となっています。 このプリントを紹介したのはTwitterユーザーの小麦こむぎ子（@co
こんにちは。壮（@sew_sou19）と申します。 メガベンチャー企業でエンジニアとして働いています。 エンジニアにジョブチェンジした当初は、ドキュメントの書き方なんてこれっぽっちも分かりませんでした。読みやすいドキュメントを書くことが本当に苦痛だったのですが、考えて、試行錯誤し続けた結果、以下のような評価を得るに至りました。 リーダーから「君は情報の整理が上手でドキュメントが本当に読みやすい。チーム全体の能力向上に繋げたいからドキュメント書く際のポイント共有してほしい」と言われたので、意識していることを言語化しつつテクニカルライティングの本でインプットしてるけど、学びが多い。ついでにnoteにもまとめてる — 壮 (@sew_sou19) November 28, 2022 そこでこのnoteでは、僕がドキュメントを作成するときに、特に意識して実践している7つのことを書きます。（本当は2
手順書フォーマットは千差万別 みなさんは自己流または、組織やプロジェクトで定められた手順書のフォーマットはありますか? 私は自己流の手順書フォーマットがあります。 自己流の手順書フォーマットがあるといっても、かなり扱いがふわふわしているので、備忘やメモの意味合い強めでまとめていきます。 「もっとこうした方がいいよ!!」などフィードバックがあれば、ぜひお願いします! いきなりまとめ 手順書はExcelやスプレッドシートではなく、Markdownで書く 手順書はgitで管理する 5W1Hを意識して手順書を書く 基本的にはCLIを使った手順書にする 手順書はExcelやスプレッドシートではなく、Markdownで書く 手順書をExcelやスプレッドシートで書くメリット・デメリット 手順書をExcelやスプレッドシートで書いている方も多いと思いますが、私はMarkdownで書いています。 Exce
「ファインマン・テクニック」で「説明がうまい人」になれる理由 - STUDY HACKER（スタディーハッカー）｜社会人の勉強法＆英語学習
「もっとシンプルに伝えられないかな……」 会議の前日、深夜。パソコンの画面に映る資料を前にため息をつく。データは揃っているのに、なぜか説得力が足りない。明日の重要な会議。どうすれば相手に「わかりやすい説明」ができるのだろう？ じつは、そんな「説明ベタ」の悩みを解決する効果的な方法があります。それが「ファインマン・テクニック」。もともとは学習法として知られていますが、じつはプレゼンや会議での発表内容を「短く、わかりやすく、伝わるかたち」に変えるのに最適な方法なのです。 この記事では、ファインマン・テクニックを使って、プレゼンや会議での説明を「シンプルで説得力がある」ものに変える具体的な方法をご紹介します。この手法を使えば、複雑な内容でも、「伝わるプレゼン」が作れるようになるはずです。 ファインマン・テクニックとは ファインマン・テクニックはプレゼンや会議にも使える プレゼンや会議で使えるファ
「という」と「こと」を削って文章のもたつきをとる【WEB文章術】 | センスも文才もなくていい 発信力を上げる「WEB文章術」 | mi-mollet（ミモレ） | 明日の私へ、小さな一歩！（1/2）
ミモレで2021年に公開された記事のうち、特に人気があったものをご紹介します。よろしければぜひご一読ください。 無意識に使ってしまいがちで、“文章のもたつき”を生む言葉に「という」と「こと」があります。「という」と「こと」を減らし、言い換えるコツをご紹介します。 「という」はなくても成立することが多い 話し言葉に近い文体で書くブログやWEB記事は、普段の口グセ・言い回しのクセがそのまま文章に出やすいですよね。前回ご紹介した「のですが」同様、「という」も、無意識にクッション言葉として使いがちです。私自身もインタビューの録音をテープ起こしのために聞くと、「〜なんですが」と「〜という」「〜っていう」を多用していることに気づいて反省します。 「〜のですが」や「という」「ということ」など、話し言葉では語気をやわらげるクッション言葉も、文字として連続するとより目障りでまどろっこしい印象に。私はこれを「
東京・立川を拠点に起業に関連したさまざまなイベントを開催しているStartup Hub Tokyo TAMA。本記事では、『秒で使えるパワポ術』『秒で伝わるパワポ術』の著者で、シリョサク株式会社代表の豊間根青地氏が登壇したイベントの様子をお届けします。今回は、スライドの本質や、スライドを見やすくするポイントについて語られました。 前回の記事はこちら スライドの本質 豊間根青地氏（以下、豊間根）：あと2つですね。「構造を図解にする」という話をしていきます。ここでお話しするのは、要はタイトルとキーメッセージが作れましたと。そのスライドで答えは決まったんだけど、じゃあその根拠・理由をどう作るかというところの考え方をお話しします。 いわゆるスライドの中に載せるコンテンツ、図表の話をしていくわけですが、最初に意識いただきたいのは、みなさんがパワポのスライドをどういうイメージで捉えるかという話です。
5秒のことを200字かけて書く～古賀さんの日記の書き方
デイリーポータルZ読者にはおなじみの古賀テンションだが、日記本で古賀さんを知った人にはこのテンションで良いのか不安になる。 だって本ではこんな感じである。 昼は私も娘も各自好きに食べ、午後リモートでうちあわせをしているうちに娘は作文教室へ行った。 PCのファンの音がとまり、IHコンロのファンの音もとまり、私以外には誰もおらず、すると一気に静かになった。うるさく感じていたわけでもなかった音がやむ、その瞬間の雰囲気が好きだ。 （「ちょっと踊ったりすぐにかけだす」 p.236） 生活のなかの一瞬を描写している。 この日記の書き方を習うために散歩してその様子を書くことにしたい。習うのは林。編集部の橋田さんにも話し相手として散歩に同行してもらった。 まずは散歩の様子をいつものデイリーポータルZ風にざざっと記し、そのようすを古賀・林がどのように日記にするかを検証したい。 まずはいつものデイリーポータル
みなさん、コードを書く前に設計書を書きますか？ 書くか書かないかは人それぞれだと思いますが、「設計」というプロセス自体は意識的であれ無意識的であれエンジニアであれば全員やっていることだと思います。 今回は設計プロセスの改善という文脈で私たちがDesign Docという仕組みを導入したことについて共有しようと思います。もし同じような状況を経験している人がいたら参考になれば幸いです。 導入の背景まずは導入するに至った状況からお話します。 私たちのサービスは、利用していただくユーザーの数が増加しています。それに伴って品質のハードルも上がってきました。サービスに障害が発生するとユーザーさんに大きな損害を出してしまうことになるからです。そこで今まで以上に安全にサービスを開発できる仕組みづくりが必要になりました。ですが、実現のためには大きく2つの課題がありました。 課題1. 開発スピードが徐々に鈍化し
自分が良い Design Docs(Software Design Document)を書くために、読んだ/参考になったリソース集 一覧 Design Docs とは Design Docs at Google デザインドック(Design Doc)について デザインドックで学ぶデザインドック 残業も減らせる!? 上級エンジニアになるための Design Doc 超入門 「Design Doc」って何なのか？ What Is A Design Doc In Software Engineering? (full example) What is a Design Doc: Software Engineering Best Practice #1 https://github.com/kaiinui/note/blob/master/Design--Designdoc.md Googleの
文末が｢よろしくお願いいたします｣ではもったいない…メール達人が多用する"キラーフレーズ3選" 最後の1文が相手にもっとも印象を残す
軽くあしらわれるのを防ぐ「平素は格別のお引き立て」 メールの書き出しの「お世話になっております」という名乗りフレーズは定番中の定番です。これらは最初に必ず入れるようにしましょう。基本的にはこれでほぼ間違いはありませんが、相手との関係性に応じて使い分けられるようになると、一目置かれるメールとなります。 たとえば、初対面や目上の人が相手なら、「お世話になっております」という名乗りに続けて、次のような文面を入れるとよいでしょう。 「突然のメールで失礼いたします。御社のHPを拝見し、はじめてメールを差し上げました」「～様からのご紹介でメールを送らせていただきました」 「日頃から～をご利用いただき、誠にありがとうございます」 相手が役職者などの場合には、「平素は格別のお引き立てをいただき、ありがとうございます」といったように、もう少し堅めの文面でもよいでしょう。こうした文面が書けると、軽くあしらわれ
DK @game_sennin 初稿に取り掛かる前に、プロットや設定資料をつくる人は多いと思うけど、さらにその前の工程を設けてみませんか、という提案。 １００文字制限、２００文字制限は、本当に大事な情報を厳選した上で書こうとすると、意外に苦労するけど、その苦労が作品をより洗練させる、と考えていただければ。 pic.twitter.com/MgC29KmlEo 2023-01-10 14:14:17 DK @game_sennin 制限文字数内でなんとか書き収めることがポイントなので文字数は厳守してください。 「たくさん書くぶんにはいいだろ」と思わずに、どうしたら収まるか、残す情報と削る情報をどう判断するか、よく吟味して書くことに意味があります。 あまりないかもしれませんが無駄に文字数だけ埋めるのもNG 2023-01-10 14:14:18 DK @game_sennin この工程を避けよ
文章を書く前にやることよい文章を書くには、実際に文章を書く前に、読者は誰か、どういう悩みを解決するのかを企画することが大切です。また、それを元にアウトラインを書いておきます。 このふたつを元に文章を書くことで、読みやすい開発ドキュメントにつながります。これについては、次の記事をご覧ください。 開発ドキュメントを書く前に決めるべき3つのこと【企画編】開発ドキュメントにおけるアウトラインの書き方開発ドキュメントの書き方企画とアウトラインの作成が終わったら、実際に文章を書いていきます。文章を書くときは、次の9つを意識して書きます。これだけで、読みやすさ、分かりやすさが大きく向上します。 一文を短く切る結論を先に述べる指示語を使わない主語を明確にする、述語との距離を近づけるひらく・閉じるを統一する再現条件を示す前提を揃える見出しや箇条書き、表などを適切に用いる読者に伝わる用語を使うひとつずつ説明し
リンク Twitter あなたの漫画を「いい感じ」にするライフハック 漫画を描く上で「これもうちょっといい感じになりそうなんだけどな・・・」って悩んでる方のお役に立てればと思い呟いてる漫画技術です。これから漫画を描こうかなと思ってる方、今漫画作成で悩んでる方、漫画を読むのが好きでもっと漫画の裏テクを知りたい方に読んでいただければと思ってます。 1 user 67
100人以上の資料を読んで見つけた伝わりやすい成果報告書の書き方 - CARTA TECH BLOG
TL;DR 自身の成果をアピールするために、1)Before/After、2)自分の寄与度、3)数字的インパクトを過不足なく伝えることが重要 説明の冒頭では、課題と解法の全体感と成果を述べ、詳細は後に肉付けすると伝わりやすい 課題を伝える際は"誰から見た課題か"を明確にする。課題は解法の前提であるためブレないように はじめに 技術広報のしゅーぞーです。この記事では、過去100人分程度の成果報告書を読み、気付いた "自分の成果をわかりやすく伝える書き方"をまとめています。 仕事をしていると自身の成果を的確に伝える機会は数多くありますよね。 評価期、転職面接、昇格面談など 評価者に自分の成果をどう分かりやすく伝えるか は自分のキャリアを伸ばす上でとても大事なスキルです。 しかし、自分の頑張りや成果を上手く言語化し、相手に正しく理解してもらうのは簡単ではありません。 特に、経験の浅い若手にとって
「コードを書くのは好きだけどドキュメントは苦手」 「ドキュメントはつい後回しにしてしまう」 エンジニアの皆さん、そんな覚えはありませんか？ 本書は、日本語ドキュメントのスペシャリストであるテクニカルライターの著者が、エンジニアが「いつ」「何のドキュメントを」「どうやって」書けばよいのかを、イチから解説します。 先生役の著者と生徒役をキャラクターにし、全編にわたってイラストを豊富に掲載。 はじめてドキュメントを書くエンジニア、またはこれまで自己流で書いてきたエンジニアが、一度読めば一生使える知識満載です。 装丁画と挿絵は、カケヒジュンさんが手がけます。 目次 ＜基礎編＞ Chapter１ 良いドキュメントを効率良く書くために Chapter２ ドキュメントの読み方を理解する Chapter３ 読み手とテーマを選定する Chapter４ テーマを分解する Chapter５ ドキュメントの骨組み
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 概要 Design Documentと聞くと何を想像しますか？ 一般的にDesign Documentが指すのは設計書であることが多いのではないでしょうか。 設計書、簡単に説明するのであればソフトウェアを「どうやって作るの？」を説明したドキュメントです。 Googleではソフトウェアエンジニアリング文化における重要な要素として、今回お話ししていくDesign Docsと呼ばれるものがあります。 Design Docsとは？ Design Docsとは、開発者がコーディングに着手する前にソフトウェアシステムまたはアプリケーションの開発する
DK @game_sennin とある大学で２０年以上、各種シナリオの研究と教育に携わってきた人。 Twitter(X)にて、独自の創作論を展開したりしなかったり。 皆様のスタイル・スタンスに合わせて、部分的にでも役立てたら幸いです。 DK @game_sennin 仮に１日100文字書くのがやっとの「低文章体力」しかない人が、3日書けば300文字。一ヶ月30日書けば3000文字。 ベースとしては速いとは言えないけど、毎日それくらい丁寧に100文字で書いたら、そこそこ質の良い文章が出来上がる筈なのだが「物書き」というのは怠けたがるもので、そこまで勤勉な人は稀 pic.twitter.com/uTd0PqkHmK 2023-10-17 15:54:21 DK @game_sennin 別に私は、毎日書かない人を責めたり馬鹿にしたりしたいわけじゃない。 ただ、私も『毎日「キャラ」か「ストーリー
文脈: blog.arthur1.dev 自分は割とガンガンアウトプットする方で、たまにバズって嬉しいという品質のブログ(これ)をやっている。普段どのような心構えでやっているのか、そして続けるコツみたいなものについて書いてみようと思う(参考になるかは全くわかりません)。 あと一応断っておくと、タイトルにある "去年書いた182本の記事" は非-技術的な記事も含んでいる(けど、だいたい技術記事なので許してほしい)。 どういうときに書くか どういうモチベーションで書くか どういうときにバズるか どのようにして続けるか 余談: 箇条書きの型を統一する 参考文献 あわせて読みたい どういうときに書くか 自分は基本的にブログを「1年前(後)の自分が泣いて喜ぶ記事」というテイで書いている。自分が知りたかったことは他人も知りたかったはずだという仮説で書いていて、それを知りたかった人の総量はその技術のシェ
この記事についてこの記事では、日本のスクラム系カンファレンスのプロポーザルを勝手に沢山読んできた筆者（さとりゅう）が考える「内容が伝わるプロポーザルの書き方」を提案します。筆者がこれまでに読んできた中で、講演内容がどのようなものなのかを伝える目的であるプロポーザルが、その役割を果たすのに不十分な記述のため、本当は素晴らしい講演内容が伝わらずに終わってしまっているのではないか、ということを危惧しています。そこで本記事では、講演内容がわかりやすいと読み手として感じたプロポーザルを思い出しながら、それがどのような構造であったのかをチェックリスト形式で提案します。このチェックリストを用いて、より多くの伝わるプロポーザルが生まれることを願っています。 動機先日、 株式会社カケハシの小田中さんが素敵なスライドを公開していました。これによって、多くの人がカンファレンスのプロポーザルを書こうというモチベー
Gamified Interventions for Composting Behavior: A Case Study Using the Gamiflow Framework in a Workplace Setting
今回、アドビさんの「みんなの資料作成」という企画に参加させていただくことになりました。せっかくの機会ですので「コピーライター流のプレゼン資料作成のコツ」を書いていきます。 わたしはこれまでコピーライター（セールスライター）として広告やセールスレター、本の表紙などのコピーを書く仕事をしてきました。 直近の実績は以下の通り↓ ・会員数100万人スキルシェアサービス ストアカ１位 ・ストアカ受講者１万人以上 ・Kindle出版総合１位 ・音声配信Podcast １位 ・アメブロランキング１位（語学部門） ・note「ライターの仕事」定番１位（累計40万PV） また、わたしのプレゼンの成約率は最大69%です（93人の参加者のうち65人が商品購入）通常、成約率の平均が5%と言われている業界ですので、単純計算で13.8倍です。 まだ道半ばで、特に才能もなく凡人のわたしが、誰の影響力も借りずに、このよう
2023年3月17日に開催されたイベント「エンジニアのためのドキュメントライティング - Forkwell Library #19」の登壇資料です。 イベントURL：https://forkwell.connpass.com/event/276576
ドキュメンテーションを文化にする〜コミュニケーションの「ハブ」作りに取り組んだ4年間～ - MonotaRO Tech Blog
はじめに こんにちは。プラットフォームエンジニアリング部門の池田（@progrhyme）です。 この記事では、モノタロウのテック系の部門で筆者が取り組んできた「ドキュメンテーションプロジェクト」について、下の目次の流れに沿って紹介していきます。 【目次】 はじめに 「ドキュメンテーションプロジェクト」とは プロジェクト発足の背景 ねらい（まとめ） 何をやったか ドキュメンテーションの促進 Confluence → Googleドキュメントへの移行 その結果どうだったか 上手く行ったこと 上手く行かなかったこと まとめ 「ドキュメンテーションプロジェクト」とは 初めに、プロジェクトの概要について簡単に説明します。 このプロジェクトのミッション（＝目標）は主に以下の2つです。 ドキュメンテーションを通してプロジェクト内外のコミュニケーションを効率化し、業務プロセスの効率を上げる 社内のドキュメ
これはなに こんにちは、LT開発部のもりたです。 今回はもりたが最近はじめたZettelkastenのご紹介をします。これは知識管理の手法で、アウトプットの敷居がめっちゃ下がるやつなんですが、ま〜〜よくわからん単語すぎて困ると思うので、今日はサクッと本編に入りますね。 Zettelkastenとは？ Zettelkasten（ツェッテルカステン）は、学びを小さなメモにして保管する方法論です。やっていることはそれだけで、ただただ学んだことを小さくメモにまとめて貯めていきます。その際に大切な点があり、それは「自分の言葉で書く」ことと、「情報をなるべく小さく保つ」ことです。 Zettelkastenっていろんな説明のされ方があるんですが、この「範囲は小さく、品質は高く」思考を言語化できるというのが最初の大きなメリットです[1]。 今回はZettelkastenなんて１ミリも知らんぜというみなさん
この記事の目的 最近「良いドキュメントが作れているな」と思う機会が増えてきたので、その知見をアウトプットしたくなった。 想定読者 今所属してる組織(会社/プロジェクトなど)のドキュメントがイマイチで悩んでいる人 そもそもドキュメントが無い組織に所属していてつらい思いをしている人 「ドキュメントを作れ」という漠然としたタスクを振られて困っている人 想定読者ではない人 メンテなブルなドキュメンテーションのエコシステムが完成している組織で更によいやり方を模索している人 私もまだ模索中なので、いいやり方があれば教えてほしいです👀 顧客提出などの「納品が必要」なドキュメントの管理方法を模索している人 この記事では「社内の情報共有」にスコープを切って話をしています 書いている人のスペック(参考) 歴５年くらいのなんちゃってフルスタックエンジニア 普段は Node.js / React.js or R
Design Doc の書き方 / How to Write a Design Doc (Ja ver.)
「Design doc とは何か」・「何を書けばよいのか」を説明するスライドです。 関連するプレゼンテーション「読みやすいコードの書き方」: https://gist.github.com/munetoshi/65a1b563fb2c271f328c121a4ac63571 © 2023 M…
デザイナーじゃなくても！見やすいスライド資料のための5つのコツ【Before／Afterあり】｜spicagraph
見やすいスライド資料は事前準備と5つのコツさえ押さえればOKクライアントさんに向けてのプレゼンテーションや、社内共有向けの資料、セミナーでの登壇資料などで用いられる「スライド資料」。いざ作ってみると、「なんだか読みにくいな」「色やレイアウトがまとまらない」と感じ、苦手意識を持っている方は多いかもしれません。 でも、デザイナーじゃなくても！デザインツールを使わなくても！いくつかのコツを押さえるだけで見やすいスライド資料は作れます。 この記事では、見やすいスライド資料をデザインするコツを5つの章に分けてご紹介していきます。 「レイアウト」「カラー」など、気になるところから読んでみていただいても大丈夫です。 スライド資料の作成だけでなく、バナーやチラシなど、いろんなデザインにも役立つコツをイラスト付きでわかりやすく説明しているので、今作っているデザインに悩んでいる、デザイン勉強中、という方もぜひ
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
質の高い技術文書を書く方法 - As a Futurist...
フルリモートで相手に気持ちよく仕事をしてもらうためのコツあれこれ
「何を言っているのか分からない」と言われないための「伝え方」のノウハウ - Qiita
テクニカルライティングの基本 2023年版
伝わる文章 | 基本要素 | SmartHR Design System
「ドキュメントの書き方」を体系的に学んだことがないエンジニアへ 書籍『エンジニアのためのドキュメントライティング』の概要 | ログミーBusiness
講師がオススメする「作家を目指す際に地道にやるべき訓練方法」が納得が深い そこに至るまでの「なぜ地道にするしかないか」も
小学生に読書感想文の書き方教えるテンプレが最高にわかりやすい 学生時代に「欲しかった」と2万“いいね”
読みやすいドキュメントを書くために今日からできる7つのこと｜壮｜Masato Tanaka
自己流の手順書フォーマットを公開してみた | DevelopersIO
文章が3行以上続くパワポ資料は読まれない まず全体像が伝わる、拾い読みできる提案資料の作り方 | ログミーBusiness
安全安心にソフトウェア開発を行うためのDesign Doc導入ガイド｜面川泰明
【メモ】良いDesign Docs(Software Design Document)を書くためのリソース集
プロが語る「初稿のプロットや設定資料を作る前にもう一工程あると作品は洗練される」
開発ドキュメントの書き方！9つのコツ【エンジニア】
「『ネーム』『お話作り』に悩む全ての人へ 」ベテラン漫画福地翼先生の漫画ライフハックが為になる
エンジニアが一生困らないドキュメント作成の基本（仲田 尚央） | 書籍 | ソシム
GoogleのDesign Docsから学ぶソフトウェア設計 - Qiita
シナリオライター講師DK氏が教える「低文章体力」での文章生成テクニック 榊一郎先生の「文章力は筋トレ」の話も
去年は182本の記事を書いた人から見た、技術的なアウトプットに疲弊しないようにするコツ - Lambdaカクテル
年100件ほどプロポーザルを読んで作った伝わりやすいプロポーザルのチェックリスト｜さとりゅう
技術文章を書くための執筆技術と実践法（パラグラフライティング）
成約率が13.8倍アップした！コピーライターが教える プレゼン資料作成の教科書｜まよまよ@AIライター
エンジニアのためのドキュメントライティング / Docs for Developers
言語化ニガテ民にはZettelkastenがおすすめ
【汎用ソフトスキル】ドキュメンテーションの続け方
sportsbull.jp
xn--n8j4cyieo3iva0gqa2f7p8cl9ic.tokyo
xn--n8jwa6d0qjamo67bd6602i.tokyo
xn--tckdgi5kmezbycd7gy187b856g.tokyo
sulasula.net
xn--eckway7asqn7j1fvbd8702g2r9afh2aci4icoza.tokyo