Backlogでシンプルでわかりやすいタスク・スケジュール管理を実現

Backlog導入前は、Jiraでのスプリントを使った開発をしていたものの、チケットの親子関係の持ち方、開発工数の管理方法がメンバーによってまちまちな状態になっていました。

課題として、Jiraの機能を活用しきれておらず、管理や運用が複雑になってしまっており、毎週チケットの棚卸しをする際に、チームのルールに沿っていないチケットの整理が必要な状況になっていました。
カンバンは使いやすかったものの、チケットの検索などカンバン以外のUIが使いにくかったです。
また当時のチームの人数規模と料金体系がうまくマッチしていませんでした。

以上のような背景から、プロダクトバックログ、スプリントバックログのシンプルな運用を保ちたいと考えていました。

Redmine→Trello→Jiraとツールを乗り換えてきました。

Redmineは自社サーバーでホストしていましたが、運用・メンテナンスの手間が大きかったためクラウドサービスへと移行しました。
カンバンが利用できるTrelloに乗り換えたものの、プロダクトバックログとスプリントバックログの関係性が見えづらくなってしまったため、Jiraに移行しました。
Jiraは自由度が高かったものの、それが逆に複雑な運用を生んでしまっていました。

• カンバン機能がある
• シンプルな使い勝手

社内の別チームがすでに使用をしており、ツールを統一することで情報管理面、費用面での経営的判断。
2020年1月にBacklogにカンバン機能がリリースされたこと。

新しく入ったメンバーのツールの学習コストが減り、シンプルな運用ができるようになりました。

具体的な導入成果として、チームのルールに沿っていないチケットが無くなったため、毎週のチケットの棚卸しが楽になりました。

また、BacklogはUIがビジネスサイドのメンバーにもわかりやすく、ビジネスサイドのメンバーもBacklogを使うようになったことで、開発スケジュールの共有やビジネスサイドからの顧客の声の集約がしやすくなりました。

BacklogではJiraのようなスプリントを切り替える機能がなかったため、どのような運用でカバーするか検討する必要がありました。JiraのデータをBacklogに移行するにあたってJiraのデータエクスポート機能の品質がそこまで高くなく、データ量が多いとエクスポートに失敗するケースが発生しました。

RedmineやJiraを使っていたときにはギチギチにルールを決めて運用をしていましたが、開発チームのメンバーが増える、ビジネスの状況が変わるなどによってルールが古くなったり形骸化したりして、誰もルールについてこられない状況が発生していました。
タスク管理ツールを管理する専任のメンバーがいないようなチームで、ほどよく管理をしていくにはちょうどよいサービスだと思います。