ChatGPTというキーワードを聞いたことがない人はもう多くは無いでしょう。かく言う弊社では、2022年11月に初めてChatGPTアプリをリリースし、延べ利用人数は5000人を超えて成長中です。 ChatGPTをSlack上で使える無料アプリ「Party on Slack」がAnthropic及びAmazon Bedrockに対応し、Claude及びStable Diffusionが利用可能に 生成AIは業務に利用できるのか では、もはや当たり前となりつつある生成AIですが、果たしてこれを業務に利用できるのかというのが、このページの読者の気になる所でしょう。 一つの返答としては身も蓋もないのですが「使えると言えば使えるし、使えないと言えば使えない」と表現するしかないのが現状です。 なぜかと言うと、生成AIは何を元に生成するのかというと「言葉」です。(生成AI文脈でいうとこの言葉＝プロンプト(指示語)と呼ばれています。) このプロンプトを的確に表現できるかどうかで、あなたが得られる情報に雲泥の差がつく、それが生成AIだと言えます。うまく使える人と使えない人の間には、プロンプトの生成能力に雲泥の差があるのだと言えます。 これが先程書いた「使えると言えば使えるし、使えないと言えば使えない」の中身です。 さて、このプロンプトの生成能力が業務にどのような影響を及ぼすのかを明らかにするために、いくつかの具体的な使用例を考えてみましょう。 カスタマーサポートの効率化 例えば、ChatGPTをSlackに統合することで、カスタマーサポートチームがよく受ける一般的な質問に対する自動応答が可能です。Slack内もしくは、過去のサポート内容のDBをChatGPTに読み込ませることによって、ユーザーに返答するためのテキストを自動生成することが可能になります。 これにより、エージェントはより高度な問題に集中することができ、全体の効率が向上すると言えるでしょう。 ドキュメントの生成と整理 ドキュメントや報告書を作成する際にも、生成AIを活用することで、時間を大幅に節約することができます。特に、定型的な文書やテンプレートを生成する作業は、AIが得意とするところです。前述したParty on Slackでは、音声ファイルをWhisper APIを使うことで文字起こしすることができます。人間同士の会話をただ文字起こしした文章は読むのに適しているとは必ずしも言えないのですが、これを生成AIで要約することによって、長時間かけて議論した流れを一瞬で文章化することができるようになります。 コードレビューとバグトラッキング 開発者は、ChatGPTに特定のプロンプトを与えることで、コードの品質をチェックしたり、バグを特定するのに役立つフィードバックを得ることができます。特に長いプログラムに関しては、入出力トークン数が10万であるAnthropic の Claude APIを使うことで解析することが可能になっています。リバネスでは、プログラマではないスタッフが、Google App Scriptを書いて作業を効率化する試みをするなど、プログラミングの民主化と言えます。 プログラミング領域についてはSlack上でやらずとも、エディタが生成AIを取り込んでいることもあるため、その作業効率は格段に向上していると言えます。 いずれのケースも、プロンプトの設定と運用が鍵となります。うまくプロンプトを設定できれば、業務の質と効率が飛躍的に向上するでしょう。 ただし、生成AIはあくまでツールであり、人間の裁量や専門知識を完全に置き換えるものではありません。したがって、適切なバランスと監視が必要です。 今後、ChatGPTや他の生成AIがどれだけ進化しても、その使い方一つで成果が大きく変わるという事実は変わらないでしょう。この技術を最大限に活用するためには、まずはその可能性と制限をしっかりと理解することが重要です。 Slack上で生成AIを使い始めることの意味 生成AI自体に触れたことのある人の割合はそこまで高くありません。PwCが発表した資料によると54%の利用に留まっているとされています。 この状況において、生成AIを業務にどう活用するかという問いが重要になります。 生成AI活用のハードルとその克服 一般に、生成AIの活用レベルは人それぞれで、プロンプトの書き方一つで大きな違いが出ます。多くの人が「自分はプロンプトを上手く書けないから生成AIは使えない」と早計に判断してしまいますが、それは時期尚早です。 知見の共有が鍵 どんな組織にも新技術に興味を持つ人はいるでしょう。そういった人々の知見や成功事例をSlack上で共有することが、生成AIの業務活用を加速させる鍵だと私たちは考えています。 Slackの利点 Slack上で生成AI、特にChatGPTを使用する最大の利点は、その使い勝手です。Slack自体がチャットベースのUIであり、ChatGPTも自然に統合されているため、使用に違和感はありません。さらに、スレッド内での過去の会話が記憶され、ChatGPTはそれに応じた返答ができます。 ツールの一元化 また、多くの人は複数のツールを使うことにストレスを感じるため、ChatGPTをSlack内で使用できるというのは重要なファクターです。これによって、生成AIが日常業務に自然と組み込まれ、活用されやすくなります。 以上がSlack上で利用する事をおすすめする理由です。 加えて別の味方から生成AI活用について考えてみましょう。 ROI（投資対効果）について 現在日本語で使える且つ簡単にサインアップして利用をスタートできる生成AIとしては以下のサービスが考えられます テキスト生成については OpenAIもしくはAzure OpenAIを使ったgpt-3.5もしくはGPT4 AnthropicもしくはAmazon Bedrockを使ったClaude 音声認識については OpenAIのWhisper [...]

リバネスでは2014年より本格的なデジタル化を推進してきました。 それまで社内には統合されたデータベースというものは存在せず、エクセルが散在し、情報の集約に時間を要していました。マネージャーは本来やるべきことより情報をまとめることに時間を割くようになってしまったことで、組織のボトルネックが顕在化しつつあったからです。 スプレッドシートは強力なツールで、オンラインで共同編集が出来ることもあって長い間重宝されてきましたが、情報量が増えると処理に時間がかかるようになったり、一人の人が起こしたエラーで全体が使い物にならなくなったりと、やはり時間が無駄にかかるようになってきました。組織が大きくなる事で現れたボトルネックはすべて自社のデジタル化環境によるもので、これを刷新しないことには次のステップへ行くことは出来ないと考えた訳です。 リバネスのDXで重視したのはなにか 情報を扱っていて思う一つの大事な事が何かというと、情報をまとめるというのには時間がかかるということです。この時間を削減する必要がありました。そこでリバネスでは、データの基幹をSalesforceに移すことを決め、あらゆる情報をSalesforce上に統合していくことになります。 最初は取引先や名刺交換で獲られた人の情報、及びそこに紐づく商談の情報のみしかなかったSalesforceに、スタッフの査定情報、勤怠管理、マーケティングオートメーションツールから獲られるWebサイトのアクセス情報、会員サイトの会員が登録した情報などを統合していきました。 そうすることで何が起こるかと言うと、Salesforce上で検索すればあらゆる情報にアクセスできるという状態を作ることができるのです。 もちろんSalesforceのみである必要は無いのですが、1つのプラットフォーム上にあらゆるデータが統合されているという状態は非常に便利です。検索をすれば情報がヒットする訳ですから。 リバネスのDXで達成したこと 最初は商談管理の為に導入したSalesforceですから、当然商談管理については大きなインパクトがありました。それまでは数字を合わせるという作業に時間が取られていたのが、そこにかける時間が0になることで戦略を考える時間が持てるように変化が起こりました。それまでどんぶり勘定と言わざるを得なかった事業計画も、実績を元に算出した数字を達成できるようになっています。2014年当時に危惧していたボトルネックは解消され、売上は当時の3倍を超えて成長しています。 情報を見ることにストレスが無くなるというのは非常にパワーを与えてくれるといえます。 能動的なアクションを必要としない環境へ Salesforceを活用する利点は、Salesforce自体に計算処理能力を持っているという点が挙げられます。つまり、集まった情報をSalesforceの計算資源を使って加工し、出力することが出来ます。情報は定期的に実行されるバッチ処理によってプッシュ配信することも出来ますし、Salesforce上に作ったカスタムページに必要な情報を適宜配置して確認することも出来ます。 自社のみがもつサーチエンジン リバネスの例で言えば、私達のSalesforce上には研究者から寄せられた情報が多数登録されており、これは年々情報量を増しています。 Salesforce上につくった検索エンジンを使って検索することで、特定のキーワードにひっかかる研究者を簡単に抽出することができるという状態が作られています。 これらの情報によって抽出されたリストを使ってメールを配信するというようなアクションも、ほんの数分で実現することができるのです。 DXのゴールはなにか Salesforceを使っていると、高いのではないか？という話になるということはよく聞きます。高い、つまりコストパフォーマンスが悪いのではないかということなのですが、当然使い方によってはコスパが悪いという状態になるでしょう。デジタル化に使うプラットフォームがどこまで使えるのかを把握し、100%以上使い倒す事ができればコストパフォーマンスが気になるということはなくなるはずです。 そのためには、DXの全体像を大きく捉え、将来的にどこまで行きたいのかを想像する必要があります。そこに向けてデジタル化を進めていくのです。 もちろんDXの始めたての頃はコストパフォーマンスが良いとは言えないかもしれません。DXは一朝一夕でなるものではなく、マラソンに近い活動だと言えます。自社のデジタルアセットが統合されることによってどのように変化が起こるのかを共有し、そこに向けて走り続ける事でいつの間にかDXが達成されているのではないかと感じています。 もちろん我々リバネスのDXも道半ばです。これからもっと強力なツールに育て上げることで事業推進に貢献できるようになるでしょう。 リバネスでは2014年より本格的なデジタル化を推進してきました。 それまで社内には統合されたデータベースというものは存在せず、エクセルが散在し、情報の集約に時間を要していました。マネージャーは本来やるべきことより情報をまとめることに時間を割くようになってしまったことで、組織のボトルネックが顕在化しつつあったからです。 スプレッドシートは強力なツールで、オンラインで共同編集が出来ることもあって長い間重宝されてきましたが、情報量が増えると処理に時間がかかるようになったり、一人の人が起こしたエラーで全体が使い物にならなくなったりと、やはり時間が無駄にかかるようになってきました。組織が大きくなる事で現れたボトルネックはすべて自社のデジタル化環境によるもので、これを刷新しないことには次のステップへ行くことは出来ないと考えた訳です。 リバネスのDXで重視したのはなにか 情報を扱っていて思う一つの大事な事が何かというと、情報をまとめるというのには時間がかかるということです。この時間を削減する必要がありました。そこでリバネスでは、データの基幹をSalesforceに移すことを決め、あらゆる情報をSalesforce上に統合していくことになります。 最初は取引先や名刺交換で獲られた人の情報、及びそこに紐づく商談の情報のみしかなかったSalesforceに、スタッフの査定情報、勤怠管理、マーケティングオートメーションツールから獲られるWebサイトのアクセス情報、会員サイトの会員が登録した情報などを統合していきました。 そうすることで何が起こるかと言うと、Salesforce上で検索すればあらゆる情報にアクセスできるという状態を作ることができるのです。 もちろんSalesforceのみである必要は無いのですが、1つのプラットフォーム上にあらゆるデータが統合されているという状態は非常に便利です。検索をすれば情報がヒットする訳ですから。 リバネスのDXで達成したこと 最初は商談管理の為に導入したSalesforceですから、当然商談管理については大きなインパクトがありました。それまでは数字を合わせるという作業に時間が取られていたのが、そこにかける時間が0になることで戦略を考える時間が持てるように変化が起こりました。それまでどんぶり勘定と言わざるを得なかった事業計画も、実績を元に算出した数字を達成できるようになっています。2014年当時に危惧していたボトルネックは解消され、売上は当時の3倍を超えて成長しています。 情報を見ることにストレスが無くなるというのは非常にパワーを与えてくれるといえます。 能動的なアクションを必要としない環境へ Salesforceを活用する利点は、Salesforce自体に計算処理能力を持っているという点が挙げられます。つまり、集まった情報をSalesforceの計算資源を使って加工し、出力することが出来ます。情報は定期的に実行されるバッチ処理によってプッシュ配信することも出来ますし、Salesforce上に作ったカスタムページに必要な情報を適宜配置して確認することも出来ます。 自社のみがもつサーチエンジン リバネスの例で言えば、私達のSalesforce上には研究者から寄せられた情報が多数登録されており、これは年々情報量を増しています。 Salesforce上につくった検索エンジンを使って検索することで、特定のキーワードにひっかかる研究者を簡単に抽出することができるという状態が作られています。 これらの情報によって抽出されたリストを使ってメールを配信するというようなアクションも、ほんの数分で実現することができるのです。 DXのゴールはなにか Salesforceを使っていると、高いのではないか？という話になるということはよく聞きます。高い、つまりコストパフォーマンスが悪いのではないかということなのですが、当然使い方によってはコスパが悪いという状態になるでしょう。デジタル化に使うプラットフォームがどこまで使えるのかを把握し、100%以上使い倒す事ができればコストパフォーマンスが気になるということはなくなるはずです。 そのためには、DXの全体像を大きく捉え、将来的にどこまで行きたいのかを想像する必要があります。そこに向けてデジタル化を進めていくのです。 もちろんDXの始めたての頃はコストパフォーマンスが良いとは言えないかもしれません。DXは一朝一夕でなるものではなく、マラソンに近い活動だと言えます。自社のデジタルアセットが統合されることによってどのように変化が起こるのかを共有し、そこに向けて走り続ける事でいつの間にかDXが達成されているのではないかと感じています。 もちろん我々リバネスのDXも道半ばです。これからもっと強力なツールに育て上げることで事業推進に貢献できるようになるでしょう。 事例に戻る [...]

TableauとSlackを組み合わせることで、意思決定を加速し、アクションにつなげるコミュニケーションを生み出すことが出来るという事例です。 リバネスでは、あらゆるデータをSalesforce上に格納しています。Salesforceに格納されたデータをTableauを使って可視化するという使い方をしています。 データドリブン組織(経営)とはなにか その名の通り、データを元にした意思決定をする組織です。と、一口に言っても、何をデータとして格納していくのかは組織によっても変わってきますし、効果的なデータが取れているかどうかを判断し、日々改善していくといった運用の工夫も必要になってきます。 Salesforceを使っていると、日々の最新情報や、経時変化(事例：Salesforceはスナップショットを使いこなしましょう 参照)の情報を簡単に見ることが出来ます。Salesforceからも具体的にダッシュボード例が紹介されていますので、興味があればこちらをご覧ください。「営業の見える化」 に役立つダッシュボード６選 これらのダッシュボードを整備し、定期的に確認をしながら、その後のアクションについての意思決定を行う。そのあたりがデータドリブン経営のとっつきやすい入り口になります。 データドリブンの成れの果て 私自身(吉田丈治)もそうですが、ダッシュボードを作り始めると、データを色々な角度から分析して見たくなります。ダッシュボードには様々なデータが紐付けられ、ボタンクリックでフィルターがかかりグラフが動的に変化する。様々な分析をすることが出来るゴージャスなダッシュボードがいつしか出来上がる、そんな経験がある人がいるのではないでしょうか。 凝ったダッシュボードを作ることで生まれるのは、情報の齟齬です。人によって何を見て何を得るのかが一意にならなくなってしまいます。情報が複雑化すればするほど色々な解釈が出来るようになっていき、一つの方向を向かせるためのダッシュボードではなくなっていきます。 ダッシュボードを分解せよ このような状態になってきた場合におすすめしているのは、ダッシュボードの分解です。 ある特定のタイミングで必要な情報というのはそんなに多くないと個人的には思っています。 例えば、マネージャーが商談の状況を確認する場合を想像して下さい。今必要なのは、部下に檄を飛ばす必要があるかどうかの判断材料です。 ダッシュボードを開くと、あらゆる情報がきれいにまとまった豪華なダッシュボードが出てきますが、必要な情報はそのダッシュボードの中のほんの一部でしかありません。オーバースペックなダッシュボードは開くのに時間がかかり、日々のオペレーションで少しずつストレスが溜まっていきます。 こんな風になってはいないでしょうか？データドリブンがうまく走ってくると、段々と特定のタイミングで必要な情報がなにかが分かってきます。 リバネスではこうなったタイミングで情報を分解していきました。特定の部門のマネージャーが自分の部門の売上推移を知りたいのであれば、その部分だけ切り出した情報を提供することができれば、最小単位で最大効率の情報伝達が可能になります。 最小単位で最大効率の情報伝達 データドリブンの究極系は、一度最大化したダッシュボードを局所最適に分解する事だと言いました。 ここからは、情報伝達からアクションに移す流れを最短距離に縮めていく手法について書きたいと思います。 リバネスではコミュニケーションの中心はSlackを使っています。Slackを使って組織を、人を動かすのが今回のゴールです。 Slackの課題は何でしょうか。それは情報量が多すぎることです。必要な情報から些細な情報まで多くの情報が飛び交います。その為、情報の伝達効率という意味では薄くなりがちなのですが、そこで活躍するのがTableauです。 Tableauでビジュアライズしたダッシュボードはこのように画像として配信が出来ます。 画像をSlackに配信することで何が良いかというと、一瞬で必要な情報が頭に入ることだといえます。忙しく、情報があふれる毎日の中において、情報の取得コストを如何に下げていくのかを考えることで、より効果的な組織運営が出来るようになると言っても過言ではありません。 画像からアクションへ これはあくまでも画像です。Tableauの画面のようにクリックしてフィルタが効くというような使い方は出来ません。しかし、だからこそ一意に情報を伝えることが可能になります。 一意な情報が伝達すると何が起きるかというと、アクションが始まります。Slackに流れた情報を元に意思決定が即座になされ、関係者に指示が飛ぶように変わっていきます。打ち合わせの時間をあえて取る必要もなく、何をすべきかが決定されて実行されるようになります。 これこそがアクションドリブン経営だと私が個人的に考えています。 アクションを忘れないために とは言え、Slackはメンションした会話がそのまま忘れ去られれてしまうことが少なくありません。 これを解決するためのアプリケーションを作りました。それはまた別の実績でお話したいと思います。

Salesforceでレポートやダッシュボードを作成すると最新情報による情報を可視化することが出来ることはご存知だと思います。 一方で、事業をやっていると、最新情報のみではなく、これまでの経時変化を見てみたいと思う瞬間が少なからず発生するはずです。Salesforceは何も設定していないと経時変化のような情報を取ることが出来ません。そこで利用するのが「レポート作成スナップショット」です。 この機能を利用することでSalesforce上で、経時変化をデータとして保存することができます。 以下は日次データを保存した結果をレポートにしたものですが、このような形で可視化できるようになります。 データの取得間隔は最短で1日です。 なぜスナップショットという機能が必要なのか 例えば、年間の積算売上であったり、年間のサービス利用者数でも良いと思います。 Salesforceは最新の情報しか見ることが出来ません。去年のデータを取得したいと思っても、最終的な状態を知ることしか出来ません。 データの分析を考える上でそれだけでは物足りないことがままあります。 年間を通して売上がどのように変化してきたのか。利用者数が増加・減少するタイミングや季節はあるのか。こういった情報を後で手に入れようとしても難しいのがSalesforceです。(Salesforceというより、どんなデータベースでも同様です) 利用事例 最も利用価値が高いのは売上推移の情報です。リバネスでは毎日スナップショットを取っており、過去数年間のデータが残っています。いつ頃、どの程度の売上が発生していたのか、季節ごとの傾向がどうなっているかといった情報を取得することが出来るようになっています。 事業計画に対する進捗度合いがすぐに分かるため、その後のアクションに対する意思決定スピードが向上します。 売上推移のように長期的なもの以外にも、あるイベントの参加人数募集がかかっている場合に、申込み人数の推移を可視化することで、短期的なゴールに向けたアクションが可能になったり、問い合わせ件数(ケース件数)の処理数の推移を測っておくことで、対応スタッフ数の適切な人数を割り出すことが可能になります。 それでは実際にどのように作っていくのかを解説します。 レポート作成スナップショットの作り方 Trailheadからなにかちょうどよいものを引っ張ってこようと思っていたのですが意外となかったので書いておきます。 まずはレポートを作成しましょう スナップショットはレポートを元に作られます。 レポートは、集計したいオブジェクトを対象にして作ります。 商談の売上金額の推移を取得したい場合は、商談のレポートを作って下さい。リバネスの場合はこのような形式になっています。 集計レポートですので、何かしらの項目でグループ化する必要があります。商談は会計年度毎に集計することが多いと思いますので、会計年度でグループ化しました(左上)。表示列には、売上系の項目を入れています。 【商談単体】金額がいわゆる金額(Amount)項目です。事業部別売上(集計用)は、数式によって事業部毎の売上金額が入るようになっていて、全社的な売上に加えて事業部別の売上推移もスナップショットで取得するようにしています。 レポートを作ったら正しく集計されているか数字を見て確認しましょう。問題がなさそうであれば、このレポートをもとにスナップショットをつくります。 スナップショットのイメージは、今レポートで表示されている数字がそのまま記録に残ると思ってください。売上推移であれば当然数字は日々動いていきます。その瞬間の数字が記録として残るのがスナップショットなのです。 レポート作成スナップショットを作る レポートを作ったら、次はスナップショットを作ります。 設定画面＞機能設定＞分析＞レポート＆ダッシュボード＞レポート作成スナップショット を開いて下さい。 スナップショット名及び一意の名前は任意です。 実行ユーザは専用のユーザが用意できる場合は専用ユーザ。出来ない場合もできるだけ退職しないアカウントで作りましょう。オブジェクトへのアクセス権限も必要です。 ソースレポートには先程作ったレポートを設定します。 対象オブジェクトはスナップショットのデータを格納するためのオブジェクトです。 存在していませんのでオブジェクトを作成して下さい。 今回は商談の金額を格納する為のオブジェクトですので、商談スナップショットオブジェクトを作成し、金額という項目を一つ作っておけば大丈夫です。上述したように事業部毎の金額も格納したいという場合は、それを入れるためのカスタム項目を追加しましょう。こんなイメージになるはずです。 次に、項目の割当を行います。 今回は特にグループごとの小計を使う予定はありませんので総集計を選びます。 もし会計年度以外の要素でグルーピングした場合は、それらの小計を入れることも可能になります。 下の方が割当項目です。スナップショットの各項目を左側で選択し、右側が格納先オブジェクトのカスタム項目になっていてそこに割り当てていきます。 注意点としては、数値項目はテキスト項目には代入出来ないといった型をあわせる必要がありますので、もし割り当てたい項目のところにほしい項目が表示されないという場合は項目の型をチェックしてみてください。 最後に、実行間隔を決めましょう。以下の条件では、毎朝7時に実行することになっています。 以上が設定方法です。 スナップショットのデータを活用する ここまででスナップショットの設定は出来たと思います。実際にデータが格納され始めたら、それを使って可視化をしましょう。 Salesforceのレポートを使ってグラフ化する所から初めて、Tableauを使ってもっとグラフィカルなグラフを作ることも可能です。 一番大事なのは、データを使ってアクションに結びつけることです。可視化された情報を使って人を動かすことができれば組織のスピードに圧倒的な向上が見込めます。 お気軽にご質問ください！ [...]

国の委託事業等では、活動日報を提出する必要がある場合があります。年間に一つのプロジェクトだけが回っている状態であればさほど苦労はないのですが、複数のプロジェクトを兼任するようになってくると、人力での日報管理には限界が出てきます。 一番まずいのがダブルブッキングです。一人の人間が同じ時刻に複数のプロジェクトの仕事を行い、複数のプロジェクトの人件費を計上するということはあってはならず、整合性の確認の為に何度も精査が必要になるというのが常態化していました。目視でデータを見比べ、その人の時間が適切に割り振られている事を証明するというのはミスが出やすく且つ確認作業も重労働になります。こういった時間を0にするための取り組みを紹介します。 Googleカレンダーの情報をマスタとして利用する カレンダー情報は誰もが利活用しているのですが、これをマスタデータとして利用しています。どんな人でもスケジュールの登録は行います。終わったあとに実際にかかった時間を調整してくれれば良いのです。 Googleカレンダーの情報はカレンダーAPIを利用して取得することが出来ます。今回作ったプログラムでは、取得した情報を月ごとのテーブルに変換して表示しています。 チェック作業は、プロジェクトメンバーの個人がGoogleカレンダーを見てダブルブッキングが無いかどうかを確認するだけです。それさえなければ不整合が起こることはありませんので、ダブルチェック要員などが軒並み不要となりました。 Googleカレンダーの情報から帳票を作る このように、Googleカレンダーの情報を元にして各種帳票を作ることが出来ます。データの修正はGoogleカレンダーのデータを修正するだけで即時反映されますので微調整の手間もかかりません。 事例に戻る

Slackを使っていると、チャンネルのタイムラインの中で様々な情報が行き交います。単純に目を通しておけば良い内容から、自分がアクションをしなくてはいけない情報まで、様々です。Slackを使いこなし、組織の規模が増えていけば行くほど、メッセージの数は増大し、自分に宛てられたメッセージについて検討する時間が増えていきます。 Slackで送られたタスクは忘れがち 一つや２つなら問題ないタスク管理も、数が増えてくることでだんだんと忘れてしまいます。Slackにはデフォルトで「メンション＆リアクション」や「スレッド」という機能が備わっているのですが、これはあくまでも情報の羅列であって情報の整理には向きません。数が少ないうちはすべて見ることができますが、量が増えてくるとこの画面を見るのがつらくなってきます。スレッドは新しい投稿が加わると上に上がってくるのですが、タスクを終えて一言加えると最新情報としてあがってきます。つまり、未対応のpostが埋もれていってしまうのです。これがなかなかつらい。特にモバイルを使っていると顕著に辛くなってしまいます。 だったら解決済みのスレッドはアーカイブできればいいじゃないか、そう思ったときに作ったのがTASUKARU-TaskAll-というアプリケーションです。 メンションを羅列し、用済みになったスレッドはアーカイブしていく。それだけで必要な情報だけが残っていきます。シンプル。 最もシンプルな使い方はこれです。これだけで自分に何が残っているのかが把握できるようになります。 ToDo管理もSlackでしたい メンションの管理だけでなく、ToDo管理もSlackでしたいと思ったことはありませんか。私はあります。詳しい話はこちらで書いたので読んでもらうと詳細がわかるのですが、Slackで誰かにToDoを渡したい、自分のToDoも管理したいと言うときに使える機能です。 先程の画像にToDoボタンがあると思うのですが、これを押すと、今現在抱えているタスクリストが表示されます。 タスクの割当は、メッセージ内に .todo もしくは to.do という文字列を含めるだけ。含めた状態でpostをすると、スレッドにアプリが介入し、ToDoを立ち上げてくれます。 ToDoには担当者・締切日・進捗率・アサインした人・タグを設定する事ができます。これらを使って管理していくという使い方です。 リバネスではタスクの受け渡しには基本的にこれを使うことにしています。口頭やslackでメンションしただけというものはタスクをお願いしたことにはならないという認識を全員がもつことが重要。(もちろん一瞬で終わるようなものについてはこの限りではないのですが) 以上のような形で、カスタムアプリを作ることでSlackの利用環境を向上させることができました。 スライドにある通り、インストールして使っていただけますので、是非ご活用ください。 リンクはこちら ・TASUKARUについて ・インストールはこちらから 事例に戻る Slackを使っていると、チャンネルのタイムラインの中で様々な情報が行き交います。単純に目を通しておけば良い内容から、自分がアクションをしなくてはいけない情報まで、様々です。Slackを使いこなし、組織の規模が増えていけば行くほど、メッセージの数は増大し、自分に宛てられたメッセージについて検討する時間が増えていきます。 Slackで送られたタスクは忘れがち 一つや２つなら問題ないタスク管理も、数が増えてくることでだんだんと忘れてしまいます。Slackにはデフォルトで「メンション＆リアクション」や「スレッド」という機能が備わっているのですが、これはあくまでも情報の羅列であって情報の整理には向きません。数が少ないうちはすべて見ることができますが、量が増えてくるとこの画面を見るのがつらくなってきます。スレッドは新しい投稿が加わると上に上がってくるのですが、タスクを終えて一言加えると最新情報としてあがってきます。つまり、未対応のpostが埋もれていってしまうのです。これがなかなかつらい。特にモバイルを使っていると顕著に辛くなってしまいます。 だったら解決済みのスレッドはアーカイブできればいいじゃないか、そう思ったときに作ったのがTASUKARU-TaskAll-というアプリケーションです。 メンションを羅列し、用済みになったスレッドはアーカイブしていく。それだけで必要な情報だけが残っていきます。シンプル。 最もシンプルな使い方はこれです。これだけで自分に何が残っているのかが把握できるようになります。 ToDo管理もSlackでしたい メンションの管理だけでなく、ToDo管理もSlackでしたいと思ったことはありませんか。私はあります。詳しい話はこちらで書いたので読んでもらうと詳細がわかるのですが、Slackで誰かにToDoを渡したい、自分のToDoも管理したいと言うときに使える機能です。 先程の画像にToDoボタンがあると思うのですが、これを押すと、今現在抱えているタスクリストが表示されます。 タスクの割当は、メッセージ内に .todo もしくは to.do という文字列を含めるだけ。含めた状態でpostをすると、スレッドにアプリが介入し、ToDoを立ち上げてくれます。 ToDoには担当者・締切日・進捗率・アサインした人・タグを設定する事ができます。これらを使って管理していくという使い方です。 リバネスではタスクの受け渡しには基本的にこれを使うことにしています。口頭やslackでメンションしただけというものはタスクをお願いしたことにはならないという認識を全員がもつことが重要。(もちろん一瞬で終わるようなものについてはこの限りではないのですが) 以上のような形で、カスタムアプリを作ることでSlackの利用環境を向上させることができました。 スライドにある通り、インストールして使っていただけますので、是非ご活用ください。 リンクはこちら ・TASUKARUについて ・インストールはこちらから 事例に戻る

提供中のアプリについてのご紹介です。 TimeLine for Slack。詳細はこちら 組織全体が見えづらくなってきた 在宅ワークや人数や拠点数の増加によって組織全体が見えづらくなってしまっていませんか。SlackはDigital HQであると宣言し、私たちもかねがね同意しているのですが、オフィス勤務時と決定的に違うことが一つだけあります。それが行き過ぎた最適化です。 オフィスに出勤していると顔が見える範囲のことはなんとなく察しが付きます。表情が見えたり、声が聞こえてくるというなんとなく漂っている情報がインプットされることで、人間はたくさんの情報を得ていると言えます。(一方でそれがノイズで集中できないというパターンもあります) リモートワークでは当然こういったセンサーを働かせることは出来ません。Slackを使いこなしていて、チャンネルが細分化していけば行くほど、リモートワークで他のチャンネルで何が起きているのかを目にする機会がなくなっていきます。 一つのチャンネルに全ての投稿を流すアプリ TimeLine for Slack そこで作ったのがこちらのアプリケーションです。アプリをインストールして設定をすると、全ての公開チャンネルに投稿されたメッセージが一つのチャンネルに流れます。パソコン版のSlackアプリを使っている場合は、分割ビューにタイムラインチャンネルを設定しておくことで、どこで誰がどんなことをしているのかが目に入るようになります。 オフィスに出勤していれば「小耳に挟む」ことが出来たような情報のやり取りが、Slack上にTimeLineチャンネルを作ることで実現することができるのではないか？という提案アプリになっています。 < 事例へ戻る

リバネスがSalesforceを導入したのは2013年末でした。これまで何度も色々なところで発表してきたことですが、2013年当時リバネスは業務量過多によって事業成長の頭打ちを迎えつつありました。その原因は貧弱なITインフラと適切なワークフローがなかったことに起因します。 2013年当時のリバネスの問題 今でも少なくない組織がやっていることだと思うのですが、営業管理をスプレッドシートを使って行っていました。事業は徐々に成長を始めたタイミングで、これまでのような管理のままだとそもそもデータが重すぎて入力するだけで数分かかってしまうという状態になっていました。スプレッドシートを好む人は少なくないと思うのですがそれはなぜでしょう。答えは簡単で自由度が高いからです。基本的に自由記述欄のみなので簡単に拡張が出来たりと便利な面はたしかにあるのですが、自由記述が故に情報の入力ルールが守られなかったり、誤って他人のデータを変更してしまったり、数値を書かないと数式がエラーになるのに気付かずに全角数字で入力したら集計用のシートがだめになってしまったり。スプレッドシートは脆弱なのです。 こういった問題を解決するための銀の弾丸として選ばれたのがSalesforce社が提供するSales Cloudでした。 ワークフローをSalesforce式に変えていく 一番効果があったのはこれです。それまでのリバネスの商談管理は本当にひどかったと今では思いますが、例えば上述のスプレッドシートですが情報が記述されるタイミングはいつだったと思いますか？答えは「契約が決まったタイミング」です。そのため、今仕掛中の案件が何件あるのかを把握することは出来ませんでした。誰がどこにどんな提案をしていたのかは、本人のみぞ知るところとなり、社内全体で共有するという文化がありませんでした。 Sales Cloudの導入で変わったのはワークフローです。誰かに何かを提案したら商談を立ち上げ、立ち上がった商談を元に現在提案中の金額が把握できるという状態にしました。こうすることによって売上の見通しがつくように変わっていったのです。それまでどんぶり勘定でしかなかった事業計画は、実態を伴った数字によって構成されるように徐々に変わっていきました。そのおかげで事業計画の達成率は100%前後で推移するようになり、計画的に成長していくことができる組織へと変わっていったのです。 副産物 課題はもう一点ありました。実はリバネスでは請求漏れが多発していたのです。せっかく完了した仕事があっても、請求書を送らなかったら入金はありません。そもそもの情報管理がスプレッドシートで信頼性が低いこともあり、請求漏れに気付くのは個人の記憶に頼る以外になく、非常に心もとなかったことを覚えています。これまでに実装してきたように、商談はまだ種状態のころから登録されており、その状態は常に管理され続けるようになりました。しかもそれまでのように、誰かが情報をまとめてレポーティングする必要はなく、ただ特定のURLをクリックすればいいだけで分かるように変わったのです。 請求漏れは、商談についた完了予定日(CloseDate)を使って確認がされるようになり、終わっていなければすぐに指摘できるように変わりました。おかげで請求漏れは二度と発生することはありませんでした。 (別件ですが、請求書を送ったあとに入金を確認するという流れの中にも多大な煩雑さがあり、最大2億円を超える未入金が蓄積したことがあるのですが、それについての解決方法については別途書きたいと思います) 間違いの始まり 日本企業の特性としてよく聞く話としてあげられるのが「自社用カスタムの過剰要求」です。自分の組織はこういうワークフローが組まれているからそれに合うようにカスタマイズして欲しいという話です。もちろん頑張って資金と工数を投入してカスタムすれば出来ないことはないのですが、それはなにか意味がある行為でしょうか。 業務用ツールを導入する場合、そのポテンシャルを100%以上引き出せるような使い方のほうがコストパフォーマンスが良くなるはずです。自社向けカスタマイズに固執していて業務効率向上がおざなりになってしまうと本末転倒。必要なのはツールの思想に自分の組織を寄せていくという柔軟性です。 ありたい理想像をそのツールを導入した上で描くことができるのであれば、ツール導入だけではなく組織変容を合わせて行っていく必要があります。 異文化導入によって組織を強化していく リバネスではこのような方法で組織を強化してきました。Salesforceが顕著ですが、Slackを導入した際には情報のオープン化を大々的に進めています。これまでのように限られた人のみが情報を得られる状態ではなく、誰もが欲しいタイミングで欲しい情報を得ることができる体制を作ったのです。検索すれば情報にありつくことができるということは、情報を残しておくことで誰かの役にたつことができるというインセンティブを与えることができるのです。 このように、ツールの導入とともに組織文化をアップデートし、ワークフローを最適化しながら成長できる組織にしていくお手伝いができればと考えているのが私達リバネスナレッジのチームです。

スケジュール管理、どのように行っていますか？ リバネスではもっぱらGoogleカレンダーを使っています。一方で、Salesforceにもスケジュールという機能が提供されており、活動オブジェクトに予定を入れておくと、その後のトラッキングが容易になるといったオプションがあり、これを使わないというのももったいないというのが現状です。 リバネスでは、Salesforceのスケジュール機能で作られた予定に報告機能を付与し、営業報告等の各種報告事項を記載してもらうようにしています。これの何が良いのかというと、イベントが有った時にわざわざ記録用のレコードを立ち上げる必要がないということです。誰が、いつ、という情報までは入っていますのであとはどこでどんなことをしたかを書いて保存すればよいだけです。 スケジュールの情報をSalesforceでも確認したい そういう事はままあるとおもいます。毎日Salesforceを開くのであればついでにスケジュールチェックもしておきたいということもあるでしょう。 かんたんにスケジュールをSalesforceに連携するのであれば、Einstein 活動キャプチャを使いましょう。GoogleもしくはOffice365と連携し、カレンダー情報を取得してくれます。(これは同製品の別機能ですが、メールのやり取りを商談の取引先責任者の役割に紐付いた人とマッチングさせることで、商談にメールのやり取り履歴を自動的に表示してくれます。これは他の方法では実現がかなり難しいのでおすすめ機能です。) これはSalesCloud Einsteinライセンスが必要ですが、非常にかんたんなソリューションで個人的にはおすすめです。以下の画像のように、Google Calendarとの同期したカレンダーを見ることができるようになります。 かんたんではあるのですが一点注意点があります。このカレンダーレコードはGoogle Calendarの情報をミラーリングしているだけでSales Cloud側にレコードがあるわけではありません。そのため、こちらを編集して情報を追加するといった上述したような使い方は出来ません。あくまでも予定の確認が便利になるよという機能になっています。 Googleカレンダーの予定をSalesforceのEventオブジェクトに同期する これにはアプリケーションの開発が必要になるので少しむずかしいかもしれませんがやる価値は十分にあります。 リバネスの場合はPHPもしくはPythonを用いたアプリケーションを書いて両者を同期するようにしています。 GoogleカレンダーからはGoogle Cloud Platformにアプリケーションを作成しアクセストークンを取得します。これを用いて予定を取得するという方法です。取得した情報はSales Cloud側に作った接続アプリケーションを通してEventオブジェクトに登録します。これを定期的にスクリプトを実行することで実現しています。(リバネスの場合は3分毎に同期) カレンダーの情報は更新されることが多いですので、更新されたレコードについてはその更新情報をSalesforce側のレコードにも伝えるようなスクリプトになってます。 こうすることによって、打ち合わせが終わったにも関わらず報告がなされていないレコードを見つけ出すようなスクリプトを走らせることが出来ます。これを使って報告を促すアラートをSlackに投げ、Slack側から情報を更新してもらうということができるのですが、それについては別の事例で書きたいと思います。 お気軽にご相談ください リバネスナレッジでは、無料相談をSlack上で受け付けています。 こちらのリンクより、Party on Slackというワークスペースにご参加ください。 https://lne.st/gptcom #質問_salesforce チャンネルにご連絡ください。お待ちしております。 Salesforce管理者あるあるを解消したい Salesforce Adminという役割は、Salesforceが進化するに従って拡張しています。それにも関わらず、一人で担当しているという組織も少なくないのではないでしょうか。ある程度運用できても、果たしてそれが効果的な施策になっているかどうか相談できる相手がいない。自分たちがやっている施策について壁打ち相手になってくれる人がいないという声を少なくない数耳にします。リバネスナレッジでは、これまで培ってきたノウハウを元に、皆さんの課題を紐解き解決していく為のチームです。まずはワークスペースよりご連絡ください。(もちろん問い合わせフォームからの連絡も歓迎しています) < 事例へ戻る

Sales Cloudを使い始めて最初にこれはなんだろうと思ったことがあります。 リード(Lead)と取引先責任者(Contact)です。 取引先責任者は取引先オブジェクトに所属する形で存在しています。一方でリードは個人そのもので組織とは関連付けられていません。 リードとは？ リードは見込み顧客のことを指します。これから商談が始まる可能性のあるリストのことで、新規商談を作る際のアプローチ先として活用されます。展示会や問い合わせフォームからの流入で既存顧客ではない場合にそれらのリストをリードとして登録し、ここにアプローチした結果商談化することが出来た場合は、取引の開始ボタンから商談を作成することが出来ます。 取引先責任者とは？ これは取引先を親とする、子のレコードとして存在します。ある組織に所属した人として登録されており、先程リードから取引の開始ボタンを押した際にコンバートされる先のレコードになっています。 商談には取引先責任者の役割という関連リストがあり、そこに紐付けることで、商談に対する取引先責任者がどんな役割を持っているかを確認できるようになっています。 理想的な管理方法について リードを活かすには、リードリストの管理が必要です。なぜかというとそれをやらないと、有用なアプローチ先リストとしてのリードが成り立たなくなってしまうからです。 具体的にはどんなメンテナンスが必要かというと、既存取引先と会社名が同じ場合は取引先責任者にコンバートする必要があります。リードから商談が始まった場合は、同じ組織所属の人を取引先責任者にコンバートして提案が重複しないようにする必要があります。理想的にはそういうことなのですが、これがなかなか徹底できない。なぜかというと、リードの会社名は基本的に自由記述欄ですので、名刺スキャンでのデータ化なら良いのですが、リードの人が自ら情報提供したり、誰かが手打ちで入力したりすると既存の取引先名と違ってしまったりということは往々にしてよくあります。 弊社リバネスでは、ある程度運用期間が経過してからベストプラクティスに気付いたため、リードと取引先責任者がぐちゃぐちゃになってしまっていました。そうなると、あまり効率の良い使い方ができなくなってしまいます。 効率の良い顧客管理方法を求めてプロスペクト方式へ 上述したとおり、リバネスではリード管理が崩壊してしまいましたのでより効率の良い方法が必要でした。個人のリストが２つのオブジェクトにまたがって存在することで情報効率が劇的に下がります。レコードには重複が存在するようになり、レポートやビューを使った単一オブジェクトでの情報のフィルタリングはできません。私達はこれらのリストを元に、さらなる商談可能性の発掘などの情報探索をしたいのですが肝心のリストが分割されていては作業効率が激減してしまいます。 さて、リバネスはPardotというSalesforce社が提供するメールマーケティングシステムを導入しています。PardotはSalesCloudと連携し、リードと取引先責任者をプロスペクトという顧客リストに同期してくれます。結論から言えば、SalesCloudの顧客管理もこのプロスペクト方式でよいではないかと考えました。 結果的には、リードもしくは取引先責任者にリンクを持ったリバネスIDというオブジェクトに統合しました。 こうすることで、全ての個人情報はリバネスIDオブジェクト内で検索すれば出てくるようになりました。その他に顧客に関連する情報はリバネスIDにぶら下げて存在させることにより、どの人がアクティブなのかを常に把握できるように変わっています。 もちろん、リードと取引先責任者にリンクが張ってあることからPardotからくるデータにもアクセスすることができるようになっています。 工夫点 リード・取引先責任者・リバネスIDという3オブジェクトが存在するのですが、これらの情報に乖離があるのは好ましくありません。そのため、リンクされたレコードがあった場合は、修正点を関連するレコード全てに反映しています。 例えば電話番号が変わったり住所が変わったりという事があれば、全てにその情報を反映させています。これらはフローによってSalesCloud上で実現できます。 まとめ 以上のように、人間一人一人に関するレコードはリード or 取引先責任者方式ではなく、プロスペクト方式にしてしまったほうが取り回しがかんたんになります。リードを使った管理方法もよく作られて入るのですが、メンテナンスがされていなかったりで実質機能しなくなった場合にはこのような方法を検討しても良いかもしれません。 気になった場合はお知らせ下さい。 < 事例へ戻る