Slack Workflowで定形的な報告業務を効率化したのでRettyでのノウハウを公開します!

ご無沙汰しています、Rettyはらみチーム (アプリチーム) の @imaizume です。

世の中はコロナウイルスで大変ですが、私は行きつけのお店でテイクアウトが始まったので、散歩がてら買いに行くことでストレスを飛ばしております!!

Rettyでもテイクアウトやデリバリーの情報を掲載しているのでぜひ見てみてくださいね!

corp.retty.me

さて今回はアプリ... ではなくSlackに関する話です(汗)

みなさんは、Slack Workflowをご存知でしょうか?

Slack Workflowは昨年の秋にSlackから発表された、定型的なやりとりを自動化したりフォーマット化することができる新機能になります。

slack.com

f:id:imaizume:20200424205633p:plain
Slack Workflowを使う時の流れ

Slack Workflowの概要や詳しい作り方については公式のヘルプページを参照していただきたいので、ここでは割愛させていただきますが、基本的には『トリガー(起動のフックとなるイベント)』と『アクション(フォーム表示やメッセージ送信)』を組み合わせて作ります。

例えばボタンを押してフォームを開き、前のステップで入力された値を変数にしてメッセージを流すことができます。

Rettyでは多くのケースで「ボタンをトリガーにフォームを起動し、入力内容をフォーマットして指定宛先へ送信する」というパターンのSlack Workflowを組んでいることが多いです。

このあたりはエンジニアであれば直感的にフローを組めるのではないでしょうか。

RettyでのSlack Workflow導入背景

この機能を使うことになった背景には、たくさんある定形的な報告業務を効率化したいという思いがありました。

例えば当時から私の身の回りだけでも下記のようなものがあり、これらは基本的にSlack上で行われていました。

  • QAチームへのリリース前検証依頼
  • エンジニアヘのリファインメント依頼
  • プランナーへのスプリントバックログ追加報告
  • チームごとのデイリーの進捗報告
  • チームメンバーへの勤怠連絡

こうした定形のやりとりは、Rettyのみならず多くの会社やチームで多かれ少なかれ存在するかと思います。

私以外にも様々なチーム・メンバーの間で同様のやりとりが発生していましたが、その際に以下に挙げるような問題が起きていました。

1. フォーマットバラバラ問題

メッセージのフォーマットが定形化されておらず、人によって記載内容にばらつきがあり可読性が低い状態。

例:

Androidのバージョン1.2.3でQAを依頼する時のメッセージ。表記ゆれや指示語などがあると解釈に差が出てしまう。

  • 「QAお願いします (ISSUEやSlackのリンク) バージョンは1.2.3でアンドロイドです」
  • Android v1.2.3 でQA :yoroshiku: やりとりはこの上のコメント参照」

2. 必要情報の記入やメンション漏れる問題

やりとりには必須で記入してほしい項目が存在する場合がありますが、人間が書く以上は記載漏れなどが往々にして起こり得ますし、その際には発言者への再問い合わせが発生するなど、やり取りのコストが発生していました。

また必要な人にメンションされず、大事な発言に気づけないという問題も起きていました。

例:

  • QA依頼 → チェック項目へのリンクやアプリのバージョン情報
  • リファインメント依頼 → 対象となるストーリーやGitHub Issueのリンク

3. メッセージ受口ばらばらになる問題

Slackにはチャンネルがたくさんあり、同じコンテキストでも人によって発言するチャンネルが異なり、結果後で探す時に苦労していました。

発言する側の「どのチャンネルで誰に言えば良いか」で悩む負荷と、発言を受けた側の「期待したチャンネルにメッセージがないため探す」という手間を考えると、単に時間だけでなく精神的にも負担となってしまいます。

例:

Aさん「XXXのQA依頼ってどこでやりとりしてますか?」(QA依頼なので #qa チャンネルに書かれていると思って探したが見つからない)

Bさん 「エンジニアに聞いた方が良い気がしたので #engineer に書きました!」

Aさん (「いつも #qa でやってるんだからそっちで発言してよ...」)

勤怠連絡から始めるSlack Workflow

そんな折、昨年末にはらみチームメンバーの提案で、チーム内の勤怠連絡に初めてSlack Workflowが導入されました。

f:id:imaizume:20200424195819g:plain
Slack Workflowを使用して実際に勤怠連絡をした時の様子

勤怠用のチャンネルからボタンクリックで入力フォームが起動します。

そこに必要事項を書いて送信すると、チャンネルにフォーマット化された勤怠連絡がしっかりと流れていることが分かります! 絵文字もすごくいい感じですね!!

これを皮切りに、Slack Workflowは一部のエンジニアには積極的に使われるようになっていきました。

もっとSlack Workflowを広めるために

しかし導入からしばらくして他の社員に聞いたところ、そもそもSlack Workflowの存在自体を知らなかったり、具体的にできることを認知していない方が多くいることが分かりました。

せっかくの便利な機能なのでぜひ他の社員・部署でも使ってほしい... そう思い立った自分は、社内で定期的に行われているプランナーやデザイナーさんも参加する勉強会で、ハンズオンのLTを行うことに!

既にある程度のSlack Workflowの作成・運用実績はあったので、利用メリットや具体的に何ができるのか、逆にできないことなどを紹介しました。 当日の発表資料を一部抜粋して掲載します!

f:id:imaizume:20200424201048p:plain f:id:imaizume:20200424201025p:plain f:id:imaizume:20200501172837p:plain

するとLT直後から「日報をSlack Workflow化したい」「分析依頼をフォームにして受け口をまとめたい」という声をいただき、無事社内にSlack Workflowが広まっていきました。

実際に運用されているSlack Workflowの例

ここで、現在Retty社内で使われているSlack Workflowの例をいくつかご紹介したいと思います。

例1: QA依頼

f:id:imaizume:20200424201217p:plain

はらみチームでは、新しい実装を行ったときにQA担当者へ依頼をするのですが、ベータ版のバージョン番号やQA項目の記載場所などを決まった形で特定のチャンネルに流すためのSlack Workflowを設定しています。

フォームには依頼主であるエンジニアやQA担当者の他、施策を担当したプランナーもリストから選択してメンションされるようになっています。

これにより「要件にはOKだけどUI/UX的にはちょっとコレジャナイ...」といった事態を防止しUser Happyをより多く早くお届けすることにつながっています。

例2: プランナーへのスプリントバックログ追加報告

f:id:imaizume:20200424201246p:plain

スクラム開発でおなじみのバックログですが、Rettyではバックログに積んだことをプロダクトオーナーやプランナーに知らせるためにSlack Workflowを活用しています。

こうすることで「あれ、こんなタスクいつの間に積まれたの??」といった把握漏れを防いだり、気づいたその場でスレッドで議論したりすることができています。

例3: 日報

f:id:imaizume:20200424201321p:plain

毎日指定時刻にボタンが出現し、押下すると日報報告用のフォームが開きます。

こちらはボタンではなく指定日時がトリガーとなっています。

Slack Workflowの仕様上1つのフローで複数チャンネルやDMには配信できないため、Rettyでは個人ではなくチームごとに代表者が日報をまとめて記入する運用をしています。

現在フォーマットは特に指定していませんが今後追加することも容易ですし、リマインダーと比べてもやることが明確で使いやすいというメリットがあります。

なおSlack Workflowはコピーできるので、他チームの運用が良ければおすそ分けしてもらうのもありでしょう。

学び

今回の一連のSlack Workflow普及活動を通じた学びをお伝えして締めたいと思います。

自分はSlack Workflowのリリース当初から機能の概要を知っていましたが、全体の認知度は思ったより低く、存在自体を知らない、あるいはステップの組み方や何が嬉しいのか分からないと思っている方もまだ少なくないようです。

実際自分も前述のLT後にSlack Workflowの作成にTRYした社員から「思ったようにメッセージが投稿されない」「なぜか意図した場所ではないところにメッセージが流れてしまう」といった相談を受けました。

そこで、ある程度Slack Workflowに慣れた人が成功事例となるSlack Workflowをいくつか作成し、旗振り役として積極的にヘルプに入ってあげるのが良いのかなと思います。

特にエンジニアは変数や手続きなどの概念に慣れ親しんでいて得意な人が多いような印象があるので、困っている方を見かけたらフォローに入ってあげると広まりやすいのかなと思いました。

またLTではSlack Workflowが得意としないことやできないことについても解説し、必要に応じて他のツールも使うことをおすすめしました。

例えばSlack Workflowには結果をストックしてまとめて流すといった機能がないので、そういったケースではGoogle Formを使うようにしています。

さらに今後Slack Workflowが増えた場合に、メンテナンスや管理をどうするのかといった問題が起きそうということもお伝えしました。

これについては現状の解決策が「運用でカバー」以外になさそうなので、管理者を決めてコラボレーターに追加するなどの対応が必要そうです。

最後に: Slack Workflowを使った社員の感想

  • 「チームの誰が日報を書いてもフォーマットが固定化されるのでよかったです!」
  • 「スプリントバックログの追加も検知できるようになったのでよかったと思っています。」
  • 「新規参入者が周りの様子をみて空気を読んだ依頼文言を考えるっていうことをしなくて良くなったのもメリットですね!」

ぜひみなさんの職場でもSlack Workflowを活用して、やりとりを定形的することで効率化とハッピーを目指してみてはいかがでしょうか?