こんにちは、アプリチームの imaizume です。 趣味でワーケーションをする傍ら、Retty投稿で47都道府県制覇を目指しています! 残念ながら今年は7割程しか達成できなかったので来年こそ達成したいと思います。 (Meetyも公開中なのでよければ是非お話しましょう)
さてついに始まりました「Retty Advent Calendar 2022 Part1」の初回記事です。 Part2のカレンダーもありますのでぜひそちらもチェックしてみてください!
今回はSlackの定形やりとりを便利にする公式機能 “Slack Workflow” についての記事になります。 2年以上に渡るRettyでの運用を経て得られた知見を詰め込んだ記事となっております! まだSlack Workflowを知らない・使ったことがないという方は、ぜひこれを読んで業務効率化に役立ててもらえれば幸いです!
- Slackを使う上での課題
- Slack Workflowとは
- Slack Workflowの特徴
- RettyでのSlack Workflowの運用例
- WF運用で得られた効果・メリット
- 実際にやってみて分かったWF運用におけるTIPS・注意点
- WFにおける制約・課題点
- まとめ: Slack Workflowは業務効率化の第一歩!
Slackを使う上での課題
今や多くの企業・組織でチャットコミュニケーションのデファクトスタンダードとなりつつあるSlack。しかし、使う人数や情報が増えると困ったことも起きてきます。 その一つが定期的・定型的に行われるやりとりにかかるコストが増えることです。 Slackの本質はずばり「メッセージの送受信」ですがその自由度の高さゆえ、定型的なやりとりについて次のような問題が発生します。
必要な情報の不足
例えばアプリをリリースするにあたり、エンジニアから関係者へ周知する場面を考えてみます。 Rettyの場合、毎回エンジニアから以下のような情報を周知する必要があります。
- 周知先
- リリースする施策の担当プランナー
- QAチーム
- CS (お知らせ配信の担当者)
- 必要な情報
また逆にプランナーからの返答として
- ストアに掲載するメタデータ(ストア画像/リリースノートなど)に変更があるかどうか
- お知らせを掲載する必要があるか
を聞く必要があります。こういった情報を毎回手入力しているとヒューマンエラーにより
- 必要な情報が漏れる
- 必要なメンションを忘れる
- 表記揺れによる可読性・検索性の低下
といったことが問題になってきます。 Rettyでも以前はこういった問題が散見され、リリース時に確認のやりとりが多く発生していました。
内容や投稿先などを書く・覚える・考える手間
そもそも周知や報告のための文章の入力自体が手間です。毎回同じフォーマットを手入力するのは非効率ですし、フォーマットをドキュメント等で共有するのもあまり良い運用とは言えません。 また慣れている人であれば文面を考えるのは簡単かもしれませんが、新人など慣れていないメンバーが報告する場合には内容を考えることも負荷になります。 加えて、必要なメンション先、投稿先のチャンネル、返答後のアクションの有無を毎回判断することで、負荷や属人性が増えることは言うまでもないでしょう。
自動化は高コスト
他方「毎朝」「毎月」といった定期的なメッセージ送信は、リマインダー機能を使うことで実現可能です。
しかしSlackのリマインダーは機能がかなり簡素で、スラッシュコマンド /remind を使った一覧表示や変更は独特の文法などが扱いづらいのが難点。
これよりも高機能な定時実行を行う方法としてはSlack Botを組むという方法がありますが、Slack Bot作成にはエンジニアリングの知識が必要であり、コードやデプロイ先サーバーの管理コストが発生することを考えるとコスパが良い手段とは言えなさそうです。
Slack Workflowとは
そこで活躍するのがSlack Workflow (以下WF)です。 WFはSlackが公式に提供する有料プラン向けの機能で、一言で説明すると「定形コミュニケーションを含む業務フローを誰でもフォーマット化・自動化できるツール」になります。
専用の画面からステップを組んでフローを作成することができ、チャンネル横のアクションボタンなどで実行させることができます。 例えば「ボタン押下でフォームを出現させ、必要な情報を入力すると、同じフォーマット・メンション先でのメッセージを送信する」といったコミュニケーションの自動化が可能になります。
基本的な使い方について説明すると長くなるため、本投稿では割愛させていただきますが、デスクトップ版内のグローバルメニューから「ツール > ワークフロービルダー」を開くと作成することができるので、公式記事を参考に作成してみてください!
Slack Workflowの特徴
WFには以下のような特徴があります。
コミュニケーションの定型化・定時実行を実現
最大の特徴は定形のやり取りをフォーマット化・フロー化できるという点です。例えば
- フォームを表示して必要な情報だけを入力させる
- 入力された情報を定形文に埋め込んで指定のメンションを付けて送信する
- 定期的にメッセージを送り、その後に何らかのアクションをさせる
といったようなことが実現可能です。
多様な起動トリガー / 外部連携が可能
WFはボタンから開始することが一般的ですが、他にも定時での実行や指定の絵文字によるリアクション、Webhook経由など様々なトリガーで起動させることができます。 またWFを使って情報をSlack上で入出力するだけでなく、外部サービスと連携させることが可能です。例えば次のようなサービスと連携することができます
- Google Spreadsheet
- Polly
- Zapier
ノーコード
WFを作成するにあたって、プログラミングは一切不要です。つまりエンジニアでなくても誰でもWFを作ることができ、管理者に追加することで1つのWFを複数人で運用・メンテナンスすることも可能です。 (厳密にはフォームの入力を扱う「変数」は登場しますがコードを書くことはありません) なので「エンジニアが作ったけど直し方が分からなくて壊れたまま…」といったことはWFでは起きません!
RettyでのSlack Workflowの運用例
Rettyでは2年前からWFの利用を開始し、現在ではエンジニアリング・プロダクト部門を中心に多くのチームでWFが活躍しています。 ここではRettyでのWFの利用例を業務フローとともに解説していきます。
定期報告系
チーム日報
日々のチームの状況をプロダクトオーナー(以下PO)に伝えるため、各エンジニアチームは毎朝日報を送ることになっています。 以前は「送信忘れの頻発」「フォーマットがバラバラ」「POが知りたい情報がない」などの課題が有りました。
そこでRettyでは毎朝11:00に、各チームへメンション付きでフォームを送信し、内容として「スプリントゴールの達成可否」「昨日やったこと」「困っていること」「その他」を入力させるようにしました。 これによりチーム間で日報がフォーマット化され、POの知りたい情報が確認しやすくなったほか、送信後はPOが確認したことをボタンで返答することで、お互いの意思疎通がより正確かつ明示的にできるようになりました。
アプリのリリース有無連絡
Rettyのスクラムは1週間スプリントとなっており、iOS/Androidのアプリリリースも原則毎週定期的に行うようにしています。 その際、前述の例のような関係者への周知が必要となるのですが、審査のリジェクト、祝祭日等の外的・内的要因によってリリースタイミングがずれることがあります。 以前はリリース日時変更の周知を忘れ、CSやPOに対して迷惑をかけてしまうことも多々有りました。
現在は週初めに「iOS/Androidでリリースはあるか」をアプリチームにメンションし送信させることでこういった周知漏れを防ぐことができています。 かなり簡単なWFではありますが、こうした定形化と定時実行が業務上のミスを減らすことに大きく繋がり生産性の向上に役立っています。
Stepを組み合わせたやりとり
リファインメント依頼
Rettyはスクラム開発(LeSS)を行っており、基本的にはチームを職能やKPIではなく機能を横断的に開発するフィーチャーチームと呼ばれるチーム構成を取っています。 フィーチャーチームについては、LeSSへの移行について書いたこちらの記事にも解説がありますので興味がある方は御覧ください。
この「機能を横断的に」という点で、リファインメントを依頼する時点では当該施策を「どのチームが対応するのか」が毎回不定であり、基本的には開発チームが相談したうえで受け入れ先を決めています。 以前はこの依頼に反応がないままになったり、リファインメントの対応状況がまとまっていないなどの課題がありました。
そこで現在では、リファインメント依頼にWFを用いており、フォーム提出後続けて各チームのスクラムマスターに向けて「この施策を自チームが担当できるか」といった問が投げられます。 この質問にスクラムマスターが回答することで、ボールが浮いたままになることもなく、また開発に参加する最適なチームを開発陣が自ら決められ、他のタスクとの調整などで早い意思決定を可能にしています。
アプリのリリース前QA依頼
冒頭の例で説明したようなアプリのリリース前QAでも、実際にWFを使った業務フローが確立されています。
まずエンジニアからリリースバージョンやQA項目の書かれたISSUEを送信すると、QAチームや品質管理を担当するプランナーに通知が飛びます。 そこからリリース文言をボタンアクションを使って返信したりQA結果をスレッドに報告することで、Releaseに必要な情報を確実に、そして1箇所に集約することができています。
このWFを導入してから2年近くが経ちますが、大枠を変えることはほぼなく、かつコミュニケーション上のミスもほとんど起きていません。
Spreadsheetとの組み合わせ
リファインメント依頼と通知
前述のリファインメント依頼には、指定のSpreadsheetに入力を追記するSTEPも入っています。 というのも、リファインメントは毎日決まった時間に行うため、翌日にまとめて通知するには依頼をバッファリングしておく必要があるためです。
そこでSpreadsheetに追記されたリファインメント依頼の一覧は、リファインメントの少し前に別のWFから各チームへ通知するようにしています。 こうすることで、リファインメントの有無や対象の施策のURLを知り、事前に内容を読み込むことも容易になります。 またリファインメントが完了したら、シート上でステータスを変更することで、翌日以降に通知されることはありません。
missrepo (お店情報の更新依頼)
Rettyでは日々様々な手段を駆使して日本各地の飲食店情報を収集していますが、社員からの情報提供もその中の1つです。 この報告はmissrepo(ミスレポ)と呼ばれており、専門のチームが報告をもとにお店のデータを逐次アップデートしています。
この報告についても、つい最近フォーマット化してSpreadsheetに記載・対応するWFとして整理されました。 イメージ的には簡単な業務システムを組んだのに近く、こうすることでカテゴリや対応状況、ソースとなるURLなどをフォーマット化し整理しやすくなり、コストをかけずにより効率的なオペレーションを実現できるようになりました。
WF運用で得られた効果・メリット
WFの導入によって、ヒューマンエラーや人力に依存する作業のコストが減り、Slack上のでコミュニケーション効率が大きく向上しました。
報告文章を考え入力しなくて良い
フォームから必要な情報だけを入力するので、文章そのものを考え入力する必要がありません。 これによって、報告する側の負荷軽減に成功しました。
誰でも同じ報告ができるようになった
必要な情報さえ知っていれば、業務に慣れている・いないに関わらず、誰でも同じクオリティで報告ができるようになりました。 これによって情報の伝え漏れなどが起きにくくなり、追加のやりとりも発生しなくなったため、報告を受ける側がスムーズに受けられるようになりました。
報告・返答忘れがなくなった
フォーマットにメンションが含まれるので、意識せずとも必要な相手に通知が飛びます。 また明示的にボタンアクションを必要とすることで、リマインダーでは実現できなかった既読忘れ・スルーの防止に繋がり、結果として報告をする側・される側の両方の負荷が減りました。
実際にやってみて分かったWF運用におけるTIPS・注意点
ここまでRettyでのWF運用における実例とメリットについて紹介してきましたが、ここからは注意点や覚えておくと良いTIPSについても紹介していきます。 WF自体は便利なのですが、いくつか制約もあるため運用でカバーしている部分もあります。
初期のWF管理者が自分だけ
WFはメンバー間で共同管理をすることができ、これによってWFの更新・改修における属人性を減らすができます。 ただしWFを作成した初期の状態では管理者は自分だけとなっているため「作ったは良いけど誰も編集できない」「よく分からない野良WFが動いている」といった事態が発生する可能性があります。
そこでRettyでは、WF作成時に原則上長やチームメンバーを追加するという運用ルールを設けることとしました。これにより「野生のWF」が増えることがなく、個別に管理者を探す手間も省けるようになりました。
なおWFの編集権限にはレベルの概念がなく、管理者は他者の招待も可能になるため、必要であれば他のメンバーを積極的に管理者に追加し、ガンガン編集してもらっています。 今のところWFを誤って消してしまう、壊してしまうといった不都合は起きていませんが、今後はこのあたりに課題が出てるくかもしれません。
リマインダーよりもWFを使う
Slackには以前よりリマインダーと呼ばれる機能があり、WF登場以前から定時のメッセージ送信に使っていた方も多いかと思います。
しかし前述にもあるようにSlackのリマインダーにはいくつかの制約があります。
- GUIがなく、スラッシュコマンド
/remindの文法がやや扱いづらい - 機能が簡素、ゆえにフォーム送信やアクションボタンは設置不可
- リマインダーはチャンネルに紐づくため、チャンネルを移動する必要がある
このため、定時のメッセージ送信にはWFを使うほうが良い場合も多く、Rettyでも私を中心にリマインダーをWFに置きかえることが多々ありました。
リマインダーと比べてWFは
- 専用のGUIで編集ができる
- 後からでもフォーム送信やアクションボタンが追加可能
- チャンネル移動が不要 (画面でリストし絞り込みもできる)
といった点でリマインダーよりも扱いやすいので、メッセージの定時送信の選択肢として常にWFを検討するようになりました。
履歴は直近1バージョンのみしか残らない
現在WFにはバージョン管理の仕組みがなく、履歴は直前の1バージョンしか残らないという仕様になっています。 json形式で現在のWFをエクスポートする機能はあるものの、手動での実行・管理となりあまりバージョン運用には適していません。
このため「もし壊してしまう不安がある」「もとに戻せる自身がない」といった場合には詳しい社員に相談するよう周知しています。 今後このバージョン管理が充実すると、失敗を恐れず安心して編集することができるようになるので、ぜひ対応してほしいところであります。
WFにおける制約・課題点
最後に運用でもカバーが難しいWFの制約や課題点について紹介します。
条件分岐は不可
WFはGUIからプログラムなしでフローが組めるので、特別な知識が不要で誰でも扱いやすいのが特徴。
しかしそれ故、複雑なフローが組めないという欠点もあります。特に If や Switch のような条件分岐がないため、時にはそれが不便に感じられる場面もあります。
例えば前述のお店情報更新依頼(missrepo)は、更新内容に応じてフォームへの入力項目も変わるのですが、これを1つのWFで表すには限界があります。
そのため現在は複数のWFを用意し、内容ごとに違うフォームを送ることで対応させています。
このように似たようなフローであっても、WFを共通化できない場面があるのはなんとも歯がゆいところです。
開始条件は後から変更不可 / 複数設定ができない
WFにはボタンからの起動や定時実行といった開始のためのトリガーを複数設定することができます。
しかしこのトリガーは最初の作成時にしか選択することができないため、例えば「定時実行にしていたけど頻度が減ってきたのでボタン起動にしたい」と思った場合には、再度WFを作り直す必要があります。 また「定時とボタンの両方」を設定したい場合にも1つのWFでは対応できず別個に作る必要があります。
運用上どうしても起動タイミングを変更したい場面は出てくるので、このあたりも柔軟に変えられるよう今後のアップデートに期待したいところです。
Spreadsheetも使える! ...けど機能が弱い
WFの外部連携を使うことで、Spreadsheetに対する追記や読み出しができます。
この機能自体はRettyでも多くの場面で使用しており大変重宝しているのですが、現状ではかなり簡易的な機能しか使えないのも事実です。 特に読み出しの機能については「指定のシートで指定の値にhitする行を見つけて読み出す」以上のことができず、フィルターや集計といった作業はできません。
たとえば前述のリファインメント報告では、未実施の依頼が複数件あった場合も「未実施の行」を1行しか読み出すことができません。
このため現状はワークアラウンドとして、Spreadsheet上で別途未実施の複数行を ARRAYFORMURA 関数を使い別シートに1行に集約しそちらを参照させるという手法を取っています。
このように現時点では課題も多く存在するので、できること・できないことを理解し、適切に業務に使っていくようにしましょう。 当たり前ですが、WFは決して銀の弾丸ではありませんし、今後のアップデートにも期待していきたいところです。
まとめ: Slack Workflowは業務効率化の第一歩!
ということで今回は2年以上にわたるRettyでのWF運用で得られた知見を余す所なくご紹介させていただきました。
みなさんも日々の業務において、多かれ少なかれ定形的なやり取りは行っているはずですので、そういったコミュニケーションからWF化することで入力・確認を効率化していきましょう! 専門知識不要ですぐに試せすことができますし、実際に使うことで応用できる部分やコツも自ずと分かってくるはずです。 まずは自身の日報や勤怠連絡などからWFを導入してみてはいかがでしょうか?
本記事を読んで、WFにより皆さんの業務改善がより一層進むことを願っております。
明日は同じチームメンバーの @matsudamper による投稿です、お楽しみに!
