社内の申請・承認業務は、紙の稟議書だったり、Excel の申請書をメールで回したり、申請専用の業務システムに都度ログインしたり・・・という会社が少なくありません。

普段の連絡や社内の動きを把握するため Slack を活用していたと仮定して、「申請する」というひと手間のためだけに別のツールへ移動するのは、地味に手間がかかりますし、なにより煩雑ですよね。

当社では、この申請・承認フローを Slack 内で完結させる仕組み（アプリ）を開発し、導入支援を開始しました。

休暇申請、経費精算、稟議など、会社ごとに異なる申請フローを、フォーム入力から承認、通知まですべて Slack 上で処理できます。

今回はこの仕組みを例に、当社がどんな考え方で Slack アプリを作っているか、そして Slack アプリには実は複数の作り方があるということをご紹介します。これから何かしらの Slack 連携・業務効率化ツールを検討されている方の参考になりましたら幸いです。

目次

• 「定型の申請フロー」を丸ごと組み込める汎用エンジン
• サンプル
• 「作り方」が 2 通りある、という Slack アプリの面白さ
  • ① セルフホスティング版(Node.js + Bolt + Socket Mode)
  • ② サーバーレス版(Slack 公式の次世代基盤 / Deno Slack SDK)
• 2 通りの作り方を知っていることの価値
• まとめ

「定型の申請フロー」を丸ごと組み込める汎用エンジン

今回作ったのは、特定の 1 業務専用のアプリではなく、申請・承認という業務パターンそのものを汎用化したエンジンです。使い方は次のようにシンプルです。

1. Slack 上のメニューやチャンネルのブックマークから「申請する」を開く
2. 申請の種類(休暇申請・経費精算など、会社ごとに定義)を選び、フォームに入力して送信
3. 承認者に DM が届き「承認」「却下」ボタンを押すだけで処理できる
4. 「上長と経理それぞれの承認が必要」といった複数段階の承認が必要な申請は、次の承認者へ自動的にバトンタッチ
5. 最終承認・却下の結果が申請者に自動で DM 通知される

ポイントは、この一連の仕組みが特定の申請書フォーマットにひも付いていないことです。フォーム項目・承認ルート(誰が何段階で承認するか)・通知文面は、すべて定義データとして外出しされています。そのため、

• 「休暇申請」用に組んだ土台に定義を1つ追加するだけで「経費精算」も「稟議」も扱える
• 承認者を役職や部署で固定する、フォームの入力者に選ばせる、といった承認ルートのパターンも定義側で切り替えられる
• 会社によって異なる申請項目・承認段階数・通知文言に合わせて、コード本体を書き換えずにカスタマイズできる

つまり「1 社専用に作り込んだアプリ」ではなく、一般的な会社のほとんどの申請フローに当てはめられる型として設計しています。

サンプル

「作り方」が 2 通りある、という Slack アプリの面白さ

このエンジンは、同じ機能を持つ 2 つの実装方式で構築できます。

① セルフホスティング版(Node.js + Bolt + Socket Mode)

Slack 公式のアプリ開発フレームワーク Bolt を使い、Node.js サーバーとして自社のインフラ(VPS など)上で動かす方式です。スラッシュコマンドを起点に、自前のサーバーでロジックを処理します。

この方式の強み

• 既存の社内システム(勤怠管理 DB、会計システムなど)と自由に連携できる
• Socket Mode 接続のため、外部からアクセスできないファイアウォール内のネットワークでも動かせる
• サーバーの挙動やデータの持ち方を完全にコントロールできる
• すでに社内にサーバー資産がある場合、それをそのまま活用できる

② サーバーレス版(Slack 公式の次世代基盤 / Deno Slack SDK)

Slack が本格展開している、アプリのホスティング自体を Slack にお任せできる次世代の開発基盤です。TypeScript(Deno Slack SDK)でコードを書き、Slack CLI の slack deploy コマンドで Slack のインフラ上に直接デプロイできます。

この方式の強み

• サーバーの用意・保守が不要(コスト・運用負荷削減)
• コールドスタート、スケーリング、証明書更新といったインフラの心配ごとがそもそも発生しない
• 承認フローのような「人の操作を数日単位で待つ」非同期処理も、Slack の標準機能(カスタム Function・Datastore)で素直に組める
• 小規模〜中規模の業務アプリを、最短距離で・壊れにくく作れる

同じ「申請を承認する」という機能でも、①は「自社の資産と連携する自由度」を、②は「運用の手間をゼロにするお手軽さ」を優先した作り方になっています。

エンジンとしての設計(フォーム・承認ルート・通知を定義データとして外出しする考え方)は共通なので、どちらの方式で作っても会社ごとの申請フローに合わせたカスタマイズという価値は変わりません。

2 通りの作り方を知っていることの価値

Slack アプリ開発を依頼する側からすると、正直「どっちの技術を使うか」自体は本質的な関心事ではないはずです。大事なのは、要件に対して最適な選択肢を提案してもらえるかどうかですよね。

• 「社内の基幹システムとがっつり連携したい」「オンプレの DB を見に行きたい」→ セルフホスティング版が向いている
• 「まず 1 部署で小さく試したい」「サーバー運用の負荷をかけたくない」→ サーバーレス版が向いている
• 「将来的に他システム連携が必要になるかも」→ 最初はサーバーレス版で始めて、必要になったタイミングで自社ホスト型に段階移行する、という選択肢もある

当社では、同じ業務要件(申請・承認)を両方の方式で実装した経験があるからこそ、「この会社の場合はどちらが向いているか」を技術トレンドではなく実際の要件から判断してご提案できます。これは、片方の技術しか知らない状態では出せない価値だと考えています。

まとめ

申請・承認フローはどの会社にも存在する定型業務でありながら、フォーム項目も承認ルートも会社ごとに微妙に違います。

今回ご紹介した仕組みは、そうした違いを「コードの書き換え」ではなく「定義の追加・変更」で吸収できるように設計しており、なおかつホスティング方式もセルフホスティング・サーバーレスの両方から選ぶことができます。

• 「この定型業務、Slack の中で完結させられないか?」
• 「今使っている Bot を、もっと運用の手間がかからない形にできないか?」

上記のようなご相談があれば、ぜひお気軽にお問い合わせください。