Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
『理科系の作文技術』から学ぶ技術文書の書き方
Search
abekoh
February 18, 2024
Technology
0
510
『理科系の作文技術』から学ぶ技術文書の書き方
2024/02/06に社内LTで発表したスライドです。
abekoh
February 18, 2024
Tweet
Share
More Decks by abekoh
See All by abekoh
Table-driven testing に縛られないGoのテストパターン
abekoh
7
2.5k
GAN -Generative Adversarial Networks- (2019-09-26)
abekoh
1
49
WSL2 (2020-10-30)
abekoh
1
53
自作キーボードつくってみた (2019-02-26)
abekoh
1
20
Other Decks in Technology
See All in Technology
dbt-coreで実現するCore DataMartsのデータモデリング〜dbt編〜 / Core DataMarts Modeling with dbt-core
i125
3
1.2k
WINTICKETアプリで実現した高可用性と高速リリースを支えるエコシステム / winticket-eco-system
cyberagentdevelopers
PRO
1
170
チームを主語にしてみる / Making "Team" the Subject
ar_tama
2
180
SwiftSyntaxでUIKitとSwiftUIの使用率を完璧に計測できちゃう件について
ldf_tech
0
160
サーバーサイドのデータプレーンプログラミング 〜 NVIDIA Blue Field / DOCA 〜
ebiken
PRO
1
230
Amazon FSx for NetApp ONTAPを利用するにあたっての要件整理と設計のポイント
non97
1
130
失敗しないOpenJDKの非互換調査
tabatad
0
230
Trusted Types API と Vue.js
lycorptech_jp
PRO
1
300
Data Migration on Rails
ohbarye
7
4.5k
Jamstack でリニューアルするグリーグループのメディア
gree_tech
PRO
2
220
生成AI×マルチテナントSaaSな新規事業を立ち上げる上でテックリードとして気を使った点の紹介
lunastera
0
530
Databricksワークショップ - 生成AIとDWH
taka_aki
2
4.5k
Featured
See All Featured
Reflections from 52 weeks, 52 projects
jeffersonlam
346
20k
Keith and Marios Guide to Fast Websites
keithpitt
408
22k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
159
15k
Templates, Plugins, & Blocks: Oh My! Creating the theme that thinks of everything
marktimemedia
26
2k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
364
22k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
328
21k
How to train your dragon (web standard)
notwaldorf
88
5.6k
Designing the Hi-DPI Web
ddemaree
280
34k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
246
1.3M
Raft: Consensus for Rubyists
vanstee
136
6.6k
Thoughts on Productivity
jonyablonski
67
4.3k
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
27
4.1k
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
おわりに • 対象読者に読んでもらい、かつ理解してもらえる技術⽂書の書き⽅のテク ニックを『理科系の作⽂技術』を引⽤しながら紹介した • 特に「⽬標規定⽂」「トピックセンテンス」「逆茂⽊型への対抗」だけは覚 えて帰ってほしい • ごく⼀部の紹介なので、ぜひ書籍のほうも読んでほしい •
兎にも⾓にも量をこなさないと上達しないので、どんどん書くべし • ⾃分も改めて全然できていない‧わすれている箇所があったので、磨いてい きたい