ドキュメントを書くときの工夫として「箇条書き」があります。
整理されている感じがあり、書き手・読み手のどちらにもメリットがありそうです。
しかし箇条書きを乱用すると、うまく情報が伝わないケースも出てきます。
もし「箇条書きにはしてるんだけど、"わかりづらい"と言われたことがある」という方がいれば、ぜひ読んでみてください。
「プロセス」としての箇条書きは「成果」ではない
書き手にとって、箇条書きは普通に文章を書くよりもスラスラ書けるはずです。
これは箇条書きが「思いついたことをどんどん書けるフォーマット」であり、言い換えれば「明確な論理構造を持たなくてよいフォーマット」だからです。
ゆえに、
- Qiitaで箇条書きに関する記事を書くぞ
- どんな内容にしようか?
- まず箇条書きのデメリットを挙げてみるか
- 思いついたことは書けるけど論理はないかも
- 「論理構造」ってどう説明すればいいんだろう。ちゃんと調べたりする?
- まあ省いてもいいか!
- 「論理構造」ってどう説明すればいいんだろう。ちゃんと調べたりする?
- 思いついたことは書けるけど論理はないかも
- まず箇条書きのデメリットを挙げてみるか
- どんな内容にしようか?
と、無限につなげることが可能です。「関連性」を表現するにはとても良いフォーマットです。
しかしこの関連の集積は「成果」とは呼べません。これはあくまで「プロセス」だと考えるのが良い、というのが持論です。
逆に言えば、プロセスとしての箇条書きはとても効果的です。いきなり本文を書く前にまず書きたいことをなんとなく出してみる。というステップを挟む人は多いはずです。1
人は「箇条書き」では論理を理解できない
ChatGPT向けに指示をするのであれば、箇条書きでもよいかもしれません。
しかし他人になにかしらの情報共有や提案、相談をする場合、箇条書きでは伝わらないケースがあります。
それは箇条書きが個別の情報を提示しているだけで、読み手がそれらの情報を「ひとつなぎ」にして理解できないときに起こります。
言い換えれば「人は順を追って、(ある程度)論理的に説明されないと理解しづらい」と表現できるでしょうか。
情報を伝えるためには「ひとつなぎの文章」を書く
つまり(箇条書きを書いたうえで)最終的には「ひとつなぎの文章」に整形するのがよい、というのが本記事の主張です。
ためしに箇条書きされた内容をまとまった文章として表現してみようとすると、結構つまづくことがわかります。
たとえば「この情報は要る?」とか「先にこっちの話をしておいたほうがいいな」とか「これは重要だから、最後に繰り返そう」とか、そういったことを考えるはずです。この工夫が情報をつなぎます。
アラカルトをまとめて相手にぶつけるのではなくコース料理を出すような気持ちで、どの順番で情報を咀嚼してもらうか。読み終わったあとにどのような理解をしてほしいか。
この編集作業はとても大変ですが、読み手側にとっては格段に理解しやすい情報になるはずです。
「ひとつなぎの文章」には接続詞が出てくる
上述の編集作業をしていると、次のような「接続詞」がかならず出てきます。
- 〜を行った。しかし...というエラーが見つかり、その調査を続けている
- A,Bのタスクが完了した。よって、Cのタスクを開始できる状態になった
こういう文章が書けていれば、かなり良い感じです。箇条書きでは暗黙的にしか示されていなかった論理的な構造が見えるからです。
箇条書きを使うべき箇所
ここまで、箇条書きを回避する主張を行ってきましたが、最後に使うべき箇所も明示しようと思います。
もっとも良いのは、リストアップのような「同じテーマのもの」を並べる場合でしょう。
買い物リストなどはその典型です。あるタスクを完了するまでのステップや、ある機能でできることの一覧なども該当するはずです。
さいごに
全部読んでいただいたうえで、この記事の主張を言い直してみると、
「同じテーマでないものが箇条書きされている場合、それはプロセスつまりメモだから、誰かに読んでほしいなら文章に編集しなおすとよい」
ということになります。
箇条書きだろうかそうでなかろうが「文章」であることには変わりありません。そのため箇条書きをした時点で満足して、あとは読み手に任せる。まあ一般的なことだとも思います。
しかしもし読み手にきちんと情報を与えたかったり説得したかったりする場合は、一度「ひとつなぎの文章」をつくってみることをオススメします。
参照
-
この記事もそうです。 ↩