トヨタグループの中でMaaSという不確実な領域に挑戦するPoCチームの活動史

KTC_KINTO

こんにちは。
KTC_KINTOこと、my Route開発グループの木下です。

これは、KINTO Technologies Advent Calendar 2021 - Qiita の19日目の記事になります。

今日は、自分の属するPoCチームの活動について紹介します。

まえがき

ご存知では無い方が多いと思います本社、KINTOテクノロジーズについて紹介します。当社は、株式会社KINTOとトヨタファイナンシャルサービス株式会社から開発・編成グループを独立させた子会社です。
そのため、世間的に知名度のある「クルマのサブスクのKINTO」 だけではなく、Global KINTO・モビリティマーケット・Toyota Wallet・Toyota Woven City・MaaS開発などのサービスの開発・運用も行っています。
このMaaS開発の中に、トヨタファイナンシャルサービス株式会社の事業メンバーと共にシステムの再構築、ビジネスプランの再作成をしている my Route というモバイルアプリがあります。自分は、普段my Routeの先行開発をするPoCチームにて、エンジニアをしています。
世間に知られていないKINTOテクノロジーズの働き方について、私たちのチームの活動内容を通して紹介します。

自序

そもそもmy Routeについてですが、トヨタ自動車株式会社の未来プロジェクト室からのプロジェクトが起点で始まりました。事業化の際にトヨタファイナンシャルサービス株式会社へと事業移管されました。元のシステムは2018年に福岡市で実証実験を行った際に開発されたものになります。新たな機能を追加して、サービスを展開していくためには、システムの再構築とビジネスプランの再作成に取り組む必要がありました。しかしながら、当初の構想にはPoCは含まれておらず、姿も形もないところから走り出しました。
本稿は、この何もないところから始め、チームを生み出し、プロジェクト貢献したPoCチームの活動史です。

事前アナウンス

記事の中に、実際の業務で活用している図がいくつか出てきますが、社内規定などの都合上、具体的な中身が分からないようにボカしてあります。どんな感じのものか程度に感じていただだけたらと思います。

はじめに

メンバーについて

PoCチームは、4名というスモールチームの構成となっています。

チーム構成表

【J.O.】
ああっと！
こんなところに、うちのPMであるJ.O.が！
ということで、以下からPMをJ.O.とします。

リンク先が切れたときに備えたJ.O.の魚拓

【馴染みのない”サポート”について】
UT熊本という熊本の販売店から出向している営業マンが担当しています。出向当初はSELECT文すら分からなかったですが。1年でNoCodeのテックカンファレンスに登壇するまでに、たゆまぬ努力を続けて成長しました。
現在の主な活動内容は、J.O.のカバン持ちです。具体的には、アプリ調査、既存アプリの仕様書の調査・獲得、MTGの日程調整など、幅広くサポート役として活躍中です。

サポートの元気そうな写真があったので晒しておこう

チームの立ち上がり

キッカケとなったのは、21年3月の終わり頃になります。当時のJ.O.は、事業戦略の見直しをトヨタファイナンシャルサービスの事業部側と進めていました。その合間に、新しいmy RouteのUI/UX案を検討していました。
とき同じ頃の自分は、別の案件でmy Routeのシステム再構築に携わっていました。そのときに、どこか噂で、J.O.が新しいmy RouteのUI/UXを検討していること耳にして、声をかけたのが始まりだったかと記憶しています。
4月中旬に、このUI/UX案を元にモックアプリを作成し、ビジネスサイドに興味を持ってもらいました。タイミング良く、社内で5月にmy Route開発グループという部署が設立することとなりました。このタイミングに合わせて、J.O.が密かに行っていたPoC活動を1つのチームへと働きかけ、正式にPoCチームとして立ち上がることとなりました。

チームの活動について

チームが立ち上がって、現在までに行ってきたPoCチームの活動を紹介します。スモールチームのため、自分はエンジニアではありますが、デザイナーも含め、開発やデザインだけに専念していたわけではありません。等しく皆、ビジネスプラン・戦略の検討、UXの吸い上げ、幅広くソフトウェア開発を実践しました。
チームの役割・目的としては、「何を作るのかを決める」ことになります。

進め方は、主にMVPキャンバスを活用しました。

MVP（Minimum Viable Product）キャンバスとは

Minimum Viable Productは直訳すると「必要最小限の機能を有する製品」。顧客に価値を提供できる「必要最低限の機能」を有するプロダクトを指します。
〜〜〜
MVPキャンバスとは、仮説検証の内容を明確化するためのフレームワークで、AppSociallyの高橋氏とRecruitのMTLが共同で開発しました。MVPキャンバスを利用すれば「仮説をもとにして、どのような結果を得るのか」、また「MVP後につくるべき、プロダクトやサービスのカタチ」が浮き彫りになります。

MVPキャンバスとは？仮説検証の無駄をなくす

これを取り入れる意義としては、不確実な領域に挑戦するMaaS アプリビジネスにおいて、最小限の失敗で最大限の成果を得ることであると考えています。

チーム運営について

チームの共有時間として、1週間の中に以下の会議体を設けて進めていました。個々で持つ業務が多いため、作業時間を圧迫させないように、定例はなるべく少なくしています。
集まって相談したいことがあれば、Slack のチームのチャンネルで声をかけて、その都度で柔軟に行っていきました。スモールチームの良さが出たのか、これで特に大きな問題も出ずに進められました。

  • Weekly Standup （45min）

    • 週始めの月曜日に実施。今週やることを、Jiraに起こして、スプリントバックログを回しています。

  • Daily Standup （30min）

    • 毎日（月曜日を除く）で実施。Weekly Standupで作成したスプリントの中の、チケットの進捗を共有・確認しています。

  • YWT（60min）

    • 週終わりの金曜日に実施。チームの振り返りとして、YWTを実践しています。

フィールドワーク

チームとして実際のユーザー行動、ユーザーニーズを知ることを非常に重視しており、現地に行き調査を行いました。今回は、都市圏で確認できる車以外の以下のモビィリティを調査しました。

  • 電車・地下鉄

  • 路線バス・回遊バス

  • シェアサイクル

  • 都市型・郊外型オンデマンドバス

  • LUUP

フィールドワークの風景 : LUUPにのるサポート

都内は東西南北の全方角のエリアで、時間帯の朝昼晩を組み合わせて、幅広く現地のモビィリティの調査を実施しました。最初は久しぶりに出かけられるという楽しい気持ちがありました。（そういえば、名古屋市とその近辺エリアにも行ったな。）
しかし、朝は5時から現地で調査を行うこともあり、またワークの調査範囲も広く、ずっと移動していたため、肉体的にも精神的にもやられてしまいました。気持ちがヒヨリ始めたJ.O.と自分を、サポートが熱く鼓舞してくれたおかげで無事にやり遂げました。

MVPキャンバスの実践

デジタルツールとしてmiroを活用して、MVPキャンバスを作成しました。スタート時は、こんな感じでしたが。

最初のMVPキャンバス

その後、「フィールドワーク → MVP」を何度か繰り返し、終わってみると、以下のようになりました。

MVPキャンバスの全体図

右上に赤く囲ったのが、最初のMVPキャンバスになります。振り返ると随分小さくなりました。やる前はあまり書くこと無いんじゃないかと思ってたんですが。実際にやってみると、書くことが多くあり、まとめるのが大変でした。うまく効果が発揮することが出来たのではないでしょうか。

ラフヒアリング

MVPキャンバスを通して、見えてきたユーザーの課題の洗い出をしました。洗い出した課題をまとめ、仮説定義を行いました。その後、仮説定義で決めたペルソナを探し集め、簡単にヒアリングを行い、課題と仮説の確度を更に高めていきました。

PoCアプリの開発

デザイナーは、FigmaとOverflowを使って、仮説定義に基づいた画面仕様を作成しました。沢山の画面があったんですが、高いスピード感で作成してました。（ホントにすごかった…、ありがとうございます！！）
開発するエンジニアは自分だけで、iOSとAndroidを同時に作る必要があるため、Flutter x Riverpodを用いた低コストでPoCアプリの開発を行いました。

ちなみに、トヨタはFlutterをコクピットに組み込んでおり、会社との相性は良さそうというのもありました。

開発時の内容については、Flutterのカンファレンスで発表できればと思っていたんですが、残念ながら採択されず。またどこかの機会でお話することがあれば、その時をお楽しみにお待ちください。

ユーザーヒアリングの実施

フィールドワークと同様に、ユーザーの声を直接に拾えるユーザヒアリングも、非常に大切にしてました。ラフヒアリングで集めたペルソナに、作成したPoCアプリ触ってもらい、幅広く意見を集めました。実際に触ってもらいながら、ユーザーストーリーをまとめました。実際の行動の中で、違和感なく使われることがあるのかを確認しました。

ユーザーストーリーの図

「ユーザーヒアリング  → ユーザーストーリー作成 → PoCアプリ修正」を何度か繰り返し、ペルソナが求めるUXの実現を目指しました。

ユーザーストーリー全体の図

全体を見てみると、右中央の赤枠が紹介したユーザーストーリーの図になります。想定してたよりも多くのヒアリングを実施することができ、UXを深く突き詰めることが出来ました。

活動成果の共有について

社内のナレッジ共有では、Confluenceを活用しています。PoCチームの活動を通して見えてきたコンセプトやUXを、プロダクトチャーターとPRD（プロダクト要求仕様書）を作成し、ビジネスサイドや部署内メンバーに共有しました。プロダクトチャーターとPRDの違いは以下です。

引用元：プロダクトの存在意義を明確にする、PRDよりも大切なプロダクトチャーターとは

プロダクトチャーター

「my routeの先行開発で分かった共通で認識しておくべき、目的・背景・指針」を文書化して、まとめました。文字だけでは分かりにくい部分は、Amazonのフライホイールを参考にした図にしたりして、ビジョンを見える化しました。

目的を伝える図

プリンシプル(原則)も含めて書き起こし、ビジネスサイドにも理解いただける内容のものが出来き上がりました。

PRD（プロダクト要求仕様書）

ご存じない方は、初めて書くPRD（プロダクト要求仕様書） を参考ください。
部署内の開発メンバーが開発できるように、my routeのビジネス戦略を含めた全体を見える化しました。

  • プロダクト成長ストーリー

プロダクト成長ストーリーの図

  • ユーザージャーニー

ユーザージャーニーの図

  • リーンキャンバス

リーンキャンバスの図

  • ビジネスモデルキャンバス

ビジネスモデルキャンバスの図

  • システム全体像

システム全体像の図


以上の図の内容に加え、一つ一つの機能に対して、ユーザーストーリーを記載しており、とてもとても長い、なが〜〜〜〜い巻物ができ上がりました。

先行開発して内容を決めるまでも大変ですが、決めた内容を書き上げて見える化するのも、また非常に大変でした。

おわりに

本稿で書ききれなかった部分としては、活動を進めていく中で行ったDX化があります。miroやFigmaといったデジタルツールは当然もともと用意されては無く、導入する必要がありました。如何せんKINTOテクノロジーズもトヨタのグループになります。上との調整で個人的にとても熱くなるイベントがあったのですが。これもまた、開発時の内容みたく、どこか別の機会でご紹介することがあれば。

あとがき

KINTOテクノロジーズの働き方を、PoCチームの活動を振り返ることで紹介しました。今回、my Routeの先行開発をして決めた内容は、J.O.と25名超の部署内メンバーにキックオフを行い、一つの大きなプロジェクトが走り始めました。PoCチームとしては、ここで一つの役目を無事に終えることができました。

後日談として、ありがたいことにチームは、UI/UXチームへと昇格しました。
“オレたちは登り始めたばかりだからな
この果てしなく遠いMaaSビジネス坂をよ…”
この言葉を胸に、前を向き、さらなる高みへと、私たちは新たに歩み始めました。

前を向くサポート

KINTOテクノロジーズでは、良くも悪くも自由な環境のため、開発に専念もあれば、今回みたいにビジネスサイドにも入り込むといった多様な働き方ができます。
自分がやりたいビジョンや積みたい経験を持っている方には、誰もゴールを設定しないので、ご自身に合った働き方ができる環境でもあります。

ご興味を持たれた方は

当社では、トヨタ車のサブスク「KINTO」等の企画/開発を行っており、エンジニアを募集中です。
KINTO Technologies コーポレートサイト


この記事が気に入ったらサポートをしてみませんか？