Salesforce World Tour Tokyo 2019
ということで行ってきました
このカンファレンスでは、ルーム付きセッションではまず間違いなく同時通訳があるという素敵仕様。
イベントを詰め過ぎて、ブースの類はほぼ回れなかったのだけど…
ちなみにまとめるのも面倒なので、当時のメモを直接公開。
第四次産業革命時代モビリティ市場の創出に向けて
世界経済フォーラムではガバメントが第四次産業革命にアップデートできてない。 ただし何がベストプラクティスはなくて真似ができない。 データガバナンス（データは誰のものか？）に結論をまずだそうといてる。
地方のモビリティの現状。
地方は、アクセスだけでも車がないと殆ど移動ができない。
数少ないバスが生命線。これは自治体から考えてもかなり厳しい。
鉄道も利益率 -80% なんて数値もざらで、経営改善でもどうにもならない。
これは鉄道に限らず、収益性の面で厳しい。タクシーすらドライバー不足なんかが深刻。
だがこれも技術で転換するチャンスが出てきた、自動運転など。
マッキンゼーアンドカンパニー、第四時産業革命センタ共同でここにアサインしてる。
Willer Group でも行ってる。
これはデータを利用したマーケティングを行う、Willer 株式会社(IT企業)。親会社が Willer Express, Willer Trains などがある。
IoT を運送を繋ぐと言う企業。
JR を抜いて、運送売上日本一とか…
日本は灰色は黒、実証実験できない。
なのでシンガポールなどで実証実験してる。
地方においては、人口減少に高齢化はあるものの、インバウンド消費は増えてる。
ここに戦う価値がある。直感的にわかるようになる。
情報を直観に変えていこう。
お客さんにも、その直観を理解してもらい、共存していこう。
現状、全てが縦割りだ。
タクシーバス、鉄道、レンタカー、みんな別々のアプリを独自開発してる。
こんなの効率的ではない。それは統合していこう MaaS という仕組みを構築中だ。
逆に MaaS を中心に、車、鉄道などを連携させていくアプローチである。
京都を拠点に札幌に支店を作った。
MaaS Texh Japan も立ち上がって、開発を行ってる。
MaaS (Mobility as a Service)本も出した。
国や行政機関に支援したり、企業(MSでMaaS、Softbank と自動運転車)にコンサルしたり、地方へコンサル（岐阜で地域通過など）してる
地方と都心部では、マーケティングが違う。
都市部は需要があることを前提だけど、地方は需要も共有も制限がつく。
どう成長戦略を立てるのか？そこにチャンスがある。
全世界都市化が進むから、同じ問題が出る。
前任者なら展開できる。
地方で MaaS 考えると、Suica/Icoca しろって議論になりやすい。
でもそんなの投資も金がひどいことになる。
横串で共通する何かが必要だ。
都市と地方では、データの集まり方も違う。
デジタルを使えば、データの収集も容易である。
問題はそれが普及してない、紙が多い…
政策でもなんでも A/B テストで効果測定すればいいのに、紙ではそのコストが高い
政治側もかろうじてデータに興味を持ってるのは救い。
Willer 的なマーケティングには有効。
東京と地方でデータの出方が全く違うことを示したら響いたようだ。
これは観光のプロモーションでも同じで、イスラムの人に酒蔵とか全く響かない。
意思決定に関わることが理解してもらえるのはでかい。
データが見えれば、問題がわかり、なら解決策も見える。
そう言う意味では地方は必死だし、事業者も必死だ。
自治体はこうした動きには敏感で響きやすい。
例えば事業者の違う鉄道がワンデイパスで乗れたりする。
データを事業の中で収集する -> 解析して問題を洗う -> 意思決定
このループは必須だ。
自治体に全てのリテラシーを求めるのは間違いで、企業は実験だけさせてもらって結果を提案して事業につなげるという方針を取らざるを得ない。
ガバメントの問題は、地方であっても基本が縦割りで連携できない。
そのせいで、地方で統合した形の政策が打てない問題がある。ここを横串でブチ抜く何かが欲しい。
真面目な話構造改革が欲しい。
Willer は消費税値上げに対して、値下げで値下げの実験をしてみる。
利用者の満足度を上げることで何がおきるか、その成功事例を作りたいそうだ。
日本人はデータに興味を示さない、もしくはどう使っていいかわかってない感じがする。
データの重要性と、それをどう理解し、政策などの意思決定に変えていくか考えるべきだ。
Salesforce DX と Lighitning Components で最新 Salesforce アプリ開発
より早くより連携してアプリを作るにはどうするか？
スピーディにアプリを開発するには：
過去２０年ビジョンを出してた、全ての設定において単一のエクスペリアンスで提供することである。
様々なアプリがあり、アインシュタインが存在する。それが全て Lighining で動作してる。
Lighitplatform は１日３回アップデートが入ってる。
Lightning comoinent は Web 標準で作成され、生産性、パドーマンス、互換性が得られる。
2014 年はWeb 標準があまりにチープで見た目しか作れなかった。
それをどうにかするために、様々なベンダーが多種のフレームワークができた。
aura はその一つだ。
Salesforce は昔から標準に関わった
今ではフレームワークでカバーする範囲の多くが Web 標準となった。
Salesforrce ではアプリのギャラリーがあり、即サンプルを実行できる。
例として Recipi というものがあり、Lightning Component を 30 行以内のコードで Lightning Component のサンプルを作成している。
これで何ができるかわかるはずだ。
これらは編集すれば即座にその動作を変更できる。
aura にある絹はほぼ全て Lightning Component で使える。
Apex をどう使うか？
Searchbox の Recipi をみてみるといい。
検索機能なのだけど、Apex のクラスは import と Weire アノテーションでもって読み込むことができる。
非常にシームレスに連携できる。
メタデータに関しては、オブジェクト名->フィールド名の順番で import することで JavaScript 側で取り込める。
LightningComponent はどのように aura を取り込んでいるのか？
<c:ContactList> のようなタグとして取り込んで利用してみた場合、Js 側では connectedCallback というコールバックメソッドで連携できる。
Google で 検索すると色々出てくる
LightWebComponent は現在オープン化してきており、Lightning Platform 外でも同じフレームワークを利用できるようにすべく実装中だ。
こうすることで、様々なオープンソースと連携して開発をつかえるようになる。
様々なプラットフォームでこれを利用することができる。
コントリビュータになってもらってもいい。
node のコンパイル型として作成されていて、簡単には npm run コマンドでローカル実行できる。
もちろんレシピも、オープンソース版がある。
これによって高速で開発ができるようになってくる。
協調性
より迅速に開発し、余計な手間ヒマをかけない、そのために SalesforceDX が存在する。
Salesforce DX では IDE と統合できる。VSCode/InteliJ などだこれらと対応するプラグインを用意している。
これにより、静的コード解析ツールなど、好きなツールを利用し、より標準的、生産的な開発ができる。
これによって、git,circleCI,Jenkins などとも連携できるようになり、継続的なデプロイがかのうになる。
ここでは組織開発でも、パッケージ開発でも行うことができる。
サンプルアプリとしては EBikes というサンプルアプリがある。
自転車販売（架空）のアプリだ。
デモの中で、ライブコードで機能追加している。
push でスクラッチ組織に入り、デプロイで本番組織にデプロイできる。
デプロイしたら、AppBuilder で追加して動かすことができる。
pull を使えばローカルにもってくることができる。
本番組織なら retrive を使う。
VSCode ではデバッガも存在し、ブレークを仕掛けることでその時点でのデバッグ情報を VSCode 上で確認を行うことができる。
ライフサイクルの中でテストをどうするか？
Jeff という JavaScript ライブラリによって、「ローカル上でテストを実行することができる」。
未来のフィールドサービス
デジタルトランスフォーメーションが全てを変化させてきている。
日本の製造業を取り巻く環境・課題も見えてきている。
ヒアリングしてみると、製造業が強化しようとしているのは多くは「アフターサービス」とこたえるようだ。
セールスフォースでは、アフターサービスを「顧客にもたらす価値を最大化する活動」と考える。
顧客体験価値の最大化とも言い換えられる。
これが意思決定になると答える企業が 8 割なのだそうである。
アナログで、属人化した世界が中傷では広がってる。
Digital Ecosystem によって、顧客とシームレスにつなげよう
受動的から、能動的、データの活用と予測に持っていきたい。
充実したセルフサービスと、開発力の最大化によってそれができると考える。
Salesforce Lightning.
Demo1
スマートマンションでの顧客体験。
食洗機からアラートが出たケース。
IoT/AR を活用して、マンション住民に自己解決をできるようにしよう。
家具から問題をiPadに通知 -> iPad からアプリ経由で問題検索 -> 保守契約や解決方法の確認。
それが難しいときに、アインシュタインによって問題の理解と、問題解決の手順を検索。
AR / 動画によって問題解決の手順を提示。
自己解決なので最速、金もかからない、みんなハッピー
なお、Salesforce 連携なので、問題解決のログなども Salesforce に記録される。
これによってさらなるヘルプや今後の改善の情報につながる。
多くの企業(8割)において、フィールドサービス部門が鍵になってる。
Demo2
機械式駐車場をりようしたときに、途中で停止してしまったケース。
- ディスパッチャが問題を受け付ける。（サポート窓口）
- 問題が起きると、電話がかかるが、Salesforce がこれを認識し、関連情報を即座にオペレータへ表示
- 問題履歴や、その人の位置座標などから問題をオペレータが勝手に認識。エンジニアの派遣を申請。
- 必要な作業指示などは過去の情報などから Salesforce が判断、手順なども作成
- エンジニアの現在位置、スケジューからどこから派遣するかを設定（いける担当者と、位置、スキルからスコアリングして表示）
- 派遣されたエンジニアが解決仕切れない時に、スマートグラスの AR からシニアエンジニアの手助けを受けれる。
Demo3
ドローンを使った点検。
Salesforce からドローンを起動・操作。
アインシュタインが画像から自動で解析、問題があればその場で通知するなどできる。
このように、様々な人、物が Salesforce を介してつながることで、ユーザ体験、現場支援がいずれもできる。
地方老舗質屋に革新的テクノロジ注入。リユース業界のデータ活用
株式会社ものばんく 様事例。
真贋判定、鑑定を AI でやるとかやってた先進技術に抵抗のない企業とのこと。
アイディアソンもやってる企業。
家業から起業家した話 10 分ほど（汗
日本初 大会式オークション。
C2B+B2B オークションという。
初期は 17 社（21年前）。
当時は
- 情報が都市に集中
- 安定した相場がない
- さんちゃん(3人)商売なので外に出れない
- 真贋情報が定かではないので高額商品の取引がやりづらい
- プロ鑑定士不足
そこから今では 1,050 社参加。
２年は日本中回った。
最近では「質屋学校」などをはじめて、情報のオープン化を行なっている。
これによって、例えば相場表などを開示して、質屋が価値を見やすくするなどできるようになってる。
今の課題
- 地検がなくて適正価格で買い取れない
- 本物かどうか自信がない(大抵店舗はバイト)
- 眠ってる動産があるのに流通できない
- フリマアプリでは高額商品の取引が行いづらい
- 真贋判定や適性価格のわかるプロ鑑定士がいない
日本には 7 大オークションがある。
日本一をめざしてるのに、途中で抜かれた。
上場企業4社、二社が合同、単独企業では ものばんくさんだけ。
彼らは規模がそもそも強力なので、一気に席巻された。
そうなると、地方であることがネックになってきた。
頑張っていても、上場企業があっさに抜いていく…戦い方が変わってきた。
企業的にはオペレーションは日本一、でもそれでは戦い仕切れない。
強みはなにか見直したら、
これを Salesforce でゲームチェンジしようとしてる。
このセッションは成功事例「ではない」「今チャレンジしているという報告だ」来年でポルシェが買えるれべるの投資をしてる。
slack 導入のアンケートをとって、不満点があれば 1on1 でごりごりやってる。
それを続けたら、パソコンをいじれないなんて言ってた社員が、ユニークユーザ数などの統計、サマリを 1.5 年でさっくり出すようになった。
正直死ぬほどしんどい。けど、この状況を考えれば社員全員が IT リテラシー持つだけで一気に変わる。
アイディアソンは超オススメ、これやると全く違う。
アイディアソンを議事録にして添削して、Salesforce にデータを集めてみれば、一気に変わる。
今では AI での鑑定を始め、中国での展開も始めた。
プラットフォームを超えたアプリケーション統合
Enterprise message bus というものがあり、イベントプロヂューサがここにメッセージを投げると、コンシューマにブロードキャストする。
これをどう Salesforce に適用しているか？
ストリームは第一第二世代がある。
第二世代だけ話す。
プラットフォームイベント
ストリームイベントはイベントはぷっしゅでブロードキャストする。
これは一方通行で、イベントをポンポン飛ばす。
そのため、拡大には非常に楽
もう一つは記録型イベントで、これはサーバ上にデータがあるだけ、クライアントが pull する。
Salesforceのストリームイベントは、最大７２時間きろくしていて、再実行可能だ。
また認証・権限がなければならず、セキュリティはこれだけだ。
項目レベルにセキュリティはない。
ぷらっとフォームイベントはカスタム項目で作成され、手動で実行する。
主な用途はアプリや IoT といった外部プラットフォーム連携、結合された複数オブジェクトレコードの統合だ。
Salesforce Platform を Enterprise messaging bus とみなすと、パブリッシャは 外部アプリ（APIコール）、Salesforceplatform(Apex/ProcessBuilder/Flow)でトリガする。
ここから Bayeux(CommetID, Socket io, etc) プロトコルにより、外部アプリへ。Salesforceplatform には EMP API/ApexTrigger/ProcessBuilder/Flow などで連携する。
変更データキャプチャ
対象の sobject によって定義されたカスタム項目をもつイベント。
レコードが変更されると自動で公開する。
デフォルトではレコードID のみ入ってる。
これは、レコード変更通知・外部ソースとの同期化などに利用する。
StreamingAPI の利点
イベント駆動型アーキテクチャであり、システムの連携のほか、依存性の排除ができる。
ストリーミング API を利用できれば、言語/ライブラリに関わらず連携できる。
イベントの通知しかできないことから、相互のデータ依存や順序性の確保などを気にする必要がない。
依存性が薄いと言うことはスケールもしやすいと言うことだ。
MuleSoft Anypoint Platform を利用すれば、それをさらにスムーズに連携させることができる。
Winter 20 で
まとめ
StreamAPI を使うことで外部システムを連携できる。
イベント駆動で、リアルタイムでありながら、依存性の排除が可能になる。
リソースとして、Trailhead があり
- 変更データキャプチャの基礎
- プラットフォームイベントの基礎
- インスタント通知アプリケーションの作成
というものがあり、ライブラリ的に
Streaming Monitor というライブラリを用意した。
有効に使って欲しい。
注意
制限がある、APIの利用回数とサイズ制限だ。
そこには注意が必要になる。
個人メモ：
要するに、オブジェクト（Salesforce外で言えばデータドリブン）でデータの変更/同期によって、シームレスに処理しようという話だ。
その方法は StreamingAPI を利用することで実現できる。
モデルのイメージは Enterprise messagee bus なので、クライアント通知は基本的にブロードキャストなので、それを受け取って Salesforce からのデータを受け取る。
外から、Salesforce には カスタムフィールドと、カスタムイベントを Salesforce 上で定義する。
クライアントはそれを利用し、API 経由でレコードの更新などを行う。するとイベントが発火される。
Mulesoft によるシームレスなオムニチャンネル体験の構築
拡散したチャンネルによりショッピングのエクスペリエンスが変革してる。
今まではトランザクションのみがコマースだったのだが、現在はより早く、より楽に、シームレスに購入できることがコマースになってる。
顧客の 85% は複数のチャンネルで商品情報を検索、75% が購入履歴に基づいてパーソナライズされたサービスを希望し、50% のオンライン行動は実店舗から始まってる。
複数（オムニ）チャンネルの顧客は支出が 41% 多い。63% の顧客は共通したエクスペリエンスを求める。
しかし、経営陣の 78% でそれは達成できていない。
これにはアプリケーションの連携・統合が必要だが、こうしたアプリは 29% しか接続されていない。
MuleSoft の API Connectivety の考え方は、API を活用することで、アプリケーションのコネクチビティを共有活用できるというものだ。
そこで、 Salesforce 上との間に中間的に共通したハブ（Mulesoft）を突っ込むことで、様々なデバイス/アプリから統一したエクスペリエンスを確保する試みだ。
API-led アプローチを活用することで、検索の容易性、セキュリティ、TimeToMarket の迅速性を確保できる。
例えば、SAPで管理するシステム、MySQL のシステムがあり、相互接続した＋モバイルからも見たい…となった時に、どうするか？
このハブを Mulesoft のデータ（on salesforce）で統合してしまう。
MySQL コネクタを使って、レガシーデータベースから Salesforce をデータソースに変更。
MuleSoft はデータベースコネクタ、などの用意があるので、これによって既存のアプリをほぼ変更することなく Salesforce 統合できる。
新アプリは MuleSoft の API を叩けばよく、MuleSoft は（元）MySQL のシステムと、SAP 運用システムにそれぞれ適切に割り振って実行できる。
例えばこれで 2 店舗が個別のシステムを採用していても、これによって同時に 2 店舗の商品を MuleSoft のシステム上でリクエスト（1回）したとき、 MuleSoft はそのリクエストを分解し、個別の店舗へリクエストすることができる。
Macdnalds も Mule と提携してる。
事例として、モバイルアプリを出して若い世代にリーリしたかった。
ところがリージョンの違いに、店舗まであまりにもガラパゴが過ぎた。
そこで、MuleSoft でもって API 連携を行うようにし、結果的にトランザクションなども含め 3 倍の高速化ができた。
API による相互連結を可能にしたことで、おもちゃ製作会社からもリアルタイムに生産状況などの調整や情報が上がるようになった。
