同じ機能でも見積工数が大きく変わる開発案件

ユーザー目線で簡単そうな機能でも、開発者目線だと非常に大変な機能って色々ありまして、、、

今モバイルのプッシュ通知の開発を行ってるのですが、まさにこれがそうで、こういうのはお客さんとあらかじめ情報共有しておかないといけないなぁと反省してる11月です。
プッシュ通知の説明はいらないと思いますが、LINEとかメールが来たときにアプリの画面にお知らせしてくれるこういうやつです。↓

プッシュ通知イメージ
プッシュ通知って実は種類が色々あるんですよね。

大きく分けると、ローカル通知リモート通知

ローカル通知は端末の中だけで処理できる通知の仕組みです。アプリの例で言うとタイマーアプリなどがわかりやすいです。

この仕組はシンプルで、アプリ内で完結するので外部との通信を行いません。

一方リモート通知はサーバーから端末に通知を行う仕組みです。

FacebookやLINEなどがわかり易い例です。ユーザーがメッセージを送ったらサーバーが受け取って対象の人に通知を送るようなフローです。

 

ユーザー目線で言えばどちらも同じ通知で、見た目で区別できませんが開発にかかる工数は大きく変わります。

なぜなら、リモート通知は通知を送るべき対象のデバイス情報を取得しておく必要があり、その情報をサーバーに保存しておいて、サーバーはしかるべきタイミングでAppleやGoogleのサーバーに通知を送る指示を出すからです。

ざっくりした工数はこうです

  1. ユーザー情報を管理するAPIサーバーの用意
  2. そのサーバーが正規の送信元かAppleやGoogleに証明する証明書の設定
  3. アプリが端末情報をサーバーに送信して、サーバーが保存する仕組み
  4. ユーザーの中から通知対象のユーザーを絞り込む仕組み
  5. ユーザーアクションの監視

検討すべき点もいくつもあります。

  • サーバーの証明書の有効期限が切れたときの対応
  • サーバーがリアルタイムに通知すべき情報をキャッチして送信する保守体制
  • ユーザーがアプリからログアウトしたり、別ユーザーでログインした時の挙動
  • AppleやGoogleなどのプラットフォーマーが仕組みを変えてくるリスクと対応

 

要件を満たしたプログラムを作るだけで済めばいいのですが、AppleやGoogleのプラットフォームのルールが変わるリスクは保守に影響するのでそこも考えないといけません。

例えば最近だとGoogleがプッシュ通知の仕組みをGCM(Google Cloud Messaging)からFCM(Firebase Cloud Messaging) に変更しました。

当然今までGCM用に動いてたプログラムは動かなくなります。

 

などなど、同じ通知機能でも要件によってかなり難易度と予算規模が変わります。

ユーザー目線、クライアント目線だと何が大変でお金がかかり、何が安く簡単なのかわからないことはよくあると思うので、いつもご相談頂くときは、簡単で工数がかからなくてかつ大きな効果が期待できるものを最初に実装するように提案しております。

The following two tabs change content below.
西尾学
会社の代表やってます。遊ぶように仕事やってます。