専門学校で教員をしていると、学生が作ったものを評価する機会はたくさんあります。
課題を提出する。
発表する。
デモをする。
プログラムがちゃんと動けば、「よくできました」で終わることもあります。
ところが今回、学生が作ったシステムがその先まで行きました。
そしてそこで、学校の中だけではなかなか経験できない「本物の失敗」を経験することになりました。
これは、なかなか面白いRetryだったと思います。
学生が作ったシステムに、外部から声がかかった
きっかけは学校の入学式でした。
学生たちが、入学式の演出で使用するインタラクティブなシステムを制作しました。
詳しい仕組みについてはここでは書きませんが、参加者が演出に関われるシステムです。
このシステムを入学式で実際に使用しました。
すると、入学式全般を取り仕切っていた外部の事業者の方が、このシステムに興味を持ってくれました。
こちらから営業したわけではありません。
学生が作ったものを実際に見てもらい、
「別のイベントでも使えないか」
と声をかけていただきました。
これは学生にとって、かなり大きな出来事だったと思います。
学校の課題として評価されたのではありません。
学校の外にいるプロが、学生の作ったものに価値を感じてくれた。
そして実際のイベントで使われることになりました。
学生作品が、本番環境へ
こうして学生が作ったシステムが、実際のイベント会場に持ち込まれました。
もちろん、教室で先生に見せるデモではありません。
本物のイベントです。
会場には実際のお客さんがいて、音楽が流れ、アーティストによるパフォーマンスも行われます。
その中で学生たちのシステムも稼働しました。
ここまで書くと、
「学生制作のシステムが外部イベントで採用されました！」
という、きれいな成功事例になりそうです。
実際、それだけでも十分な成果だと思います。
ところが、本番で使ってみると別のことが見えてきました。
あれ？ 思ったほど使ってくれない
システムは動きました。
でも、イベント参加者が思ったほど使ってくれませんでした。
ここが今回、一番面白かったところです。
開発している側からすると、
「こんなことができます」
「参加すると演出が変わります」
「面白いでしょう？」
と思っています。
でも、実際のイベント参加者からすれば事情が違います。
目の前では音楽が鳴っています。
アーティストがパフォーマンスしています。
友人と話している人もいます。
つまり、その人たちは、
システムを使うために会場へ来たわけではありません。
イベントを楽しむために来ています。
これは考えてみれば当たり前です。
でも、作っている側にいると意外と見えなくなります。
「動く」と「使われる」は違った
ここで、かなり大きな気づきがありました。
システムが動くことと、ユーザーが使ってくれることは別なんだ。
プログラミングの授業では、どうしても「動くところ」までを目標にしがちです。
入力したら期待した結果が返ってくる。
通信できる。
データを保存できる。
エラーなく動く。
もちろん、それらは大切です。
でも、実社会にシステムを置いた瞬間、その先にもう一つ大きな問題がありました。
人は、本当にそれを使いたいのか。
ここから先は、プログラミングだけでは解決できません。
UXの世界に入っていきます。
顧客とエンドユーザーは同じではない
もう一つ面白かったのが、「顧客は誰なのか」という問題です。
今回、我々にシステムの利用を依頼してくれたのはイベントを運営する事業者です。
つまり、ビジネス上の顧客はその事業者です。
しかし、実際にシステムを使うのはイベントの参加者です。
整理すると、
開発側 → 顧客 → エンドユーザー
という構造になっています。
顧客が「こんな演出をしたい」と考える。
開発側が、それを実現するシステムを作る。
システムは仕様どおりに動く。
それでも、
エンドユーザーが使ってくれるとは限らない。
これはAWSなどのクラウドを勉強するときに出てくる「責任範囲を切り分けて考える」という発想にも少し似ています。
誰が何を提供していて、誰が何を担当しているのか。
ただしUXの場合、「ここから先はお客さんの責任です」で終わらせても、良いシステムにはなりません。
実際に使われなかったという事実は、開発側にとっても重要な情報です。
技術的には合理的でも、UXでは別の問題が起きる
今回採用した仕組みにも、当然ながら理由があります。
イベント会場で多数の人に参加してもらうためには、通信環境や端末、運用方法など、さまざまな条件を考えなければなりません。
その中で、学生たちは一定の合理性を持った方法を選択しました。
実際、その仕組みで本番環境でもシステムを動かすことができました。
ところが、一つの問題を技術で解決すると、別の問題が見えてきます。
今回見えてきたのは、
「技術的に実現できるか」ではなく、「その瞬間にユーザーがその行動をしてくれるのか」
という問題でした。
これは机の上で仕様書を書いているだけでは、なかなか分かりません。
では、どうすればよかったのだろう
ここからがRetryです。
「使ってくれなかった。失敗だった」
で終わる必要はありません。
むしろ、
なぜ使ってくれなかったのか？
を考えるところから、次の開発が始まります。
参加者に操作してもらう方法そのものを変えることもできます。
専用のデバイスを使う方法もあるでしょう。
参加者が意識的に操作しなくても、イベントを楽しんでいるだけで演出に参加できる仕組みも考えられるかもしれません。
逆にシステムを変えず、イベント側の演出や案内を変える方法もあります。
演者やMCから参加を促してもらう。
利用するタイミングそのものを変える。
開演前の待ち時間に参加してもらい、その結果を本番の演出に反映する。
考え始めると、いろいろなアプローチがあります。
そして、そのどれが正解なのかは、実際に試してみなければ分かりません。
動いたからこそ、本当の失敗ができた
今回、学生たちはシステムを完成させました。
学校行事で使われました。
それを見た外部の方から声がかかりました。
そして、本当のイベントで使われました。
だからこそ、
「思ったほどユーザーが使ってくれない」
というところまで到達できました。
これは結構すごいことだと思っています。
プログラムが完成しなければ、この失敗はできません。
本番環境に投入しなければ、この失敗もできません。
本物のユーザーがいなければ、この失敗もできません。
つまり、
動かなかったから失敗したのではありません。
動いたからこそ、本当の失敗ができました。
学校は「安全に本物の失敗」ができる場所なのかもしれない
企業で本番システムを作って、大きな失敗をすれば大変です。
売上に影響するかもしれません。
顧客との契約に影響するかもしれません。
会社の信用問題になることもあります。
でも学校なら、大人がある程度リスクを引き受けながら、学生を本物に近い環境へ送り出すことができます。
そして、うまくいかなかったときに、
「なぜだろう？」
と一緒に考えることができます。
私は今回の経験を通して、学校にはそんな役割もあるのではないかと思いました。
失敗しないために練習する場所ではなく、安全な環境の中で「本物の失敗」を経験できる場所。
教室の中で先生が、
「ユーザーがあまり使ってくれなかったと仮定して、改善案を考えてください」
と言うこともできます。
でも、本当に会場へ行って、自分たちが作ったシステムを目の前の人たちが使ってくれない経験とは、やはり違います。
プログラミングの、その先へ
プログラムを書く。
システムを作る。
クラウドにつなぐ。
それだけでも十分に勉強になります。
でも、それを実社会に置いてみると、その先に、
UX、顧客、エンドユーザー、運用、コスト、イベント設計、ビジネス
といった世界が広がっていました。
システム開発は、コードを書いて終わりではありません。
作ったものを人が使う。
そこで初めて分かることがあります。
今回の学生たちは、かなり貴重なところまで到達したのだと思います。
成功したから学べたのではありません。
成功して、その先まで進んだから、より価値のある失敗ができた。
そして、
「では、次はどうする？」
と考えられる。
これもまた、立派なRetryだと思います。
コメント