Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Sign up for free
Menu
Search
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Pricing
Search
Sign in
Sign up for free
『理科系の作文技術』から学ぶ技術文書の書き方
Search
Sponsored
·
Ship Features Fearlessly
Turn features on and off without deploys. Used by thousands of Ruby developers.
→
abekoh
February 18, 2024
Technology
1.4k
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
『理科系の作文技術』から学ぶ技術文書の書き方
2024/02/06に社内LTで発表したスライドです。
abekoh
February 18, 2024
More Decks by abekoh
See All by abekoh
Table-driven testing に縛られないGoのテストパターン
abekoh
9
4.5k
GAN -Generative Adversarial Networks- (2019-09-26)
abekoh
1
88
WSL2 (2020-10-30)
abekoh
1
88
自作キーボードつくってみた (2019-02-26)
abekoh
1
65
Other Decks in Technology
See All in Technology
[AWS 秋のクラウドオペレーション祭り 2026]AWS DevOps Agentで変わるリリースと運用対応 ~リリース管理機能と Directed actions のご紹介~
furuton
4
1.2k
【Data Engineering Summit2026_登壇資料】医療ビッグデータ×AIエージェントを支えるデータ基盤とハーネスエンジニアリング
jmdc_presentation
0
100
ゲームのリアルタイム通信から見た QUIC と MoQ
segadevtech
0
110
継続的なAIコスト最適化
bgpat
1
280
味覇で作るパスタが美味い - 20261001_yabaubuki.dev
livesense
PRO
0
120
More Freedom on the Same Shared GPU Cluster: A Small Team’s Experience with vCluster
nttcom
0
150
宣言型部分更新は何を解決しどこへ向かうのか
shuta13
0
310
"優秀な誰か"の下位互換にならないために
yut0naga1_fa
1
1.7k
Deep Data Security 機能解説
oracle4engineer
PRO
2
770
生成AIで高い生産性を求められて、 悩み、乗り越えた話
mot_techtalk
2
160
実践!Cloud Run ハンズオン!! / Cloud Run handson
y0hgi
0
200
Jetson Orin Nanoとk3sとローカルLLMで音声文字起こしシステム作ってみた
y_sera15
0
120
Featured
See All Featured
DevOps and Value Stream Thinking: Enabling flow, efficiency and business value
helenjbeal
2
410
Scaling GitHub
holman
464
140k
Reality Check: Gamification 10 Years Later
codingconduct
0
2.3k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
50
10k
AI: The stuff that nobody shows you
jnunemaker
PRO
10
1.1k
Code Reviewing Like a Champion
maltzj
529
40k
Producing Creativity
orderedlist
PRO
348
41k
Bootstrapping a Software Product
garrettdimon
PRO
306
120k
KATA
mclloyd
PRO
35
16k
Impact Scores and Hybrid Strategies: The future of link building
tamaranovitovic
0
450
Everyday Curiosity
cassininazir
0
350
Amusing Abliteration
ianozsvald
1
340
Transcript
『理科系の作⽂技術』から学ぶ 技術⽂書の書き⽅ 2024/02/06 abekoh@MICIN LTゆる会
はじめに • 対象読者に読んでもらい、かつ理解してもらえる技術⽂書の書き⽅のテク ニックを『理科系の作⽂技術』を引⽤しながら紹介する ◦ 技術⽂書: ここではエンジニア向けのブログ記事や社内ドキュメントなど • ⾊々な記事をレビューしたり、ドキュメントを読んでいて、結局伝えたかっ たことが何なのかわからないことがある
• きちんと伝わるブログ記事やドキュメントの書き⽅‧テクニックについて、 『理科系の作⽂技術』と持論をもとに解説し、皆の⽂章⼒向上に役⽴てたい ◦ 持論は💡マークを付けている • 論⽂向けテクニックという側⾯もあるので、あくまで⼀つのスタイルとして 受け取ること ◦ ブログ記事にすべて適⽤すると堅苦しくなってしまうが、 守破離の「守」として念頭に⼊れておくとよい
『理科系の作⽂技術』 • 物理学者の⽊下是雄の著作 • 出版は1981年。現在でも毎年重版されているロングセラー • 学⽣や社会⼈が授業や仕事の上で必要とされる、レポート、報告書、論⽂、 説明書、マニュアルなどの表現技術とプレゼンテーションのコツを、まとめ たもの •
漫画版もある • 次スライド以降、ことわりなくこの書籍を 引⽤する
⽬次 • ⼼得 • ⼀⽂書⼀主題、ターゲットを明確に • 「重点先⾏主義」を忘れない • ⽂章の構成>>>⽂のうまさ •
段落の「⼀⽂⽬」に魂をこめる • 修飾語を刈り落とす • はっきり⾔い切る姿勢 • 図表‧参考⽂献を⼤いに使う • わかりやすく簡潔な表現
⼼得 理科系の仕事の⽂書を書くときの⼼得は 1. 主題について述べるべき事実と意⾒を⼗分に精選し、 2. それらを、事実と意⾒とを峻別しながら、順序よく、明快‧簡潔に記述する ことであると要約できる。 (p.6) • 必要なことは漏れなく書く、必要ないことは⼀つも書かない
• 情報と意⾒の伝達だけを使命とし、感想を混⼊しないこと ◦ 💡ブログ記事の場合感想中⼼でも良いが、事実‧意⾒と混同しないように注意す べき
⼀⽂書⼀主題、ターゲットを明確に • ⼀つの⽂書は⼀つの主題に集中すべきもの ◦ 別の主題が混⼊すると、読者に与える印象が散漫‧説得⼒が低下 • 主題を決めたら次に、⾃分は何を⽬標としているか、何を主張しているかを 熟考‧⼀⽂にしてみるとよい(⽬標規定⽂) ◦ 💡「誰に」「何を」伝えたいか、具体名も含めて作ってみるもあり
◦ 💡⽬標規定⽂をそのまま序論の最初に持ってくるのもあり
「重点先⾏主義」を忘れない • 表題(タイトル)、あるいは書き出しの⽂を読めば最も重要なポイントがわか るようにすべき ◦ 読んでもらえるかどうかはここに懸かっている • 表題は、的確に内容を⽰す具体的なものでなければならない ◦ 💡本⽂書いてるとズレてくることも多いので、最後に考えるもよい
⽂章の構成>>>⽂のうまさ • ⽂章の死命を制するのは、⽂章の構成。以下が⼤切 ◦ 何がどんな順序に書いてあるか ◦ その並べ⽅が論理の流れに乗っているか ◦ 各部分がきちんと連結されているか •
語句のえらび⽅、⼝調のよさといった「⽂のうまさ」は⼆の次三の次 • 全体構成の基本は「序論」→「本論」→「結び」 ◦ 起承転結でなくてよい。特に「転」は不要 • 💡箇条書きで最初に⾒出しだけ洗い出してみるとよい
段落の「⼀⽂⽬」に魂をこめる • 各段落の1⽂⽬に重点を置き、そこだけ読み進めても 理解できる⽂章にすること(トピックセンテンス) ◦ 右図の⻩⾊の箇所だけ読むだけで内容が理解できるよ うにすべし ◦ ⽇本語の場合難しいので意識が必要 ◦
流れを意識すると、やむを得ず2,3⽂⽬にくることも ◦ 💡2,3⽂⽬になったときは思い切って太字にするのもあ り • トピックセンテンス以降でその具体化を⾏う ―――――――――――――――――――― ―――――――。 ―――――――――――――――――――― ―。 ―――――――――――――――――――― ―――――――――――――。 ―――――――――――――――――――― ――――――――――。 ――――――――――――――――。 ―――――――――――――――――――― ―――――――――――――。 ―――――――――――――――――――― ―――――――――――――――――。 ―――――――――――――――――――― ――――――――――。 ―――――――――――。 ―――――――――――――――――――― ――――――――。
修飾語を刈り落とす • ⽇本語は修飾句‧修飾節はかならず前置されるため、 逆茂⽊(さかもぎ)型の⽂章になりがち(右図の(A)) ◦ パラグラフ全体を読まないと理解できない⽂章になってしまう ◦ ⽇本語の性質上避けにくい ◦ 英語論⽂では逆茂⽊型は書くのはNG、(B)のようにすべし
• 逆茂⽊型に対抗する⼼得 ◦ ⼀つの⽂の中には⼆つ以上の前置修飾節は書きこまない ◦ 修飾節の中のことばには修飾節をつけない ◦ ⽂または節は、なるたけ前とのつながりを浮き⽴たせる ようなことばで書きはじめる • 💡とりあえず思うままに書く→後で刈り落とすという 2フェーズで書くもあり https://www.jstage.jst.go.jp/article/butsuri/74/3/74_175/_pdf/-char/en
はっきり⾔い切る姿勢 • いくらか不⾃然に思えても、できるかぎり明確な、断定的な⾔い⽅をしたほ うがいい • 「〜と思われる」「〜と考えられる」→当否の最終的な判断を相⼿にゆだね て⾃分の考えをぼかした⾔い⽅。逃げの余地あり ◦ 「⾃分は〜と思う」「〜と考える」と書くべき •
「ほぼ」「約」「ほど」「ぐらい」「たぶん」「ような」「らしい」をでき るだけ削ること • 💡修飾語と同様、⼀旦書いてあとで刈り取ってみるとよい
図表‧参考⽂献を⼤いに使う • 図や表はいちばん⼤切な役割をしばしば演じる ◦ 本⽂をはじめる前に準備すべし→何を書かなければならないかはっきりする ◦ それしか⾒ない読者もいる。キャプション‧説明をつけるべし ◦ 💡可能な限り前段で全体感が伝わる図表を置くとよい •
引⽤‧参考⽂献は出典を明⽰して効果的に使う ◦ 💡研究室の恩師⽈く「参考⽂献の無い‧少ない論⽂は、⾃分が勉強していないこ とを⽩状しているようなもの」
わかりやすく簡潔な表現 • ⽂は短く、短くと⼼がけて書くべき ◦ 💡⻑くて3⾏。⻑くなりそうなら2つに分ければよい • 不要に漢字を使わない ◦ 字⾯が⽩いほうが読みやすいとされる ◦
「但し」→「ただし」、「等」→「など」、「事」→「こと」… ▪ 💡絶対NGではないが、字⾯が黒いなと思ったときに対応してみるとよい ◦ 💡電⼦情報通信学会 会誌原稿執筆のしおり 付録A 常⽤漢字表‧送り仮名につい て などルールに従ってみるのもよし • 読点(、)の打ち⽅ ◦ ①受けることばが、すぐ続くときはつけない。離れているときはつける ◦ ②2つの⽂からできている⽂は、間につける ◦ ③読点が多すぎてくどいときは③は省いてよい ◦ 💡難しいので読み返して整える https://www.ieice.org/jpn/books/kaishiannai/kaishishiori.pdf
おわりに • 対象読者に読んでもらい、かつ理解してもらえる技術⽂書の書き⽅のテク ニックを『理科系の作⽂技術』を引⽤しながら紹介した • 特に「⽬標規定⽂」「トピックセンテンス」「逆茂⽊型への対抗」だけは覚 えて帰ってほしい • ごく⼀部の紹介なので、ぜひ書籍のほうも読んでほしい •
兎にも⾓にも量をこなさないと上達しないので、どんどん書くべし • ⾃分も改めて全然できていない‧わすれている箇所があったので、磨いてい きたい