CXDIVE 2018: 森ビル 杉山さんと チームラボ 猪子さんのセッション「チームラボ・ボーダレスで目指した、これからの顧客体験」

お台場にオープンしたteamLab Borderlessというデジタルアート施設についてのセッションで、森ビルは「東京を世界一の都市にする」というミッションを掲げており、世界で活躍するチームラボのアート作品を東京で見れるようにすればより大きなインパクトがあるのではないかという想いと、新たなアート作品を作るためには巨大な常設施設が必要という考えがあったチームラボとのマッチングによってteamLab Borderlessは生まれたようです。

 

borderless.teamlab.art

 

コンセプト正しく理解してもらえるかでCXは変わる

この施設が出来上がって、最初に関係者に対してお披露目したときに行ったアンケートでは結構不評が多く、その理由は「経路がわからずに迷ってしまう」「作品がどこにあるのかわからない」「知り合いが見たという作品が見れない」というものだったらしい。しかし、このアート作品のコンセプトを理解してもらうために入り口に「Wander, Explore and Discover ~ さまよい 探索し 発見する」というメッセージを入れると多くの人がコンセプトを理解して不満だった点がむしろ楽しい要因となるように顧客体験が変わったそうです。

 

f:id:arakaji-yuu:20180911094808p:plain

 

アーティスト側としては意図して作ったものでも、理解してもらえないとCXとしては不満に変わることもある。ただ、正しく理解できるようなアプローチをとる同じ事象でも良いCXとなるという面白い事例でした。

 

デジタルアート x 沖縄という可能性

このセッションを聞きながら僕が個人的に考えたのはデジタルアート x 沖縄の可能性でした。

沖縄はアジアの観光地として立地的も文化的にも大きなポテンシャルがあるが、そこにテクノロジーとアートの最先端が感じられるデジタルアート作品が見られるような施設・イベントなどがあれば観光資源としての可能性が高い。

 

あと個人的な想いとして「沖縄を観光客だけでなく、クリエティブクラスがいきいきと活動できる島にしたい」というのがあり、ただ観光客が集まるだけでなくモノやコトを生み出す人たちが集まり、その人たちが作るモノでまた人が集まるというサイクルを作れたらより面白くなるんじゃないかと考えており、その意味でもデジタルアートの可能性にはとても惹かれました。

 

いまはアプリケーションエンジニアとしてしか活動できていないですが、デジタルアートという分野も覗いてみたい、挑戦してみたいと思えたセッションになりました。

 

プログラミングの開発効率を上げて速く実装するには

 

 

 

 

 

 

JavaKuecheリモートもくもく会をして、子育てしながらも学び・コミュニティ活動をやる形のヒントが見えてきた。

JavaKuecheでほぼ週一木曜日にリモートもくもく会というものをやっています。

 

もくもく会というのは、特定の場所に集まってそれぞれが好きなことをもくもく作業して、最後に成果報告をするというような小さいミニ勉強会のようなものです。

 

ただJavaKuecheのメンバーはいま県外にいる方がいたり、僕は子供がいるのでなかなか夜外に出づらいということで、そのもくもく会をリモートで行っています。

 

やり方はというと、appear.inというビデオMTGのWebサービスを使って参加者をつなぎ、そこで集まって今日やることはじめに宣言し、もくもく会の終わりにまた成果報告をするという感じで進めています。

 

19:30から行ったのですが、ぼくは19:00から子供のお風呂に入れてご飯を用意し、19:30にイベントが始まると最初の挨拶だけして子供の食事に戻り、19:45からまたオンラインに戻ってもくもくを開始するという風に参加しました。

 

このように子供相手をギリギリまでやりながらも勉強会に参加できるのは、リモートでやる最大のメリットです。

 

僕は今回、自分が開発しているCollaboというプロジェクト共有サービスがまだスマホ対応していなかったのでそれをこのもくもく会で対応しました。

前はPC画面しか用意していなかったのですが、いまはスマホでも使えるレベルのデザインにできたと思います。

 

www.collabo.fun

 

僕以外の参加者の方はカイゼンジャーニーという本を読んでいた方がいてその内容をシェアしてもらったり、Google Colaboratoryを使って統計分析の勉強をしていてその話をシェアしてもらったりしました。

自分がいままで興味をもったことがないことに取り組んでいる人の話を聞いて、情報のインデックスが付けることができるのも、一人でやるのではなく誰かと一緒にもくもく会をするメリットでもあります。

 

カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで

カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで

 

 

Google Colaboratory

https://colab.research.google.com/notebooks/welcome.ipynb

 

子供ができて子育てしながらも、エンジニアとしての学びのサイクルを作ったり、コミュニティ活動したりするというのはいまの課題でもあるのですが、「リモート勉強会」というのはその解決策になるとだんだん思えてきたので、もくもく会以外でもリモートで参加できる勉強会・コミュニティ活動を自分のためにももっとやっていきたいと思います。

 

 

3ヶ月後の未来のために今日の自分を生きてみる

自分はとても意思が弱い人間で、ほんとはもっと勉強したいしもっとコードを書きたいし子どもや家族のために時間を使いたいしその他のやりたいことがあるのに、昨日はなぜか進撃の巨人の漫画を夜11時から一気読みして深夜3時まで起きてしまった。

ほんとにやりたいこと、やるべきことがあるのに、いまの感情・衝動を優先して正しい行動ができていない...

それを解決するために「3ヶ月後の未来のために今日の自分を生きてみる」というのをやってみたいとおもう。

今日の自分の行動は、3ヶ月後の未来のための投資である。

今日の自分がここにあるのは3ヶ月前の自分の行動の結果である。

そう考えると、重要な行動を正しく評価し実行できるような気がしてくる。

3ヶ月という期間は、自分がリアルに想像できる未来の上限がいまのところ3ヶ月が限度だからだ。

IT業界で、かつベンチャー企業、スタートアップ企業にいるという職業柄か、あまりに変化のスピードが早くてそれより先の未来がいまの自分の力だと想像できないからだ。

そしていま、3ヶ月後先の自分がちゃんと楽しめるように進撃の巨人の26巻を予約注文してあげた。

進撃の巨人(26) (講談社コミックス)

進撃の巨人(26) (講談社コミックス)

「デザイン思考」のワークショップで学んだユーザーインタビューを実践してみた。

前回ブログでも書いたんですが、ワークショップで「デザイン思考」について学んだので、そこで重要だと学んだ「ユーザーインタビュー」について実践してみました。

ちなみに前回の記事はこちら。

Okinawa Dialogのデザイン思考のワークショップに行ってきました。 - ゆーじのろぐ

今回は自分が現在開発中のプロジェクト共有サービス「Collabo」について、実際非営利組織で人材育成やイベント運営を行っている方にインタビューさせていただきました。

具体的な質疑応答内容は差し控えますが、Collaboの核である「だれでも見えるオープンな状態プロジェクト管理をおこなう」ということについてはあまり魅了を感じていないことがわかりました。

ユーザーインタビューを通して再認識したのが、そもそもクローズドないまの状態で必要な人にLINEのグループやFacebookメッセンジャーに入れてその中でコミュニケーションとるということで十分で、それをわざわざオープンにすることで発生するリスクを考慮するとメリットが見えないということでした。

また、やはりフルオープンにすることには大きな問題が発生しうるので、細かな権限管理の重要性に気づきました。

今回のインタビューについてわかったことをまとめると以下のようになります。

  • オープンにするということ自体には少し興味がある。
  • しかし、デメリットを超えるほどのメリットが見えない(情報統制、既存ツールで事足りている)
  • オープンにしていいものと、してはいけないものを細かく管理できる権限管理は必須
  • オープンにしたことによるインセンティブ設計が必要

特にプロジェクトをオープンにすることによるインセンティブは改めて重要だなと気づきました。

よくCollaboを説明する上で「ソフトウェア開発におけるオープンソースの文化のように、様々なプロジェクトに誰もが参加してコラボレーションを行えるようにする」という風に説明するのですが、ソフトウェア開発においては、そもそもオープンにしないと使ってもらえないだとか、バグ報告だけでなくバグ修正などもオープンにすることで得られるなどの、オープンにするインセンティブがすでに設計されていることに気づきました。

Collaboで運営されるプロジェクトにおいても、そこで運営することによる明確なインセンティブを意図的に設計して組み込んでいかないといけないので、これは当初思い描いていたよりも難しい課題だなと再認識しました。

Collaboにおける課題は「既存ソフトウェアを超える利便性」、「オープンとクローズドを簡潔にコントロール可能にする」、「オープンにプロジェクトを行うインセンティブ設計(ブロックチェーン・トークンエコノミーを取り入れる？)」ということが、今回のユーザーインタビューで見えてきたので、やはりやってみてよかったと思います。 今後のプロジェクトにおいてもデザイン思考を取り入れた開発プロセスをどんどん回していきたいとおもいます。

Okinawa Dialogのデザイン思考のワークショップに行ってきました。

Facebookフィードにデザイン思考に関するイベントがあることを知り、興味があるにはしていたが実際申し込んではいなかったんですが、朝起きて台風の暴風域を抜けたということを知り、せっかくなので行ってみるか！と当日に申し込みして参加しました。

デザイン思考 〜ユーザー中心のプロダクト開発〜

サンフランシスコにて大企業や企業家向けにユーザー中心のものづくりやピッチ指導をしているという我那覇若菜さんが講師となり、そもそもデザインってなんだっけ？デザイン思考っていうのはどういうこと？デザイン思考を用いてものづくりや改善プロセスのやり方について学びました。

デザインとは？

デザインとは「目的のための計画そのもの。常にヒトが中心にあり、誰かの生活を豊かにしようとする」というもの。

あとデザインには４つのレイヤーがある。 - グラフィクデザイン - インダストリアルデザイン - インタラクションデザイン - エンバイラメンタルデザイン

Web制作の現場にあるデザイナーとかだとグラフィックデザインをやっているヒトが多いと思うけど、それはデザインの一部で、問題を解決するためにその問題が発生しうる環境自体をデザインするっていうのもデザイナーの領域らしい。

超一流デザイナーは、かなり広範囲な知識とスキルが求められるな。

デザイン思考とは？

デザイン思考とはなにか？という話でもちろん問題解決するためのプロセスは教えてもらったが、まずマインドセットを変えることが何より重要ということに言っていました。

まず「共感」する

まず、ユーザーに「共感」し、相手の話を聞きながら、そのヒトがどのようになぜ行動するのか？ニーズはなんなのか？などのインサイトを得ます。

このとき、「同情」ではなく「共感」するように、と強調していて、同情は「かわいそう〜」と相手の気持ちを推測して終わるが、共感は「悲しかったね〜」とホントに相手の気持ちに成るような違いがあるそうです。

問題定義

そのヒトに共感してインサイトを得たら、次は本質的に何が問題なのかを見つけ出す「問題定義」を行います。

アイディア出し

「問題定義」された問題に対しての解決策をともかく質より量でどんどん出していきます。 そのときのコツとして、否定しない、実現性を考えずぶっ飛んだ発想をする、ポストイットに書き出して視覚化する、アイディアは文字だけでなく絵でも書くなどがありました。

プロトタイプ化

アイディア出しで挙げられたものから選定して、プロトタイプを制作します。 このプロトタイプは出来るだけ低コストでかつすばやく作れるものにすることにより、様々な可能性を試せ、かつ時間と経費の節約になるそうです。

テスト

試作したプロトタイプについて、実際のユーザーにユーザーテストをしてフィードバックを得ます。このプロセスによって、そもそもの問題定義が間違っていないか、また解決法としているアイディアが間違っていないかなどを検証できます。 もし、方向性があっていればもう少しプロトタイプの精度を上げていく。 アイディアが間違っていれば違うアイディアでプロトタイプをしてユーザーテストする。 問題定義が間違っていればそこからやり直すというふうにプロセスを何度も行き来しながら、製品開発・問題解決を進めていきます。

ワークショップについて

デザイン思考の概要を学んだあと、次は実際にデザイン思考のプロセスを実践してみるワークショップを行いました。

お題は「飛行機で旅行に行く体験をリデザインする」というもので、飛行機の予約をするところから目的地に到着して旅行するまでのプロセスなかの問題点を見つけ出して、問題解決のアイディアを出していこうというものでした。

やり方としてはまず二人一組のペアになり、ユーザーインタビューをしながら飛行機での旅行体験に関わる不満のインサイトを得ます。その後得られたインサイトから問題定義を行い、アイディア出しをしてその時点で相手にそのアイディアをぶつけてフィードバックを得ます。 そのフィードバックからアイディアを一つにしぼり、そのアイディアのプロトタイプとしてポストイットに絵や説明を書いて、相手にまた説明し、フィードバックを得るというのを繰り返すというものでした。 すべてのプロセスが終わったあとにいくつかのグループが自分たちのアイディアを発表し、我那覇さんがそれに対してフィードバックを行いました。

僕がパートナーの方にインタビューしたとき、最初は「荷物が多くてキャリーバックを持って移動するのが大変で、コインロッカーを使うのだがそれを見つけるのも取りに行くのも大変」という話を聞き、最初はコインロッカーを増やすとか探しやすくという方向性で考えていました。 パートナーの方は女性だったのですが、よくよく問題を深掘りすると「多くなる荷物のもとは、洋服と化粧品」、「化粧品はとくにいつも自分が使っている物を使いたいけど旅行サイズの小さいものはないから、大きいサイズのものを全部持っていく必要がある」など他の問題があることが発見できました。

そのインサイトから問題定義を「旅行時にもっていかないといけない荷物が多いこと」という定義にして、解決策として「服と化粧品のインスタントレンタルアプリ」というものにしました。

それは、旅行先のホテルで使いたい服と化粧品をアプリで選び、ホテルの住所を入力すると、数時間以内にその服と化粧品を届けてくれて旅行期間中レンタルできるというものです。これによって、旅行期間中に持たないといけない荷物の中から服と化粧品をなくせるというサービスです。

このアイディアをパートナーにプレゼンしてフィードバックを得たのが、「化粧品はレンタルだといやなので使い切りにしてほしい」というものだったので、次のプロトタイプのブラッシュアップのタイミングでは化粧品は滞在日数分を小分け使い切りパックにして提供するという風に改善できました。

これからの自分の活動にどう活かすか？

いま働いているPaykeのプロダクト開発にも活かしていきたいと思いますし、特に今自分でもプロジェクト共有サービスのCollaboというサービスを開発しているので、それにはすぐに活用出来ると思います。

これを作るときに想定していたユーザーがいるので、実際にいまのプレビュー版を見てもらいその後のアップデートをどうしていくかを説明した上で、実際に使いたいと思うかどうか、フィードバックを得るためにユーザーインタビューをまずしていきたいと思います。

付箋

僕のプログラマーとしての師匠と思っている前職の上司と久しぶりに飲む機会があったのですが、そこでこんなものをもらいました。

 

 

f:id:arakaji-yuu:20180714205051j:image

 

これが何かというと3-4年前にチームでやりたいことを付箋に貼って共有するということをやっていて、それをずっと持っていてくれてこの機会に渡してくれました。

 

3-4年前から考えていたこのサービス、忙しいことを言い訳にして全然開発出来なかったのですが、今年の5月ごろに一念発起して開発スタートしてやっとプレビュー版を公開するところまではこれました。

 

プレビュー版を解除するのに必要な開発リストも決まってきたのでさらに本腰入れて進めていきます。

 

あと昔の自分、スペル間違ってるぞ。