位置情報付きのマンホール画像情報ポータルサイトである、拙作「マンホールマップ」を作って運用しています(詳しくはこちら):
2017052401


このサービスに限った話をすると、仕様を決める&変えるのも、作るのも、管理運用するのも、基本的には全部僕が1人でやっています。なので現状 DevOps 的な観点では非常に楽ちんです。

ただ一般的(?)にはこれらは分業制が取られることが多いです。そこで DevOps 的なアプローチやツールが活用されたりするわけですが、特に「業務で地図アプリを作る」場合に意識しておくべきことが大きく3つあります:
(1) どこの地図 API を採用するのか?
(2) (1) の API が有償の場合、誰が支払いをするのか?
(3) 誰がキーを登録するのか?



まず (1) です。一般的、というか理想的にはまず最初に仕様を決めて、その仕様にあったものを作っていきます。地図アプリの場合、「その地図を使ったどういうアプリを作るのか」というのが仕様にあたるわけですが、「それが実現できるのは、どこの地図か?」ということを意識して決める必要があります。ウェブで使える地図にも Google MAP だったり、Yahoo! Developers の YOLP だったり、オープンマップだったり、・・・と色々あって、まず地図の見た目からして異なります。そして持っている機能や拡張機能も異なります。アプリケーションサービスとして作る場合は、そこから提供されている API でどこまでできるのか/できないのかも異なってきます(更にいうとウェブ上の情報量も異なります)。というわけで、やりたいことを実現できる地図はどこの地図か? を見極めるのがかなりの労力を要する作業になります。 機能や情報量の面で比較的メジャーなのは Google MAPs だと思っているので、とりあえず Google MAPs にしておけば柔軟な対応も可能にはなりますが、その場合は (2) の問題を意識する必要がでてきます。

次に (2) です。例えば Google MAPs は商用利用可ですが有償です。この利用料金を支払うのは仕様を決める人?作る人?管理する人?それとも別の人?作る内容によって利用頻度(つまり料金)が変わることもあるし、作っている段階で支払いが発生する可能性があるものですが、開発時の利用ルールを決めたりするとそれが足枷になったりすることもあるので、仕様を決める人と作る人、管理する人が分かれていたりすると、この支払い責任を誰が持つのか、というのが悩ましくなります。

#かといって無償のだと、それなりの機能だったりします。。。

最後に (3) です。ほとんどの地図 API はコードを書けば動く、というものではなく、アカウントを作って、そのアカウントを使ってアプリケーションキーを登録し、そのアプリケーションキーを使ってコードを書く、という開発スタイルになります。ということは、極端な例えですが、アプリケーションキーを誤って消してしまったりするした場合、作ったアプリケーションの地図は動かなくなってしまいます。 そんな大事なアプリケーションキーを管理するのは仕様を決める人、作る人、管理する人、誰のアカウントで作るべきでしょうか? で、これも (2) 同様に誰の権限でこのキーを登録するか、という問題が生じるわけです。


以下は私の私見です。

最終的な運用をイメージしなければ(試験的に使ってみるだけなら)、(2) と (3) は作る人がやると手っ取り早いと思います(試験的であればおそらく (1) も)。が、実際の運用を考えるとこれは運用者の責任範囲で行うべきです。が、そうなると見積もりとかいろいろ話が長くなって、なかなか進まなくなるというのも現実です。また実際の運用となると「商用利用」だと思うので、(1) の選択肢においても利用規約を意識する必要がでてきて、話がややこしくなるわけです。


単に「アプリで地図を使う」だけでも、上記のようなややこしい要素が含まれていて、これらを意識しておかないと (1) の調査や稟議で時間がかかってしまったり、仕様変更時に (1) に戻らないといけなくなったり、(2) や (3) で見積もりや手続きで時間がかかってしまったり、、、ということが起こり得るのでした。逆にこの辺りをタイムリーに判断できると、地図アプリを効率よく開発・運用していけるのだと思っています。