Backlogを作ってるエンジニアが教えるBacklog活用術 - 開発チーム内外をつなぐ、課題管理の考え方

プロジェクト管理ツール、コラボレーションツールとしてBacklogを採用しているチームは多いでしょう。多岐にわたる機能を利用できるツールですが、上手に使うためのアイデアと方法を、Backlogを生み出したヌーラボ社の中村知成さんが解説します。開発チーム内だけでなく、マーケやセールスなどを含めた、チームを横断した課題管理など、“中の人”ならではの知見をご紹介します。

Backlogを作ってるエンジニアが教えるBacklog活用術 - 開発チーム内外をつなぐ、課題管理の考え方

株式会社ヌーラボの中村知成1@ikikkoです。Backlogの開発・運用全般のマネージャーを務めつつ、Backlogの導入・業務改善や、ソフトウェア開発現場の支援サービスに携わっています。

Backlogはソフトウェア開発やWeb制作の現場をはじめ、ITに明るくないメンバーも含めた社内外とのコミュニケーション用途など、幅広く利用されているプロジェクト管理ツールです。もちろん、ヌーラボ社内でもプロダクト開発はもちろん、Webサイト作成、人事労務の業務や社内申請の管理など、あらゆる場面でBacklogを使い倒しています。本稿ではソフトウェア開発の現場で使われる方に向け、Backlogの基本的な機能と開発の流れや開発チーム内外での活用方法、さらには徹底的なドッグフーディングで蓄えられたTIPSも合わせて紹介していきます。

Backlogの基本的な機能と開発の流れ

Backlogは、様々な機能を兼ね備えています。その中でも、開発で主に使う機能は、以下の3つです。

  • 課題(ボード / 各種チャート含む)
  • バージョン管理(Git / Subversion)
  • Wiki

Backlogの核となる機能が、課題機能です。実現したい機能や、そのために必要なタスクを、「課題」という形で登録します。課題の管理には、一覧表示だけでなくボード形式での表示もできます。また、課題に期限やマイルストーンといった日付を設定しておくと、バーンダウンチャートガントチャートの自動作成も可能です。

Backlogでは、バージョン管理システムとして、GitSubversionを提供しています。Gitでは、効果的なコードレビューをサポートするプルリクエストや、大容量ファイルを扱うためのGit LFSが備わっているため、特に制約事項がなければGitの方がおすすめです。

まとまった情報を記録しておくには、Wiki機能が利用できます。会議の議事録を始め、ソフトウェアの仕様や開発環境の構築方法、チームの約束事などを管理しておくのに適しているでしょう。

上記の機能を用いた開発の流れは、以下のようになります。

  1. 実現したい機能や必要なタスクを、課題として登録
  2. 課題の内容に沿って開発を進め、ソースコードをバージョン管理システム(GitもしくはSubversion)に追加
  3. ソースコードに問題がなければ、課題を完了
  4. 開発を進めていく中で培われたノウハウや汎用的な情報を、Wikiに整理
  5. 課題やソースコードを修正する中で、適宜Wikiを参照
2

開発チーム内での活用

ここからは、開発チームでBacklogを使う際の活用方法を紹介していきます。

まずは、開発チーム内の活用です。ここでは、開発の業務を「Project(プロジェクト)型業務」と「Operation(運用)型業務」の2種類に分類し、それぞれの業務における活用法をお伝えします。

Project型業務

まずは、Project型業務について。ある程度の開発期間(大抵、6ヶ月程度まで)が確保されており、その期間で新規機能の開発に注力するタイプの業務です。Project型業務では、スクラムプロセスが相性がいいため、本稿ではスクラムをBacklog上でどう実現するかを紹介します。

スクラムでは、作成物としてプロダクトバックログやスプリントバックログが定義されています。Backlogでは、それぞれのバックログに入れる課題を以下のように分類するとよいでしょう。

  • PBI:プロダクトバックログアイテム。プロダクトバックログに入れる項目で、ユーザーストーリーなど
  • タスク:スプリントバックログに入れる項目で、スプリントでやるべきタスクを表現したもの。プロダクトバックログアイテムと紐づくタスクならば、親子課題で表現しておくと、関係が把握しやすい

こうして分類することで、課題テンプレート機能を使って特定のフォーマットに沿った内容を入力しやすくなります。例えば、ユーザーストーリーでは、受入基準やデモ手順をテンプレートとして設定しておくことが考えられます。

合わせて、スプリントごとにマイルストーンを設定することで、現在のスプリントをはじめ、各スプリントごとのスプリントバックログが閲覧できます。また、スプリントごとにバーンダウンチャート表示もできるようになります。

Backlogの開発チームで実践した記事もありますので、ご参考ください。

Operation型業務

続いて、Operation型業務です。プロダクト開発では、純粋な開発業務だけではなく、ユーザーからの問い合わせ対応や不具合対応、他部署からの依頼事項などが発生します。こうした業務はスプリント単位できっちり計画しきることは難しいこともあるため、優先順位を柔軟に変更しやすいカンバンプロセスで対応するといいでしょう。

こうしたOperation型業務に対しては、ボード機能の利用が有効です。WIP(仕掛中の課題)数の制限や侵入条件を表現する機能などはBacklogとしては提供していないため、自分たちで運用ルールを定めた上でWikiに記載するといったやり方が考えられます。

例えば、ヌーラボのOperation型業務では、標準で定義されている「未対応(Open)」と「処理中(In Progress)」の間に、「Ready」「Investigating」という状態を設けています。Operation型業務では入ってくる課題が多いので、少しでも分類して把握しやすくするために、入ってくる課題を全て未対応状態で登録した上で、次に着手したい課題を優先順位をつけてReady状態にしています。また、調査や検討が不十分なまま課題登録されることも比較的多いため、Investigating状態を明示的に設定しておき、このタイミングで受入基準などを定義するようにしています。

開発チーム外との連携

エンジニアHubに会員登録すると
続きをお読みいただけます(無料)。
登録のメリット
  • すべての過去記事を読める
  • 過去のウェビナー動画を
    視聴できる
  • 企業やエージェントから
    スカウトが届く