Dreamforceの熱気冷めやらぬ中、今回は、非常に地味な情報をエントリーします！ だけど、とても大事なんで、ぜひご参考に。

ちなみにDreamforce に参加したテラスカイのエンジニアがフィードバックLTを行う 勉強会＆懇親会を開催しますので、こちらも要チェック！

http://www.zusaar.com/event/2027003

1.パフォーマンス

Salesforceで構築されたアプリケーションのパフォーマンスチューニング方法が詳しく書いて いるこの２つの記事は、必読です。

LDV(大量データ)のベストプラクティス日本語版 公開!!

http://blogjp.sforce.com/2013/03/ldv-277b.html

Force.com クエリのセレクティビティ (選択度) に関する統計データの収集

http://blogjp.sforce.com/2013/10/forcecom-34b2.html特にインデックス周りは、大事で、１つのSOQLで利用されるインデックスは１つのみなので、 カーディナリティの高い列の指定が、難しい場合は、場合によってワークフロールールを 使って、複合キーを作成したり、SOQL自体を分けたりして工夫しなければなりません。

また、インデックスを貼ってるにも関わらず、WHEREの検索条件でその項目に対して、 NULL値かどうかを検索かけるような条件だったり、!= を使った否定形を使う条件では、 インデックスが効きませんので、注意する必要があります。

パフォーマンスの対策を講じたはずなのに、開発者コンソールのクエリエディタ、Workbench などでテストした結果、クエリがタイムアウトになる場合は、セールスフォース・ドットコムの カスタマーサポートに問い合わせ、担当者の案内に従ってチューニングを進めましょう。

その問合せのやりとり時間も含めて本番リリースまでの移行スケジュールは、 多少余裕を持っておくことをお薦めします。

2.ガバナ制限

大量データを扱う際に、よくはまるガバナー制限として、１回のトランザクションでSOQLクエリー で取ってこれる合計レコード数が50000件を超えるというのものがありますが、 これは、VisualforceだとReadOnlyにしたり、@futureを使った非同期やバッチApexを検討する 必要があります。

Force.comアプリケーション構築の要件定義フェーズでは、実装方法によって、運用に直接関係 してくるこういったことも検証しながら進めなければなりません。

3.テスト環境

Sandboxは、保存できるデータに本番環境と異なる制限があります。

・開発者：200MB

・Developer Pro：1GB

・部分データ：5GB

ご利用者のライセンス契約が、Unlimitedで、完全版Sandboxをお持ちであればベストですが、 そうでないと大量データが入った状態でのパフォーマンス検証ができないので、 運用後の保守のことなどのことも考えて必ず準備していただくことをお薦めします。

4.データ移行

移行元データは、お客様が準備することが多いかと思います。 本番リリース日から逆算して、いつまでに準備しなければならないのかを 綿密にスケジューリングしなければなりません。

データ移行は、何も本番環境用のものだけではありません。１で紹介したパフォーマンスを チューニングするにも実際のデータに近い状態でテストしなければなりませんので、 Sandboxにもデータ投入する時間を考慮する必要があります。

データの投入は、ApexDataLoaderで実施すると思いますが、この時、あるトリガーが仕込まれた オブジェクトに例えば100万件いれるのにどれくらい時間がかかるのかといったことを計測する為に も本番移行前にSandboxで、リハーサルしておきましょう。

また、地味に困るのがデータの受渡しです。個人情報が含まれるような大量データの場合、 そのデータをどのような方法で、受け取るのかをあらかじめ、お客様と協議しておく必要があります。

あと、本番環境でデータを投入する際に気をつけなければならないのは、APIコール数やBULK API の24時間で処理可能なバッチ数（3000）のリミットです。 Salesforceの管理者メニューである組織情報や一括データ読み込みジョブから数字を確認した上で 実施しましょう。

この他にもDataLoaderでデータを流している最中に予期せぬタイムアウトがおこったり 想定していないデータ型が移行元データにあったりして、なかなか思うようにいかない ことがあったりするので、リリース前にプギャーっとかならないように慎重に準備してください。