Backlogをどう利用しているか

1. Backlogでわかる炎上の見分け方、消し方
リビルド
藤崎 優

2. • 藤崎 優
• 株式会社オルターブース所属
• 業務執行役員COO
• 最近やってること
• 福岡市粗大ごみ収集LINEBot
• 某社の案件のディレクション
• JAWS-UG福岡コアメンバー
(#jawsugfuk)

7. 福岡市粗大ごみ収集LINE bot

8. 本日の内容
• 受託開発でBacklogを使ってどうマネージメントしているか？
• Backlogで炎上を見分けて消せる？

9. ここで話した内容です！！！

11. 案件スタート時のチケット数
・・・マジ？

12. やってます！

13. なぜ最初に大量の課題作成をするの
か？

14. 受託開発で顧客と共にアジャイル開
発を行うため！

15. 要件定義と設計・開発が平行して行
う

16. ここでネックになるのは全体像が見
えないことを不安に思われること

17. そのためにやることは？

18. 案件の作業量の見える化

19. そのためにやることは？

20. 最初に想定しうる作業をすべてチ
ケット化する!

21. 実際には不要になるチケットも当然ある

22. 追加されるチケットもある

23. 1チケット1日∼3日を想定

24. 初期のチケットは埋めていく箱として使う
（内容の詳細はこの時点では記載しない）

25. 案件の作業量の見える化の目的

26. やるべき作業のゴールを仮で作る

27. リリースまでの作業日程は全て入れる

28. アジャイルなので要件が固まっていないもの
もあるが、作るべき機能を想定し、チケット
化

29. この時点でリリースが完全にオーバーするこ
ともある

30. これをやると良い点

31. スタート時点でのゴールを共有できる

32. 初期の段階で、開発機能の調整ができる

33. 機能を削るか、想定した要因から追加を行う
か

34. 進んでいく中でどうしても入れたい機能、捨
てても良い機能の調整ができる

35. なぜここまで最初にやるのか？

36. 炎上を発生させないため

37. 炎上が起こるの大きな要因は？

38. 受託側と発注側のゴールの認識のずれ

39. 機能開発におけるボリュームがわからない

40. 最初にチケットを登録すると？

41. ゴールの認識をあわせられる

42. 追加・変更は当然起こるものとできる

43. 追加・変更が起こった際のトレードオフの議
論がスムーズになる

44. 顧客が得られるもの

45. 作業量の可視化・見える化による安心感

46. 柔軟な対応による満足感

47. トレードオフが発生した際の納得感

48. これで大体問題が起こりそうなこと
を事前に交渉できる！
炎上の見分け、消しができる！
（タイトル回収）

49. でも・・・・
これには顧客の主要メンバーに
Backlogに私事として参加して貰う
必要がある

50. 案件におけるBacklog利用の徹底

51. メールは使わない

52. 対応・要望は全部チケットに書く

53. ダブっても構わない

54. チケット作成ルールの明確化が ？

55. • 1チケット1作業
• 複数の作業をメールのように書くと終わらないチケットに
なってしまう・・・
• 顧客はメールのように長く書きがち
• 初期は我々でチケットを分割する
• 慣れてくれば自然とそのようにやってくれるようになる
• 期限日の共通化

56. 両者ともにどんどんチケットに追加して記録
を残すことを重視する

57. 思っていたのに・・・の排除

58. 言った言わないを避ける

59. その物量をどうやって・・・・登録
するの？

60. 便利なツールがあるんですよー
• スプレッドシートから一括登録
https://backlog.com/ja/blog/release-2018-07-23-bulk-issue-
registration/

62. 大量のチケットどう裁く？

63. 毎週棚を行う。除外なども。担当が明確になっていれば
放置は少ない。
放置されるようなときはタスク量が過多なので別の調整も必要

64. メール通知はしている？

65. slackに連携して、担当者に対してメンションが飛ぶよ
うにしている
• 弊社松村が作ったbacklackを導入
• https://tsubalog.hatenablog.com/entry/2017/01/22/090000
• でも・・・

66. 公式が・・・対応した・・だと？
https://backlog.com/ja/blog/backlog-with-typetalk-slack-chatwork/#SlackBacklog

67. 途中で想定していない問題が発生し
て、計画通りにスケジュールが進め
られなかった場合はどうする？

68. 毎週調整していると、どの段階でオーバーす
るのかが見えてくるため、見えた時点で削減
などの交渉に入ったりしています

69. しかし結局・・・

70. 担当者やその上の方々と泥臭くお話をしま
す。
ツールはあくまで補助するもので入れただけ
でどうにかなる銀の弾丸ではありません。

71. まとめ
• スタート時にチケットを想定する限り作成することでゴールの
共有ができる
• これを軸に柔軟な変更を顧客とともに取り組むことができる
• 顧客の安心感・満足感・納得感を得る
• 問題ポイントが事前にみえるため炎上しそうなポイントは事前
交渉で潰せる

72. ご清聴ありがとうございました

73. 宣伝