スケジュール管理と経路検索が連携する「RODEM」の開発チームが味わった産みの苦しみ

交通費の精算がめんどうだ――。外回りの多い会社員には、共感できる悩みではないだろうか。

「駅すぱあと」の株式会社ヴァル研究所が開発した「RODEM（ロデム）」は、カレンダーに行き先を登録するだけで、経路の検索から、交通費の精算までを自動化する、画期的なサービスだ。手間を87％も削減できるという。

そのプロダクトオーナーをつとめるのが伊藤英明さん（HCD-Net認定 人間中心設計専門家）だ。ベテランのUXデザイナーでもある。

伊藤英明さん（株式会社ヴァル研究所）

RODEMの開発では、シビアな判断も迫られた。プロダクトオーナーとしての工夫と苦労を、伊藤さんに聞いた。

――RODEMの開発中には、苦しい意思決定もあったと聞きました。どのようなものだったのですか。

もともとは、RODEMはモバイルアプリとして、つくりはじめたんです。でも、ベータテストで利用してもらったら、コンセプトからして、ユーザーの行動をとりちがえていたことに気がつきました。

だから捨てたんです。モバイルアプリをバッサリと。まるまる3カ月分ぐらいの工数を、です。

忘れもしない、リリース前の開発中、ゴールデンウィーク明けの、開発合宿でのことです。アプリもできあがっている。ベータテストのデータを集めて、今後の方針を決めようとしていました。

ところが、ベータテストの結果、「モバイルアプリでは、出しても使われない、使いものにならない」というデータがそろってしまったのです。

2日間の合宿の、その終盤。「これはやっぱり、出しても使われないよね」という話になりました。

チーム全員で、出さない、と決めました。

――出さない、という話を切り出したとき、チームの反応はいかがでしたか。

「やっぱりそうだよね」という感じでした。開発チームの中では「しょうがない、たしかにそういう状況だ」という納得感がありました。反発はあまりなかった。

むしろ、ここまでつくってしまったけれど、リリースしなくて、社内的に大丈夫なのか、という心配をしていたほどです。

――リリースしない、とまで思わせる材料というのは、何だったんですか。

ゴールデンウィーク前までしていたベータテストは、具体的には、UXデザインのプロセスでいう「行動観察」を行うためものでした。

RODEMのモバイルアプリを、社内外の営業など外出のあるメンバーに使ってもらいました。そのようすを見るために、僕も営業回りを一緒にしました。行動観察にはポイントがあって、営業メンバーがRODEMを使っているところで、いっさい口出しをしないこと。操作を間違っても、困っていても、どう使うのかずっと見ている。

朝の混雑する時間帯で、RODEMが提示したとおりには乗り換えられない、というような場面にも遭遇しました。そういうときに、営業メンバーを観察していると、あれ、駅すぱあとで調べているな、とか、Googleマップを見ているな、とか、そういう行動をとっていました。

「移動中に、RODEMは見ないんですか？」と、何度も聞きそうになってしまうんですけど、ただ黙ってこらえて。

モバイルアプリとしてルート検索をするならば、駅すぱあとやGoogleマップに、ユーザーは慣れている。そこからスイッチして、RODEMのアプリを使ってもらうのは難しい。それが、すぐに見てとれた。

行動観察は僕だけではなく、開発のメンバーで分担しました。それぞれが、やはり同じような場面に出くわしていた。

そういうふうに、ユーザーの行動について、共通の理解があったので、リリースしないということに、開発チームの納得感はあった。

つくっちゃったから、という理由で、使われないものを出す、というのは、よくないという結論に至ったわけですが、このモバイルアプリを捨てたことで得たものもありました。

このサービスのメインインタフェースが、モバイルアプリから、想定ユーザーが普段利用しているGoogleカレンダーやOffice365 Outlook予定表などのクラウドカレンダーサービスに変わったのです。

そうなることで、RODEMのシステムはカレンダーサービス、行き先指定に用いる名刺管理サービス、交通費精算サービスなどを繋ぎ、連携して機能させる「アグリゲーションサービス」という立ち位置になりました。これが現在まで続くサービスの大きなコンセプトとなった瞬間でもありました。

――RODEMの開発はどのように進めていったのですか。

2015年末からプロジェクトをたちあげて、翌年の夏にはリリースしました。

最初は、毎月の交通費の精算を、より楽にできるようにする新しいサービスをつくろう、という、ぼんやりとしたところからスタートしました。BtoBのサービスという点だけが決まっていた。

そこで、まず価値検証からスタートしました。

具体的には、ビジネスマンの、とくに交通費の精算が多い人に、インタビューをすることからはじめました。

どういう課題がありますか、というインタビューではありません。この段階では、ふだんの交通費の精算をどうしているか、まず現状を教えてください、というインタビューです。

チームリーダーの人、管理職の人、バリバリの営業回りをする方、いろいろなタイプの人の話を聞きました。

共通してわかったのは、交通費の精算をするためには、まず自分の予定を思い出す必要があるということ。精算作業で、まず最初にすることは、今月の自分のカレンダーを見直して、いつ外出があったのかを思い出すところからはじまるんです。

そして、どういう乗り換えで、いくらかかったのか。だいたいは覚えていないので、駅すぱあとで、わざわざ乗換検索をする。

それだけでなく、さらに、わかったことがあります。

そもそも、アポが取れたとき、たとえば、ヴァル研究所で来週に商談があります、というのが決まったら、多くの人が最初にするのは、ヴァル研究所のウェブサイトを見るか、もしくはGoogleで検索して、最寄り駅を調べる。弊社だと高円寺ですね。

それから、商談が14時からの約束だったら、その10分前ぐらいに高円寺の駅に着く、という到着時間を指定して、駅すぱあとで検索して、会社を出る時間を何時ぐらいにしようかと計画する。

当日になると、具体的に何時何分の電車に乗ろうかというために、また調べ直す。

つまり、アポが取れた日と、当日と、同じことを検索する。場合によっては、移動中に、乗換駅はどこだったか、もう一回、検索をする。

そして、月末に精算するときに、また乗換検索する。けっきょく何回も何回も検索している。そういうことが日常的にある。それに気がついたんです。

じゃあ、どうしたらこの課題を解決できるだろうか。そこで考えたのが、カレンダーです。いつ、どこへ行く、というスケジュールをベースにして、移動予定を自動的につくり、精算のデータもつくる。

最初の検索をしたときに、ぜんぶ終わらせないと、そのあと何回も検索することになる。だから、1回目の検索のときに、全て完結するようにしたんです。

そして、既存のGoogleカレンダーとかOffice365 Outlook予定表をインターフェースにして、それをできるようにした。いつも使っているものからスイッチすることなく、RODEMを利用できるようにしたんです。

――伊藤さんはプロダクトオーナーという立場だったわけですが、開発チームとのコミュニケーションはどうされていたのですか。

開発チームへ、タスクを「開発してください」とただ共有するだけだと、たんに指示をカタチにする、というだけになってしまいます。

そこで、開発タスクごとに目的を明らかにしました。ユーザーはどのような行動をしていて、それをどのように変えたいのか。指標はどうするか。

MVPキャンバスをアレンジしたシートを使って、すべての開発タスクに目的づけをしました。タスクに対して、MVPキャンバスを1枚ずつつくる。キャンバスのサイズを後先考えずにA4にすると、あっという間にホワイトボードが埋まる（笑）。A4の半分サイズにしましたが、それでもスペースが足りなくて、最終的にはデジタルのツールと併用しました。

※MVPキャンバス…効率的な開発を目指して仮説と検証に用いるシート。仮説や検証理由、検証の方法、コストや結果など10の項目を記入する。AppSociallyの高橋雄介氏とリクルートテクノロジーズの黒田樹氏が開発。

RODEMのチームでは、次のスプリントに先駆けて、MVPキャンバスをチームに共有するようにしていました。仕様が不明なところはあらかじめ議論ができる。だから、スプリントに入ったときには、すぐ開発にとりかかれる。没頭できる。

スプリントの2週間はあっという間なので、コミュニケーションの齟齬による手戻りが発生すると厳しい。スプリントの前に意思疎通ができる、というのは大きいと感じました。

それも最終的には、早く改善して、ユーザーに届けて、ユーザーが使う、フィードバックを得る、次の機能を考える、という繰り返しをなるべく早くするためでした。

――お話を伺っていると、ほとんど理想的なUXデザインのプロセスを実現できているように感じます。実現できたのはなぜですか。

ここまで自由にできたのは僕の功績ではなくて、RODEMのプロダクトマネージャーを担当していた上司の成果です。社内のほかのサービス開発と切り離した、本当に独立して動けるチームをつくってくれたからです。このRODEMの開発に没頭できるチームがあった。

アプリを出さないと決めたときに、社内からあがった反論に対応してくれたのも上司です。僕らに対して、影響が出ないようにしてくれました。

それから、チームもよかった。RODEMのチームは7人で、エンジニア5人、プロジェクトマネージャとして僕の上司、プロダクトオーナーとして僕、という編成でした。その年齢層が、ほとんど同じ30代の後半だったんです。働き盛りだし、知識も十分だし、そういったバリバリ働けるメンバーで構成されていました。

ふつうだったら、中堅として後輩の育成もしながら、いろいろやらなきゃいけない立場になる年齢です。それが、同じ年代しかいないので、RODEMをつくることに没頭できた。

社風としても、カンバンによる業務の可視化など、柔軟な業務改善に繋がるマインドが根づいていました。「カイゼン・ジャーニー」の著者の一人が弊社の社員であるように、もともとアジャイル開発の流れがある会社なんです。変化を柔軟に受け入れる地盤は、もともとあった。

ユーザーを見る、ということもチームでやりました。インタビューにもエンジニアが同席しました。それから、プログラミングでペアプロやモブプロをするのと同じように、ユーザー分析もペアやモブワークでやったんです。

ユーザーの行動を僕だけで分析するのではなく、開発チームと一緒に取り組む。エンジニアも、生のユーザーの行動を見て、こういうふうに使っているんだ、というのを見る機会をつくった。そうやってユーザー像を共有していきました。

――UXデザインに必要な、さまざまな要素をうまくそろえることができたのですね。

もうひとつ、パートナーとして、ギルドワークスという会社と一緒にやれた、というのもあります。ユーザーのフィードバックを取り入れながら開発をまわしていく、というマインドのギルドワークスと一緒にやったことで、ユーザー視点を大切にするチームの体制が短期間でできました。

――RODEMを導入する会社は、どういうところが多いのでしょうか。

RODEMを導入される顧客の担当者は、経理部門や営業部門であることが多いです

経理部門は、会社全体としての精算作業のボリュームを減らしたい。営業の現場の人たちは、毎月の精算のための残業を減らしたい。

営業の現場でも、精算にかける時間は会社に利益を直接もたらす工数ではないので、できるだけ減らしたいという意図があります。

先日、RODEMも連携しているマネーフォワードさんのイベントで、NewsPicksのマネジャーの方と対談をしました。NewsPicksのマネジャーの方は、部下が深夜に申請を出してくるのに、心理として耐えられなかった、とおっしゃっていました。ただでさえ忙しくて、いっぱいまで仕事をしている。そこに交通費の精算の申請がある。それがなかったら、もっと早く家に帰せるだろう。そう思ったのがきっかけだったと。

世の中にある、いわゆる精算システムは、じつは現場が楽になっていないんです。

システムから登録されてくるデータというのは、整頓されたデータで、経理部門の負担は減ります。けれども、その登録をしている営業は1件1件、乗換検索をして入れている。そのために自分のカレンダーを見直す。現場は変わっていないんです。

その問題に気がついている経理部門の方もいます。従来のサービスだと、じつは効率化されていないところがある。そういう人たちに、今、リーチしています。

――ありがとうございました。

［取材・文：羽山 祥樹（HCD-Net）／写真：編集部］

［PR］HCD-Net認定 人間中心設計専門家・スペシャリスト 受験者を募集（申請締切： 12月20日）

現場のエンジニア・デザイナー・ディレクタ－の方、あなたも「人間中心設計専門家」「人間中心設計スペシャリスト」として認定を受けませんか？

• http://www.hcdnet.org/certified/

人間中心設計推進機構（HCD-Net）が実施する「人間中心設計専門家」「人間中心設計スペシャリスト」は、日本で唯一の「人間中心設計（HCD）」の資格として注目されています。

資格認定者の多くは、企業・団体において、

• 人間中心設計
• UXデザイン
• ユーザビリティ評価
• Web制作
• システム開発
• ユーザーリサーチ
• テクニカルライティング
• 人工知能
• IoT

などの従事者や研究者として、第一線で活躍しています。

ユーザーエクスペリエンス（UX）や人間中心設計にたずさわっている方は、ぜひ受験をご検討してみてはいかがでしょうか。

「人間中心設計専門家」「人間中心設計スペシャリスト」の、今回の受験応募は、11月20日（火）に開始します。受験申請の締め切りは12月20日（木）です。

• 人間中心設計（HCD）専門家・スペシャリスト 資格認定制度
• 申込受付期間：2018年11月20日(火)～2018年12月20日(木)
• 応募要領： http://www.hcdnet.org/certified/