企画屋さんは自分の仕事はデザインだと認識したほうがいいんだと思うよ

いわゆる典型的な企画屋さんの仕事ってほんとに手におえないなって、最近つくづく感じます。

僕自身、どちらかというと企画を担当する仕事をしてますけど、そんな僕からみても、いわゆる企画屋さんの仕事って傍からみてても「おいおい、それじゃあ、いつまで経っても形にならないよ」ってくらい、実装のことを無視した仕事の進め方をしてたりします。

制約を知らない人たち

それでいて、そういう人たちに限って「自分はものづくりにかかわってる」みたいな顔したり「ユーザー視点がどうこう」とか言ったりします。客観的にみると、ぜんぜん、ものづくりの視点が欠けてるし、ユーザー視点のかけらもなくて単にあなたの思いつきを並べてるだけですよね、と思うことが多いんですけど。

とにかくアイデアベースだけなので、ものづくりが受ける物理的制約・技術的制約からもフリーですし、ユーザー視点といいつつユーザーの意見に耳を傾けてるわけでもないからそちら側からの制約もありません。なので、話は収束するどころか何の制約もない状態で話が拡がるばかり。

仕事をするってのは制約を知るってことなんだと僕なんか思いますけど、そういう視点がないんですよ、典型的な企画屋さんには。

アイデアばかりが豊富でも形になりません

「思いつき」から「考え、形にする」ことへ」というエントリーでは「思いつき」のアイデアだけでそれ以上深掘りせずに仕事が滞っちゃう問題について書きましたが、企画屋さんの場合はそれとはちょっと違うんです。
深掘りしないのはいっしょですけど、じゃあ、何にもしないかっていうとそうでもなく、ひたすら「思いつき」の量を増やそうとするんです。いつまでたってもアイデアフラッシュ。やれやれ。

もちろん、ある段階においてアイデアの量をひたすら増やすことは必要です。視点が拡がりますから。
でも、いつまででも視点を拡げっぱなしでは何にも形にならないのは結果として深掘りせずに仕事が滞っちゃう場合とおんなじです。

ふろしきを拡げる方向で進めていたベクトルをどこかの時点で収束させないと仕事としてはどうにもなりません。

アイデアばかりが豊富でも形になりません

僕はこんな風に考えてます。簡単にいっちゃうと仕事って企画と実装しかないって。

なので、最近、僕がずっとこのブログで書いてるデザインの話ってようは企画の側の話です。企画=デザイン。設計です。計画です。アイデアを出しっぱなしにするのが企画じゃない。

企画の側の人間がわかってないのは、実装側だって初期段階ではアイデアを膨らますんだってこと(いや、実装をやってる人でもわかってない人がいるかも)。アイデアを膨らますのが企画の仕事なんじゃなくて、単に実装とデザインでは膨らますべきアイデアも違えば、そこからアイデアを収束させて固めるべき形も違うだけだということです。

イメージとしては、システム開発における外部設計と内部設計の区別に近いのかな。外部設計が企画。内部設計が実装寄りです。あるいは内部設計こそデザインと実装の架け橋になるのかも。

企画屋はデザイナーなんです。

アイデアの収束の仕方

なので企画屋がやるべきことは単にアイデアを膨らますだけではなく、同時にそのデザインに課せられた制約を知り、その制約とアイデアのリストを見比べることで最も適切なアイデアに収束させていくことも企画屋=デザイナーの仕事には含まれます。

アイデアを出すほうは得意な人が多そうなので、ここではアイデアの収束の仕方をいくつかリストアップしておきましょう。

  • 物理的な制約を知る:企画屋さんで困りものなのは口であれこれ言うばっかりで、手を動かさない人が多いこと。そうじゃなくてちゃんと手を動かしなさいって思います。具体的に「手を動かす」ってどういうことかというと、プロトタイプ、デモをつくることです。別に最初からかっこいいプロトタイプをつくる必要なんてないんです。つくることが重要です。いや、かっこつけてばっかりで自分の手を汚そうとしない企画屋さんにはぜひプロトタイピングを行ってほしい。そして、物理的な制約を知れ!
  • ユーザーの側の制約を知る:これはもうこのブログでは毎日のように書いてることですよね。なのでここでははしょります。ペルソナ/シナリオ法もあれば、Contextual Designなんて方法もありますよね、と。とにかく「ユーザー視点」とか口でいうだけじゃなく、ユーザーの実際の行動を見てみなさい、と。
  • ビジネス・市場の制約を知る:自分の会社の制約は知っている人は多くても、結構、市場環境における競合とのギャップなど、広い目でビジネス上の制約について考えている人は意外といません。せめて3C分析くらいはやってビジネス面での制約についてもちゃんと理解しましょう。

やっぱりこう書いていて思うのは、企画屋っていう位置づけがよくないなっていうことです。
そうじゃなくて企画というのはデザインすることなんだということをちゃんと認識することかなと思います。

そして、企画屋にも、デザイナーにも言いたいのは「あんたがやってて楽しい企画やデザインがいまここで求められている企画・デザインじゃないんだよ」ってこと。
自分がやりたい企画・デザインしか見えない企画屋、デザイナーが本当に多いんですけど、そういう人は結局、いまここにある制約条件から必要とされる形を見出せない人なんだと思います。そうじゃない。あなたが何をやりたいと思っていようと、形はすでにそこにある。あなたの仕事は、Found Objectなんですよって思います。もちろん、これは自戒も含めて。

企画屋=デザイナー

逆にいえばデザインとは企画することでもあるということです。
ものづくりのデザイナーはどうも最終形に近いもののデザインにばかり集中しがちですが、初期の段階ではものの形など見えないもやもやとした霧のなかから形の原型を見つけることからはじめないといけない。企画屋がでしゃばっちゃう原因のウラにはデザイナー側のこのあたりの弱さも関係しているのかもしれないななんてことも思います。

でも、本当は企画屋とデザイナーはイコールだと思う。完全に同一人物である必要は必ずしもありませんが、同じミッションをともに遂行していくのが企画屋とデザイナーで、ゴールは完全にいっしょなのではないかと思います。

 

関連エントリー

この記事へのコメント

  • とおりすがり

    内容興味深く読ませていただきました。
    おおむね同意ですが、少し意見も。

    僕は手を動かすほうですが
    企画屋がプロトタイプをしては
    (練習ならともかく)
    仕事にならないと思います。
    スーパーな人じゃないかぎりパフォーマンスの問題として。

    手を動かすほうのディレクターレベルは、企画やのイメージや思い付きを上手に収束するのが腕だと思います。

    工程の上流と下流をトップとボトムで表現するなら
    トップダウンからどこまで手が届くか
    ボトムアップからどこまで手を伸ばせるか
    それがそれぞれのプロとしての力量のような。

    >外部設計と内部設計の区別に近いのかな。
    重箱の隅ですが
    これは違うと思います。
    (当方SE経験あり)

    外部設計で、すでに様々な制約を考慮した設計に入ります。
    ひとつ上流の要件定義(システム要件定義)でもシステム制約ありきです。

    あえて言うなら
    ビジネス要件定義とシステム要件定義の区別に近いですかね。
    ただ、この工程の呼び名は各社で様々です。
    また、システム特性によっても。
    2007年07月09日 04:04
  • tanahashi

    プロトタイプに力量は必要ないと思ってます。
    どうせ捨てるものですから。
    練習じゃなくてテストです。
    もちろん、工程が後のほうになれば、ある程度の力量が必要になりますが、最初のダーティープロトにはそれは必要ないでしょう。
    よほど不器用であれば別かもしれませんが。

    うまいへたじゃなく、人間なので手を動かしましょうって思います。

    あともうひとつ思ったのは、結局、企画/デザインと制作/実装という区別は入れ子状態になっているのではないかってこと。
    大きなプロセスの上では制作/実装側だと思われているものが、詳細にはいっていくとその中にもデザインと制作がある。

    工程におけるタスクとそれを実施する人を1対1対応させようとしてイメージするのがダメなのかもしれませんね。

    本文中にも、

    >でも、本当は企画屋とデザイナーはイコールだと思う。完全に同一人物である必要は必ずしもありませんが、

    と書いていますが。

    2007年07月09日 08:19

この記事へのトラックバック