テクニカルライティングの基本
テクニカルライティングの基本を学べます。サイボウズの新入社員向け研修資料です。業務マニュアル、報告書、仕様書、技術解説書などのドキュメントを書く機会がある方向け。 Twitter：https://twitter.com/naoh_nak 2023年度のアップデート版もあります：https://speakerdeck.com/naohiro_nakata/technicalwriting2023
テクニカルライティングの基本を学べます。サイボウズの新入社員向け研修資料です。業務マニュアル、報告書、仕様書、技術解説書などのドキュメントを書く機会がある方向け。 Twitter：https://twitter.com/naoh_nak 2023年度のアップデート版もあります：https://speakerdeck.com/naohiro_nakata/technicalwriting2023
大学や大学院で論文の書き方を鍛え上げた人たちには遠く遠く及ばないが、僕の様なはぐれもの1でも最近は Amazon 社内で文書の質が高いと評価してもらえるまでにはなった。Software Engineer として、コードでのアウトプットはもちろん大事だけど、文書のアウトプット(およびそれによって得られた実際のアウトプット)は同じだけ重要である2。今回は自分が最近どういうところに気をつけて技術文書を書いているのか、ということについて数年後の自分が忘れてないことを確かめられる様にまとめておく。 そもそも文書とは？ 英語だと document。ここで指す(技術)文書とは、人間が読む文体で書かれた技術に関連する情報、といったものだ。具体的に言うと以下の様なものを想定している: 新しいプロジェクトの骨子を説明する資料 会議の叩き台となる 1 枚ペラ 本番環境に変更を加えるにあたっての包括的な情報や具体
私自身、物事を分かりやすく伝えるスキルを身に着けるため、手あたり次第に、いくつかノウハウ本を読んだり、YouTube動画を観たりしてきました。本記事では、本や動画から得られたノウハウや、私が普段の仕事で発見した個人的に使っているテクニックをまとめてみました。 0 本記事の最重要ポイント 本記事がストックの墓場に行ってもいいように、本記事の最重要ポイントだけ先に伝えておきます。 質問に答える時は、聞かれたことにシンプルに答える。 事実と解釈を分けて話す。 1 本記事で伝えたいメッセージ 1-1 コミュニケーション能力の苦手意識はノウハウで解決する ITエンジニアの裾野が広がるにつれて、SNSでも「コミュニケーション能力の低いITエンジニア」の話題をちらほら見かけるようになりました。いわく「これからはITエンジニアにもコミュニケーション能力が求められる」「プログラミングができるだけでは生き残れ
テクニカルライティングの基本を学べます。業務マニュアル、報告書、仕様書、技術解説書などのドキュメントを書く機会がある方向け。 サイボウズの2023年度 新入社員向け研修の資料です。 Twitter：https://twitter.com/naoh_nak 2022年版（初版）：https://speakerdeck.com/naohiro_nakata/technicalwriting
【翻訳】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 2023-08-01 19:06:37
伝わりやすいスライド資料の作り方。資料作成の流れからデザインのコツ、デザイン初心者さんにおすすめの本まで紹介｜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 2023-01-10 14:14:18 DK @game_sennin この工程を避けようとする自分がいたら気をつけてください。 「要するにどんな話なのか説明できない」「おおまかな結末すら考えられていない」「何が作品の一番の特徴か言えてない」など、かなり根本的な部分の構想が固まりきっていない可能性があります 2023-01-10 14:14:18
文章を書く前にやることよい文章を書くには、実際に文章を書く前に、読者は誰か、どういう悩みを解決するのかを企画することが大切です。また、それを元にアウトラインを書いておきます。 このふたつを元に文章を書くことで、読みやすい開発ドキュメントにつながります。これについては、次の記事をご覧ください。 開発ドキュメントを書く前に決めるべき3つのこと【企画編】開発ドキュメントにおけるアウトラインの書き方開発ドキュメントの書き方企画とアウトラインの作成が終わったら、実際に文章を書いていきます。文章を書くときは、次の9つを意識して書きます。これだけで、読みやすさ、分かりやすさが大きく向上します。 一文を短く切る結論を先に述べる指示語を使わない主語を明確にする、述語との距離を近づけるひらく・閉じるを統一する再現条件を示す前提を揃える見出しや箇条書き、表などを適切に用いる読者に伝わる用語を使うひとつずつ説明し
リンク Twitter あなたの漫画を「いい感じ」にするライフハック 漫画を描く上で「これもうちょっといい感じになりそうなんだけどな・・・」って悩んでる方のお役に立てればと思い呟いてる漫画技術です。これから漫画を描こうかなと思ってる方、今漫画作成で悩んでる方、漫画を読むのが好きでもっと漫画の裏テクを知りたい方に読んでいただければと思ってます。 1 user 67
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の作成となるようです。 このドキュメントには、高レベルの実装戦略と主な設計の決定事項がまとめられて
100人以上の資料を読んで見つけた伝わりやすい成果報告書の書き方 - CARTA TECH BLOG
TL;DR 自身の成果をアピールするために、1)Before/After、2)自分の寄与度、3)数字的インパクトを過不足なく伝えることが重要 説明の冒頭では、課題と解法の全体感と成果を述べ、詳細は後に肉付けすると伝わりやすい 課題を伝える際は"誰から見た課題か"を明確にする。課題は解法の前提であるためブレないように はじめに 技術広報のしゅーぞーです。この記事では、過去100人分程度の成果報告書を読み、気付いた "自分の成果をわかりやすく伝える書き方"をまとめています。 仕事をしていると自身の成果を的確に伝える機会は数多くありますよね。 評価期、転職面接、昇格面談など 評価者に自分の成果をどう分かりやすく伝えるか は自分のキャリアを伸ばす上でとても大事なスキルです。 しかし、自分の頑張りや成果を上手く言語化し、相手に正しく理解してもらうのは簡単ではありません。 特に、経験の浅い若手にとって
文脈: 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
この記事の目的 最近「良いドキュメントが作れているな」と思う機会が増えてきたので、その知見をアウトプットしたくなった。 想定読者 今所属してる組織(会社/プロジェクトなど)のドキュメントがイマイチで悩んでいる人 そもそもドキュメントが無い組織に所属していてつらい思いをしている人 「ドキュメントを作れ」という漠然としたタスクを振られて困っている人 想定読者ではない人 メンテなブルなドキュメンテーションのエコシステムが完成している組織で更によいやり方を模索している人 私もまだ模索中なので、いいやり方があれば教えてほしいです👀 顧客提出などの「納品が必要」なドキュメントの管理方法を模索している人 この記事では「社内の情報共有」にスコープを切って話をしています 書いている人のスペック(参考) 歴５年くらいのなんちゃってフルスタックエンジニア 普段は 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 Munetoshi Ishikawa, supported by LINE corporation
デザイナーじゃなくても！見やすいスライド資料のための5つのコツ【Before／Afterあり】｜spicagraph
見やすいスライド資料は事前準備と5つのコツさえ押さえればOKクライアントさんに向けてのプレゼンテーションや、社内共有向けの資料、セミナーでの登壇資料などで用いられる「スライド資料」。いざ作ってみると、「なんだか読みにくいな」「色やレイアウトがまとまらない」と感じ、苦手意識を持っている方は多いかもしれません。 でも、デザイナーじゃなくても！デザインツールを使わなくても！いくつかのコツを押さえるだけで見やすいスライド資料は作れます。 この記事では、見やすいスライド資料をデザインするコツを5つの章に分けてご紹介していきます。 「レイアウト」「カラー」など、気になるところから読んでみていただいても大丈夫です。 スライド資料の作成だけでなく、バナーやチラシなど、いろんなデザインにも役立つコツをイラスト付きでわかりやすく説明しているので、今作っているデザインに悩んでいる、デザイン勉強中、という方もぜひ
継続的ドキュメンテーション: Github DiscussionsとADRのすすめ - LIFULL Creators Blog
こんにちは。テクノロジー本部のyoshikawaです。好きなW3C Recommendation は RDF 1.1 Concepts and Abstract Syntax です。 会議やチャットでのやり取りの決定事項・議事録、アプリケーションや機能の設計書・仕様書、READMEなどなど... LIFULLの開発現場においては、ソースコード以外にもこのように様々な文書の管理・蓄積(=ドキュメンテーション)を実施しています。 多くの開発者・メンバーがドキュメンテーションの重要性やその恩恵は理解はしているものの、なかなかうまく情報の蓄積・管理ができない、 その結果、本質的ではない調査に時間を取られてしまいDeveloper Experienceが下落してしまう。 このような課題を抱えているプロジェクトやチームは世の開発現場において少なからず存在すると思います。 LIFULLの開発現場にもこの
ユーザーなのか、ユーザなのか
ユーザーなのか、ユーザなのか ユーザー、ユーザ サーバー、サーバ リカバリー、リカバリ 皆さんはどちら派でしょうか？ 経緯 ー (長音符)の扱いについて、どちらで統一するか？と言うちょっとした議題が上がりました。 個人的に気になったので、ちょっと深堀してみます。 長音符、長音符号、長音記号とは？ wikipediaによると、以下の内容が記載されています。 長音符（ちょうおんぷ）、長音符号（ちょうおんふごう）、長音記号（ちょうおんきごう）または音引き（おんびき）は、「ー」のように書き表される、日本語の記号（約物）のひとつ。棒引き（ぼうびき）ともいう。 まず、前提として「記号」として扱われるらしい。 カタカナ表記においては 長音符は主にカタカナで外来語（例：テーブル）や擬音・擬態語（例：ニャーン、シーッ）の長音を表記する場合に使われる。 とのことらしい。 では、具体的にどのようなパターンで調音
フロントエンド開発にtextlintを導入して運用している話 2021.07.13 Tue. SaaSプロダクトのフロントエンド最前線@オンライン 近藤 大介 @diescake SmartHR プロダクトエンジニア ／年末調整チーム／主にWebフロントエンド（React + TypeScript） 2020年1月SmartHR入社 SmartHR年末調整チームを住処にして、2020年の年末調整の管理画面リニューアルから姿を現す クラフトビールをポチっては冷蔵庫に積む習性を持つ 経緯・モチベーション SmartHRの開発グループは、 フィーチャーチーム構想を掲げ、 クロスファンクショナル化の取り組みを進めています クロスファンクショナル化の一環で 文言（UXライティング）と向き合い始めたdiescakeであったが… 単純な表記揺れ・ルールに起因する不備を一掃したい PRでSuggested
仕様書を浸透させるために何が必要か？ 品質の作り込みをしていきたい・仕様を把握するコストが高いので仕様書を書くことを会社全体で浸透させたいと思っていて、そのために書く・読むの負担軽減が重要だと考えて以下をやることにした。 仕様書の項目を減らす 仕様書フォーマットの統一 仕様書の命名規則を決める 統一されたフォーマットに沿ったテンプレートの作成 管理方法の明示化・単純化 仕様書作成・更新・廃止プロセスの明示化 仕様書の具体例の作成 仕様書を書くときに迷いそうなときに参照するガイドの作成または作成の依頼 実は一回シンプルなフォーマットを決めたのだが、自分の進め方が悪くそれが全く浸透しなかった。その反省を踏まえて上記を考えた。 仕様書の話は、このあたりの話に関係する。 仕様書は必要か？ - パルカワ2 チームが品質を作り込むために必要なこととは - パルカワ2 ちなみに仕様書は、Notionで記
yamalab.com
神奈川工科大学 山崎研究室 創造工学部 ホームエレクトロニクス開発学科 山崎 洋一 yamazaki@he.kanagawa-it.ac.jp 論文紹介入門 Introduction of “Article Reading” ホームエレクトロニクス開発学科 山崎研究室 yamalab.com 1/13 ゼミで身につくスキル 山崎研究室で何ができるようになるのか？ できないことができるようになる やりたいことができるようになる 剛柔相済 ・技術は力、アイデアは技 ・技術力×アイデア ＝つくれるもの 論文の読み方・書き方 ・読者の気持ちを考える ・結論が先 NYの超エリートビジネスマン ・論文のピラミッド ・タイトルの重要性 ・SPIN：説得できるストーリ ・論文の書き方10か条 ・問題設定を明確に ・自分の仕事を中心に ・実験環境・手順を詳細に ・参考文献は引用 ・メッセージを明確にして文を
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カクテル
成約率が13.8倍アップした！コピーライターが教える プレゼン資料作成の教科書｜まよまよ@WEBコピーライター
エンジニアのためのドキュメントライティング / Docs for Developers
【汎用ソフトスキル】ドキュメンテーションの続け方
日本語ネイティブのユーザーが英語ドキュメントを書く際に指針となるガイドが無料公開中【やじうまWatch】
フロントエンド開発にtextlintを導入して運用している話
https://twitter.com/developer_quant/status/1551910433858400256
仕様書を浸透させるために仕様書のあれこれを決めた - パルカワ2
news.ntv.co.jp
mag.japaaan.com
www.sanspo.com
aoyamanagisa.jp
mixi.jp
blog.livedoor.com