よみかきをしよう。

たくさんよんだりかいたりしようとおもいます。

常葉大学未来デザイン研究会体験型展示会 出張ラボ「プロジェクトを報告します」にいってきた

UXD イベント 日常

https://www.instagram.com/p/BQFYKMGARqp/

産官案件にサービスデザインのプロセスを持ち込んだものや、卒業制作として自ら問題視した事柄の解決をサービスプロトタイピングで図ったもの、その他自主活動として実施したフィールドワークの報告など、各種プロジェクトのポスター発表が会場全体で行われてた。

配布されてた冊子にも表記されてた通り"クリティカルにプロトタイピング"するためのプロセスを体現している。特に"リサーチ（をする際の枠組みのつくりかた）"と"そのリサーチ結果の可視化＆分析"が見事。面白そうな経験をしていて、羨ましささえ覚える。

＊

会場でコーヒー飲みつつ数名で雑談してて、「年取っても完璧になんて出来ないし、むしろ出来てないと思うことが増える（意訳）」みたいなこと話してて。

これ聞いてて、マーク・ザッカーバーグが掲げたことで有名な "Done is better then perfect." って標語はまあ真理だよな、と改めて思ってた。

完璧にしなくても要件満たせることが多い。プロトタイプはそういう意図でつくるし。
ひとりで完璧に振る舞う必要はなくて、困ったら助けを求めればよい。そのために組織化しているし。
失敗したって死にはしない。その仮説では効果が出なかったことを証明できた、という成果が出たわけだし。

まあ自戒も込めてやな( ˘ω˘)

Fwd: UXデザイナーが直面する、体や心を壊す状況について

考えてること UXD PdM

（過去に雑に書いたやつ、雑に公開しておく。）


takoba [3:09 PM]
クオリティとスピード感はトレードオフだし、そのクオリティを担保するための作業量には上限があるはず。その状況下で都度「このチームでいま何をすべきか」を取捨選択して進まなくてはいけない。
全部自分でやろうとするならシーケンシャルになるだけだし、チームでやるなら適切に分担しつつやるだけだし。どっちにしろ優先順位つけなくちゃ動けないし、その辺の段取りをそういう視点を持った人（これをUXデザイナーとかっていうのかな？）が取り扱うんだろうなあ (edited)

takoba [3:15 PM]
UIとかUXとか言われてるけど、結局は「よりよいプロダクトをつくるためには、気にしなくちゃいけない部分って実はめっちゃあるんだよね」ってのがベースにあって、その中にUXとかUIとかって概念が転がってる。 (edited)

[3:15]
全部を一気に網羅するのなんてツラいだけだし、だからLEAN UXとかは"ひとつの仮説を検証するサイクル"に終始して説明してたりする。

[3:17]
そのくらいの粒度から取り組んでいかないと草の根活動は厳しい。何度か仮説立てて検証してみたらヒットして、そういう経験（ノウハウ）を積むことで「これくらいやれば当たるよね」みたいなところを掘り当てないといけない。 (edited)

[3:18]
草の根活動って、要は投資をもらうためのひとつのプロセスだ。大きいことをするためには、小さく成功させてそれがスケールする可能性を示してみせることが大切だ。スタートアップ感。

[3:18]
まあ、力を割くポイントがちょっとよろしくない印象を受ける。ちゃんとプロセスを噛み砕いて、どこに力を入れるべきかを整理しなくちゃいけない。これは自戒でもあるな...

第19回情報デザインフォーラムにいってきた

UXD イベント デザイン

https://www.instagram.com/p/BFIeemgmVNm/

デンマークへ1年間サバティカルしてらっしゃった上平先生のお話を聴きたかったのと、「新しいデザイン教育」と題された内容が気になったので参加してきた。

上記みたいなことを書いたけど、"そういう話題が多かった"というより"DesignしたものをBizとして世に出すためのヒントが多かった"感覚。

日本とデンマークとの"リスクテイキング"の違い

コペンハーゲンは港町であり、運河も発達している。そのため、水上バスが主な交通機関として数多く運営されている。
そんな街でレンタサイクルのように提供される、ライセンス要らずのレンタルボート。めっちゃたのしそう。

一方では「ライセンス要らずで本当に大丈夫なの...？」「お酒飲みながら運転？そんなことさせて大丈夫？？？」みたいな疑問も浮かんでくるよね？ってお話。
その一方で、太陽光を用いた"カーボンニュートラル"なモーダビリティとして捉えると、水路が多いコペンハーゲンにおいては、なるほど持続可能なソリューションだ、とも言える。

他にも廃棄物を利用したレストランなどが例に挙がってて、こちらも「衛生的に問題ないの？」みたいな疑問が浮かぶが、その一方で「食物が大量に廃棄されてしまう」問題に対するひとつのソリューションとも言える。


「このアイディア、こういう問題が孕んでるから止めたほうがいいんじゃない？」みたいなことって割とよくあると思うけど、その場合に そのアイディアが孕む問題を"どのように解消するか" を問うだけではなくて、 そのアイディアが孕む問題と"どう付き合っていくか" を問うこともできるんだなあ、と思った。

"参加型デザイン"という言葉のニュアンス

参加型デザイン（Participatory Design）がスカンジナビア半島発祥であることは聞いたことがあったけど、「元々は労働者の社会運動が起源である」みたいな文脈のお話ははじめて聴いた。

参加型デザインを簡単に解説すれば，デザイナーだけでデザインするのではなくて，実際の利用者をデザインプロセスに積極的に巻き込みながら進めていくアプローチのことで北欧で40年ほど前に始まった取り組みである．ちなみにベテラン研究者の方々曰く「本当の意味でのParticipatory Design（参加型デザイン）とは，スカンジナビアの社会民主主義のカルチャーによって成されたもので，我々のやっていることだけが正統派なのだ」と誇りをもって主張しているし，一方で若手は「元々は"自分たちの働く職場なのに，その職場の改革に参加出来ないのはおかしいだろう"という異議申し立ての労働運動から発するものだし，参加するのが当たり前でなかった時代に参加を希求した時の言葉であって，今となっては過去の遺産だよ」となんだか微妙な反応をすることも多い．実はデザインという概念も産業革命に対する異議申し立てから始まっている（という通説）と重ねて考えると興味深い．なお彼らも人々と共にデザインするアプローチ自体を諦めてしまったわけではなくて，当時とは時代背景も変化しているし，Participatory Designという言葉では反体制っぽいニュアンスが強すぎるということなんだろう．

参加型デザインという言葉について - Kamihira_log at 10636

"実際の利用者を〜"みたいな "co-design"的な形式は、英国発祥のインクルーシブデザイン（Inclusive Design）って考え方と近しいけど、こちらは高齢者を対象にしたデザインの中で生まれている。なるほど、面白い。

利用者を巻き込むデザイン手法ではあるが、"利用者がデザインを決める"わけではない。
「デザイナーが利用者からの意見を取り入れ、デザイナーが決裁者に提案する」という構造を持っており、このあたりが語られているのは労働者運動をルーツとしている影響なんだろうな、と感じた。

その他よさそうなお話

大本綾さんがクリエイティブリーダーシップについて解説してくださってるときに書いたやつだったかな。


これは山崎先生がおっしゃってたけど、要するに"インプットとアウトプット"的なことですよね。
インプットするだけじゃダメだし、アウトプットの説得力って過去のインプットが繋がってる、みたいな。

おわりに

https://www.instagram.com/p/BFJNe-IGVNY/

魚真の底力を感じる"のっけ盛り"。どうぞご査収ください。

参考

「ものづくりに集中せよ！」

クリエイティブ 考えてること

先日書いたエントリ に関連して。

CA卜部さんのこのエントリはいまでも心に鋭く刺さってる。
何度も読み返して、その都度己を振り返りたくなるエントリ。

http://ameblo.jp/urabehiroki/entry-12018161265.htmlameblo.jp

続きを読む

「作りたいのはプロダクトだから」ってのがグッときた - 「UI Crunch #8」にいってきた #uicrunch

Web イベント エンジニアリング デザイン クリエイティブ

https://www.instagram.com/p/BELW47nGVIq/

というわけで、いってきました。

UI Crunch #8 UIデザインに求められる実装スキルと考え方 - connpass

しれっとブログ書く枠が1名分空いてたので、滑り込んだやで٩( ‘ω’ )و
とはいえ、詳細な議事録とかは以下のエントリに任せて、思ったことを書きます。

sd-ts1017.hatenablog.com

「作りたいのはプロダクトだから、自分で書いた方が効率的に目的に近づけるのでは」*1

"「UIデザインをする上で、実装するスキルもデザイナーとして求められてくるよね」という前提のもと、先駆者にお話を聞いていく"というスキームで展開されてった今回ですが、割と「デザイナーとエンジニアの垣根を超える」みたいなセッションが多かったです。
UIを"実装する"ことに苦手意識を持っているデザイナーも多い、という背景があることを想定してるんだと（勝手に）思ってます。

そんな中、各セッションを通して「今回はこれに尽きるなあ」と個人的には思った。

Wantedly青山さんのセッションでご紹介されたコメントなんですけど。
これ聞いて、「ぼくがエンジニア職として会社に属してるの、まさにこれが理由だなあ」とめっちゃ腑に落ちた。

プロダクトの細部にこだわるにはエンジニアリングの知識をそれなりに持っていないと、"より良くしたいこと"を実現できない場合があるよなー、って思うんです。*2
逆に考えると、そういうデザインはエンジニアにだってできる。そういうところに気付ける視点を持ってプロダクトをつくらなくちゃなあ、と改めて感じました。


プロダクトをつくる上で、すべての工程をそれなりに理解できると便利

DeNA成澤さんのセッションを聞いて。
以下でも紹介されてるように、Xcodeでプロトタイピングまでやってるそうな。

creator.dena.jp

スライドの中で、デザインタスクと実装タスクとの配分を3つのフェーズに分けて説明してたんだけど、最後の3つ目のフェーズではデザイン/実装を両方やってるのに、効率が上がってたんだよね。
（画像がなくて恐縮... 後日スライドから拝借したく...！）

デザイナーが実装するスキルを身につけたり、エンジニアがデザインを理解することによって、こういうロスを徐々に減らせるし、「ここはこういう状態にしてデザイナー/エンジニアに渡したほうがよいよね」みたいな発想もどんどん生まれるはず。
そうすると、もっとプロダクトの本質を磨き込むのに時間が使えるようになると思うんですよね。

これ、デザイン/実装に限らない話だと思うので、もっとプロダクトをつくる工程（"誰がどう考えて、何をしているのか"）を理解することに努力を惜しまないようにしたいな、と思った次第です。

デザイナーもエンジニアも、CSも営業も企画もみんなプロダクトをつくる人ですよね

で、以上のことを考えてると、ふと以下のことを思い出したんですよね。

b.hatena.ne.jp

これ、めっちゃよいなって思ってます。
プロダクトはデザイナー/エンジニアのものだけじゃないし。みんなでつくっていきたい。
いま、個人的に理想に掲げてるチームです。

おわりに

今回のテーマ、元々考えてたことと結構近かったりして、めっちゃ共感すること多かったです。

とはいえ、実際に実現するのはなかなか難しい...
貴重な実践事例を聴くことができて、とても実りがありました( ˘ω˘)


＊

地震、ヒカリエにいたら全く感じなかった。
とりあえず、友人の実家が無事だという報告をちらほら目にして安堵してます。
被災された皆様、くれぐれも二次災害にご注意くださいませ。

*1:タイトル修正するのわすれてたので修正した 2016/04/15 09:50

*2:デザイナー/エンジニアってラベルは「あくまでどの職能が得意か」ってだけだと個人的に思ってます。いずれにせよ、みんなでひとつのプロダクトをつくってるんですよね。「デザイナー/エンジニアは、そのラベルに沿った職能だけ担当していればよい」なんて考え方だと、これからは淘汰されていくんじゃないかな、と個人的には思います。