読者です 読者をやめる 読者になる 読者になる

Backlogを上手く活用するための課題

こんにちは。おいかわです。
弊社ではプロジェクト管理にBacklogを使っています。ですが私の担当してるプロジェクトでは、どうも上手く使えてないように思えます。というわけで、現状の課題点と対応策について考えてみました。

ぼくの考える理想的な運用

  • タスクはすべて登録されている
  • 開始日・期限日も登録されておりガントチャート化出来る
  • ステータスは常に現在の状態に更新されている
  • 作業内容はすべて記載されていて、後から容易に追うことが出来る
  • 過去のタスクの予定時間・実時間を参考に見積もり精度を上げる
  • プロジェクトの情報はすべてWikiを見れば分かる
  • タスクの完了は登録者が確認後行う

つまりBacklogを見ればプロジェクトの状態がひと目で分かるようにしたいわけです。当たり前といえば当たり前のことですが、これが導入した目的でもあるわけです。

では、それに対して現在はどのような状態かというと

うまく使えてるところ

  • 作業内容はすべて記載されていて、後から容易に追うことが出来る(達成率80%)
  • プロジェクトの情報はすべてWikiを見れば分かる (達成率40%)

作業内容は割と細かく書いてもらえています。これにより他の人がどんな作業を行ったのか確認が容易になりました。また、Gitのコミットメッセージにタスクのキーを必ず登録するようなルールとし、Backlogのタスクとコミットを紐付けて、その修正の背景がすぐに分かるようにしています。(本当はリリースバージョンも登録した方が良いかもしれません) ※BacklogにもGitは含まれているのですが、弊社ではGitBucketを使ってますのでそちらは使っていません。なので直接の連携はしていません。

また、Wikiの利用はまだまだ少ないですが作業手順のまとめなど徐々に増えていっています。現在、Excel等に分散している情報や、システムの仕様、ミーティングの議事録なども登録していきたいですね。理想は新しく入ったメンバーがここを読めば全部分かる!という状態です。

どうにかしないといけないところ

  • タスクの登録漏れがある
  • ステータスの更新漏れ
  • 開始日・期限日・予定時間・実時間が登録されていない
  • 作業担当者自身がタスクの登録・完了を行っている

  • タスクはすべて登録されている → 漏れがある

  • 開始日・期限日も登録されておりガントチャート化出来る → されてない
  • ステータスは常に現在の状態に更新されている → 漏れがある
  • 過去のタスクの予定時間・実時間を参考に見積もり精度を上げる → ほとんどされてない
  • タスクの完了は登録者が確認後行う → 担当者が行っている

タスクの登録漏れは開発メインのプロジェクトではほとんど無いのですが、導入作業メインのプロジェクトで多く見受けられます。これについてはタスクの洗い出しといった作業がそもそも抜け落ちてることもありプロセスの見直しを現在行っています。

その他の項目については他のプロジェクトでもありがちなのではないでしょうか?結局、このようなツールを使って一番メリットを享受出来るのは管理者なわけです。各作業担当者にしてみれば余計な手間が増えたくらいにしか思っていないかもしれません。もちろん、情報の共有は管理者以外にも大きなメリットのあることなのですが、そのことが伝えられていないというのはあります。

どうしたらよいのか?

まずやるべきことは

  • どういうことをやりたいのか?
  • それによりどんなメリットがあるのか?

をはっきりと共有することなのではないでしょうか。その上で運用ルールをしっかりと決めて、これもしっかり共有することが大事だと考えます。

また、作業担当者の負担をシステム面からも軽減してあげることも重要なのではないでしょうか。例えば、弊社ではタスクの登録やステータスの更新がslackに通知されるようにしています。埋もれがちな標準のメール通知より確実に通知できます。こちらで紹介されているZapierを使うとスクリプトなどを書かずに簡単に連携出来るので便利ですね! nulab-inc.com

また、現在はGitBucketを使用しているため出来ていないコミット時のタスクステータスの更新も取り組みたいと考えています。これによりステータス更新漏れは大幅に減るはずです。(実装したら紹介します)

ツールを使う目的は便利だったり、楽をするため(最終的には)だと思いますので、ツールを使うこと自体が目的にならないように気を付けつつ、上手く使いこなしていきたいですね。