テクニカルライティングの基本
テクニカルライティングの基本を学べます。サイボウズの新入社員向け研修資料です。業務マニュアル、報告書、仕様書、技術解説書などのドキュメントを書く機会がある方向け。 Twitter：https://twitter.com/naoh_nak 2023年度のアップデート版もあります：https://spe…
テクニカルライティングの基本を学べます。サイボウズの新入社員向け研修資料です。業務マニュアル、報告書、仕様書、技術解説書などのドキュメントを書く機会がある方向け。 Twitter：https://twitter.com/naoh_nak 2023年度のアップデート版もあります：https://spe…
大学や大学院で論文の書き方を鍛え上げた人たちには遠く遠く及ばないが、僕の様なはぐれもの1でも最近は Amazon 社内で文書の質が高いと評価してもらえるまでにはなった。Software Engineer として、コードでのアウトプットはもちろん大事だけど、文書のアウトプット(およびそれによって得られた実際のアウトプット)は同じだけ重要である2。今回は自分が最近どういうところに気をつけて技術文書を書いているのか、ということについて数年後の自分が忘れてないことを確かめられる様にまとめておく。 そもそも文書とは？ 英語だと document。ここで指す(技術)文書とは、人間が読む文体で書かれた技術に関連する情報、といったものだ。具体的に言うと以下の様なものを想定している: 新しいプロジェクトの骨子を説明する資料 会議の叩き台となる 1 枚ペラ 本番環境に変更を加えるにあたっての包括的な情報や具体
社内のプチ発表に使った資料です。 文章のコツ 前置き フルリモートでは、文章でのやり取りがメインになる。 なので、文章がヒドいと「この人と仕事するのキツイ」と思われちゃう😢 そう思われないための色々思ったことを自戒メモ。 なるべく箇条書きにする
文章上達法について、「大量に書け」派と「大量に読め」派の人がいます。 「ひたすら大量に文章を書け。文章上達にはそれしかない」というのは書け派の典型。 「まずはラノベを千冊読め。話はそれからだ」というのは読め派の典型。 しかし、大量に文章を書いているのに文章の下手な人はたくさんいますし、 ラノベをたくさん読んだけど面白いラノベの書けない人もたくさんいます。 これはスキル全般に言えることで、 たとえば、アメリカに二十年住んでいるのに英語がいまいちな人なんて、いくらでもいます。 「量をこなせば自ずと質に転換する」のは、もともと才能のある人間だけです。 私のような凡才は、量をこなすだけでは効率よく上達しません。 質の高い修練を大量にやってはじめて、効率よく上達するのです。 では、質の高い修練とはどういうものでしょうか？ それは、次の２つです。 (1)優れた文章のどこがどう優れているかを、文章を書く
私自身、物事を分かりやすく伝えるスキルを身に着けるため、手あたり次第に、いくつかノウハウ本を読んだり、YouTube動画を観たりしてきました。本記事では、本や動画から得られたノウハウや、私が普段の仕事で発見した個人的に使っているテクニックをまとめてみました。 0 本記事の最重要ポイント 本記事がストックの墓場に行ってもいいように、本記事の最重要ポイントだけ先に伝えておきます。 質問に答える時は、聞かれたことにシンプルに答える。 事実と解釈を分けて話す。 1 本記事で伝えたいメッセージ 1-1 コミュニケーション能力の苦手意識はノウハウで解決する ITエンジニアの裾野が広がるにつれて、SNSでも「コミュニケーション能力の低いITエンジニア」の話題をちらほら見かけるようになりました。いわく「これからはITエンジニアにもコミュニケーション能力が求められる」「プログラミングができるだけでは生き残れ
テクニカルライティングの基本を学べます。業務マニュアル、報告書、仕様書、技術解説書などのドキュメントを書く機会がある方向け。 サイボウズの2023年度 新入社員向け研修の資料です。 Twitter：https://twitter.com/naoh_nak 2022年版（初版）：https://sp…
【翻訳】Googleのエンジニアがソフトウェア開発する時に必ず書くドキュメント「Design Docs at Google」 - BppLOG
Googleでの「Design Docs」とは 2007年の Google Developer Day Tokyo での鵜飼氏のプレゼンによると「Google で必ず書くことになっているドキュメント」であり、「プロジェクト立ち上げ時の 1～2週間をかけて書く」ものです。 今回は Google のソフトウェアエンジニアである @cramforce 氏が自身のブログで「Googleでの Design Docs」について解説している記事を公開されていたため、氏の許可を得て翻訳しています。 原文： www.industrialempathy.com 関連書籍： Googleのソフトウェアエンジニアリング ―持続可能なプログラミングを支える技術、文化、プロセス オライリージャパンAmazon 読了目安：11分 (目次) デザインドキュメント の解剖学 文脈と範囲 目標と非目標 実際のデザイン システ
相手に誠実に、わかりやすい文章を書くための心がけをまとめました。 どういう思考プロセスからどんな表現が生まれるのか、参考として実例を紹介しています。実際に読み比べ、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 今日も何処かでシナリオライター向けセミナーと講義をしているゴリラ。頼む、どうか許してやってくれ。俺はゴリラなんだ DK @game_sennin ここ数日「地道にやるしかない」みたいな話をし過ぎた気がする。 じゃあ「その地道なことってなんだよ」と考えてみたが、私がすすめるなら、人気作や感銘受けた作品のストーリーを簡潔にまとめる事と、ストーリー構成を抽出することかな。 そうしてインプット、自作にアウトプットする地道な繰り返し。 pic.twitter.com/zYmnXFXnA2
伝わりやすいスライド資料の作り方。資料作成の流れからデザインのコツ、デザイン初心者さんにおすすめの本まで紹介｜fuyuna blog｜デザイン・ライフスタイル・キャリアについて書くデザイナーのブログ
センスがなくても大丈夫！デザインのコツを活用すれば、だれでも見やすくわかりやすい資料を作成できます。 イマイチな例といい例のスライド見本もご用意しているので、よければ参考にご自身のスライド資料をブラッシュアップしてみてください。 5. フィードバックをもらう資料のデザインが完成したら、上司や先輩に確認してもらいましょう。プレゼン資料は人に見てもらうことを前提として作るため、客観的な意見は重要です。 目的を果たせる資料になっているか内容がわかりやすいかプレゼンを通してどんな印象を受けるかなど意見をもらい、ブラッシュアップをしていきます。 このとき、PDF形式で書き出したものを確認してもらうと、より資料のクオリティが上がります。デザインの現場でもよくあることですが、PDFや印刷した資料を見ると、スライド作成時には気づけなかった誤字や脱字、表現の違和感などに気づけます。 PDFファイルの作成・共
学校で配布された「どくしょかんそう文のかきかた」というプリントが、「私の学生時代もこんなのが欲しかった」「読書感想文ってこういうこと書けばよかったのか」と話題を呼んでいます。 話題になっているのは小学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
「という」と「こと」を削って文章のもたつきをとる【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 制限文字数内でなんとか書き収めることがポイントなので文字数は厳守してください。 「たくさん書くぶんにはいいだろ」と思わずに、どうしたら収まるか、残す情報と削る情報をどう判断するか、よく吟味して書くことに意味があります。 あまりないかもしれませんが無駄に文字数だけ埋めるのもNG DK @game_sennin この工程を避けようとする自分がいたら気をつけてください。 「要するにどんな話なのか説明できない」「おおまかな結末すら考えられていない」「何が作品の一番の特徴か言えてない」など、かなり根本的な部分の構想が固まりきっていない可能性があります
小山田圭吾問題の最終的解決｜外山恒一
【外山恒一の「note」コンテンツ一覧】 ──名探偵・外山恒一の冒険４ 「名探偵・外山恒一の冒険」シリーズ １．オフィスＶＡＤの秘密（98年） ２．「アナーキー・イン・ザ・UK」の秘密（04年） ３．『ファイト・クラブ』──“映像の乱れ”の謎（16年） １． さて皆さん。 北尾修一氏による勇気ある告発によって、〝コーネリアス〟こと小山田圭吾氏への今回の壮絶なバッシングの火元となったブログ記事が、文章能力の不足といった不可抗力の類ではなく、明白なる悪意に基づいて巧妙に構成されたデマ、要するにいわゆる〝フェイク・ニュース〟の類であることはすでに明らかとなりました。 「勇気ある」というのは、北尾氏はそもそも、小山田氏が自身のイジメ加害体験を赤裸々に告白したインタビュー記事が掲載された『クイック・ジャパン』誌の編集者であり、しかも問題のインタビューの場にも居合わせたというのですから、「身内をかばっ
文章を書く前にやることよい文章を書くには、実際に文章を書く前に、読者は誰か、どういう悩みを解決するのかを企画することが大切です。また、それを元にアウトラインを書いておきます。 このふたつを元に文章を書くことで、読みやすい開発ドキュメントにつながります。これについては、次の記事をご覧ください。 開発ドキュメントを書く前に決めるべき3つのこと【企画編】開発ドキュメントにおけるアウトラインの書き方開発ドキュメントの書き方企画とアウトラインの作成が終わったら、実際に文章を書いていきます。文章を書くときは、次の9つを意識して書きます。これだけで、読みやすさ、分かりやすさが大きく向上します。 一文を短く切る結論を先に述べる指示語を使わない主語を明確にする、述語との距離を近づけるひらく・閉じるを統一する再現条件を示す前提を揃える見出しや箇条書き、表などを適切に用いる読者に伝わる用語を使うひとつずつ説明し
リンク Twitter あなたの漫画を「いい感じ」にするライフハック 漫画を描く上で「これもうちょっといい感じになりそうなんだけどな・・・」って悩んでる方のお役に立てればと思い呟いてる漫画技術です。これから漫画を描こうかなと思ってる方、今漫画作成で悩んでる方、漫画を読むのが好きでもっと漫画の裏テクを知りたい方に読んでいただければと思ってます。 1 user 67
100人以上の資料を読んで見つけた伝わりやすい成果報告書の書き方 - CARTA TECH BLOG
TL;DR 自身の成果をアピールするために、1)Before/After、2)自分の寄与度、3)数字的インパクトを過不足なく伝えることが重要 説明の冒頭では、課題と解法の全体感と成果を述べ、詳細は後に肉付けすると伝わりやすい 課題を伝える際は"誰から見た課題か"を明確にする。課題は解法の前提であるためブレないように はじめに 技術広報のしゅーぞーです。この記事では、過去100人分程度の成果報告書を読み、気付いた "自分の成果をわかりやすく伝える書き方"をまとめています。 仕事をしていると自身の成果を的確に伝える機会は数多くありますよね。 評価期、転職面接、昇格面談など 評価者に自分の成果をどう分かりやすく伝えるか は自分のキャリアを伸ばす上でとても大事なスキルです。 しかし、自分の頑張りや成果を上手く言語化し、相手に正しく理解してもらうのは簡単ではありません。 特に、経験の浅い若手にとって
DK @game_sennin 今日も何処かでシナリオライター向けセミナーと講義をしているゴリラ。頼む、どうか許してやってくれ。俺はゴリラなんだ DK @game_sennin 仮に１日100文字書くのがやっとの「低文章体力」しかない人が、3日書けば300文字。一ヶ月30日書けば3000文字。 ベースとしては速いとは言えないけど、毎日それくらい丁寧に100文字で書いたら、そこそこ質の良い文章が出来上がる筈なのだが「物書き」というのは怠けたがるもので、そこまで勤勉な人は稀 pic.twitter.com/uTd0PqkHmK 2023-10-17 15:54:21
概要 Design Documentと聞くと何を想像しますか？ 一般的にDesign Documentが指すのは設計書であることが多いのではないでしょうか。 設計書、簡単に説明するのであればソフトウェアを「どうやって作るの？」を説明したドキュメントです。 Googleではソフトウェアエンジニアリング文化における重要な要素として、今回お話ししていくDesign Docsと呼ばれるものがあります。 Design Docsとは？ Design Docsとは、開発者がコーディングに着手する前にソフトウェアシステムまたはアプリケーションの開発する人が作成するドキュメントです。 => ソフトウェア設計における仕様書や設計書とは別物と捉えた方がよいです。 仕様書、設計書は作成した上でのDesign Docsの作成となるようです。 このドキュメントには、高レベルの実装戦略と主な設計の決定事項がまとめられて
文脈: blog.arthur1.dev 自分は割とガンガンアウトプットする方で、たまにバズって嬉しいという品質のブログ(これ)をやっている。普段どのような心構えでやっているのか、そして続けるコツみたいなものについて書いてみようと思う(参考になるかは全くわかりません)。 あと一応断っておくと、タイトルにある "去年書いた182本の記事" は非-技術的な記事も含んでいる(けど、だいたい技術記事なので許してほしい)。 どういうときに書くか どういうモチベーションで書くか どういうときにバズるか どのようにして続けるか 余談: 箇条書きの型を統一する 参考文献 あわせて読みたい どういうときに書くか 自分は基本的にブログを「1年前(後)の自分が泣いて喜ぶ記事」というテイで書いている。自分が知りたかったことは他人も知りたかったはずだという仮説で書いていて、それを知りたかった人の総量はその技術のシェ
この記事についてこの記事では、日本のスクラム系カンファレンスのプロポーザルを勝手に沢山読んできた筆者（さとりゅう）が考える「内容が伝わるプロポーザルの書き方」を提案します。筆者がこれまでに読んできた中で、講演内容がどのようなものなのかを伝える目的であるプロポーザルが、その役割を果たすのに不十分な記述のため、本当は素晴らしい講演内容が伝わらずに終わってしまっているのではないか、ということを危惧しています。そこで本記事では、講演内容がわかりやすいと読み手として感じたプロポーザルを思い出しながら、それがどのような構造であったのかをチェックリスト形式で提案します。このチェックリストを用いて、より多くの伝わるプロポーザルが生まれることを願っています。 動機先日、 株式会社カケハシの小田中さんが素敵なスライドを公開していました。これによって、多くの人がカンファレンスのプロポーザルを書こうというモチベー
今回、アドビさんの「みんなの資料作成」という企画に参加させていただくことになりました。せっかくの機会ですので「コピーライター流のプレゼン資料作成のコツ」を書いていきます。 わたしはこれまでコピーライター（セールスライター）として広告やセールスレター、本の表紙などのコピーを書く仕事をしてきました。 直近の実績は以下の通り↓ ・会員数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つです。 ドキュメンテーションを通してプロジェクト内外のコミュニケーションを効率化し、業務プロセスの効率を上げる 社内のドキュメ
この記事の目的 最近「良いドキュメントが作れているな」と思う機会が増えてきたので、その知見をアウトプットしたくなった。 想定読者 今所属してる組織(会社/プロジェクトなど)のドキュメントがイマイチで悩んでいる人 そもそもドキュメントが無い組織に所属していてつらい思いをしている人 「ドキュメントを作れ」という漠然としたタスクを振られて困っている人 想定読者ではない人 メンテなブルなドキュメンテーションのエコシステムが完成している組織で更によいやり方を模索している人 私もまだ模索中なので、いいやり方があれば教えてほしいです👀 顧客提出などの「納品が必要」なドキュメントの管理方法を模索している人 この記事では「社内の情報共有」にスコープを切って話をしています 書いている人のスペック(参考) 歴５年くらいのなんちゃってフルスタックエンジニア 普段は 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
「ドキュメントの書き方」を体系的に学んだことがないエンジニアへ 書籍『エンジニアのためのドキュメントライティング』の概要
講師がオススメする「作家を目指す際に地道にやるべき訓練方法」が納得が深い そこに至るまでの「なぜ地道にするしかないか」も
小学生に読書感想文の書き方教えるテンプレが最高にわかりやすい 学生時代に「欲しかった」と2万“いいね”
読みやすいドキュメントを書くために今日からできる7つのこと｜壮｜Masato Tanaka
自己流の手順書フォーマットを公開してみた | DevelopersIO
文章が3行以上続くパワポ資料は読まれない まず全体像が伝わる、拾い読みできる提案資料の作り方
安全安心にソフトウェア開発を行うためのDesign Doc導入ガイド｜面川泰明
【メモ】良いDesign Docs(Software Design Document)を書くためのリソース集
プロが語る「初稿のプロットや設定資料を作る前にもう一工程あると作品は洗練される」
開発ドキュメントの書き方！9つのコツ【エンジニア】
「『ネーム』『お話作り』に悩む全ての人へ 」ベテラン漫画福地翼先生の漫画ライフハックが為になる
シナリオライター講師DK氏が教える「低文章体力」での文章生成テクニック 榊一郎先生の「文章力は筋トレ」の話も
GoogleのDesign Docsから学ぶソフトウェア設計 - Qiita
去年は182本の記事を書いた人から見た、技術的なアウトプットに疲弊しないようにするコツ - Lambdaカクテル
年100件ほどプロポーザルを読んで作った伝わりやすいプロポーザルのチェックリスト｜さとりゅう
成約率が13.8倍アップした！コピーライターが教える プレゼン資料作成の教科書｜まよまよ@WEBコピーライター
エンジニアのためのドキュメントライティング / Docs for Developers
ヨッピー、脇が甘すぎる(※追記しました @yoppymodel ）
【汎用ソフトスキル】ドキュメンテーションの続け方
日本語ネイティブのユーザーが英語ドキュメントを書く際に指針となるガイドが無料公開中【やじうまWatch】
