利用する立場で快適なSlackのスラッシュコマンドを求めて改善に着手してみた

はじめに

使い勝手のいいSlackのスラッシュコマンドは業務の円滑進行にとても役立ちます。ただ、他のやりとりが間に挟まらないようにするため、私個人としてはSlackBotや自身のDMチャンネル上にしています。

とある社内向けスラッシュコマンドの利便性向上を試みました。エラーになった場合は処理用のAWS Lambda関数ログをCloudWatch上で調査するのですが、単純にバグやネットワーク経路が原因のエラーなのか、コマンド要件に沿わないパラメータを渡されたとしてのエラーなのか、区別のつかないケースが多かったためです。

改善を図る際に検討した項目とそのうち具体的に行った項目を、記録として残してみることにします。

よいスラッシュコマンドとは

ものすごくふわっとした問いになりますが、個人的には以下の要件で考えています。

1. 読み取れる実行結果がレスポンスとしてかえされること
2. コマンドによる実行だと後からわかること
3. 正常に完了しなかった理由が推測できること
4. コマンド名の誤認を起こさないこと
5. 必要な引数に所謂Secretな文字列を求められないこと

満たしていない場合、1番目はバグとして、2番目は要件不足として扱われる可能性があります。3番目は作業工数の関係で割愛されやすいところです。4番目はその後追加される無関係なスラッシュコマンドが災いする可能性もあり、もらい事故的な面もありそうです。5番目はインシデントに繋がりかねません。

よいスラッシュコマンドへ昇華させてみる

上記を踏まえて対処していくことにします。

読み取れる実行結果がレスポンスとしてかえされること

他のチャンネルへ通知するつもりがされていない場合は、チャンネルを間違えていないか確認します。投稿したいのに上手く行っていない場合はAPIの利用を見直します。投稿した内容が人に解釈できない場合は、大体はmarkdownの失敗だったり、文字化けだと思われます。確認方法が検討つかない場合は、以下のプレビューを利用しましょう。

コマンドによる実行だと後からわかること

実行コマンドをSlackに投稿して残したい場合、API Gateway経由でAWS Lambda関数に渡しているのならeventから取得するように指定可能です。

>from urllib.parse import parse_qs


def invoke(event, context):
    payload_raw = event['body']
    payload = parse_qs(payload_raw)
    command = payload['command']
    text = payload['text']
    print(f"実行されたコマンド: {command} {text}")

取得したcommandとtextの組み合わせをSlackに通知するとよいでしょう。

正常に完了しなかった理由が推測できること

恐らく一番工数のかかるところです。手を付けるべき場所に迷う場合は、まずは以下の順に進めてみましょう。

1. 引数のバリデーション
2. 有効期限判定
3. 取得したいデータの有無

実装によっては難しいかもしれませんが、ポイントはtry ... exceptionでの例外ベースにて明確に想定外だとわかる状態にすることです。

コマンド名の誤認を起こさないこと

連想しにくい略称や、既存のコマンド名と類似するものは採用すべきでありません。システム名が短い場合はそのままコマンド名にするのがベターだと思われます。

必要な引数に所謂Secretな文字列を求められないこと

まずは、本当にSecretな文字列が必要かどうかを考えましょう。実行結果をコマンド実行した人に結びつける必要があるなら、文字列を渡すのではなく認証基盤を利用すべきです。利用者毎に異なる文字列をキーとして生成管理し、紐付け等で利用したいのであればAmazon Cognitoを用いる手もあります。

処理中にAPI認証等で固定の文字列が必要な場合は、引数ではなくコマンド処理内でAWS Secrets Manager等から取得する形にすべきです。

今回行ったこと

個人的に求める内容について書きましたが、今回行った対処としては以下の2項目になります。

• コマンドによる実行だと後からわかること
• 正常に完了しなかった理由が推測できること

他の要素は既に対処されていたり、認証にSecretな文字列ではなくGCPを利用する形となっていました。

あとがき

快適なスラッシュコマンドについて理想を求めてみました。本音としてはショートカットからの呼び出しやワークフロービルダーにて、文字列入力時の人力フォーマットのストレスから逃れたいところです。引き続き改善すべき課題として模索していこうと思います。