Slack Workflow Builder使った年休申請やリリース通知の例


※この記事は自分が所属する組織で書いた以下の記事のコピーです。投稿した記事は個人の著作物として自ブログにコピーして良いルールとしています。

https://tech-blog.mitsucari.com/entry/2025/03/26/184503


Slack

こんにちは、ミツカリCTOの塚本こと、つかびー(@tsukaby0) です。

突然ですが、みなさんはSlackのWorkflow(Builder)機能を使っていますか?

https://slack.com/intl/ja-jp/help/articles/16583775096083-%E8%87%AA%E5%8B%95%E5%8C%96---Slack-%E3%83%AF%E3%83%BC%E3%82%AF%E3%83%95%E3%83%AD%E3%83%BC%E3%81%A8%E3%81%AF

何らかの申請や処理フローなどをSlack上で構築できる機能です。マネージドとしてデフォルトで用意されているものもあれば、Workflow Builderで自作することもできます。

ミツカリでは創業当初からずっとSlackが使われてきており、フルリモートの会社ということもあってSlackが職場という状況です。日々の相談、たとえば年次有給休暇の取得相談などもSlackで行われており、そのような定型業務の際にWorkflowは力を発揮します。

今回はミツカリの社内でWorkflowを使っている一例や課題、将来の展望をご紹介します。

Slack Workflow導入の背景

私は創業メンバーではありませんが、かなりの古株でミツカリは7年目になります(2025年時点)。スタートアップはいろいろなものが整っていません。そのため、ルールや運用を自分たちで創っていくという楽しさがあります。

何らかの定型業務のルールがWiki等で定められていないということはよくあります。これは別にスタートアップに限った話ではないですが、そのようなものは少しずつ整えていく必要があります。

例えば年次有給休暇の申請ですが、弊社では以前は特に明確なルールが定まっていませんでした(弊社はマネーフォワード勤怠を利用しており、そちらで申請するルールはありましたが)。そこから #kintai チャンネルで申請・報告するルールが生まれましたが、これには以下の課題がありました。

  • 直属の上長が年次有給休暇の取得を許可するという承認フローが無い (マネーフォワード勤怠の方で労務担当者が承認するフローはある)
  • 上長が承認したかどうかという証左が残らない (一応OKスタンプが承認である、ということにはできるが)
  • 各自申請するフォーマットがバラバラでまれにミスコミュニケーションが発生する
  • チャットのログを辿れば良いものの、今週は誰がいつ休むのか、といった情報が分かりづらい

※ちなみに年休だけでなく、休出申請も同様です。

そこでSlackのWorkflow Builderで解決できるのではと思い、試験的に導入してみることにしました。

Slack Workflow Builderで年次有給休暇の申請ワークフローを作る

Workflow Builderはいわゆるノーコードツールで、非プログラマでも扱えます。以下では弊社の例をご紹介します。

SlackのUI上でWorkflow Builderを起動し、新規作成から以下編集画面で設定を行います。

起動条件は Starts from a link in Slack としています。これによって、Slack上で特定のリンクを踏むとワークフローを開始できるようにしています。実際にはSlack #kintai チャンネルのWorkflowフォルダに登録をしているので、そこから開始する事が多いです。

1つめのステップは Collect info in a form としてテキストと上長を選択してもらいます。テキストは自由形式としており、 4/1 に年休取得させていただきます など、自由に入力してもらっています。このあたりは改善点ですが、課題は別途最後にまとめます。

WorkflowではSlack userを選択するinputを用意できますので、ここで大抵はCEOであったり、CTOが選ばれます。

2つめのステップは Send a message to としています。ここでは #kintai チャンネルに投稿を行い、前のステップで選択された上長にメンションが飛びます。上長は承認ボタンを押しますが、場合によっては取得時期をずらせないか相談します(※現時点までで取得時期変更の相談がされたケースはないです)。

3つめのステップは Reply to a message in thread です。同じメッセージにスレッド形式で投稿を行います。これは承認ボタンが押されたら動く、という条件づけがなされています。承認された場合は従業員は以下の3つの作業を行います。

  1. マネーフォワード勤怠で年休の申請を行う
  2. 自分のGoogleカレンダーに 不在 を設定して、ミーティングが設定されないようにブロックする
  3. 社員全員で共有している ミツカリ社員勤怠 に終日カレンダー登録を行い、同僚に対して休む日を共有する

ワークフローはこれで完成です。後はこれをPublishして、 #kintai チャンネルから使うだけです。それとは別にSlackとGoogleカレンダーを連携しておき、ミツカリ社員勤怠Googleカレンダーの予定を毎日投稿するようにします。

実際の使用例

ワークフローを開始して情報を入力します。

Slackに通知が来るので、承認者は承認ボタンを押します。

※画像の例では既にボタンが押されています

運用してみた所感

Goodポイント

  • 承認したという証左がSlackに残るようになった
  • 申請したときにどのような作業が必要かをSlackメッセージで指示されるので、頭を使う必要がなくなった。Slack Workflowを使うということだけ覚えておけば良い
  • (Googleカレンダーによる功績が大きいが、)誰がいつ不在なのか明確になった。来週はAさんとBさんが休みだから定例会議を延期しよう、というような意思決定がしやすくなった

Badポイント

  • 以前の運用ではGoogleカレンダー登録という作業はなかったが、その作業が増えてしまったため、申請者の負担になっている
  • フォーマットが自由という問題点はあまり解消されていない

改善点

まだまだ改善点はありますが、これ以上の開発コストを私が負うことができないので見送っています。具体的には以下のような改善を行いたいと考えています。

  • フォーマットを固定化し、自由入力のテキストではなく、日付形式とする。このとき単一の日付ではなく、複数入力や範囲指定、午前年休など柔軟に対応できるようにしたい
  • あるいはフォーマットは自由化するが、何らかの機械学習等のAIによって日付を上手く特定できるようにしたい
  • そのうえでカレンダー登録を自動化したい
  • また、マネーフォワード勤怠に自動で申請したい。しかし、そのようなAPIは提供されていない
  • 理想的にはWorkflowを独自構築するのではなく、マネーフォワードなどの何らかのワークフローサービスを使って構築すらなしで対応したい。しかし、現状ではマネーフォワード勤怠はGoogleカレンダー連携機能やSlack通知機能を有していない
  • 社員が増えた場合、ミツカリ社員勤怠カレンダーやSlackのカレンダー予定通知などの量が増えてしまうため、見づらくなってしまう

今後課題が深刻になってきた場合や、より良いアプローチを見つけたときに改良していきたいと思います。

ただ、自分で作る必要は無いかなとも思っています。これは私の予想ですが、今後10年以内には勤怠管理の操作を行うMCP Serverが登場し、それをSlackやTeamsから利用できるという勤怠管理システムが登場すると思います。それをマネーフォワードが実施するかは分かりませんし、そういうスタートアップが出てきても結局はマネーフォワードに勝てないから流行らないということもありえそうです。ただ、このような低難易度のオペレーションは簡単にAIが実施できる世界はもう目の前まで迫ってきているため、今後はもっと簡単にワークフローを構築できそうだと思っています。

その他のWorkflow、リリース通知の例

年休申請を皮切りに今では他にも色々なワークフローが登場しています。

例えばリリース通知は以下のようなワークフローとしています。

基本的には年休申請と同じですが、Spreadsheetに記録を残すようにしています。これは証左としての意味合いもありますが、何らかのインシデントや障害があったときに、どのリリースによるものなのかを特定するために利用したりもします。

もちろんこれも完璧ではないと思っています。例えばこのリリース通知はシステムの何らかのリリース作業後に実施するものですが、その作業の途中でGitHub PRを作成しており、そこには同じような内容が書かれています。つまり二重になっており、無駄があります。他の開発チームでは、GitHub Releaseを作成して、非開発チームもそれを見る、などの運用にしているところもあります。そのような方法のほうが良いかもしれませんし、このあたりはまだまだ改善の余地があると思っています。

余談

余談ですが、これらのワークフローは現時点で全て私が作成しました。私が好きでやったものだったり、チームの改善としてやったものだったり、理由は様々です。開発部長・CTOである私がやるべき仕事だったのか、スタートアップという状況下で本当にやったほうがよいことだったのかについては疑問が残ります。この記事を書いていて、今後は徐々にこのようなタスクもメンバーに任せて行きたいと思いました。


現在、ミツカリではITエンジニアを募集しています。興味のある方はぜひお気軽にご連絡ください!開発だけ、インフラだけ、というような仕事ではなく、フルスタックとして、DevOpsを意識して色々な仕事をしたい!という方には向いている環境だと思います。よろしければぜひ私とお話しましょう。フォローもお待ちしております。

@tsukaby0

https://herp.careers/v1/mitsucari