Slack上でのやり取りを元にBacklogへの起票を行いたい場合、現在は大きく3つほどの手段に分類できます。SlackとBacklogの直連携、Backlogチケット発行URLを直接開く、独自処理を挟む、辺りでしょう。いずれも一長一短があり、これが正解というものはありません。
チケット起票手段を見直すにあたり、これらの起案方法についてピックアップしつつメリットとデメリットの2面から整理してみました。
SlackとBacklogの直連携
Backlogアプリを介した仕組みを利用したものです。設定済みであれば**/backlog add**によって呼び出せます。
メリットは、Backlogを直接開かずにSlack内で操作を完了できることです。複数プロジェクトを活用している場合には課題の追加先プロジェクトを切り替えることができます。
ネックとなるのは、種別に設定したテンプレートが利用できない点です。テンプレート上に手順を掲載している場合等にはおすすめしません。また、公式に以下のような注意点が挙げられています。
プロジェクトのプルダウンリストは操作するユーザーが参加しているプロジェクトのみ表示されます。また、必須設定のカスタム属性を使用しているプロジェクトでは課題の追加ができないため、プルダウンリストにプロジェクトは表示されません。
Backlogチケット発行URLを直接開く
ブックマークの活用となります。URL構成は以下の通り。
https://<SPACE_ID>.backlog.jp/add/<PROJECT_ID>メリットは、対象とするプロジェクトが1つに限られている場合においてはアクセス以外に操作を求められません。連携の設定も不要です。Slackのチャンネル上部に関連ページとしての追加がおすすめです。
ネックはブラウザ上でBacklogページに繊維しての操作となるので、Slack内で完結しなくなる点です。
途中に中間処理を挟む
Slackにポストされた内容を外部からAPI経由で取得するか、SlackからSpreadsheet等に出力したものを加工、その後Backlog APIにポストする流れとなります。
メリットは途中で独自集計を行ったり、Backlog上へは保存方法がないデータ入力を設けた場合でも独自に管理できる点があります。
ネックとなるのは、SlackとBacklogのユーザデータ等を一致させる必要があるところです。中間処理にて双方のデータを参照してマッチングさせる手続きが発生します。また、SlackとBacklogのAPI双方で実行に影響のある変更が入った場合、それぞれに対して改修を入れる必要がでてきます。
起案方法の選択
起案方法の選択にあたっての指針は幾つもありますが、今回はSlack内完結・アクセス手順不要・ローコストの3点としてみました。
| Slack内完結 | アクセス手順不要 | ローコスト | |
|---|---|---|---|
| SlackとBacklog間連携 | ◯ | - | ◯ |
| チケット発行URL | - | ◯ | ◯ |
| 途中に中間処理を挟む | ◯ | ◯ | - |
サービス部ではSlackとBacklog間連携とチケット発行URLの2つを利用可能にしていますが、SlackとBacklog間連携はコマンドに慣れていることが前提もあり、ほとんどのBacklog問い合わせはチケット発行URL経由となっています。
あとがき
SlackとBacklogの2点を利用したチケット発行プロセスについて、明確に書き出した覚えがなかったので記事としてみました。
SlackとBacklogの連携によってチケット発行URLしかなかった頃に比べて便利になりましたが、個人的にはSlackでのコマンドライン実行はあまり手軽なものと感じておらず、メッセージを右クリックしてのショートカットがチャンネル毎に固定化できればと思っています。
