皆さんこんにちは。 今回はこれからSalesforceの各種サービス、Force.com Platformを使ってアプリケーションの開発プロジェクトをする人に向けて、プロジェクトの各フェーズで意識したいことを書きたいと思います。
システム開発全般における話しだったり、Salesforceサービス特有の注意事項だったりいろいろとありますが、今後開発をする人の助けになれば幸いです。
また、一応フェーズを分けて記載をしていますが、プロジェクトを進めているとフェーズの分割が曖昧になることも多いので、その辺は適宜前後させながらお読みください。
導入準備フェーズ
1.導入の目的を明確にする
Salesforceでの開発に限りませんが、システムを構築する上で目的を明確にすることは大切です。
目指すべきゴールが決まっていないプロジェクトは、問題が発生した時に指針がぶれてしまい、リカバリが難しくなります。
またユーザの「あったらいいな」で、あれこれと機能を追加してしまい、必要以上にリソースを使ってしまったり、あるいはリスクを高めてしまいます。 プロジェクト内の様々な判断に使うためにも、まずはシステム化する目的を明確にしましょう。
2.エンドユーザも含めたプロジェクト体制
プロジェクトの体制には、ぜひ実際の利用部門の人を含めましょう。
利用する人の意見が考慮されていないシステムは実際の業務内容と噛み合っていなかったり、 あるいは分かりづらいなどの理由で使われなくなりがちです。 ぜひ、利用者となる人の意見も取り込めるような体制にしましょう。
ただし、人が多すぎても打合せが紛糾してしまい、プロジェクトの進捗が遅れてしまう可能性もあるので、人数を1～2人に絞ったり、あるいは打合せに参加するのではなくて、早いタイミングから触れる環境を用意することで、実際に触ってもらってフィードバックを貰えるようにすると良いでしょう。
3.開発部門、開発ベンダーに任せきりにしない
要件を出す部門（企業）は日々の業務とかけもちして、システムの開発プロジェクトに関わることが多く、とても忙しい人が多いです。 そういった理由もあってか、要件だけ出してその後をIT部門や開発ベンダーに任せっきりにしてしまうと、出来上がったものが思っていたものと違い使い物にならないというリスクが高まります。
また、運用後のことを考えても、利用部門が開発に関わっておくメリットはあります。 Salesforceの大きな特徴として、簡易な要件であればITにそれほど詳しくない利用部門であってもシステムの改修が可能です。
積極的に開発に関わることで運用が始まった後でも、IT部門やベンダーに頼らず利用している自分達でシステムを改善していくことができます。 プロジェクト期間中は通常業務をほどほどにして、開発プロジェクトに時間をとれるよう事前に準備やお願いをしておきましょう。
4.要件に適したSalesforceライセンスを選択する
SalesCloud、ServiceCloud、MarketingCloud、Force.com、Communities等々、Salesforceのサービスやライセンスは沢山あります。 また、それぞれのサービスにエディションが存在し、それにより利用できる機能も異なります。
単に安いからとか、人に勧められたからとかではなく、自分達の利用したい機能に沿ったライセンスを選択しましょう。
選択する時に考慮したいのは機能（利用オブジェクト）はもちろんですが、ストレージ容量やSalesforceのサポートレベル、開発環境となるSandboxの種類も気にしたいところです。
後から「ライセンスを変えたい」という要望を聞くことがありますが、多くの場合大きな困難とリスクを伴います。 後悔のないライセンス選びをしましょう。
後から「ライセンスを変えたい」という要望を聞くことがありますが、多くの場合大きな困難とリスクを伴います。 後悔のないライセンス選びをしましょう。
5.Salesforceを理解する
開発者がSalesforceを理解するのは当然ですが、要件を出す部門（企業）側もSalesforceを知ることは重要です。
Salesforce独自の用語や機能名を知っておくことでプロジェクトを円滑に進めることもできますし、先にも述べましたが、Salesforceの良さはカスタマイズ性にあります。 様々な機能やカスタマイズ方法を知っておけば、運用に入ってからも自分達でシステムを改善し、より使いやすくすることができます。
Salesforceを知るにはWeb上のコンテンツで学ぶことも良いですし、セールスフォース・ドットコム社や弊社などベンダーが提供しているトレーニングを受けると良いでしょう。
6.利用者の環境を確認する
Salesforceのサービスや機能は動作がサポートされている環境が決まっています。逆に言えばサポートされていない環境もあります。 フルサイト版であればブラウザの種類やバージョン、モバイルによるアクセスはSalesforce1というアプリを利用することが多いので、モバイルデバイスのOSなど利用者の環境を確認しておきましょう。
特に古いブラウザだとサポートがされていなかったり、機能を使えないといった制限などもあります。モダンブラウザではない場合、開発する上でのライブラリの選択の幅が狭まったり、パフォーマンスへの影響も懸念されます。 ブラウザに限らず、Excel出力をする場合はOfficeのバージョンなど、事前にユーザの利用環境を確認しておくと良いでしょう。
要件定義・基本設計フェーズ
7.開発環境と移行方法を検討する
ここでいう開発環境とはSalesforceの組織のことです。
SalesforceでApexによる個別開発を実施する場合、本番（運用）環境では開発ができないという制限があります。 Sandboxを使うのか、Developer Edtionを使うのか、それらから本番環境に移行する方法やタイミングはどうするか、開発環境が複数になった場合やシステムテストを実施する場合はステージングの組織を用意するかなど、検討することは多々あります。
また移行のタイミングとSalesforceのバージョンアップの時期が重なると、組織間でバージョンが異なることになるので、バージョンを統一させておくか、あるいは新機能を使わないなど注意が必要です。
8.標準機能を使ってプロトタイプの構築と評価を繰り返す
Salesforceは業務システムとして必要になる、多くの機能が標準として用意されています。 また、簡易なデータ参照・登録・更新・削除といった機能（画面）も標準として存在します。これらの標準機能を使い業務要件を確認しながらプロトタイプを構築していくことで、素早く動作するシステムが出来上がっていきます。
ユーザはこれらの動くシステムに対して実際に触りながら評価をし、開発者はその意見を反映するということを繰り返していきます。 ドキュメント上やモックでの見た目の確認だけではなく動作するシステムを触ることで、実際に出来上がったものとのギャップを少なくすることができます。
9.できる限り標準機能を使って実装する
プロトタイプの構築をする際には、業務的に問題ない範囲であればできる限り標準機能を使って実装しましょう。
画面やビジネスロジックの個別開発をすることで現行のシステムを踏襲したり、業務に合わせたシステムを作ることも出来ますが、時間やコストなど様々なリソースが必要になってしまいます。
また、年に3回あるメジャーバージョンアップで標準機能は強化されていくので、今できないことも将来的には出来るようになるかもしれません。 標準機能での実装であれば、バージョンアップ時に原則的に既存への影響はありませんが、個別開発をしていると影響が出る可能性も高くなります。 Salesforceを利用する場合は、出来る限り標準機能を使って実装しましょう。
10.データ容量を算出する
プロトタイプを構築していくと、だいたいのオブジェクト構成が決まってきます。このあたりのタイミングで各業務からトランザクションデータがどの程度発生し、各オブジェクトにどのくらいのレコードが入る見込みか計測しましょう。
ここで考えるのは、まず全体の組織ストレージに収まるかどうかです。 Salesforceではライセンスの種類やユーザ数によって、組織の容量が決まります。また、各レコードは特殊なオブジェクトを除いて1レコード2KBで計算されます。
これらを計算した上で、適切なシステム稼働年数でデータが増えても十分に収まるかどうか確認します。 ストレージだけ追加購入することも可能ではありますが、予算の都合もあると思いますので、オブジェクト構成や設計、ユーザ数、ライセンスの種類など、様々な要素を含めて検討しましょう。
データが多すぎて問題になるようであれば、一定期間経ったデータはどこかに退避して削除することも検討すると良いと思います。
11.AppExchangeで提供されていないか確認
AppExchangeはForce.comアプリケーションのマーケットプレイスで、有償から無償のものまで様々なアプリが存在します。
購買管理や勤怠管理といった特定業務をカバーできる大きなアプリから、郵便番号検索といった入力補助、設定取得や画面開発ツールといった開発者を助けるものまで、実に様々なアプリケーションが登録されています。
要件定義を進める中で標準機能で実現できないようなものがあった時、1から個別開発するという方法もありますが、その前にAppExchangeサイトを見て登録されていないか確認してみてください。
12.スコープを調整する
Salesforceに限りませんが、システム開発をしているうちに当初の要件より膨らんでしまったり、あるいは最初は標準機能で予定していたが業務的に対応が難しく、個別開発することになる機能も出てくるでしょう。 期間を延ばせますか？予算を増やせますか？・・・たぶん難しいでしょう。
そういう時は開発範囲を調整しましょう。要は実装する機能や内容をトレードオフします。優先順位を考えて、必要な機能から実装リリースします。「全部必要だから優先順位なんて付けられない」なんてことはないでしょう。最初に考えた、システム化の目的・ゴールから考えた時に、その機能は本当に必要か？といった観点で検討するとよいでしょう。 優先順位の低い機能はあくまで「今回は作らない」だけであり、次の開発サイクルの中で再度検討してみましょう。
実際はリリースして利用者の意見を聞いてみると、意外と必要なかったり、あるいはもっと優先度の高い要望が出てくると思います。
13.運用も考えた設計にする
作られたシステムは当然ながらリリース後運用されていきます。むしろ運用が始まってからが本番です。
そうしてリリースした後はちょっとここを変えたいとか、あるいは機能を追加したいという要望が出てくることは自然なことです。
そうなると、システムにより柔軟性を持たせ、後から変更を用意にした設計にすることは非常に重要になってきます。 例えばカスタム表示ラベルを使ってメッセージを容易に変更できるようにしたり、カスタム設定を使って何らかの挙動を変更できるようにしたりなど。 他にも権限セットや項目セットなど運用に便利な機能をどんどん利用しましょう。
開発・テストフェーズ
14.ガバナ制限を理解した開発
Force.comはマルチテナントのプラットフォームとなっており、1つの組織でコンピュータリソースを占有することを避けるためにガバナ制限が存在します。
細かい制限についてここでは触れませんが、開発する上で各ガバナを理解し、回避した開発を心がけましょう。 ガバナ制限はForce.comエンジニアのお友達です。仲良く付き合うことが大切です。
15.Force.comの制限の拡張
ガバナ制限もそうですが、Salesforceで開発すると様々な制限にぶつかることがあります。
それらの制限値を考慮した上で開発することも大切ですが、この制限値を緩和する方法もあります。 例えば1オブジェクトに作成できる積み上げ集計項目の数や項目履歴管理の数、APIコール数のリセットなどなど.. 緩和についてはサポートデスクにケースで依頼すれば良いのですが、緩和可能な種類や数などあるので、詳しくはSalesforceサポートに確認しましょう。
当然ながら必ずしも緩和できるものばかりではありません。ただ、制限値にどうしても困ったら、諦めずにまずはサポートデスクに依頼してみるという方法もあることを覚えておきましょう。
16.組織依存しない開発
開発組織となるSandboxやDeveloper Edition、本番組織、ステージング環境...Salesforceでは様々な組織を利用します。 開発する際は作った機能がどこの組織に移行されても動作するようにしましょう。
具体的にはSalesforce内のURLを定義する際にhttpsからのフルパスにするのではなく相対パスにしたり、内部的なID値は組織によって変わる可能性があるのでベタ書きで使わないようにするなど注意が必要です。
17.ベストプラクティスに沿ったテストメソッド
SalesforceではApexの開発において必ずテストコードが必要になります。
テストコードは本番にデプロイする際に75%のカバレッジとエラーがないことが条件になるので、どうしてもカバレッジやエラーがないことばかりに意識がいってしまいますが、それはあくまでデプロイするための最低条件です。
本来テストコードは開発した機能が想定通り動くかどうかを確認するためのものなので、カバレッジというのはその結果に過ぎません。 開発者は「正常系」「異常系」「シングルレコード」「バルクレコード」「セキュリティ」などのパターンを考慮してテストコードを書くことを意識しましょう。
18.運用も考えた開発にする（再掲）
先にも述べましたが運用後の改修も考えられた開発にしましょう。 システムはリリースして終わりではありません！
19.パフォーマンスチューニング
各オブジェクトに入るデータ量を見込んだ上で、パフォーマンスが十分に出る設計・開発を行います。 データ量はSOQLやレポート、ビューなどに影響します。
経験的に1オブジェクトに10万件以下であれば大きく問題になることはありません。それを越えるのであれば、外部IDによるインデックスやカスタムインデックスの検討が必要になるでしょう。
また、場合によってはディビジョンやスキニーテーブルの利用も検討します。 大量データについては「大量のデータを使用するリリースのベストプラクティス - 日本語 ※PDF」のドキュメントを読むと良いでしょう。
移行・リリース前フェーズ
20.移行対象データを検討する
移行の対象とするデータを選定しましょう。（実際にはもっと前の移行計画から考えるべき内容ではあります）
前述した通りデータ量はストレージやパフォーマンスに大きく影響するので「使うか分からないけどとりあえず過去データも全部入れておこう」ではなく、必要な分だけ移行します。 コンプライアンス的な理由でとっておく場合でも、Salesforceには入れずにとっておくこともできるはずです。
21.システム項目を任意値で移行する方法
データ移行時に特に何も考えずにデータを登録すると「作成日」や「作成者」といったForce.comが自動で付ける監査項目はデータ移行日や実行者になってしまいます。
特に問題なければそれでもいいのですが、既存システムからの移行の場合、データはその前システムに登録された日とかにしたいですよね。 Salesforceではサポートに依頼すると監査系の項目がcreateableになります。
ただし、期間が限られていたり、Insert時のみといった制約などもあるようなので、この件を検討する場合は事前にサポートに確認しておきましょう。
22.リリース後のサポート体制
システムが完成してもそれをユーザに利用してもらい、期待通りの効果が出なければ成功とはいえません。 そのために、リリースした後もエンドユーザをサポートできるような体制を整えておきましょう。
システムに関する問い合わせ窓口を設けるだけではなく、例えばChatterを使ってシステムに対する質問や意見を受け付けるようなグループを作ったり、あるいは部署ごとにレポートをバリバリ作れるようなスペシャリストを育成・配置して、現場で直接ユーザをサポートできるような体制を作るのも良いでしょう。
「こうして欲しい」という要望を早急に察知して、それをすぐにシステムに反映できるようにすると、ユーザは自分達の意見が反映してもらえるということを知り、より改善に協力してくれるようになります。
逆に意見が出ても「難しい」とか「検討します」で止まってしまうと、だんだんと協力を得るのが難しくなってきてしまいます。 そういった意見にすぐ対応できるようにするためにも、出来る限り標準機能を使う、あるいは個別開発をしても変更に対応しやすく作っておくのが良いでしょう。
23.ユーザトレーニング計画
トレーニングの計画では「いつ実施するのか」「誰に対して実施するのか」「誰が実施するのか」「場所はどこでやるのか」「どのSalesforce環境を使うのか」「本番データを入れておくのか」「トレーニングで作ったデータを削除するか」「教材（マニュアル）の準備」などを検討しておきましょう。
最後に
今回はSalesforceの導入開発において各フェーズで意識したいことを書いてみましたが、細かいところを考えると注意したい点はまだまだ沢山あります。 過去記事には「開発ライフサイクルとリリース計画で意識したいこと」や「初期データ移行の勘所」といった投稿もあります。
記事を読んだだけでは自信がないといった方は、数多くの経験をしている開発ベンダーに相談してみるのも良いでしょう。
また、弊社今岡が書いている「Force.comのすべて」にも、開発をする上で意識したいことが多数記載されているので、ぜひそちらも合わせて読んでみてください。 
