こんにちは、チャイフ(@chaif123)です。
プロジェクトマネージャーがいかに大変かを説明する連載記事です。
こちらの記事でも述べた通り、技術やツールは「お客様に迷惑をかけないこと」「QCDを守ること」の手段でしかありません。
とはいえ、非常に有用なツールは多く、うまく活用することでプロジェクトを円滑に進めることができます。プロジェクトマネジメントをする上で必須なのがスケジュール管理・タスク管理で、そのための代表的なツールがBacklogです。今回は、Backlogでタスク管理を進める上での注意点について解説します。
それでは！
Contents
プロジェクトマネージャーとは？
そもそも、プロジェクトマネージャーとはどんな仕事でしょうか？
細かい所掌範囲や定義は会社によって異なるとは思いますが、共通する要素としては、「納期までに成果物を完成させられるように、プロジェクトをマネジメント（≒管理）する」仕事ではないでしょうか。
そのために、例えばこんな業務が挙げられるでしょう。
- キックオフ
- クライアントの要望から計画の立案
- 全体スケジュールの作成
- 担当メンバーのアサイン
- プロジェクト推進
- マイルストーン管理
- 担当メンバーの進捗管理
- 担当メンバーのモチベーション管理
- プロジェクトのコスト管理
- クライアントへの進捗報告
- 問題発生時の対応
- クロージング
- 納期の調整
- 成果物の取りまとめ
- クライアントへの成果報告
プロジェクトに関わるあらゆることを調整するので、必然的にお客様（クライアント）、プロジェクトメンバー、下請け、社内の上司などあらゆる人とのコミュニケーションが発生します。したがって、情報をまとめる能力・的確に説明する能力・折衝能力・リスクを察知する力・決断力・問題解決力など、様々な適性が存在します。
Backlogとは？
Backlogとは、プロジェクト管理ツールです。無料の類似ツールとしては、オープンソースソフトウェアとしてRedmineがあります。機能として「Backlogでしかできないこと」はほとんどなくRedmineでも十分に代替可能ですが、Backlogの方がUIが使いやすいなどの利点があるため、今回はBacklogについてのみ紹介します。
（by https://backlog.com/ja/features/）
タスクチケットのライフサイクル
Backlogにはさまざまな機能がありますが、チケット作成→チケット消化の2つが基本になっています。それに様々な情報を付与できて、プロジェクト管理に活用できるというだけです。
そこで、タスクチケットが作成されてから完了するまでのライフサイクルを簡単に見てみます。
- PM（プロジェクトマネージャー）あるいはTL（テックリーダー）などがタスクチケットを作成します。
-
- チケットの内容として、「目的」「背景」「成果物」「作業内容」「参考URL」などを項目として書いてあげると認識齟齬が減るでしょう。
- 担当者、カテゴリー、期限を設定します。
- マネージャーが”担当者”にチケット作成完了の旨を通知し、そのタイミングでチケット管理はほぼ”担当者”の責務になります。
- “担当者”が随時タスクを進め、進捗に応じてステータス変更・進捗報告を行います。
- PMは、毎日〜週1回の適切な頻度で各チケットの進捗を確認し、期限に対する完了見込みを”担当者”に確認します。
- 間に合いそうならステイ、間に合わなさそうで延長して問題なければ延長、延長して問題ありそうであれば、中断・リソース投入・納期交渉などの対応を考えます。
- “担当者”はタスクをやり終えたらステータスを「処理済み」にしてPMに通知、PMが成果物を確認する。OKであればステータスを「完了」に変更、NGであれば”担当者”に差し戻しを行います。
僕は「カンバンボード」「バーンダウンチャート」「Githubとの連携」はうまく使えておらず、「ガントチャート」のみを利用していますが、プロジェクトでのタスク管理をするだけなら十分だと思います。
Backlogを運用する上での注意点
確かにやることはシンプルです。しかし、それを実際に問題なく運用していくことは実は難しいです。
そこで、何がどう難しいのか、Backlogを運用する上での注意点を3つ紹介します。
発生したタスクは漏れなくタスクチケットに落とし込むこと
1つ目は、発生したタスクは漏れなくタスクチケットに落とし込むことです。
目的は「todoを忘れないため」と「記録として残すため」の2つです。
タスクは、ミーティングの中で生まれます。タスクを進める中でも生まれます。それでも「これがタスクで、内容はこうだよ」と教えてくれる人はいません。PMがタスクを形にする必要があるのです。
放っておくとフワフワと飛んでいって忘れられていきそうなその”課題らしきもの”を捕まえて、目的と完了要件を言語化してチケットの形に押し込む。そんな感覚です。
これが、タスクチケット作成の難しさです。
作成したチケットの管理責任は”担当者”にありますが、チケット作成の責任はPMにあります。「やるべきこと」をPM・メンバー、引いては上司がBacklogのガントチャートを見れば一目瞭然になっていること。これが理想です。
“担当者”に責任を持たせること
2つ目が、”担当者”に責任を持たせることです。
”担当者”には以下の2つを命じ、徹底させましょう。
- 実態通りに進捗のステータスを変更すること
- 作業に伴う進捗結果・考察・発生した課題などをコメント欄に記載する
「有能な人」「無能な人」という絶対的な能力ではなく、人には向き不向きがあります。
例えば、作業スピードは遅いが進捗報告は丁寧にやってくれる人もいれば、作業スピードは速いが進捗報告が雑な人もいます。どちらが良いか悪いかではなく、メンバーごとの性質を理解して、そこも含めてマネジメントしていくのがPMの力の見せ所と認識しています。
僕の感覚では、「タスクを片付けさえすれば（報告が不完全でも）文句はないだろう」と考えているプレイヤーは少なくないと思っています。
しかし、PMの重要な業務の1つが「プロジェクトの状況を把握していること」です。そう考えれば、PMとしてはタスクが「終わったか終わってないか」だけでなく「どのように進捗してどんな課題が見つかったのか」まで知っておきたいです。
チケットのコメントでテキストベースでの進捗報告をしてもらいつつ、必要に応じてミーティングを行い、詳細をヒアリングしておくようにしましょう。
PMのレビューを以て完了とする
3つ目が、PMのレビューを以て完了とすることです。
“担当者”がやって終わりではなく、PMのレビュー（確認作業）によって完了になります。
健全なコーディングチームでは、レビュー文化がしっかり根付いています。開発者が「OKだ」と思ったコードも、必ずレビュアーがレビューを行なって、リリースされます。
Backlogのチケットも同じです。元々、プロジェクトとして発生した課題を遂行したいのはPMだったハズです。PMがそのタスクをプレイするわけにはいかないので、チケットの形にして”担当者”に振り分けている状態です。
したがって、PMが成果物の内容を把握し、イメージしていた成果物になっていることを確認して初めてステータスが「完了」になります。それまでは「処理済み」というステータスが使われます。
例えば、お客様に製品を納品するとして「中身がよくわからない”担当者”がOKと言ったモノ」を納品するのは、あってはなりません。それは”信頼”ではなく”怠慢”です。
少なくとも、技術的に理解ができていなくとも、想定する価値があることを確認することは必須なのです。
Backlogを使ってタスク管理をしてみましょう
いかがでしたでしょうか。
ちなみに個人でのタスク管理をするには、タスクシュートクラウドが至高です。
「1分以上のタスクは全て登録する」という思想もあり、「備忘」「記録」の両面で、個人用Backlogのような感覚があります。ガントチャートとかはないですが、1日の終了時間が見れるので、1日の設計には最高です。
一方、複数人でタスクの状況を把握するには、Backlogが至高です。
有料なので「ちょっと使ってみる」というのは難しいですが、すでに「会社でBacklogを使ってるよ」という方は、ぜひこの記事で紹介した注意点を参考にしてみてください。
それでは。
チャイフ
