想定する読者層
- BackLogのWikiを使っていない状況でBackLogチケット上から運用の周知を行いたい
チケット管理用サービスあるいは機能で悩ましい要素の一つに、該当サービスや機能を使う上でのルールやアナウンスへの誘導があります。これはよく使われるGitHub Issues、JIRA、BackLogのいずれにも言えることでしょう。
GitHub Issuesをチケット管理に用いる場合はコントリビューションガイドラインが役立ちます。JIRAであればダッシュボード上での共有にて対応できます。個人的に手強いのはアクセス頻度の高いダッシュボード内に独自ガイドラインへの導線が仕込めないBackLogです。WikiはNotionとの二重管理になることから活用していません。
現在BackLogを利用する上で行っている運用周知について、社内向け認知も含めて書き起こしてみました。
BackLogチケット発行手続きを通して周知させる
Wikiを使わない場合の周知プロセスは非常に限られます。BackLogダッシュボード上にはユーザが自由にリンク等の導線を差し込むことはできません。公式ヘルプにも特に記載がないので、そういうものなのでしょう。
代替手段を、開発室へ依頼するスタッフが共通して操作する手順上にあり、且つ開発室から自由記述できる何らかのスポットに差し込む必要があります。確認した限り、該当箇所は恐らくチケット発行時のみです。
種別毎のテンプレート作成には中々手が伸びないかもしれません。当初開発室もチケット内の欠落するコンテキスト補完を逐次コメントで促していましたが、効率目的でテンプレートによる必要項目強制を始めました。効果は目に見えて現れたため、最終的に全ての種別に対して反映しました。
現在は特定テンプレート最初の行にBackLogチケット発行手順を記載したNotionページへのリンクも載せています。発行手続きを認識している前提にてチケットを作成してもらうため、何らかのアクションを開発室から起こす際はNotionページ内に記載されているルールに沿って行う形としています。
依頼者の視点ではBackLogの中で恐らく一番目にする時間の長い画面になる可能性もあり、テンプレート上への記載を見落とす可能性は低いはずです。
注意すべき点
テンプレートへの手続き記載は量に気をつける必要があります。増えすぎると、チケット発行手順に関する説明なのか、チケット内容そのものなのか、見分けつきにくいのが難点です。
また、テンプレート内のURLはクリッカブルにはならないため、依頼者はプレビュー状態でクリックするか、ブラウザのURLへコピーペーストする必要があります。投稿した後リンクに気がついた場合でも、次回のチケット発行で役立ててもらえれば問題ありません。
プレビューにした際にクリック可能なURLであることに気が付かない可能性を考慮して、MarkdownのURL機能は利用していません。以下、比較のためにURL機能を利用有無の例です。
あとがき
BackLogでの手順や独自ルールの周知をBackLogチケット発行時に試みようとすると、予想以上に骨が折れます。事前に手順を常に読んでもらえるのがベターですが、毎回取説付きでの操作は誰もが面倒なものです。読んでなくても読んだことにする人もいることでしょう。
ですが、周知に関する取り組みをやめた場合、後には解消し辛いチケットの山や、本当に時間の掛かる棚卸し作業が発生することになります。一気に改善することはないでしょう。継続しての取組が重要です。
13
