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

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

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

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

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

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

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

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

開発チーム内での活用

ここからは、開発チームで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状態を明示的に設定しておき、このタイミングで受入基準などを定義するようにしています。

開発チーム外との連携

さて、Backlogの強みの一つは、開発チーム内外の連携にも効果を発揮する点にあります。エンジニアでない方でも容易に扱えるUIを採用しており、さまざまな部門の業務に活用できるのです。実際、ヌーラボでもサポートチームやマーケティングチームをはじめ、場合によっては経理・法務などのバックオフィスチームとのやり取りもBacklog上で行っています。

ここでは、開発チーム外との連携を行う際の、課題の運用方法をお伝えします。複数のチームをまたがった課題運用の場合、課題を「どこで管理するか」「誰が課題に関係するか」「やり取りの発生頻度や量」といった要素に応じて、いくつかの運用パターンが考えられます。まずは、どのようなパターンがあるかを説明します。

なお、Backlogの用語として、参加者や課題などの情報を大きく分類・分割するためのくくりである「プロジェクト（GitHubにおけるリポジトリのような概念です）」が存在します。本稿では、Backlogにおける分類概念を「プロジェクト」とカタカナ表記し、上述した「Project型業務」を英語表記して区別します

1. 単一プロジェクト上での課題管理

一番シンプルなパターンです。単発的な依頼事項を、依頼する側もしくはされる側どちらかのプロジェクトに課題として登録します。その課題上で、必要なやり取りを行って課題の完了を目指します。

課題の登録作業は1プロジェクトに収まりますが、自分のチームがメインで管理していないプロジェクトに立てられた課題はどうしても把握しづらくなってしまいます。下図の例では、開発チーム外のプロジェクトに課題が登録されているため、開発チームが管理している他の課題との優先順位や課題の総量が把握しづらくなってしまいます。

ただ、課題を漏れなく登録することさえ意識しておけば、課題管理の手間はそれ以上かかりません。チーム外と連携する課題の数が少ない状態ならば、このパターンから始めてみるといいでしょう。

2. 複数のプロジェクト上で同一課題の管理

同一の課題を複数のプロジェクトに登録するパターンです。管理が二重になり手間はかかりますが、各チームのニーズやフローに合わせて柔軟に課題を運用できます。例えば依頼する方は開発の詳細を知らなくてもいいが、開発チームとしてはソースコードレベルで詳細なタスクを考えながら進めたい場合、このパターンのように課題が分かれていれば、柔軟に対応可能です。

ヌーラボのOperation型業務のプロジェクトでも、このパターンを採用しています。これは、今抱えている複数の課題を比較検討した上で優先順位を設定する、また、課題の総量の増減をもとにチームの健全性を測定したい、という2つの意図があるからです。

3. 各チームをまたがって課題管理

上記2つのパターンのように、チームごとによってプロジェクトが分断されていると、どうしても全体的な視点が欠けやすくなります。業務によっては開発して終わり、とはならず。開発完了後、プレスリリースを打つといった適切なマーケティング・PR活動が必要となる場合もあるでしょう。つまり、以下の図のように一つのプロジェクトのフェイズに応じて、関わるべきチームが変化するパターンです。

こうした場合、各チームをまたがったプロジェクトを作成し、そのプロジェクト上で課題管理を行うというパターンが考えられます。チーム分断で個別最適になって全体としての価値提供が遅れるのではなく、エンドツーエンドでの価値の流れ（バリューストリーム）と提供するべき価値が俯瞰しやすくなるのです。

このように一元管理してプロジェクトを見える化することで、全体としての価値提供を共通の目的として見据えやすくなり、結果としてよりよいコラボレーションを実現しやすくなります。

例えば、PRのレーンが詰まってる状況で、いくら機能開発してリリースしても、適切なPR活動ができないばかりか、より一層PR担当の負荷を与えることになってしまいます。その場合、PR活動のフォローができないかを検討することが望ましく、結果としてチームを超えたコラボレーションの発生が期待できます。

各パターンの比較

各パターンの長所と短所を整理すると、以下のようになります。

• 単一プロジェクト上での課題管理

  • 課題の性質：定常的には発生しない単発の課題・数時間～数日でさっと終わる課題
  • 長所：課題をあげる場所が1箇所なので、その分課題管理コストが少ない
  • 短所：依頼する方/受ける方を問わず、課題管理をしてない方からは課題の全体量や優先順位が把握しにくい|

• 複数のプロジェクト上で課題管理

  • 課題の性質：それなりにやり取りが発生して、量・時間ともに長引きがちな課題
  • 長所：依頼をする方/受ける方の双方で、課題全体の量や優先順位を把握しやすい。また、各チームのニーズに応じて柔軟に課題運用ができる
  • 短所：課題の二重管理の手間が発生する

• 複数のチームをまたがった課題管理

  • 課題の性質：各チーム視点による部分最適でなく、全体最適を考えたい課題
  • 長所：全体最適の視点で、エンドツーエンドの価値提供までを意識するという意味で効果的。また、共通の目的を見据えることによって、よりよいコラボレーションを実現しやすい
  • 短所：チームをまたがった認識合わせやプロセスの決め事が必要になり、手間がかかる

注意点：チームによって、慣れているやり方やツールが違う

最後に、チーム外とやり取りする際に意識しておきたいことをお伝えします。

チームによっては、Backlog以外のツールを使っていることも多いでしょう。それぞれのチームで使ってる他のサービス、例えば手軽に使えるメールやGoogleスプレッドシート・Googleフォームなどを使っている場合もあるでしょう。また、こうしたサービスを社内システムと連携させているケースも往々にしてあります。

それぞれのチームが適切にタスクをこなすには、適したサービスを使う方が望ましいのは確かです。しかし、課題管理という観点ではなんらかのツールに集約し確認できた方がいいでしょう。Backlogの場合、他のサービスとの連携を実現するための、Backlogを操作できるAPIや、メールで課題登録する機能といった機能があります。特に後者の機能は汎用性が高く、問い合わせフォームとの連携やGoogleフォームとの連携も容易に行えます。

メールで課題登録機能による、問い合わせフォームとの連携。
画像は「メールによる課題登録を設定する – Backlogヘルプセンター」より

最後に：コラボレーションを促進するために必要なこと

本稿では、ソフトウェア開発の現場でBacklogを使いこなすために、Backlogの基本的な機能や活用方法、TIPSを紹介してきました。

Backlogは、皆さんの業務上のコラボレーションを促進するツールの一つです。良質なコラボレーションによって現場が活性化し、価値あるソフトウェアの開発・提供に近づくのですが、そのために必要なのはツールだけではありません。チームのみんながコラボレーションの価値を認め、コラボレーションを生み出していくんだ、というマインドもまた重要です。

ツールとマインドは相互補完の関係にあります。適切なツールの活用は、建設的な議論やコミュニケーションをもたらし、現場の雰囲気をポジティブな方向に向かわせるため、マインドの価値を実感しやすくなるでしょう。一方で、マインドが育まれることによって、ツールのより一層の効果的な活用につながります。

適切なツールとマインドによるコラボレーションの促進。皆さんの開発現場に、このような良いスパイラルを生み出すツールとしてBacklogを活用していただければ幸いです。

中村知成（なかむら・ともなり） @ikikko

前職で課題管理・構成管理といった環境整備に面白さを感じ、2009年にBacklogを提供するヌーラボに転職。ソフトウェアエンジニアとしてBacklogの開発・運用両面を担当。並行して「共に働く人たちが、より輝けるように」という思いのもと、CI/CDや環境整備に対する取り組みも行う。2016年頃に知人のアジャイルコーチの活動に触れたことによって、技術的なプラクティスだけではないチーム作りや改善活動の重要性や難しさ・楽しさを実感し、以後アジャイルへの興味とそれを突き詰める活動を始める。
現在は、Backlogチームの開発マネージャーをしつつ、社内の各チームへの支援活動を通じて、ヌーラボのサービス開発を影から支えている。共著書に『現場のインフラ屋が教える インフラエンジニアになるための教科書』（刊：ソシム）がある。