Force.com Developer Group Japan Meetup#3 に参加しました
先日、こんなところに参加してきました。
今回もチームスピリットさんにご協力頂いて、STARTUP Base Campにて開催しました。
前回と比較すると、人数が少なく40名枠でした。30名以上の方々にご参加頂けたのではないかと思います。
パネルディスカッション
今回、初の試みとして、パネルディスカッションの枠を作ってみました。
- モデレータ：岡本さん（Salesforce.com）
- パネラー：
- 今岡さん（テラスカイ）
- 倉谷さん（チームスピリット）
- 竹内さん（with-p）
- 自分
というメンバーで、こんなネタでディスカッションしてました。
- Force.comでの受託開発 vs サービス開発
- 設計段階からガバナ制限考えるときに気をつけていること
topic1: Force.comでの受託開発 vs サービス開発
Force.comというプラットフォームでなくとも熱くなるような対決ですが、Force.comの上では果たしてどちらが良いのか？という具合で始まりました。
Force.comにはAppExchangeというApp Storeのようなマーケットがあり、ユーザが気に入ったアプリを自由にインストールすることができるステキな仕組みが用意されています。
その一方で、ガッツリとゼロからアプリケーションを作っていく（＝スクラッチ開発）ことも可能で、
- 受託開発でご飯を食べていく
- サービス開発でご飯を食べていく
のどちらを選択することもできます。
一般的には、そのどちらかを選択して、日々の業務を遂行していく...という印象がありますが、どちらが良いのでしょうか？
ディスカッション中には、様々な意見が出ました。（が、一部しか記憶してない... (/++)/ ）
- 日銭を稼ぐには、受託の方が良さそうだ
- サービス開発は、ライセンス数がある一定ラインを超えるまでは大変だ
- 受託開発ではレバレッジが効きにくく、売上を伸ばすには規模を増やす（＝開発人員も増やす）ことが必要になる ...etc
サービス開発の方でご飯を食べられる程に稼げるようになるのが理想的...という意見が多かった印象ですが、参加者含め、受託開発に従事している人の方が多かったですね。まだまだ受託開発の方が現実的、ということでしょうか？
一方で、従来の受託開発のままでは、あまり明るい未来が待ってなさそう...という印象もあり、双方メリット／デメリットが飛び交いました。
※余談ながら、人数に頼った受託開発、となると弊社のような少人数では太刀打ちできなくなるのが痛いポイントです。。
結局、"受託" VS "サービス" という対決モードでは「なく」、その両方をいいとこどりしたスタイルを目指すべきなのでは？という意見が非常に良かったと思います。
これは自分も非常に賛成するところで、
- 受託開発で得た知見をもとに共通に使えそうなところをパッケージ化して次の受託開発に活かす
- 次の受託開発で得られた新たな知見をもとに、パッケージを洗練させていく（共通にできないところがカスタマイズポイントになる）
という黄金の回転ができたらいいなー...と常日頃から考えていました。
製造業でいうと、固変分離とでも言いましょうか。「固」の部分（＝パッケージ）と「変」の部分（＝カスタマイズ）を切り分けることで、効率よく製品を作り上げていく...という感じですね。（すごい大雑把な説明..）
もしくは、こんなサイクルでも良いのかもしれません。
- パッケージとして開発したアプリケーションを受託開発に適用する
- 受託開発に利用する上で、良かった点／悪かった点／改善すべき点...などをパッケージに戻して洗練させていく
というサイクルですね。
こうして見てみると、上は帰納的なアプローチによるパッケージ開発で、下は演繹的なアプローチによるパッケージ開発...という見方もできそうかな？とも思います。
多くの実案件の中からパッケージ化できる範囲を見つけ出す、という方法と、ある仮説に基づいて作成したパッケージを実案件に適用することで検証する、という方法ですね。
でも、結局は何かしらパッケージを作りあげていく、という意味ではサービス開発を目指していきたいのかな？と思うようになりました。（おい
最後に１点付け加えると、Force.comというプラットフォームはこれを実現していく上で非常に良くできてるプラットフォームだな、と思います。
ユーザ自身で、項目追加したり、ワークフロー作ったり、レポート／ダッシュボード作ったりすることができる（マウス操作のみで）のが非常に大きなメリットだと思います。
というあたりの話でしたが、このテーマはまだまだ検討すべきポイントが沢山あるので、引き続き考え続けていきたいですねー。
topic2: 設計段階からガバナ制限考えるときに気をつけていること
Force.com特有の「ガバナ制限」というネタですね。Force.comで開発する上で、避けては通れない道です。
元々のテーマでは、たまたま「設計段階から」としてますが、結局は「要件定義段階から」考える必要があるよね、という意見が出ました。
ガバナ制限によっては、その要件は満たせないから代替策を考えるケースも結構あるそうです。（特に大容量データ連携など）
また、「クラウドなんだから仕方ないじゃん」という「確かに！」という意見もありました。プラットフォーム側で、アプリケーションがある一定以上のリソースを使用することを「制限」とするのか「課金」とするのかは自由だけど、クラウドである以上、それは仕方ないよね、という意見。
非常に分かりやすい話だと思いました。
その他にも、「Salesforceとしては『ガバナ制限を設けることで、システムのパフォーマンスを担保している』という見解を出して...いるんですよ」という意見をモデレータから頂きました。
これもあながち間違った意見ではないなーと思いました。効率の悪いプログラムは強制終了したりすれば、ある一定以上のパフォーマンスは保てるかな？と思いました。（まぁ、ガバナ制限によるエラーでぶった斬られるとちょっと切なくなりますが。。）
多くの人からよく耳にする言葉ですが、
制約があるからこそ、創造性が高まる
確かにその通りだと思います。制約があるからこそ、（ない）頭をひねって、考えて考えて考え尽くした先に創造的なモノが出てくるものだと思います。
そういう見方からすると、ガバナ制限は決して「敵」ではなく、厳しい中にも優しさをもって、開発者を成長させてくれる素晴らしいモノなのかもしれません。これからのForce.comでの開発が「より」楽しくなる...かもしれませんね。（というのはちょっと言い過ぎか？？）
