こんにちは。元システムエンジニア、チョッピーです。
世はまさに一億総クリエイター時代
「一億総クリエイター時代」という言葉があるらしい。
Googleで「一億総クリエイター時代」で検索してみたところ本記事掲載時点で約411万件のページがヒットした。どうやら、かなり人口に膾炙している言葉の様だ。
また、この言葉はどうも2008年くらいから顕著に使われはじめたように思われる。2008年と言えばYouTubeやニコニコ動画等のサービスが開始されて数年が経った時期。
僕の記憶をさかのぼると、2008年時点におけるそれらのサービス利用者の多くは、著作権などは全く気にせずに他人の著作物を流用してコンテンツを作っていたような気がする。そのため、「一億総クリエイター時代の著作権」というような形でこの言葉は使われ始めたように見受けられる。
IT化の進展で一般大衆も著作者となり、ネット上に著作物を発表できるようになった。「一億総クリエイター時代。著作権法はより普遍性を持った法律に変性してきた。従来の『権利者』の声だけを考えていい時代ではない」
「著作権は混迷」「ダメと言ってもネットは止まらない」──東大中山教授｜ITmedia
当時は「コンテンツなんて作っていなかった人々がコンテンツを作り始めた。このままでは色々と問題が発生するぞ。社会も変わらないといけないし、人々の意識も啓蒙しなければいけない」という考えが主流を占めていたのであろう。
実際、2008年4月24日に一般社団法人コンピュータソフトウェア著作権協会が発表した「豊かな情報社会への正しい知識と思いやりのある行動・情報モラル」というパンフレットは、まさにその問題を防ぐための心構えなどを「情報モラル」という言葉で『私たち』に向けて説明している。
現在私たちの社会では、情報の力が社会を動かす重要な要素となっています。そのような情報社会にあって、私たちは日々創作を行い情報を発信しており、一億総クリエイター時代にあるといえます。「情報モラル」とは、「創作」という人間しか行わない行為の価値を土台に据え、情報社会において安全・適切に活動するために私たちが身につけるべき知識と行動のことです。
豊かな情報社会への正しい知識と思いやりのある行動・情報モラル｜一般社団法人コンピュータソフトウェア著作権協会
その後、時代は流れ「一億総クリエイター」の活躍の主戦場はSNSに移った。また、一般消費者が作り出すコンテンツはUGC（User Generated Content）などと呼ばれるようになり「市井のクリエイティブ」はマーケティングとブランディングの文脈で解釈されるようになった。
…ような気がしている、僕は。
念のための補足ですが、上の「一億総クリエイター時代」に関する文章は全て僕ことチョッピーの調査と記憶と感性に基づく独自の理解です。「その解釈や歴史認識はおかしい」という批判は当然、あると思いますし、事実誤認もあるかもしれません。上の文章に違和感を感じた方はご自分で調べてみる事をおススメします。
道具の質は高くなくては価値がない
さて、他人事のように『「市井のクリエイティブ」はマーケティングとブランディングの文脈で解釈されるようになった。』などと書いてみたのだが、かくいう僕もマーケティングとブランディングにコンテンツを活用している人間の一人である。
僕もSNSを利用しているし、YouTubeに動画をアップした事もある。そもそも、今、皆様が読んで頂いている本記事自体が、まさにそれを目的として僕が作ったコンテンツのひとつである。
また、本記事が掲載されている本サイト『ふらとぴ』自体もコンテンツマーケティングを目的として構築・運用されているメディアだ。
僕達ふらとぴ編集部のメンバーはコンテンツを通じて「障害福祉施設」や「授産製品」や「クリエイター職の志望者」や「それを応援する一般企業」の知名度や売上やイメージなどを高め、それと同時に「サイト閲覧者」の皆様に「楽しさ」を提供しようとしている。
おそらく「障害福祉 × コンテンツ」をビジネス化しようとしている本サイトは、コンテンツマーケティング業界的にも福祉ビジネス業界的にも極北も極北のかなり異端児と言える存在なのではないかと思います。マクロな目線で捉えると「コンテンツマーケティングは行きつくところまで行きついた」と言える状況にあるのかもしれない。
そんなわけで僕は日々、コンテンツを作っている。作っているのだが、別に昔からコンテンツを作る事を目的に生きてきた人間ではない。
ここまでの書きっぷりでご理解頂けたかもしれないが、僕は「コンテンツメイク」を完全に「手段」として捉えている。まさにマーケティングとブランディングのツールとしてコンテンツを作っているわけだ。
高校時代に文芸部に所属して小説を書いていたりしたので、昔からコンテンツ作りが好きではありました。でも、それを生きる目的にはしていませんでした。
これは僕の持論だが、「コンテンツメイク」が目的である場合は極論、出来上がったアウトプットの質は作者にとってはどうでもいいのではないかと思う。
「作ること」自体が目的なのだから、作り終わった後の事は関係無いハズだ。それが世の中に受け入れられるかどうかとか、自分が味わって楽しいかとかは全て副次的なモノのハズだ。
「そうではない」という方は、きっと「コンテンツメイク」以外の目的があるのだ。それを自覚しているか自覚していないかはさておき。
一方、「コンテンツメイク」を手段として捉えている僕の様な人間にとっては「コンテンツの質」はものすごく重要なファクターとなる。「低品質なコンテンツ」だとマーケティングとブランディングのどちらの目的も達成できないからだ。
切れない包丁や、打てないハンマー、もしくは動かないプログラム。これらと同じく「面白くないコンテンツ」は、それを手段と捉える人間にとって役に立つ代物ではない。
そんなわけで、僕は最近、コンテンツを自ら作りつつ、コンテンツメイクに関する書籍を読んだりしてアウトプットの質を出来るだけ上げられるように動いている。
何事においても実践と座学は大事だと思いますので
「要件定義・設計・開発・テスト」の流れって有益！
そこで気付いた事がある。正確に言うと昔からボンヤリと感じていたのだが、最近、確信をもって言えるようになった事がある。
「なにかしらのアウトプットを作るにおいては『要件定義・設計・開発・テスト』がとても大事」なのだ。
僕は前職でシステムエンジニアとして11年間働いていた。システムを作る上では「要件定義・設計・開発・テスト」という流れが基本となる。僕の理解で非常に簡単に各工程を説明すると以下の通り。
- 要件定義：「何を作るのか」を確定させる作業
- 設計：「どう作るのか」を確定させる作業
- 開発：要件定義・設計で決まった内容に従い実際に作る作業
- テスト：要件定義・設計で決まった通りに作られているかを確認する作業
補足です。実際のシステム構築作業にあたっては要件定義の前段階として「システム化計画」などの工程も存在します。また、各工程をもっと細分化して表現するのもマトモなプロジェクト運営をするにあたっては必須の作業となります。（基本設計とか詳細設計とか単体テストとか結合テストとかシステムテストとか運用設計とか業務設計とか）
これらの工程をテキトーに行ってしまうと出来上がるシステムの品質はヒドい事になる。逆に言うと、これらの工程をキッチリ行えば「まぁ、問題はない」と言えるレベルのシステムは出来上がる。
これ、システム以外にも同じことが言えると思うのだ。
「ヒドくないコンテンツ」を作りたいのであれば、実際の作業に着手する前に「何を作るのか」と「どう作るのか」を確定させる必要がある。そして、実際の作業が終わった後に「キチンと作れているか」を確認する必要もある。
これは完全に上に書いた「要件定義・設計・開発・テスト」の流れと同じだ。
もう少し具体的にお伝えする。たとえば文章を書く上では以下の工程を辿る必要があるだろう。
- その文章のテーマ・主張を決める（要件定義）
- テーマ・主張を伝えるために最適な構成を考える（設計）
- 実際に書く（開発）
- 書き上がったモノに誤字脱字や論理の破綻がないかを確認する（テスト）
動画を作る場合だと以下のようになるだろう。
- その動画のコンセプトを決める（要件定義）
- コンセプトを伝えるために最適な場所・構成を絵コンテ等に表す（設計）
- 実際に撮影・編集を行う（開発）
- 撮影・編集にミスがないかを確認する（テスト）
エンタメ要素のないコンテンツでも同じだと思う。たとえばプレゼンテーション資料。
- プレゼンで聴衆に伝えたい主張を決める（要件定義）
- プレゼンの構成・目次を決める（設計）
- プレゼン資料を実際に作る（開発）
- プレゼンのリハーサルを行い、問題ないかを確認する（テスト）
うん、やはり何のアウトプットを作るにしても「要件定義・設計・開発・テスト」のメソッドは適応できるように思える。「アウトプットに汎用的に使えるフレームワーク」と言ってもいいのではないだろうか。
今回の記事にも適応させています
最近、僕は本連載『Daily Choppy !』において「構成」を非常に強く意識している。今回の記事もそうである。
正直、この記事で僕が言いたいことは「要件定義・設計・開発・テストの流れって有益！」という１点だけ。記事の冒頭で書いた「一億総クリエイター時代」とか実はどうでもいいのである。それに関して何かしらの意見があるわけではない。
でも、たぶん、いきなり「要件定義・設計・開発・テストの流れって有益！」と書いても読者は困惑してしまうのではないかと思った。そこで「一億総クリエイター時代」という言葉を用いて「あなたもコンテンツ作っていますよね」という語り口で「読者にとっての自分ごと化」を計ったのである。
うひゃー、浅ましい魂胆
いや、だって、実際「自分にとって関係のない記事」って読む気にならないじゃないですか。僕だったら「自分にとって関係のある記事」を読みたい。「自分が読んで楽しい記事」にするためにも「読者にとっての自分ごと化」は必須だったのだ。
その後、徐々に「あなたがコンテンツを作っている様に、実は僕もコンテンツを作っていまして。で、そこで気付いた事があるんですけど…」と徐々に「自分が本当に言いたいこと」を伝える構成にしてみた。
うひゃー、浅ましい魂胆
いや、繰り返しになりますけど「自分が読む場合」を考えたって、その人の素性もよくわからないうちから「聞いて聞いて！ 気付いた事があるんだけど！」って言ってくる人の話って僕は読みたくないですもん。
まずはお互いの共通点を見出して、なんとなくのシンパシーを感じた人の意見じゃないと聞きたくないでしょう？ その是非はさておき。
あと、誤字脱字とか論理の飛躍とかがあると読者に失礼なので、これを書き終えたら記事のセルフチェックもします。
自分の主張をキチンと伝え、かつ、読者に楽しさを感じてもらうためには、このくらいの工夫は最低限のマナーとして必要なんじゃないかな…と思う次第です。そのマナーを忘れないためにも「要件定義・設計・開発・テストの流れって有益！」なのではないかと思います。
本日の締め
今回は僕の考える「『要件定義・設計・開発・テスト』は全てのアウトプットに使えるフレームワークだ！」という主張を伝える記事を書いてみました。
僕は駆け出しクリエイターとして活動し始めてまだ2年足らずの経験しかありません。そのため、この主張に対して「そんなことないのでは…」と思われる方も多いかもしれません。
僕はクリエイターとしての経験が浅い分、過去のシステムエンジニアとしての経験も組み合わせてコンテンツを作ろうとしています。そのため、今回の記事の様な意見を持つようになった可能性も高い。
もし、こちらの記事になにかしらのご意見がある場合は是非コメント頂けると幸いです。本記事もいつものようにTwitterやFacebookにシェアするので、それに対して引用リツイートとかでコメントして頂けると一番、ありがたいですね。
本日もふらとぴにお越し頂きありがとうございます。
ただ、このフレームワークに従うと、どうしても「ライブ感」が失われる…という欠点もあるのは自覚しています。システムにライブ感は本当にいらないですけど、コンテンツはその限りではない…という気もしているので。
