デバイス施工業務のワークフローを Deno Slack SDK で構築した話

こんにちは、株式会社 OptFit CTO室 の 宮地 です。

最近は空き家を購入しDIYに注力してしています。休日はDIY作業を行いサウナに入ることが一番楽しいです。

さて、本ブログでは社内で行っているデバイスの施工業務において、Deno Slack SDK を活用したワークフローシステムを構築し、業務改善を行った事例を紹介します。

「なぜ Slack Bolt ではなく Deno Slack SDK を選んだのか？」「どのような課題を解決したかったのか？」といった背景を中心にお話しできればと思います。

背景：自然言語による施工管理の限界

私たちのチームでは、現場作業担当者が行うデバイスの施工時に、オペレーターとの連携を Slack 上で行っています。これまでは、専用のチャンネルで「〇〇現場、デバイスID △△の設置完了しました。確認お願いします」といったように、自然言語（チャット）ベースでやり取りを行っていました。

しかし、現場の数が増え、関わる作業者が増えるにつれて、以下のような問題が顕在化してきました。

抱えていた課題

現状の課題点

1. 必須工程の抜け漏れ

   • どの現場でも必ず実施しなければならない「必須工程」がありますが、チャットベースだとどうしても個人の記憶や慣れに依存してしまい、確認漏れが発生するリスクがありました。

2. 情報の形式化と人為的ミス

   • デバイスIDやMACアドレスなど、システム的に形式化された情報を手入力（またはコピペ）でやり取りするため、入力ミスやフォーマットの揺らぎが発生していました。
   • これにより、後工程でのデータ登録時にエラーが発生するなど、手戻りの原因となっていました。

これらの課題を解決するため、「必須工程をシステム的に明確化」し、「形式的な情報の入力ミスを削減する」ためのワークフローシステムを導入する意思決定を行いました。

技術選定：なぜ Deno Slack SDK なのか

ワークフローを実現するツールは世の中に数多く存在します。SaaS型のワークフローツールや、Slack 純正のワークフロービルダー（ノーコード版）なども検討候補に挙がりましたが、最終的に私たちは Deno Slack SDK（次世代プラットフォーム）^[1]を採用しました。

採用に至った主な理由は以下の6点です。

1. 使い慣れた Slack で完結できる

現場の作業担当者にとって、新しいツールやアプリを導入・学習するコストは無視できません。すでに業務連絡の基盤となっている Slack 上で完結することは、UX の観点から非常に重要でした。

2. Git でコード管理（IaC）ができる

これがエンジニアとしては非常に大きなメリットです。GUI ポチポチで作るワークフローは手軽ですが、変更履歴の追跡やレビュープロセス（Pull Request ベースでの開発）に乗せることが困難です。
Deno Slack SDK であれば、ワークフローの定義自体を TypeScript で記述し、Git で管理できるため、品質担保と継続的な改善が容易になります。

3. 機能と柔軟性のバランス

よく比較対象に挙がる Slack Bolt (Node.js や Python などで動かすフレームワーク) と比較すると、Deno Slack SDK はプラットフォーム側の制約を受けるため、柔軟性という点では劣る部分があります。
しかし、今回の要件である「定型的な入力フォームの提示」「必須項目のバリデーション」「外部システムへの簡易的な通知」といった機能に対しては、現状の SDK の機能で十分であると判断しました。

4. サーバーレス（Slack ホスティング）

Slack Bolt を採用する場合、AWS Lambda や Heroku、Google Cloud Run などのインフラを自前で用意・管理する必要があります。
一方、Deno Slack SDK は Slack のインフラ上でコードが実行されるため、サーバーの構築やメンテナンスが一切不要です。インフラ管理コストをゼロにできるのは大きな魅力でした。

5. デプロイの容易さ

開発体験（DX）も優れています。Slack CLI を使用すれば、以下のコマンド一つでデプロイが完了します。

$ slack deploy

CI/CD パイプラインへの組み込みも容易で、開発サイクルを高速に回すことができます。

6. サンドボックス開発環境

Slack Developer Program に参加することで、開発用のサンドボックス環境を利用できます。本番環境（プロダクションワークスペース）を汚すことなく、安全に試行錯誤できる環境が提供されている点も採用の後押しとなりました。

構築したワークフローの概要

今回作成したワークフローは、単なるフォーム入力ツールではなく、Slack Datastore を活用して施工の状態を管理するインタラクティブなアプリケーションとして実装しました。

具体的な処理フローは以下のシーケンス図の通りです。

ワークフローの設計ポイント

実装上のこだわりポイントは以下の3点です。

1. Datastore によるステートフルな管理

   • 単発のイベントで終わらせず、Datastore に入力データを一時保存・永続化しています。これにより、「デバイス登録」→「関連コンポーネント登録」といった依存関係のあるデータ処理を実現しています。

2. ビジネスロジックによるバリデーション

   • 「関連コンポーネント登録」のフェーズで示されている通り、「親デバイスが登録されていないと子コンポーネントを登録できない」といった整合性チェックを Handler 側で行っています。これにより、現場での入力ミスや順序間違いをシステム側で防ぐことができます。

3. インタラクティブな UI/UX

   • Slack の Block Kit を活用し、初期メッセージを投稿した後、ボタン操作によってモーダルを出し分ける設計にしました。
   • 「確認依頼」フェーズでは、担当チームへのメンションと同時に「完了/取消」ボタンを提示することで、チャット上での承認フローをスムーズに完結させています。

まとめ

Deno Slack SDK を採用したことで、インフラ管理の手間をかけずに、Git 管理可能な堅牢なワークフローを素早く構築することができました。 「チャットツールの延長」として使える手軽さと、「エンジニアリングによる管理」のメリットを両立できるこの選択肢は、社内業務改善の有力な手段だと感じています。

今後は、入力されたデータを元にバックエンドシステムとの連携をさらに強化し、疎通確認の自動化などにも取り組んでいきたいと考えています。

脚注

1. Deno Slack SDK とは: Slack の次世代プラットフォーム向けに提供されている SDK です。TypeScript を用いて、Slack 上で動作するカスタムファンクションやワークフローをコードベースで定義・構築できます。作成したアプリケーションは Slack のインフラ上でホスティングされるため、別途サーバーを用意する必要がありません。Getting Started | Slack Deno SDK