「歌ってみた」「踊ってみた」という言葉にピンとくる人はニコニコ動画を観たことがある人なんじゃないかと思います。
文字通り、既存曲やボーカロイドの曲を歌ってみたり、踊ってみたりして、その様子が数多くアップされているんですよね。
歌ってみたとはニコニコ動画のカテゴリタグの一つ。自らの歌声を動画に収めて投稿したものである。ジャンルとしてはパソコン通信時代から存在していたが、こうした行為を「歌ってみた」と称することになったのは、2007年5月10日のニコニコ動画における正式カテゴリ化以後のことである。
歌ってみたとは (ウタッテミタとは) [単語記事] – ニコニコ大百科
「歌ってみた」「踊ってみた」って、いいよね
この「歌ってみた」「踊ってみた」という言い回しが面白いなー、と思います。
「完璧とは言えないけどとりあえず歌ってみたよー」
「ただ踊ってみただけで特別スゴいわけじゃないからね」
とエクスキューズしておくことで、動画をアップするハードルを自分から下げにいくカンジｗ
この、まずはアウトプットして、2回3回と回数を増すごとにクオリティを上げていくのが 今の時代にマッチしていていいなーと感じます。
観ている側もストーリー性を読み取れて、応援したくなる気持ちになるんですよね。
ビジネス界の「やってみた」
ビジネスの世界でも「やってみた」カテゴリー、流行ってます。
リーン・スタートアップ
これまで新規の事業を立ち上げるときには、緻密な事業計画書を作って収益のシミュレーションして、失敗しないように細心の注意を払って実行に移すものでした。
けれど、そのやり方ではコストがかかる上に、なによりスピードが遅くなってしまいます。
おまけに計画を練りに練ってスケジュールをガチガチに固めているので、途中で「あれ？なんか方向性間違ってない？」となっても、容易には方向修正できませんでした。
そこで現れたのが「リーン・スタートアップ」。
仮説を立てその検証をする、それを何度も繰り返して事業を進めていくという方法論です。
ニコニコのカテゴリができた方が早いみたいですねｗ
アジャイル型開発
似たようなタイミングで、ソフトウェア業界では「アジャイル開発」という開発手法が脚光を浴びました。
私が SEモドキをやっていた頃は、ウォーター・フォールモデルという開発手法が当たり前でした。
ウォーターフォール型の開発とは、「基本計画」「外部設計」「内部設計」「プログラム設計」「プログラミング」「テスト」と、開発のプロセスをそれぞれの工程に分けて、順番に各工程を進めていく方法です。
「基本計画」が終わったら次は「外部設計」に進むといった具合ですね。
次の工程に進んだら基本的には前の工程には戻りません。
それを「落ちる水」になぞらえて「ウォーターフォール」と呼んでいるんですね。
このウォーターフォール型も、リーン・スタートアップが登場した時と同様、柔軟性のない開発手法だったんです。
例えば「テスト」の工程まで進んだということは全開発の8割〜9割方終わっているという進捗になるのですが、その段階で「あれ？なんか方向性間違ってない？」となっても、もはや後戻りできませんよね。
そんなウォーターフォール型の開発の弱点を華麗にクリアする開発手法として登場したのが「アジャイル開発」なわけです。
アジャイル開発は、イテレーション（反復）と呼ばれる短いスパンで設計からプログラミング、テストまでをひとまずやってしまいます。
これまでのウォーターフォール型なら作るべきシステムの設計を全て終わらせて、次に全てのプログラミングをして、、と順番にやっていたのを、アジャイルでは細かく分割して、部分の設計・プログラミング・テストをまずやるんです。
このやり方なら、テストの工程で設計のミスに気づいても、致命的にはならずに設計に立ち戻って修正ができるようになります。
今日で言うアジャイルソフトウェア開発手法は、以前は「軽量ソフトウェア開発手法」と呼ばれていた。 先述したとおり、2001年に軽量開発手法において名声のある人々がスノーバードに会し、「アジャイルソフトウェア開発手法」と呼称を変えた。
アジャイルソフトウェア開発 – Wikipedia
こちらはニコニコの「◯◯ってみた」カテゴリが生まれるよりも先にあったみたいｗ
計画の細部にこだわるな
リーンやアジャイルを引き合いに出すまでもなく、「綿密で壮大な計画」の弱点は「スピードが遅くなる」ことと「軌道修正が難しくなる」ことの2つ。
特に私のような個人で動いているような人にとって「スピード」と「フットワーク」って大きな組織と対抗する唯一の利点みたいなものじゃないですか。
そのスピードとフットワーク、両方を殺すのが、「計画に全力を注いで計画が完成するまでは動かないこと」なんです。
これフリーランスが一番やっちゃいけません。
重箱の隅をつついてるヒマはないんです。
大まかブレてなければOK!
今や誰もが知っている映像制作会社のピクサーもリソースをどこに割くかを意識されているんですね。
ピクサーと言えば恐ろしいほど繊細でリアルな CG のイメージがあるので、ちょっと意外でした。
でも 3D のレンダリングとか不要なモデルにリソースを割かないように意識するのは、当然ちゃ当然か。
Google もサービスを出しては自らつぶしていくのがよくわかる企業の一つですね。
でも、日本でこの考え方を徹底できてる企業ってどれくらいあるんでしょうか？
大きな企業こそ実践するのは難しいんでしょうが、だからこそ我々のようなフリーランスでも勝負できるフィールドが生まれるってもんです。
走りながら完成を目指すもう一つのメリット
とりあえずやっちゃうって、スピード感が出て、軌道修正も楽チン。
さらにもう一つは何度も達成感が味わえて楽しい！というメリットも。
遥か遠くのゴールに向かって、いつ辿り着けるか不安なまま走り続けるのはしんどいもの。
でも小さな目標を多く設定すればムリなく走り続けられるんです。
メチャクチャ給水所の数が多いマラソンのようなもの。
これこそ個人や小さな組織がとるべき立ち位置。
さぁはじめましょう。
1件のコメント