「アイデア」の選びかた

選ばれるべき「アイデア」とは

大人数で企画をすすめれば、当然、様々な意見がでてくることになります。(逆に、アイデアがでてこない企画会議というのは想像するに恐ろしいですし、様々な意見はよい状況ですね。)

「面白いアイデア」であったり、「かっこいいアイデア」であったり、「社会的に意味のあるアイデア」であったり、「過去成功体験のあるアイデア」かもしれません。いろいろな意見がでてきます。

ここで、仮定として、それら全ての意見が、「それなりにまともで傾聴する価値がある」とします。

「全てがまともな意見」という、そんな僥倖ともいえる状況があったとして、「その沢山のアイデアの中で、私たちは、どのアイデアが選ばれるべきなのでしょうか。」

実際のところ、仮に「どうみてもまともじゃない意見」だって、本人がすごい良いと思っていたら、同じことです。却下は簡単にはできません。

 

横行する、主観による判断

皆さんも経験があるように、これを決めるのは、簡単なことではないんです。多くの場合、社長の意見であったり、声が大きい人の意見が通りやすくなります。

その『 上位の役職者や声が大きい人のアイデアが通る状況』というのは、「評価する物差し」がないままに、主観や雰囲気で、企画を評価しているという状況です。

一般的に、「新規事業を考えよう！」とか「何か新しいことを考えよう！」といったようなブレストはその評価軸が存在しないので、よくないブレストになりがちです。

残念ながら、このように、企画進行をする際に、「評価する物差し」や「評価軸」を用意しないで、進めることが多くあります。

 

評価軸が明確にしてみると

逆に、「評価軸」が明確なブレストを想像してみます。

例えば「シルバー世代が、孫のために、これは購入せざるを得ない！というサービス」という「評価軸」を用意すると、その会議は生産的になってきます。

「そのアイデアは購入動機にならない？」とか「購入単価が高すぎでは？」とか、だれでもアイデアを精査することが可能になります。

物差しなしで、「何がいい企画か」を判断するというのは非常に主観的で乱暴であり、その主観が正しい場合には良いですが間違っているときは目を当てられません。

 

企画における「テスト駆動開発」

プログラムを組む際に、「テストコードから開発する」というテスト駆動開発があります。

※ テスト駆動開発(TDD)自体は、数年前に、Ruby on Rails の開発者 DHH が 「TDD is dead. Long live testing. (DHH)」っていうエントリー書いてましたね。そういえば。

ものすごく簡単に説明すると、「「正しい処理をするか・否か」を判断するプログラムを書いておいて、その後で本体のプログラムを書く」形です。そのテストコードがあるために、「プログラムが上手く動いているか、否か」は、テストコードを無事に通っているかどうかで判断がすることができるわけです。

アイデアを検討する際にも、まず「評価する軸」を用意するだけで、その後の「アイデアの選択」が容易になります。

個人的には、「企画もテスト駆動開発が有効だよな」って強く思っています。

はじめに評価軸ありき

「評価軸を明確にすること」は、「アイデアの選び方」だけではなく、そのアイデアをブラッシュアップする際にも評価は不可欠です。評価がなければ、どの方向性でこのアイデアを改善していけばいいのかわかりません。

例えば前述の例では「もっとシルバー世代が買いやすくする仕組みってなんだろう。。」とか、いろいろアイデアを深めることができます。

恐らく多くの方が、無意識のうちに「評価する軸」を用意していると思います。ですが、自覚的に「評価する軸」を用意したり、参加者に「これで評価する」ということを共有することで、そのミーティングの生産性は大きく変わってくると思います。

何かを考える時は、まず「評価する軸を用意する！」

これはあまり語られることはありませんが、論理的思考の骨子なので、意識してみてみるといいかもしれませんね。