場所検索の原価を月415円からゼロにした — ただし規約が1つ、設計を縛ってきた — 制作日誌 #16
ビジネス

場所検索の原価を月415円からゼロにした — ただし規約が1つ、設計を縛ってきた — 制作日誌 #16

住所の入力補完・店の詳細・近くの駅。この3つで月415円払っていた。同等のことが無料でできる仕組みへ全面的に移したが、「データを使うなら地図も出せ」という規約のせいで画面の作りまで変わった。

KIYODO00
#個人開発#iOS#コスト#地図#制作日誌

タスクアプリには「場所」を扱う機能がある。タスクに場所を紐付けて、近くに来たら知らせる、といった使い方だ。この場所を探す部分で、外部の有料サービスを3種類使っていた。

実際にかかっていた額を、1か月ぶん洗い出した。

処理使っていたもの単価その月の実額
住所・店名の入力補完有料の補完サービス1回 約0.7円206円
場所の詳しい情報有料の検索サービス1回 約2.4円207円
近くの駅を探す有料の周辺検索1回 約1.1円2円
合計415円/月

月415円。金額としては小さい。だが利用者が増えるほど比例して増える性質の費用で、しかも収入(広告で月40円前後)を大きく上回っている。使われるほど赤字が増える構造になっていた。

端末側の仕組みへ全面移行した

移行先は、OSに最初から入っている地図の仕組みだ。同じことがほぼできて、利用料がかからない

移行後の原価はこうなった。

移行前移行後
場所検索まわり415円/月0円
経路(車・徒歩)42円/月42円/月
経路(電車・バス)55円/月55円/月

場所検索の費用が丸ごと消えて、残るのは経路の97円だけになった。

このとき、設定で「どちらを使うか選べる」ようにはしなかった。切り替えを残すと、両方の実装を永久に保守することになるうえに、有料側が黙って使われ続ける事故も起きる。片方を消す判断のほうが、あとが軽い。

規約が画面の作りを縛ってきた

ここが今回、一番学びの大きかった部分だ。

移行先の利用規約に、こういう趣旨の条項がある。

対応する地図を表示せずに、このサービスのデータをアプリ内に表示してはならない

つまり**「検索結果の一覧だけを出す」という画面が作れない**。

私が最初に考えていたのは、入力欄の下に候補をぶら下げる形だった。よくある形だし、画面遷移も要らないので使い勝手も良い。だが地図が1枚も出ない画面は、この条文を満たしようがない

リンクを添える、小さく地図アイコンを置く、といった逃げ方も検討したが、条文が求めているのは「対応する地図の表示」なので満たせない。結果として、

  • 候補は地図と同じ画面(地図つきの選択画面)の中にしか置けない
  • 入力欄の下に候補をぶら下げる案は破棄

という結論になった。費用の話から始めた変更が、画面設計まで書き換えたわけだ。外部サービスを選ぶときは、単価だけでなく**「使う条件」まで含めて選ばないといけない**と痛感した。

落とした機能

移行先は、店の評価の星を返さない。返さないものは出せないので、星の表示は機能ごと落とした。

これは判断が要る場面だった。星が無いと、飲食店を選ぶ用途では明らかに情報が減る。それでも落としたのは、

  • 星のためだけに有料サービスを1つ残すと、原価ゼロ化の意味がほぼ消える
  • 星があるサービスと無いサービスを混ぜると、同じ画面に出どころの違う情報が並ぶ

という2点からだった。「全部無料に寄せる」か「全部有料のまま」かの二択で、混ぜないほうが健全だと判断した。

移行でやったこと

  • 座標だけを持っている場所を名前に戻す窓口を、自前のサーバーに新設した(移行先の検索は文字列を要求するので、座標だけでは引き当てられない)
  • 場所を扱う処理を1ファイルにまとめ直し、呼び出し側からは移行先が見えないようにした
  • 地図つきの選択画面を移植して、7言語に対応させた。「近くの駅」もこの画面の中に同居させた
  • 使わなくなった有料側の選択画面(約380行)は削除した

最後の削除が大事で、残しておくと「切り替えを戻せる」という誘惑が残り、両方を保守することになる。

移行の副作用:規約の縛りは連鎖する

「データを使うなら地図を出す」という条項は、1つの画面だけの話では終わらなかった。場所を扱う画面は他にもあるので、全部の画面で同じ条件を満たしているかを確認して回ることになった。

画面場所のデータを出すか地図はあるか対応
場所の選択出すあり(同居させた)そのまま
経路の検索出す選択画面の中に選択画面へ寄せた
タスクの詳細保存済みの名前だけなし自分が保存した文字列なので対象外
開発用の画面出すなし自分しか見られないので露出なし

判断の分かれ目は、**「そのサービスから今取ってきたデータを出しているか」**だった。すでに自分のデータとして保存した名前を表示するのは、また別の話になる。

こういう条項は、読んだその日に画面の一覧と突き合わせておかないと、後から機能を足すときに忘れる。移行のときに一覧表を作って、リポジトリに残した。

まとめ

  • 原価は「使われるほど増えるか」で見る。 月415円そのものより、増え方の形のほうが重要だった
  • 外部サービスは、単価と同じ重さで利用条件を読む。 条項ひとつで画面設計が決まることがある
  • 移行は片方を消すところまでやる。 切り替えを残すと二重の保守が始まる
  • 落とす機能を決めるのも移行の一部。 全部を持ち越そうとすると、原価が下がりきらない

Comments (0)

No comments yet. Be the first to leave one.