非エンジニアがSlackワークフロー×GoogleスプレッドシートでカンタンIssue管理システムを作成＆運用した話

この記事の概要

• この秋にあるサービスの社内CRMをSalesforceに切り替えるプロジェクトを動かしていました。
  • 2018年から一部チームでの導入を実施していましたが、今回はサービスに関わる全チームのCRM切り替えです。
• 切り替え後は1か月半を不具合対応・質疑応答のフォロー期間と設定していました。
• その期間中、リアルタイムでレスポンスできるよう、社員からの問い合わせをslackで受け付け、進捗管理をスプレッドシートで行っていました。
  
  
• リアルタイムなレスポンスの結果、
  発生した不具合の51%は当日中に、80%は1週間以内に、90%は10日以内に解消 する事が出来ました。
  
• この記事では、エンジニアでなくても30分で作れたその仕組みを共有します。

前提

GitLab/GitHubは使わないのか？

• 気になるところだとも思いますので、少し長めに説明します。
• 本来、対応管理やIssue管理は、GitLab/GitHubを使うべきだと思いますが、今回の事例は「新ツール導入」に際する問い合わせ管理にフォーカスしています。
  • 新システム導入初期の一時的なIssue管理であるとご留意頂けると幸いです。
    
    
• 通常、弊社もGitLabを用いたIssue管理を行っていますが、管理者が起票するフローになっています。
  • 「新ツール・新システム導入」で発生する不具合は、実際のCRM利用者が気づいてから修正対応するまでのリードタイムが短くあるべきです。よって、管理者の起票を待つ余裕はありません。
    • とすると、GitLabでの管理はCRM利用者が新ツール（Salesforce）導入に合わせてさらなる新ツール（GitLab）の使い方を覚える必要があり、これは現実的ではないと判断しました。
      
      
  • 日常的に使うSlackからGitLabに自動起票されるような仕組みはどうか？も検討しましたが、プロジェクトチームは全員開発をしていたので、開発過渡期に保守・運用期に向けて仕組みを構築する専任担当を置くほどのリソースはありませんでした。
    • 先のことを考えるのはプロジェクトマネージャーのミッションです。
      • よって私が考え、私が出来得る手段で実装することにしました。
        • ただし、私もごりごりのSalesforceフロー開発担当だったので、問い合わせ管理のシステムは必要最低限で（しかも息抜き程度で）整備しよう、と心に決めていました。
      • 今後同じ進行を行うのであれば、プロジェクトの始動段階で「CRM利用者が気軽に起票→その内容がGitLabに転送される→GitLabでのIssue管理が叶う」ようなフロー開発のタスクを入れると思うので、PMとしての反省点でもありますね "(-""-)"＜ もっと余裕をもたねば。

作ったひと

• 私は（残念ながら）エンジニアではありません。
  • よく「ビジネスサイド」「企画部門」と置かれるようなポジション・キャリアです。
  • ただ、企画を考えるよりも、その企画を動かす枠組みや仕組みを考えるほうが好きなタイプです。
    
    
• 私が自分で何か仕組みを開発したいなーと思ったときに使える手札は
  「スプレッドシート関数」
  「簡単なGAS」
  「Slackワークフロー」
  「Salesforceフロー」です。
• 今回の話は、私が自分の持つ手札で仕組みを作った話です。
  
  
• エンジニアじゃないけど業務が自然と回る仕組みを作るの好きなんだよなあ、
  という人のお役に立てれば幸いです。

作ったもの

• 前置きが長くなりましたが、ここからは実際に構築した内容について説明します。

全体像

• 不具合報告→修正対応→確認依頼→確認完了、までの一連の流れを作りました。
• 弊社内のコミュニケーションツールはSlackなので、気軽に×すぐに問い合わせができる場所として、Slackチャンネルを起点にすることにしました。

詳細

フォームの送信

• Salesforceを利用する社員が集まるSlackチャンネル（以下、問い合わせチャンネル）に
  ワークフローをリリースしました。
  
  

• まず、不具合を発見した社員がここを押すと↓のフォームが立ち上がります。
  

• 選択肢はこんな感じです。

種別	重要度

不具合内容の通知・修正対応者の確定

• フォームが送信されると、

  • 問い合わせチャンネルにはこの確認用メッセージが届き、
  • 管理者チャンネルにはこの通知用メッセージが届きます。

• 管理者チャンネルで、対応できるスタッフが 「対応を引き受ける」ボタンを押します。

担当者の通知

• 先ほど、問い合わせチャンネルに届いた 確認用メッセージのスレッド に、
  対応者が確定した事が通知されます。
  
• このとき、対応者がメンションされているので、
  対応者はこのスレッドで不具合発見者と情報交換をします。

対応完了の通知

• 対応者の通知がされると同時に、管理チャンネルのスレッドには
  対応完了後に対応ボタンを押すよう指示が飛びます。
• 対応者は不具合を確認し、修正が完了したら、この「対応完了」ボタンを押します。
  

確認依頼の通知・確認を完了する

• 「対応完了ボタン」が押されると、
  問い合わせチャンネルに届いた 確認用メッセージのスレッド に
  対応完了通知が送信されます。
• 手元の画面で、修正が反映されている事を確認した不具合発見者は、
  「確認した」ボタンを押します。
  

確認完了を通知する

• 確認完了ボタンが押されると、管理チャンネルのスレッドに完了報告が通知されます。
• これで一連の流れは終了です。
  

Issueの管理

• Slackで報告された不具合は、「Issue」としてスプレッドシートで管理していました。
  
• フォームを送信すると、スプレッドシートの新規行が作成されます。
• そして、Slackのメッセージに配置された各ボタンを押すと、状況が更新されるようにしていました。

• Issue管理では、ステータスの更新が手動であることが多く、
  状況が最新になっているかを確認しなければならないときがあります。
• この場合は、Slackの会話のなかにステータスの更新を組み込んでいるため、
  常にIssueの状況が最新の状態に保たれる点が便利でした。
  
  
• 毎日の朝会では、このスプレッドシートを見て、
  • 対応者が確定していない、浮いているIssueはないか。
  • 対応が完了していないIssueはどれか。
  • 確認が終わっていないIssueはどれか。
• をチームで確認すればOKだったので、
  スプレッドシートのフィルタを使い、対応漏れがない状況を作る事もできました。

必要なもの

• スプレッドシート
• Slack
  • Slackアプリケーション「Google Sheets for Workflow Builder」
  • Slackワークフロービルダー
    • ワークフロービルダーを使うためには有料プランが必要です。
      

作り方

• 今回のワークフローは「ショートカット」です。
  

• 作ったワークフローはこのようになっています。
  

• Slackアプリケーション「Google Sheets for Workflow Builder」では、
  Slack上から、「Add」「Update」「Delete」を行う事ができます。

• 今回は「Add」と「Update」を使っているので、その内容も載せておきます。
  

Add a SpreadSheet row	Update a SpreadSheet row

この仕組みを運用した結果

• リアルタイムでやり取りを重ね、状況を更新し続けることで、
  発生した不具合の51%は当日中に、80%は1週間以内に、90%は10日以内に解消 する事が出来ました。（再掲）
  

• スピードだけでなく、数をこなす事にも寄与したため、
  1か月半のフォロー期間の間、大小ありますが、1人平均28件 の対応を行いました。

  • 私たちのSalesforce導入は自社CRMと併用する事が前提なので、Salesforce以外の不具合対応も含みます。
  • また、同じ仕組みで「質疑応答」も受け付けていたため、1人平均28件の内訳には「質問への回答」も含んでいます。（グラフには含まれていません）
  • このあたりの奮闘記もまた別で記事として起こせたらなあと思っています。

• 不具合は出ない事がもちろん最適だと思いますが、
  初めてのCRM移行で想定できない事態が起こる事は容易に想像できていました。

• 不具合が起こることを前提に、いかにスピーディに解決できるかに舵を切り、
  事前に対策を講じられた事は大変良かったと思います。

Slackワークフロービルダーについて思う事

• Slackのワークフロービルダーは、条件分岐が指定できないため、直線的なフロー作成に適しています。
• 外部からのトリガーをフローに取り入れる事もできないので、例えば、スプレッドシートで状況を「〇〇」に更新したらSlack通知する、という処理もできません。
  • そのような処理を取り入れたい場合は、GASを書いてフロー外で動かす事になります。
• 業務やフローをシンプルにする強制力が働いて良いと思う反面、
  どうしても条件分岐や書き戻し処理があったらな‥と思ってしまいます。(笑)

一番避けたかった事

• リリースしたあとに、問い合わせがチーム個々人にダイレクトで入る 事だけは
  プロジェクトマネージャーとして絶対に避けたいと考えていました。
  • リソースのマネジメントやヘルプもできませんし、ノウハウもたまらないからです。
• 次に避けたかったのは、 Slack上の会話から修正対応が自然発生してしまう ことでした。
  • ぬるっと引き受けた対応は、誰にも管理されることなく、ぬるっと進行してしまいます。
  • 管理体制を徹底すべく、 フォームから起票されないものは対応しない、という統制をとるべく、
    問い合わせフローを一本化する事にしました。
• ここまで管理体制を敷いたのは、不具合が治らないツールは使われなくなるという前提があったからです。
  • 頑張って切り替えたCRMが使われなくなり、社員のローカルPCにCRMに書くべきデータが保存されていく未来ほど最悪なシナリオはありません。
• 信頼され、使われるCRMになるには、リリース後の問い合わせは徹底管理・即時全件対応が必須だと考えていたので、少工数で作った割には効果があってよかったなと思っています。
  • CRMを導入する事がゴールではないので、プロジェクトはまだまだ終わりませんが。

補足

• この仕組みのよいところは「スレッドに情報がまとまるところ」でした。
  • 問い合わせ起票者と担当者をメンションをつけることでスレッドに集め、情報のやりとりが行われて行きます。Slack内で起票・更新・情報のやりとりが簡潔するのはとても良かったと思います。
    • スプレッドシートの情報からSlackの検索をすれば、スレッドでその内容を確かめる事も可能でした。
      • ヘルプをするときに役立ちます。
  • また、学習コストが低いのもよかったです。
    • 特に説明をしなくても問い合わせが発生し、対応が進んでいたのは、私からすると不思議な気持ちでした。管理者・CRM利用者双方からこの仕組みの使い方の質問が来るかと思っていましたが一切来ませんでした。感覚を言葉にする事はまだ出来ていませんが、「直感で使える」仕組みってこういうことかと思いました。
      
      
• この仕組みの良くないところは「問い合わせチャンネルと管理チャンネルの２つのチャンネルを混同しやすい」というところでした。
  • 対応者が「対応を引き受ける」ボタンを押し、そのまま、管理チャンネルのほうで質問を始める、という場面が何度も発生しました。管理チャンネルには問い合わせた社員は入っていないので、気づく事ができません。
    • チャンネルは１つにすべきだったか‥？いや、管理側だけで情報をやり取りする場合もあり、そのときは通知が邪魔になるだけだし‥と運用終了の最後まで悩みの種でした。
      
      
• また、冒頭でも述べましたが、この仕組みは暫定的なものだとも考えています。
  • 短期間で、さっと問い合わせ管理の仕組みを立ち上げたい場合には有効だと思いますが、恒常的に使うものではありません。我々も問い合わせ数がひと段落した後は、GitLabにIssue管理を移しました。
  • スプレッドシートはあくまでも表計算のツールですし、スプレッドシートの行やSlackのスレッドをバージョン管理やGit管理に紐づけることは無理があります。
  • システム運用なので、Issueはリリース対応とセットで管理すべきだと思います。

今後の発展

• とはいえ、Issueの起票は、Salesforceを利用する社員（ビジネスサイド）からすると少し敷居が高いのも事実です。
  • 網羅的に仕様にまつわる情報を書き記さなければと、躊躇してしまう気持ちもわかります。（私がそうだからです）
  • Slackは、そういった心理的ハードルを下げていた側面もあるかもしれません。
• そのため、最近は、IdeasAnyWhereというAppExchangeを試験的に導入しています。
  • IdeasAnyWhereについては、参考にさせていただいている記事がありますので、そちらの紹介に留めさせていただきます。
  • 試験的な導入を経て、いつか記事にできたらいいなあと思います。

業務効率を上げる仕組みづくりを追求したい

• 私のプロジェクトチームは、エンジニアサイドとビジネスサイドが融合したチームです。

タイトルの「非エンジニア」や、「エンジニアサイド」「ビジネスサイド」という区分けはポジショントークに陥りやすそうで、使いたくないなーと思っていますが、良い表現を2年考えても見つからないので便宜上使用しています。

• ビジネスサイドはエンジニアリングを学び、エンジニアサイドはビジネスを学び、双方が歩み寄ってSalesforceとTableauを用いた業務効率化・オペレーションの改善・データ活用に邁進しています。
  • 常日頃GUIやノーコードでプログラムを組むときにも、保守観点やノウハウ共有の観点など、エンジニアリング独特の視点で指摘やアドバイスを貰うことができるため、安定して長期運用できる仕組みづくりのノウハウが身についてきたように思います。
  • だからこそ、エンジニアリングの効率化が叶う仕組みをチームに提供出来た事は、私にとって少しの恩返しができたかのような気持ちです。（おこがましい）
    • アドベントカレンダーに参加して4年目ですが、これまでの記事より、だいぶシステマチックななんちゃって開発になっていると思います(笑) 有難い環境であります。
• これからもビジネスサイドとエンジニアサイドが歩み寄り、一緒に業務を見直し、一緒に仕組みを作りあげる事で、さらなる事業発展・顧客価値の創造につなげていきたいと考えています。
  
  
• そんな私のボスであり、尊敬するエンジニアである @kakakaori830 は、現在、アドベントカレンダー完走賞を目指してひた走っています。
  • ぜひ12/25に立派なSalesforceエンジニアになる姿を見届けてください。

おわり。

• 簡単な仕組みの説明で大げさな記事を書いてしまったような気がしますが(笑)
• ここまでお読みいただきありがとうございました^^