3
8

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 3 years have passed since last update.

チームで開発するためのBacklog運用ルール

Last updated at Posted at 2019-05-30

Backlogでプロジェクトの課題管理をする場合、何をするべきかまとめました。
大事なのは、「ルールを決めて、ルールを守る」ことです。
Backlogってなに?という人はコチラを。

1. ルールを決める

課題の書き方を決めよう

課題を書く人それぞれで書き方が異なると、読む人にとって負担です。課題の質を担保するためにも、書き方を決めましょう。テンプレートを作成して運用するのも効果的です。
具体的な例として、以下のようなルールがあります。

  • ひとつの課題に複数の内容を含めない
  • 課題詳細に共通の小見出しを使う(概要、完了条件、注意事項など)
  • 課題詳細には「事実」を書き、意見や感想を含めない
  • 課題詳細はメールのような文体にしない(○○さん、お疲れ様です〜のような)

課題の完了条件を明確にしよう

課題で大事なのは、「どうすれば完了なのか」が分かりやすいことです。
ざっくりとした作業の内容ではなく、できるだけ具体的に書きましょう。

BAD...

  • タイトルを変更する。

GOOD!

  • テスト環境で、ディレクターが、タイトルの変更を確認したら完了。

課題の期限を決めよう

期限は作業の順番に影響します。仮でも良いので、課題製作時に設定しましょう。
期限の未設定は放置の元になります。

課題タイトルの書き方を決めよう

タイトルは単純かつ明快につけましょう。ルールが乱れやすい場所なので、注意が必要です。
大切なのは、1つの課題としての分かりやすさだけではなく、課題一覧として分かりやすいことです。

GOOD

  • トップ画面のタイトルにアニメーションを追加

BAD...

  • トップ画面にアニメーションを追加 → 何にアニメーションをつけるの?
  • 【トップ画面】タイトルにアニメーションを追加 → 勝手な装飾ルールをつくらない
  • トップ画面のタイトルにアニメーションを追加してください → 話し言葉にしない

フローを決めよう

課題の登録や完了のフローを決めましょう。
課題を完了するのはプロダクトマネジャーに限定したり、親課題の完了は各職能のリーダーにするなどの方法があります。
重要な課題は責任者を含めた複数人が関わる方が良いですが、重要な範囲を広げすぎないことも大事です。例えば、バグ報告は課題登録者が確認して完了とするといったルールが良いと思います。

担当者を切り替えよう

ひとつの課題を複数の作業者が担当することはよくあることです。自分の作業が終わったら、次の人に担当を変更しましょう。作業が終わった課題を貯めていたら、プロジェクトは進みません。

ファイルの管理方法を決めよう

Backlogには課題とは別に色々なファイルをアップロードする場所があります。こちらもルール化しないとゴチャゴチャになります。特によく更新されるデータは、最新のデータの場所を明確にしましょう。フォルダを整理した上で、Wikiにデータの場所について説明を書いておくと良いと思います。
ファイル更新時の連絡ルールとして、必ず課題を通すのは良い方法です。直接URLをSlackなどで送ると、後から文脈を追いにくくなるためです。

連絡方法を決めよう

仕事の連絡方法は色々なチャンネルがあります。(メール、Slack、電話…)
Backlogに登録した内容をSlackで連絡し、問題ないか電話で確認していては効率が悪いです。連絡のコミュニケーション・コストを最適化するために、「Backlogを中心に課題を管理する」といったやり方をチームで徹底するのも方法のひとつです。
もちろん、緊急時はコスト云々言ってられませんが。

ルールを更新しよう

一度決めたルールは変えられないわけではありません。
使い勝手が良いよう、プロジェクトの状態に合わせて更新しましょう。更新のための確認フローを決めておくと良いかもしれません。更新を提案できる場と、相談できる相手がいれば、もやもやは減ります。
人や状況によって選ぶべきルールは変化します。その時々の最適解を探りましょう。

2. ルールを守る

Wikiを活用する

BacklogにはWiki機能があります。制作についての情報をまとめるだけでなく、Backlogの運用ルールを書いておきましょう。困った時の相談窓口も書いておくと良いです。

チーム内に共有する

みんながルールがあることを意識している状態をつくらなくては、ルールは機能しません。
プロジェクトのはじめにしっかり話し合うことが肝心です。Backlog課題の書き方について話すことは、どうしても優先度が低く設定されがちです。期間の長いプロジェクトほど、はじめにしっかり共有することで、後から困らないでしょう。

みんなで守る

プロジェクトが進むと、どうしてもルールがゆるくなることがあります。次の工程を担当する人のためにも、みんなでルールを守りましょう。
忙しい時、「とにかく課題を立てよう。内容の整理は後回しで」といった事が起こりがちです。ただ、その課題を受け取る人も忙しいことは容易に想像できます。忙しい時ほど丁寧に課題をつくりましょう。
どうしてもルールが乱れてしまった時は最終手段です。「みんなでBacklogルールを読み合わせる」という課題を立てましょう。

状況を確認する

ルールを守るためにも、まずは「自分の状況を知ること」が大事です。
Backlogを使い始めた人には、まず以下の3つを覚えましょう。

  • 課題の検索をする(基本は、完了以外自分が担当の確認。)
  • ガントチャートを見る(「いつまでに、何をするか」を意識する。)
  • メール通知を設定する(必要な情報だけ届くように。もしくは分類する。)

マネージャーやリーダーは、複数人分の課題を見ることになると思います。1日の終わりや決めた曜日に必ず確認するといった習慣をつくると良いでしょう。Backlogで一番怖いのは、「放置」です。

3. まとめ

今回、チームで開発する上でBacklogについて考えるべき項目をまとめました。
具体的にどういった内容のルールを選択するべきかは、プロジェクトの性質(規模、期間、スピード感、フェーズ)により多種多様です。規模が大きく、期間が長いほどルール化は重要になってきますが、小さいプロジェクトでも身軽なルールがあると良いでしょう。
大事なのは、ルールをつくるだけではなく、チーム内で共有し協力して運用することです。
上手に使って、効率的に開発しましょう。

3
8
1

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
3
8

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?