7. バージョンアップ議論
技術者の働き方は、いわゆるこれまでのSI (システムインテグレーション）での受託開発と、SaaSでの製品開発では全く異なります。SaaSと受託開発（SI）との大きな差は、自分たちとお客様、「どちらが仕様を握っているか」そして「そのリリース日を誰が決めるか」だと思っています。この単純な違いが生活を楽しくもするし、苦しくもなるのです。ここでは、SaaSとしての大きなイベントである「バージョンアップ」というものを参考にしていきながら、技術者の観点での「働き方」も話していきたいと思います。
Salesforceのバージョンアップ
まずはSaaS業界の基準ともいうべき、Salesforceで考えてみましょう。Salesforceでは年3回のバージョンアップ（Spring, Summer, Winter）、特に秋に行われるDreamforceというイベントに合わせた大きな（メジャー）バージョンアップは有名です。その発表もサンフランシスコのモスコーニセンターで行われるキーノードで「どーん」と行うのですから、皆、「参加してみたいなぁ」などと思うものです。
Dreamforceの会場は上の写真のようにTrail（トレイル）を意識して創られています。Trailblazer (トレイルブレイザー)が「道なき道を切り拓いて進む」ことを意味しているように、イベントでもオフィスでも緑に囲まれた環境の中で、開拓者として行動することを目指して会場セッティングしてしまっています。このあたりの統一感、マーケティングセンスって凄いです。
大きなバージョンアップはこのDreamforceで発表されますが、そこに至る道のりは開発者にとってもなかなか大変です。Salesforceの開発者はIdeaExchangeと呼ばれるユーザーからの要望受付の仕組みとそこでの投票結果で付与されたポイントにより評価されます。「私は何ポイント今年はIdeaExchangeのIdeaを開発してポイントを獲得します。」というのが評価対象です。これはDELLのマイケル・デル氏のアイデアらしいのですが、よくできた仕組みですし、そこまで徹底的にできるのが凄いです。「大手企業に忖度」みたいなことも発生しないでしょう。最もSalesforceはカスタマイズできるので、そのお客様用にするにはカスタムのSIを提案すればよいのでしょうが。
いくつかのアイデアをとりだして、そこから自分で開発を進めていきます。「これをやる」と言ったものは記録され、担当者になるわけですから、それらを集めてくれば次や、次の次のバージョンの仕様がわかるようになります。これによってバージョンのコントロールがされています。ユーザーの欲しいものに寄り添っていくわけですが、果たしてこれだけでいいのでしょうか？
そう、Salesforceにはもう1つの開発方法があります。それが会社が決める新しい機能です。AIのアインシュタイン (Einstein) のことを思い出してみましょう。誰かが「AIでこういう機能が欲しい！」と言ったから開発していたのでしょうか？ユーザーは「どこかで経験したことを元にしてコメントする」ので、見ていない、あるいはこの世の中にないものに対してコメントできる人はほとんどいません。そのため、テクノロジーの情報を元に、自分たちで新しい要素も入れていかないと、アプリ自身が古く見えてしまいます。「SaaSはいつも進歩していく」というお客様に説明している言葉を守るためにも、業界動向をみて、それに合わせて開発していかないといけません。実際AIの機能の多くは買収という形で入手したSalesforceはそれらをまとめあげてアインシュタインという1つの製品群を作り上げました。
モバイルであるSalesforceアプリ（一時期Salesforce 1と呼んでいた）はスマホの登場に合わせて企画された。もともと「B2Cの技術がB2Bに適用するのが遅い」ということを改善することを企業の理念に持つ同社は、iPhone登場から企画しており、2008年にはSalesforce Mobileを発表している。このアプリはその後改善を続け、Lightning UI（ユーザーインターフェス）の試行としても定義され、そのUIはデスクトップにも継承された。新しいUIを使うか、使わないかの変更を個人で設定できるのは画期的だったと思う。通常はシステム設定なので、管理部門が決めると全員で一気に移行する。戸惑う人が多いと生産性は下がってしまう。まずは先行するテック好きから慣れてもらって、会社全体へと行き渡らせるようなシナリオが描けるようになっていた。このUI変更は構想から実現までに7年かけたという。
バージョンアップが実施されるとき、アプリを提供しているSaaS企業も影響を受ける。通常、バージョンアップの3ヶ月ほど前に、サンドボックス（テスト環境のこと）に新しいバージョンがリリースされる。もちろん一部にバグが残っているが、テストできた方がいいという考えだ。プラットフォームがバージョンアップしたときに動かなくなったらユーザーにとっては悲劇的だ。バージョンアップはある日の夜中にセットされるため、朝起きたら「なぜか動かない」ことになってはたまらない。そのため、特に新しい機能が影響されるような場合は早めにテストをしておきたい。
お気づきになったかと思うが、「3ヶ月前にテストを始める」ためには、その前に「どんな機能がリリースされるか」を知っておかねばならない。そのため、Salesforceでは次の次のバージョンのリリース情報（リリースノートという）を告知する仕組みになっている。図にすると下図のようになる。
一部の機能は「リリースする機能要件を満たさない」と判断されるとリリースが遅れることがある。AppExchangeパートナーだけではなく、カスタマイズなどで開発したお客様、パートナー様もリリース直前のリリースノートには注意を払っておきたい。（テラスカイさんのブログが秀逸）
Dreamforceはこの概念を上回ることがある。つまり上の図の左端をはみでてコンセプトや概念が発表されることがある。その場合、Dreamforceで発表されたものがその日に手に入らない。一部は紙芝居ではないか、という噂があるくらい、「リリースが1年先」など早めに発表し、市場を造りにいくということをやっている。このあたりのマーケティング手法は見事というしかないが、それを真似するのも相当難しい。マークベニオフCEOのカリスマ性も十分に生かされている戦略と言えよう。
バージョンアップのコントロールはSalesforceならではのもので、アプリは稼働中に変更が可能なアーキテクチャーになっています。とはいえ、混乱を避けるために各時間帯ごとにリリース時間が設定されます。土曜の午前2時というのが通常のようです。この世界展開には1ヶ月くらいかかるのも理解しておく必要があります。
AppExchangeパートナーのバージョンアップ
では、このようなSalesforceの動きに合わせてパートナーはどう動くべきなのか、を考えてみる。
1) Salesforceに合わせてリリースをしていく
2) 自社のスケジュールで廻していく
の2つがあるが、明らかに1)でやった方が効率的だ。次のコラムは翻訳版だが、海外ではどう考えているか、を参考にしてほしい。
その前に、AppExchangeパートナーが得られる大きなメリットを説明しておかないといけない。とりわけ便利なのは管理パッケージによる自動アップデートだ（詳細は下記ISVforceガイドを参照のこと）。
AppExchangeパートナーはSalesforceが提供するLMA (License Management App; 英語のみ)を使って、全世界に導入されたアプリをクリックすることでバージョンアップできる。管理パッケージとは非常によくできた仕組みでSalesforce自身も使っているアプリコードや画面定義などの塊を指します。管理パッケージを使い、バージョン管理すると、Salesforceのどの組織（Salesforce導入時のデータの管理単位、会社ごとにすると会社単位に、いくつかの部門に分けることもできる。）にどのバージョンが入っているか、がLMAで表示することができる。それらを自社のアプリのバージョンアップとして自動更新してしまえば、お客様環境が最新の1つに統一される。オンプレでは夢見ていたようなことが現実にできてしまう。また特定組織を選択することもできるので、仕様で悩んだとき、お客様にお願いしてA/Bテストのようなこともできる。
私は「Salesforceの組織」は会社単位を強く推奨している。理由は
1) 会社全体でのKPIを簡単に作れる
2) それらのKPIを見て、全社の動きを見えるようにできる
3) KPIで問題が発生していることがわかれば全社課題で取り組み、全社レベルで修正できる。（部分最適にならない）
4) 他部門のノウハウが転用できるようになる
これらはどこかで記載したいが、それはAppExchangeとは直接関係ないのでこのマガジンでは記事にしないかもしれない。
さて、アプリの更新方法がわかったところで、本題へ戻ると、一番ベストなバージョンアップ方法だと私が思ったのはVeevaがやっている方法だ。やはり当初から参加しているだけあり、いろいろと学ぶべきノウハウは多い。Veevaのポリシーは「Salesforceの1ヶ月後に必ずバージョンアップ。年3回。」というものだ（2020年6月からは毎月へと変更）。1ヶ月後にしているのは正式版で最後の確認を行う、という意味を持っているのだろう。
Salesforceと同じ日に変更することに対するリスクも回避できるし、管理パッケージで同時更新したい場合にはSalesforceのバージョンアップ展開後にできることになる。もちろんSalesforceのように米国西海岸が終わってから1ヶ月後のように細かくフォローしてもいいが、小さい会社のうちはたぶん耐えられないので、バージョンが揃う時間を待つだけの方が簡単だ。バージョンアップの時期はSalesforceのTrust（トラスト;信用）サイトへ行けば情報を入手できる。ただ、Salesforceのバージョンアップでリリースされた機能をすぐに生かすような方針ではなく、リリース時期を合わせて、自社のイベントなども絡め、効果的にマーケットへ訴求している感じの方が強い。メジャーバージョンアップも秋(Winterバージョン)ではなく、春だったような気がする。
他にも例を見てみよう。CodeScience社のOperationalizing your AppExchange Strategyでは以下の図がでてくる。こちらは初期リリース用に書かれているが、Salesforceの3回のリリースとR1やR2を考えていくスケジュール感がわかるだろう。
Salesforceのバージョンアップや開発のスケジュール感がなんとなくつかめれば、それをどう自社へ展開していくか、を考えないといけない。Salesforceが教えてくれていることは以下の2つだと思う。
1) バージョンアップコンセプトをきちんとユーザーに告知し、将来の投資をとともに機能改善への努力をお約束する。（間接的にそのための協力も要請することになっていてフィードバックループができあがる。）
2) バージョンアップに合わせたマーケティング、営業活動をきちんと組み立てる。
これらの戦略立案は製品担当者だけでできるものではない。会社としての戦略からプロダクトリリースポリシーを作り、それを社内の他部門へと展開して、それを全社で徹底して実施していく。その実施程度はSalesforceのダッシュボードで検査し、必要なら修正、変更して、改善を進める。フィードバックループは以下の記事を参考にしてほしい。
マーケティング戦略だが、英語版があるなら「Dreamforceに参加する」のも1つの方法である。これまで多くの会社が参加してきたが、そこには海外戦略のシナリオが必要になる。（これは別途記事を書く予定。）
通常はSalesforce World Tour Tokyo (SWTTと略称される)に参加するのが一番だろう。Dreamforceの内容を受けて、世界ツアーが始まるWorld TourはNew Yorkが起点になる。New York向けに3.5日くらいあるDreamforceの短縮版を作り、それを世界展開する。日本はそこから日本語訳や同じシナリオに必要なお客様やパートナー様の選定が入るから、どうして2−3ヶ月は遅れるので年末に実施されるのが通例になっている。
ちなみに、私は在籍期間中、このSWTTのCAMP GROUND（キャンプグラウンド；展示会場のこと）の責任者でもあった。毎年変わる配置とミニシアターなどの仕組み、登壇順番やセッションとのかぶり、スポンサーレベルでのブース位置の差配などいろいろ判断することが多かった。当日はその企画でどのブースが一番人が来ていたのか、来ていなかったのか。どのような仕掛け（グッズやクイズなど）がうまくいって、何がうまくいかないか、などをチェックするようにしていた。2013年ころに行ったビックサイトでのイベントは相当苦労したらしく、担当者はトラウマのようになっていたが、2018年に思い切ってもう一度のリターンマッチ（来場者数が急に増えて、収容できる場所が他になくなった）を実施したが、それはとてもよい結果になった。広い会場ではあったが、お客様がどこにもいらっしゃる状態で、5年での市場の受け入れ方が変わったことを皆で振り返っていたのを思い出す。
SWTTに参加するときにはSalesforceのメジャーバージョンアップが実施されている可能性がある(上記CodeScience社の暦ではWinterリリース）。もしその最新機能を使って先進性を訴求したいなら大きなチャンスになる。そうでなくとも、Salesforceが集客したお客様に自分たちの製品を紹介できるのだから、ABM (Account Based Marketing; ターゲットを絞ったB2Bマーケティングのこと)的にはまさにターゲットが前を歩いていると思えるくらいかもしれない。
（最近弊社でこういう事象の例として「魚のいるところで魚は釣るものだ」と言ってたことがあった。ターゲットを絞るのはB2Bでの鉄則。）
そのとき、「この場をどう位置づけていくか」がマーケティングおよび製品戦略上で重要になってくる。年に1度のバージョンアップでいくなら、この機会に新機能をぶつけない手はない。それは一番効率よく説明できる場が提供されるからだ。お客様へももちろんそうだが、そこに来場するSalesforce社員、パートナー様などビジネスの話題でいっぱいだ。そのために製品開発部門は仕様を確認して開発を進めていく。SWTTへの申込をしたら、そこでのマーケティングメッセージやグッズなどを調達する。ブースのデザインも基準が指定されるとはいえ、できれば来場者の目にとまるようなものにしたい。フォーメーションも決めないといけない。臨時雇用者を利用するなら、彼らへの教育や、社員への引き継ぎルールなども決める必要がある。
テラスカイさんがやっている速報レポートなども有効だ。オンラインでの訴求も十分に考えていきたい。ネクタイまで含めてブースとの一体感があり、多くの人が集まる中で、説明員とわかる工夫も素晴らしい。
気をつけて欲しいのはセッションを持ったとき(あるレベル以上だと個別のセッションを持てる。ときどきお弁当付きなどが設定されることもある。人数は会場によるが50−150名程度だろうか）だ。いくつかの会社では社長または事業責任者がセッションを持ち、マーケティングがブースを担当していた。セッションを持っている方はできるだけ新しい情報を提供したくなる。ブースは締め切りがあって、それまでにメッセージなどを固めないといけないから、その後に経験した新しいことなどはブースにはないが、セッションに盛り込もうとする傾向がある。そのとき新しいことがメインになりすぎて、ブースと違ったメッセージになってしまうことがある。「前日夜中まで頑張って資料を仕上げた。」パターンは一番危険だ。セッションを聞いたお客様はあとでブースに行くがセッションと同じ話にならないことがある。「昨晩まで修正していた」のだからブースのメンバーが知っているはずがない。マーケティング担当がセッションもブースも担当するようになっていれば問題ないが、初期のベンチャーにはありがちな話である。マーケティング担当は「会社としてのメッセージを統一しておくこと」に一番留意しておきたい。
他の時期にバージョンアップを企画するのも悪くない。パートナー含めて皆が一斉に「バージョンアップ」「新機能」と言っている時期だと、自社のメッセージが埋もれてしまうかもしれない。多少ずらしてリリースすることにして、「リリースしました」の連絡を、それらのバージョンアップの大波から外すことで、お客様の目にとまる確率が上がるかもしれないからだ。
せっかく入手できる名刺情報（リード）を使い、コミュニケーションをきちんと続け、リリース時の拡販につなげたいものである。
そして、時期をずらすのであれば、お客様の増加に応じて自社のブランディングのためにも自社主催のイベントを考えていくのもよい。実はSalesforce自身もイベントのデビューはシーベル社（Salesforce創業時でのCRMの巨大企業）のイベントだ。そこから自社でのイベントへと切り替えて成長してきた。集客力が持てない初期は他社イベントで集客を期待しつつ、自分たちの製品を売り、お客様が増えて、営業体制も整ってくれば、自社イベントをやるのはブランディングとしては是非考えたい。
もし資金調達などができて広告などもできるなら、タクシー広告なども効果的だ。イベントをやる地域に限定して、ある一定期間広告を流す。ここ数年は「イベントでの新機能発表で驚く」よりも、「イベント前に新機能を発表してイベントへ導く」ようになっているので、イベントへのマーケティング投下としてもよいと思う。値段の割に、実は結構（真剣に）見てしまっている人が多いので、効果が高く、有効な方法だ。これらもSWTTでの「ブース vs. セッション」ではないが、すべてに同じメッセージを詰め込んでおくことが重要になる。キーノートを設定し、会社の戦略、方針などに加えて、ぜひリーダーがいろいろコメントを述べる時間もセットしておいてほしい。イベントは最初から大きなものにしなくてもいい。TeamSpiritさんは最初はファン感謝Dayと称して実施して、その手応えでTeamSpirit Dayへと進化させている。最初のイベントでノウハウやユーザーの反応、パートナー様の協賛などの感触もチェックできるのはとてもいいことだ。
SWTTでは各国に合わせたコメントにできるシナリオ部分が実は定義されている。それ以外はすべて全世界で同じになるように設計され、録画されたキーノートではあとで採点されて登壇者にフィードバックされる。世界でメッセージが異ならないように徹底されているくらいだ。例えばNew Yorkで金融のお客様が登壇したとすれば、日本でもそこに当てはまる金融のお客様に登壇をお願いすることになるなど、だ。
さて、イベントが定まればそこに合わせたバージョンアップを企画し、マーケティングも考えていかないといけない。マーケティングが他でもいろいろ語られることがあるので、ここではプロダクト側での話をしておこう。
次のバージョンで実現できることを、今の開発陣容の中で決めていくことになる。もちろん多くの案があり、懸案事項があり、さらには将来の要望としてお客様にもらっていることもある。Salesforceのアーキテクチャで考えていけば、多くの機能はあるオブジェクトに対して固有になっており、ワークフローなど連携していく機能は別になっている。これは実はすごく開発しやすいことを意味している。例えば名刺というオブジェクトがあれば、基本そのオブジェクトを操作するアプリを1つ創る。そのアプリ以外から触ろうとするのはオブジェクトが公開されていればそんなに難しくない。Salesforceのオブジェクトは取引先責任者(Contact)と取引先(Account)はパートナーアプリも自由に使っていいことになっている。
（注；その他のオブジェクトをアクセスするアプリを創るのはいいが、Sales Cloud, Service CloudまたはLightning Platformをお客様に購入いただくのがライセンス上の制限）
となると、そのオブジェクトを操作するアプリを開発、更新していくことになるが、アプリ単位の独立性が高いのが特徴になる。
上記Summer'20のリリースノートを見てみると、個々の機能でどれか1つが完成できなかったら、他の項目に影響を与えるようになっていない。ということはこの項目単位で進捗によってはリリースノートから外すこともできるということだ。もちろん目玉機能を外すわけにはいかないから、そちらの進捗が悪いときに周りの機能を次に延ばして、皆で目玉機能の開発に注力するようなこともできる。これらは働き方という点では受託に対して大きな違いになる。つまりSaaSの完成日のコントロールを自分たちでできることになる。製品開発はずっと続いていくから1つのバージョンアップで倒れ込むようなゴールをするわけにもいかない。これに対して受託となればSIの場合は納期厳守になり、かつ機能も最低限のコミットは実現しないといけないから、多くの制約の中で無理をやりがちである。結果をださないと次の仕事がこないかもしれないからだ。SaaSが長距離走だとすればSIは短距離と言えるかもしれない。でも100m走をマラソン並にやっていては体を壊してしまう。きちんとしたリリース管理はされるべきだが、ずっと開発が続く中で無理を続ければ個人が、そして組織と会社が疲弊してしまう。「開発に対してあまりプレッシャーを与えるな」とはSalesforce社内でもときどき飛んでいたメッセージである。
Salesforce社の開発陣は「売れっ子」だ。サンフランシスコ周辺ではどんどんソフトウェアの会社が誕生しているから、その技術者としての勧誘なども多い。そのため技術者に無理をさせると、他社に転職してしまう可能性も高い。そもそもSalesforce社員を受け入れるときは、ポジションをあげる傾向にあるから、昇給、昇進を絡めての提案も多く、自分の経験を生かして次のキャリアを目指したいという希望を持つ人も多い。そのため、エンジニアについては他社より優遇されている感じを受けていた。
開発の要件を管理することはとても大変ではあるが、それらを順序づけてきちんと実施し、マーケティングメッセージと、イベントの時期を絡めて、自社製品をブランド化していく。イベントから逆算してまとめてみると、以下のようになるだろう。
0)（6ヶ月前）イベントの企画、メジャーリリース機能を確定。
1) （3ヶ月前）バージョンアップ告知。リリースノートを発行。ベータ環境を提供。イベントの発表と集客開始。
2)（1ヶ月前）新機能プレスリリース。Sandboxへプレビュー環境を提供。さらなる集客を実施。
3)（イベント当日）イベントの実施、セッションの記録、ブログへ記載。
4)（イベント後）リードへのフォローを開始。
6)（イベント後2ヶ月）リード、商談の評価
自社であれ、SWTTであれ、他のイベントであれ、上記はあまり変わらないと思う。イベントに参加するには大きな時間と労力を取られるが、その結果はリードや商談、そしてARR (Annual Recuuring Revenue年間契約額）に必ず反映される。まじめにやっていけばARRは伸びていく。ビジネスが伸びていけば組織も会社も大きくなる。そしてその実績は社員と会社をさらに強くしていく。会社にとってはアプリが生命線ではあっても、このイベントを実施するときの総合力が重要に思っている。特に最近はProduct Led Growthと言われる商品もでてきている。強い製品ならこそ、製品の訴求はより重要になってくると思っている。
自社イベントのときには自社だけで展示しているというより、パートナーが周りにたくさんいるエコシステムをお客様に伝えることが重要になる。それらの各パートナーとの交渉やエコシステムなどの作り方がこのマガジンの大きな主題の1つでもあるので、これはどこかでまとめておきたいと思っている。
最後に開発方法についてだが、こちらの記事が秀逸なので紹介させていただく。
また次回をお楽しみに。
この記事が気に入ったらサポートをしてみませんか？