Backlogでスクラム開発の安定的な運用とフルリモートでも情報格差がない組織を実現

導入前は以下のような状態でした。

• タスクを個人が管理しており、優先順位づけができていなかった
• カスタマーサクセスチームから開発チームへの依頼がチャット上で行われ、対応の抜け漏れが発生
• コミュニケーションがチャットのDMなどで行われ、情報が属人化
  

そのため

• 開発チームのプロジェクト管理
• マーケティングチーム、カスタマーサクセスチームのタスク管理
  

を行なうためにBacklogを導入しました。

• Trello
• JIRA
• Asana
• Notion

使いやすさ、特に非エンジニアでも違和感なく使用できるかという点

上記同様で使いやすさ、特に非エンジニアでも違和感なく使用できるかという点を考えた結果、Backlogを選定しました。

• タスクが見える化され、スクラム開発を安定して運用できるようになったことで残業時間が減少
• チーム間の連携がスムーズに
• コミュニケーションがオープンになり、フルリモートでも情報格差がない組織を実現

Backlog導入以前はNotionでタスク管理をしており、既に作成済みのチケット含めた移行が必要だった点です。
すべてを移行するのは断念し新規分からをBacklogに移行しました。
移行期間における運用ルールの作成、浸透なども苦労しました。
複数チームがあったため、Notionでそのまま運用しようとするチームもあり、数回にわたり浸透をおこないました。

失敗してしまったエピソード

課題が1階層の親子関係までしか作れないのを把握しておらず、プロジェクトのチケットルールを作成してしまい修正が大変になりました。
カスタマイズ属性を増やして管理しやすくしていきましたが、リスト属性が課題一括登録に対応しておらず課題一括登録機能を利用できないフローにしてしまいました。

機能がシンプルなので開発者内だけで利用するケースだと少し物足りないかもしれません。
逆に機能が厳選されており、UIもわかりやすいのでビジネスサイドと一緒に使うケースなどでは良いと思います。他の進捗管理サービス（例えばJIRA、Redmineなど）は非エンジニアのキャッチアップコストが高い印象を受けますが、Backlogはすぐに使用できる印象を受けます。

また、弊社テックブログでもBacklogの活用方法について詳しくご紹介してますので、よければご覧ください。

• ヌーラボ社によるBacklogの活用法についてインタビュー記事が公開されました。
• Backlogを用いたスクラム開発のススメ
• GASを使ってGoogle FormとSlackとBacklogを連携してみた