Luminous Tale.

「今を幸せに生きる」ために。過去よりも未来よりも、目の前の「いま」にいつもまっしぐらに生きる人。旧「月光の狭間」。

*

Workflowyで記事構成を決めてから書くようにしたらさらに文章量が増えた話

   

この記事の所要時間: 121

どうも、先日書いた花組公演感想記事のPV数に驚いている怜香@Ray_mnzkです。

いやもう、こんなに読んでいただけるなんて、本当に有難い限りです。皆さん本当にありがとうございます!

早いもので花組梅芸公演は千秋楽を迎えましたが……今回からはまた通常営業に戻ります。少し前からちょこちょこと記事にしてきた、Workflowyを活用してブログを書くというお話。以下の記事の続きにあたるものになります。

「Workflowy」と「するぷろX」で記事を書こう!ブックマークレットによるシームレスな連携で記事執筆が捗る! | 月光の狭間

今回はどちらかというと、Workflowyそのものについてというよりは、ブログ執筆自体に主眼を置いた感じです。

感想記事を除き、ここ最近は上記記事で紹介したブックマークレットを活用して記事を書いています。その中での思わぬ発見が、今回のテーマです。

WorkFlowy
カテゴリ: 仕事効率化, ユーティリティ

Sponsored Link

どの記事もだらだらと長ったらしい文章を書いているように思えた

全てはこのもやもやとした思いから始まりました。私の書く記事は、いつだってやけに「長い」のです。短くしようと心では思っているのですけど、どう書いても絶対に長いのです。

見積読了時間が常に5分超え

私はしばらく前から、ブログ記事の冒頭に「この記事の所要時間」として読了までの見積時間を表示させています(表示させるために使っているプラグインはこちら→記事を読む所要時間を表示させるWordPress用プラグイン「estimated」)。

いつも書き上げてからライブプレビュー時にこの見積時間を確認するのですが、実を言うとこれが5分を切った記事は数えるほどしかありません。しかもそのほとんどは、お知らせ系の記事です。

では大半の記事はどうなのかというと、読了までの見積時間はだいたい8分程度です。私自身の感覚としては、これが「普通」です。しかし、恐らく一般的な感覚としては「長い」のではないかなと思います。

あまり記事構成を意識して書いたことがなかった

思えば私はこれまで、事前に記事構成を決めてから記事を書くということをしてきませんでした。

基本的に構成は頭の中でざっくり決めるだけ。あとはするぷろXの白紙状態のエディタに、頭にどんどん思い浮かんでくるものをただひたすら書き綴っていたのです。

そのせいか、どうも単にだらだらと長いだけという印象になっているなと自分でも思っていました。いつの間にか話が脱線していて、途中で無理やり話を戻していたりとか……。

一応完成後に読み返しはするものの、あまり直さないことが多かったです。記事を上げてからざっと目を通して、なんか話が合ってないなぁと思うこともしばしば。これではいけないと思いつつも、つい最近まで対策は取ってこなかったのです。

記事構成をしっかり決めれば文章は自然と短く簡潔になると思っていた

そんなわけで、私の記事がやたら長いのは「事前に記事構成をきちんと決めておかないから」ではないかと考えるようになりました。

裏を返せば、「記事構成を決めておけば記事は簡潔になるはず」ということです。

構成を考えていないからだらだらした文章になるのでは?

記事においてどのように話を運んでいくか。頭の中にはある程度の道筋があったとしても、それを元に実際に書き綴ってみると、たいていの場合その通りには話が進まないものです。

私の場合、ひとつ文章を書くごとに次の文章が頭に浮かび、それをそのまま書き綴っていきます。心の赴くまま書いている節があるため、よく話が脱線してしまうのです。

こうなると、途中で気づいて話を予定通りの道筋に戻したとしても、余計な話題が挟まることになるため、話のオチが見えづらくなります。また、当然ながら記事が必要以上に長くなります。「結局この記事は長いばかりで何が言いたいのかよく分からない」という残念な結果になってしまいかねません。

それどころか、下手をすると自分でも何の話をしていたか分からなくなり、元の道筋に戻すことすら困難になる可能性もあるのです。

構成をあらかじめ決めておけば、すっきりとまとまった文章になるはず

そこで、上述したような「長いだけで何が言いたいのかよく分からない」記事になってしまわないために、「事前に記事の構成を決めておく」ようにします。要は、頭の中にある「記事の道筋」を取り出して、目に見える形で用意しておこうというわけです。

あらかじめ記事構成を用意しておけば、どういう話をどういう順で続ければよいか明確になります。話のオチもはっきりしていますから、最後まで脱線せずに記事を書き上げることが可能になるはずです。

また、もし話が逸れたとしても、次に来る見出しと話が合わなくなるため、脱線に気づきやすくなります。それはつまり「余計な話題を書かずに済む」ことでもあります。

あらかじめ記事構成を練ってから記事を書けば、話の脱線が防げるから、記事自体も無用に長ったらしいものにならずに済む。そう考えたのです。

実際にWorkflowyで記事構成を決めてから記事執筆してみた結果

そんなわけで、ここ最近はWorkFlowyで構成を練ってから、それをするぷろXに移して記事を書いています。

普通ならWorkflowyで作ったアウトラインをするぷろXに移すのは難しいのですが、マロ。さんが作ってくださったブックマークレットのおかげでそれが可能になっています。本当にありがとうございます!

WorkFlowyからhタグをつけて「SLPRO X」や「するぷろ」へ送るbookmarklet|マロ。|note

今までよりもさらに文章量が増えた

早速、先ほど立てた「記事構成を事前に決めておけば記事は短く簡潔になる」という仮説を実証すべく、実際にWorkflowyで構成を練ってするぷろXに移す形でいくつか記事を書いてみました。

……結果、まさかの事態が発生しました……。

なんと、今までよりもさらに記事が長くなってしまったのです。

今までは8分前後が見積もり読了時間の目安だったのですが、それが軒並み10分超えになっていたのです。これまでは、観劇感想記事以外で見積もり読了時間が10分を超える記事はほとんどありませんでした。

これは正直、完全に予想外です。

記事の枠組みを決めておいたら、余計なことは書かなくなると思っていたのに……どうしてこうなってしまったのでしょう。

小見出しで区切られたスペースについつい書き込みたくなる

この方式で記事を書いていて気付いたのは、「小見出しと小見出しの間のスペースについついたくさん書きたくなってしまう」ということです。「ここは好きなだけ書き込んでいい欄」という感じに思えてくるのです。

この感覚は、書くべき内容の枠組みが既に決められているが故の安心感から来るのかもしれません。

というのも、見出しという形で取り込んだアウトライン(つまり記事の構成)がエディタ上に敷かれているので、それぞれの小見出しの下にたくさん書き込んでも、話が脱線せずに済むからです。もし万一途中で脱線したとしても、次の見出しがあるので、それに合わせて意識的に軌道修正することが可能です。

私はWorkflowyで構成を練る時、するぷろX上で小見出しとなる階層よりも下の階層にある項目は、すべて「本文に盛り込む内容」という認識をしています。したがって、するぷろXに移した後は、小見出しの中に用意された項目を全て盛り込もうとするんですよね。

もちろん箇条書き状態のままでは不自然な文章になってしまいますから、前後の文脈を整えるつもりで加筆することになります。また、話の流れによっては、既存の項目を消して別の内容を盛り込むこともあります。

結局、予定していた分量の数倍は書き込んでしまう

そんなわけで、実際にはするぷろXに移した後、それぞれの小見出しごとに相当な文章量を加筆していたことがわかりました。そりゃ文章量減らないはずです。

どうやら私は白紙(文章を書き込むべき空白)を見るととりあえず書き込んで空白を埋めたくなってしまう性格みたいです。というのも、事前にWorkflowy上で書くべき内容を出し切ったはずなのに、するぷろXに移してくるとまた書きたいことが出てくるからです。

私の場合、まとまった量の文章を書く場合、次の文章が思いつかなくなるまでひたすら書き続けてしまう癖があるのですが……どうやらそれは事前に構成を決めていようがいなかろうが関係ないようでした。

結局のところ、一度文章を書き始めたら、「ここまで書かないと気が済まない」というところまで一気に書き上げてしまうんですよね。

結局意識的に「削る」努力をするしかないのか?

さて、ここまでの過程で、「事前に記事構成を決めていたとしても、記事は短く簡潔にはならない」ことがわかりました。

それでは、記事の文章量を減らすには、文章を意識的に「削る」必要があるということなのでしょうか。

WorkflowyからするぷろXに渡すブックマークレットを使えば「削り」はしやすい

マロ。さんが作ってくださった「WorkFlowyからhタグをつけて「SLPRO X」や「するぷろ」へ送るbookmarklet」は、ブックマークレットを使用した時点で「画面上に表示されているトピック」だけをするぷろXに送るようになっています。

ということは、Workflowyで記事構成を練った後、それを読み返して「不要」だと感じた部分は折り畳んでしまうようにすれば、その折り畳んだ行はするぷろXには出力されなくなります。

最初に記事構成を練った段階である程度「削る」作業をしておけば、最終的な文章量を減らすことに一役買いそうに思えます。

Workflowy側で削ったところで、するぷろXに渡してから加筆したら結局同じこと

しかしながら、それだけでは文章量を減らせるとは限りません。

というのも、いくらWorkflowyの段階で書くことを削っても、するぷろXに渡した後に加筆してしまったら結局文章量は減らないからです。私の場合、するぷろXで書くとついついたくさん書き込んでしまうので、むしろ文章量が増えてしまう可能性が高いです。

これを避けるには、Workflowy側で全ての本文を書きあげるのが理想となりそうです。しかしそのためには、アウトライン形式で通常文体の文章を書くことに慣れる必要があります。

それに、たとえ全てWorkflowyで書き上げてからするぷろXに渡したとしても、その後の校正で加筆してしまったら結局文章量増加に繋がってしまいます。

テクニックでどうにかすることはできないのかもしれない

いろいろと文章量を抑える方法を考えてみたものの、決定打となる方法は見出せませんでした。

もしかしたら、文章量の多い少ないは、文章を書くにあたっての癖のようなものなのかもしれません。どう工夫しても文章量が少ないままで困っているという人もいるかもしれませんしね。

そうなってくると、改善のためには意識改革が必要になるかもしれません。非常に難しそうではありますがね……。

ブログ記事は長い方がいいのか、短い方がいいのか

ここまで記事の文章量が多すぎるという話をしてきましたが……実際のところ、ブログ記事は長いほうがいいのでしょうか、短いほうがいいのでしょうか。

短い方が読みやすいが、長い方がSEO的には評価されやすいらしい

やはり、短いほうが読みやすいのは間違いないようです。諸説ありますが、だいたい多くても2000字〜2600字が望ましいようです。以下の記事では2600字以内が望ましいと紹介されています。

ブログは何文字で書けばいいのか? – デマこい!

しかしながら、SEO(検索エンジン最適化)の観点から考えると、文字数は多いほうが望ましいようです。記事が長いほど情報量が多くなる傾向にあることが理由のようです。以下の記事に、そのことについての解説があります。

ブログは記事数ではなく「文字数」で決まる

こうなってくると、読みやすさを取るか、検索で上位表示されて読者が集まることを取るか、どちらを重視するかで悩むことになります。

でも、本音を言えば、どちらも取りたいところなんですよね……。

たとえ記事が長くても、読みやすさを保つ工夫をしていきたい

正直なところ、「長文書き」にとって文章量を減らす作業はかなり難しいものがあります。だから、出来ることなら、記事が長くても読みやすいように工夫をしたいところです。

その典型的な手段が、「目次をつける」ことです。分かりやすい見出しをつけて目次をつけることで、記事の中の一部の情報だけを求めている人にもすぐにお目当ての内容にたどり着いてもらえるようになります。

さらに、出来れば中見出しの最後に「目次に戻る」ボタンをつけたいところだったりもします。掻い摘みという形でも読んでもらえるようになりますから。これについては、今どうすれば実装できるか調べているところです。

そしてもうひとつ、長い記事を読みやすくする方法として考えられるのが、記事をページ分割させるという方法です。これなら1ページあたりの文字数は少なく収めることができ、読みやすくなります。

ただ、この方法だと、RSSを講読してもらった場合に、リーダー上では1ページ目しか読めなくなってしまいます。さらに、記事全体の目次を用意するか、ページごとの目次を用意するか、という点でも問題が残ります。

この「記事が長くても読みやすくするにはどうすればいいか」という問題を解決するには、かなり時間がかかりそうです……。

今日のあとがき

というわけで、すっかり長くなってしまいましたが……ブログ記事の長さにまつわるお話をお送りしました。自分でも思った以上にがっつり書いたなぁという感じです。

結局のところ、記事の長さに関してはまだまだ研究・試行錯誤すべき部分が多いように感じました。ベストの文字数も、何を目的にするかで変わってくるようですし。

だからもしかしたら、「こうした方がいい」などの形式上の縛りに囚われずに、記事の中身を充実させることを一番に考えた方が良いのかもしれません。ブログって奥が深いなぁ……。

いろいろと研究しつつ、これからも良質な記事を書いていけるように頑張っていきたいですね。

それでは、今回はこのあたりで。

 - ブログ, Webツール , , ,

Sponsored Link
Sponsored Link

  関連記事

「あとで読む」ツールとしてEvernoteへのWebクリップを使っていた私がPocketを導入した理由
この記事の所要時間: 107

今まで長らくの間「あとで読む」ためのツールとしてEvernoteへのWebクリップを愛用してきた私だが、この度思うところあってPocketを導入した。実際使ってみたら思いの外便利に活用できる手応えを感じたので、今回はPocket導入への経緯を含めお話しする。

Todoistでブログのネタを管理してみる!
この記事の所要時間: 648

この記事の所要時間: 約 6分48秒 長かった一週間が終わって休日を迎えた怜香@Ray_mnzkです。 今日は久々に宝塚まで出向いてきました。といっても観劇ではなく、今日発売のポケットカレンダーと先日 …

ブログテーマ変えてみました!
この記事の所要時間: 821

先日偶然出会ったWordpressテーマ「Stinger5」に一目惚れしたのをきっかけに、ブログテーマの変更を行った。その際に行ったカスタマイズや、苦労した点などのお話。

Workflowyからたすくまにタスク転記できるブックマークレットに新作が登場!さらに転記がやりやすくなったよ!
この記事の所要時間: 731

クラウドアウトライナーであるWorkflowyでタスク管理をする場合、一日のタスクをうまく実行させていくために、たすくまを併用することも多い。その際、Workflowyからたすくまにタスクを転記する必要があるが、その作業を簡単にしてくれるブックマークレットに新作が登場したので、早速ご紹介する。

今年も一年ありがとうございました!
この記事の所要時間: 445

2016年も大晦日。まもなく到来する2017年を前に、ブログにまつわる今年の振り返りと、来年に向けた抱負を語ってみようと思う。

ブログを独自ドメインにしてみました
この記事の所要時間: 612

この記事の所要時間: 約 6分12秒 (Pixabayより) 昨日の記事通りに早めの時間に親指シフト練習してたら見事に寝落ちた怜香@Ray_mnzkです。 どういうわけか親指シフトの練習していると途端 …

no image
ブログカスタマイズと謎のアクセスの話
この記事の所要時間: 444

この記事の所要時間: 約 4分44秒 大晦日ですがつい先ほど2014年の仕事納めをしてきました。といっても今日やったのは事務所の大掃除ぐらいですけど。大晦日だし午前中まででいいよーと言われてたんですが …

ブログ移転作業真っ只中! ~「要素を検証」が何気に超便利~
この記事の所要時間: 611

この記事の所要時間: 約 6分11秒 (Pixabayより) ブログ移転の準備を着々と進めております怜香@Ray_mnzkです。 とはいえ、なかなか思うようにいかず難儀しているのが現状です……何せ私、 …

CSSのお試し・勉強に!ブラウザ上でCSSを扱える「CSS Desk」
この記事の所要時間: 545

ブラウザ上でCSSを試すことができるWebツール「CSS Desk」。登録・ログイン不要ですぐさま使え、記述したCSSがリアルタイムでプレビューできる便利さをもったこのツールをご紹介する。

タスク細分化が簡単になる!Workflowyで作ったタスクリストをTodoistのプロジェクトテンプレートにできるブックマークレットが来たよ!
この記事の所要時間: 920

Todoistでのタスクの階層化作業は、インデントが若干やりづらかったりと、面倒に思えてしまうことがある。しかし、Workflowyなら簡単だ。ならばWorkflowyでタスクリストを作り、Todoistに渡したらいいではないか……そんな願望を叶えるブックマークレットが登場したので、早速ご紹介する。

Message

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

CAPTCHA