Archive for the ‘デザイン’ Category

ビジュアル・コンプレキシティのChapter3を読んでおくといろいろ捗るかも、というはなし。

2月 2, 2014

マニュエル・リマ氏が来日するのですこしでも活かすため事前勉強会を開催した。
この勉強会で、「ビジュアル・コンプレキシティについて理解するには、『ビジュアル・コンプレキシティ』のChapter3にはネットワーク・ビジュアライゼーションについて読むと良いんじゃないか」とアドバイスをいただいたので、再読をした。

たしかに、Chapter3には、

  • 関連する手法と技術
  • 5つの機能
  • 実現するための8つの原則

がまとってまっていて、とくに8つの原則は実践的な内容なので、「どうやって活かすの?」という疑問を持つ人にはおすすめの内容だ。

しっかり読んでも1時間程度なので、読んでおくとビジュアル・コンプレキシティに通底している、ネットワーク・ビジュアライゼーションについて整理することができる。
詳しい内容は本を読むのが一番なので、ざっと要点を引用して紹介する。

関連する手法と技術

ネットワーク・ビジュアライゼーションはさらに大きなくくりとしてネットワーク表現の領域に収まり、研究されている。
そして、ネットワーク表現はおおきくネットワーク・ビジュアライゼーションのほかに、グラフの描写について研究されている。
ネットワーク・ビジュアライゼーションにはグラフ理論、コンピュータグラフィックス、地図製作法が大きな影響を及ぼした。

今日のネットワーク表現は、一般に(グラフ理論に則した)グラフの描写と(情報の可視化に則した)ネットワーク・ビジュアライゼーションの2つの領域で研究が行われている。
p.79

ネットワーク・ビジュアライゼーションに大きく影響を与えたものには、グラフ理論と近年のコンピュータグラフィックの成果のほかに、地図製作ある。(原文ママ)
p.79

ネットワーク・ビジュアライゼーションがもつ5つの機能

ネットワーク・ビジュアライゼーションは、5つの機能を備えることにより、人々との知的好奇心を刺激し、ビジュアルを通じて情報の処理や理解をたすけ、発見を導くことができる。
またビジュアルが新たな研究へ展開するきっかけとして作用することをも期待されている。

では、ネットワーク・ビジュアライゼーション固有の目的は何なのか? 複雑なものの表現は、以下の「記録」「明確化」「表面化」「拡張」「抽象化」という主要な5つの機能によって実現される。
p.80

ネットワーク・ビジュアライゼーションを実践するための8つの原則

8つ原則はいかのとおり。
事前の勉強会でも「そもそもビジュアライゼーションをするプロセスが謎だよね。」などと話していたのだけど、しっかりヒントは本に載っていたのだった。

  1. 質問から開始する
  2. 関連性を探す
  3. 多変量解析を可能にする
  4. 時間を含める
  5. 語彙を豊かにする
  6. グループ分けを顕在化する
  7. 拡大縮小を活用する
  8. 複雑さを管理する

インフォグラフィックは、作成者が説明したいことを閲覧者の理解してもらうのが目的で作られる。
なので、「この図ではこういうことが表現したい」という、作成者の目的が定まっている、という前提がある。

しかし、ビジュアル・コンプレキシティの中で紹介される図は、動的なインタラクションができないためか、「なにを表現したいのだろう」と思わせる図が多い。
そのため、図を作成するときの目的が、「単純に見た目の美しさ、視覚的な快が目的なのか」「なにか発見があったらいいな、という漠然とした目的なのか」という疑問を抱かされる。
とくに、見た目が幻想的な図は、作成意図もまた神秘のヴェールに包まれて徐々にはっきりしてくる、というプロセスをたどるのか、という疑問があった。

上記の8つの原則を見ると、やはり図を作成には目的ありき、であることがわかる。

以上、ざっとChaper3を読んだ結果を引用を含めてまとめた。

最終的に「ネットワーク・ビジュアライゼーションとビジュアル・コンプレキシティの違いってなんだろう?」というのが新たな疑問がうまれた。
また、図を見て発見がある、という経験をすることがあるけど、作成者が故意に閲覧者に発見を促すことは可能だろうか。
ようるすに「発見」を促すためのネットワーク・ビジュアライゼーションの開発のプロセスというのは存在するのか、またそのプロセスというのはどういうものなのか、が疑問としてのこった。

広告

なぜ実践なのかを考えた@ブレスト祭り

3月 4, 2012

2012/03/03にDevLOVEとhcdvalueが合同開催したブレスト祭りに参加した。
http://kokucheese.com/event/index/28198/

「学びの効果を実感するにはどうするか」ということをテーマに、デザイナーとプログラマが出会ってアイデア出しをしたらどうなるか、という主旨で行われた。

最近は特に勉強会を開催する身として、どれだけ自分を含めた参加者が効果的に学べるか、ということに悩んでいたので、このテーマには惹かれるものがあった。

学んだことの効果が実感できれば、たとえば、勉強会で得た知見を実際に会社でも活かしてみようと思える人たちが増えるだろうし、実践者が集まる場所は魅力的な場になるだろうからだ。

この会に参加してあらためて思ったのは、「フィードバックを得ることが学びの効果を実感するには大切だ」ということだ。

フィードバック重要。そのためのアウトプット

なぜフィードバックが重要だとおもったのか。
そのように思った理由は単純で9名?の人たちとブレストをする機会があったのだか、学んだことをアウトプットすることを学びの効果を実感するために重視していたからだ。

方法は、学んだことのリストを作る、とにかく実践、ブログを書く、人に教える、などのよく聞くものが多かった。
なので、方法について目新しい!と思ったのではなく、僕の気づきは、実践やブログ、人に教える、リストを作るという頭の中のものをアウトプットすること通じて「フィードバックを得る」という目的があるのだ、ということだった。

いままで、学んだことを実践する、ということが学習の効果を実感できる1番の方法だし、学んだことの価値を高める1番の方法だろうと漠然と思っていた。

でも、なんで「実践が1番なのか」という点について深く考えたことはなかった。

しかし、今回いろんな人達のお話を聞いてそれがようやく理解できた。(ような気がする)
実践は頭の中に入れた理論や知識、人の経験と再び出会う機会であり、フィードバックをつうじて理論や知識の再解釈が行う機会になるからだ。

たとえば、人に教えることが学びの実感につながるのも、その行為を通じたフィードバックがあるからだ。

人に教えるときに自分の学びの深さについて実感したり、学びが深まるのは、「何を教えるか」「どう教えるか」などを考えて教材を作っている時だ。

そして、教材を作っている時というのは、内的に自分の学びの深さについてフィードバックをかける効果がある。
たとえば、自分が知っていると思っていることに穴があって、教科書などを調べ直す、ということは結構ある。
もちろん、教えている最中に質問されて答えられない、ということで自分の無知に気づくこともある。

教えるという機会は、自分の知識に自身が能動的に問い直し、問いの結果を通じてフィードバックをかけること機会でもあり、第三者から学びのついてフィードバックを受ける機会でもある。

学びの効果を実感するためにはフィードバックが必要であり、フィードバックをうけるための1番の方法が頭の中にある知識や知見をアウトプットすることなのだ。
そして、実践にはその知識を自分の状況に合わせて再解釈する機会がある。

だから、実践が大事。

とはいえ、実践のハードルは高い。

なので、「すぶり」ができる場が必要だ。
すぶりは、模擬的な体験を通じて学びを活かす場だ。
そして、失敗をしても良い場所だ。
それは、Wikiでいうところのsandboxのようなものだ。

勉強会のワークショップなどはまさにそんな場だと思う。
ワークショップは準備は大変だけど得るものが大変多い。
なので、機会があったらどんどん参加したいし、参加してもらいたい。

今回の企画は、講師の石井力重さんに非常にお世話になりました。
懇親会でもずっと貴重なお話を聞かせて頂きました。
ありがとうございました。

モノのカタチは価値を伝える道具だと思う

9月 5, 2011

少しぼやけてわかりにくいけれど、この写真を見てほしい。

可愛らしいリボンのカタチの絆創膏だ。

デザインに親しむと、デザインはデコレーションとは違うということに気付かされる。
デザインは意図も意味もなく、ものの姿や形を飾り立てることではない。

では、上記の写真のリボンのカタチの絆創膏はどうだろうか。
単に絆創膏をリボンのカタチにすることには全く意味が無いだろうか。

おそらくある。

写真のパンフレットに女の子が掲載されているが、ちょっと見た目を気にする女の子は、普通の絆創膏よりもリボンの形を選びそうだ。

もしかしたら、男の子だって普通の絆創膏をするよりは、リボンの形を選ぶかもしれない。

見た目をちょっと変えるだけで、傷とダサさをイメージさせる絆創膏が、可愛らしい、ポジティブなイメージに変わる。

カタチを変えるというのは思った以上にインパクトがある。

使用する材料がかわったり、同じ材料でも使用する量が変わるかもしれない。

絆創膏だったら材料の切り抜き方が変わるから、切りぬくための型がかわったり、効率良く材料を使うための材料の利用計画が変わるかもしれない。

そして、使う人たち、見る人たちのイメージを変えてしまう力がある。

見る側、消費する側のイメージが変わることで、そのモノの価値が変わることがある。

たとえば、時計だ。

時計は時間を知るものだ。
しかし、一方では富の象徴であったり、美的な嗜好を表現するものとなる。

富を象徴したり、美的な嗜好を表現したりする時計は、「正確な時間を知りたい」という欲求を満たすものではなく、「時間を計算して行動できない」という問題を解決するものでもなくなる。

時計は「目立ちたい、金銭的優位を誇示したい」という欲求を満たすものであり、「見た目が貧弱で軽視されがち」という問題を解決するものになりうる。

機能を変えずに見た目を変えることで、同じ機能をもつものが、別の意味や価値をもつ。

そして、意味や価値を変えることで、人びとその商品を消費する態度を変えることもある。

たとえば、リボンの絆創膏はちょっと高くても子供たちのお気に入りになってよく売れる商品になるかもしれない。

もしかしたら怪我をしていないけど、おしゃれとして自分を飾り立てるために使うかもしれない。

そうしたモノの価値を変える場合に、形を変える、というのは単純な発想かもしれない。
カタチを変えるだけで、それを使う人たちの感覚や体験を変えることはそう多くないかもしれない。

ただ、モノのカタチを変えるということは、そのモノが発信する価値を変えるということがありうる。

普段使うものが少しおしゃれだったり、良いイメージなったりするだけで、消費者の少しだけ良い気持ちになるかもしれない。

カタチを変え、見た目を変えることは、姑息な手段かもしれないけれど、ときにその意味を受け取った人たちの感情や経験を変えてしまう力をもつ。

リボンのカタチの絆創膏は「かわいさ」という、リボン型の絆創膏の価値を消費者に伝える。

その時にリボンのカタチの絆創膏は、単に傷を保護するものではなくアクセサリーとして消費される。

カタチを変えることは、ときにモノの価値を変える力になる。

リボンのカタチの絆創膏を見て、そんなことを再確認した。

エリックとリンダと僕らの世界

4月 15, 2011

Not all of a large system will be well designed
(大規模システムのすべての部分がうまく設計されているわけではない)

4月13日、EricEvansのチュートリアルでDomain Driven Design(以下、DDD)を学ぶなかで、この言葉こそがDDDにおける核心の1つだと感じた。

あまりに大きなシステムは、全体的な調和を保つことはできても、全体をつくる個々のすべてのシステムでは、最適な状態を保てないのだ。

DDDにおいて、このシステム観は重要だ。
だからこそ、汎用サブドメイン、支援サブドメイン、コアドメインの3つにシナリオ(といってよいのだろうか)をわける。
そして、ビジネス的に価値が高いコアドメインに注力する。

必要だけれども、コアドメインとは異なり企業の競争力につながらない、ビジネス価値の低い、汎用サブドメインや支援サブドメインは外部調達などによってまかなおうとする。

自分たちのリソースを、コアドメインに自ら注力することこそが重要だと考えているのだ。

僕はさほど多くのシステムを観てきたわけではないが、「すばらしい設計だ」と思わされたシステムは少ない。

ひどいプログラムや設計で作られたシステムに出会うと、先々起こるであろう、システムのバグの改修や変更への対応を考えて気が重たくなる。

そして、そんなシステムを創り上げた誰かに同情しながらも、腹をたてる。

しかし、僕は大きな勘違いをしていたのかもしれない。

そもそも、僕は、自分の関わるすべてのシステムがユーザーに必要とされ、なおかつ重要だと思い込んでいたのだ。

自分が創り上げようとしているシステムは、DDDでいうところのコアドメインに当たるシステムだと思い込んでいたのだ。

僕はもっと疑問をもつべきだった。

いままで僕が携わってきたシステムのどれだけが、顧客にとってのコアドメインとなるシステムだっただろうか。

そして、顧客にとってビジネス価値が高く、競争力の源となるビジネスを可能とするシステムだっただろうか。

システムを外注するユーザー企業からすれば、会社というシステムなかの、さらにプログラムで作られたシステムの一部でしかない。

そんなシステムを僕はつくってきたのかもしれない。

そうであるならば、僕が携わってきたいくつかのシステムの設計が洗練されたものでないとしても、仕方のないことかもしれない。

それは戦略的に選択されたシステムの姿だったのかもしれない。

もちろん、僕が見てきた大抵のシステムのプログラムの汚さやシステムの低品質さは、それを言い訳にはできないものだったけど。

大規模なシステムはすべてを完璧に設計し、維持することはできない。
DDDはそのことを大前提として、重要な部分に集中するのだ。

大きなシステムは、その全体を作り上げている個々のすべてのシステムに注力し、洗練させることは難しいのだ。

チュートリアルを受けたあと、DDDで学んだ大きなシステムを設計し、創り上げることの難しさを改めて考えさせられる話を聞いた。

その話をしてくれたのは、組織を変化させるために利用できるパターンをまとめた『FearLessChange』の著者の1人、Linda Rising だ。

Ericのチュートリアルのすぐあとに、Lindaと出会うという幸運を得たのだ。

その席で、Lindaから、9.11のあとのアメリカで起こった出来事について聞いた。
9.11において、飛行機が高層ビルに飛び込む姿を繰り返しテレビで見ることになったアメリカの人びとは狼狽した。

結果、何が起こったか。
交通事故により死亡する事件が多発したのだ。

飛行機の乗ることを恐れた人びとの多くが車での移動を選んだ結果だ。
そして、アメリカの人びとが恐れたテロリストたちよりも一般の人びとにより、多くの死がもたらされることになった。

個人が最適だと思った方法は、アメリカという全体では、とても大きな問題を引き起こしたのだ。

この現象から、個々の動きが複雑に絡み合う国家という大きなシステムの姿が垣間見える。

翻って、今、大きな地震の被害をうけた日本もおなじだ。
僕も、大きな地震で一部の地域が崩壊したことで、生まれた歪をみたことで、日本が1つの大きなシステムであることを再確認した。

首都圏で使用できる電力は減り、ヨーグルトやタバコは手に入らず、西日本でも電車の本数が減らされている。

日本は大きなシステムであり、一部の地域の崩壊は、日本という大きなシステムを確実に壊したのだ。

EricやLindaの祖国アメリカがそうであるように、日本も3.11以前に戻ることはない。
日本という大きなシステムで壊れた部分は、元通りなることはなく、確実につくり直される。

ならば以前よりも良くしたい。

そのためにも、DDDがビジネス価値に集中するように、日本というシステムにとって価値のあることに集中して、僕らは日本という国を復興、再構築する必要がある。

そして、日本にとって一番、価値があることを発見するためには、今の日本を前向きに見つめ直して、良い点を探し出す必要がある。

Lindaはいっていた。(と思う。英語が苦手ですんません。)
世界をどのように観るか、それが大切だと。

世界を失望のまなざしで見つめていたら、きっと世界を良くすることはできない。
「なにかよいことはないだろうか」という前向きな心で世界を眺めれば、どこかに希望が見いだせる。

ありきたりな認識論かもしれないが、大切なことだ。

いままで、自分の周囲が平和で満たされていたからこそ、世界のうまく設計されていない部分を見過ごしてきた。

それでいて、失敗が分かりやすい、うまくいっていない部分にだけ集中して批判ばかりをしてきた。

経済も、社会保障も、政治も、スポーツも、うまくいっていない部分をあげつらい「日本はダメだ」と言ってきた。

もうそろそろ、世界のすべてがうまく設計されていない、設計されない、という現実に目を向けるときだ。

しかし、その現実に失望するのではなく、前向きで希望をこめた視点で注力すべきところを探す。

すべてにおいて良くあろうとするのではなく、自分たちがより良く生きるために、どこに注力するべきかを戦略的に選択し、注力する。

DDDというシステム設計と『FearLessChange』の著者の考え方から、システム開発の領域を超えて、これから僕が世界とどのように関わってゆくべきか、生きるための知恵を学んだ。

必要かつ重要なデザインを仕事にする

4月 12, 2011

5年後にはシステムデザイナーと呼ばれ、仕事をしているようになりたい。
本日をもって30歳になった僕の夢だ。

もしかしたら、僕がなりたい職業は、アーキテクトという存在なのかもしれない。
でも、僕はシステムの設計を専門として活躍できる存在なりたい。
だからこそ、既存のアーキテクトという言葉ではなく、システムデザイナーと名乗りたい。

3月11日の東北・関東大震災は、自らを振り返る機会になった。
東京ではらたき、千葉に住まう僕も被災者だった。

もちろん、津波に家をのまれ、炎に家を焼かれて、命、家族、帰る場所を失った人たちとの温度差はある。
僕には疲れたり、落ち込んだりすれば逃げ帰れる家がある。
しかし、東北で大きな被害を受けた人びとの多くは、帰る家も、慰めあう家族もない。

ただ、生まれて初めて経験した大きな地震に僕は命の危機を感じた。
そして、人生、とりわけ今の仕事の価値を見つめ直すようになった。

自分の今の仕事に価値はないのではないか。
今後、本当に今のままの仕事をつづけてゆくだろうか。
そもそも仕事という存在は自分のなかでどのような存在感をもつのだろうか。

今でも悩んでいるし、考えている。
自分がいったいなにがしたいのか。

そんなもやもやを抱えて、2011/04/9(土)にDevLOVEのDDD(Domain Driven Design)のイベントに参加した。
そして、印象深い2つの言葉に出会った。

1つは「世界を端的に変えるのは政治家かデザイナーかディベロッパー」
もう1つは「実装は必要。設計は重要」という言葉だ。

僕はこの2つの言葉を聞いて、デザインとそれを専門とするデザイナーの重要性を改めてかみしめた。

デザイナーは世界を変える。
そして、世界を変えるのはデザインという企てだ。

システムの世界において、プログラミングとプログラマは王様だ。
社会的な地位や評価は別として、情報システムの開発に携わる人々にとって、優れたプログラミングのスキルとそれを実践するプログラマは憧れの的だ。

プログラマやプログラマに憧れる人々にとって、いわゆる上流工程にのみ関わり、要求定義や基本設計しか行わない、プログラムに見向きもしないエンジニアは軽蔑の対象だ。

そんな人びとからみれば、デザイン、設計に大きな価値をおいた「実装は必要、設計は重要」という言葉には違和感をもつかもしれない。
しかし、この言葉は事実を表現している。別に実装を軽視しているわけではない。
実装、すなわちプログラミングとは、優れた設計の実現なのだ。
だからこそ、設計が重要なのだ。

そしてまた、設計は実装に制約を受ける。
実現方法によって、デザイン、すなわち理想の姿が制限を受けるのは当然のことだ。
だからこそ、デザインに携わる人だったら、実現方法であるプログラミングを知らない、という状況は許されない。

制約があるなかでいかに目的を達成するか、ということもデザインの1つの要素だからだ。

なにより、優れたプログラマは、実現方法のプログラミングのみならず、実現すべき姿を描くデザインの能力も優れている。
だからそ、優れたプログラマが産み出したプログラムは、価値がある。

僕は優れたプログラマではない。
そう名乗るには圧倒的にプログラミングの経験が少ない。

だから、優れたデザインを生み出すために、僕は歯を食いしばりながらプログラミングを勉強する。
もちろん楽しめればそれに越したことはない。
ただ、今の自分ではプログラミングを楽しむまではないかない。

そしてまた、僕はシステムのデザインについて勉強する。
こちらも歯を食いしばりながら、になるかもしれない。

なにより、協力してくれる人たちを巻き込んだり、お金を集めたり、プログラミングとデザイン以外のさまざまなことをできるようにならなければいけないかもしれない。

イバラの道かもしれない。

ただ、僕には2つの言葉にもらった信念がある。
迷いながらも、信じられる言葉がある。

情報システムは、世界を変える力をもっている。
そして、そのシステムをデザインするとは、世界をかえる企てだ。

システムのデザインを通じて世界を変える。
システムデザイナーという存在に、いま僕はなりたいと思っている。

デザイン思考ワークショップで富士ロック子さんをつくった@DevLOVE

7月 25, 2010

最近、勉強中のデザイン思考について、昨日(2010/07/24)、DevLOVEでワークショップが開催されました。
ワークショップの講師は、棚橋弘季さんでした。
『ペルソナをつくってそれからどうするの?』や『デザイン思考の仕事術』の著者としても知られている方です。

最初に「デザイン思考とはなにか」という説明を棚橋さんから受けました。
デザイン思考によるプロダクトの作成においては、ペルソナとシナリオの2つ成果物が大きな役割を果たします。
ペルソナというのは、つくろうと思っているプロダクトや解決しようと思っている問題に関わる「仮想」の人物像です。
一方、シナリオというのは、「仮想」の人物がプロダクや問題の状況下においてどのような行動をとるか、を考えるものです。

今回のワークショップでは、旅行サイトの集客を増やすことを目的としたサイトリニューアルを想定し、ワークを行ないました。
大まか流れとして、まずは3人の実在の人物の調査結果から2人を選択し、1人のペルソナを考え、シナリオを抽出します。
情報の抽出と整理には、KJ法を使用します。
その後、KJ法によってペルソナとシナリオを活かしながら、理想となるサイトについてペーパープロトタイプを作成し、終了、というものです。
だいたい1チーム5から6人に分かれて作業を行ないました。KJ法は以下のように壁に大きめの用紙を張っておこないました。

その分析の結果、私たちのチームはいかのようなペルソナを作成しました。

富士ロック子さん
-ライブ好きでネット好き
-アイスクリーム作りが趣味
-ライブがゆくのが目的で旅行する
-時間があって興味がそそられたら観光名所もゆく
などいうペルソナを作ったのですが、この時点ですでに講師の棚橋さんからは「アドバイスできない。笑」と言われてしましまた。

というのは、3人から2人を選択した時点で、あまりにも共通項の少ない人物を選択したために、2人の人物像がうまく統合できなかったためです。
ちなみに、課題終了後には、このペルソナづくりは非常に重要で、ここの誤りはプロダクトでは取り戻せない、というお話がありました。
考えてみると、ペルソナを作成されると、このペルソナ(富士ロック子さん)へ向けて、プロダクトを作成するのですから、当たり前ですね。
ということで、私たちのチームは、この失敗ペルソナ、富士ロック子さんの呪縛から逃れることはできず、ちゃんとしたプロダクトを作ることができなくなってしました。
ただ、個人的には、KJ法を使用して富士ロック子さんを作成するくだりが一番、面白かったのですが。

ちなみに、本来のプロダクトを作成する際には、実在の人物の調査は5人程度、この調査結果をKJ法により分析すると、分析だけでも1日ちかくかかるらしいです。

その後は、抽出したシナリオからユーザー(富士ロック子さん)要求や要求を満たすためのコンテンツを考える作業に移りました。

ユーザーの要求については、作成したペルソナや抽出したシナリオからあまりにも離れすぎてしまうと、ごくごく一般的なプロダクトになってしまいます。
こうなるとペルソナやシナリオを作った意味はなくなってしまいます。
と同時に、あまりにペルソナにこだわり過ぎると、偏ったプロダクトが生まれそうな恐怖もあります。
実際に、私たちのチームは、そもそも富士ロック子さんが偏ったユーザー像だったために、プロダクトが偏ったものになりました。
良いペルソナやシナリオがないと、よいプロダクトを生むことができないのでしょう。

最後に、上記で抽出した要求から考えだされたコンテンツを元にペーパープロトタイプを作成しました。

ペーパープロトタイピングは楽しんでやることが重要ですね。
あんまり「絵ごころないしなぁ」とか考えてやってもプロトタイプが作られませんし、作ってゆくたびにうまくなってゆくはずです、きっと。

以上が、私たちのチームで作成したペルソナ、シナリオ、ペーパープロトタイプです。
これらの一連の作業は、思ったよりも疲れると同時に大変楽しいものでした。

と、これだけで終わってしまうのはなんので、ワークショップを通じて学んだことを以下にまとめます。

<エンタープライズでもペルソナを書く意義はある>
ペルソナやシナリオを作成する価値はどの程度あるのでしょうか。
iPodのようなクリエイティビティあふれる商品を生み出したい、と考えるのならいざしらず、エンタープライズなシステムを開発するうえでどれほど価値があるのでしょうか。
想像の段階ですが、価値の1つに教育のコストの低減が考えられます。

棚橋さんいわく、デザイン思考の目的の1つは、イノベーションを起こすこと、すなわち、新しい価値観や生活の様式をユーザーに提案することです。
デザイン、としていまappleなど注目を集めているのは、この点についてでしょう。

そして、もう1つの目的は、ユーザーの”?”、疑問をなくすことです。
たとえば、なにかの道具、アプリケーションを目の前にしたユーザーが「いったいどのように使えばよいのだろう?」という疑問をなくす、これは非常に大切な事です。
というのは、エンタープライズ向けのシステムを刷新すると、今まで使い慣れていたシステムを捨てなければならないからです。そして、新たなシステムを使用するためには、その使い方を覚えなければいけません。
システム屋の目線からは、そのほうが情報管理もシステムの構成もすっきりと使いやすいシステムを作ったつもりなのですが、それを使うユーザーからしてみると今まで使い慣れていたシステムが使いづらいものになってしまうのです。
そのために、ユーザーの側では教育期間をもうけてシステムの使用方法をユーザーが覚えなければならず、システム屋は(システム屋の)みんなが嫌いなドキュメント作業にとりかかり、それほど質の高くない操作マニュアルを作らなければいけません。

現状、こうした教育コストを減らす試みの1つは、「元のシステムと同じ画面」で作る、というものです。
たとえば、汎用機上に載っていたシステムを、マイグレーションする際には、使い慣れているように「TAB」と「ENTER」で移動し、マウスでのクリックは出来ないようにするのです。
たしかに、それも1つの手段ではありますが、たとえば今年、新入社員で入ってくる人にとっては、操作方法がほとんどわからないでしょう。

新入社員、にフォーカスをすると、既存の社員との相対的な数は少ないうえ、教育費もある程度、見込まれているので教育という観点からは痛手を感じることはないかもしれません。
とはいえ、今後はダイバーシティという価値観から、目が見えないなどのハンディを抱えた人やそもそも日本語を母国語としない人々が増えたり、一斉、定期的な新卒採用がなくなったりした場合は、スキルセットも経験もバラバラで、一括で教育を施すことが難しくなってゆくでしょう。
そうなると、システム屋が書いた分かりにくい日本語のマニュアルをポンっと渡して、「使い方を覚えておいて」などとは言えなくなります。現在でも、そのようにできない部分はやはり先輩社員や上司が、その目的と使い方を教えなければならないのです。

そうしたちょっと遠い未来においては、誰でも直感的に使用方法がわかるシステムは教育のコストを減らすためには有効なのではないでしょうか。

ただ、「誰でも」というのは、ちょっと曲者な言葉です。
受託開発のシステムにおいては、法律など各業界の標準に則る必要がありますし、各会社の業務に則る必要があります。
もちろん、業務についても業界における標準のようなものがあるのですが、標準を越えた独自の部分は存在するのです。
その独自の部分を取りこぼさないことが、ユーザーのシステムの使いやすさに、通じるのだと思います。
なぜなら、その点が他の人たちにはなにその人達が固有に抱える問題であり、共有している価値観であるからです。
そして、その問題を解決し、価値観に訴えることが、使いやすさに通じると思うからです。
そのため、やはり「誰でも」というよりは、ターゲットとする「誰か」に届ける必要があるのです。

たとえば、教育のコストを下げるため、直感的に使いやすいシステムを、考えても、

・PCをよく利用する人なのか、全く使用しない人なのか
・業務知識がある程度ある人なのか、ない人なのか
・席に座ったま使用するのか、工場や売り場などでたったまま使用するのか

など、システムを使用するユーザーの使用状況や知識レベルを理解する必要があります。
ペルソナやシナリオはこうしたユーザーの行動や性質を理解するために作成されるのです。

棚橋さんの言葉で感銘を受けたのは、

同じものでも使用状況によって価値が変わる

という言葉です。
そのために、ユーザーが一体どのような人たちで、どのような状況のおいて使用するのか、をインタビューなどのユーザーへの調査やKJ法による分析、そして、ペルソナとシナリオをづくりと通じて理解するのです。
そして、こうした理解の先に、システムのコンセプトが生まれます。
ワークショップでも、どのようなユーザーに向けて、どのようなシステムを作るのか、というコンセプトを、ペルソナとシナリオを描けたチームのペーパープロトタイプは、しっかりとしていました。
ちなみに、ペーパープロトタイプの良さは、「たくさんの質問、疑問が発生すること」だそうです。
そのようなペーパープロトタイプは、ワークショップでは1チームしかできてきていませんでした。

情報収集→KJ法による分析→ペルソナ・シナリオづくり→プロトタイプの作成→プロダクトの作成、という流れの中では、1つ1つの作業が重要になります。
そして、前段の失敗は、後段ではなかなか取り戻すことできません。そのためにも、早めの失敗が重要です。
ペーパープロトタイピングはまさに、失敗に早く気づくための方法の1つでしょう。
また、直接、触れられてはいませんでしたが、安上がりに失敗する、という視点も必要なのでしょう。
早めに失敗しても、その時に大金を失っていては、失敗を取り戻すことはできません。
紙を使う、というコンセプトが、安上がりに失敗する、failcheapという観点を含んでいるのだと思います。

また、デザイン思考において、固定的なプロセスはない、と棚橋さんはおっしゃっていました。
なんだか、アジャイル開発に通じるものがありそうです。
ということは、知ることは簡単でも実践は困難ということでしょう。
今回、ペルソナ作りに失敗したことは、難しさに触れることができた、良い経験なのだと思います。

ランキング参加中。気に入ったら一押しお願いします!
人気ブログランキングへ