企画設計=デザインとは

結局のところ、企画設計=デザインとは、

  1. 与えられた問題あるいは自ら発見した問題を明確に定義
  2. その問題を下位問題に分解し要素間の関係性を把握することで解決するべき問題全体を理解した上で
  3. さらには下位問題の各要素について理解を深めるためのデータ収集を行うことで下位問題のそれぞれに解決案を見つけつつ
  4. 個々の解決案を最終的に統合する解決のコンセプトを探り
  5. そのコンセプトが見つかったら今度は実現に向けた素材や技術の検討
  6. 実現性の検討やコンセプトの検証のためのプロトタイピングとユーザーによるデザイン評価を行うことで
  7. 最終的な設計案=解決を導き出す

という一連のプロセスにほかなりません。

まっ、これが創造性の基盤となるプロセスです。
もちろん、これがあれば「創造的な仕事」ができるようになるわけじゃありませんが、このプロセスを知らないと「創造的な仕事」がむずかしいのは確かです。

planning process


ある雨の休日の午後に

例えていうなら、

  1. ある雨の休日の午後、おいしいものを食べたいなと思って何かつくろうと思い立ち
  2. それには、雨で買い物に出かけるのは嫌だから材料は冷蔵庫にあるもので済まそうとか、そんなにいま現在お腹が空いているわけではないので実際に食べるのは1時間くらいあとでいいなとか、ここのところ洋食系のものばかり食べてるから和食がいいなとか考えつつ
  3. 冷蔵庫には実際あれやこれやの素材があるからこんなものがつくれそうとか、12時間でできるのはどんなものかなとか、和食だと何がいいだろうとかなど頭を悩ませ
  4. 最終的に絞り込むとあれとこれとそれといった3品かななんて思い
  5. それって実際どうやってつくればいいのかと家にあった料理の本を見返したり、必要な調味料は揃ってたっけなんてことも確認しつつ
  6. いちお同居人にもこれからあれとこれとそれをつくろうと思ってるけど食べる?などと聞いたりもして
  7. 最終的につくるものを決める

みたいなことをやるわけです。

深澤直人さんが『デザインの輪郭』で書いている「デザインの輪郭」を決める外側からの「選択圧」と内からの「張り」という区分でいうなら、問題の細部化や階層構造化とそれに基づいたデータ収集(冷蔵庫に何があるかとか洋食より和食だなとか、調査でのユーザーの利用状況やニーズの把握もそう)が外側からの「選択圧」を知ることにあたり、内からの「張り」に相当するのが素材や技術を吟味する部分(料理本でつくり方を調べるとか、製品の素材や作り方の検討とか)になります。

どうでしょうか? すこしは企画設計=デザインというもののプロセスがイメージできたでしょうか?

レシピどおりにしかつくれなかったら主婦失格

注意点としては、なにをデザインするかによってプロセスは必ずしも上記のすべてを行うわけではないということです。つくるものによってプロセスやプロセスの中身はすこしずつですが、確実に変わるということ。
だから、プロセスそのものだったり、そのなかで使う手法を丸覚えするのではいけません。問題に応じて応用が利くようにそれぞれのプロセスがなぜ必要かとか、そこで使う技法にはどんな特徴があり何を解決するかはわかっていないとダメです

しかし、これはプロセスが標準化できるということではありません。ある問題を理解したとしても、同じ方法で次の問題も解決できるわけではありません。典型的なデザインの状況にはいつも、方法のわからないものがつきまといます。

そのあたりも料理と同じ。なんでも焼けばいい、煮ればいい、切り刻めばいいってわけじゃありません。つくる料理に応じて必要なプロセスや料理法なんかも違ってくるのが普通です。

レシピどおりにしかつくれなかったら主婦がつとまらないのとおんなじで、企画設計もプロセスどおり手法どおりにしかできないのであったら、それは実戦では役に立たないということもお忘れなく。

  

関連エントリー

この記事へのコメント

  • fin

    問題を解決するにあたって、当然それを妨げる阻害要素を洗い出すように心がけていますが、
    阻害要素をすべて除去することは難しいかと。SEOなんて良い例です。すべての阻害要素を取り除ければ、順列1位は可能ですが難しいですよね。

    ですから、阻害要素の重み付けってすごく重要だと考えていますが、hirokiさんはこのあたりのノウハウってお持ちでしょうか?
    2007年12月14日 12:25
  • hiroki

    おっしゃるとおりで、阻害要素をすべて取り除くのはむずかしいことです。
    そして、僕はすべて取り除くことがいいことではないと思ってます。
    足りないくらいでちょうどいいか、と。
    「侘び」です。ゆがんだ茶碗です。引き算のデザインです。

    阻害要素の重み付けという点では、やっぱり僕は重要度を導くのにもペルソナをつかってます。
    『ペルソナ戦略』にも載っていますが、ペルソナ・フィーチャー・マトリックスという手法ですね。
    ようはペルソナの観点からフィーチャー=機能の重要度を評価する手法です。
    ユーザー視点での機能評価という意味では、古典的な品質機能転換(QFD)の手法もありますね。
    これも似たようなものです。
    一度調べてみたら、そのままは使えないにしても応用という意味では役に立つかもしれません。
    2007年12月14日 22:42
  • fin

    引き算のデザイン・・・。
    うーむ、発想の転換・・・すこしすっきりしました。ありがとうございます。
    デスクの前だけでは煮詰まるようです。

    hirokiさんが紹介してくれたサイモンも、最適ルートと満足ルートは決してイコールではないと。

    満足ルートのインデキシングにペルソナを使ってみます。
    2007年12月15日 00:09

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