チームスピリットデベロッパーブログを振り返る

こんにちは。プロダクト開発チームの松田(id:a-matsuda)です。

今年も残りわずかとなってきましたね。年末といえば 1年を振り返って成果を祝福したり、できなかったことを反省したり。そして来年は何をしていこうかと次なる目標を考え始める時期ではないでしょうか？

そこで今回は、はてなブログに引越しをして丸 2年となったこのチームスピリットデベロッパーブログを、google Analyticsのデータをみながら、振り返っていきたい思います。

チームスピリットデベロッパーブログとは

チームスピリットのプロダクト開発チームの有志メンバーで書いているブログで、12月のAdvent Calendarの時期は、投稿数が多くなります（笑）これまでは、魂のブログという会社ブログのなかで投稿をしていましたが、2016年12月に独立、はてなブログに引越しをしました。

ブログビュー数ランキング

さあ最初は、みなさんがきっと気になる「ブログビュー数ランキング」です！

第5位：Slack×GAS 契約自動更新サービスの稟議忘れを防ぎたい！（ビュー数：461）

teamspirit.hatenablog.com

Slack×GAS連携を取り入れてから1年が経ちますが、おかげさまで稟議申請忘れが大幅に削減され効果を実感しています。 この記事でもご紹介している通り、Googleカレンダーの情報を抽出してSlackに通知をするなど、GASとSlackを連携させることで業務効率化や品質向上に繋がる様々な仕組みを構築できるので、そのあたりが注目されたのかもしれません。

第4位：入社して10ヶ月がたったので入社エントリ書く（ビュー数：512）

teamspirit.hatenablog.com

メンバーの入社エントリーですが、チームスピリットの自由な働き方や仕事に集中できる環境について紹介をしてくれています。 フレックスタイム制、スタンディングデスク、リモートワークやチームの雰囲気など盛りだくさんなので、気になった方はぜひチェックしてみてください。チームスピリットの働き方や環境に注目が集まることは、とても嬉しいことですね！

第3位：スクラムMTGに【Lean Coffee (リーンコーヒー)】を導入してみた！（ビュー数：642）

teamspirit.hatenablog.com

Lean Coffee というミーティング方法をご存知でしょうか？ ご興味の湧いた方は、ぜひ記事をご覧くださいね！ この記事に注目が集まったのは、みなさんミーティングのやり方について試行錯誤をしているということかもしれません。 新しいミーティング方法があれば知りたい、もっと良いミーティング方法はないのだろうか？と考えている読者のアンテナに引っかかったのではないでしょうか。

第2位：Amazon Echo から Salesforce へ繋げてみた（ビュー数：866）

teamspirit.hatenablog.com

GoogleHomeやAmazon Echoに世の中の注目が集まっていた2017年の記事で、GoogleHomeやAmazon Echoで何ができるのか、色々試してみようという動きが多かったですね。そういう意味では、世の中の興味・関心にマッチした内容になっていたことが、記事のビュー数アップに繋がったのかもしれません。

第1位：Google Homeから音声で出退社を記録する（ビュー数：1213）

teamspirit.hatenablog.com

圧倒的なビュー数で第1位を獲得したのは、GoogleHomeとTeamSpirit連携です！！おめでとうございます。 第2位と同様、2017年の記事で、GoogleHomeには注目が集まっていました。第2位からダントツ引き離したのは、やはりTeamSpiritと連携するというチャレンジをしているところでしょう。TeamSpiritのユーザ様をはじめ、エンジニアにも刺さる記事だったことは間違いありません！

アクティブユーザ数の動向は？

ランキング以外も振り返っていきましょう。アクティブユーザ数（以下AU）とは、特定の期間内にサイトを訪れたユーザーの数を表す指標のことです。月別のAUは2017年12月以降大きく増加しています。2017年のAdvent Calendarに取り組んだ後から増えていますね。ランキング第1位、第2位の記事が投稿されたのもこの時期です！

アクティブユーザ数

ユーザの地域は？

日本、シンガポール以外に、アメリカからのアクセスもありますね。Dreamforceに参加したチームスピリット社員からの閲覧かもしれません。今後はますます、世界のエンジニアからも注目される記事を書いていきたいですね。

セッション数（国別）

もっともよく使われるデバイスは？

まだまだPCからの閲覧が多い印象です。お仕事中にみてもらっているのでしょうか。

デバイス別セッション数

まとめ

簡単ではありますがチームスピリットデベロッパーブログの2年の奇跡を振り返ってみて、いくつかの気づきがありました。 これらを生かして、来年もこのブログを盛り上げていきたいと思います！！

• （当然ですが）世の中の興味・関心が集まっている技術や取り組みに注目が集まること
• TeamSpirit×興味・関心のある技術の組み合わせに期待されていること
• Advent Calendarは新しい読者を獲得できる素晴らしい取り組みであること
• 日本やシンガポール以外の国でも記事をみてもらえるチャンスがあること

エンジニア募集♪

チームスピリットではエンジニアを募集しています。チームに興味を持っていただいた方、ご連絡くださいね。（直接メッセージでも、下記の応募フォームからでも構いません）

終わりに

最後になりましたが、この投稿は チームスピリット Advent Calendar 2018 - Adventar 第21日目の投稿になります。

TeamSpirit Singaporeと日本の開発チームがうまくやってる話

Hi everyone! TeamSpirit Singaporeの二宮です。
私がTeamSpritの海外開発拠点の社員一号として入社し、気づけば6ヶ月が経ちました。

前回のTeamSpirit Singapore紹介記事はこちら。

teamspirit.hatenablog.com

今ではシンガポールのメンバーも増え、日本の開発チームと連携しながら、いい感じに開発が進められるようになって来ました。
今回はその事についてシェアしたいと思います。

 開発体制について

まず現在の開発体制、日本とシンガポールチームの位置付けについて説明したいと思います。

ざっくり、こんな感じになってます。（※チーム名は仮称です。）

一つの製品を、モジュールで大きく2つのチームに分けて、その片方のチームが日本、シンガポールの混成チームになっています。

（Team Bの内訳は、日本：PM 1,スクラムマスター兼QA 1, エンジニア 3、シンガポール：エンジニア 5）
なので、もちろんスクラムイベントは日本とシンガポール両方のエンジニアが同席して行われますし、プロダクト横断の大きなスクラムイベントにもシンガポールからリモートで参加しています。

シンガポールチームの歴史

下記がシンガポールチームの人数推移です。

6月から始まって、少しづつですが、着実に人数が増えて現在は5人になりました。

上記の様に、国際色も豊かです。すべての国が分かりますか？

今後も、少しづつ人数が増えていく予定です。

コミュニケーションのとり方

シンガポールチームと混成チームになってから、チームの公用語は英語になっています。

スクラムイベント、チケットの表記、Slackでのやりとり、その他ドキュメントは基本英語ファースト（英語、もしくは英日併記）です。

とはいえ、全員がいきなり英語をペラペラに話せる訳では無いので、日本人同士の場合は普通に日本語を使っています。

始めた当初は全く自信がなかった日本メンバーも、学生時代の読み書きの経験＋Google先生のおかげで、Slack上でのコミュニケーションはだいぶスムーズになってきています。

口頭でのコミュニケーションが必要な場合は、私が通訳サポートすることもありますが、基本的にダイレクトにSlackなどでやりとりできています。

海外と一緒に仕事をするというのは一見ハードル高そうに見えますが、エンジニア同士の場合、そもそもプログラミング言語という共通言語があるので割となんとかなります。

シンガポールのメンバーも、コミュニケーションについて不便に思っていることは殆どなさそうです。

どこまで英語でコミュニケーションするか

ここが一つのキーとなる要素になるかと思っています。

よく英語化の事例とかで、社内英語公用語化！などと一気にすべてを英語に置き換えることを大々的にやっているところもありますが、私の感覚だとそんな必要はないと感じています。

ドキュメント類は読めないとわからないので英語、これは必要。

残りのミーティング類については、すべてを英語で行う必要はないというのが今の所の答え。

最低限は事前に用意して英語でやる、残りの込み入った部分については私が軽く通訳しながら、要点は後から改めて共有、それが効率が良くて早いです。

残りの小さな疑問や、質問については、ドキュメントや画面、ソースを見ながら後から直接個人間でSlackなどで英語でやり取りして埋めていけています。

今はそんな感じで状況に応じて、コミュニケーションの方法を変えていってうまく行っています。

出張によるF2Fのコミュニケーション

重要な開発が始まる時は、日本からPMやエンジニアが来て短期的に直接一緒に働くこともあります。

F2Fのコミュニケーションを取ることで、仕様の理解や疑問の解消を効率よく行っています。

普段、画面越しでしかやり取りできない人と直接コミュニケーションできるのも、シンガポールメンバーの刺激になりモチベーション維持にも繋がってます。

交流イベントなど

仕事以外ではなかなか話す機会の無い人たちとは、"オンラインランチ"という企画をして交流を図っています。

"オンラインランチ"とは文字通り、画面越しにランチを持ち寄って、ビデオ通話しながら、雑談しながらランチを楽しむというものです。

顔と名前を知らないと、なかなか仕事上でも話しかけるのを躊躇したりしてしまいますが、このようにお互いを知ることで、オフィスを超えて気軽に話しかけられる関係を構築しています。

まとめ

最初はお互い、海外と仕事をしたことがない日本メンバー、日本と仕事したことがないシンガポールメンバー、という不安でいっぱいなスタートでしたが、今では非常によく開発プロセスが回せています。

英語でのコミュニケーションも最初は拙かった部分もありますが、日々良くなっていっています。

このままの調子で日本と海外で強固な開発チームを実現できるよう、さらに頑張っていきます！

----

この記事はチームスピリットアドベントカレンダー18日目の記事になります。

adventar.org

チームスピリットでのQA仕事内容

はじめに

寒い日が続いていますね。
QAエンジニアの生井 ( id:riririusei99 ) です。
会社ごとにQAと呼ばれる人達は働き方が異なっているのではないかというのが自分の持論で、今回は私が所属しているチームでの働き方を紹介することでチームスピリットに興味があるQAの方の想像と実際の仕事内容のギャップを埋められないかなと考えた。そんな記事です。

開発サイクルと主な仕事

所属しているTeamSpiritWSPチームではSalesforceプラットフォームのバージョンアップに合わせて4ヶ月の開発サイクルを一つの単位として開発を行っています。
2017年よりスクラム開発を採用しており、現在は4ヶ月の開発サイクルを更に2週間のスプリントに分割し、前半6スプリントが開発スプリント・後半2スプリントがリリーススプリントとしています。

開発サイクル単位でのQAの仕事をざっくりではありますが、簡単にまとめると下記になります。

開発サイクルでの大まかな流れ

• テスト計画作成（左上のTest Planning）
• StoryTicket のテスト設計・実施 （緑）
• QualityTicketの実施 （青）
• Test Reportの作成 （赤の範囲部分）
• Quality Reportの作成 （オレンジ）

テスト計画作成

開発サイクルにおける計画を立てます。
私達のチームでは毎回少しずつ項目は違いますが主となるものは下記です。

• 品質目標
• リリース判定基準
• テスト環境
• 活動内容
• テスト体制・スケジュール
• 成果物

StoryTicket のテスト設計・実施

開発チームが作るストーリー毎の機能開発のテスト設計・実行を行います。
QAエンジニアはスクラムにおける開発チームのメンバーとして開発に参画しています。
そのため仕様検討を始めとするすべての会議に参加しますし、必要であれば調査も実施します。

QualityTicket(QA用バックログ)

テスト計画ができたタイミングでQA用のチケット(QualityTicket)のBacklogを作成します。
最近実施した具体的な例でいうと下記のようなイメージです。

• 強化テスト
• Salesforceプラットフォームのバージョンアップテスト
• テスト設計のカイゼン
• テストの自動化
• CIサーバの構築

Test Reportの作成

スプリントレビューのタイミングでTest Reportの共有を行います。
Test Reportではテストの結果と起票されたバグチケットのトレンドからスプリント毎にリスクになる事象・問題がないかを確認しています。

品質評価レポート

4ヶ月毎のリリースパッケージを作成する際には現在のプロダクトの品質はどの程度かレポートを書きます。
ここではQualityTicketの実施状況や、各Test Reportを基にプロダクトの品質に課題があるかどうかとリリースできるような状態かを確認しています。
品質評価レポートは次回の開発サイクルでのテスト計画でのインプットにもなるので重要なレポートになります。

まとめ

いかがでしたでしょうか。 各項目でざっくりと書こうと思ったのですが、ひとつのセクションでも内容があるので簡潔に書いた結果、抽象的な記事になってしまって少し反省しています。

最後になりましたが、この記事はチームスピリットアドベントカレンダー17日目の記事になります。 adventar.org

最後までありがとうございました。ではこの辺で。

2018年に会社が発信した内容を可視化してみる

今年は会社として大きな節目の年になりました。それに合わせて様々なチャネルでの製品や会社情報の発信が活発化していましたが、一年を通じてどんなことをお伝えしていたんでしょうか、、

ということで、Pythonのライブラリで、さくっとテキストマイニングしてみました。

今回は実行環境としてGoogle Colaboratoryを使っています。クラウド上でJupyter Notebook環境が無償で使える、個人的には今年イチオシのML（機械学習）ツールです。

結果の画像

2018年の魂のブログ記事をワードクラウドで表示するとこんな感じです。

うーん、固い、の一言。基幹業務と密接な領域のBtoB SaaSなのでこうなりますが、もう少し柔らかくしたい。 あと、弊社はFintech企業でもあるんですが、そちらの訴求も強くしていきたいですね。

実現方法（ポイント）

以降は興味がある方に向けて、今回Pythonでやったことの流れを書いておきます。

1. Beautiful SoupによるHTMLのパース

• ブログから対象範囲の記事CSVファイルを抽出
• HTMLタグ除去など

2. Janomeによる自然言語処理（形態素解析）

• 品詞のうち今回は名詞を抽出

※使っていたMecabでは上手く解析できず、途中でライブラリを切り替えました

3. WordCloudによる単語出現頻度の可視化

• フォントやストップワード設定
• お遊びでマスク設定

以上、処理時間は数分程度かかりますが、GPUの利用も無料なので有り難い限りです。

結びに

やはり驚愕すべきはGoogle Colaboratory。

ブラウザ上でまるで電卓を使うように対話的にPythonの処理を「無料で」実行が可能。ちょっとしたテキストマイニングなどは、既存の専用製品を使わずに済んじゃうあたりがうれしい一方、Googleのような巨大プラットフォーマーが「無料で」提供してしまうことによる恐怖も感じています、、。違うところで戦わないと死活問題です。

今回のワードクラウドを見て？TeamSpiritに興味をお持ちの企業様は、是非こちらからTeamSpiritが多くのユーザーに選ばれる理由をご覧ください！

この記事は「チームスピリット Advent Calendar 2018」の15日目です。
以上、若林（id:hwakabay）が執筆しました。

【バックエンドランチ #再始動】潜入レポート！

こんにちは。プロダクト開発チームの松田(id:a-matsuda)です。

クリスマス、お正月と転がるように毎日が過ぎていく師走となりましたが、みなさまいかがお過ごしでしょうか？ プロダクト開発チームのフロアには、こんなに素敵なクリスマスツリーが飾ってあり、季節を、いまを、味わうことができます。 毎年ツリーの飾り付けをしてくれている皆さん、ありがとうございます！！

毎年恒例のクリスマスツリーwithアストロ

さて今回は、プロダクト開発チームで行っている「バックエンドランチ」に潜入した様子をレポートします！！

バックエンドランチとは

2018年夏にご紹介したフロントエンドランチの記事はご覧になりましたか？まだの方は、是非チェックしてみてくださいね。

teamspirit.hatenablog.com

バックエンドランチはフロントエンドランチと同様、バックエンド領域の気になる話題や、チームとして解決したいバックエンド課題をネタに和気藹々とランチしながら、侃々諤々盛り上がろうぜ、という取り組みです。 伝統ある？フロントエンドランチに対して、バックエンドランチは長い冬休みに入っていましたが（笑）、最近入社をしてくれたメンバーを中心にこのたび復活を遂げました！

バックエンドランチ #再始動

少し前になりますが、2018年11月6日（火）13:00より「バックエンドランチ」が行われました。

お弁当を持って集合！

メンバーがお弁当を持って集まってきました。

メンバー集合

ナポリタン、美味しそうですねぇ。

ランチ風景

こんなテーマで話をします

バックエンドランチでまず取り上げる大きなテーマは「Apex デザインパターンのアンチパターンについて学ぼう！」です。

Apexとは、Salesforce独自のプログラミング言語で、この言語を使うことで、Salesforceサービスのカスタマイズや修正、トリガーやストアードプロシージャの作成、ビジネス・ロジックの構築、実行などが可能となります。 Apexは、Javaに似ているオブジェクト指向の言語なので、Javaでおなじみのデザインパターンがまとめられています。今回は、デザインパターンの中でも、アンチパターンやベストプラクティスを勉強していこうというわけです。

ApexやSalesforceについてしっかり学んでみたい方は、Salesforce社の提供するTrailheadという秀逸なE-ラーニングツールがありますので、ぜひ取り組んでみてください！

今回の流れ

今回のバックエンドランチは、こんな流れで進んでいきました。

• 学びの進め方
• 一個やってみる：Over usage of formula fields
• もう一個やってみる：Functional Decomposition

学びの進め方

Packt Publishing社から出版されている「Apex Design Patterns（by Anshul Verma and Jitendra Zaa）」を参考図書に、どんな風に学びを進めていくか全員で議論し、参考図書の章立ての順で学んでいくことが決まりました！

サマリも含め、13章あるんですね！

アンチパターンとベストプラクティス

一個やってみる：1. Over usage of formula fields

最初は「数式フィールドの過多」です。数式フィールドは簡単に作成および管理でき、値を動的に表示する場合には非常に便利ですが、レコードが取り出されるたびに計算される計算フィールドです。そのため、コードやレポートを使って大量のレコードを取得するなど多くの数式フィールドを使用すると、システムのパフォーマンスが低下します。また、数式フィールドがクエリまたはレポート条件で使用されると、アプリケーションのパフォーマンスがさらに低下する問題も発生します。

全員で、以下のようなことを話しながら、学んでいきました。具体的に自分たちが開発しているプロダクトでの使用を意識しながら、書いてあることを読み解くと、学びが深まることを実感しました。

• そもそも数式フィールドは、TeamSpiritでどれくらい使ってる？
• TeamSpiritで、●●●のような使い方をしたら、パフォーマンスに大きな問題が出そうだね
• 数式フィールドのパフォーマンスを向上するには、Salesforceのサポートチームに連絡を取ってインデックスを貼ってもらうといいんだね

喋りたいことがいっぱいあります

もう一個やってみる：2.Functional Decomposition

トリガーやページコントローラー内に全てのビジネスロジックを書くことは簡単かつ迅速ですが、維持が難しいので「機能分解」しましょうという内容です。オブジェクトの観点から考えて、それに応じた1つ以上のクラスに機能分解することが非常に重要ですとはっきりと書かれています。

機能分解については、こんな会話になりました。

• 今の開発では割とできているよね。
• 機能分解の視点で、いくつか気になるクラスがあるなぁ。-->アクション一覧に登録しました
• トリガー内にもビジネスロジックが入っているところはないだろうか。呼び出しているケースはどうだろうか。
• トリガーから勤怠計算ロジックを呼ぶというは、アンチパターンだね。

まとめ

このように、学びを通して業務という実践に活かすことを意識しながら進めてきたバックエンドランチ。 実はこの処理が気になるんだよねという内容がポロっと出てきたり、参加したメンバー全員が、意見や気づきを積極的に、かつ楽しそうに発言している様子が印象的でした。

楽しそうな表情のバックエンドメンバー

次回は、3.Ignoring the equals() and hashcode() methods while performing object comparison、4.Circular dependencies に取り組むことを決めて、終了となりました！次に繋がるいいスタートが切れたように感じました。

バックエンドエンジニア募集♪

チームスピリットでは、バックエンドエンジニアを募集しています。最先端のPaaSプラットフォーム（Salesforce Lightning Platform）で、TeamSpiritのエンジンとなるロジックを生み出す仕事です。今回ご紹介した、バックエンドランチに飛び入り参加いただくことも可能ですので、少しでも興味を持っていただいた方、ご連絡くださいね。（直接メッセージでも、下記の応募フォームからでも構いません）

終わりに

最後になりましたが、この投稿は チームスピリット Advent Calendar 2018 - Adventar 第5日目の投稿になります。

Salesforce Basecamp Singapore Report

みなさん, こんにちは! This is ライアン (id:ryancsf) from TeamSpirit Singapore. Today, I would like to talk about my first Salesforce Basecamp experience in Singapore.

Today, on 28th of November 2018, salesforce basecamp was held in Marina Bay Sands, Singapore. Together with Koizumi-san, Nino-san, Go-san, Prashant, Ace and Jerry, all of us went to the basecamp. It was our first conference together as the Singapore team.

Below is the agenda of the event:

First Impression

The venue of the event, Marina Bay Sands exhibition center is huge. We spent around 5 minutes walking around the different expo theatre until finding the right one. Upon entering the venue, we were greeted with some nice refreshments of coffee and English tea. There's also some fresh fruit on display.

Prashant and Nino-san were very happy when they discovered the drinks

Fresh fruits provided as refreshments!

Salesforce logo everywhere!

Keynote

Around 1.00 pm, the keynote started. All of us went to one of the bigger halls and the atmosphere changes. Lights were dimmed down and there was 2 big screens in front of us. It feels like a Mini-Dreamforce event to me.

Mini DreamForce atmosphere

We took a group photo before the event started

The first slide they present is Thank You slides! So sweet :D

This slide talks about the fourth revolution that we are in now.

Salesforce's core values

The entire keynote was very inspiring as they showcase the latest innovation of Salesforce which is the Einstein Voice and there was a live demo on how they integrated different customer data using MuleSoft's anypoint platform, and then using Einstein AI to suggest the best recommendation after analyzing all the data.

After the keynote

After the keynote, we went back to the smaller room where we can each go to different tracks. There were many interesting tracks on that day. Each of us have different interests, so we separated and went to different tracks. If you are interested, you can see the list of all tracks here :

Salesforce Basecamp Singapore - 28 November 2018 - Agenda - Salesforce

As we are walking around... we saw some familiar characters!!! They are...

Astro & Codey, Salesforce's mascots!

So, we did the only thing that everyone else wants to do, which is...

Take a picture with them!

Individual Track: Introduction to MuleSoft

MuleSoft is a company that was recently acquired by Salesforce. It is a company that specialise in integration of data. I joined a talk about MuleSoft's Anypoint platform.

The speaker talks about their company's main feature : API-fying everything

With API, you can avoid mass duplication.

Second talk: Transition to Lighting

Afterwards, around 3.00 pm, I joined another talk by Mr Dennis Chau, Senior Customer Adoption Analyst. In this talk, we learned about why Salesforce is pushing Lightning and how we can help customer to move to Lightning.

According to Mr Dennis, the main reason Salesforce is moving to Lightning is personalisation. Other reasons includes:

1. Modern, intuitive interface
2. Better performance.
3. More customisability.

The title slide

Free salesforce notebook!

Conclusion

We went back to the office after the last talk. Overall, it was a good experience as we learned a lot more about how Salesforce works in Asia. We were also exposed to their vision and mission as well as their future products (Einstein Vision, Einstein Analytics, Anypoint integration).

I look forward to the next conference so we can get more knowledge and bring it back to TeamSpirit.

Lightning プロセスビルダーで通知を考える

今年も 技術系アドベントカレンダーの季節がやってまいりました。皆さま元気にお過ごしでしょうか？

日本では、もうすぐ1年に1度の Salesforce World Tour Tokyo 2018 が 12月5日に迫ってきています。 イベントを楽しみにして待っている方、登壇のため資料などの準備に追われている方などさまざまでしょう。

クリスマスまで25日ですので、今日から毎日投稿されるアドベントカレンダーの記事を読んで楽しみながら過ごしてもらえればと思います。

はじめに

Salesforceでの通知といえば、これまではワークフロールールを利用して、メールアラートを送信するが主流だったのではないかと思い込んでいます。

もう一つの手段としてはChatter での通知なども考えられますが、Chatter 投稿を自動化できるようになったのも比較的最近であるため、まだ使い始められていない方も多いのではないでしょうか？

この Chatter 投稿を自動化するためには、Lightning プロセスビルダーを利用します。Chatter 投稿以外にもいろいろとできるので、Lightning プロセスビルダーを活用すると、どういった通知が自動化できるか考えてみたいと思います。

考えてみた

プロセスビルダーで自動化できるものは数限りなくありますが、ここでは「通知」に絞って考えることとします。

プロセスビルダーで「通知」に関連してくる機能として、メールアラート、Chatter、レコード追加・更新の3つに分けて取り上げていきたいと思います。 その他にも何かあれば教えてもらえると嬉しいです。

メールアラート

まずは、メールアラート。これまではワークフロールールを利用して、メールアラートを送信してきました。

ご存知のかたも多いと思いますが、プロセスビルダーからもメールアラートを起動できるようになっています。設定できる項目についてもワークフロールールも同じですね（詳しく差分を取っていないので、差分があれば教えてください）。

図：メールアラート

Chatter

次に、Chatter投稿。

「Chatter」に投稿する場合は、ユーザー、Chatter グループ、レコードを選択できます。Chatterでの通知となるため Salesforce モバイルアプリでも通知して受信することができます。通知としては、自分のタイムラインに投稿が表示されてしまうところは良くない点なので、Chatter メッセージ（自分宛てだけに）で送信できるようになるとよいですね。

ところで、Chatter メッセージは Lightning Experience で対応される気配が…（げふんげふん）。

図：Chatterに投稿

レコードを作成

最後に、レコード関係。こちらはいろいろな応用が考えられます。

プロセスビルダーでは、アクションとしてレコードを作成できるようになっています。レコードを作成・更新できると Sales Cloud や Service Cloud などの機能をかなり自動化できるので、かなり強力な機能となります。

それに加えて、Salesforce ではレコードを作成・更新で起動する Apex トリガーを仕込むことで外部サービスとの連携を含めてさまざまなことができるようになります。

ここでは、「通知」という観点で関連しそうなものを挙げていきます。

ToDo

ToDoは、いわゆるタスク管理ツールのタスクにあたります。ToDoはタスクとしての意味合いがあるので通知より強制力があり、完了させる（通知を消す）ためには本人が明示的に操作する必要があります。

図：レコードを作成（ToDo）

行動

「行動」は開始日時、終了日時を登録できるので、予定として登録したい場合に非常に有効になります。また、クイックアクションでも登録できますが、いろいろな方法で登録できるのは少し謎なところがあり、どの手段が一番よいのか気になるところです。

行動を「レコードを作成」で作成する

図：レコードを作成（行動）

行動を「クイックアクション」で作成する

図：クイックアクション（行動）

Slack

少し前からメールに集約していた通知を、Slack などのチャットツールに集約していく流れがあります。 これは日常的なやりとりに使っているツールがメールからチャットツールに変遷していることに関連しています。

ここでは、Salesforce から Slack に通知する方法について2015年の Advent Calendar にやり方を書いた記事がありますので紹介しておきます。

Salesforce App Cloud Advent Calendar 2015 (23日目) - Salesforce→Slack通知をオープンソースで公開しました

TeamSpirit

最後に、私が携わっているプロダクト「TeamSpirit」と絡めて小技をご紹介します。

「TeamSpirit」は勤怠管理、経費精算、工数管理、カレンダーを一体にした働き方改革プラットフォームです。もう少し知りたい、という方はこちら。

TeamSpirit の勤務表を開くと、お知らせが表示されることがあります。このお知らせ機能はカスタムオブジェクトでデータを管理しています。そのため、今回のプロセスビルダーでレコードを作成するように設定してあげることで、勤務表に任意のお知らせを表示できるようになります。

ここからは、少し具体的に設定方法について解説していきたいと思います。

今回設定するお知らせは、「36協定残業時間（法定休日労働を含む）」が40時間を越えたときに通知する、というものです。

新規プロセス

まず、プロセスビルダーを起動して、新規のプロセスを作成します。下記のように新規プロセスを設定します。

図：新規プロセス

• プロセス名：残業通知（任意）
• API 参照名：OvertimeNotification（任意）
• 説明：（任意）
• プロセスを回位するタイミング：レコードが変更されたとき

オブジェクトを選択

次に、プロセスビルダーの画面で対象となるオブジェクトを選択します。

下記のようにオブジェクトを選択してプロセスを開始するタイミングを指定します。

図：オブジェクトを選択

• オブジェクト：勤怠月次
• プロセスを開始：レコードを作成または編集したとき

条件を追加

そして、下記のように条件を追加します。

図：条件を追加

• 条件名：36協定対象残業時間(法定休日労働を含む)>40時間
• アクションの実行条件：条件を満たしている

条件を設定

項目	演算子	種別	値
teamspirit__AtkEmpMonth__c > 36協定残業時間(法定休日労働を含む)	＞	番号	2,400

※ 値は分単位で設定します（例：40時間×60分のため、2,400分を設定しています）

詳細

• レコードに指定の変更が行われた場合にのみアクションを実行しますか? ：オン

ルール適用時のアクション

下記のように、上記で設定した条件を満たす場合のルール適用時のアクションを設定します。

図：アクションを選択して定義

• アクション種別：レコードを作成
• アクション名：勤怠お知らせを作成（適宜、わかりやすい名前をつけてください）
• レコードタイプ：勤怠お知らせ

項目値を設定

項目	種別	値
勤怠お知らせ名	文字列	teamspirit__AtkEmpMonth__c > 社員ID > 社員名
メッセージ	文字列	36協定残業時間(法定休日労働を含む)が40時間を越えました
社員 ID	項目の参照	teamspirit__AtkEmpMonth__c > 社員ID > カスタムオブジェクトID
所有者 ID	項目の参照	teamspirit__AtkEmpMonth__c > 社員ID > 所有者ID

任意の残業時間でお知らせを表示するためのプロセス

以上で主だった設定は終わりになります。下記のようなプロセスが作成できていると思います。

図：プロセス - 残業通知

プロセス有効化

最後に、忘れずプロセスを有効化しましょう。

テスト

実際に、今回設定した条件を満たすように勤務表から出退社時刻を入力していってみましょう。

条件を満たすところまで入力した後に画面を再表示すると、下記のようにお知らせが表示されました（パチパチパチ）。

図：お知らせが勤務表に表示される

このように設定することで、かなり柔軟な条件でお知らせを表示できますので、ご参考にしていただければ幸いです。

まとめ

ここで紹介した通知の方法についてメリット、デメリットを独自判断でまとめておきます。書いてみて参考にならなさそうですが、ご参考まで。

通知方法	メリット	デメリット
メールアラート	これまでと同様、メールによる通知でわかりやすい	通知を受け取る手段としてメールのみになる
Chatter投稿	Salesforce モバイルアプリで通知として受信できる	タイムラインに通知のための投稿が表示されてしまう
ToDo	強制力のあるやり方で、本人が明示的に完了させることができる	余計なToDoが作成されてしまう
行動	日時を指定して知らせることができる	余計な行動が作成されてしまう
Slack	Slackに通知を集約する運用ができる	設定の難易度が高い
TeamSpirit	TeamSpiritのお知らせをある程度自由に拡張できる	TeamSpiritを利用していないと使えない

おわりに

今回は、Lightning プロセスビルダーを通じて、Salesforce における通知について考えてみました。皆さまはどういった通知を作成していますでしょうか？

通知を一つとっても実際の運用を考慮するとなかなか奥が深いところがあり、いろんな方の知見を伺いたいと思いました。

最後になりましたが、この投稿は チームスピリット Advent Calendar 2018 - Adventar と Salesforce Platform Advent Calendar 2018 - Qiita 第1日目の投稿になります。