Hyper IslandのBusiness Transformationの授業が終わった
Hyper Islandの6つ中4つ目のモジュールが終わりました。もう終盤だ。今回も成績としてはDistinctionをとることができ、いままでなんとか全てのモジュールでDistinctionをとることができています。
いままでの学びの振り返り記事は、下記にまとめております。
今回のモジュールは"Business Transformation & Innovation"という授業。その名の通り、企業のなかでどう変革を起こしていくか？ いままでの延長線ではない事業をどう作っていくか？ ということについて深く入り込んでいくモジュールです。
モジュールの進め方などは、いままでの記事と被ることも多いと思うので、そこは他の記事に任せてすっ飛ばします。気になる方は下記の記事などを見ていただければ幸いです。
それぞれのモジュールの雰囲気は下記記事から、感じていただけると思います。
お題は、公共交通機関のデジタル化の加速
今回のクライアントは、スウェーデンの公共交通機関のSL社（Storstockholms Lokaltrafik）。スウェーデンの首都ストックホルムを拠点にした公共交通機関の運営会社で主に、バス、地下鉄、トラム、郊外電車などを運営しており、これらの交通サービスはストックホルムの日常の移動に欠かせない部分です。
ちなみに、僕もスウェーデンでは毎日使っていましたが、本数も多いし、時間通りくるし、すごく快適でした。日本人の感覚からしても、安心して使えます。
今回のお題は、交通機関を使うためのチケット購入を、なるべくアプリ上からさせるために、どのような施策が考えられるか？ というものでした。
チケットの購入は駅でもできるのですが、なるべくアプリから購入させるように移行させていきたいというのが、SL側の願望です。
これはHyper Islandあるあるな気がしますが、モジュールで取り組んでいる内容と、実際のクライアントが求めている解決策が少し離れていることがあります。
今回も、ビジネストランスフォメーションというよりは、アプリを啓蒙するためのマーケティングキャンペーンをどう作っていくか？ ということに近しかったような気もします。悩ましい・・・
4つめのモジュールにもなると、所謂デザインシンキング的なプロセスは自然と共通言語のように使われるようになっており、スケジュールのなかにプロトタイピングやユーザーテストなどは当たり前に入ってきます。
今回は「なぜ人々がアプリからチケットを購入していないのか？」という部分を深掘りしながら、そこに対して仮説を作って検証する方法で進めました。SLから開示されたデータには、多くの数字データがあり、スプレッドシートを駆使しながら（私がちょっと輝けたポイント）情報をまとめつつ、ヒアリングを重ねていきます。
結論「そもそもアプリを使うメリットがないからじゃね？」というまあ、なんとも当たり前の話になり、アプリを使うことで生まれるメリットをマーケティングキャンペーンとともに提案することとしました。
ユーザーテストはLPを作成して実施
アプリのモックアップを作ると時間が足りなそうだったので、僕らが考えるアイデアをLPにまとめて、それを元にユーザーインタビューする形で進めています。そこから、どのアイデアがユーザーメリットとして大きいかをまとめました。
結果として、アプリでチケットを購入した場合は、友人や家族とそのチケットをシェアできるという機能にフォーカスしてマーケティングキャンペーンを作っていくこととしました。
実は、スウェーデンに住んでいるメンバーに聞いたところ、フィジカルカード（≠アプリからの購入ではないカード）はSLが正式に他の人と共有することを認めているとのこと。 ……本当か？
まあ真意はおいといて、その機能をもっと使いやすくアプリで実装することができれば、アプリ経由のチケット購入頻度はあがるんじゃないか、という仮説です。もちろんチケットがシェアできるようになることで、売上自体が下がるリスクもありますが、そこは数字的な計算をして影響はポジティブなのでは、と結論づけました。
おおむね、クライアントの反応もよかったと思います。簡単な事業計画も作ったからね……
いつでもトランスフォメーションするべきは組織
さて、Hyper Islandらしく、モジュールでの気づきなども振り返っていきたいと思います。
ビジネストランスフォメーションの定義はいくつでもあると思いますが、どのビジネスでもデジタルのことを無視したトランスフォメーションはありえないですし、結局はどうデジタルを活用するか・テクノロジーにどう投資していくか、という話になります。
そこで大きな問題になるのは、じゃあどうすればデジタルやテクノロジーを活用する人材を社内で生み出せるのか・育てられるのかという観点です。
もちろんそれ自体の方法も難しいですが、既存の事業も伸ばしていくなかで新しい試みをするのは、社内の軋轢を生むことにもなりえますし、組織文化をどう変えていけるかという問題もあるでしょう。そういう意味では新しいゴールに向けて組織をどうトランスフォメーションできるのか、という観点が一番難易度が高く、また一丁目一番地だとも言えます。
たとえば今回のSL社の例でも、アプリの活用データに関する問い合わせをしても、「データをすぐに用意するのは難しい」だったり「他の部署に問い合わせする必要があって、ちょっと時間がかかる」だったり。という回答が繰り返し起きていました。
これらの対応からは、デジタルに移行したいけれども、会社のなかの基盤がデジタルに順応できてなさそうな雰囲気を感じました。
トランスフォメーションは「やりたい！」と思ってすぐできるものでもなく、「できました！」と終わりがあるものでもありません。常に未来を見据えながら組織とサービスとを進化させていくという姿勢、そしてその速度が本当の意味でトランスフォメーションを起こすためには必要なのでは、と感じました。
有能なチームが、所属したいチームというわけではない
これは個人的に大きな学びでした。Hyper Islandはモジュールごとにグループが代わり、新しいグループでクライアントの課題に向き合うことになります。
今回のチームは、メンバー6人全ての能力が高く、タスクをうまく分けつつサクサクと進んで行った感じです。ファシリテーターがいて、ストーリーを考える役割がいて、デザイナーがいて、ユーザーリサーチャーがいて・・・という感じの。
かなりスムーズに進んでいったのですが、なんだかサクサクとうまくいきすぎて、チーム内でのコミュニケーション自体は密ではなかったように感じます。なのでモジュールが終わったあとも「おつかれ！また！」という感じですごくシレッと終わってしまった感じがあります。
たしかにアウトプットとしてはいいものを出せたんだけど、なんだか個人的にはちょっと物足りない。
対して、前のモジュールのグループは、アウトプットのクオリティはもっと改善できる余地は多いにあったものの、「またこのチームでやりたいね！」という空気に溢れていた気もします。
これはまだ深く考える必要がありますが、チームの雰囲気の良さはアウトプットの「遊び」の幅を左右する感じがします。
優秀で各人がやるべきことが明確になっていても、チームでのコミュニケーションが最低限だと、その「遊び」の幅が小さく、結果アウトプットも問題はないんだけど、予想通りのものになってしまうというか。
どこかで、もっと深くリフレクションしたいものです。
のこりのモジュールはあと2つ！
そして、その2つともあと1ヶ月もしないうちに終わってしまいます。ひやー、早かった。
この記事が気に入ったらサポートをしてみませんか？