教材
読みにくさは、書き手の努力不足ではない
長い文章をチャットに貼って「読んでおいてください」と送ったのに、要点が伝わっていなかった。そんな経験はないでしょうか。多くの場合、原因は文章の中身ではなく、どこが見出しで、どこが箇条書きで、どこが引用なのかが区別されていないことにあります。
Markdownは「構造」を書くための記法
Markdownは、記号をいくつか使って文書に構造を与える書き方です。見出しには #、箇条書きには - を行の先頭に置く。それだけで、読む側にも、機械にも「ここは見出しだ」と伝わります。
ワープロのように文字を大きくしたり色を変えたりするのとは、目的が違います。Markdownが指定しているのは見た目ではなく役割です。だから同じ文章が、GitHubでもSlackでもAIツールでも、それぞれの場所にふさわしい見た目で表示されます。
すでに身のまわりで動いている
GitHubのREADMEやIssue、Slackのメッセージ、Notionやesa、ChatGPTへの指示文。これらはすべてMarkdownか、その方言で書かれています。新しく何かをインストールする必要はありません。 いま使っている道具の上で、今日から効きます。
この講座のゴール
この講座を終えると、次のことができるようになります。
- 議事録や仕様書を、見出しと箇条書きで構造化して書ける
- GitHubのREADMEやプルリクエストの説明を、規約に沿って書ける
- AIに渡す指示文を、条件と出力形式が伝わる形で書ける
覚える記号は10個ほどです。順に見ていきます。
このレクチャーで学ぶこと
- 装飾ではなく「構造」を伝える書き方
- どこで使われているのか
- この講座のゴール
質問
まだ質問は投稿されていません。
質問投稿
ログイン後に質問の投稿ができます。
#1
未完了
Markdownとは ― 記号で構造を伝える
#2
未完了
見出しと段落 ― 文書に骨格を与える
#3
未完了
リストと強調 ― 箇条書きで読み手を助ける
#4
未完了
リンクと画像 ― 情報の置き場所をつなぐ
#5
未完了
コードブロックと引用 ― 記号をそのまま見せる
#6
未完了
表 ― 比較を一目で伝える
#7
未完了
GitHub Flavored Markdown ― 現場で使う拡張記法
#8
未完了
README.md を書く ― 最初に読まれる文書
#9
未完了
Issue と Pull Request を書く ― 伝わる報告の型
#10
未完了