JBUG大阪#9 Backlogで発揮できるホスピタリティの工夫

2026.05.21のJBUG大阪#9のユーザーセッションで紹介した資料です。

Transcript

1. 【JBUG大阪#9】 Backlogで発揮できる ホスピタリティの工夫 2026.05.21 株式会社TAM　伏見ゆず
2. 自己紹介 伏見　ゆず 株式会社TAMUNO　取締役 2015年　株式会社TAMへ。 Backlog歴＝社歴のウェブディレクター。 現在は大規模運用案件のPMをメインに、チームマ ネジメントや育成にも取り組んでいます。 プライベートでは3児の母として家庭のプロマネに も奮闘する日々。 仕事も家族も、大事なことはいつだって「愛」。 2
3. 会社紹介 株式会社TAM since 1992 3
4. 4 戦略立案支援 コンサルティング、プランニング 開発支援 クリエイティブ、開発 運用支援 運用支援、広告、SNS活用 デジタルのあらゆる課題に、 専門家がクライアントとチームとなって取り組みます。 サービス開発からリサーチ、企画、デザイン、運用まで責任をもって担います。
7. 本日のお題 『ミスと属人化を防ぐ、 　Backlogでつくるチームの仕事設計』 「属人化を防ぐ」ってどういうこと……？ 7
8. 属人化とは その人がいないと業務が滞る状態 　　　　　↓　↓　↓ その人がいなくても業務が回る状態 ……ハードル高くない？ 8
9. 属人化とは （その人に逐一教えてもらわなくても） 迷いなく、必要な情報に辿り着けて、 円滑にタスクが進められる状態 9
10. 属人化とは （こういう風にも言えそう） ちょうどいい感じで ボールのやりとりができる状態 10
11. 属人化とは 「ちょうどいい感じのボール」は、 ドッジボールじゃなくてキャッチボール 　　　　　↓　↓　↓ 相手が受け取れる状態にする＝ホスピタリティ 11
12. 属人化とは いい感じのボール 　＝（余計な）脳のメモリが食われない 12
13. 属人化とは 「迷い」は脳のメモリを食う 探す　思い出す　判断する　……etc. 13
14. 属人化とは 人は忘れる生き物 • いつも同じところで突っかかるとイラっとする • 同じことを何回も聞かれてもイラっとする • 3日前の自分ですら別人 イラッとするポイントをなるべく減らすように仕組み化する 14
15. 属人化とは 「迷い」が生じるポイントを減らす工夫 • 探す場所（範囲）が限定されている • 参照が必要な場所との行き来が少なくて済む • ボールを投げ返すまでのフローが自明 15
16. Backlogでできる工夫① Backlogの「属性」を活用する 16
17. 17 このへんのやつ Backlogの「属性」
18. 18 デフォルトは「シンプルな検索」 これで表示される属性は1軍 デフォルトでは「完了」は表示されない ※消えても構わない状態を「完了」とする 課題一覧の属性は表示・非表示は変更できるものがある（ちゃんと設定しよう） 課題一覧の「属性」
19. 19 属性は並び替えが可能 表示・非表示も切り替え可能 課題一覧の「属性」
20. 20 種別 状態 カテゴリー マイルストーン 課題詳細（本文）の「属性」
21. 21 状態 マイルストーン 課題詳細の属性の表示・非表示は変更できない＝ここを意識してカスタム 課題詳細（コメント）の「属性」
22. 22 属性：種別 • 種別ごとに「課題テンプレート」が設定できる • 定型のやりとりはテンプレート化しておくと便利
23. 23 起票後のフローまで記載しておくと マニュアル的に利用できる
25. 25 プロジェクト設定の「種別」から設定できる
26. 26 属性：状態 • 削除できない項目がある • 「完了」は一覧のデフォルト表示では表示されない
27. 27 起点は必ず「未対応」 終点は必ず「完了」
28. 28 属性：マイルストーン • ホーム画面に 「バーンダウンチャート」 が表示できる
29. 29 「開始日」「終了日」が設定できるので 期間に関わる項目を設定したいなら応用可能 例）請求タイミング
30. 30 属性：カスタム属性 • 必須項目化できる • コメントでは変更できない
31. Backlogでできる工夫② 他のツールと上手く使い分ける 31
32. Backlogでできる工夫② 32 • Googleドキュメント • Backlog ◦ Wiki ◦ ドキュメント • GitHub Issues • slack canvas
33. 他ツールとの使い分け 33 情報の「粒度」は取り扱いが難しい ……どれを使うべきか迷いがち
34. 他ツールとの使い分け 34 判断のポイント • ストック型／フロー型 • 課題を閉じた後に再利用する可能性があるか？ • 1画面でなるべく済ませられる（複数タブを移動しない） • 関与者の権限範囲 • 編集のしやすさ（編集履歴を追う必要があるか）
35. Backlogの工夫のキモ 35 カスタマイズの試行錯誤は軽薄に
36. Backlogの工夫のキモ 36 プロジェクトはナマモノである • 「100%完璧な状態」には到達しない • 最初から作り込みしようとしすぎるとつまづく • 複雑なカスタマイズは余計なコストになることもある
37. Backlogの工夫のキモ 37 余計なコストになる要因 • 迷いなくポチポチできるか？ • とりあえず判断保留することができるか？
38. Backlogの工夫のキモ 38 変更可能性を見すえて試行錯誤する • あとから設定を変更して致命的なエラーが生じないか？ • 他のツールへ移行できるデータ形式を意識する
39. Backlogプロジェクトのカスタマイズ 39 使い方を試行錯誤する ＝みんなが使いやすい状態を模索する →「ホスピタリティ」精神が発揮されている
40. Backlogプロジェクトのカスタマイズ 40 Backlogで「ホスピタリティ」 発揮していきましょう
41. おしまい 41