Tweet

IoTインテグレーション事業部 開発部の古川です。

弊社では、全社スコープのコミュニケーションには、グループウェアであるサイボウズがメインで使われていますが、当開発部のタスク管理では、Backlogをメインで使用しています。
https://backlog.com/ja/

Backlogには、幾つかの利用方法の側面があるため、用途に応じた使い方を行うことが肝要です。
普段はそれほど意識することなく使い分けていますが、本ブログのエントリでは、利用方法の整理も兼ねて、Backlogによるタスク管理方法について紹介します。

はじめに

本エントリでは、次の使い方に分類して紹介します。

• プロジェクト管理
• コミュニケーションツール
• 課題管理
• 複数プロジェクト管理

ケースに応じて、使い方が変わります。
ポイントになるのは、課題の「担当者」です。

プロジェクト管理

ガントチャートを利用する目的で使用します。
プロジェクト管理が必要となる中規模～大規模のプロジェクトで利用することが多いと思います。
プロジェクトによっては、WBSを別途作成する場合もあると思いますが、Backlogを利用してタスク管理を行うなら、Backlogのガントチャートを使った方が、進捗管理のために別途作業を増やす必要が無くてよいですね。

実際のプロジェクト情報を載せられないので、Backlog社のイメージを記載します。

ガントチャートを利用する場合は、最低でも次の属性を利用します。

• マイルストーン
• 担当者
• 開始日/期限日

バーンダウンチャートも良いです。

この場合、計画線／実績線を正しく表すために、次の属性も利用します。

• 予定時間
• 実績時間

プロジェクトの中盤以降あたりで、プロジェクト状況を報告する際に、残タスクを出し切った上で「残工数がどの程度かかるのか？」を報告する際に有用です。

・・・といっても、実案件では、Excelベースで管理したことはありますが、まだ、このBacklog機能を実案件の報告として利用したことはありません。
今度、生かせそうなプロジェクトがあったら利用してみようと思います。

ポイント

どのタスクが順調ではないのか？誰のタスクか？どの程度残っているのか？を管理することが目的なので、課題の担当者は基本的には変更しないルールです。

例えば、設計書のレビューが必要だった場合は、子課題でレビュータスクを作成して、別の担当者に割り当てます。
そうしないと、ガントチャート上で見た時に、担当者が変わってしまい、管理がしにくくなります。

プロジェクトによっては、仕様のQAや不具合チケット等の担当者を変更したい課題を同じプロジェクトで管理することがあると思います。
そのような場合は、次のようにルールを定めて使用します。

• ガントチャート用の課題の種別は「タスク」として担当者は変更しない
• 不具合管理用の課題は「Bug」として、修正後に起票者に戻す

ポイントを纏めると次の通りです。

コミュニケーションツール

社内外とのコミュニケーションツールとして利用します。
電子メールと比べて次のようなメリットがあります。

• やり取りの履歴が残るため、後からプロジェクトにJOINしたメンバーも以前の情報にアクセスすることができる
• ファイルの送受信をファイル管理機能で行うことができる

ポイント

メールの代わりのように利用するため、レスポンスを返した場合に、課題の担当者を変更します。
メンションでやり取りされ、担当者が変わらないケースもあると思います。
利用するプロジェクトにおいてプロジェクト管理用途と混在して利用する場合は、課題の種別等でどちらの用途の課題なのかを区別する必要があります。

ポイントを纏めると次の通りです。

課題管理

プロジェクトの課題を管理するために利用します。
開発～運用中のシステムに対する不具合報告や機能改善要望等を管理する目的で利用します。
次の属性も同時に用いられます。

• マイルストーン
• 優先度
• 開始日/期限日

ポイント

起票者から担当者、担当者から起票者へ返すタイミング等で、課題の担当者を変更します。

複数プロジェクトタスク管理

組織で進行するプロジェクトに対して、Backlogの「プロジェクト」を割り当てて運用した場合、複数のBacklogプロジェクトが立つことになります。
組織運営においては、各プロジェクトからの進捗や状況報告を受け、取りまとめて上位の報告対象者へ報告します。
各プロジェクトの担当者に、進捗報告向けの報告事項を纏めてもらうというケースも考えられますが、できれば、報告のための作業は極力減らしたいもの。
当部署の運用では、担当者には、Backlogの課題の更新を行ってもらい、定例報告には更新されたBacklog課題を参照するようにしています。

課題画面の右側にある「プロジェクトをまたいだ検索」を利用します。

定例報告

報告対象の会議体のスコープとなる担当者を条件として、
「更新日」を条件に、前回報告時点からの更新分をスナップショット表示して報告に利用します。
X月X日 開発部報告、という感じです。

口頭で連絡を受けるタスクもありますが、時間が経ってしまうとどうしても全ての状況の把握には綻びが出るもの。更新された課題一覧は、ある時点のスナップショットとして閲覧可能であるため、関与するプロジェクトのタスクを漏れなく閲覧することができます。
複数の会議体が異なる周期で開催された場合でも、担当者と更新日を変更して検索すれば良いので、担当者の作業は変わりません。

「プロジェクトをまたいだ検索」でも、「検索条件を保存」が利用できます。
画面上部の「フィルタ」に保存されます。

「フィルタ」から各会議体向けの報告を呼び出して、「更新日」の条件を変更して利用します。
表示した一覧をPDF等の形式で出力できます。

プロジェクト単体では、短縮URLが利用できますが、「プロジェクトをまたいだ検索」の場合は、利用できないのが残念。
リンクを他者と共有する場合、長いURLを共有することになります。

また、担当者には、マイルストーンやカテゴリを適切に入力してもらうことで、
課題一覧上で状況を把握できるようにします。

タスク管理

次のような課題を検索、参照して担当者へフォローします。

• 「未着手」のままになっている
• 「処理中」のまま状況が更新されていない

これも「フィルタ」に保存しておくことで、定期的にチェックすることができます。

APIを利用した管理

上記までの利用方法では、課題のタイトルを含む一覧情報までが取得できますが、それぞれの課題のコメントは閲覧できないため、課題の詳細状況までを俯瞰することができません。
（※Backlog APIでも課題情報と課題のコメントは別APIとなっています）

この課題を解決しようとして、以前BacklogのAPI経由でコメントを含む情報を取得し、スプレッドシート上に可視化することも検討しましたが、

https://qiita.com/nilesflow/items/d8ab98cfa985c108e112

結局、コメント内容は必要に応じて参照する程度として、現在は、「プロジェクトをまたいだ検索」機能を利用する運用としています。
作成する課題の大きさを適切な粒度として、課題の状態の更新だけで状況が俯瞰できる管理が望ましいですね。

課題

以下は、現在の運用における課題と感じている点です。

• URLが長く、短縮URLが適用されない
• 保存したフィルタの条件から、報告都度、更新日を変更する必要がある。
• 課題のコメントで記載される詳細状況は、一覧から別途確認する必要がある
• プロジェクトや課題の種別が増減した場合に、検索条件を再設定するのに少し手間がかかる
• 実際の業務状況に関係なく更新された課題も抽出対象となる

ポイント

プロジェクトをコミュニケーションツール等で利用されている場合は、担当者が変更されて参照のスコープ外になっている場合もあるため、注意が必要です。

ポイントは、次の通りです。

さいごに

業務シーンにおけるBacklogの利用方法を整理・紹介しました。
プロジェクトの状況に応じて、適切に使い分けて運用しましょう。
実際には紹介した複数の用途が混在するケースが多いので、その場合でもより適切に管理できる運用を進めていきたいと思います。