はじめに

こんにちは!bravesoftエンジニアの赤ちゃんです!

昨年、2019年10月15日に、Slackの新機能として「ワークフロービルダー」がリリースされました。(関連記事: ワークフロービルダーが新登場 : Slack で簡単にタスクを合理化

Slackでカスタムフォームを作ったり、そのフォーム回答内容などの情報を使ってチャネルへの投稿(報告・通知)など、一連のワークフローを作成・設定できる便利な機能です。

今回は、ワークフロービルダーで作成したフォームから勤怠連絡をするとGoogle Spread Sheet(スプレッドシート)にその情報が追記される勤怠管理システムを作ってみたので紹介します!

目次

記事が長くなったので、目次を用意しました。
忙しい人は、興味があるところから読み始めてください。
1. 背景
2. 要件
3. 試行錯誤
3-1. 【原因①】ワークフローから直接3rd Partyにデータ送信できない
3-2. 【原因②】ワークフローからユーザー表示名をチャンネルに投稿できない
4. 概要仕様
5. Workflow Builderの設定
6. Google Apps Scriptを作成
7. 踏み台サーバ@Glitchに中継アプリケーションを作成
8. Slack Appの設定
9. 動作確認
10. あとがき
10-1. 勤怠システム導入後
10-2. 拡張性
10-3. 課題
10-4. Slackへの期待

背景

昨今、会社の業務を改善する為の様々なツール・サービスが増え、便利な世の中になってきました。
業務効率化をする為にそれらを導入すると、結果として、社内の情報が用途や内容毎に様々なツールに分散してしまい、逆に管理がしずらくなってしまう問題が生じます。
社内の情報が様々なツールに分散して困っている人

そういった社会的な課題が生まれたことを背景に、Slackの様な便利なコミュニケーションツールが世の中で評価される様になったと思っています。
Slackは、元々Tiny Speck (現: Slack Technologies)というゲーム会社が自社製品開発時に併せて内製したコミュニケーションツールを製品化したもので、名称の由来の「Searchable Log of All Conversation and Knowledge」に表される通り強い履歴検索(部分一致・完全一致)が可能なこと、そして多種多様なAPIが整備されているため他システムとのAPIによるデータ連携・インテグレーションが容易であることから、2014年頃からグローバルに広まったチャットツールです。

1500以上のツールや組織と連携しているSlack

弊社も、2019年12月から業務に関係するコミュニケーションは社内・社外ふくめ、基本的にすべてSlackに集約するようにしています。
最近では、社内の部署間で業務を依頼する為の申請もSlackを通して行う様にして、他システムに申請内容をAPI連携してます。ただ、最初は申請フォーマットをすべて手打ちで入力する運用をしていた為、記入ミス(バリデーションエラー)による申請ミスが多発し、業務効率化を目的に導入したはずの制度が機能しない、というのが課題となりました。

*実際に手打ち入力していたフォーム

[info][title]勤怠連絡[/title]・名前(例:ブレイブ二郎)
・区分(例:遅刻、欠勤)
・理由(例:気分が悪く途中下車したため)[/info]

(タグや中黒の書き損じ・書き忘れ等でバリデーションに引っかかる事が多々ありました)

Slackのワークフロービルダーの登場により、Slack上で使えるカスタム入力フォームを作成できる為、申請者の入力の手間を軽減できるだけでなく、そういった記入ミスを発生させない様に申請者側の入力方法を制御することが可能になりました。

そこで、弊社でも、Slackのワークフロービルダーで申請フォームを作成し、活用し始めました。その活用例として勤怠管理システムを紹介させて頂きます。

要件

弊社では現在(2020年2月)、以下の組織体制で業務を行っています。
2020年2月時点のbravesoftの組織図

ユニット・事業部毎にSlackのプライベートチャネルを作成し、その事業部に所属するメンバーしか投稿内容を閲覧できない様に管理・運用しています。勤怠連絡も事業部チャネル内で行っています

ですので、以下の様に、事業部毎にワークフローを設定すれば良いですね!
ワークフローの設定イメージ、その1

と油断していたら・・・
bravesoft、DD事業部長の古岡
DD事業部長の古岡からの依頼!
他部署と連携が密なプロジェクトに携わる部署だとこういう運用の方が良いですね!柔軟に対応しましょう!

また、勤怠連絡をした時にちゃんと送れたのか成功/失敗のステータスもbotで返事が返って来た方が親切ですね。
以下のような仕組みにしましょう。
ワークフローの設定イメージ、その2

以下のような使い勝手のものを作ります。
(1)自分の所属するユニット(事業部)のチャンネルのアクションから勤怠連絡ワークフローを開始し、必要な情報を入力・送信します。
勤怠管理ワークフローの操作イメージ1

(2)自分の所属するユニット(事業部)のチャンネルにワークフローから送信した内容が投稿され、勤怠連絡システムのBotから勤怠連絡申請登録の成功/失敗のステータスが返答されます。送信内容はGoogle Spread Sheet上の勤怠管理シートに追記されます。
勤怠管理ワークフローの操作イメージ2

これで勤怠管理ができるはず!

試行錯誤

実現方法を決めるにあたり、赤ちゃんなりに色々試行錯誤しました。
参考になるか分かりませんが同じ轍を踏む人がいそうなので、その主な原因を書いておきます。

【原因①】ワークフローから直接3rd Partyにデータ送信できない
試行錯誤した原因の1つは、Workflow BuilderからGAS(Google Apps Script)にデータを送る方法です。
SlackのAPI Referenceを斜め読みした赤ちゃんは、当初、以下の3つの送信手段を想定していました。

(1) Workflow Builderで作成したワークフローの中でSlash Commandsを実行してGASにデータを送信する
(2) Workflow Builderで作成したワークフローからチャンネルにメッセージを投稿する時に発生するイベントをEvents APIでハンドリングし、GASにデータを送信する
(3) Zapier等の外部連携サービスを利用してGASにデータ連携する

Slack Workflow Builder(ワークフロービルダー)で作ったワークフローから外部(3rd Party)にデータ連携する手段の想定

赤ちゃん的には(1)がベストプラクティスだと思っていました。

理由は必要十分なデータ(勤怠連絡ワークフローからチャンネルに投稿されるEvent Message)だけを外部に送信できる方法が(1)であるからです。
(2)(3)の手段を取ると勤怠連絡以外のイベントもハンドリングして不要なデータを送信することで、GASに対して無駄なリクエストを行い、最悪の場合GASの実行時間やスプレッドシートの書き込み・編集回数制限の上限に達し、業務に影響が出る恐れがあるので出来るだけ避けたいと思いました。
*ただ、(2)のケースに関してはSlackとGASの間に踏み台サーバーを噛ませる事で、不要なイベントメッセージをフィルター処理することが可能です。

さっそく、(1)の方法でワークフローからSlash Commandsをチャンネルに投稿してみました。
すると・・・
Slack Workflow Builder(ワークフロービルダー)で作ったワークフローからスラッシュコマンド(Slash Commands)は実行できない
Slash Commandsが実行されずに、通常メッセージとして投稿されますね!
念のため、Slack本社のサポートに問い合わせてみました。
すると・・・

Slash Commands are not available in Workflows sorry. It’s an interesting idea though and a request we’ve had from other developers too. I’ve shared your thoughts with the Workflows team for consideration in a future release.

ワークフローではSlash Commandsは使用できません。しかし、これは興味深いアイデアであり他の開発者からも要望がありました。今後のリリースを検討するために、ワークフローチームに意見を共有しました。

What you’re describing is the type of workflow the Events API is designed for. As you mentioned by subscribing to the message event when a message is posted in a channel your app’s request URL (your server) will receive a HTTP POST of data describing the event.

あなたがやりたいワークフローの使い方だとEvents APIを使うのが良いです。あなたの言う通り、Events APIを使ってchannelにメッセージが投稿された時のmessage eventを購読してください。

Your app (external to Slack) will need to parse the message event and determine if the message that has been posted is something your app needs to take action. For example: If the event payload contains “subtype”: “bot_message” and the username parameter is equal to the name of your Workflow eg. “username”: “My Workflow” then your app parses the text parameter and adds the data to the Google Sheet.

あなたのアプリでmessage eventを解析し、投稿されたメッセージがアプリでアクションを起こす必要があるものかどうかを判断する必要があります。
例:event payloadに”subtype”: “bot_message”が含まれ、usernameパラメーターがワークフローの名前と等しい( “username”: “My Workflow”)場合は、アプリがtextパラメーターを解析し、データをGoogleスプレッドシートに追加する、など

という回答が返ってきました。
残念ながら、ワークフロー内でSlash Commandsは叩けない様です。
(2)のチャンネルにメッセージを投稿する時に発生するイベントをEvents APIでハンドリングする方法が推奨だったので、この方法を採用します!

(3) Zapier等の外部連携サービスを利用してGASにデータ連携する方法でももちろん実装可能ですが、その実装方法については本記事では触れません。

【原因②】ワークフローからユーザー表示名をチャンネルに投稿できない
また、原因の2つ目は、プロフィールの氏名/表示名の設定に起因する問題でした。
遡ること2019年12月、Slackを導入し始めた頃にディレクターの宙蔵があることに気が付きました。

iOS版Slackアプリでは、ユーザー表示名が設定しないとメンションのレコメンドに名前が表示されないと気づいちゃった宙蔵

iOS版Slackアプリでは、ユーザー表示名が設定しないとメンションのレコメンドに名前が表示されない画面のスクリーンショット

この指摘には流石の赤ちゃんも「宙蔵やるやん」と思わざるを得ませんでした。
すると、取締役の清田から真っ先に返信があり。

Slackのユーザー氏名/表示名の設定を分ける様に指示するbravesoft取締役清田

氏名を日本語で設定すると、メンションをつける時に「半角英数変換で@を入力 => 全角ひらがな変換にする => 日本語で氏名を入力する」という手間が発生する
氏名を英語で設定するとメンションの可読性が下がる
* ベトナム・中国・韓国の社員の名前が英語だとマジ読めない!入力する時も英語の綴りが分からないことがある!

という問題に対する、氏名と表示名をそれぞれ設定するという改善案です。

清田どうかな?の裏に隠されたさっさとやれよ?というを汲み取った社員たちによって、迅速に社内Slackの運用ルールが取りまとめられ、全社員がプロフィールの氏名にアルファベット名表示名に日本語名を設定することになりました。

ユーザープロフィール設定画面で、実際に氏名・表示名を設定している例のスクリーンショット

どうも、赤ちゃんこと赤間です。
これにより、@の後にアルファベットを打てば、日本語名のメンションを探せるようになりました!(便利!)

氏名・表示名を設定したら、@を入れた後に、氏名・表示名のどちらを入力してもメンション先がレコメンドされるようになった画面スクリーンショット

しかしこの設定により後で苦しめられるとは、この時赤ちゃんも思っておりませんでした。
ワークフローでチャネルに投稿する内容を設定する時やユーザーの名前に関する変数の設定を行う時、「表示名」という選択肢が無いんですよね・・・。(名前を選択すると、表示名ではない方の氏名になります)

Slackワークフローでユーザーの表示名を投稿内容に設定できない画面のスクリーンショット

もういっそのこと名前も自由なテキスト入力にしちゃおうかな、むしろもうメールアドレスでも良いかもなと諦めかけながら技術戦略本部長の間宮に相談したところ、

表記揺れを絶対許さない技術戦略本部長の間宮

との返事。
そうなんですよね。
勤怠管理で誰が遅刻・早退・半休・全休を何回ずつ行ったのか月次で集計しますね。
勤怠連絡の申請者の名前って集計のキー項目なので、表記揺れすると勤怠を集計するCC本部(人事部)の手間が増えます

ここで技術戦略本部長に逆らうとエンジニアとしてのキャリアが終了してしまいそうなので、ユーザーを特定する為の情報としてメールアドレスを使うことにしました。そのままユニークなキーになりますからね、メールアドレス。
Google Spread Sheet上に用意した社員名簿を変換テーブルとして使い、メールアドレスを氏名に置換することに決めました。

(2020/03/29追記)GSuiteで社員のアカウントを管理している場合、変換テーブルを用意しなくても、Directory APIでメールアドレスをクエリーパラメータに指定したユーザー検索が可能です。

概要仕様

前置きがだいぶ長くなりました。
今回の勤怠管理システムの概要は以下の図の通りです。

Slack Workflow Builder(ワークフロービルダー)で作成したワークフローから外部(3rd Party)のGoogle Spread Sheet(スプレッドシート)上の勤怠管理シートに連携する勤怠管理システムの概要
実際の作り方を紹介していきます。

Workflow Builderの設定

ワークフローの全体の設定は以下の通りです。
チャンネルのアクションメニューで起動し、入力フォームを立ち上げ、入力された内容をチャンネルに投稿します。
Slack Workflow Builder(ワークフロービルダー)で設定した勤怠連絡ワークフローの流れ

入力フォームの設定内容は以下の通りです。
勤怠連絡の申請者の「氏名(表示名)」に関しては、入力させる必要がないので、入力欄を設けていません。(アクションメニューから勤怠管理ワークフローを開始した人の情報を利用します)
「所属部署」「勤怠種別」に関しては、勤怠連絡を月次で集計する際のキー項目になるので、表記揺れが発生しないように選択式にしています。
「理由」集計のキー項目ではないので、自由記述のできるテキスト入力フォームにしています。
Slackワークフローの勤怠連絡用の設定その1

入力フォームからデータが送信されたら、以下の形式でデータをチャンネルに投稿します。
Slackワークフローの勤怠連絡用の設定その2
@可変ユーザー ( 可変テキスト )の部分は、括弧の前後に半角スペースを入れてます。
以上のワークフローを勤怠連絡する全てのチャンネル分作成します。

Google Apps Scriptを作成

事前に勤怠管理シート(Google Spread Sheet)ログファイル(Google Document)を作成しておきます。

勤怠管理シート(Google Spread Sheet)上には、以下の様な「社員名簿」シートを追加しておきます。
A列にメールアドレスB列に氏名の社員名簿です。

社員名簿シートのサンプル画像

そして、Google Apps Scriptに実際に書いたソースコードは以下の通りです。

このGASの設定で気を付けるべきポイントは以下の4点です。
ポイント① : 権限アカウントを一致させる
(1)勤怠管理シート(Google Spread Scheet)の編集権限を持つアカウント
(2)ログファイル(Google Document)の編集権限を持つアカウント
(3)Google Apps Scriptの実行権限を持つアカウント
が全て一致している必要があります。
ポイント② : データへのアクセス権限の許可を確認する
Google Apps Scriptを書いたからと言って、油断してはいけないんです。(赤ちゃんは油断しました。)
以下の手順を踏まないと、何だかよく分からないけどGoogle Spread SheetやGoogle Documentにデータが書き込めない!という事態に陥ってしまうので気をつけましょう。
doPost関数を一度実行し、Googleのデータへのアクセスの権限の許可を確認しましょう。

doPost関数を一度実行し、Googleのデータへのアクセスの権限の許可を確認する

アカウントを選択し、データへのアクセスを許可します。
Google Apps ScriptにGoogleのデータへのアクセスを許可する設定
以上でアクセスできるようになります。

ポイント③ : Google Apps Scriptを修正・変更したら新しいバージョンとして公開する

修正を加えたら、その都度公開してください。その際バージョンはNewを選択し、Who has access to this app(このアプリへのアクセス権限)はAnyone, even anonymousを選択し、Deploy(適用)してください。
Google Apps Scriptを公開する時は、必ずNewして欲しいし、アクセス権限はAnyone, even anonymousにして欲しい

すると、Google Apps Scriptのエンドポイントにリクエストを送る為のURLが払い出されます。
Google Apps ScriptのエンドポイントのURL

Glitch上のWEBアプリからGoogle Apps Scriptにデータを送る時に使うので、メモしておいて下さい。

ポイント④ : 重複書き込みの解決方法は、書き込んだ後に消すアプローチが良い
何らかの原因でGoogle Spread Sheetへのデータの重複書き込みが発生する場合がたまにあります。(恐らくGlitchからのPOSTリクエストが短いスパンで重複リクエストで来る時がある?)
既に同じ内容の書き込みがあるか重複チェックして制御しようとすると、チェック処理のスピードより重複リクエストのスピードの方が速く、あっさり書き込まれます。
ここは諦めて、書き込んだ後に重複行を削除するアプローチが良いと思います・・・。

踏み台サーバ@Glitchに中継アプリケーションを作成

そもそもGlitchって何やねん」とお思いの方もいると思うので、簡単に紹介します。
Glitchは、サーバーレスでNode.jsのマイクロサービスを立ち上げられるWeb IDEサービスです。自分でサーバー立てたりしなくても、WEBアプリケーションサービスを公開できます。

Glitchのコード編集画面のスクリーンショット

赤ちゃんも、Slackの中の方の記事「Slack API 新機能の Block Kit を使ってより情報的なレストラン検索コマンドを作ろう」を読んで、Glitchの存在を初めて知りましたが目からウロコでした。

Glitch無料で使えますが、制限事項があります。

(1) 匿名ユーザによって作成されたプロジェクトは5日で消滅します。(* 無料アカウント登録してログイン後にプロジェクトを作れば消滅しません。)
(2) 5分以上利用されていないプロジェクトはスリープ状態になります。(* スリープ中でもエンドポイントにデータを送ると自動で起動します。)
(3) リクエストの上限は、1時間あたり4,000件です。(* 上限に達すると、エンドポイントへのリクエストに対して、429 Too Many Requestsを返却するようになります。)
(4) 1プロジェクトあたり128MBのディスクスペースがコンテナ上に用意されます。
(5) プロジェクトのファイルツリーに表示できるファイル数は100までです。(* ファイルそのものが存在できないわけではないです。)
(6) プロジェクトのファイルツリーには200KBを越えてファイルを表示することはできません。また、200KBを超えるデータをエディタに貼り付けることもできません。

無料なのに、結構ガッツリ使えそうですね!
今回の弊社の件だと、社員全員で1時間に4,000件も事業部チャンネルに投稿をしないので、問題なさそうだと判断しました。

さっそく、Glitchで勤怠管理アプリケーションを立ち上げよう!
サンプルのソースコードはこちらです。

事前にGlitchのサインイン画面SNSログインするかアカウント作成を行ってください。
その後、ご自身のアカウントでログインしている状態で、Glitch勤怠連絡システムのサンプルコードのプロジェクトをRemix to Edit(Fork)して、ご自分のプロジェクトを作ってください。

プロジェクトは、ランダムな名前のプロジェクト名で自動生成されます。
画像の赤枠内の部分がプロジェクト名になります。
Glitchのプロジェクト名の例

Glitchにリクエストを送信する際のエンドポイントのURLは、https://{{プロジェクト名}}.glitch.me/{{エンドポイント}}になります。
上記の画像の例だと、プロジェクト名はpolite-casquette-pbigvww6oqです。また、エンドポイントはソースコードのindex.jsの中の/commandの部分です。(プロジェクト名・エンドポイントは任意に変えられます)

ですので、この例だとhttps://polite-casquette-pbigvww6oq.glitch.me/commandがGlitchのエンドポイントのURLになります。
ご自分のプロジェクトのエンドポイントのURLはSlackのアプリ側の設定に使いますので、メモしておいてください。

実際のソースコードの修正箇所についてですが、index.jsの部分は特に変更せずに、.envファイルの中の以下の環境変数に値を設定するだけで動くはずです。

.envファイルに記載した環境変数は、同プロジェクトの編集権限を持つユーザー以外、閲覧できない様になってます。SlackやGoogle Apps Secript等の認証情報はこちらの環境変数に定義するのが安全ですね。

今回設定している環境変数は、以下の4つです。
(1)SLACK_SIGNING_SECRET : Slackで作成したアプリのSigning Secretを設定してください。
(2)SLACK_ACCESS_TOKEN : Slackで作成したアプリのBot User OAuth Access Tokenを設定してください。
(3)SLACK_WEBHOOK_URL : Slackで作成したアプリのIncomming WebhookのURLを設定してください。
(4)GOOGLE_APPS_URL_KINTAI : Google Apps ScriptのエンドポイントのURLを設定してください。

このアプリの設定の気を付けるべきポイントは以下の2点です。
ポイント① : 二種類の通知を使い分ける
システムエラーの通知の様に、常に固定のチャンネルに通知を投げる時は、Slack Incomming Webhookを使いましょう。
勤怠連絡のOK/NGステータスの返答の様に、動的に通知先のチャンネルを変更したい時は、通知先のチャンネルをURLパラメーターで指定可能なchat.postMessage APIを使いましょう。

ポイント② : chat.postMessageのURLパラメータに注意
chat.postMessage APIのURLパラメータの必須項目に、tokenchanneltextがあります。通知メッセージの内容を設定するtextパラメータの値だけ、URLエンコードする必要があるので注意して下さい。

Slack Appの設定

SlackのYour Appsから設定ができます。

Signing Secretを環境変数に設定する
アプリを追加したら、まずはSlackのアプリ毎に採番されるSigning Secretをコピーして、Glitchのアプリケーションの.envファイルの環境変数SLACK_SIGNING_SECRETに設定して下さい。
SlackのSigning Secretを環境変数に設定する

Glitch内のverifySignature.jsの中でSLACK_SIGNING_SECRETを使った認証チェック処理を行い、不正なリクエストを防ぐために使用します。

Incomming Webhookを有効化する
システム通知用のチャンネルに勤怠システムのエラー通知を行う為のIncomming Webhookを作成します。
Add New Webhook to Workspaceから、通知先のチャンネルを選択し、追加してください。
SlackのIncomming Webhookを追加する

作成したIncomming WebhookのURLをコピーして、Glitchのアプリケーションの.envファイルの環境変数SLACK_WEBHOOK_URLに設定して下さい。

SlackのIncomming WebhookのURLを環境変数に設定する

Event Subscriptionsを有効化する
続いて、Event Subscriptionsを有効化します。
Request URLには、Glitchのエンドポイントにアクセスする為のURLを記載します。

Glitchのエンドポイントの情報を記載する

URLの初回登録時にエンドポイントへの導通確認をする為にchallengeというパラメータを含むevent messageが発行されますので、Glitch側のアプリケーションでは以下の様な処理でevent_type : url_verificationの時に中身の challengeだけSlackに返却してあげてください。

認証に成功すると、設定画面にVerifiedと表示されます。
続いて、Subscribe to bot eventsで、ハンドリングするイベントを追加します。
今回は、プライベートチャンネルのメッセージが投稿された時のイベントであるmessage.groupsと、念のためパブリックチャンネルのメッセージが投稿された時のイベントであるmessage.channelsを追加しましょう。
追加したら忘れずにSave Changesで保存します。
SlackのEvents APIでハンドリングするEventの種類をSubscribe to bot eventsで追加する

すると以下の様なメッセージが表示されるのでreinstall your appをクリックして、再度アプリをエラー通知先のチャンネルにインストールし直しましょう。
再度Slackのアプリをチャンネルにインストールし直す

BotのOAuth Access Tokenを設定
OAuth & PermissionsBot User OAuth Access Tokenがあるので、コピーしてGlitchのアプリケーションの.envファイルの環境変数SLACK_ACCESS_TOKENに設定して下さい。
勤怠申請の成功/失敗ステータスをチャンネルに返答する際に使うchat.postMessage APIのURLパラメータの必須項目のひとつである、tokenの値として設定する必要がある情報です。
Bot User OAuth Access Tokenを環境変数に設定する

作成したアプリは管理対象のチャンネルでインストール
最初にインストールした通知用のチャンネル以外に、勤怠連絡を行うチャンネルにもアプリをインストールする必要があります。忘れずにインストールしましょう。
Slackのアプリをチャンネルに追加

動作確認

おもむろにテストしてみたら、ちゃんと動きました。わーい!
勤怠連絡システムを動作確認してみたらちゃんと動きました

あとがき

勤怠システム導入後
2020年1月初旬に導入してから運用して2ヶ月弱になりますが、申請時のバリデーションエラーやシステムエラー等は1件も起こっていないです。今のところ安定して動いてるんじゃないかなと思います。

拡張性
EventsAPIを導入して投稿イベントがハンドリングされているチャンネルからは、常にmessage eventが流れて来ますので、今回作成したGlitch上のアプリケーションをmessage eventの連携先を分岐するハブの様に使うと拡張性があると思います。Glitchのプロジェクトのエンドポイントの中に以下の様な条件分岐を増やしていけば、簡単に連携先を増やしていけると思います。

課題
課題は、Google Spread Sheetの社員名簿を手動更新で管理していることです。自動更新にするか、不要にしたいですね。Googleのチームに所属しているメンバーの名前・メールアドレスの一覧をGASで定期的にGoogle Spread Sheetに出力するか、Slackのメンションから取得可能なユーザーID(data-member-id)を使って表示名を取得する、という処理が実現できれば解決できそうなのですが、もし実現方法ご存知の方いたら教えてください!

(2020/03/29追記) Directory API で解決できました!

Slackへの期待
以下のアップデートを期待しています!
(1) ワークフローでSlash Commandsを実行できるようにして欲しい!
理由① : EventsAPIを使う場合と、向いているユースケースが違う気がするから

Channel : 3rd Partyが 1 : N の時、EventsAPIを使うのでも良いと思います。
Channel : 3rd Partyが N : 1 ないし N : N の時、Slash Commandsで必要十分なデータをevent messageとして送るのが効率的だと思います。

理由② : 既存のSlackアプリと連携可能なワークフローを作れるから

BacklogWrikeなど、様々な業務効率化ツールがSlackからSlash Commandsで実行できるアプリを提供しています。これらがSlackのワークフローから実行できたら便利だと思います。

(2) ワークフローのカスタムフォームの選択方式を増やして欲しい!
理由 : ユーザーの入力が簡便化される、入力ミスを減る、ことでユーザビリティが向上するから

特に、日付形式(Date Picker)複数選択(Multitude Selector)など。
テキスト入力形式だと表記揺れが発生し得る入力項目や、フォームの制約(設問が最大10個しか登録できない等)によって実現が難しい入力項目に対応して欲しいです!

(3) ワークフローのカスタムフォームに入力バリデーション機能を付けて欲しい!
理由 : 入力バリデーションで入力ミスを防げるとユーザビリティが向上するから

正規表現で良いので、バリデーションルールを設定できるようにして欲しいです!
既存の業務効率化ツールのSlackアプリでも、Slash Commandsの引数に使える文字に制限がある場合が多いです。(入力項目がそのままそのサービスのURLクエリパラメータ等に使われることが多々あることも関係していると思いますが。)
Google Formの様な正規表現で設定できると非エンジニアの方も取っ付き易いかもです!

(4) ワークフローでユーザーの表示名もチャンネルに投稿できる様にして欲しい!
理由 : Slackユーザーの氏名をワークフローから3rd Partyにデータ連携する時に便利だから

日本語、中国語、韓国語などの2バイト言語を母国語とする国だとメンション入力の効率化を目的にプロフィールの氏名/表示名の設定を分けるケースがあるはずなので、必要だと思います!

Slackの中の方!ぜひ宜しくお願いします❤︎

★会社紹介★

私達bravesoft(ブレイブソフト)は「最強のものづくり集団」を目指し、
新しいものへの果てしない挑戦を日々繰り広げております!
その中で一緒に働いてくれる仲間も積極採用中ですので、是非お問い合わせください!

<基本情報>
bravesoft オフィシャルホームページ
採用情報
受託開発紹介
UI/UXデザイン紹介

<自社事業>
eventos
Live!アンケート
Appvisor Push

投稿者プロフィール

赤ちゃん

赤ちゃん
フロントエンドエンジニア
JavaScriptと黒ギャルが好きです