Backlogへのタスク管理ツール移行によるプロジェクト横断型タスク管理の実現

参考になった

レビュー投稿日の情報になります

弥生株式会社 / takuya kawamoto

メンバー / プロジェクトマネージャ / 従業員規模: 501名〜1,000名 / エンジニア組織: 301名〜500名

最終更新日2024/07/17投稿日2024/07/17

利用プラン	ツールの利用規模	ツールの利用開始時期	事業形態
プレミアムプラン	501名〜1,000名	2021年10月	B to B

アーキテクチャ

アーキテクチャの意図・工夫

独自の工夫として「Microsoft ProjectからBacklogのチケットを一括起票する」仕組みを作って効率化しています。
アーキテクチャの通り、弊社開発本部ではプロジェクト管理ツール（Microsoft Project）とタスク管理ツール（Backlog）が分かれています。
「プロジェクト管理ツールでプロジェクト全体のタスクを計画し、個々のタスクの進捗および成果はタスク管理ツールで管理する」という構造です。

したがって、プロジェクト管理ツールで計画したタスクを、タスク管理ツール（Backlog）に登録していく必要が出てきます。
このときBacklogに1件1件手動でチケットを起票していくのは非常に手間が掛かるので、BacklogのAPIを利用してまとめて起票できるようにしています。
また、プロジェクト管理ツールでスケジュールを再計画した場合は、チケットの日付（開始日/期限日）をまとめて更新できるようにしています。

【補足：プロジェクト管理ツールとタスク管理ツール】
プロジェクト管理ツール（Microsoft Project）は、WBSを組み立ててプロジェクト全体のスケジュールを作成し、進捗を可視化することに特化したツールです。プロジェクト全体に焦点を当てるため、個々のタスクの進捗や詳細な対応状況、発生している問題などの具体的な情報を表現することはできません。
一方、タスク管理ツール（Backlog）は、個々のタスクをチケットというフレームワークで詳細に管理し、作業時のコミュニケーションを円滑にすることに優れています。
これらのツールのどちらか一方だけでは、十分なプロジェクト管理は難しいため、弊社ではそれぞれのツールの得意分野を活かして運用しています。

導入の背景・解決したかった問題

導入背景

ツール導入前の課題

弊社開発本部では十数年に渡ってプロジェクトのタスク管理にTracを利用しており、開発プロセスは十分に定着し運用している状態でした。
一方で昨今の開発事情・開発規模の変化によって、Tracでは解決できない困りごとが出てきていました。

①Tracでは複数のプロジェクトを横断的に確認しづらい

デスクトップアプリケーション単体で独立していたプロダクトが他アプリケーションやクラウドサービス等と連携する機能を備え、複数のプロジェクトに対して横断的に関与する必要性が増加した
弊社のTracの構成は「複数のプロジェクトを横断的に確認する」ことに適した構成になっておらず、利用者の努力で補うには限界があった

②Tracのオンプレミスサーバーの運用・メンテナンスコストが増加

移行前の時点でTracのオンプレミスサーバーを10台運用していた
インフラチームはTrac以外にも管理すべき設備が多数あり、今後の保守運用をどうしていくか課題だった

どのような状態を目指していたか

弊社の場合はタスク管理ツールをゼロから導入する状況ではなかったため、「Tracで実行できている良い点はなるべくそのまま維持し、その上で前述の課題解決やプロセス改善を行う」という状態を目指しました。
また、タスク管理ツールをBacklogに移行してもタスク管理の本質的な考え方はTracと変わらないと考えていたので、以下の運用ポリシーは変更しないことを発信し続けました。

タスク管理ツールはコミュニケーションのツールである
- チケットの詳細欄を見れば状況がすぐ分かるようにする
プロジェクトに関する情報を一元管理する
- 常に最新の状態を保つ
- チャットや口頭でやり取りした情報も蓄積すべき情報はBacklogに集約する

導入の成果

改善したかった課題はどれくらい解決されたか

①Tracでは複数のプロジェクトを横断的に確認しづらい

複数のプロジェクトで自身が担当者になっているチケットはダッシュボード画面で一覧化されるので、Tracよりも確認しやすくなった
検索機能で全プロジェクトを対象にチケットを絞り込むことができるので、Tracよりも検索容易性が格段に改善した
一方で「複数のプロジェクトを横断的に確認する」ことを全員が徹底できているかというと、個人差があると感じるため改善の余地がある

②Tracのオンプレミスサーバーの運用・メンテナンスコストが増加

移行検討時点ではBacklogのオンプレミス版（エンタープライズ版）も候補にあったが、結果的にSaaS版を導入することで決定したのでオンプレミスサーバーの保守運用に掛かる人的リソースは不要になった

導入時の苦労・悩み

「Tracで実行できている良い点はなるべくそのまま維持する」という目標に対する落としどころ
- ツールの仕様が異なるので、当然ながら既存のプロセスと適応しづらい部分は出てきた
- そのプロセスが何のためにあるのか、譲れない要素は何なのか、といった議論をあらためて行うことにも時間を取られた
運用中のTracに登録されたチケットの移行
- 残念ながらBacklogのヘルプセンターには、RedmineからBacklog、JiraからBacklogに移行するツールしか公開されていなかった
- BacklogのAPIを利用した自社専用のTracからBacklogに移行するツールを実装する必要が生じた

導入に向けた社内への説明

上長・チームへの説明

いきなり全プロジェクトに展開することは難しいため、トライアルプロジェクトをいくつか選定し、フィードバックを得ながらより詳細なルールを策定する方針で検討を進めました。
トライアルプロジェクトでは、Tracより良いと感じた点や、運用で工夫した点、改善が必要な点について確認しました。
おおむね好感触だった一方で、ツールのコンセプトの違いで、Tracで慣れ親しんだ運用をBacklogでは実現できないことも判明しました。
特にチケットに複数担当者を設定できない点はかなりネガティブな要素でしたが、代替手段としてカスタムフィールドを活用する運用を提示するなど、なるべく利用者に寄り添った対応を心掛けました。

活用方法

チームで毎日チケットを確認して進捗管理を行っています。

よく使う機能

ダッシュボード
- 組織全体の担当チケットを横断的に確認
課題管理
- プロジェクトの個々のタスクの進捗および成果の管理
Wiki
- 開発に関するナレッジベースとして各種情報をWikiに集約

ツールの良い点

シンプルなUIで直感的に操作することができる
チケット管理に便利な機能が揃っている
- 一括編集機能（まとめて操作）
- チケット複製機能
- ウォッチ機能、etc
課題キーがそのまま別チケットへのリンクになる

ツールの課題点

複数人が関わる課題の管理
- ツールのコンセプトとして、担当者に複数人設定できない
- 複数人で作業する場合は「子課題を作成する」「カスタムフィールドを活用する」といった運用面での工夫が必要
チケットのワークフロー機能がない
- 担当者一人ひとりが適切にワークフローを理解して更新することが必要
親子課題を再帰的に設定できない
- 親子関係を設定すると、その子課題を親課題とすることができない