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

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

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

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

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

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

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

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

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

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

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

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

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

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

Android開発を選択しなかった

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

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

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