Salesforceはエンジニアを幸せにするか?

石川悟氏(以下、石川):「Developers Summit 2018 徹底討論!! Salesforceはエンジニアを幸せにするか?」を開始させていただきます。本日はよろしくお願いいたします。「お前たち誰なのよ?」というところから始めさせていただきます。

私たちは「Salesforce Developer Group」で活動しております。全国にSalesforce Platformを使っている開発者がいるのですが、主に東京のメンバー中心で集まって運営しております。

今回は「Salesforceという名前を聞いたことはあっても、開発者がどう関わっているのかはあまり伝わっていないのではないか」ということで、実際のところを5名のパネリストにうかがってみよう、というセッションです。では、順番に自己紹介をお願いします。

今岡純二氏(以下、今岡):テラスカイの今岡と申します。テラスカイという会社はクラウドを専業にしている会社でして、私はその中でSalesforceを主に導入する部隊の責任者です。

私自身はもともと2004年からSalesforceに携わっており、「パワー」のようなものに強く感銘を受けてからもう14年が経ちました。いまもひたすら追求しているところですが、今日は少しでもSalesforceの良さを伝えていけたらと思っております。よろしくお願いいたします。

(会場拍手)

木村篤彦氏(以下、木村):co-meetingの木村と申します。

弊社は5名ぐらいの会社で、もともとパブリッククラウドで自社サービスを展開しておりました。ベテランと言われましたが、私は3年前ぐらいにSalesforceに参入したのでそんなにベテランではありません。

今はSalesforceユーザー向けに自社サービスと、顧問SalesforceプログラマーというかたちでSIを半々ぐらいでやっております。両方ともSalesforce Platform上で開発をしております。

(会場拍手)

中山純子氏(以下、中山):株式会社フレクトから来ました中山純子と申します。Salesforceにはデベロッパーとして6年ぐらい関わっています。

あとは個人的に「Salesforce女子部」というコミュニティを立ち上げて、女性同士で集まってわいわいSalesforceについて学ぶといったことを去年から始めています。もし興味がある女性がいたら紹介していただけるとありがたいです。今日はよろしくお願いします。

(会場拍手)

小泉剛氏(以下、小泉):みなさん、こんにちは。エムキューブ株式会社の小泉と申します。

私はみなさんとは少し異なり、プロダクトマネージャーとしてB2BのSaaSのアプリケーションを開発しておりまして、そのプラットフォームとしてHerokuやSalesforceを使わせいただいております。Herokuを使い始めてから6年ぐらいになります。よろしくお願いします。

(会場拍手)

倉谷彰氏(以下、倉谷):チームスピリットの倉谷と申します。

私は働き方改革で言われているような、「勤怠管理」「経費精算」「工数管理」といった「面倒くさいこと」をまとめて簡単にしましょう、というサービスをSalesforce Platformの上で提供させていただいております。

私は現在、20名ほどの開発チームでマネージャーを務めております。2011年ぐらいから関わっていて、Developer Groupの立ち上げ当初から運営に携わらせていただいている者です。よろしくお願いします。

(会場拍手)

Salesforceの特徴

石川:今回は5名の方にお題を出しまして、その中でご経験を語っていただきたいと思っております。実際にそのお話をうかがう前に、今回Salesforceのことをわからない方もいらっしゃると思うので、かいつまんで説明させていただきます。ご存じ、いろんなCMとかでやってると思うんですけど、Salesforceはクラウド型のCRMです。この分野ではけっこう認知度があると思っていて。

実はSalesforce上にいろいろなアプリケーションを開発して提供することができるというのが特徴です。例えばその上で、チームスピリットさんやco-meetingさんのように、Webサービスを事業として展開することができるのが大きな特徴です。そのほかに、あまり知られておりませんが、PaaSのHerokuも10年以上前からSalesforceのグループの一員です。

これらを前提にディスカッションを始めさせていただきたいと思います。今回のテーマは「Salesforceはエンジニアを幸せにするか?」という非常に重たい……。

中山:重たい。本当に重たいです(笑)。

石川:Salesforceさんにお声がけいただいて話し合いもしましたが、「幸せってそれぞれですよね」というところに落ち着きました。どういうことが幸せかというのは人それぞれ違うので、みなさんのご経験などを語っていただいて、その中からオーディエンスの方々に感じていただければと思っております。

今日は3つのお題を用意していまして、そのお題に即してパネリストの方々にお話をうかがいたいと思っております。

出会いのきっかけ

石川:まず1つ目のお題です。「Salesforceと出会ったきっかけについて」。どのように初めて接点を持ったのかというのを、うかがっていきたいと思います。ちょっと急になんですが、中山さんちょっとお話うかがってもよろしいでしょうか?

中山:OK、大丈夫です(笑)。話すと長くなりますが、私がSalesforceと初めて出会ったのは、28歳の4回目の転職の時でした。ちなみに今は、6回目、7回目ぐらいですね(笑)。

ゲームプログラマーが初の社会人経験で、そちらを2年ほど。ゲームボーイアドバンスやガラケーのアプリを作っていました。小さいゲームメーカーなので仕事がない時期もあり、「安定した仕事をしたいな」「自分がやりたいのはゲームを作ることだけど、安定した仕事って考えたときにゲームは不安定かな」と思い、転職をいたしました。

そしてWebサービスに転職しました。通販サイトなどを運用保守するようなお仕事に就き、そこで、みなさんはあまり馴染みがないかもしれませんが、ColdFusionという言語で開発をしておりました。会場の反応を見ると、やはりマイナーなんだなぁと思います(笑)。

(一同笑)

そのColdFusionで4年ほど運用保守をして、ColdFusionでの仕事が検索に出てこなくなり、「もうちょっとメジャーな言語で開発したい!」と思って、転職活動をはじめて出会ったのが「Salesforceを主軸とする体制にするつもり」という会社でした。

「Salesforceもメジャーなのかな?」と怪しい感じもありましたが(笑)。なにか新しいものにチャレンジできるきっかけだと決心し、入社してSalesforceを学ぶことになりました。

OJTでまずはじめに驚いたのが「Salesforceって本当にクラウドで動いているんだな」ということでした。ブラウザベースでマウスクリックをしてデータベースを作っていくんですね。

前の現場では、CREATE TABLEやALTER TABLEの準備をしていましたが、マウスクリックで項目もテーブルも簡単に作れてしまうし、1クリックでテスト環境や本番と同じ環境がそっくりそのまま作れるところに感動しました。そこから楽しく開発していました。

前の現場は50人ほどの体制でしたが、基本的に少人数で行えるんですね。

石川:ああ、 現場の人数?

中山:そうですね。前の現場は50人ほどで、インフラチームがいて、アプリ開発チームがいて、そのため決定速度も遅く、作ってリリースする頻度も遅かったです。それが少人数のチームに入ったことで、リリース速度も非常に上がり、お客さんと対面する機会も増えて、やりがいをめちゃめちゃ感じるようになりました。

自分の作ったものを見てもらって、フィードバックしてもらって、それがすごく自分のためになって、「次はもっといいもの出したいな」「もっとスピードを上げたいな」「品質・クオリティを上げたいな」とつながっていくので、私はこのプラットフォーム、好きです。

石川:すごい熱量が(笑)。

中山:まだしゃべれますけど、ちょっと(笑)。

転職をきっかけにSalesforceデビュー

石川:いやいや。ありがとうございます。倉谷さんはどういうきっかけでSalesforceに関わる仕事をするようになったのですか?

倉谷:私は、2011年に今の会社に転職しました。社長とはもともとの知り合いで、声をかけてもらい、入ってみたらSalesforceを使っていた、という感じですね。

もともとはSIだったので、Javaのフレームワーク、承認申請の機能などいろいろなものを作っていたのですが、「自分たちで作るにはつらいし、なにかないのかな?」と思っていました。そこから入社してSalesforceと出会って、考えていたものが全部揃っていて。たとえばレポートも下手なBIツールより充実したものがあって、「楽だなぁ」と思いながら使っていました。

人数としては6~7人で始めていて、それでも1,000人、2,000人のユーザーさんに使ってもらえました。お客さんに環境を払い出して使ってもらうことも簡単にできます。当時はAmazonがまだ台頭する前だったので、前職ではサーバを持っていて設置して、ということをやっていましたが、「楽になったな」というのは感じていました。

最近になってどんどん機能も増えていくし、「やっぱりすごい会社だな」と感じ始めていますね。「当時なんですごいと思ってなかったんだろうな?」というのは、まぁ、忙しかったのかな(笑)。

(一同笑)

それが出会いでしたね。

石川:なるほどですね。中山さんも倉谷さんも、きっかけとなったのは転職でしたね。そこで触ってみたら、小さいチームでもいろいろなことができる。環境の構築・複製が実際にお手軽にできて、ユーザーのフィードバックも早くできる。非常にやりがいを感じられているということでよろしいでしょうか?

中山:です!(笑)。

石川:はい、ありがとうございます。

Salesforceの好きなところ・好きじゃないところ

石川:それでは、次のお題に移っていきたいと思います。それぞれのきっかけがあってSalesforceを使われているかと思いますが、次はこのようなテーマを設けさせていただきました。「自分の関わっているSalesforce製品の好きなところ、好きじゃないところを教えてください」です。

先ほど、中山さん倉谷さんから「非常に人数の少ないチームでいろいろなことができる」「そのプラットフォームを作る機能が整っている」と、いいところをおうかがいしました。

仕事の中で感じる好きなところとは逆に、「もうちょっとここはこうなるといいな」というところを教えていただけると助かります。また急角度での振りになります。小泉さん、お願いします。

小泉:はい。

石川:ちなみに、今プラットフォームのHerokuを扱われているとおうかがいしたのですが、実際に提供されているWebサービスのこともご紹介いただけると非常にわかりやすいかなと思います。

小泉:そうですね。「企業でストレスチェック」というサービスをHeroku上でサービス提供しています。

昨年、1,000社ほどのお客様、200万人ほどの従業員さんがHeroku上でストレスチェックを実施しています。ですので、就業人口の10から20パーセントの方がHeroku上でストレスチェックをしていたということなりますね。みなさんの中でも試された方がいらっしゃるかもしれませんね。

好きなところと好きじゃないところですが、私たちのサービスは最初に立ち上げたときはオンプレミスだったと思います。それから4年5年ほど経って「お客さんも増えてきたし、スケールするものがいいだろう」ということでサーバーの建て替えをしました。

その当時まだB2BのHerokuはそんなにでもなかったんですが、「オートスケールさせたい」ということと、ストレスチェックの性質上「ストレスチェックする期間だけキャンペーンのように大きくしたい」というのもあったので、そのタイミングでHerokuというものを選びました。

現状利用ユーザーは1,000社・200万人ほどですが、インフラ専任のエンジニアなし、つまり兼任だけで運用できているのが非常にいいところですね。

「好きじゃないところ」を挙げますと、運用し始めてしまうと大丈夫なんですが、導入するときに上の偉い人が「Dynoってなんだよ? こんなの小泉みたいに頭のいいやつじゃないと理解できないだろ?」というところです。

(一同笑)

石川:Dynoについては少し補足させてください。Dynoというのは、Heroku、つまりPaaSですが、その上で動くLinuxのコンテナのようなイメージですよね。アプリケーション実行環境の単位がHerokuの世界でDynoと呼ばれております。

小泉:1Dyno、2Dynoという。「わしは何Dyno注文すればええんや?」って関西弁の上司に言われまして(笑)。

(一同笑)

「まぁ、とりあえずお前の好きなだけ買っとったらええわ!」って言われました(笑)。

中山:おお、太っ腹ですね(笑)。

石川:金額にすると、どのぐらい買ったんですか?

小泉:金額ですか? 具体的な数字は控えさせていただきますが、10万人規模の大企業が朝9時に「ストレスチェック開始ですよ」というと、50Dynoぐらいバーっと自動であがるといったところでしょうか。

石川:おお。

小泉:Herokuは数字や呼び方がわかりづらいので、ちょっと説明しづらいんです。

石川:なるほど。普通に今Herokuのサイトで1Dynoいくらというのは出ていますので、見ていただくと小泉さんの買った金額がわかりますね。

(一同笑)

石川:独特な単位を使っているところが「好きじゃない」んですね。

見積もりもそうですね。PaaS全般に言えるのかもしれませんが、おそらく「好きなだけ買っておけや」というのは普通の企業さんだと珍しいでしょうし、これも一因かと思いました。ありがとうございます。

コア機能に集中できる環境

石川:では、小泉さんにHerokuの話をしていただいたのですが、木村さんの方からは、自社で開発されているサービスについてお願いできますか?

木村:HerokuだとDynoというのがあって、Dynoをいっぱい積む、つまり、札束で叩けばどんなアクセスでも耐えられるんですね。

私自身はSalesforce Platform上サービスを作っておりまして、昔「Force.com」という名前で今はSalesforce Lightningというものなんですが、こっちだとなんとすごいことに、札束すら要りません。インフラ費がかからないんですね。

私はもともとパブリッククラウド、IaaSでサービスを作ってきていたので、「インフラの運用」「セキュリティパッチ」「スケールするように構成組む」といったものも非常に大変で、大企業に入れようとすると「セキュリティシート埋めてください」「ログイン周りSSOはできませんか?」「二要素認証は……」といったいろいろ注文があって、コア機能になかなか注力できないんですよね。

「次どこか、どこでサービス作ろうかな? IaaSつらいな」という思いで探して、Salesforceに参入しました。

Salesforceの「すごいところ」は、さきほど倉谷さんも言っていましたが、そういうサービスを提供するための機能、今言ったようなログイン系も全部あるところです。SAML連携も可能ですし、監視系もありますし、サービスのリリースやアップグレードもボタンひとつでできますし、コア機能だけに注力できるというのが非常にすばらしいんです。

あと、先ほども言いましたように、Salesforceにはお客さんの環境があって、アプリを作るとその環境にインストールするようなイメージになるんですね。ですので、お金払っているのはお客さんで、サービスベンダー側はインフラ費がまったくいらないんです。

それはもう「スゴイ」んです。「作ったらあとは放置しておけるプラットフォーム」というのは、私はここで初めて出会いました(笑)。

最初は仮説検証を速く回したくてここに来たのですが、最近はどんどん作って放っておけるので、作るのが楽しくなって、今は小さいアプリ作って出しています。そんな感じですね。

ローリスクでビジネスをはじめられる

石川:ありがとうございます。木村さんのco-meetingさんのサービスも、倉谷さんのチームスピリットさんのサービスも、SalesforceのCRMを使っているお客さんの中で動くサービスを提供されているということで、やっぱりプラットフォームの手当てがお客さんのSalesforceに寄せられていて、自分のやりたいことに注力できるということですかね?

倉谷:少し補足をすると、弊社のサービスは、直接弊社から売っていて、Salesforceさんからは一応プラットフォームを卸してもらっているという関係になっています。1ユーザー600円ですが、その中からインフラ代を払っているような流れになっています。

すごいところは、売っただけ課金してもらえるので、売れなければそれなりにしか払わなくてよく、売れてきたらその分を払っていくようなビジネスモデルにできるので、そこは本当に助かったなぁというところです。

木村:そうですね。売れなければお金がかからない。

(一同笑)

石川:非常にローリスクでSaaSビジネスを始められるということですかね。

木村:あと、うちと倉谷さんのところで違うのは、うちの場合はSalesforceユーザーしか使えないサービスで、倉谷さんのところはSalesforceユーザーじゃなくても使える。でもSalesforce Platformで作っている感じですね。

石川:えっ、どういうことですか?

倉谷:基本的にはうちのサービスは独立したものでして、今のユーザーさんもSalesforceユーザーとうちのサービスだけを使っているユーザーは半々です。うちのサービスにプラスアルファで、SalesforceのSales CloudやCRMの機能を使いたければ同じプラットフォームで使えますよ、という立てつけになっています。

石川:1つのWebのSaaSとして普通に提供もできて、流用してSalesforceユーザー向けに流すこともできるというような。

倉谷:そうですね。

石川:なるほど。勉強になります。ありがとうございます。

Salesforceとエンジニアのキャリア

石川:では、最後のお題です。ここが実は一番大事なところで、みなさんエンジニアとしてキャリアスタートしていただいていると思います。その中で今Salesforceとなんらかの関係があるエンジニアになっていると思うのですが、「エンジニアにとって、Salesforceが関係するキャリアのイメージはどんなものなのか?」というのをうかがえたら思います。まずは今岡さんお願いします。

今岡:私はシステムを導入することをずっとやっていまして、従来はいわゆるオンプレのシステム導入のようなものをやっていました。

その当時のことを考えると、エンジニアというのは、どうしてもプログラマーになって、そのあとSEになって、その次がPMになってというキャリアがほとんどでした。つまりウォーターフォールの縦割りの工程だと思うんです。

一方で、現状、お客さんの要求が非常に高くなっており、当然、品質も高いものを要求されますが、納期そのものは短く要求されるわけです。そうなってくると、そういうキャリアの形成や体制の組み方だと間に合わないという実態になってきています。

したがって、さきほど言ったような、「キャリアそのものの形成」というのは形式的なものではなく、非常に多様化してきているというのが率直に感じているところです。

「Salesforceに携わって今後のキャリアをどう形成することができるのか」というと、本当にわかりやすく言えば、今日ここにいるメンバーそのものです。みんなSalesforceに深く携わってるんです。

私の場合はアーキテクトという立場でもありますし、会社を経営している方もいらっしゃいます。女性のデベロッパーとして活躍して、コミュニティとしてネットワークを広げる活躍もあります。プロダクトマネージャーというかたちもありますね。

あるいはデベロッパーのマネージャーとして、非常にモダンなQA環境を構築されて、Salesforceの開発そのもののスタイルを革新的にやっているということもあります。さまざまなものがあるということをみなさんにお伝えしたいなと思うんですね。

場合によっては、Salesforceというと、どうしてもベンダーロックイン的なイメージを持たれることがあると思うんですけど、今みなさんがお話しされたように非常にいいものだと思うんです。

食わず嫌いだともったいないかなと思っていて、今日帰ってブラウザでサインアップすればすぐに使えるものなので、とりあえず食ってみて、おいしくなければやめるぐらいで関わってみてもいいかな、と思っております。

石川:ありがとうございます。非常にきれいに、まとめに入っていただけました。

(一同笑)

Salesforceは「開発者をダメにするソファ」なのか?

石川:ありがとうございます。もうここにいらっしゃる方々の場合、そのままキャリアのイメージになる、さらに多様化しているということだと思います。個別に、ほかの方にも「私は今後こうしていきたい」「こうしたい」という話をうかがおうかと思ったのですが、せっかくここにお集まりいただいたので、会場にいらっしゃる方のなかでなにかご質問等ありましたら、挙手で教えてください。

質問者:今日登壇いただいている方々にあえて聞いてみたいと思うのですが、僕のちょっとしたイメージで、Salesforceの上でなにかものを作っているというのは、言ってしまえば、 「開発者をダメにするソファ」の上に座ってなにかものを作るというイメージに若干近いんですけれども。

みなさんそういう人をダメにするソファの上に座ってなにか作っていくというイメージを持たれているのか、あるいは、その上で作っていくということに対して今後をどう思われているのか、というあたりをちょっとなにか。

中山:重いなぁ。

(一同笑)

質問者:最後の3番目の質問にも関わってくるところだと思いますが、そのあたりいかがでしょうか?

木村:そうですね、そんなに人をダメにするとは思っていませんが、確かにプログラマとして職人肌の人にはそれほど向いていないのかなとは思います。かなりのことができるんですが、多少のロックイン、制限はあります。

ですので、プログラミングを手段として問題解決に使うというタイプの人、私も今ビジネス面のメリットを多く言いましたが、そういう人のほうが向いているのかなとは思いますね。

中山:そのソファを知るというか、CRM自体、Salesforceに関わらなければ知らなかった世界ですので、こういった仕組みがあるというのは勉強になります。

それとプラットフォームとして全員が使う環境ですので、ガバナ制約という縛りもありますが、それに関してはどういったシステムでも考えないといけないことだと思います。負荷がかかったときに耐えられる仕組みというのは、別にSalesforce以外でも同じことですからね。

どういったものがあるかを知って、それをSalesforceでいう「ベストプラクティス」で実装する。それはほかのアーキテクチャー使うときにも流用できることなので、私は前向きにとらえています。

プラットフォームに乗るということ

小泉:問いかけが大きかったので、さらに大きく返そうかなと思っているのですが、そもそも、まず人間の歴史自体がですね……。

(一同笑)

木村:でかいでかい(笑)。

小泉:発明の下に成り立っていて、どんどん楽になっていくということだと思うんですよね。

それを小さくしてOSを見れば、かつてFreeBSDというものがありまして、すべてのOSはソースからコンパイルせねばならないというライブラリから始まって、次にLinuxやWindows、その上にIaaSができて、PaaSができてという時代の流れなので、PaaSに乗っかり楽をしていく。

ただ、その下にあるテクノロジーというものはすべて知っておく必要があります。先ほどあったように、ソースがあって、コンパイルがあって、バイナリがあって……というものを知ったうえで、上のものを使う。技術的な勉強をしながら、「知ることは多くなったけど、やることは少なくなった」というのがいいのかなと思いますね。

倉谷:逆にうちの場合だと、フロントエンドはReact、サーバサイドは『実践ドメイン駆動設計』を読みながらDDDで設計していて、Salesforceのベストプラクティスに沿ってないかたちで実装しているかなという気はしています。

簡単なアプリを作る分には生産性が高く、Salesforceのやり方に沿って作れますが、大規模に作るときは他の開発と同じような深さ、というところはあるのかなとは思っています。

今岡:まぁ、ソファの上でぬくぬくかというと、Salesforceは年3回バージョンアップするんですよね。バージョンアップするたびに膨大なリリースノートが出ます。したがって、新しいことをとにかく追求して覚えていくということに必死にしがみついていかなきゃいけないというのもありまして、実際はそんなにぬるくないんですよね。

例えば大規模な開発現場になってくると、大量のトランザクションを捌かなければいけない事態があって、その時はマルチテナントであるがゆえの制限みたいなものもあります。

そういった「制限をうまく乗り越えながらうまく作っていく」ところは醍醐味でもあり、おもしろさでもあり、非常に苦労を伴う面もあります。まぁ、そんなところですかね。

石川:ご質問とご返答ありがとうございました。慌ただしくなってしまいましたが、お時間になりましたのでセッションを締めさせていただきたいと思います。本日は、パネリストのみなさん、セッションに参加くださったみなさん、ありがとうございました。

(会場拍手)