自分の開発したプロダクトがニュースに！？日本初のサービスだからこそ…「Q SKIP」開発秘話

こんにちは、東急株式会社「URBAN HACKS」採用担当です。

URBAN HACKSは、交通事業を軸に不動産や商業施設開発、ホテル等多彩な事業を展開している東急株式会社が、街づくりにおけるDXを目的に、2021年7月より生まれた新組織です。現在、新たなイノベーションを生み出すべく、積極採用を進めています。

今回は、URBAN HACKSがリリースしたデジタル乗車券サービス「Q SKIP」について、その概要や事業背景、開発における苦労ややりがいなどをメンバー4名にお伺いしました。

東急のリソースを活かした開発が行われており、Web系の事業とはまた一味違う「モノを作る喜び」が伝わってきます。

東急の事業領域の広さ、身近さに惹かれたメンバーがジョイン

―最初に、皆さんのご経歴や現在の業務内容などについて、簡単に教えてください。

石神：前職は小売企業でネットスーパーの立ち上げに携わりました。やりがいはありましたが、次第に1つのドメインだけではなく、複数のドメインを横断したサービスを作りたいという気持ちが強まってきました。そうした意味で、東急グループは交通、不動産、リテール、ホテルなど200を超える企業で構成されたコングロマリットな企業です。その中でも東急株式会社は、東急グループを統括することが役割なので、DXという側面でグループ横断のサービスを作ることが出来ると思い入社しました。

現在はプロダクトマネージャーとして、中長期の戦略立案、プロダクト開発チームをリードする役割を担っております。

吉田：私は東急が2社目で、1社目はヤフー株式会社でエンジニアや企画、プロダクトマネージャーといったポジションも担当し、最終的には検索や求人などの事業責任者を経験しました。そのなかで、一人ひとりのユーザーに対してしっかりとデータを取り、エンゲージメントを高めていく仕事に興味が出てきたんです。東急なら、オフラインの行動履歴も含めてデータが取れるというところに魅力を感じて、入社しました。現在はQ SKIP以外にもアプリやホームページなど、移動関連のプロダクトの全般を、POとして統括しています。

真鍋：私は日本テレビグループのWeb制作会社、楽天モバイルを経て、3社目に東急へジョインしました。1社目ではテレビ番組やアニメ、映画のホームページを作ったり、番組と連動したWebのリアルタイム企画を手掛けたりしていましたね。2社目の楽天モバイルでは、公式ホームページや製品ページの制作開発を進めました。制作がひと段落し、新しい環境でのチャレンジがしたくなったため、「社会に対して役に立てそう」と感じた東急にジョインしました。規模感や社会への影響力に惹かれたところも大きいです。現在はフロントエンドエンジニアとしてQ SKIPの開発を進め、チーム体制の構築も行っています。

大友：私は新卒でヤフー株式会社に入社し、ヘルスケア系メディアの運用保守や遺伝子解析サービスの新規開発などに携わっていました。その後AI系のベンチャー企業に転職し、物理サーバーの構築からアプリケーションの開発運用まで幅広く手掛けた後、東急に転職しています。私は長年東急沿線に住んでいる東急ユーザーでして、「自分にとって身近なプロダクトを開発したい」と思ったのが転職理由です。現在は、バックエンドエンジニアとしてQ SKIPの開発や運用を担当しつつ、1月頃リリース予定である新機能の開発や、取得データを用いた機能改善も行っています。

マイクロツーリズム需要に合わせ、1日乗車券のペインを解消

―Q SKIPのプロジェクト概要や、事業背景を教えてください。

石神：Q SKIPは、これまで販売していた紙の乗車券を、デジタル化して販売するサービスです。ユーザーは紙の切符の代わりに、QRコード乗車券やタッチ決済対応のクレジットカードを使って改札を通過することが出来ます。

事業背景としては、近年通勤・通学のような定期範囲の移動だけではなく、近場でのおでかけ（マイクロツーリズム）の需要が伸びてきたことです。そうした需要に合った券種の作成を目的として、プロジェクトが立ち上がりました。

これまでもそうしたおでかけ系の乗車券は販売していたのですが、東急線各駅の券売機でしか買えず、買えても紙の乗車券を持ち歩かなければならなかったり…というペインがありました。

Q SKIPはネット上で乗車券を購入・利用できるため、こうしたペインを解消できるサービスとなっています。今後は、沿線施設や観光地とコラボし、移動需要そのものを喚起するサービスにしていきます。

👆Q SKIPの改札

多数のステークホルダーと連携し、日本初のサービス開発に挑戦

―今回のプロダクト開発は、どのような体制やスケジュールで進められたのでしょうか？

石神：リリースまでの開発体制は以下の通りで、計8名で進めていました。

PO 　　　　：1名
プロダクトマネージャー　 ：1名
フロントエンドエンジニア ：1名
バックエンドエンジニア 　 ：2名
デザイナー 　 ：2名
QA　　　　　　　　　　　 : 1名

※他グループ各社の関係者多数

開発期間は約10か月となっており、スケジュールの内訳は以下の通りです。

2022年11月〜：チームビルディングとスコープの確定
2022年12月〜：UI/UXの設計
2023年01月〜：開発着手
2023年08月末：リリース

―URBAN HACKSではアジャイル開発がメインのようですが、具体的にどのような連携を行っていましたか。

石神：Q SKIPにおいては、ウォーターフォール開発をメインとしつつ、部分的にアジャイル開発の良さを取り入れたハイブリットな方式を採用しました。

ウォーターフォール開発をメインとした理由は、本サービスが東急線の各駅、東急グループ各社、改札機メーカー様など多くのステークホルダーを巻き込んだ大規模なプロジェクトであり、スコープとスケジュールを明確を握り、全体で歩調を合わせながら進める必要があったためです。

そのため、社内外を交通整理しながら、最初にしっかりとスコープを確定させることを意識していました。

また、キックオフ後は、議論が空中戦にならないように、デザインやプロトタイプなど実際に動くものを見てもらいながら、打合せを行いました。

とはいえ、人によって意見が分かれるポイントもありました。と言いますのも、「オンラインで購入した乗車券をQRコード/クレジットカード、いずれか好きな媒体を選択し、改札機を通過することが出来るサービス」は、全国的にも例がありませんでした。

（厳密に言いますと、期間限定で一部駅を対象とし、窓口に読み取りリーダを取り付ける形で行われた他社事例はありましたが、多くのお客様が利用する改札機を改造し、全線に展開した弊社の事例とは異なります。）

そのため、参考事例がない中で、「良いサービス設計」という答えのない問いに何度もぶつかりました。また、立場や利害の異なる関係者同士で議論をすると、「良い」の基準が微妙にズレる瞬間が生まれることに気が付きました。

そこで、全員がお客様の求める「良い」を基準に話が出来るように、リリース前にユーザビリティテストを行いました。

すると、私たちが「良い」と思っていたサービス設計に対して、ユーザーから多くのフィードバックを頂きました。そうしたフィードバックは素直に受け止め、何度も改善を重ね、納得いくまで磨き上げました。

そうした意味で言うと、今回はウォーターフォール開発をメインととしつつも、アジャイル開発の良さも取り入れたハイブリットな開発が出来たのではないかと思います。

自分たちのプロダクトを「見える形で」使ってもらえる喜び

―プロダクトをリリースするまでに苦労したことや、やりがいを感じたことを教えてください。

真鍋：フロントエンドエンジニアとしては、Q SKIPは前例のないサービスであるため「Q SKIPとはどういうサービスなのか」を、画面上でユーザーに説明することが難しい点でした。例えば、スマホ上の乗車券を使用するにあたり、当初は「チケットを有効化する」という表現を使っていました。ただ、ユーザビリティテストを実施したところ、「これではよくわからない」というアドバイスを頂いたため、「チケットを使う」という表現に変更しました。こういう、「世の中にないサービスをどう表現するか」という点は、デザイナーさんも苦労されていたようです。そこはお互い連携し、話し合いながら進めていました。

また、フロントエンドが開発する部分は、ユーザーが一番使ってくれる部分でもありますので、自分の開発した画面がニュースに出たり、現場で使ってもらえたりします。駅の改札機や電車の中吊り広告でもQ SKIPの名前を見ることがあり、「自分たちのサービスが街の人々に役立っている」と、とてもやりがいを感じています。その一方、交通インフラ系のサービスですので、ユーザーとしては「動いているのが当たり前」という認識が強いですよね。障害が起こると電車に乗れなくなってしまうため、バックエンドのメンバーとも緊張感を持ちながら仕様を詰め、開発していました。

石神：プロダクトマネージャーとして苦労したこと・やりがいは、先程の話と重複しますが、今回のようなサービスは、全国的にも例がありませんでした。そのため、参考事例がない中でゼロから体験設計をしたことが苦労した点です。

一言に体験と言っても、リアルのアセットを持つ弊社においては、「ユーザー体験」だけではなく、駅係員やバックオフィス系のオペレーションなど「従業員体験」も含まれています。

しかしながら、多くのステークホルダーがいる中で、全体設計をする人が不在でした。そこで私たちの方でデジタル化した乗車券をシステムに登録し、ユーザーが購入、駅で利用、そして精算するまで全体像を描き、各ステークホルダーと擦り合わせることでポテンヒットが生まれないようにしました。関係者とのコミュニケーションコスト然り、あらゆるケースの洗い出しが大変でした。

サービス開始後は、合計で150を超えるニュースやWebメディアで報道されたこともあり、多くのお客様に購入していただきましたが、駅で問題なく使われているのを見た時に、自分のやった仕事が世の中に与える影響力とやりがいを感じました。

大友：バックエンドとしては、ベンダーとの並行開発だったため、API連携をはじめとしたすり合わせが大変でした。また、決済やシステムを同時に繋ぐ必要があったため、トランザクションにはとても気を使いましたね。やりがいとしては、改札という「目に見える」サービスであり、オフラインで人が使ってくれる点に楽しさを感じました。私自身も東急線ユーザーですので、自分に身近なものの開発に携われたことも、モチベーションになりました。テストでは東急の検査場へ行って、いろんなスマホで実際に改札を通れるか試しました。実際のモノに触れながら検証できたことも、新鮮な経験で楽しかったです。

吉田：PO目線で大変だったことは、まず事業をしっかり理解することです。前職の事業領域はデジタルに限られていたので、Q SKIPのように交通インフラに関わるサービスについて、マネタイズ方法やユーザーへの接し方がこれまでと全く違いました。KPIツリーを作ったり東急電鉄の方にも質問したりと、自分で勉強して事業への理解を深めたことが大変でした。

やりがいに関しては、前職から変わらずプロダクトが利用されている場面が見られること。今回はそれだけでなく、東急に入社できて初めて経験した、デジタルを活用することでオフラインの課題を解決できたことです。前職では基本的に、オフラインの課題をデジタル上で解決していました。実際は、ユーザーのほとんどの行動はオフラインであり、そのオフラインでの課題解決に取り組めたことが良い経験になりました。また、ユーザーのデジタルでの購買行動だけではなく、その後のオフラインでの移動や前後の行動履歴も追えたことは、今後の事業/プロダクト開発の幅が広がっていく可能性を感じることができました。