フロントエンド開発者、スマホアプリのニーズの不確実性に挑む――価値提供のリードタイムを最短化する工夫：Webフロントエンドエンジニアだけでスマホアプリ開発（2）

リクルートテクノロジーズが開発している、B2Bのスマートフォンアプリ『Airシフト メッセージ用アプリ』。Webフロントエンドエンジニアだけで行っている開発の裏側を明かす連載。今回は、開発計画や、ユーザーの要望を引き出すための工夫などについて。

[高橋知成，リクルートテクノロジーズ]

　こんにちは、リクルートで『Airシフト』のフロントエンドの開発を担当している髙橋です。今回は、『Airシフト メッセージ用アプリ』（以下、スマホアプリ版）を開発するに当たっての開発計画や、ユーザーの要望を引き出すための工夫を紹介します。

　連載第1回でお話しした通り、スマホアプリ版の開発プロジェクトは、『Airシフト』Web版への課題を起点としてスタートしました。しかしそもそも『Airシフト』は、PC／タブレットでの使用を前提として、設計と開発が行われていました。

　というのもシフト表作成という作業は、「前期のシフトと見比べる」といった工程が必要となるため、「大きな画面で行わないと難しい」と考えられていたからです。よって、スマホの小さな画面で操作されるときにどのような価値をユーザーに提供すればよいのか、われわれは答えを持っていませんでした。

　そのためまずは、ユーザーの要望を基にして、スマホアプリ版が提供する価値を検証しながら開発するという工夫を行いました。

初回リリースで提供する機能の選定

　『Airシフト』のWeb版は、2018年4月に公開されました。公開されてから、ユーザーへの定性的なインタビューを定期的に行っていく中で、ユーザーの感じている課題が見えてきました。

　中でも最大の課題となっていたのは、リアルタイム性が求められる「チャット機能」です。例を挙げると、アルバイトのAさんが明日のシフトの開始時間を遅くしたいというメッセージを送った場合、シフト管理者はPCを起動させWeb版を開いたときに初めてそのメッセージに気付き、慌てて返信するしかありませんでした。こうしたリアルタイム性に関する課題は、スマホアプリ版を提供することで、PUSH通知機能によって効果的に解決できる見込みがありました。

　また同時に、「1カ月のシフト表の作成は画面が大きなPCで行い、スマホでは単発のシフト調整を行う」というように、目的によって利用ツールを使い分けているユーザーがいることも分かりました。

　開発に当たっては、Web版でできることを全部スマホに移植するという選択肢も、もちろんあります。しかし、「ユーザーがWeb版の機能をそのまま全てスマホで同じように使いたいのか」については不確実でした。また、もしいらない機能も含めて作ってしまうと、その機能に費やしたコストが無駄になるだけではなく、有効な機能のユーザーへの提供や価値検証までのリードタイムが遅くなってしまいます。

　そのためこの開発では、ユーザーにとって明確な価値がある機能をより早く提供し、不確実な部分については、リリース後にユーザーからの声と利用状況を基に価値検証を行うという前提で進めることになりました。

　しかし一部機能しか提供していないことにより、以下のリスクが発生する可能性が考えられました。

1. アプリダウンロードサイトから流入したユーザーが、使い方が分からず離脱してしまう
2. 機能が制限されていることに不満を持つユーザーが生まれてしまう

　これらのリスクについては、スマホアプリ版の紹介ページとUIをユーザーに対してコミュニケーションをとれる状態に設計することで、低減することにしました。

Android開発を選択しなかった

　開発に用いたReact Nativeは、クロスプラットフォーム開発が行えるアプリケーションフレームワークです。しかしUI部分においては、iOS／Androidそれぞれに最適なものを提供しようとなると、個別で実装しなければなりません。

　Web版のユーザー分析を行ったところ、スマホからアクセスしているユーザーの大部分がiPhoneを使っていることが分かっていました。よって、最速でユーザーへスマホアプリ版を提供し、価値検証を進めることを考え、初回はiOSのみでアプリを提供することにしました。リリース後の現在も、引き続き価値検証を進めながら、対応プラットフォームについて検討しています。

価値提供のリードタイムを最短化する工夫

　スマホアプリ版として提供すべきユーザー体験が、Web版と大きく異なることは分かっていました。しかし、せっかく開発した機能がユーザーの課題を解決できていないのでは、それまでの開発時間が無駄になってしまいます。

　そこで、ユーザーからのフィードバックを基になるべく早く軌道修正ができるようにしたいと考え、開発初期からユーザーに協力してもらい、二人三脚でスマホアプリとしてのあるべき姿を考えながら開発しました。

　具体的は、日頃から接点のあるユーザーの中から、タイプごとに異なる少数のユーザーに協力をお願いし、クローズドβのテストや定期的なインタビューに参加してもらいました。その際はエンジニアもインタビューを行い、ユーザーとコミュニケーションをとりました。そしてユーザーの使っている様子から、「使いにくそうな点がないか」「パフォーマンスは問題なさそうか」といったインサイトを得ることができました。

ペーパープロトタイプとユーザーインタビューを駆使した開発

　開発初期には、認証部分といったスマホアプリとしての基盤部分の開発と並行して、「InVision」のプロトタイプ機能を用いたUI／UX部分の検証を進めました。

　InVisionのプロトタイプ機能では、画面遷移などができるインタラクティブなプロトタイプを、スマホアプリを通じて操作することができます。開発の流れとしては、まずデザイナーが「Sketch」でUIパーツを作成し、InVisionを通じてチーム内へデザインを共有します。そしてデザイナーが、そのままデザイン作成と併せて、InVisionのプロトタイプ機能を用いてペーパープロトタイプを作成します。そのプロトタイプを使ってユーザーにインタビューを行い、フィードバックを基にUIのブラッシュアップや確認を行い、実装予定のUI／UXの価値検証を行っていきました。

　今回は、この段階で大きな方針転換が必要になることはありませんでしたが、このようになるべく早く検証できる部分を進めることで、軌道修正に生じるコストを最小限に抑えることができます。

クローズドβリリースによる価値検証と品質強化

　最低限の機能が実装された段階で、協力してもらっているユーザーの端末に開発途中のアプリ（クローズドβ）をインストールし、業務の中で使ってもらいました。ペーパープロトタイプだけでは見つけにくい課題があるのに加え、使っていく中でユーザーが新たに感じた課題や発見などを、なるべく早く開発チームが検知するという意図があったためです。またこの工程は、ユーザーの業務に支障を与えるクリティカルな欠陥がないかどうかを確かめるのにも役立ちました。

　開発中のアプリを配布するツールは、「Visual Studio App Center」（以下、App Center）の他に「DeployGate」など複数あります。『Airシフト』では、アプリのビルド環境も併せて提供してくれることなどから、App Centerを使っています（※App Centerについては次回以降の記事で詳しく紹介する予定です）。

想定した機能を大幅に削り、リリース

　プロトタイプツールやクローズドβ配布ツールを使い、なるべく早い段階からユーザーからのフィードバックを得たことで、当初ユーザーにとって必要だと思われた機能のうち、不要となる機能が分かりました。結果として、想定した機能を大幅に削り、ミニマムでリリースできました。

次回予告

　次回は、『Airシフト』のスマホアプリ版を開発するに当たっての技術的な工夫を、前回も担当した辻から紹介する予定です。

筆者紹介

髙橋 知成（たかはし ともなり）

リクルート SaaS領域プロダクト開発部　Laborプロダクト開発グループ所属

2018年4月、リクルートテクノロジーズに新卒入社。現在は、店舗向けシフト管理サービス『Airシフト』の開発に従事。都内の銭湯巡りにハマり中。