UXploration

Bringing you dispatches from the UX world.

Code for Namie ー 「考える」と「つくる」

東日本大震災による東京電力福島第一原発力発電所事故の影響により今尚全町避難が続く福島県浪江町。今年度に全町民に対してタブレット端末を配布する事業を予定している浪江町の支援の一環として開催された、浪江町住民のタブレット活用を考えるハッカソンCode for Namie(浪江町 Code for Japan)が今週末に開催されました。

f:id:separate-ks:20140629225755j:plain

f:id:separate-ks:20140629231644j:plain

((c) Code for Namie)

ふるさとである浪江町を離れ、物理的にバラバラになってしまった地域の絆を再生するために、タブレット端末をどう使えるか。情報格差が著しい浪江町の町民に対してどのような情報や機能を提供すべきなのか。

Code for Namie ではこれまで僕が携わってきたハッカソンとは異なり、計6回のアイディアソンを開催し、のべ420名が参加し、創りだされた770ものアイディアを16種類に分類し、内7つのアイディアを今週末に開催されたハッカソンで形にしていきました。通常はアイディアソン / ハッカソンそれぞれ1回づつ開催されることが多いため、驚きました。

その昔、アインシュタインは言いました。

"If I had only one hour to save the world, I would spend fifty-five minutes defining the problem, and only five minutes finding the solution."

(もし、地球が滅びそうな状況になって助かる方法を考えるのに1時間あるとしたら、私は最初の55分で問題を理解し、問題がどういったものであるかを適切に定義することに費やすだろう。そして残りの5分で、その答えを考えるだろう。)

今回のハッカソンも、その通りだと言えます。

それだけではありません。自治体が発行している浪江町の住民意識調査の報告書や避難状況をはじめとする、タブレット事業の導入に向けた江町の現状と課題を、浪江町役場の方々のご協力により事前インプットとして参加者に提供されました。

f:id:separate-ks:20140629230350j:plain

((c) Code for Namie)

また、どんな人が、どんな生活を送っているのか?被災前と比較してどのように生活が変わったのか?どのようなことに困っているのか?こういった事柄に具体的イメージを持つために仮想ユーザーであるペルソナが、実データを基に成形されています。

f:id:separate-ks:20140629230430j:plain

((c) Code for Namie)

そして、浪江町をはじめとるす福島の復興に関する話題が会ごとに提供され、繰り返し開催されるアイディアソンのアウトプットの質の向上に寄与しています。7つに絞られたアイディアは、ハッカソン最終日に実際に町民の方々の前でタブレット端末内で動くアプリケーションとしてデモンストレーションを行い、最も票を集めたアイディアはその後、民間企業と連携し今年度中に製品化され、配布されます。ぼくはメンターのひとりとして、アイディアの具現化を支援させていただきました。

f:id:separate-ks:20140629230507j:plain

((c) Code for Namie)

利用者との交流

Code for Namie では実際にアプリケーションを利用する立場となる町民の方々による審査が設けられたことが素晴らしいと思いました。その後、デモンストレーションを終えた各チームのテーブルを周り、アプリケーションをタッチ&トライして実際の利用イメージを持っていただくような時間も設けられていましたが、アプリケーションの良し悪しを最終評価するのは利用者なのです。

f:id:separate-ks:20140629230641j:plain

((c) Code for Namie)

被災者が抱える課題の解決に向けたアイディアが優れていると自身で思っていても、答えは利用者のみが知っています。利用者との交流はもちろん、フィードバックがなければ自己満足で終わってしまいます。そのような事態を回避するためにも、全国各地で開催されているすべてのアイディアソン / ハッカソンはつくる側の人間と、つかう側の人間の距離をもっと縮めていくべきです。

何のためのアイディアソン / ハッカソンなのか?いまいちど問いなおす必要があるのではないでしょうか。

伝える&伝わる仕組みづくり

イベント最後の総括でもお話させていただきましたが、ぼくは参加者のみなさんと、その素晴らしいアイディア(アプリケーション)の魅力を確実に利用者に伝えるための仕組みづくりを未熟ながらも支援させていただきました。

f:id:separate-ks:20140629231002j:plain

((c) Code for Namie)

デモンストレーションでは町民の方々にそのアプリケーションの魅力をちゃんと伝えることができましたでしょうか?また、ちゃんと伝わっていましたでしょうか?実装した機能に対してではなく、そのものの価値について共感していただけたでしょうか?

いくらアイディアや具現化されたアプリケーションが優れていても、その魅力が利用者に伝わっていなければ全く意味がありません

どのように伝えるべきか?どうしたら伝わるのか?伝わる仕組みを考えることは決して簡単なことではありませんが、日常のコミュニケーションから意識可能な内容です。

まとめ

アイディアソンでアイディアを生み出し、ハッカソンで創る。すっかりと定着してしまったこの構図について疑問が残ります。開発プロセスを単純にまとめると「考える」と「つくる」に別けることができますが、昨今のアジャイル開発や、当ブログでも何度も解説している LeanUX などの浸透に伴い、「考える」と「つくる」距離は除々に縮まってきています。双方の境目がなくなってきている、と言い換えることができるかもしれません。前述のアインシュタインの言葉のとおり、「考える」ためには「つくる」必要があり、「つくる」ためには「考える」必要があります。 

f:id:separate-ks:20140629231243p:plain
((c) Peter Morville)

つまり、現代のアイディアソン / ハッカソンは同一の作業内で完結させるべきではないでしょうか。時間的制約はあるものの、「考える」を専門とする参加者と「つくる」を専門とする参加者を別けることで、創りだされたアイディアの裏にある背景が引き継がれにくいといった事態に陥りやすくなります。

また、今回のハッカソンでも事前に選定されたアイディアそのものがソリューションを限定してしまうような示唆が含まれているものがありました。アイディアソン / ハッカソンにも LeanUX マインドを浸透させるべく、引き続きいち参加者としてもハッカソンイベントに足を運びたいと思います。

最後に、こんな僕をメンターとしてお招きいただいた運営スタッフのみなさま、ありがとうございました!

関連リンク;

This work is licensed under a Creative Commons Attribution 4.0 International License.
Others, like quotes and images belong to its original authors.