2月20日にWindows女子部で「Dynamics 365 Customer Engagement 理解のススメ -サブスクリプションビジネスモデルから読み解くカスタマーサポート機能活用のポイント-」の発表をしてきました
久しぶりに Dynamics 365 一色なセッションを2月20日にWindows女子部で発表してきました。
(Burikaigi 2019ではちょっといろいろ手を出していたのと共同セッションだったので、また今回は毛色が違いますね。)
第して、「Dynamics 365 Customer Engagement 理解のススメ -サブスクリプションビジネスモデルから読み解くカスタマーサポート機能活用のポイント-」
以下でセッションスライドを公開しています。
なんでこんな発表をしようと思ったのか?
今回 Windows 女子部という、あまり普段 Dynamics に馴染みが無い層の方々向け、ということを考えていた部分もありますが、
おそらく大きく影響したのは私自身が「SIerでは無くなったこと」が大きなきっかけとしてあるなと思います。
視点が実際にCRMを使って、業務を効率化したり、可視化する側のエンドユーザーサイドに立ったことで、今までの自分自身の知っているコンテンツを棚卸しし、かつ私自身のエンドユーザー経験も踏まえて、Dynamics ってこういうことじゃないの? というお話をまとめてみたいなーという野望がありました。
かつ、昨今 Power Platform (Power Apps / Power BI / Flow)が広まって、徐々に認知されるようになってきた Dynamics 365 シリーズですが、まだ実際に触った方は少ないのではないかなと思うので、そもそも Dynamics 365 を理解するためには、何から始めるべきなのか? という下地の部分を訴えてみたかったところもあります。
機能とかデータモデルとか触ってみるとかのその前に、「考え方」「捉え方」から伝えてみたい。それが以下の1スライドのメッセージでも掲げられているところかなと思っています。
Dynamics 365 CEを理解するためには Dynamics 365 CE を知る・触るよりも前に 何かの課題を解決しようとした ビジネスモデル・手法を理解する必要がある
それをより明確に伝えるため、昨今のビジネスモデルの流れ、サブスクリプションビジネスモデルを取り上げることで、よりよく Dynamics 365を理解するための礎になればという感じでした。
個人的にテクニカルな内容は5%くらいで、かなり新しい試みのセッションになりました。
すごく独断と偏見と経験にまみれた内容ではあります。(Microsoftはこんなことを言ってはいないw)
でも、ビジネスモデルに多様な「解」があるように、おそらくこれも一つの「解」なのだと思って見てもらえると嬉しいです。
今後 Dynamics 365 の導入を予定されている会社の参加者からも「すごく参考になった、ここのなぜ? どうやって?使うのかという意識の部分は、私の会社でも根付かせていかなければいけない」といったコメントをいただけて、個人的な棚卸しも含めてとても有意義なセッションだったなと思います。
せっかくなので、このあたりの「考え方」の部分は、今後もどこかで発表しつつ棚卸ししていきたいなと思った次第です。
Microsoft MVP更新の季節。CData Excel Add-Inを使って、Twitter での活動情報をさくっと可視化してみる
Microsoft MVP 更新の季節がやってまいりました。
昨年から Microsoft MVP の更新スケジュールが代わって、年度末である3月に統一されましたね。
Microsoft MVPの申請・更新には日々どのような形でコミュニティに貢献したかどうかを数値化、文書化して貢献度を可視化する必要があります。
昨今ですと、Twittter や FacebookなどSNSでの活動状況も入力するシチュエーションがあるかと思います。
ただ、ちまちまと記録をさかのぼって、集計するのもなかなか骨が折れる作業ですね・・・。
そこで、そんな面倒な作業を CData Excel-Addinを使って、Excel上でさくっと集計・可視化する方法を紹介します。
Microsoft MVP 向け CData ツール・ドライバーの無償提供
ちなみに、通常 CData Driver は有償のツールなのですが、Microsoft MVP向けには個人利用の範囲で無償のライセンスを提供しています!
以下のURLから申請することが可能ですので、是非申し込んでみてください。
https://www.cdata.com/jp/community/mvp/
私のTwitterやFacebookに直接ご質問頂いても大丈夫です。
ちなみに、今回はTwitterですが、FacebookやInstagram、Youtube、Wordpress などのExcel Add-inもあるので、そちらも集計することが可能です。
必要なもの
・Twitter アカウント
・Twitter ClientID・ClientSecret・AccessToken・AccessTokenSecert
実施手順
それでは具体的な実施手順を説明していきます。
Twitter アプリ登録・認証用情報の取得
まず CData Excel Add-inを通じて Twitter APIにアクセスするために、Twitter APIアクセスに必要な各種情報を入手します。
詳しい入手方法は以前私がBlogにしたためているので、参考にしてみてください。若干UIが変わっていますが、大筋は同じです。
CData Twitter Excel-Addinのダウンロード・インストール
次に、CData Twitter Excel-Addinを入手します。
以下からトライアル、もしくはMVP用のライセンスがあればそれを使って、ダウンロードし、セットアップしておいてください。
https://www.cdata.com/jp/drivers/twitter/excel/
セットアップは特に難しい設定はありません。
そのまま次へ次へと進めていくだけでインストールが完了します。
CData Twitter Excel-Addin の 接続設定
インストールが完了するとこのようにExcelにCData タブが追加され、アドインを利用できるようになります。
それでは、実際に接続をしてみましょう。「取得元Twitter」をクリックして、接続画面を表示します。
表示された接続プロパティ画面に、事前に取得しておいた「ClientID・ClientSecret・AccessToken・AccessTokenSecert」を入力します。
OKをクリックして、接続テストを行い、以下のように「サーバーに接続できました」というメッセージが表示されれば、OKです。
CData Excel Add-inでは、SQLベースでTwitterのデータが取得できるようになっています。
SQLを知らなくとも、Twitter データがテーブルやビュー・カラムの構造になっているので、かなり直感的にTwitterのデータが取得できると思います。
今回は自分自身のツイートデータを取得したいので「Tweets」テーブルを選択します。
そして、下のSQL入力フォームに、各種条件のSQLを記述します。
例えば今回私はDynamics のデータを取得したいので、「[From_User_Screen_Name] = 'sugimomoto'」で私のツイートの絞り込み、「Text Like '%Dynamics%'」で Dynamics に部分一致の指定を行います。
SELECT * FROM [CData].[Twitter].[Tweets] WHERE [From_User_Screen_Name] = 'sugimomoto' and Text Like '%Dynamics%'
入力完了後、OKをクリックすれば
このように過去に私がDynamics についてつぶやいたツイートの一覧が取得できます!
あとはピボットテーブルで、IDの合計でツイート数、Favorite_CountとりRetweet_Countを取得すればOKですね。
(私の今年度の Dynamics ツイート少ないな・・・orz)
注意事項
Twitterの無償APIは最新のものから最大3200件までしか、ユーザータイムラインのツイートを取得できません。
上記出力結果は3200件のデータを裏で取得して、そのなかの Dynamics が含まれているキーワードだけ算出しています。
1年間に3200ツイート、1ヶ月260ツイートくらいまでが取得の目処になるので、Twitter中毒の方は要注意。4半期に1回とかやっておくといいかもしれないですね。
有償のAPIを使えば、もっと柔軟に取得できますが、なかなかお高いです・・・。(最低1万円はくだらない。)
終わりに
いかがでしたでしょうか!
今回はTwitter データだけでしたが、前述の通り他にもFacebookやInstagram、YoutubeなどのDriverもあるので、是非各種Driverでも試してもらえればと思います。
何かわからないこと、こんなことできないの? みたいなご質問があれば、TwitterかFacebookでお気軽にどうぞー。
2月20日(水)に虎ノ門で「Windows女子部/初心者向け:Dynamics365 カスタマーサポート業務での活用ポイント解説」を開催します!
Burikaigi 2019に続いて、Dynamics 365 関係で登壇することになりました。
今回はMS MVP の方々がリレー形式で登壇を担当する企画を開催している「Windows女子部」で発表します。
そして、珍しくというか、久しぶりにというか、初心者向けと銘打って、カスタマーサポート機能を中心に「Dynamics 365 Customer Engagement」を解説する予定です。
具体的にどんなお話をするの?
でも、そもそも今回お話する「Customer Engagement」、名前からして、今までDynamics 365 に関わってこなかった方々にはよくわかんないですよね。
顧客管理とかSFAとかMAとか、キーワードや世の中の風潮?みたいなもので大事っぽいっていうのはなんとなく理解している。
でも、じゃあ Dynamics 365 を使ったからって何が変わるの? っていうのがイメージできない。そんな方が多いのではないかなーと漠然と思ってます。
今回実は初心者向けとは銘を打ちつつも、個人的に結構新しい試みをしていて、昨今のビジネスモデルを土台にしながら、Dynamics 365 をどのように解釈すればいいのか? その上で、なんでこんな機能があるのか? どんな風に使えるのか? というのをお話する予定です。
是非、今まで Dynamics 365 を触ったことが無い人も、触っている人も、開発している人も、参加してもらいたいなーと思います。
3月1日(金)に仙台で「【JAZUG TOHOKU】ZOZO前澤社長お年玉リツイート企画のビッグデータに立ち向かう方法」を開催します!
1月28日(月)に日本マイクロソフト品川本社セミナールームで開催した「ZOZO 前澤社長のお年玉リツイート企画は、どのくらい世の中に影響を与えたのか?」の仙台スピンオフを開催することになりました!
イベントページはこちらからどうぞ。
【JAZUG TOHOKU】ZOZO前澤社長お年玉リツイート企画のビッグデータに立ち向かう方法 - connpass
東京開催時のTwitterまとめもあるので、どんな感じなのかなーと気になっている方は見てみてください。
会場は以前も Azure 勉強会でお世話になりましたSRIAさんのオフィスです! 仙台駅から徒歩圏内。
セッション終了後には LT & ビアバッシュ会になっていますので、是非お気軽にご参加ください!
500万件を超えるTwitter のリツイート データを取得・分析する方法 -Twitter Premium Search API を実際に使ってみてわかった嵌りポイントとその対策-
このBlogでも告知していましたが、今週の月曜日1月28日に日本マイクロソフト品川本社セミナールームC+D で「ZOZO 前澤社長のお年玉リツイート企画は、どのくらい世の中に影響を与えたのか?」を開催しました!
開催前はこんな色物企画に本当に人が来てくれるのだろうか? とずっと半信半疑でしたが、最終的に申込みは4営業日ほどで満席(108席)になりまして、イベント当日もたくさんのツイート、ご質問をいただけて、個人的にとても得るものも多く、楽しいイベントとなりました!
以下のまとめでどんな雰囲気だったか垣間見ることができるのではないかなと思います。
ただ、私自身がやったことは、このイベントのタイトルから見えるよりも、ひたすら地味なもので、Twitter API の「制約」・「制限」・「仕様」をどのように回避・咀嚼しながら、対象の500万リツイートデータ取得と分析に挑むのか? といったものでした。
もちろん、取得してきたデータから見えてきたことも最後のほうで紹介したいと思いますが、この記事としては今後 Twitter 上でキャンペーンなどを展開していく企業やユーザーの役に立ってもらえればという考えで書いています。
こんな色物な取り組みですが、是非いろいろと参考にしてもらえると幸いです。
なお、さっくりと見たい方にはほぼ同じ内容のスライドも公開しています。
- なんでこんなことをしようと思ったのか?
- 立ちはだかる「嵌りどころ・落とし穴」たち
- 1.どうやって500万件のリツイート(+アルファ)を取得するの?
- 仮に ZOZO前澤社長が本気で API を使って抽選しようとした場合どうなるか?
- 2.どうやって対象のツイートを識別するの?
- ボトルネック③ どうやって Twitter の JSON データを構造化するの?
- Basic Tweet Format
- Extended Tweets Format
- Retweets Format
- Retweets and Quote Tweets Format
- 解決アプローチ
- ボトルネック④ どうやって DB にデータを流し込むの?
- めんどくさいこと
- データ投入アプローチ
- 終わりに
Java クライント開発における Web API の実装アプローチ まとめ REST vs GraphQL vs Swagger vs OData
最近作成してきた、Java クライント開発における Web API の実装アプローチのまとめ記事です。
初めての試みでしたが、私自身多くの発見があり、とてもいいナレッジになったのではないかなと思っています!
この記事では、まとめとして総括した内容を中心にお伝えしますが、是非以下の記事郡を見てほしいと思います。
タイトルでは vs なんてことを書いていますが、それぞれの特徴を把握してもらうことを目的としています。
各記事の一覧
Java クライント開発におけるWeb API の実装アプローチ:その1 Web API を活用する上で意識したい APIエコシステム - Morning Girl
Java クライント開発における Web API の実装アプローチ:その2 一般的なREST API編 - Morning Girl
Java クライント開発における Web API の実装アプローチ:その3 Swagger(OpenAPI)Code Generate 編 - Morning Girl
Java クライント開発における Web API の実装アプローチ:その4 OData 編 - Morning Girl
Java クライント開発における Web API の実装アプローチ:その5 GraphQL 編 - Morning Girl
Java クライント開発における Web API の実装アプローチ:その6 CData Driver編 - Morning Girl
REST・Swagger・OData・GraphQL比較表
あまりマルバツ表は好きではないのですが、改めてそれぞれの特徴をまとめました。
REST を比較するのはあまりにも難儀ですが、ここからも「結局の所 REST はデザインパターンである」ということが明確にわかるのではないかなと思います。
あまり意図してつけたわけではないのですが、思ったよりもそれぞれの長所・短所がはっきりする結果になったのではないかなと思います。
Swagger・OData・GraphQL それぞれを使ってみた所感
Swagger
Code Generate で生成した Client SDKの使いやすさはピカイチでした。現在公開されている API を右肩あがりですので、知っておいて損は無い仕様だと思います。
ただ、ドキュメントのアップデートに気を使っているかどうかは、そのプロバイダーにかかっていますし、メタデータは Swager の記述アプローチ次第なところもあるので、その辺を注意しながら使う必要はあると思います。
OData
スキーマやリクエストのコントロールのアプローチは確立されていますが、アーキテクチャとしての複雑さ、使う敷居の高さは若干否めません。
ただ、Salesforce・Dynamics 365・SAP などが OData で API を提供しているため、エンタープライズ領域としては把握しておいて損は無いでしょう。
特に、ツールやサービスとの接続には依然多く利用されるシチュエーションに溢れているため、この点を知っているかどうかで、選択肢の幅は大きく変わります。
GraphQL
上でも述べた通り、Java Client から使う、となるとまだまだ敷居の高さは否めません。
実際のところ Java で使うよりも、React といった Java Script系クライアントライブラリで利用する、というシチュエーションの方が、現在は多いと思います。
しかしながら、Github や Shopify がパブリックなAPIを公開したところを見るに、これからエンタープライズ領域でも見かけるシチュエーションは多くなるのではないでしょうか。
Microsoft も一部ベータ的に GraphQL API を公開し始めましたし、今後ウォッチしておく価値はあると思います。
最後に。なぜ開発者が API のエコシステムを理解しておくことが大事なのか?
おそらく Swagger と GraphQL が出てきたタイミングから Web API(REST)の捉え方は変わってきています。
ただ Web API(ないしREST)として、それらに接することはあまりにも脆弱になってしまったのだと思います。
Swagger で CodeGenerate することを知らなければ、クラス名を一から記述することになり
OData で Metadata を取得することを知らなければ、動的なアプリケーションは作りづらい
仕様であることを理解しているだけで、開発者が取れる選択肢は格段に多くなります。
そして、それが適切かつ保守しやすい開発に繋がることは間違いないでしょう。
API を実装する側ではないからといって、API エコシステムを疎かにしてはいいわけではない理由がここにあると思います。
是非、各仕様・エコシステムを理解してもらいながら、開発に役立ててもらえたらなと思います。