はじめに
fotowaという出張撮影プラットフォームの開発において、ユーザーの利便性に関する不満から来る要求と、開発による要求への対応がどのような思考と行動の流れで行われているのか。その一例を紹介します。
fotowaとは
気軽にプロのフォトグラファーを予約して、ハイクオリティな写真を撮影できるサービスです。現在は七五三の需要が大きく、ニューボーンフォト（新生児写真）にも力を入れております。その他折々の記念写真など、「ご指定の場所・時間で、イメージどおりに」思い出を写真に残すことができます。
サービス開始は2016年2月で、今年の2月末に4周年を迎えました。
参考：fotowa開発の規模感
2020年5月現在のサービス開発の規模、人員的にはエンジニア（サーバ・クライアント兼任）3名（専任でないインフラ担当1名）デザイナー2名ディレクター1名です。
システム構成は、サーバサイドはRuby on Railsで、LOCは12000行、RDBのテーブル数は100といった規模感です。商用サービスとしては「小さめの中くらい」でしょうか。
課題設定
従来fotowaでは、フォトグラファーの対応範囲を都道府県（複数設定可能）で設定するようになっていました。これにはフォトグラファーにとって設定が容易で、ユーザーにとっても検索が容易というメリットがありました。
しかし、ユーザーが都道府県単位でしかフォトグラファーを探せない割にフォトグラファーがその都道府県の全域をサポートするとは限らないという状況になっていました。対応都道府県が増えていくに従って「検索で出てきたフォトグラファーに依頼したが断られる」という事象（撮影場所のミスマッチ）が増えてきました。
これはユーザーにとって
- せっかく選んだフォトグラファーに断られるのが辛い
- 選び直すのが面倒
フォトグラファーにとっては
- 予約を断るのが心苦しい
- 断るためのコミュニケーションコストが徒労である
といった悪いユーザー体験に繋がっていました。
そこで、ユーザーが「指定した撮影場所に対し依頼を断らないフォトグラファー」を選べ、写真を撮ってもらう側と撮る側のマッチング精度を改善しようということになりました。
そしてユーザーストーリーとして「フォトグラファーの移動可能範囲をより詳細に設定できる」「詳細に設定された移動可能範囲をひく形で、撮影場所をパラメータにフォトグラファーを検索できる」を設定し開発をスタートしました。
手段の検討
何を改善するかは決まったものの、どう改善するかはこの段階では決まっていません。開発の現場では常に様々な手段を比較して費用対効果のバランスが取れたものを選んでいかなければいけません。
フォトグラファーが依頼を受ける範囲の詳細を作るための入力情報
フォトグラファーに移動可能範囲を入力してもらう必要があるので、そのパターンを検討します。
- 都道府県より細かい単位（市区町村）を選択してもらう（市区町村パターン）
- 拠点位置と移動可能時間（片道）を入力してもらう（拠点+移動時間パターン）
- フォトグラファーに地図上で範囲を囲ってもらう（自由図形パターン）
大まかに3パターンが検討の選択肢として浮かびました。
市区町村パターンは、
- 移動可能範囲を大きく取りたいフォトグラファーに手間が多い
-
隣の都道府県の市区町村などに詳しくないと、近いけどマイナーな市区町村の選択漏れに繋がりがち
- その市区町村のユーザーに不便
- fotowaの地域カバー率低下の恐れがある
- 面積が大きな市区町村について、都道府県と同じ問題が現れる
と各方面にデメリットがあるので除外し、自由図形パターンは、
- （実装できれば）フォトグラファーの入力が直感的
というメリットがあるものの、
-
フロントエンドでの工数に心配がある
- 自由図形の抽出や、図形作成中の描画にノウハウがない
-
フォトグラファーによっては複数都道府県にまたがる大きな範囲を地図上で設定する必要がある
- フォトグラファーが知覚する範囲と実際に行ける範囲のズレ（設定した図形の範囲内だが駅から遠くて、公共交通機関では行くことが困難など）の多発が心配
と、想定されるデメリットが大きい（特にフロントエンドの工数は大きな問題で、これを実装するとなると本質から外れた部分で高めの外部品質を求められる状況は避けがたい）ため、拠点+移動時間パターンを選択することにしました。
範囲設定
フォトグラファーの入力情報が決まったら次は範囲の設定です。入力された情報をもとにどのように検索できる形にするかを検討します。
最初に思いつくのは、「撮影場所とフォトグラファー拠点の直線距離が移動時間に応じた距離より短いかどうかで判定する」という手段です。
計算量も小さく単純ですが、単純に距離で判定してしまうと、離島や山越えなど行くことが不可能な地点を含んでしまいがちです。地理的条件を考慮しない単純な方法による範囲設定は、マッチング改善に繋がらないことがわかりました。
より詳細な交通手段などの条件を考慮して移動可能範囲を設定するのが望ましく、それを自前で用意するのは難しいため、外部サービスのAPIの利用を検討することにしました。
まず、既にGoogleのAPIを利用していたことから、Google Maps APIに使えるものがないか探し、Distance Matrix Serviceという適用できそうなAPIを発見しました。
これは2点間の距離と移動時間を算出するAPIで、複数の組み合わせを1リクエストで送ることができ、検索に使えるかと思いましたが、よく調べるとFAQに、
The Google Maps Directions Service, which includes the Directions API and Distance Matrix API, supports all the transit providers in the transit coverage list, except for those in Japan.
（抜粋訳：日本を除く公共交通機関をサポートしている。）
と書いてあり、利用することはできませんでした。
Googleがダメだったので、他のサービスで使えるものはないか探します。地図系サービス、乗換案内系サービス各社のAPIを調査し、NAVITIMEの到達圏APIを使うことにしました。
理由は、
- 移動手段の柔軟性が高い（公共交通手段と自動車の両方がOKでオプションも豊富）
- 道路を移動する範囲の結果が多角形で取得できるので、ピンポイントの判定が容易
- その他、位置情報系APIが充実しているので、移動可能範囲の入力や検索で合わせて使える
などで、要件にピタリと合っているものが見つかった感じです。
