【構造化して考える】ブログ記事の書き方、考え方、テンプレート公開

のろっこ

「ブログを始めたい、でも記事の書き方が分からない」

このような方を想定し、本記事を執筆しました。

記事を書く、文章を書くことについて、なんらかのご参考になれば幸いです。

テンプレートの用意



記事というのは、慣れてくるとある程度の「型」が出来上がってきます。


この「型」を抽出して、記事を執筆する際のテンプレートにすると、執筆が捗ります。


なので、本記事では、私が記事を執筆する際に用いている「型」を紹介します。


なお、本記事で紹介する「記事の執筆法」は、「ノウハウ記事」に特化していますが、他の分野にも応用できると思います(実際に私は、ノウハウ記事以外もこの方法で書いています)。

テンプレートの中身



私は「_設計書.txt」というテキストファイルを用意していて、その中に以下の内容が記述されています。

_設計書.txt

◆この記事を読む人

◆改善内容


一つ目、「この記事を読む人」は、誰に向けての記事なのかを明確にするためのものです。


いわゆる「ペルソナマーケティング」と呼ばれるマーケティング手法を取り入れてるわけです。


二つ目、「改善内容」は、その人の何を改善するのか、その改善内容を明確にしていくためのものです。


要するに、「誰に対して、何を伝えるのか明確にする」ということです。


手順としては、記事を執筆する前にこの「_設計書.txt」をコピー&ペーストして複製します。


次に、ファイル名に日付を追加します。例えば「20200510_01_設計書.txt」という風になります。(01というのはその日の1本目の記事という意味合いです)


このように「_設計書.txt」を流用し、全体構造を統一しているわけです。

テンプレートの応用例



例として、この記事を書く際に使用した設計書を以下に示します。

20200510_01_設計書.txt

◆この記事を読む人

 ・ブログを始めたいと思っているが、記事の書き方が分からない人
 ・ブログを運営しているが、記事の書き方がイマイチ分からない人

◆改善内容

ノウハウ記事の執筆法
 1.テンプレートの準備
  ・読者像の明確化
  ・改善内容の明確化
 2.読者像の明確化
  ・誰が読みたいと思うか
  ・何を知りたいと思うか
 3.改善内容の明確化
  ・改善内容を一つに限定
  ・改善内容を分解し構造化
  ・肉付けをして記事の完成



この設計書をどのように仕上げたのか、その手順を以下にまとめます。

  1. 「改善内容」を考える
  2. 「この記事を読む人」を考える
  3. 「改善内容」を分解し、構造化する
  4. 出来上がった設計書に肉付けをし、記事を執筆する。


順番が前後しますが、まずは改善内容として「ノウハウ記事の執筆法」を考えました。


次に、「この記事を読む人」を明確化したところで、改善内容を分解し、構造化しました。


この「分解して構造化する」というのがこの手法の肝だったりします。


この場合は、まず「ノウハウ記事の執筆法」を考えたわけです。


これを一段階分解すると、「1.テンプレートの準備」「2.読者像の明確化」「3.改善内容の明確化」という3つの要素になったわけです。


それぞれをらに分解することで、最小単位の要素が出来上がるわけです。


場合によっては、さらに分解して階層を深くすることもあります。


「ここまで分解すれば全体像としては十分だし、執筆できるだろう」となれば、いよいよ執筆にとりかかわるわけです。


そうすると、全体の構造を把握しているので、「どのような流れで記事を書いていけばよいのか」という手順が自ずと分かります。


このように、ノウハウ記事を執筆する際は、「誰に向けて、何を伝えるのか」ということを念頭に、構造化することが重要だと考えられます。

まとめ



これまでの内容を以下にまとめます。

  1. 「この記事を読む人」と「改善内容」を記したテンプレートを用意する
  2. 「改善内容」を考える
  3. 「この記事を読む人」を考える
  4. 「改善内容」を分解し、構造化する
  5. 出来上がった設計書に肉付けをし、記事を執筆する。


余談



本記事で触れた「分解して構造化する」という考え方は、色んな場面で使用することが出来ます。


今回のように、上位層を分解して下位層を作るという手法を「トップダウン設計」と言ったりします。


逆に、下位層を積み上げて上位層を作る手法を「ボトムアップ設計」と言います。


実は、この考え方はIT業界では普通に用いられている手法です。


IT業界ではそれを「WBS(Work Breakdown Structure)」という表にまとめて、プロジェクトを管理します。


このWBSがプロジェクト成功のカギだと言っても過言ではないくらい、物事を構造化するというのは最重要なことだと多くの人から信頼されています。


私自身、WBSの知識があったおかげで、「記事の執筆」にも「新しいことの計画」にも応用できていると実感しています。


もしWBSという考え方について詳細に知りたい方は、以下の書物が参考になると思います。


「システム開発のための」とありますが、前半部分は前提知識などほとんど無い状態でも気軽に読めます。


後半はがっつり「システム開発のためのノウハウ」になりますが、前半部分だけでも十分に生きた知識になります。


専門書とかの重々しい感じはなく、書物として普通に読めます。


興味がある方はどうぞ。


では、本日も物事を構造化して良い一日を。

コメントを残す

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