改善手順
どうやるかの目処が立ったところで詳細設計〜実装に入っていきます。
ここからの工程は、
- データモデリングと各画面の入出力確認
- フォトグラファーの移動可能範囲の入力を差し替え
- 検索インタフェース変更
という順番で、継続的に利用するユーザー、フォトグラファーのインパクトを最小限に抑えるよう小刻みにリリースしていきます。
上記の改善を2018年の8月から9月にかけて実施しました。
モデル構造
到達圏APIで、スタート位置と移動可能時間を入力して取得できるデータとして
- 移動可能範囲のポリゴン
- 移動可能な駅と駅までの移動時間
があります。これを検索のための基本データとして用います。移動可能な駅と駅までの移動時間を利用して、駅から徒歩移動可能な時間を算出します。
（移動可能時間） - （駅までの移動時間） = （駅から徒歩移動可能な時間）
検索時には検索位置からNAVITIMEの最寄駅APIを使用して、位置そのものと最寄駅（と最寄駅までの徒歩時間）を取得した上で移動可能範囲とつき合わせ、検索点にフォトグラファーが移動可能か判定します。
また、都道府県のランディングページのために引き続き特定の都道府県に行けるフォトグラファーの一覧を出す必要があります。これは、都道府県のポリゴンと駅情報を保持することで対応します。定期的に駅データのメンテナンスが必要になりますが、それ以外は特にコストを必要としません。
位置入力インタフェースの実装
モデル構造が決まり、データを作るため、フォトグラファーの移動可能範囲や検索位置の設定の入力インタフェースを更新します。
ここでは、神社などのスポット名や住所を入力したら候補リストから選択し位置を決定できるようにするため、Railsに頼りきりだった検索フォームの制御をReact/Reduxで再構成することになりました。
しかし、これ自体は基本的なサーバ・クライアント間通信が必要なフォームで、複雑な内容にはなっていません。強いて苦労したことをあげるなら、神社の名前などを入力した際に同名のスポットが全国に多数ある場合など、スポット名の選択肢とその住所をあわせて表示する必要があることに気が付いたのが完成間近になってからだったことくらいでしょうか（笑）。そのため内部APIの仕様とデザインを微調整することになりましたが、その節はデザイナーに迷惑をかけました。
結果
今回の施策の結果として、予約リクエスト（ユーザーからの撮影依頼）のキャンセル率（注1）が、施策実施前の2017年11月と実施後の2018年11月を比較し、約32％→24％に減少しました。ユーザー数ベースで、この時期予約リクエストを行ったユーザーが撮影完了した割合は変わっていないので、「断られたが他のフォトグラファーを探して撮影」という手間だけが減っていることがわかります。
狙い通り「検索で出てきたフォトグラファーに依頼したが断られる」を減らす、というユーザー体験の向上ができたという結果になりました。
フォトグラファーにとっても、依頼の精度が高まり、断るためのコミュニケーションに使う負担が減るのでよかったです。
注1
予約リクエストをフォトグラファーが承認すると、予約リクエストの受付完了になります。その後の撮影〜写真受け取りまでのキャンセルは含まれていません。
考察
コアの機能ではないが重要な施策を行う際に外部サービスとの連携で実現するというのは、我々のような大きくないチームが素早く施策を実行していくためには欠かせません。しかし、何と連携するかについては実現したいことベースで都度、きちんと選択していくことが大事です。今回はNAVITIMEのサービスが要件にフィットしていたので良い結果を出せました。
また、その際に、何が問題か→何をするか→どう実施するかというプロセスを踏むことで目的を外さない改善ができました。
その後のfotowa
外部サービスとの連携は増え、2019年にはフォトブック販売でコンテンツワークスと連携し、今後もサービスの拡大・改善のための連携が予定されています。それらはこの時のプロセスをベースに、開発が実施されています。
そして今回例示したユーザーとフォトグラファーのマッチングについて、市区町村別ランディングページを新設するなど流入経路の多角化からさらなる改善の必要性が見えてきています。都度、適切なタイミングで継続的な改善を続けていきます。
以上、サービス改善に置ける具体的な思考と行動を時系列で記すことにより、現場での開発プロセスを例示しました。読者の皆さんの参考になれば幸いです。
