クライアント向けBacklogプロジェクトのふりかえり

加納です。社内SEとして従事しております。

2019/04/23 に JBUG (名古屋#1) に参加させていただきますので、それまでに現状をまとめておきたいと考えております。

jbug.connpass.com

初めに2月からクライアント向け Backlog プロジェクトの運用を開始したので、そのふりかえりを行います。

イントロダクション

1月に開催された Backlog World 2019 に参加し、セッション「『連絡板』が支える、Backlog嫌いなクライアントとのコミュニケーション」を聴講しました。

私にとってのクライアントは社内のユーザー部署であり、当時、主な連絡方法が電話(次点がメール)であった為、導入することにしました。

導入から2ヶ月

導入から2ヶ月が経ち、「導入して良かった点」と「これからの課題」が見えてきましたので、まとめます。

良かった点

状態が管理できる様になった点

今まで電話を受け、何かしらの約束をした場合、「言った言わない問題」を防止するべく、その内容をメールで送っていました。

ただし、そのメールは状態も何もない為、長期間経過してしまうと、うやむやになってしまうケースがありました。

ユーザー部署向け Backlog を導入したことで、双方に状態が見える様になりました。また、完了条件を提示した上で完了とすることで、うやむやになることを防いでいます。

期限日の管理がしやすい点

今まで、ユーザー部署への展開は、 Google スプレッドシートを用いていましたが、期限日がただのセルでしかなかった為、超過に気づきにくいことがありました。

Backlog ではガントチャートやレポートなど期限日に気づきやすい仕組みが最初から用意されています。

また、内部では元々、 Backlog を使用していた為、外部へ展開する際に加工が少なくて済むという点が個人的には非常に助かっています。

これからの課題

「3ない」問題にどう立ち向かうか

上記セッションで提示された問題点、「3ない」問題。 例に漏れず、私もこの問題を抱えています。

  • タスクを整理してくれない
  • 見てくれない
  • 使ってくれない

1 つ目のタスク整理については、私が整理しているので問題ありませんが、残りの 2 つについては、少しずつ馴染んでもらえる様に努めていくしかない状況です。

それでも加工は必要

スプレッドシートよりは加工が少なくて済みますが、それでも加工は必要です。内外での文言の統一など表層的な改善は概ね済ませてしまったので、次の策として API での自動化を検討しています。

よろしければ、下記もご覧ください。 ma310kano.hatenablog.com ma310kano.hatenablog.com