はじめに

Salesforceは、基本的には社内、社外を問わずネットワークに接続できれば利用できる（VPNやネットワーク制限をかけている場合を除きます）ので、モバイル・アプリケーションとの相性はよく、お客様からもよく問い合わせがあります。テラスカイでもモバイル開発案件は行っていますが、そこで蓄積したノウハウをご紹介するために、今週から、３週間ほどモバイル開発関連の情報をこのTech blogに掲載していきます。

まず最初の週は、Salesforceを使ったモバイル開発案件における要件定義で注意するべきポイントをご紹介します。尚、今回のご紹介の前提として、iOS系のモバイル開発を想定しています。したがって、Androidについてはポイントが異なるかもしれません。しかし、Androidに関しても弊社内でノウハウを蓄積しておりますので、別途、このTech blogでご紹介する日もくるでしょう。

今週は、モバイル開発の要件定義時によくお客様からご質問をいただき、また、後々の急な追加・修正開発回避（つまり、リスク回避）のためにも抑えておきたい以下の３つのポイントについてご紹介します。

• ポイント１．ログイン画面のブランディングについて
• ポイント２．オフライン機能の要件について
• ポイント３．アプリケーションの配布方式について

また、それらのポイントを踏まえて、工数の削減や開発期間の短縮のために、どのような開発ツールを利用するべきかについてもご紹介します。 それでは１つずつポイントを確認していきましょう。

ポイント１. ログイン画面のブランディングについて

お客様が、Salesforceをプラットフォームに使用して、消費者向けにサービス提供する場合など、アプリのログイン画面を独自にブランディングしたい、などの要件がある場合があります。この場合、詳細な要件として以下のような機能が挙がる場合があります。

• ログイン画面は通常のSalesforceのログイン画面のロゴ画像を変更する程度ではなく、デザイナーによってデザインを施した綺麗な画面にしたい
• ログイン画面自体にも、プロモーション情報の表示やバージョン番号の表示など機能を持たせたい

これらの要件に応える場合、Salesforce公式のMobile SDK（以下、Mobile SDK）を利用しづらくなってしまいます。なぜなら、Mobile SDKは、ログイン画面や認証の機構も提供してくれる（図１）のですが、そのログイン画面がOAuth認証前提になっており、Web上にHTMLで実装されたカスタマイズのできないログイン画面であるからです。

図１.Salesforce標準のログイン画面

もちろん、Mobile SDKを使いつつ、ログイン画面だけネイティブな画面としてカスタマイズ実装し、ログイン後に取得したトークンだけをMobile SDKが持つ認証機構に渡す、などの手段もおそらく不可能ではなく、個人的には検討したことはありますが、あまり見通しはよくなく、その方式の採用には至りませんでした。

したがって、現状、ログイン画面をブランディングするかどうかで、強力な機能を提供してくれる公式のMobile SDKを選択肢として選べるかどうかが変わってきます。ブランディングが不要な場合は、Salesforce1上で画面を作成すれば充分要件を満たせる場合もあるでしょう。

なお、独自ブランディングをしたログイン画面をネイティブアプリで実装する場合、SalesforceのAPIを呼び出してロジックを実装する部分をすべて自前で実装するのは現実的ではないので、SOAP APIをラップしたライブラリであるzkSforceの利用を検討するのがよいでしょう。zkSforceについては次週のブログでご紹介します。

ポイント２. オフライン機能の要件について

モバイルアプリ開発をする場合、オフラインでの利用が要件定義時の話題にあがることはよく有ります。これについても注意すべき以下のようなポイントが有ります。

1. 本当にオフライン機能は必要か？
2. オフライン機能実現時のセキュリティ面
3. 認証のオフライン化をどうするか

それぞれについて、もう少し詳しく説明をします。

１．本当にオフライン機能は必要か？

オフライン要件はよく話題にあがるのですが、よくよく確認していくと、オフライン機能を提供する必要がそれほどない場合もあります。

ここ数年、地下鉄ですらオンライン化が進み、都心部に限ると、今後の傾向としてオフラインであるエリアが少なくなっていくことが想像されます。つまり、オフライン機能が必要なユーザー数は年々減っていくかもしれません。

その状況を踏まえて、オフライン機能が本当に必要であるのかは、充分に検討したほうがよいでしょう。オフライン機能を実装する場合、アプリの根本的な前提が変わるため、開発工数も膨らむことが予想されます。つまり、開発費用が膨らむ可能性が高いのですが、その割にその恩恵に預かれるユーザーが少なくなっていくため、本当にそのコストを費やしてまでオフライン機能を提供するメリットがあるのかどうかは、確認をしておいた方がよいです。

ただし、以下の様な場合ではオフライン機能が必須になるでしょう。

• モバイル端末を利用した業務を行う場所が地下である、など、そもそもオフラインなエリアでアプリを使用する場合
• 都心部ではなく、地方の山間部などデータ通信できない可能性が高い場所で業務が行われる場合

２．オフライン機能実現時のセキュリティ面

モバイル端末でオフライン機能を提供する場合、端末のローカルファイルシステム上に業務のデータを蓄積する必要がでてきます。その場合、問題になるのが端末紛失時にデータをどのように保護するのか、という点です。

ローカルのデータの保存時に暗号化をしておく必要があるのは当然として、リモートからデータを消去（リモートワイプ）する機能や端末の位置を知るための機能が必要になるかもしれません。

開発するアプリケーションを使用するのが、企業の社員など端末を一定の管理下における状況であれば、いわゆるMDM（Mobile Device Management）機能を持ったサービスやシステムを導入するのがよいでしょう。MDM製品にはクラウドで利用できるCLOMOや、クラウド以外にイントラにサーバーを立てて利用することもできるMobile Ironなどの製品があります。

アプリを使用するのが特定の企業の社員ではなく、一般消費者の方である場合は、MDMを導入することはできません。そのユーザーの方がiCloudを個人的に設定されていれば、iCloudの「iPhoneを探す」機能で端末の位置の確認やメッセージの送信、リモートからのデータ消去などを行うことができますが、そうでない場合は、アプリ内にデータ消去の仕組み（例：　アプリ起動時で認証前に、最後に利用した時間から一定の時間が経過していれば、ローカルのデータを消す、など）を実装しておく必要があるでしょう。

いずれにせよ、ここで言いたいことは、オフライン機能を提供する場合、単にオフライン機能だけを開発すれば良いわけではなく、こういった運用や紛失時の対応を含めたセキュリティ面と、それを支える仕組みも含めて考える必要がある、ということです。場合によっては、その分、開発規模は大きくなってしまいます。

３．認証のオフライン化をどうするか

オフラインで業務を行う場合、大きな問題になるのが、ログイン認証です。

Salesforceはクラウド上のサービスですので、認証を行うためにはサーバーと通信をする必要があり、オンラインである必要があります。したがって、この点について考慮しておかなければ、オフラインで作業をし、しかもログインをするのを忘れていた場合、業務が全くできなくなってしまいます。では、この点についてどのように対応するのがよいでしょうか。

この問題は、あまりシンプルではありません。例えば、この問題を解決するために、ログインする可能性がある人のユーザーIDとパスワードを端末のローカルDBにも持つようにした場合、仮にデータを暗号化していたとしても、非常にクリティカルな情報を各端末が持つことになってしまい、リスクを考慮するとそのような対策はできないでしょう。また、サーバー側でパスワードが変更された場合にどうするか、などのデータの同期の問題も発生します。例えば、この場合、オンライン時に最後にログインしたユーザーのIDとパスワードだけを保存しておき、最後に利用した人だけがオフラインでも認証できる、といった制限付きのオフライン認証機能を実現する、などのやり方を検討するのがよいでしょう。この際、一時的に保存する認証情報については、KeyChainServiceを使用してセキュアな領域に保存しておくことになります。

それらを踏まえた実装方針

オフライン要件を実現する場合、Salesforce1だけでの実装は難しくなります。したがって、ネイティブアプリを開発する必要が出てきますが、Mobile SDKにはオフライン時のデータストアとして、SmartStoreという機能が提供されており、データの暗号化や、オンラインになったときのローカルとサーバーのデータをマージする方式選択など、便利な機能も利用できます。オフライン要件があり、ログイン画面の独自ブランディングが不要な場合は、Mobile SDKのSmartStoreを利用するのがよいでしょう。SmartStoreについての詳細な説明は今回は省略しますが、2013年のDreamForceでオフラインアプリケーションの開発について説明されていますので、興味のある方は確認してみるとよいでしょう。

ポイント３. アプリケーションの配布方式について

作ったアプリケーションを誰に対して、どのように配布するのか、という点を考えておくのも重要です。アプリの開発を弊社のようなSIerが行う場合でも、実際に配布する企業（お客様）にAppleへの開発者登録をしていただく必要があります。

そして、お客様が想定されているアプリケーションのユーザーが社内にいるのか、社外の人なのか、また、BtoCなのか、BtoBなのかによって、以下の様に開発者登録すべきプログラムが変わります。また、登録したプログラムによって、Appleの審査の有無が変わります。審査がある場合は、ガイドラインに準拠する必要がでてきます。

例えば、お客様が、Salesforce Communities for partner を利用していて、販売代理店企業にアプリケーションを一般ユーザーには非公開で配布したい場合は、カスタムB2Bアプリケーションを使用する必要があります（表１のケース３、これは無料配布も可能）。非公開にする必要がなければ、通常のApp Storeでの配布も可能です（表１のケース２）。

要件に従った開発ツールの選択

以上の説明を踏まえて、ざっくりと利用するSDKや開発ツールの選択方針を表にすると次の表２のようになります。

おわりに

今回は、要件定義時において特に注意すべきポイントを３つ紹介しました。これらのポイントはどの案件でも必ず確認が必要になる重要な部分ですので、ご検討する際に参考になれば幸いです。

次回は、「zkSforceを使用したネイティブアプリケーションの構築」について紹介します。zkSforceについては、日本語の情報がほとんどなく、こちらも参考になると思いますので、是非ご一読いただければと思います。